作者：李东博

出版社：清华大学出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

HTML5+CSS3从入门到精通试读：

内容简介

本书内容翔实、结构清晰、循序渐进，基础知识与案例实战紧密结合，既可作为HTML5+CSS3初学者的入门教材，也适合作为中高级用户对新技术作进一步学习的参考用书。本书显著特色有：

1. 同步视频讲解，让学习更为直观高效。17小时大型高清同步视频讲解，先看视频再学习效率更高。

2. 海量精彩实例，用实例学更轻松快捷。225个精彩实例，模仿练习是最快捷的学习方式。

3. 精选实战案例，为高薪就业牵线搭桥。31个实战案例展示可为以后就业积累经验。

4. 完整学习套餐，为读者提供贴心服务。实例源程序、答疑服务等，让读者学习更加方便。

5. 讲解通俗翔实，看得懂学得会才是硬道理。

前言Preface

互联网技术日新月异。2011年以前，HTML5和CSS3看起来还遥不可及，如今很多公司都已经开始运用这些技术了，Chrome、Safari、Firefox和Opera等主流浏览器已经开始逐步实现对它们的支持。从前端开发技术看，互联网发展经历了三个阶段：第一阶段是Web 1.0的以内容为主的网络，主流技术是HTML和CSS；第二阶段是Web 2.0的Ajax应用，热门技术是JavaScript/DOM/异步数据请求；第三阶段是即将迎来的HTML5+CSS3技术，这两者相辅相成，使互联网又进入了一个崭新的时代。

HTML5+CSS3奠定了打造下一代Web应用的基础，这两项技术可以让网站更易开发、更易维护、更具用户友好性。HTML5被设计为跨平台的技术，只需要一个所有主流操作系统上都有的免费现代浏览器。最新版本的Apple Safari、Google Chrome、Mozilla Firefox、Opera以及Microsoft Internet Explorer都支持HTML5的许多特性。在iPhone、iPad及Android移动设备上预装的浏览器也都对HTML5提供了极好的支持。

本书系统地讲解了HTML5和CSS3的基础理论和实际运用技术，通过大量实例对HTML5和CSS3进行深入浅出的分析，着重讲解如何用HTML5+CSS3进行Web应用和网页布局。全书注重实际操作，使读者在学习技术的同时，掌握Web开发和设计的精髓，提高综合应用的能力。本书特色● 系统的基础知识

本书系统地讲解了HTML5+CSS3技术在网页设计中各种应用的知识，从为什么要用HTML5开始讲解，循序渐进，配合大量实例帮助读者奠定坚实的理论基础，做到知其所以然。● 大量的案例实战

本书设置大量应用实例，重点强调具体技术的灵活应用，并且全书结合了作者长期的网页设计制作和教学经验，使读者真正做到学以致用。● 深入解剖HTML5+CSS3应用开发和布局

本书用相当多的篇幅重点介绍了用HTML5+CSS3进行应用开发和布局的方法和技巧，配合经典的布局案例，帮助读者掌握HTML5+CSS3最核心的应用技术。● 精选综合实例

本书每章都会精选多个常见Web开发和设计的综合实例，帮助读者总结前面所学知识，综合应用各种技术、方法和技巧，提高读者综合应用的能力。本书内容

本书分为两大部分，共19章，具体结构划分如下。

第一部分：HTML5部分，包括第1章~第10章。这部分主要介绍了HTML5相关基础知识，包括HTML5概述、Web开发历史、HTML5文档结构异同与创建HTML5文档、设计HTML5表单、使用HTML5绘画、HTML5音频与视频、如何实现Web本地存储、如何实现Web离线应用、如何设计多线程应用、如何实现移动互联网中地图定位等技术。

第二部分：CSS3部分，包括第11章~第19章。这部分主要讲解了CSS3的新特性和新用法，以实现在简单的代码中能够设计更加精彩的网页效果。主要内容包括CSS3概述，CSS选择器，定义文本、字体与颜色，设计背景和边框，使用2D变形，设计动画，设计多列和流动网页布局，优化用户界面以及CSS3的其他新特性。本书读者● 希望系统学习网页设计、网站制作的初学者、进阶者● 从事网页设计制作和网站建设的专业人士● 各大中专院校相关专业的老师、学生● 相关培训机构的学员本书约定

本书主要面向熟悉HTML和CSS的Web开发人员。初学者也可以从本书获益，读者还应该具备基本的HTML、CSS、JavaScript知识，我们会用这些知识来创建各种应用方案。

本书中上机练习的示例要用到Firefox、Chrome和Opera浏览器，因此，为了测试所有内容，读者需要安装上述所有类型的最新版本浏览器，因为各种浏览器的实现都稍有差异。

读者还需要安装Internet Explorer来测试自己的站点，以便确保示例的兼容性。如需针对不同版本的Internet Explorer测试示例，可以下载IE Tester Windows版，因为它可同时支持IE6、IE7和IE8。对于非Windows用户，可以考虑使用VirtualBox或者VMware等虚拟机，或者使用CrossBrowserTesting和MogoTest等服务。

为了给读者提供更多的学习资源，同时弥补本书篇幅有限的遗憾，本书提供了很多参考链接，许多本书中无法详细介绍的问题都可以通过这些链接找到答案。因为这些链接地址会因时间而有所变动或调整，所以在此说明，这些链接地址仅供参考，无法保证这些地址都是长期有效的。

本书所列的插图可能会与读者实际环境中的操作界面有所差别，这可能是由于操作系统平台、浏览器版本等不同而引起的，在此特别说明，读者应该以实际情况为准。

