《webkit入门准备》
1、 1. C++
a) Webkit代码风格
b)
c)
d)
e)
f)
2、 2.
a)
b)
c)
3、 3.
a)
b)
Inline Const 构造与析构 重载 继承 泛式编程 Vector/List/HashTable Iterator 智能指针 面向对象编程 对象概念 设计模式
4、 4. 调试、测试及工具
a) Gcc及Makefile
b) Trace
c) VC
d) Gdb
e) Alert及javascript调试
f) GUN binary工具
g) JsUnit
h) Javascript框架Dojo
i) JsDoc
j) JsLint
k) HTML Validator
l) Dom inspector
m) Xml spy
n) 标准测试用例
5、 5. 性能分析
a) Gprof
6、 6. Socket
7、 7. 编译原理
a) 词法
b) 语法
8、 8. 操作系统
a) Linux线程
b) Linux 内存
c) 编译与链接
9、 《体系结构详解》
1、 浏览器功能结构
2、 浏览器结构
3、 Webkit体系结构
4、 WebKit目录结构
5、 WebKit编译
10、 《HTML引擎详解》
1、 HTML语法
2、 Dom Core
3、 Dom Event
4、 Dom Html
5、 焦点处理
6、 HTML扩展
11、 《JS引擎详解》
1、 Javascript语法
2、 JS Binding
3、 JS Interpreter
4、 GarbageCollect
5、 javascript扩展
12、 《CSS排版详解》
1、 CSS语法
2、 Dom-CSS
3、 Dom-Style
4、 Paint
5、 CSS风格扩展
13、 《CURL、SSL详解》
1、 Loader
2、 Curl
3、 HTTP
4、 SSL
14、 《XML引擎详解》
1、 XML
2、 Ajax
15、 《TCMalloc内存管理机制》
1、 内存池
2、 TcMalloc
16、 《其它》
1、 WebKit外壳封装
2、 Plugin插件机制
Webkit 主要组成
WebKit 主要包括三个部分WebCore、JavascriptCore 及Ports部分。
WebKit 专注的核心部分主要是：
分析Html，Javascript的解析，布局渲染技术。
分别在WebCore/html，JavascriptCore 和WebCore/rendering里面
1 WebCore内容
目录结构
bindings
将Dom Binding 给JavascriptCore 方面的代码，同时包含依据idl 接口描述文件，自动生成对应于JavascriptCore 的Binding 实现的脚本等内容
bridge
主要包含NPPlugin方面的接口访问等内容
css
主要包括与css 方面相关的内容如解析、不同css 规则的定义与实现、css Binding 给JS的接口定义等内容；
dom
主要包括dom方面相关的内容如不同dom元素的定义与实现、dom Binding 给JS的接口定义等内容
html
关于html 方面相关的内容，如不同html 元素的定义与实现、HTMLTokenizer 及HTMLParser等内容
load
主要包括装载资源如html页面、css、js 及image等方面内容；
page
主要包括描述一个Web页面所涉及的内容如page、frame、frameview、frametree、setting、history、chrome、chromeclient等内容；
rendering
主要包括如何使用样式，组织布局、显示html 元素等方面内
plugins
主要包括浏览端如何实现NPPlugin 方面的内容
svg
主要包括与svg方面相关的内
xml
主要包括与xml 方面相关的内容如xml parser、XPath、XSLT等
platform
主要包括与不同平台或外部库相关的内容如graphics（图形输出方面）、network（网络处理方面）、image-decoders（解析不同图片格式方面）等
主要数据结构
为了更加简单有效的描述浏览网页的内容及过程，WebKit 为了明显区分不同方面的内容，采取了不同的namespace 如webcore、javascriptcore、webkit等，webcore 方面的主要数据结构有： webcore::page 、 webcore::frame 、
webcore::FrameLoader 、webcore::FrameView 、Document 、DOMWindow 、KJSProxy 、DocumentLoader 、ResourceHandle 、ResourceRequest 、ResouceResponse、MainResourceLoader、RenderObject、RenderView等
总的说来，WebCore 包含了浏览器引擎的核心部分如处理html、dom、css、svg、获取资源、渲染页面过程控制、回调/通知外壳程序以及与Javascript 实现的Binding等等
2 port的内容
Port 方面的主要内容在于提供不同的Port 接口供外部程序使用以及如何与外部程序交互，因为WebKit 中的其它两部分WebCore、 Javascript 实现，从逻辑上讲是不直接提供接口给外部程序使用的。同时为了完成浏览器的核心功能，WebKit 也需要从外部程序中通过Port 接口的方式获取一些支持。
1 WebCore 交互接口
在 WebKit源代码目录结构中WebKit目录下分别包含gtk、mac、qt、win、wx 目录，其分别对应不同的Port 移植方式，在每一个目录下面都包括WebCoreSupport 目录，而在不同的WebCoreSupport目录下分别包含有对类接口
WebCore::ChromeClient 、WebCore::ContextMenuClient 、WebCore::DragClient 、WebCore::EditorClient 、WebCore::FrameLoaderClient 、WebCore::InspectorClient 等的实现，它们代表外部程序提供给WebKit 内部使用的接口实现，其中WebCore::ChromeClient、WebCore::FrameLoaderClient非常重要。
2 连接模块 loader
对WebCore 中的page/loader 等方面的类提供对应Port 的实现支持如
EventHandlerWin.cpp 、FrameLoaderWin.cpp 、DocumentLoaderWin.cpp、DocumentLoaderWin.cpp、WidgetWin.cpp、KeyEventWin.cpp等。 Loader 是在WebKit 里面一个很重要的连接器，通过loader 发起IO下载网页，再通过loader发起解析，已经最后的渲染功能。
3 显示模块WebView和WebFrame
WebView 及WebFrame 主要功能是方便外部程序嵌入WebKit不同的Port 移植对WebView 及WebFrame的定义及实现有所不同，但其与WebCore中的Page、Frame 之间的关系图描述相一致。
4 chrome中对Port移植方面的实现
其基本上与其他Port 移植类似，其主要代码在webkitglue 目录中， 可重点关注带client_ 后缀的文件、webview_、webwidget_ 等。但是其究竟如何创建原生windows 窗口、如何创建Render 进程、 Render 进程与创建
的原生windows 窗口的关系如何等需要更进一步深入研究Chrome，如果能从上面提到的Port部分入手也许很快就可得到答案。
5 Android中对Port移植方面的实现
其实现有点特殊，由 于Andriod 将WebKit 以一个Java 类接口的方式提供给Java 环境使用（不像上面提到的Chrome、Safari 等都是将WebKit 以 一个C++动态或静态库的方式供C/C++外部程序调用），这样WebKit 内部与外部即JavaVM 的交互（如上面提到的ChromeClient、FrameLoaderClient 接口实现）需要一个Bridge 类来协调处理，同时WebView、WebFrame 接口绑定给JavaVM 的jni 接口实现也需要通过这个Bridge 来支持协调处理。具体可详细参考android源码代码中WebCoreplatformandroid目录下的源文件。
WebKit gtk+学习文档
简介 WebKit 是一个开源浏览器网页排版引擎，与之相应的引擎有Gecko（Mozilla，Firefox 等使用的排版引擎）和Trident（也称为MSHTML，IE 使用的排版引擎）。同时WebKit 也是苹果Mac OS X 系统引擎框架版本的名称，主要用于Safari，Dashboard，Mail 和其他一些Mac OS X 程序。WebKit 所包含的 WebCore 排版引擎和 JSCore 引擎来自于 KDE 的 KHTML 和 KJS开源项目，当年苹果比较了 Gecko 和 KHTML 后，仍然选择了后者，就因为它拥有清晰的源码结构、极快的渲染速度。
目前使用WebKit 引擎的浏览器主要有：Safari（apple出品），Midori，chrome（google出品）等。
Adobe AIR也采用了WebKit渲染HTML。
一、用到的库：
除了平台相关的库， WebKit 需要用到的一些主要的后台库有：
ICU ： International Components for Unicode ， 一个成熟，广泛使用的一套为 C / C + + 和 Java 库提供 Unicode 的 全球化支持软件；
XSLT ： eXtensible Stylesheet Language Transformation, W3C 定义的用于 XML 文档转换的规范； Curl ： 一个利用 URL 语法的命令行数据传输工具，基于 libcurl 。
Sqlite ： SQLite 是实现了 SQL92 标准的 SQL 数据库引擎，它能在一个库里组合数据库引擎和接口 ， 将所有数据存储于单个文件 ；
Gperf ：一个很完美的哈希函数生成器； Flex ： Fast Lex, 快速词法分析生成器； Bison ：语法分析生成器，可以将一段带注释的上下文无关语法转化成 LALR 或 GLR 语法； Enchant ：一个拼写检查库，提供单词的拼写检查、纠错等功能；
二、 代码目录结构
WebKitTools：一些测试 WebKit 实现功能的程序； WebKit：此目录位于 WebKit 的最上层，定义了与应用相关的一些接口，因此它是平台相关的，子目录是对应平台的完整实现：
WebCore： WebKit 的核心部分，定义了浏览相关的数据 IO 、页面加载、脚本分析、 UI xml：提供 xml 相关的内容； 组织、事件处理、网络分析、平台相关的具体实现等内容。
html：提供 html 相关的内容；其下的 Canvas 目录定义了 3D 画布以及 WebGL 库相关的内容；
wml: Wireless Markup Language ； css：提供 css 相关的内容； dom：提供 dom 相关的内容； editing：编辑相关的功能； page：浏览相关内容，并非是我们看到的一个页面，在一次浏览会话中，它只有一个实例； rendering：页面渲染相关的内容，在对页面脚本进行 DOM 树分析之后，需要对这些元素进行渲染和显示；
notification：内部模块间的事件通信； history：页面浏览历史记录相关的内容； svg：矢量图形功能，有选项， --svg ；
mathml： W3C 为网页中的数学表达式制定的规范；有编译选项， --mathml ； loader加载资源及 Cache ； ：
workers：“ Web Workers 为 WEB 前端网页上的脚本提供了一种能在后台进程中运行的方法。一旦它被创建， Web Workers 就可以通过 postMessage（) 向任务池发送任务请求，执行完之后再通过 postMessage(） 返回消息给创建者指定的事件处理 程序 （ 通过 onmessage 进行捕获 ） 。
Web Workers 进程能够在不影响用户界面的情况下处理任务，并且，它还可以使用 XMLHttpRequest 来处理 I/O ，无论 responseXML 和 channel 属性是否为 null 。”
storage ： Web Storage 相关的内容，保存页面的数据，可以看成是 Cookie 的升级； websockets ：与网络连接相关的内容； bridge: 主要包含 NPPlugin(Netscape Plugin) 方面的接口访问等内容； binding ： Dom 与 JavaScriptCore 绑定的功能；
accessibility ：提供控件的可用性相关的内容， accessibility 常用来形容对一些特殊人群的功能支持，比如残障者、老人等；
icu ：里面放了专门为 Mac OS X 10.4 编译的 icu 相关头文件 ； platform ：提供了平台相关的具体实现，如事件响应、本地化、网络连接等； plugins ：插件相关内容； ForwardingHeaders ：头文件；
inspector ： Inspector 是 WebKit 提供的查看网页源代码， DOM 树，以及调试脚本的工具，本目录包含了实现此功能的内容；
English.lproj ：本地化文件； Resources ：资源，图标；
WebCore.gyp ：工程文件。 GYP （ Generate Youre Project ）是 google 自己开发了一个脚本工具，这个工具也 是采用 python 编写的。它采用了自定义的一套规则，用于生成各种工程文件；
JavaScriptGlue JavaScriptCore ：有关 JavaScript 的相关内容，包括了脚本解释器、分析器以及执行程序； PlanetWebkit: 一个比较灵活的 RSS 阅读器； Webkit 网站上的 Planet ：一站式的 Webkit 开发与动态信息；
三、体系结构
WebKit 主要包括三部分： WebKit ， WebCore ，以及 JavaScriptCore ，加上所使用的库，依托的平台，其基本的体系结构 (Architecture) 如下所示：
注意有的模块相对于下面的模块有突出，这是因为此模块与下面几个模块直接相关，比如 WebCore 模块就与JavaScriptCore 、 Libraries 和 Platforms 模块直接相关。
四、Webkit/gtk +中下层与gtk的接口
WebKit中实现网页上所有信息的显示一部分是由WebKit本身画出来的，一部分是利用gtk的接口实现部分对象的显示，其中本身画出来的部分的代码实现部分主要位于editing和rendering两个目录下，利用gtk【WWW.BAIHUAWEN.】提供的一些控件的接口实现网页上一些对象的显示主要集中于platform/gtk/目录下：
。/platform/gtk/RenderThemeGtk.cpp
。/platform/gtk/ContextMenuGtk.cpp
。/platform/gtk/FileChooserGtk.cpp
。/platform/gtk/WidgetGtk.cpp
。/platform/gtk/Language.cpp
。/platform/gtk/PasteboardGtk.cpp
。/platform/gtk/CursorGtk.cpp
。/platform/gtk/ContextMenuItemGtk.cpp
。/platform/gtk/ScrollbarGtk.cpp
。/platform/gtk/LocalizedStringsGtk.cpp
。/platform/gtk/DragImageGtk.cpp
。/platform/gtk/PlatformScreenGtk.cpp
。/platform/gtk/PopupMenuGtk.cpp
。/platform/gtk/PasteboardHelper.cpp
。/platform/gtk/GRefPtrGtk.cpp
。/platform/gtk/ScrollbarThemeGtk.cpp
。/platform/gtk/ScrollViewGtk.cpp
。/platform/gtk/ClipboardGtk.cpp
。/platform/gtk/GtkPluginWidget.cpp
。/platform/network/soup/ResourceHandleSoup.cpp
。/platform/graphics/gtk/IconGtk.cpp
。/platform/graphics/gtk/FontPlatformDataPango.cpp
。/platform/graphics/gtk/ImageGtk.cpp
。/platform/graphics/cairo/FontPlatformDataCairo.cpp
。/plugins/gtk/PluginViewGtk.cpp
1、
各个文件实现的功能 RenderThemeGtk.cpp
该文件主要实现了对一些基本控件的创建与属性的设置，例如：button,Toggle,Checkbox,RadioMenuList,Text,Background,Foreground,ListBox,Container,Entry,TreeView,MediaSlider等
ContextMenuGtk.cpp 该文件主要是对文本菜单(ContextMenu)的创建 FileChooserGtk.cpp 该文件中包含两个函数： static bool stringByAdoptingFileSystemRepresentation(gchar* systemFilename, String& result)； 该函数是得到systemFilename中所包含的文件的名称，通过result值返回
String FileChooser::basenameForWidth(const Font& font, int width) const;
通过给定文本的字形名称，和一定的宽度，从而得到该长度下可以显示最长文本信息 WidgetGtk.cpp
该文件主要是对widget的一些属性的设置，例如：光标、焦点、显示，隐藏，还有对widget自身的新建与销毁等等
Language.cpp
该文件仅包含一个函数：
String defaultLanguage()；
该函数实现返回当前默认的语言类型
PasteboardGtk.cpp
该文件主要是对剪贴板的操作，文件中所包含的函数主要有：
static void clipboard_get_contents_cb(GtkClipboard *clipboard, GtkSelectionData *selection_data, guint info, gpointer data)；
得到指定剪贴板当前的内容
static void clipboard_clear_contents_cb(GtkClipboard *clipboard, gpointer data)；
清空指定剪贴板中当前的内容
Pasteboard* Pasteboard::generalPasteboard()；
创建一新的剪贴板
void Pasteboard::writeSelection(Range* selectedRange, bool canSmartCopyOrDelete, Frame* frame)；
存储所选内容至剪贴板中
void Pasteboard::writePlainText(const String& text)；
保存纯文本至剪贴板中
void Pasteboard::writeURL(const KURL& url, const String&， Frame* frame)；
保存URL至剪贴板中
void Pasteboard::writeImage（Node* node, const KURL&， const String&）；
保存图片文件至剪贴板中
void Pasteboard::clear()；
清除默认剪贴板中的'内容
PassRefPtr
//欠缺
String Pasteboard::plainText(Frame* frame)；
返回当前剪贴板中的纯文本内容
CursorGtk.cpp
该文件主要实现了对各种不同光标类型的的创建
ContextMenuItemGtk.cpp
该文件主要实现了对文本菜单的一些操作，例如：
static const char* gtkStockIDFromContextMenuAction(const ContextMenuAction& action)； 根据所操作的对象得到它所对应的stockID
GtkMenuItem* ContextMenuItem::createNativeMenuItem(const PlatformMenuItemDescription& menu)；
创建菜单项
void ContextMenuItem::setSubMenu(ContextMenu* menu)；
webkit用例审核及处理方法
1、 前言
Webkit官方用例大约有3万，现已通过自动化方式将一半的用例添加进入日常的LayoutTests测试集中。还有一般需要人工地过滤，看不过的原因是什么。
2、 用例类型说明及举例
按照测试用例给出的预期结果类型，可以将用例分为：文本型（TextResult）、图片型（PixelResult）、Render树型（RenderTreeResult）、HTML型（工具暂不支持）、其他特殊类型（例如，预期是音频、pdf文件的用例，暂不支持）。
文本型：测试结果标注为TextResult，预期文件为-expected.txt，内容是：该用例使用浏览器打开后显示的文字信息，如果有图片，也不会出现在txt文件里的。用例源码js有testRunner.dumpAsText（)或testRunner.dumpAsText(false）调用。例如：
图片型：测试结果标注为PixelResult，预期文件为-expected.png：该用例使用浏览器打开完全后的截屏文件。用例源码js有testRunner.dumpAsText(true)调用。
Render树型：测试结果标注为RenderTreeResult，预期文件一般会给出-expected.txt和-expected.png，目前只做txt的对比，效率较高。txt内容是该用例使用浏览器排版之后的RenderTree结构。用例源码js没有调用testRunner.dumpAsText()这样的方法（目前还没出错，不知道其他不通过的用例会不会存在误判）。例如：
Html型：暂时不支持测试，给出的预期文件是-expected.html，主要是根据预期文件类型来判断。
其他类型：用例给出的预期文件是txt、png、html以外的其他类型，比如-expected.pdf，-expected.audio等。主要是根据预期文件类型判断，这些特殊用例不支持测试。
更详细的介绍说明见附件《LayoutTests测试用例编写。docx》
3、 不通过用例处理方法和归类
3.1处理方法
对于目前还未通过测试的15k用例建立excel表格记录分析处理结果。表格设计如下：
测试同学目前需要做的工作：根据该文档的说明，逐一分析未通过用例，将分析的结果填入表格。
开发同学根据表格信息快速定位，进一步分析根本原因，或者修改用例或者查内核缺陷。优先级高的问题已注明提tapd，开发优先解决这些问题。个别内核缺陷会转给项目组其他相关开发同学跟进。
3.2归类
对不通过的用例结果和基准对比，分析原因归类，分为：
1、（用例在）目录测试时crash：测试该用例目录时，该用例必现crash，但是单独测试该用例时并不会crash，原因应该和前后用例行为有关，需要整个目录测试复现问题解决。处理方法：提tapd bug。
2、内核crash：用例使用浏览器打开过程必然crash。处理方法：提tapd bug。
3、工具crash：用例不会在浏览器打开过程crash，但是单独测试时比如crash。处理方法：提tapd bug。
4、（测试用例）内核不支持：测试用例调用了某些js方法，需要内核专门支持测试而增加的，目前X5内核还不能支持。处理方法：将分析的原因填入对应的excel表格，调用的特殊js对象描述清楚，方便后期确定是否实现支持。
5、（测试用例）工具不支持：测试用例中，testRunner调用了某些js方法并未实现，例如testRunner.display()。处理方法：将分析的原因填入对应的excel表格，调用的特殊方法描述清楚，方便后期继续跟进。
6、（测试工具）类型判断错误：工具判断出来的用例类型和用例给出的基准文件判断的类型不一致。处理方法：将原因填入对应的excel表格。
7、内核缺陷：工具和内核对用例测试完全支持，测试结果和预期存在差异，判定为内核逻辑缺陷。处理方法：将原因填入对应excel表格。
8、html型用例：用例给出的预期文件是expected.html，工具暂不支持测试。处理方法：将原因填入对应excel表格。
9、其他类型用例：用例给出的预期文件类型不是txt、png、html（htm）之一的，工具暂不支持。处理方法：将原因填入对应excel表格。
10、其他原因：不能归入前9类的另类原因。
4、 审核步骤、归类及处理方法
注： 所有提tapd的bug请标题注明 LayoutTests，处理人leolincao、totorima
首先，打开目录对应的Details.html文件，逐一审核未通过的用例。
4.1 分析Crash用例
Details.html文件中，注明是CrashedDummyResult，该用例测试过程crash。
1、单独测试该用例是否crash，如果没有crash，归类为：目录测试时crash。
2、使用浏览器打开该用例，如果crash，归类为：内核crash，提tapd；否则归类为：工具crash，提tapd。
4.2 分析Timeout用例
Details.html文件中，用例后面有黄色底色的TIMED OUT标识用例。
TIMED OUT用例大多数原因是用例调用的部分js对象方法不支持，导致js执行中止；js执行了testRunner.waitUntilDone （)，但testRunner.waitUntilDone(）未能执行。
1、查看用例源码，包括html和js资源文件。
2、阅读主要的js代码，是否存在特殊的js对象调用。
如果存在window调用了未知的js对象（testRunner例外），归类为：内核不支持。记录下window调用的未知js对象名称。
如果存在testRunner调用js方法，除了一下这些方法外，还存在其他方法，归类为：工具不支持。记录下testRunner调用的未知js对象名称。testRunner支持的方法有：clearAllDatabases（)、dumpAsText（）（包括带参和不带参）、dumpChildFramesAsText（）、dumpDatabaseCallbacks（）、notifyDone（） 、overridePreference（）、setAppCacheMaximumSize（）、setCanOpenWindows（）、setDatabaseQuota（） 、setXssAuditorEnabled（）、waitUntilDone(）。
3、还不能确定的归类为：其他原因。
4.3预期文件找不到
Details.html文件中，如果测试结果Expected result栏为空（图片类型用例PixelResult例外），可以判断为预期文件找不到，先到platform/mac或者platform/win目录（优先选择mac目录）结合用例相对路径寻找对应expected文件（例如：fast/1.html的预期结果可能会在platform/mac/fast/或者platform/win/fast/下面），复制到用例所在目录。然后重新测试，如果测试通过，将用例加入DB测试集，否则根据测试结果重新判断归类。（图片用例的判断有专门章节继续说明）
预期找不到用例：
4.4类型判断不准确
Details.html文件中，根据给出的预期结果判断该用例测试类型（TextResult、RenderTreeResult、PixelResult），或者在用例路径找到对应的expected文件，判断用例类型，如果根据预期结果判断的类型和测试结果给出的测试类型不一致，归类为：类型判断错误。
根据前面的规则判断之后，其他的未通过用例按照类型详细说明：
4.5图片类型用例
Details.html文件中，被表示为PixelResult的用例。
1、在用例所在目录寻找对应的expected文件。
2、如果不存在对应的expected文件，按照“预期文件找不到”章节处理方法处理，判断结束。
3、根据预期文件判断是否工具类型判断错误，若是，归类为：类型判断错误。
4、人工对比预期图片和测试生成的-actual.img，如果人工判断一致，将生成的-actual.img代替预期图片，加入DB测试集；否则，归类为：内核缺陷。
4.6 RenderTree类型用例
Details.html文件中，被表示为RenderTreeResult的用例。
1、从Details.html对比分析生成的txt差异，如果整个文档RenderTree结构一样，个别元素差异一两个像素，可以通过浏览器打开该用例查看显示同chrome uc等浏览器打开页面的显示对比，如果一样，可以使用生成的-actual.txt代替基准提交到DB测试集。
2、如果Details.html中对比文档的RenderTree结构存在差异，则归类为：内核缺陷。
4.7文本类型用例
Details.html文件中，被表示为TextResult的用例。
1、从Details.html对比分析生成的txt差异，如果对比差异仅仅是个别字段值不一致，归类为：内核缺陷。
2、如果-actual.txt结果和预期结果相比缺少很多行内容，查看用例源码，包括html和js资源文件。
3、阅读主要的js代码，是否存在特殊的js对象调用。
如果存在window调用了未知的js对象（testRunner例外），归类为：内核不支持。记录下window调用的未知js对象名称。
如果存在testRunner调用js方法，除了一下这些方法外，还存在其他方法，归类为：工具不支持。记录下testRunner调用的未知js对象名称。testRunner支持的方法有：clearAllDatabases（)、dumpAsText（）（包括带参和不带参）、dumpChildFramesAsText（）、dumpDatabaseCallbacks（）、notifyDone（） 、overridePreference（）、setAppCacheMaximumSize（）、setCanOpenWindows（）、setDatabaseQuota（） 、setXssAuditorEnabled（）、waitUntilDone(）。
4、还不能确定的归类为：其他原因。
4.8 html类型用例
根据预期文件判断用例是html类型用例，归类为：html型用例工具不支持。该类型用例后期需要支持。
由于工作需要，最近在准备一个介绍webkit的PPT文档， 我个人断断续续学习webkit的代码也有一年多了，其间也阅读了网上的一些webkit相关技术文章，但中文的资料很少，大部分都是english的，有些E文资料还需要翻墙。平常由于自已记性不好，去年看过的一些模块今年再去翻时，竟然没一点印象了，悲剧？?
所以，借此机会，把自已对webkit的理解先做下笔记，以便于以后需要时可以方便查阅。 需要说明的是，笔记记录的有我个人的理解，也有网上摘录的片段和图片，不一定正确，也会比较凌乱，希望看到的朋友及时指正，共同进步。
一．
Webkit的由来
1． 十几年前的故事
1994年，Netscape浏览器曾占据整个浏览器市场的90%，风头无二（也很嚣张）。但随着微软推出win95后，把IE 1.0做为win95的插件发布，开始挑战Netscape的霸主地位，到发布IE 4.x，短短三年时间，打败Netscape。 这里面虽然说有与windows集成的原因，但从本身的功能上来讲， IE从速度和对标准的支持上来讲，已真正打败了Netscape。
此阶段的浏览器可称为第一代浏览器。它的主要特点是单窗口型式。竞争的最主要是访问速度、兼容性。原因：90年代都大多是用modem拨号上网，56K/S。
2．Webkit出生
Apple公司在它的Mac OS X里，集成了基于KHTML 改进型的 WebKit 引擎的浏览器，命名为：Safari，当年苹果比较了 Gecko 和 KHTML 后，之所以选择了后者，就因为它拥有清晰的源码结构、极快的渲染速度。（KHTML是由KDE 小组开发的）
随后， apple将它开源。
至此，第二代浏览器，基本上是三分天下：
Trident: IE系列， 以Trident 作为内核引擎；
Gecko: Firefox 是基于 Gecko 开发；
WebKit: Safari, Google Chrome, 搜狗双核浏览器（集成IE和chrome）， QQ浏览器5。
WebKit 内核在手机上的应用也十分广泛，例如 Google 的手机 Gphone、 Apple 的 iPhone, Nokia’s Series 60 browser 等所使用的 Browser 内核引擎，都是基于 WebKit。
总结：
webkit是什么？
答：Webkit是一套浏览器排版代码， 已开源，主要由apple公司在维护。强调： webkit仅仅是一套排版引擎，
举个例子说明下：
google的chrome是一个浏览器对吧， 那chrome主要包含以下模块： 外壳UI（多标签，菜单，状态栏，网址输入栏等），读取网络数据的模块，排版解析模块，JS解析引擎。 外壳UI是google自已写的，js引擎是google写的V8, 读取网络数据模块用的winhttp，只有排版引擎用的webkit。
不知道我说清楚了没，呵呵。
WebKit is an open source Web content engine for browsers and other applications. We value real-world web compatibility, standards compliance, stability, performance, security, portability, usability, and relative ease of understanding and modifying the code (hackability)。
二． Webkit编译环境
Webkit的官网：/retype/zoom/5b3f590ceff9aef8941e0617?pn=4&x=0&y=0&raww=626&rawh=719&o=png_6_0_0_135_113_704_808_892.979_1262.879&type=pic&aimh=551.3099041533546&md5sum=a27dea88b29041c789cb0213818b8bbc&sign=171bf19a9b&zoom=&png=87947-148147&jpg=0-0" target="_blank">点此查看
编译运行。在Visual Studio中设置browser工程为主工程，然后编译。可以顺利编译完成，下面是运行后的效果图。
4、 最最简单的webkit学习环境-ISee
5、 Isee是一位中国人移植的webkit， 在winxp下用vs2008直接编译即可调试，用于学习
最好，强烈支持，也是一位同事推荐给我的，后面的代码走读主要基于该环境。
6、 Isee还可以直接移植到wince平台运行噢。
7、 官网：
备注：原作者已经不再维护了。所以webkit内核的版本号有点老。
8、 webkit在vs2008中编译
见 :
三． Webkit整体介绍
1、 Webkit的结构图（以ISee架构举例）：