浏览器渲染过程梳理

当我们输入一个 www.google.com 到浏览器搜索框的时候，经过一系列通信链路，我们最终拿到了一份HTML文件。

浏览器会使用这份HTML文件来 构建DOM、构建CSSOM、再将两者合并成Render树、再排版Layout、再绘制Paint。

整个Web页面的构建过程我们可以通过监听 document 的 readystate 变化事件，

变化过程为：

构建DOM的过程就是将HTML字符串解析成DOM树

构建CSSOM时是 将浏览器默认的样式，和用户自定义的样式构建

将上述DOM和CSSOM的过程是，将 display=none(visitibilty=hidden不能忽略)、不显示的节点（如meta、link）忽略，再合并，这样就能得到每个可见节点的位置以及样式信息了

Layout排版的过程是 先拿到视口 viewport 的宽高，然后 使用Containing Block 容器盒子 的规则进行计算每个结点的位置，

首先是 Containing Block 容器盒子的规则是

（1） 如果是常规流定位，且 子元素盒子 使用百分比，则 子元素 的 height 以 容器盒子的height为基准，width 与 margin 与 padding 以容器盒子的 width 为基准

（2） 如果是绝对定位（absolute 和 fixed）， 且用百分比来定义偏移量 left 、top、right、bottom，则以 容器盒子 的 border内侧 为起点

如何找到一个子元素盒子的 Containing Block 容器盒子呢？

分情况讨论：

（1）如果是普通流，即 position 缺省为 static ，或为 relative ， 则为 它的父元素的 content 部分。

（2）如果是绝对定位中的 absolute，则为 它的祖先元素中 position值不缺省为static的元素，如果找不到就用 viewport 视口作为容器盒子。

（3）如果是绝对定位中的 fixed，则为 viewport。

知道 viewport 这类 依照容器盒子来计算子元素盒子的位置规则后，还得知道每个元素节点的自身规则。

渲染树中的每个元素节点都会被渲染成一个个盒子，对应的规则就是盒子模型。

我们可以指定我们想要的盒子模型，

如用 box-sizing=content-box 选择标准盒子模型，

这样的话我们给盒子指定宽高只是指定content部分的宽高，而非整个盒子的宽高

还可以用 box-sizing=border-box 选择IE盒子模型。

这样指定宽高是指定 border2+padding2+width 的大小

chrome 中默认都是标准盒子模型，我们无需过于在意

在我们指定盒子模型的类型后，每个不同的元素节点会按照规定，将自身渲染成 块级盒子 和 行级盒子

常见的块级盒子有 div、p

常见的行级盒子有 span、a

如果是在常规流的定位方案中，块级盒子是自上而下一行一行的摆放的，而行级盒子是从左到右，一行摆不下就再放一行。

用户不能给行级盒子的垂直方向设置 height、padding、margin，但是水平方向是可以的。

摆脱常规流有两种做法，浮动 和 绝对定位，

浮动的布局方案为，使用 float=left 或者 float=right 将盒子向左或者向右浮动，浮动规则是：

从常规流的位置向左浮动直到碰到之前浮动的元素，或者 容器盒子的边界 为止。

因此按这个规则我们就能写出三栏布局问题中的 圣杯布局 和 双飞翼布局，从而解决实现3栏，中间栏先加载，且左右宽度固定，中间栏宽度自适应。

<<<< ------------------------ 占坑：补充三栏布局实现方案 >>>>

除此之外，较为现代且常用的布局方案还有 flex弹性盒子布局、grid表格布局，补充补充！

浮动定位的表现是，如果相邻节点会被渲染成块级盒子，则会被相邻节点给忽视且覆盖掉，

如果相邻节点被渲染成行内盒子，则行内盒子会环绕浮动定位的盒子。

由此可见，浮动定位后的盒子会影响他们的兄弟节点盒子与父节点盒子。

因此，清除浮动的各种方法便应运而生，如BFC，如clearfix等等，这些其实我都不会，补充补充！

最终是绝对定位的布局方案，他们不会影响兄弟和父节点。

Layout完毕，就是绘制了。

至此，第一次渲染完毕。

如果后续操作不当，频繁操作更新DOM以及CSSOM就会频繁重排重绘，严重影响性能，因此，为了性能，一些避免频繁重排重绘的操作也就应运而生了：如虚拟DOM、影子DOM、先隐藏再进行更新。

这些我都不懂，补充补充！

文章的最后，再加入<script>脚本进行讨论，看看上述的构建过程又会变成什么样子。