为了帮助读者快速上手，在一般情况下，读者可以在程序和文档中自由使用本书中的示例代码。关于我们

参与本书编写的人员包括咸建勋、奚晶、文菁、李静、钟世礼、李增辉、甘桂萍、刘燕、杨凡、李爱芝、余乐、孙宝良、余洪萍、谭贞军、孙爱荣、何子夜、赵美青、牛金鑫、孙玉静、左超红、蒋学军、邓才兵、袁江和李东博等。由于作者水平有限，书中疏漏和不足之处在所难免，欢迎读者朋友不吝赐教。广大读者如有好的建议、意见，或在学习本书时遇到疑难问题，可以联系我们，我们会尽快为您解答，服务邮箱为：design1993@163.com, liulm75@163.com。编者第1章　Web开发新时代

从2010年开始，HTML5和CSS3就一直是互联网技术中最受关注的两个话题。2010年MIX 10大会上微软的工程师在介绍IE9时，从前端技术的角度把互联网的发展分为3个阶段：第一阶段是以Web 1.0为主的网络阶段，前端主流技术是HTML和CSS；第二阶段是Web 2.0的Ajax应用阶段，热门技术是JavaScript/DOM/异步数据请求；第三阶段是即将迎来的HTML5+CSS3阶段，这两者相辅相成，使互联网又进入了一个崭新的时代。本章将重点介绍HTML5语言基础，为将来系统地学习HTML5+CSS3编程奠定扎实的基础。1.1　HTML5概述

2004年成立的Web超文本应用技术工作组（WHATWG）创立了HTML5规范，同时开始专门针对Web应用开发新的功能。2006年，W3C介入HTML5的开发，并于2008年发布了HTML5的工作草案。2009年，W3C停止了对XHTML2的更新。2010年HTML5开始用于解决实际问题。这时各大浏览器厂商开始对旗下产品进行升级以支持HTML5的新功能，因此，HTML5规范也得到了持续性的完善。1.1.1　HTML5新特性

HTML5是基于各种全新的理念进行设计的，这些设计理念体现了对Web应用的可能性和可行性的新认识，下面简单介绍HTML5语言的特征和优势，以便提高读者自学HTML5的动力，明确学习目标。

1. 兼容性

考虑到互联网上HTML文档已经存在二十多年了，因此支持所有现存HTML文档是非常重要的。HTML5不是颠覆性的革新，它的核心理念就是要保持与过去技术的兼容和过渡。一旦浏览器不支持HTML5的某项功能，针对该功能的备选行为就会悄悄运行。

2. 合理性

HTML5新增加的元素都是对现有网页和用户习惯进行跟踪、分析和概括而推出的。例如，Google分析了上百万的页面，从中分析出了DIV标签的通用ID名称，并且发现其重复量很大，如很多开发人员使用

3. 效率

HTML5规范是基于用户优先准则编写的，其宗旨是用户即上帝，这意味着在遇到无法解决的冲突时，规范会把用户放到第一位，其次是页面作者，再次是实现者（或浏览器），接着是规范制定者（W3C/WHATWG），最后才考虑理论的纯粹性。因此，HTML5的绝大部分是实用的，只是在有些情况下还不够完美。例如，下面的几种代码写法在HTML5中都能被识别。id="prohtml5"id=prohtml5ID="prohtml5"

当然，上面几种写法比较混乱，不够严谨，但是从用户开发角度考虑，用户不在乎代码怎么写，根据个人习惯书写反而提高了代码编写效率。当然，我们并不提倡初学者一开始写代码就这样随意、不严谨。

4. 安全性

为保证安全性，HTML5规范中引入了一种新的基于来源的安全模型，该模型不仅易用，而且各种不同的API都可通用。这个安全模型可以不需要借助于任何所谓聪明、有创意却不安全的hack就能跨域进行安全对话。

5. 分离

在清晰分离表现与内容方面，HTML5迈出了很大一步。HTML5在所有可能的地方都努力进行了分离，包括HTML和CSS。实际上，HTML5规范已经不支持老版本HTML的大部分表现功能了。

6. 简化

HTML5要的就是简单，避免不必要的复杂性。为了尽可能简化，HTML5做了以下改进：● 以浏览器原生能力替代复杂的JavaScript代码。● 简化的DOCTYPE。● 简化的字符集声明。● 简单而强大的HTML5 API。

7. 通用性

通用访问的原则可以分成3个概念。● 可访问性：出于对残障用户的考虑，HTML5与WAI（Web可访问

性倡议）和ARIA（可访问的富Internet应用）做到了紧密结合，

WAI-ARIA中以屏幕阅读器为基础的元素已经被添加到HTML中。● 媒体中立：如果可能的话，HTML5的功能在所有不同的设备和

平台上应该都能正常运行。● 支持所有语种：如新的元素支持在东亚页面排版中会用到

的Ruby注释。

8. 无插件

在传统Web应用中，很多功能只能通过插件或者复杂的hack来实现，但在HTML5中提供了对这些功能的原生支持。插件的方式存在很多问题：● 插件安装可能失败。● 插件可以被禁用或屏蔽（如Flash插件）。● 插件自身会成为被攻击的对象。● 插件不容易与HTML文档的其他部分集成，因为存在插件边界、

剪裁和透明度问题。

以HTML5中的canvas元素为例，以前在HTML4的页面中较难画出对角线，而有了canvas元素就可以很轻易地实现了。基于HTML5的各类API的优秀设计，可以轻松地对它们进行组合应用。例如，从video元素中抓取的帧可以显示在canvas中，用户单击canvas即可播放这帧对应的视频文件。1.1.2　HTML5组织

