主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
家园 Z-order 我在第20篇，“结构与解构”一文的例子里，用到了z-order。注意看第20篇figure 1.，图中两行字浮在Einstein头像上。
本来想仔细跟踪一下z-order的实现方法，实际跟踪以后发现，涉及相当多的objects，为了突出重点，暂时不去深究。
大致说来，在render tree以外，还有一棵shadow tree，z-order里面的东东，都在shadow tree里放着。因为没有深究，所以不敢妄加评判，但是感觉与render tree平行着，再建一个shadow tree，似乎不是表现力很丰富的做法。
家园 不枯燥,不枯燥,老邓写得深入浅出,看得入迷得很哩. 家园 不是太枯燥了,是太技术了.像俺这样的纯外行估计都看不懂啊 期待下面与管理决定相关的优劣分析. 花~~
家园 务虚与务实 这个系列前几篇都是在谈商机，谈vision。高瞻远瞩当然很重要，但是把目光总是投射在远方也不是事儿，谈来谈去，自己觉得不踏实，心虚。所以，决定把视线收拢回来，聚焦在近处，看看究竟如何才能实现远大的梦想。
这不，把视线聚焦在源代码上，虽然文章写得慢了，但是贴上一张沉甸甸的sequence diagram，自己心里觉得踏实。
但是踏实未必叫座，源代码里涉及的问题不仅庞杂，而且不容易解释清楚。既正确，又明白，最好还能有趣，的确不是一件容易的事。
所谓有趣，就是插入一些轻松的段子。但是这一篇，篇幅已经很长，如果再插入额外的段子，就太长了。
- 复 务虚与务实
家园 遥想当年大三的时候 我们一个学期有图形学，编译和微机三门大作业，我当时还在跟老婆热恋。
当时和三个同学一起做图形学的东西,scope是：
1.一个DOS下面的图形界面，包括窗口，按钮，鼠标输入的3维旋转体建模，鼠标进行物体的三维移动
2.光线跟踪算法，计算透明物体在一个有bmp作为墙纸的场景中的render
3.三维视角模型，完整的文档
当时为了那个图形界面，我们从BC++的bitset开始写起，硬是在半个学期+寒假把这个东西给做出来了，从此以后，看到视窗模型和鼠标事件这些事情，就觉得很自然了。
家园 光看不够，还得动手 实际动手做一遍，道理就明白了。
当然，这个过程是比较痛苦的。
- 复 务虚与务实
家园 也谈务实与务虚。 那个click与WEBKIT(RENDER ENGINE)的问题可以先放到一边。如果不是真正对优化engine有兴趣的人相信不一定能深入其中，但是真正对非文本编辑器（比如CAD,CAM软件）有设计经验的人都会按那个思路来操作。
上面的人（比如CTO,或者乔布斯这样的CEO）务虚完成后，就是底下的DIRECTOR，PM,甚至SENIOR开始给这些人“擦屁股”。“擦屁股”就是真正的务实，比如要多少人多少时间，多大的预算。没有这些务实，务虚就是埃里森嘴里的网络计算机，雾中花，水中月。大公司务虚务错了没有关系，反正东方不亮西方亮，手下的人如果务实悟不出来也好办。CFO过来一下，公司手里还有多少现金?CTO过来一下,那个TOM的team实在是有问题，这么长时间都搞不定，打开你的雷达，去找个有类似东西的小公司，让CFO下面的团队看看能不能搞定它们。如果这个小公司后面能搞定，TOM的team就地解散，TOM本人的问题你自己看着办。
家园 【原创】【22】WebKit，鼠标引发的故事，上 【22】WebKit，鼠标引发的故事
外链图片需谨慎，可能会被源头改Figure 1. JavaScript onclick event
Courtesy http://farm4.static.flickr.com/3302/3640149734_3268bf297f_o.jpg
先看一段简单的HTML文件。在浏览器里打开这个文件，将看到两张照片。把鼠标移动到第一张照片，点击鼠标左键，将自动弹出一个窗口，上书“World”。但是当鼠标移动到第二张照片，或者其它任何区域，点击鼠标，却没有反应。关闭“World”窗口，自动弹出第二个窗口，上书“Hello”。
<html>
<script type="text/javascript">
function myfunction(v)
{
alert(v)
}
</script>
<body onclick="myfunction('Hello')">
<p>
<img onclick="myfunction('World')" height="250" width="290" src="http://www.dirjournal.com/info/wp-content/uploads/2009/02/antarctica_mountain_mirrored.jpg">
<p>
<img height="206" width="275" src="http://media-cdn.tripadvisor.com/media/photo-s/01/26/f4/eb/hua-shan-hua-mountain.jpg">
</body>
</html>
这段HTML文件没有什么特别之处，所有略知一点HTML的人，估计都会写。但是耳熟能详，未必等于深入了解。不妨反问自己几个问题，
1. 浏览器如何知道，是否鼠标的位置，在第一个照片的范围内？
2. 假如修改一下HTML文件，把第一张照片替换成另一张照片，前后两张照片的尺寸不同。在浏览器里打开修改后的文件，我们会发现，能够触发弹出窗口事件的区域面积，随着照片的改变而自动改变。浏览器内部，是通过什么样的机制，自动识别事件触发区域的？
3. Onclick 是HTML的元素属性(Element attribute)，还是JavaScript的事件侦听器(EventListener)？换而言之，当用户点击鼠标以后，负责处理onclick事件的，是Webkit 还是JavaScript Engine？
4. Alert() 是HTML定义的方法，还是JavaScript提供的函数？谁负责生成那两个弹出的窗口，是Webkit还是JavaScript Engine？
5. 注意到有两个onclick="myfunction(...)"，当用户在第一张照片里点击鼠标的时候，为什么是先后弹出，而不是同时弹出？
6. 除了PC上的浏览器以外，手机是否也可以完成同样的事件及其响应？假如手机上没有鼠标，但是有触摸屏，如何把onclick定义成用手指点击屏幕？
7. 为什么需要深入了解这些问题？ 除了满足好奇心以外，还有没有其它目的？
外链图片需谨慎，可能会被源头改Figure 2. Event callback stacks
Courtesy http://farm4.static.flickr.com/3611/3640149728_bc64397f60_o.gif
当用户点击鼠标，在OS语汇里，这叫发生了一次中断(interrupt)。系统内核(kernel) 如何侦听以及处理interrupt，不妨参阅“Programming Embedded Systems” 一书，Chapter 8. Interrupts。这里不展开介绍，有两个原因，1. 这些内容很庞杂，而且与本文主题不太相关。2. 从Webkit角度看，它不必关心interrupt 以及interrupt handling 的具体实现，因为Webkit建筑在GUI Toolkit之上，而GUI Toolkit已经把底层的interrupt handling，严密地封装起来。Webkit只需要调用GUI Toolkit 的相关APIs，就可以截获鼠标的点击和移动，键盘的输入等等诸多事件。所以，本文着重讨论Figure 2 中，位于顶部的Webkit和JavaScript两层。
不同的操作系统，有相应的GUI Toolkit。GUI Toolkit提供一系列APIs，方便应用程序去管理各色窗口和控件，以及鼠标和键盘等等UI事件的截获和响应。
1. 微软的Windows操作系统之上的GUI Toolkit，是MFC(Microsoft Fundation Classes)。
2. Linux操作系统GNOME环境的GUI Toolkit，是GTK+.
3. Linux KDE环境的，是QT。
4. Java的GUI Toolkit有两个，一个是Sun Microsystem的Java Swing，另一个是IBM Eclipse的SWT。
Swing对native的依赖较小，它依靠Java 2D来绘制窗口以及控件，而Java 2D对于native的依赖基本上只限于用native library画点画线着色。 SWT对native的依赖较大，很多人把SWT理解为Java通过JNI，对MFC，GTK+和QT进行的封装。这种理解虽然不是百分之百准确，但是大体上也没错。
有了GUI Toolkit，应用程序处理鼠标和键盘等等UI事件的方式，就简化了许多，只需要做两件事情。1. 把事件来源(event source)，与事件处理逻辑(event listener) 绑定。2. 实现事件处理逻辑的细节。
Figure 3 显示的是Webkit如何绑定event source和event listener。Figure 4 显示的是Webkit如何调用JavaScript Engine，解析并执行事件处理逻辑。首先看看event source，注意到在HTML文件里有这么一句，
<img onclick="myfunction('World')" height="250" width="290" src=".../antarctica_mountain_mirrored.jpg">
这句话里“<img>”标识告诉Webkit，需要在浏览器页面里摆放一张照片，“src”属性明确了照片的来源，“height, width”明确了照片的尺寸。“onclick”属性提醒Webkit，当用户把鼠标移动到照片显示的区域，并点击鼠标时(onclick)，需要有所响应。响应的方式定义在“onclick”属性的值里面，也就是“myfunction('World')”。
当Webkit解析这个HTML文件时，它依据这个HTML文件生成一棵DOM Tree，和一棵Render Tree。对应于这一句<img>语句，在DOM Tree里有一个HTMLElement节点，相应地，在Render Tree里有一个RenderImage节点。在layout() 过程结束后，根据<img>语句中规定的height和width，确定了RenderImage的大小和位置。由于 Render Tree的RenderImage节点，与DOM Tree的HTMLElement节点一一对应，所以HTMLElement节点所处的位置和大小也相应确定。
因为onclick事件与这个HTMLElement节点相关联，所以这个HTMLElement节点的位置和大小确定了以后，点击事件的触发区域也就自动确定。假如修改了HTML 文件，替换了照片，经过layout() 过程以后，新照片对应的HTMLElement节点，它的位置和大小也自动相应变化，所以，点击事件的触发区域也就相应地自动变化。
在onclick属性的值里，定义了如何处理这个事件的逻辑。有两种处理事件的方式，1. 直接调用HTML DOM method，2. 间接调用外设的Script。onclick="alert('Hello')"，是第一种方式。alert()是W3C制订的标准的 HTML DOM methods之一。除此以外，也有稍微复杂一点的methods，譬如可以把这一句改成，<img onclick="document.write('Hello')">。本文的例子，onclick="myfunction('world')"，是第二种方式，间接调用外设的Script。
外设的script有多种，最常见的是JavaScript，另外，微软的VBScript和Adobe的ActionScript，在一些浏览器里也能用。即便是JavaScript，也有多种版本，各个版本之间，语法上存在一些差别。为了消弭这些差别，降低JavaScript使用者，以及 JavaScript Engine开发者的负担，ECMA(欧洲电脑产联)试图制订一套标准的JavaScript规范，称为ECMAScript。
各个浏览器使用的JavaScript Engine不同。
1. 微软的IE浏览器，使用的JavaScript Engine是JScript Engine，渲染机是Trident。
2. Firefox浏览器，使用的JavaScript Engine是TraceMonkey，TraceMonkey的前身是SpiderMonkey，渲染机是Gecko。TraceMonkey JavaScript Engine借用了Adobe的Tamarin的部分代码，尤其是Just-In-Time即时编译机的代码。而Tamarin也被用在Adobe Flash的Action Engine中。
3. Opera浏览器，使用的JavaScript Engine是Futhark，它的前身是Linear_b，渲染机是Presto。
4. Apple的Safari浏览器，使用的JavaScript Engine是SquirrelFish，渲染机是Webkit。
5. Google的Chrome浏览器，使用的JavaScript Engine是V8，渲染机也是Webkit。
6. Linux的KDE和GNOME环境中可以使用Konqueror浏览器，这个浏览器使用的JavaScript Engine是JavaScriptCore，前身是KJS，渲染机也是Webkit。
同样是Webkit渲染机，可以调用不同的JavaScript Engine。之所以能做到这一点，是因为Webkit的架构设计，在设置JavaScript Engine的时候，利用代理器，采取了松散的调用方式。
家园 打屁股12 标题党啊，还是应该乱弹12。
不过这个“鼠标引发的故事”的帖子中问题多了点，俺认为“妨碍”了河友的正确理解，是不是该打楼主的“屁股”？
1.别的OS俺不是太熟悉。Windows操作系统之上可用于C/C++ GUI开发的GUI Toolkit(俺对TOOLKIT这个词质疑，是否应该用FRAMEWORK？)，包括但不仅限于MFC(Microsoft Fundation Classes)。比如BORLAND就先后有OWL,VCL。MS自己有MFC和ATL(Active Template Library)。为什么？第一是MFC框架的笨重，第二是MFC不支持多重继承。第二点在“现代”C++开发中特别重要。没有多重继承，许多代码设计模式比较难于实现（这个东西非常的枯燥和“丑陋”，俺不想在这里多费口舌）。但是俺可以100%负责任地说，CHROME在其WINDOWS上的“窗口”部分采用的是ATL的框架 --- 或者说CHROME的“窗口控件类”（CHROME的术语叫VIEW类）继承自ATL的CWindow。
2.关键的问题LZ在其叙述点击过程中的不“全面”对河友的“误导”。XDJM们打过枪没有？没有打过枪的请先学习射击基本知识。打枪扣动扳机前瞄准不？如果你不瞄准的话，剩下的东西你也别看了。相比扣动扳机，瞄准是个“漫长”的过程（成年人可以类比ML中的“活塞运动”与“高潮”。
）；扣动扳机仅仅是利用了瞄准的结果 --- 瞄准是为了射击（扣动扳机），射击必须依赖瞄准。。。。。。fire at will。回到楼主的帖子来。楼主的叙述把WIBKIT描述的其笨无比，按下鼠标键，然后。。。。。。WIBKIT是如此动作的。慢慢慢！！！鼠标的光标是从火星上掉下来然后突然跑到render tree的某个NODE上吗？在on_mouse_click这个事件前，有无数个on_mouse_over和on_mouse_out事件，而且on_mouse_over, on_mouse_out和on_mouse_click统统都是WEBKIT(RENDER ENGINE)的派生事件。难道无数个on_mouse_over和on_mouse_out事件，WEBKIT都无动于衷吗？无动于衷这个提法本身就有大问题。为什么？鼠标的运动是一个“连续”的过程，一个新的鼠标位置事件（由操作系统提供）被WEBKIT可能解释为on_mouse_over, on_mouse_out，on_mouse_click。。。WEBKIT(RENDER ENGINE)解释的过程就是与某个NODE的“绑定”（over）与“松绑定”（out）过程，而且这个结果可以重复利用 --- 新的鼠标位置信息，检查上一个“绑定”的NODE，如果位置还在这个NODE的范围，继续发on_mouse_over，返回；如果不在这个NODE的范围先给先给node发on_mouse_out，然后“遍历”NODE TREE,看看是否给给另外一个NODE发on_mouse_over 。。。。。。，返回。在某个时间尺度上，on_mouse_click之前必定是on_mouse_over --- 正如扣动扳机的时候枪口停止运动(别和俺抬杠自动武器的连发，鼠标就是一个古老的土枪，扣一下打一发
)。- 复 打屁股12
家园 太守是故意这么写吗？ 这明显是太细节的咚咚啦。
我个人感觉邓侃尺度把握的挺好
- 复 打屁股12
家园 这篇文章写得太匆忙 1. GUI Toolkit
俺对TOOLKIT这个词质疑，是否应该用FRAMEWORK？坦率讲，俺也同意你的观点。MFC也好，ATL也罢，已经不是toolkit，一个工具箱，想用就用不想用晾一边去。它虽然在操作系统以外，但是的确是系统必不可少的一部份。有点冤枉，如果说File System是OS的一部份，凭什么GUI就不是OS一部份？
但是，俺遵从Wikipedia。Wikipedia说那是GUI Toolkit，而不是Framework。好吧，那就工具箱吧。
2. ATL etc
Windows操作系统之上可用于C/C++ GUI开发的GUI Toolkit，包括但不仅限于MFC。比如BORLAND就先后有OWL,VCL。MS自己有MFC和ATL。GUI Toolkit的内容庞杂，历史纠结也深。应该单独写一篇。你看，把GUI Toolkit塞在Webkit event同一篇文章里，行文匆忙，涉嫌误导不说，读者也觉得累。这篇文章的内容太多了。
3. Event
WEBKIT(RENDER ENGINE)解释的过程就是与某个NODE的“绑定”（over）与“松绑定”（out）过程，而且这个结果可以重复利用 --- 新的鼠标位置信息，检查上一个“绑定”的NODE，如果位置还在这个NODE的范围，继续发on_mouse_over，返回；还是前面说的那个问题，一篇文章不宜塞太多内容，累人，而且有可能误人。
本来这些内容都该展开来慢慢谈的。结果，因为担心篇幅太长，就从略了。从略，就有误导的可能。
家园 GNOME环境中使用的浏览器是Konqueror? 家园 严格地说 严格地说，应该是“Linux的KDE和GNOME环境中可以使用Konqueror浏览器”，而并非，
Linux的KDE和GNOME环境中使用的浏览器是Konqueror谢谢提醒，马上去修改一下。
家园 终于见到通宝了，还是双宝 恭喜：你意外获得【通宝】一枚
谢谢：作者意外获得【通宝】一枚
鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】
家园 【原创】【21】WebKit，为了布局，忙并美丽着 【21】WebKit，为了布局，忙并美丽着
如果没有1440年以后活字印刷术的大规模普及，或许就不会有文艺复兴运动，更不会有后来的启蒙运动。如果没有这两个运动的开展，或许就不会有世界范围的工业化。
在活字印刷术出现以前，每出版一本书，都必须先刻制一套模版，称为雕版，每套雕版上的每一个字，都是手工雕刻的。不仅制作雕版费时费力，而且有了错误不容易更改。活字印刷术的进步在于，可以预先批量生产各种样式和大小的字体，称为活字。需要出版某一本书籍时，先制作该书的页面模版，模版做好以后，只需要把这些活字摆放在模版上即可。如果出现错误，只需要调换某些活字，既省时又省力。如果某本书的模版不需要长期保存，还可以把模版中摆放的活字拆解下来，在印刷其它图书时用，节约成本。
活字印刷术没有解决的问题，1. 图像的印刷。起初不能印刷笔触丰富，层次复杂的图像，一直到1796年，石板印刷术(lithography)出现以后，才能印刷表现手段丰富的图像。 2. 灵活的布局排版。纸张大小不同，布局排版也不同，布局变了，需要重新摆放活字，而且有时候还需要改变字体和大小。
灵活的布局排版对于纸质书籍来说，或许并不太重要，但是对于电脑浏览器来说，却必须实现完全的自动化。否则，每当用户改变浏览器窗口的大小的时候，页面内容就不能正确显示。对于手机浏览器来说，布局排版的自动化尤其重要，因为不同手机的屏幕不一致，而且屏幕分辨率也不同。
但是即便是浏览器，也没有摆脱传统的排版方式。所谓传统的排版方式，基本是横平竖直的，单一的鸟瞰视角。
外链图片需谨慎，可能会被源头改Figure 1. Incunabulum, the end of 15'th century
Courtesy http://www.citrinitas.com/history_of_viscom/images/printing/venice-1505.jpg
外链图片需谨慎，可能会被源头改Figure 2. City of Words, by Vito Acconi, 1999
Courtesy http://upload.wikimedia.org/wikipedia/en/6/63/%27City_of_Words%27%2C_lithograph_by_Vito_Acconci%2C_1999.jpg
Figure 1 中显示的是1490年代的书籍，不难看出，现代书报中广泛使用的双列，边注，页码，首字母大写等等，都是继承了500多年以前的做法。而CSS规范，囊括了所有这些页面设计的要素。
在当今信息爆炸的形势下，如何安排页面的布局排版，在有限的页面面积内，承载更多内容，突出读者关注的内容，增强页面设计的视觉美感，成为不可回避的问题。例如，手机购物的UI设计，既要包含商品简介，又要包含用户意见反馈，还要包含实物照片，以及各个不同商场的标价等等。完美的页面设计，不仅要求简练而清晰，而且也不能遗漏相关内容，实在是一件困难的事情。可以说，手机购物之所以不普及，与手机购物的UI设计笨拙而丑陋是相关的。
要巧妙地设计手机应用的UI设计，终极而言，需要突破传统的单一鸟瞰视角的方式，Figure 2 就是这方面的尝试。Webkit能不能做到这一点？原理上是可以做到的，但是必须修改源代码。但是在改造以前，我们还是先踏踏实实研究一下，Webkit 的布局排版的内部机制是什么。只有充分了解对方之长，才有可能改进对方之短。
读解Webkit排版布局与绘制的具体实现以前，首先需要明确的是，Webkit把排版布局(layout)，与绘制(paint)，分开处理。
Layout负责确定Render Tree中，每个叶子和中间节点的位置。每个节点在屏幕上的显示，都呈长方形格局。所谓位置，指的是这个长方形左上角起始坐标(X,Y)，以及长方形的宽度和高度。每个中间节点的长方形，里面嵌套着若干小长方形，对应这个中间节点的后代节点等等。
在Layout过程结束以后，Webkit启动 Paint过程，负责把Render Tree中各个叶子节点，在相应的位置绘制出来。Webkit 把具体绘制的工作，交给第三方图形工具库(Graphics Library)去完成。常用的第三方图形工具库包括QT，GTK+，Wx，Skia，Cairo等等。
打个比方，图形工具库相当于活字，以及绘制图像的石板(lithography)，它们负责paint。而从严格意义上来说，Webkit的主要工作是layout，也就是排版布局，相当于版面模版。
关于图形库，台湾的开源高手，黄敬群(Jim Huang / jserv)，写过一篇介绍Google Skia 图形库的文章(http://blog.linux.org.tw/~jserv/archives/002095.html)。文中谈到，
Google 为了搭建Android平台，于2005年8月并购了Android公司。同年11月份，Google还收购了Skia公司。2007年11 月，Google发布Android，并公开部分源代码。当人们热衷于探究Android Dalvik VM的奥秘的时候，忽略了Skia的意义。
2008年9月，Google发布了以改良的Webkit为核心的Chrome PC浏览器。当人们热衷于探究V8 JavaScript引擎等等功能模块时，再次忽略了Skia的意义。
Skia是一个2D图形工具库，该产品的特色在于，能够在手机等等移动设备中，以较低的内存和CPU消耗，呈现高品质的2D图形。
Skia 的创办人，Michael Reed，是图形技术方面的顶尖人物。Michael早年任职于Apple，参与QuickDraw GX项目，处理字型和图像显示。后来他跳槽到OpenWave，开发手机浏览器。在OpenWave工作期间，与Benoit Schillings合作，在50-300KB的内存空间内，提供图层之间alpha blended方式的预览，以及全功能向量矩阵转换等等，真可谓螺丝壳里做道场。后来Benoit Schillings离开OpenWave，去Trolltech任职CTO。Trolltech的主打产品是大名鼎鼎的QT。再后来Trolltech 被Nokia并购，Benoit随之加入Nokia。Benoit Schillings离开OpenWave不久，Michael Reed也离开了OpenWave，去创建Skia公司。
外链图片需谨慎，可能会被源头改Figure 3. Layout implementation in Webkit
Courtesy http://www.flickr.com/photos/87209438%40N00/3609632247/sizes/l/
外链图片需谨慎，可能会被源头改Figure 4. Paint implementation in Webkit
Courtesy http://www.flickr.com/photos/87209438%40N00/3609632249/sizes/l/
Figure 3 和 Figure 4， 分别显示了Webkit执行排版布局(layout)，以及绘制(paint)的两个过程。仔细查看这两张sequence diagrams，会发现以下特点，
1. Layout 和 Paint 这两个过程完全分开。开始执行Paint过程以前，必然预先执行过Layout，否则图形库就不知道在哪里写字以及显示图像。但是这并不意味着，Layout执行结束后，随即就立刻执行Paint。实际上，Layout执行结束后，触发一个事件，这个事件启动Paint过程。但是Paint过程也可以被其它事件触发，譬如屏幕内容的切换，以及把隐藏的浏览器窗口复原等等。
2. Layout 涵盖了所有CSS规定的布局要素。包括页面边缘与内容之间的空白，文字对插入图像的避让(floating)，单列与多列，上下层覆盖(z-index)等等。
3. 图像，视频播放器插件，Applet等等，在 Layout 被称作 Replaced Render Object。这些 Replaced 元素的宽度和高度可以由CSS规定。如果CSS没有规定，就解析这些元素的数据流，譬如一个JPG照片的metadata里，规定了这幅照片原件的宽度和高度。如果元素自己也没有规定宽度高度，就使用Webkit提供的缺省值。
4. 文字的宽度根据页面的排版来确定。譬如一页中包含多列文字，则每列文字宽度相等。每列文字的宽度，乘以列数，加上列与列之间的夹缝，加上页面边缘空白等等，应当等于页面总的宽度。假设页面总的宽度已知，边缘空白，和列与列之间的夹缝的宽度也已知，就可以反推文字的宽度。
5. Render Tree中每个节点在屏幕上的显示，都呈长方形格局。前面第3点和第4点，描述了宽度的确定。而高度的确定，取决于这个中间节点的所有后代节点的高度的总和。对于 Replaced 元素来说，它的高度相对比较容易确定，而文字段落的高度，需要根据字数，字型，以及字体大小计算得出。
6. 在 Layout 过程中，反复出现以 Repaint 为开头的子过程，例如 repaintAfterLayoutIfNeeded()。这些子过程的意义在于，当确定了某个节点的高度和宽度以后，需要对其前辈节点，和左右兄弟节点的位置，做适当调整。严格意义上来讲，这不是repaint，而是relayout。
7. 相对于 Layout 过程，Paint 过程的逻辑要简单得多。Paint的过程，大致按照深度优先的顺序，遍历整棵RenderTree。也就是说，从最左边的叶子节点开始，从左向右逐个绘制 RenderTree所有可以显示的叶子节点。所谓“可以显示的叶子节点”，是因为CSS中可以规定，不显示某些叶子。
反复研究以上Layout和Paint的过程，我们有以下看法。
1. Layout 是一个计算量很繁重的过程。之所以繁重，主要体现在估算完每个RenderTree节点的宽度尤其是高度以后，需要相应调整这个节点的前辈节点以及左邻右舍兄弟节点的位置。对于文字段落而言，它的高度有赖于字数，字体和大小，所以估算不容易准确。
有没有可能把Layout 过程，与第一遍 Paint 过程合二为一？只要遍历一次RenderTree的所有叶子节点，绘制图像并码字。Paint过程结束后，各个叶子节点对应的长方形的起始位置的(X,Y)坐标，以及宽度和高度都自然迎刃而解。然后再由叶子节点开始，逐步确定RenderTree中，各个中间节点的起始位置和宽度高度。这样做的好处是，可以大大降低 Layout 过程的成本。
2. Layout 过程假设每个RenderTree 的节点都对应一个长方形屏幕区域。受限于这个规定，类似于Figure 2的效果，就显示不出来。有没有可能取消这个限制？SVG不仅提供了强大的绘图能力，而且也提供了强大的排版布局能力。能不能把CSS当着SVG格式的一个子集来看待？