在移動端瀏覽器，不管處于哪種模式，不管有沒有viewport meta tag，layout viewport的尺寸（以CSS像素為單位）在頁面加載以后就固定了。無論用戶如何縮放、調整瀏覽器窗口大小（這在手機上似乎做不到），layout viewport的尺寸都不會改變。
因此，不管你在移動端瀏覽器如何縮放，頁面布局都不會改變。

“layout viewport的尺寸在頁面加載以后就固定了”，這個歸納有一個例外：用戶可以在加載好頁面以后切換橫屏、豎屏模式，從而meta viewport tag中的device-width發生改變，從而layout viewport寬度改變。

造成以上不同的原因是，在桌面端的縮放和在移動端的縮放有不同的性質。見我在上一篇文章的討論。

使用media query查詢width、height的時候（比如@media screen and (max-width: 500px) {...}），查到的是layout viewport的尺寸，并且px指的是CSS像素。在桌面端和移動端都是如此。

MDN 文檔也指出了這一點：... if the virtual viewport(也就是這里所說的layout viewport) is 980px for example, media queries that kick in at 640px or 480px or less will never be used, limiting the effectiveness of such responsive design techniques.

例子：

這個例子中，在桌面瀏覽器，通過改變瀏覽器窗口大小或者改變縮放比例，都能造成媒體查詢結果的改變。前面已經解釋過了，這兩個操作都會造成layout viewport尺寸的改變。

為了讓讀者明白meta viewport、媒體查詢出現的原因，這里舉一個例子：
有很多網站沒有針對移動端進行優化。對于這些網站，如果在移動端上將layout viewport的尺寸設置為visual viewport的尺寸（寬度為360CSS像素左右），那么排版可能會完全亂掉（意料之外的換行、溢出）。為了能正確顯示這種網站的排版，如果沒有meta viewport的指示，移動端瀏覽器將layout viewport的尺寸設為與電腦瀏覽器一樣，比如980px（單位：CSS像素）。由于手機的屏幕邏輯像素寬度一般只有300~400邏輯像素，因此需要將多個css像素由1個邏輯像素顯示（也就是縮小，不要忘記縮放比例=css像素邊長/邏輯像素邊長），通過縮小css像素讓手機屏幕顯示的css像素與網頁的css像素一樣多。

但是這會引發一個問題：字體小得難以閱讀。用戶閱讀的時候又不得不用手指將縮放比例調整到100%左右（一個設備獨立像素顯示一個css像素，對于我的手機來說，水平方向只有360個設備獨立像素），這個時候visual viewport只顯示layout viewport的一部分了。閱讀的時候需要橫向、縱向滾動。

雖然能夠閱讀網站內容，但這依然是一種非常差的用戶體驗。

適配移動端的時候，先使用來定義layout viewport的寬度，然后通過媒體查詢來為不同的layout viewport定義不同的CSS排版。以下是瀏覽的效果（使用“查看移動版網站”模式）：

現在的字體大小合適了，網頁的排版變化了，沒有元素橫向溢出，沒有橫向滾動條，在移動端上的閱讀體驗更好。

上一篇文章說過的screen.width/height：整個屏幕的寬度和高度。這兩個數值的單位是設備獨立像素。這兩個數值不隨頁面縮放、瀏覽器窗口大小而改變，在前端開發的過程中可以認為是固定不變的（除非你通過操作系統改變屏幕的分辨率）。這兩個數值是操作系統決定的，由于設備獨立像素:設備像素經常不等于1：1，實際屏幕物理像素的分辨率不一定是screen.width×screen.height。

在上圖中列出了iphone各代的設備分辨率（物理分辨率）和邏輯分辨率，我們只需要看這兩行。

設備分辨率就是屏幕上的物理像素的數量，當手機廠商宣傳自己的屏幕有多么清晰銳利的時候，相互攀比的就是這個數值。

邏輯分辨率就是screen.width/height。為什么iphone3GS以后的iphone都要把這個值設為實際屏幕分辨率的1/2或1/3呢？因為隨著屏幕上塞進越來越多的物理像素，屏幕大小的變化卻不那么明顯，因此像素密度也越來越高。如果還讓邏輯分辨率：真實屏幕分辨率=1：1，那么12px的字體就會越來越小，影響閱讀體驗。因此，后續的iphone用4個物理像素（甚至9個像素）組合成一個“邏輯像素”。這樣，即使物理像素越來越小，每一個“邏輯像素”的大小變化不大。瀏覽器可以放心地使用邏輯像素來衡量大小，而不用擔心真實大小在不同的顯示器上出現嚴重偏差。

visual viewport的大小，也就是瀏覽器內容窗口的大小，不包括菜單欄、地址欄、狀態欄等，但是包括滾動條。單位是CSS像素。通過這個屬性你可以知道，當前的瀏覽器窗口可以容納多少個css像素。當用戶放大的時候這個數值會減少（因為css像素變大了），當用戶縮小的時候這個數值增大。縮放改變瀏覽器窗口都會改變這個屬性的值。

與之對應的，window.outerWidth/outerHeight給出整個瀏覽器窗口的大小（包括各種欄），但是單位是設備獨立像素。

Layout Viewport(initial containing block)的尺寸。注意，Layout Viewport沒有滾動條（根據css溢出機制探究中的討論，只有元素或者visual viewport才能擁有滾動條）。單位是CSS像素。

document.documentElement指的是html元素，通常Element.clientWidth應該給出元素的內容區域的大小，但是document.documentElement.clientWidth/Height并不衡量html元素的大小，這是一個特例。各個瀏覽器都遵循著這個約定。并且，這個約定正在被標準化。

元素的尺寸。前面已經討論過元素的尺寸是如何計算的了，默認情況下的寬度始終與Layout Viewport寬度相同。單位是CSS像素。元素的高度由內容撐開。

滾動距離，描述visual viewport已經向右、向下滾動了多少個像素。也可以理解為visual viewport相對于layout viewport的偏移值。單位是CSS像素。

它們分別有1個別名（前者的兼容性更好些）：

window.pageXOffset == window.scrollX; // always true
window.pageYOffset == window.scrollY; // always true

此外，由于Element上就有獲取內容滾動的scrollLeft、scrollTop屬性（所有Element都可以使用），因此還有：

window.pageXOffset === document.documentElement.scrollLeft; // always true
window.pageYOffset === document.documentElement.scrollTop; // always true

當用戶進行縮放的時候，瀏覽器會盡量保證：原先在內容區頂部的元素，在縮放以后依然在內容區頂部，看以下例子：
放大前：

放大后：

原本數字3在頂部，放大后3依然在頂部。window.pageYOffset大致相同。大致相同的原因是CSS像素數量不隨著縮放而變化，原本在上方的內容高度有多少個CSS像素，放縮以后依然是多少個CSS像素。至于為什么不是完全相同，是因為"原先在內容區頂部的元素，在縮放以后依然在內容區頂部"這一機制無法完美地做到。

https://www.quirksmode.org/mo...

https://www.quirksmode.org/mo...

https://www.quirksmode.org/bl...

一些比css2.1更新的文檔（但是還沒有正式作為Recommondation規范）：

CSS Snapshot CSS3開始，CSS不再由一份大而全的文檔來定義，而是分成多個模塊、由多個文檔來定義，方便各個技術的獨立演化。這份文檔收集了當前隸屬于CSS的、相對穩定的文檔。

CSS Box Model Module Level 3 盒模型文檔。該文檔的內容與CSS2.1相比沒有變化。

CSS Positioned Layout Module Level 3 布局、層疊文檔。

CSS Display Module Level 3 CSS formatting box tree文檔。