HTML5开发主要由下面3个组织负责和实施。● WHATWG：由来自Apple、Mozilla、Google和Opera等浏览器厂

商的人员组成，成立于2004年。WHATWG开发HTML和Web应

用API，同时为各浏览器厂商以及其他有意向的组织提供开放式

合作。● W3C：W3C下辖的HTML工作组，目前负责发布HTML5规范。● IETF（因特网工程任务组）：这个任务组下辖HTTP等，是负责

开发Internet协议的团队。HTML5定义的一种新API（WebSocket

API）所依赖的WebSocket协议，正由IETF工作组负责开发。1.1.3　HTML5构成

HTML5主要包括下面这些功能。● Canvas（2D和3D）● Channel消息传送● Cross-document消息传送● Geolocation● MathML● Microdata● Server-Sent Events● Scalable Vector Graphics（SVG）● WebSocket API及协议● Web Origin Concept● Web Storage● Web SQL database● Web Workers● XMLHttpRequest Level 2

HTML5发展的速度非常快，因此不用担心浏览器的支持问题。读者可以访问www.caniuse.com，该网站按照浏览器的版本提供了详尽的HTML5的功能支持情况。如果通过浏览器访问www.html5test.com，该网站会直接显示用户浏览器对HTML5规范的支持情况。另外，还可以使用Modernizr（JavaScript库）进行特性检测，它提供了非常先进的HTML5和CSS3检测功能。建议读者使用Modernizr检测当前浏览器是否支持某些特性。1.2　HTML5设计原理

设计原理是Web发展背后的驱动力，也是通过HTML5反映出来的某种思维方式。软件就像所有技术一样，具有天然的独裁性。代码必然会反映作者的选择、偏见和期望。任何开放的标准，都应该追求以下几点：● 简化最常见的任务，让不常见的任务不至于太麻烦。● 只为80%设计。● 给内容创建者最大的权力。● 默认设置智能化。

在制定设计原理时，很多人用了很多时间却抓不住重点，因为他们想取悦所有人。关键在于我们不是要取悦所有人，而是要明确哪些人是最重要的。

意大利经济学家帕累托提出“世界上20%的人口拥有80%的财富”。这个比例又暗合了自然界各个领域的幂律分布现象。总之，无论是编写软件，还是制造什么东西，都是一样的，即20%的努力可以触及80%的用例，最后20%的用例则需要付出80%甚至更多的努力。因此，有时候据此确定只为80%设计是很合理的，因为我们知道为此只要付出20%的努力即可。1.2.1　HTML开发历程

HTML最早是从2.0版开始的，实际上并没有HTML 1.0版官方规范。HTML Tags文档可以算作HTML的第一个版本，但它却不是一个正式的版本。第一个正式版本HTML 2.0也不是出自W3C之手，而是由IETF（Internet Engineering Task Force，因特网工程任务组）制定的，从第三个版本开始，W3C（World Wide Web Consortium，万维网联盟）开始接手并负责后续版本的制定工作。

20世纪90年代，HTML有过几次快速的发展。众所周知，那时构建网站是一项十分复杂的工程，浏览器大战曾令人头疼不已，市场竞争的结果就是各家浏览器里都塞满了各种专有的特性，都试图在专有特性上胜人一筹。当时的混乱程度不堪回首，HTML还重不重要，或者它作为Web格式的前景如何，谁都说不清楚。

从1997年到1999年，HTML的版本从3.2到4.0，再到4.01，经历了非常快的发展。问题是到了4.01的时候，W3C的认识发生了倒退，W3C并没有停止开发这门语言，只不过他们对HTML不再感兴趣了。在HTML 4.01之后，W3C提出了XHTML 1.0的概念。虽然听起来完全不同，但XHTML 1.0与HTML 4.01其实是一样的。

这两个规范的内容是一样的，词汇表是一样的，所有的元素是一样，所有的属性也都是一样的，唯一不同的就是XHTML 1.0要求使用XML语法。也就是说，所有属性都必须使用小写字母，所有元素也必须使用小写字母，所有属性值都必须加引号，所有的标签都必须有结束标签，对img和br等孤标签，要使用自结束标签。

从规范本身的内容来看，本质是相同的，不同之处就是编码风格，因为浏览器读取符合HTML 4.01、HTML 3.2或者XHTML 1.0规范的网页都没有问题，对浏览器来说这些网页都是一样的，都会生成相同的DOM树，只不过用户更喜欢XHTML 1.0，因为不少人认同它比较严格的编码风格。

到了2000年，Web标准项目（Web Standards Project）的活动开展得如火如荼，开发人员对浏览器里包含的那些乱七八糟的专有特性已经忍无可忍了。当时CSS有了长足的发展，而且与XHTML 1.0的结合也很紧密，CSS+XHTML 1.0可以算是最佳实践了。虽然HTML 4.01与XHTML 1.0没有本质上的区别，但是大部分开发人员接受了这种组合。专业的开发人员能做到元素全部小写，属性全部小写，属性值也全部加引号。由于专业人员起到了模范带头作用，越来越多的人也都开始支持这种语法。

XHTML 1.0之后是XHTML 1.1，只是小数点后面的数字变成了1，而且从词汇表的角度看，规范本身没有什么新内容，元素、属性也都相同，唯一的变化就是必须把文档标记为XML文档。而在使用XHTML 1.0的时候，还可以把文档标记为HTML。

