【响应式布局】initial containing block、viewport以及相关尺寸

在移动端浏览器，不管处于哪种模式，不管有没有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文档。