但是，这样做就带来很多问题：首先，把文档标记为XML后，IE浏览器不能处理。当然，IE9及其以上版本是可以处理的。作为全球领先的浏览器，IE无法处理接收到的XML文档类型的文档，而规范又要求以XML文档类型来发送文档，这对于广大用户来说，是一件很痛苦的事情。

所以说XHTML 1.1有点脱离现实，而用户不想把文档以XML格式发送给那些能够理解XML的浏览器，则是因为XML的错误处理模型。XML的语法，无论是属性小写，元素小写，还是始终要给属性值加引号，这些都没有问题，但XML的错误处理模型却是这样的：如果解析器遇到错误，停止解析。如果把XHTML 1.1标记为XML文档类型，假设用Firefox打开这个文档，而文档中有一个符号没有正确编码，就算整个页面中只有这一处错误，浏览器也会死掉，用户将看不到任何网页内容。根据XML规范，这样处理是正确的，对Firefox而言，遇到错误就停止解析，并且不呈现其他任何内容是严格按照XML规范处理的。因为它不是HTML，HTML根本没有错误处理模型，但根据XML规范，这样做没错。这就是为什么人们不会把文档标记为XML的另一个原因。

接下来，新的版本是XHTML2，但是这个版本并没有完成。从理论的角度来说，XHTML2是一个非常好的规范。如果所有人都同意使用的话，也一定是一个非常好的格式。只不过，它还不够实际。

首先，XHTML2仍然使用XML错误处理模型，用户必须保证以XML文档类型发送文档；其次，XHTML2中有意不再向后兼容已有的HTML的各个版本，甚至曾经讨论过废除img元素，这对每天都在做Web开发的人来说确实有点难以接受，理论上分析，使用object元素可能会更好。

因此，无论XHTML2在理论上是多么完美的一种格式，却从未有机会付诸实践。之所以难以将其付诸实践，就是因为开发人员永远不会支持它，它不向后兼容。同样，浏览器厂商也不会支持它，必须要保证浏览器向后兼容。

为什么XHTML 1.1没有像XML那样得到真正广泛地应用？为什么XHTML2从未落到实处？因为它违反了一条设计原理，这条设计原理就是著名的伯斯塔尔法则：发送时要保守，接收时要开放。

接收的时候要开放，而这也正是Web得以构建的基础。开发浏览器的人必须敞开胸怀，接收所有发送给浏览器的东西，因为它们过去一直都在接收那些不够标准的东西，Web上的很多文档都不规范，但那正是Web发展的动力。从某种角度讲，Web走的正是一条混沌发展之路，虽然混沌，却非常美丽诱人。在Web上，格式不规范的文档随处可见，如果所有人都能够写出精准的XML，所有文档的格式都十分正确，那当然好，可是那不现实。

作为专业人士，在发送文档的时候应该保守一些，尽量采用最佳实践，尽量确保文档格式良好，但从浏览器的角度说，它们必须以开放的姿态去接收任何文档。

XHTML 1.1和XHTML2都使用XML错误处理模型，但这个错误处理模型太苛刻了，它不符合“接收时开放”这个法则，遇到一个错误就停止解析怎么能叫开放呢？我们只能说它与伯斯塔尔法则是对立的。1.2.2　HTML5开发动力

在20世纪末期，W3C琢磨着改良HTML语言，“HTML也许还可以更长寿一点，只要把我们放在XHTML上的时间和精力拿出一部分来，就可以提升一下HTML中的表单，可以让HTML更接近编程语言，就可以让它更上一层楼。”

于是，在2004年W3C成员内部的一次研讨会上，Opera公司的代表伊恩·希克森（Ian Hickson）提出了一个扩展和改进HTML的建议。他建议新任务组可以跟XHTML2并行，但是在已有HTML的基础上开展工作，目标是对HTML进行扩展。但是W3C投票表示反对，因为HTML已经死了，XHTML2才是未来的方向。然后，Opera、Apple等浏览器厂商以及其他一些成员脱离了W3C，他们成立了WHATWG （Web Hypertext Applications Technology Working Group，Web超文本应用技术工作组），这就为HTML5将来的命运埋下了伏笔。

WHATWG决定完全脱离W3C，在HTML的基础上开展工作，向其中添加一些新东西。这个工作组的成员里有浏览器厂商，因此他们可以保证实现各种新奇、实用的点子。结果，大家不断提出一些好点子，并且逐一做到了浏览器中。

WHATWG的工作效率很高，不久就初见成效。在此期间，W3C的XHTML2没有什么实质性的进展。在2006年，蒂姆·伯纳斯·李（Tim Berners-Lee）写了一篇博客反思HTML的发展历史，“你们知道吗？我们错了。我们错在企图一夜之间就让Web跨入XML时代，我们的想法太不切实际了，是的，也许我们应该重新组建HTML工作组了。”

W3C在2007年组建了HTML5工作组。这个工作组面临的第一个问题，毫无疑问就是“我们是从头开始做起呢，还是在2004年成立的那个叫WHATWG的工作组既有成果的基础上开始工作呢？”答案是显而易见的，他们当然希望从已经取得的成果着手，以之为基础展开工作。于是他们又投了一次票，同意在WHATWG工作成果的基础上继续开展工作。

第二个问题就是如何理顺两个工作组之间的关系。W3C这个工作组的编辑应该由谁担任？是不是还让WHATWG的编辑，也就是现在Google的伊恩·希克森来兼任？于是他们又投了一次票，赞成让伊恩·希克森担任W3C HTML5规范的编辑，同时兼任WHATWG的编辑，更有助于新工作组开展工作。

这就是他们投票的结果，也就是我们今天看到的局面：一种格式，两个版本。WHATWG的网站上有这个规范，而W3C的站点上同样也有一份。

如果不了解内情，你很可能会产生这样的疑问：“哪个版本才是真正的规范？”当然，这两个版本内容是一样的，基本上相同，但这两个版本将来还会分道扬镳。现在已经有分道扬镳的迹象了：W3C最终要制定一个具体的规范，这个规范会成为一个工作草案，定格在某个历史时刻，而WHATWG还在不断地迭代，即使是目前的HTML5也不能完全涵盖WHATWG正在从事的工作。最准确的理解就是WHATWG正在开发一项简单的HTML或Web技术，因为这才是他们工作的核心目标。然而，同时存在两个这样的工作组，这两个工作组同时开发一个基本相同的规范，这无论如何也容易让人产生误解，误解就可能造成麻烦。

其实这两个工作组背后各自有各自的流程，因为它们的理念完全不同。在WHATWG，可以说是一种独裁的工作机制。伊恩·希克森是编辑，他会听取各方意见，在所有成员各抒己见，充分陈述自己的观点之后，他批准自己认为正确的意见。而W3C则截然相反，可以说是一种民主的工作机制。所有成员都可以发表意见，而且每个人都有投票表决的权利。这个流程的关键在于投票表决。从表面上看，WHATWG的工作机制让人难以接受，W3C的工作机制听起来让人很舒服，至少体现了人人平等的精神。但在实践中，WHATWG的工作机制运行得非常好，这主要归功于伊恩·希克森。他在听取各方意见时，始终可以做到丝毫不带个人感情色彩。

从原理上讲，W3C的工作机制很公平，而实际上却非常容易在某些流程或环节上卡壳，造成工作停滞不前，一件事情要达成决议往往需要花费很长时间。那到底哪种工作机制最好呢？最好的工作机制是将二者结合起来。而事实也是两个规范制定主体在共同制定一份相同的规范，这倒是非常有利于两种工作机制相互取长补短。

两个工作组之所以能够同心同德，主要原因是HTML5的设计思想。因为他们从一开始就确定了设计HTML5所要坚持的原则。结果，我们不仅看到了HTML5语言规范，也就是W3C站点上公布的那份文档，还在W3C站点上看到了另一份文档，也就是HTML5设计原理。1.2.3　HTML5设计理念

HTML5是一个里程碑式的规范，它为下一代Web发展指明了方向，下面我们就来探析HTML5语言的设计理念。这个设计理念相当于共同行动纲领，无论W3C与WHATWG之间有多大的分歧，他们都将遵循这个设计理念。● 避免不必要的复杂性

例如，使用HTML 4.01规范时，如果定义doctype，需要输入很长的字符串：

很少有人能够记住这行代码，本来它要告诉浏览器的是“这个文档是XHTML 1.0的文档”。那么在HTML5中，省掉不必要的复杂性，doctype就简化成了：

第一次看到这个doctype的时候，或许很难想到，这个doctype要告诉浏览器什么呢？这个文档是HTML吗？难道这是有史以来唯一一个HTML版本吗？HTML今后永远不会再有新版本了吗？

实际上这个doctype并没有HTML版本区分的意思。我们先搞清楚为什么文档一开头就要写doctype。这不是写给浏览器看的，而是写给验证器看的。也就是说，之所以要在文档一开头写那行XHTML 1.0的doctype，是为了让验证器按照该doctype来验证我的文档。

浏览器反倒无所谓了。假设写的是HTML 3.2文档，文档开头写的是HTML 3.2的doctype，而在文档中某个地方使用了HTML 4.01中才出现的一个元素，浏览器会怎么处理这种情况？它会因为这个元素出现在比doctype声明的HTML版本更晚的规范中，就不解释呈现该元素吗？不会，它照样会解释呈现该元素，别忘了伯斯塔尔法则，浏览器在接收的时候必须要开放。因此，它不会检查任何格式类型，而验证器会，验证器才关心格式类型。这才是存在doctype的真正原因。

而按照HTML5的另一个设计原理，它必须向前向后兼容，兼容未来的HTML版本，不管是HTML6、HTML7，还是其他版本，都要与当前的HTML5兼容。因此，把一个版本号放在doctype里面没有多大的意义，对验证器也一样。

但是有一种情况下，使用doctype会影响到浏览器，这也是为了达到某种特殊的目的才使用doctype。当初微软在引入CSS的时候，走在了标准的前头，他们率先在浏览器中支持CSS，也推出了自己的盒模型。后来标准发布了，但标准中使用了不一样的盒模型。微软想支持标准，但也想向后兼容自己过去推出的编码方式。于是，他们想出了一个非常巧妙的主意，那就是利用有效的doctype来触发标准模式，而不是兼容模型（quiks mode）。这个想法非常巧妙。我们今天也都是在这样做，在向文档中加入doctype时，就相当于声明了使用标准模式，但这并不是发明doctype的本意。这只是为了达到特殊的目的在利用doctype。

HTML5规范的本质是不追求理论上的完美。HTML5所体现的不是给用户一个简短好记的doctype，好记的doctype也无法适应现有的浏览器。因此，doctype不仅从理论上看简短好记，而且在实践中仍然可以触发标准模式。

还有一个例子，同样可以说明规范是如何省略不必要的复杂性，避免不必要的复杂性的。如果前面的文档使用的是HTML 4.01，假设要指定文档的字符编码，理想的方式是通过服务器在头部信息中发送字符编码，不过也可以在文档这个级别上指定：

如果想指定文档使用UTF-8编码，只能添加上面一行代码。在HTML 4.01中需要这样做。要是在XHTML 1.0指定同样的编码，就得在一个开始的XML标签中声明meta元素。

在HTML5中，只要输入下面代码即可。

同样，这样写也是有效的。它不仅适用于最新版本的浏览器，仍在使用的以往版本的浏览器中也同样有效，因为在把这些meta元素输入浏览器时，浏览器都会正确解释。

关于省略不必要的复杂性的例子还有很多，但关键是既能避免不必要的复杂性，又不会妨碍在现有浏览器中使用。在HTML5中，如果使用link元素链接到一个样式表，先定义rel="stylesheet"，然后再定义type="text/css"，这样就重复了。对浏览器而言，不需要同时看到这两个属性，只要看到rel="stylesheet"就够了，因为它可以猜出来要链接的是一个CSS样式表，所以就不用再指定type属性了。

同样，如果使用script元素，定义type="text/javascript"，浏览器也可以识别。对Web开发而言，谁还使用其他的脚本语言吗？愿意的话，可以添加一个type属性，也可以什么都不写，浏览器自然会假设在使用JavaScript。● 支持已有的内容

支持已有的内容。这一点非常重要，因为很多人都认为HTML5很新，它应该代表着未来发展的方向，应该把Web推向一个新的发展阶段。当然我们都会考虑让Web的未来发展得更好，但工作组则必须考虑过去。别忘了WHATWG这个工作组中有很多人代表的是浏览器厂商，他们肯定是要考虑支持已有内容的。只要想构建一款浏览器，就必须记住一个原则：必须支持已有的内容。【示例1】本示例展示了编写同样内容的4种不同方式。上面是一个img元素，下面是带一个属性的段落元素，4种写法唯一的不同点就是语法。把其中任何一段代码交给浏览器，浏览器都会生成相同的DOM树，没有任何问题。从浏览器的角度看，这4种写法没有区别，因此在HTML5中可以随意使用下列语法。

Hello world

Hello world

Hello world

Hello world

HTML5同时允许这些写法，对于那些写了很多年XHTML 1.0代码，已经非常适应严格的语法的开发人员来说，是难以适应的，但站在浏览器的角度上，这些写法实际上都是一样的，确实没有什么问题。

HTML5必须支持已经存在的内容，而已有的内容就是这个样子的。根据伯斯塔尔法则，浏览器没有别的选择。

有人可能会说“这样不行。我觉得语言本身应该提供一种开关，让作者能够表明自己想做什么。”比如说，想使用某种特定的语法，像XHTML，而不是使用其他语法。这些人的想法可以理解，但没必要在语言里设置开关。因为我们讨论的只是编码风格或者写作风格，跟哪种语法正确与否无关。专业人士可以使用lint工具（一种软件质量保证工具，或者说是一种更加严格的编译器。它不仅可以像普通编译器那样检查出一般的语法错误，还可以检查出那些虽然完全合乎语法要求，但很可能是潜在的、不易发现的错误）。

对其他技术我们也在使用lint工具，比如对JavaScript使用lint工具。JavaScript同样也是比较混乱、不严谨的典型，但它非常强大，恰恰是因为它混乱、不严谨，而且有很多不同的编码方式。在JavaScript中可以在每条语句末尾加上分号，但不是必需的，因为JavaScript会自动插入分号。

正因为如此，才有了像JSlint这样的工具。在道格拉斯·克劳克福德（Douglas Crockford）的网站jslint.org上写着“JSlint可能会伤害你的感情”，但这确实是个非常棒的工具，它可以把JavaScript代码变得完美无瑕。如果通过JSlint运行JavaScript，它会告诉你你的JavaScript代码有效，但写法不妥。特别是对团队，对于要使用统一的编码风格的团队，JSlint是非常方便的工具。

个人认为，不仅对团队来说，就算是自己写代码，也要坚持一种语法风格。从浏览器解析的角度讲，不存在哪种语法比另一种更好的问题，但作为专业人士，必须能够自信地讲“这就是我的编码风格”。然而，语言里并不需要内置这种开关，用户可以使用lint工具来统一编码风格。现在就来说说lint工具。大家可以登录htmllint.com，在其中运行HTML5文档，它会帮用户检查属性值是否加了引号，元素是否小写，还可以通过选中复选框来设置其他检查项。● 解决现实的问题

HTML5的另一个设计原理是解决现实的问题。显而易见的是，解决各种问题的格式和规范已经比比皆是了，因此，这个原理其实是要解决理论问题，而非解决现实问题。这条设计原理是要从理论上承认人们普遍存在的问题，消除敏感问题。但是，那些格式和规范要解决的都是理论问题，而非现实问题。这条设计原理才是真正要解决今天人们所面临的现实问题、令人头疼的问题。【示例2】假设使用HTML 4或XHTML 1，页面中已经有了一块内容，想给整块内容添加一个链接，怎么办？问题是这块内容里包含一个标题，一个段落，也许还有一张图片。如果想使它们全部都可以生成链接，必须使用3个链接元素。于是，得先把光标放在标题（比如说h2元素）中，写一个链接标签，然后再选中所有要包含到链接里的文本。接着，把光标放在段落里，写一个链接标签，然后把段落中的文本放在链接里。

标题文本

段落文本

在HTML5中，只要简单地把所有内容都写在一个链接元素中就可以了。

标题文本

链接包含的都是块级元素，但现在可以用一个元素包含它们。这样，碰到类似的情形，就必须给几个块级元素加上相同的链接，因为这样做解决了一个现实的问题：不必因此重新写代码来支持这种写法。这种写法其实早就存在于浏览器中了，因为早就有人这样写了，当然以前这样写是不合乎规范的。所以说HTML5解决了现实的问题，允许这样写了。● 求真务实

求真务实对于HTML的含义是：在解决那些令人头痛的问题之前，先看看人们为应对这些问题都想出了哪些办法。集中精力去理解这些解决方案才是当务之急。

HTML5中新的语义元素就是遵循求真务实原理的反映。新增的元素不算多，谈不上无限的扩展性，但却不失为一件好事，尽管数量屈指可数，但意义却非同一般。这些新元素涉及头部（header）、脚部（footer）、分区（section）、文章（article）等，相信大家都不会觉得陌生。即便不使用HTML5，也应该熟悉这些名称，它们都是曾经使用过的类名，如class="header"/"head"/"heading"，或class="footer"/"foot"。当然，也可能是ID，如id="header"或id="footer"。

在HTML5中，这些元素都可以换掉。说起新增的语义元素，它们价值的一方面就是可以用HTML5新增的元素把这些div都替换掉。

在文档级别上使用这些元素没有问题，但是，假如新增这些元素仅仅是为了取代原来的div，那就没有必要了。

虽然在这个文档中用这些新元素来替换ID，但在个人看来，将它们作为类的替代品更有价值，因为这些元素在一个页面中不止可以使用一次，而是可以使用多次。没错，也可以为文档添加一个头部（header），再添加一个脚部（footer），但文档中的每个分区（section）照样也都可以有一个头部和一个脚部，而每个分区里还可以嵌套另一个分区，被嵌套的分区仍然可以有自己的头部和脚部。

这4个新元素是section、article、aside和nav，之所以说它们强大，原因在于它们代表了一种新的内容模型，一种HTML中前所未有的内容模型--给内容分区。迄今为止，我们一直都在用div来组织页面中的内容，但与其他类似的元素一样，div本身并没有语义；但section、article、aside和nav实际上是在明确地告诉用户，这一块就像文档中的另一个文档一样。位于这些元素中的任何内容，都可以拥有自己的概要、标题和脚部。

其中最为通用的section，可以说是与内容最相关的一个，而article则是一种特殊的section。aside和nav也是特殊的section。

当然，现在仍然可以使用div和类来描述页面中不同的部分：

其中包含的可能是有关内容作者的元数据，而下面会给出一些链接。在HTML5中，完全可以说这块内容就是一个文档，通过对内容分区，使用section、article或aside，这一块完全是可以独立存在的。因此，可以使用header和footer。

在HTML5中，只要建立一个新的内容块，不管用section、article、aside、nav，还是用别的元素，都可以在其中使用H1，而不必担心这个块里的标题在整个页面中应该排在什么级别；使用H2、H3也都没有问题，因为现在可以把每个内容分区想象成一个独立的、能够从页面中拿出来的部分。此时，根据上下文的不同，这个独立部分中的H1在整个页面中也许会扮演H2或H3的角色，这取决于它在文档中出现的位置。面对这个突如其来的变化，也许有的人暂时不能理解，但这才是HTML5中这些新语义标记的真正价值所在。换句话说，现在有了独立的元素，这些元素中的标题级别可以重新定义。

文档中可能会包含一个分区，这个分区中可能会嵌套另一个分区，或者一篇文章，然后文章再嵌套分区，分区再嵌套文章、嵌套分区，文章再嵌套文章。而且每个分区和文章都可以拥有自己的H1~H6。从这个意义上讲，H元素真可谓层层嵌套。但是，在编写内容或者内容管理系统的时候，它们又都是完全独立的内容块。

这个点子并不是HTML5工作组想出来的，也不是W3C最近才提出的，实际上蒂姆·伯纳斯·李在1991年的一封邮件中就提到这种想法。他在邮件中解释了对HTML的理解，他说“我认为H1、H2这样单调地排下去不好，我希望它成为一种可以嵌套的元素，或者说一个通用的H元素，我们可以在其中嵌套不同的层次。”但后来，我们没有看到通用的H元素，而是一直在使用H1和H2，那是因为我们一直在支持已有的内容。今天，这个理想终于实现了。● 平稳退化

渐进增强的另一面就是平稳退化。HTML5遵循这条原理的例子，就是使用type属性增强表单。下面列出了可以为type属性指定的新值，有number、search和range等。input type="number"input type="search"input type="range"input type="email"input type="date"input type="url"

最关键的问题在于浏览器在看到这些新type值时会如何处理。现有的浏览器是无法理解这些新type值的，但它们会将type的值解释为text。

无论你写的是input type="foo"，还是input type="bar"，现有的任何浏览器都会把它理解为“text”。因而，从现在开始就可以使用这些新值，而且也可以放心，那些不理解它们的浏览器会把新值看成type="text"，而这正是一个浏览器实践平稳退化原理的好例子。

例如，现在输入了type="number"。假设需要一个输入数值的文本框，那么可以把这个input的type属性设置为number，然后理解它的浏览器就会呈现一个可爱的小控件，如带小箭头图标的微调控件之类的，而在不理解它的浏览器中，则会看到一个文本框，那么为什么不能说输入type="number"就会得到一个带小箭头图标的微调控件呢？

当然，还可以设置最小值和最大值属性，它们同样可以平稳退化。

再看input type="search"。你也可以考虑一下这种输入框，因为这种输入框在Safari中会被呈现为一个系统级的搜索控件，右边还有一个单击即可清除搜索关键词的X。而在其他浏览器中，得到的则是一个文本框，就像所写的是input type="text"一样。那为什么还不使用input type="search"呢？它不会有什么副作用。

HTML5还为输入元素增加了新的属性，如placeholder（占位符），它表示在文本框中预先放一些文本。占位符就是文本框可以接受的示例内容，一般颜色是灰色的。只要一单击文本框，它就消失了。如果把已经输入的内容全部删除，然后单击文本框外部，它又会出现。使用JavaScript编写一些代码当然也可以实现这个功能，但HTML5只用一个placeholder属性就解决了问题。

当然，对于不支持这个属性的浏览器，还是可以使用JavaScript来实现占位符功能的。通过JavaScript来测试浏览器是否支持该属性也非常简单。如果不支持，可以让JavaScript来模拟这个功能。

下面就来看看这个新的video元素，它设计得既简单又实用。一个开始的video元素，加一个结束的video元素，中间可以放后备内容。注意，是后备内容，而不是保证可访问性的内容。下面就是针对不支持video元素的浏览器写的代码。

那么，在后备内容里面放些什么东西呢？可以放Flash影片，这样，HTML5的视频与Flash的视频就可以协同起来了，用户不需要作出选择。

因为这里使用了H264，部分浏览器支持这种视频格式，但有的浏览器不支持，对于不支持的情况，仅需要把后备内容放在那儿而已，后备内容可以包含多种视频格式。如果愿意的话，可以使用source元素而非src属性来指定不同的视频格式。

上面的代码中包含了4个不同的层次。● 如果浏览器支持video元素，也支持H264，则直接用第一个视频。● 如果浏览器支持video元素，也支持Ogg，那么用第二个视频。● 如果浏览器不支持video元素，就要试试Flash影片了。● 如果浏览器不支持video元素，也不支持Flash，代码中还给出了

下载链接。

总之，无论是HTML5和Flash一个也不能少。如果只使用video元素提供视频，难免会遇到问题。而如果只提供Flash影片，性质是一样的。所以还是应该两者兼顾。

为什么要兼顾这两种技术呢？假设你需要面向某些不支持Flash的手持设备提供视频，当然希望手持设备的用户能够看到视频了。

至于为什么要使用不同的格式？当然，面对竞争性的视频格式和不同的编码方式，只向浏览器发送用一种方式编码的视频是行不通的，而这也正是Flash在视频和音频领域如此成功的原因。只要把Flash影片发送给浏览器，安装了插件的浏览器都能正常播放。● 最终用户优先

这个设计原理本质上是一种解决冲突的机制。换句话说，当面临一个要解决的问题时，如果W3C和WHATWG给出了不同的解决方案，一旦遇到冲突，最终用户优先，然后是作者，其次是实现者，再次是标准制定者，最后才是理论上的完满。

理论上的完满，大致是指尽可能创建出最完美的格式。标准制定者指的是WHATWG、W3C等。实现者指的是浏览器厂商。作者就是开发人员。用户是第一位的。

根据最终用户优先的原理，开发人员在链条中的位置高于实现者，假如我们发现了规范中的某些地方有问题，又不支持实现这个特性，那么就等于把相应的特性给否定了，规范里就得删除，因为我们的声音具有更高的权重。本质上是我们拥有了更大的发言权，我认为开发人员就应该拥有更多的发言权。

这应该是最重要的一条设计原理了，因为它承认了用户的权利，无论是设计一种格式，还是设计软件，这条原理保证了用户的发言权。而这条原理也正道出了事物运行的本质，用户的权利大于作者，作者的权利大于实现者，实现者的权利大于标准制定者。然而，反观其他规范，如XHTML2，就会发现完全相反的做法--把追求理论的完满放在第一位，而把用户放在了链条的最底端，需要忍受严格错误处理带来的各种麻烦。这是一种完全不同的思维方式。

因此，无论是构建像HTML5这样的格式，还是构建一个网站，亦或一个内容管理系统，明确设计原理都至关重要。1.3　编写第一个HTML5页面

尽管各主流厂商的最新版浏览器都对HTML5提供了很好的支持，但毕竟HTML5是一种全新的HTML标记语言，许多新的功能必须在搭建好相应的浏览环境后才可以正常浏览。为此，我们在正式执行一个HTML5页面之前，必须先搭建支持HTML5的浏览器环境，并检查浏览器是否支持HTML5标记。1.3.1　搭建上机练习环境

目前，Microsoft的IE系列（IE9+）浏览器，以及Mozlilla的Firefox与Google的Chrome浏览器等都可以很好地支持HTML5。

本书所有的应用示例，主要执行的浏览器为Chrome，其对应的版本号是15.0.874.120。如需运行本书中的示例，则要安装最新的Chrome浏览器，以浏览相应的示例页面效果。1.3.2　检测浏览器是否支持

安装相应的浏览器以后，为了能进一步了解浏览器支持HTML新标签功能的情况，还可以在引入新标签前，通过编写JavaScript代码来检测浏览器是否支持该标签。

浏览器在加载Web页面时会构造一个文本对象模型（DOM），然后通过该对象模型来表示页面中的各个HTML元素，这些元素被表示为不同的DOM对象。全部的DOM对象都共享一些公共或特殊的属性，如HTML5的某些特性，如果在支持该属性的浏览器中打开页面，就

试读结束[说明：试读内容隐藏了图片]

下载完整电子书