浏览器w3c验证

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

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

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

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

2.
合理性HTML5新增加的元素都是对现有网页和用户习惯进行跟踪、分析和概括而推出的.
例如,Google分析了上百万的页面,从中分析出了DIV标签的通用ID名称,并且发现其重复量很大,如很多开发人员使用来标记页眉区域,为了解决实际问题,HTML5就直接添加一个标签.
也就是说,HTML5新增的很多元素、属性或者功能都是根据现实互联网中已经存在的各种应用进行技术精炼,而不是在实验室中理想化地虚构新功能.

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.
简化的字符集声明.
简单而强大的HTML5API.
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.
2HTML5组织HTML5开发主要由下面3个组织负责和实施.
WHATWG:由来自Apple、Mozilla、Google和Opera等浏览器厂商的人员组成,成立于2004年.
WHATWG开发HTML和Web应用API,同时为各浏览器厂商以及其他有意向的组织提供开放式合作.

W3C:W3C下辖的HTML工作组,目前负责发布HTML5规范.
IETF(因特网工程任务组):这个任务组下辖HTTP等,是负责开发Internet协议的团队.
HTML5定义的一种新API(WebSocketAPI)所依赖的WebSocket协议,正由IETF工作组负责开发.
1.
1.
3HTML5构成HTML5主要包括下面这些功能.
Canvas(2D和3D)Channel消息传送Cross-document消息传送GeolocationMathMLMicrodataServer-SentEventsScalableVectorGraphics(SVG)WebSocketAPI及协议WebOriginConceptWebStorageWebSQLdatabaseWebWorkersXMLHttpRequestLevel2HTML5发展的速度非常快,因此不用担心浏览器的支持问题.
读者可以访问www.
caniuse.
com,该网站按照浏览器的版本提供了详尽的HTML5的功能支持情况.
如果通过浏览器访问www.
html5test.
com,该网站会直接显示用户浏览器对HTML5规范的支持情况.
另外,还可以使用Modernizr(JavaScript库)进行特性检测,它提供了非常先进的HTML5和CSS3检测功能.
建议读者使用Modernizr检测当前浏览器是否支持某些特性.

1.
2HTML5设计原理设计原理是Web发展背后的驱动力,也是通过HTML5反映出来的某种思维方式.
软件就像所有技术一样,具有天然的独裁性.
代码必然会反映作者的选择、偏见和期望.
任何开放的标准,都应该追求以下几点:简化最常见的任务,让不常见的任务不至于太麻烦.
只为80%设计.
给内容创建者最大的权力.
默认设置智能化.
在制定设计原理时,很多人用了很多时间却抓不住重点,因为他们想取悦所有人.
关键在于我们不是要取悦所有人,而是要明确哪些人是最重要的.
意大利经济学家帕累托提出"世界上20%的人口拥有80%的财富".
这个比例又暗合了自然界各个领域的幂律分布现象.
总之,无论是编写软件,还是制造什么东西,都是一样的,即20%的努力可以触及80%的用例,最后20%的用例则需要付出80%甚至更多的努力.
因此,有时候据此确定只为80%设计是很合理的,因为我们知道为此只要付出20%的努力即可.

1.
2.
1HTML开发历程HTML最早是从2.
0版开始的,实际上并没有HTML1.
0版官方规范.
HTMLTags文档可以算作HTML的第一个版本,但它却不是一个正式的版本.
第一个正式版本HTML2.
0也不是出自W3C之手,而是由IETF(InternetEngineeringTaskForce,因特网工程任务组)制定的,从第三个版本开始,W3C(WorldWideWebConsortium,万维网联盟)开始接手并负责后续版本的制定工作.
20世纪90年代,HTML有过几次快速的发展.
众所周知,那时构建网站是一项十分复杂的工程,浏览器大战曾令人头疼不已,市场竞争的结果就是各家浏览器里都塞满了各种专有的特性,都试图在专有特性上胜人一筹.
当时的混乱程度不堪回首,HTML还重不重要,或者它作为Web格式的前景如何,谁都说不清楚.

从1997年到1999年,HTML的版本从3.
2到4.
0,再到4.
01,经历了非常快的发展.
问题是到了4.
01的时候,W3C的认识发生了倒退,W3C并没有停止开发这门语言,只不过他们对HTML不再感兴趣了.
在HTML4.
01之后,W3C提出了XHTML1.
0的概念.
虽然听起来完全不同,但XHTML1.
0与HTML4.
01其实是一样的.
这两个规范的内容是一样的,词汇表是一样的,所有的元素是一样,所有的属性也都是一样的,唯一不同的就是XHTML1.
0要求使用XML语法.
也就是说,所有属性都必须使用小写字母,所有元素也必须使用小写字母,所有属性值都必须加引号,所有的标签都必须有结束标签,对img和br等孤标签,要使用自结束标签.

从规范本身的内容来看,本质是相同的,不同之处就是编码风格,因为浏览器读取符合HTML4.
01、HTML3.
2或者XHTML1.
0规范的网页都没有问题,对浏览器来说这些网页都是一样的,都会生成相同的DOM树,只不过用户更喜欢XHTML1.
0,因为不少人认同它比较严格的编码风格.
到了2000年,Web标准项目(WebStandardsProject)的活动开展得如火如荼,开发人员对浏览器里包含的那些乱七八糟的专有特性已经忍无可忍了.
当时CSS有了长足的发展,而且与XHTML1.
0的结合也很紧密,CSS+XHTML1.
0可以算是最佳实践了.
虽然HTML4.
01与XHTML1.
0没有本质上的区别,但是大部分开发人员接受了这种组合.
专业的开发人员能做到元素全部小写,属性全部小写,属性值也全部加引号.
由于专业人员起到了模范带头作用,越来越多的人也都开始支持这种语法.

XHTML1.
0之后是XHTML1.
1,只是小数点后面的数字变成了1,而且从词汇表的角度看,规范本身没有什么新内容,元素、属性也都相同,唯一的变化就是必须把文档标记为XML文档.
而在使用XHTML1.
0的时候,还可以把文档标记为HTML.
但是,这样做就带来很多问题:首先,把文档标记为XML后,IE浏览器不能处理.
当然,IE9及其以上版本是可以处理的.
作为全球领先的浏览器,IE无法处理接收到的XML文档类型的文档,而规范又要求以XML文档类型来发送文档,这对于广大用户来说,是一件很痛苦的事情.

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

接下来,新的版本是XHTML2,但是这个版本并没有完成.
从理论的角度来说,XHTML2是一个非常好的规范.
如果所有人都同意使用的话,也一定是一个非常好的格式.
只不过,它还不够实际.
首先,XHTML2仍然使用XML错误处理模型,用户必须保证以XML文档类型发送文档;其次,XHTML2中有意不再向后兼容已有的HTML的各个版本,甚至曾经讨论过废除img元素,这对每天都在做Web开发的人来说确实有点难以接受,理论上分析,使用object元素可能会更好.

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

为什么XHTML1.
1没有像XML那样得到真正广泛地应用为什么XHTML2从未落到实处因为它违反了一条设计原理,这条设计原理就是著名的伯斯塔尔法则:发送时要保守,接收时要开放.
接收的时候要开放,而这也正是Web得以构建的基础.
开发浏览器的人必须敞开胸怀,接收所有发送给浏览器的东西,因为它们过去一直都在接收那些不够标准的东西,Web上的很多文档都不规范,但那正是Web发展的动力.
从某种角度讲,Web走的正是一条混沌发展之路,虽然混沌,却非常美丽诱人.
在Web上,格式不规范的文档随处可见,如果所有人都能够写出精准的XML,所有文档的格式都十分正确,那当然好,可是那不现实.

作为专业人士,在发送文档的时候应该保守一些,尽量采用最佳实践,尽量确保文档格式良好,但从浏览器的角度说,它们必须以开放的姿态去接收任何文档.
XHTML1.
1和XHTML2都使用XML错误处理模型,但这个错误处理模型太苛刻了,它不符合"接收时开放"这个法则,遇到一个错误就停止解析怎么能叫开放呢我们只能说它与伯斯塔尔法则是对立的.

1.
2.
2HTML5开发动力在20世纪末期,W3C琢磨着改良HTML语言,"HTML也许还可以更长寿一点,只要把我们放在XHTML上的时间和精力拿出一部分来,就可以提升一下HTML中的表单,可以让HTML更接近编程语言,就可以让它更上一层楼.
"于是,在2004年W3C成员内部的一次研讨会上,Opera公司的代表伊恩·希克森(IanHickson)提出了一个扩展和改进HTML的建议.
他建议新任务组可以跟XHTML2并行,但是在已有HTML的基础上开展工作,目标是对HTML进行扩展.
但是W3C投票表示反对,因为HTML已经死了,XHTML2才是未来的方向.
然后,Opera、Apple等浏览器厂商以及其他一些成员脱离了W3C,他们成立了WHATWG(WebHypertextApplicationsTechnologyWorkingGroup,Web超文本应用技术工作组),这就为HTML5将来的命运埋下了伏笔.
WHATWG决定完全脱离W3C,在HTML的基础上开展工作,向其中添加一些新东西.
这个工作组的成员里有浏览器厂商,因此他们可以保证实现各种新奇、实用的点子.
结果,大家不断提出一些好点子,并且逐一做到了浏览器中.

WHATWG的工作效率很高,不久就初见成效.
在此期间,W3C的XHTML2没有什么实质性的进展.
在2006年,蒂姆·伯纳斯·李(TimBerners-Lee)写了一篇博客反思HTML的发展历史,"你们知道吗我们错了.
我们错在企图一夜之间就让Web跨入XML时代,我们的想法太不切实际了,是的,也许我们应该重新组建HTML工作组了.
"W3C在2007年组建了HTML5工作组.
这个工作组面临的第一个问题,毫无疑问就是"我们是从头开始做起呢,还是在2004年成立的那个叫WHATWG的工作组既有成果的基础上开始工作呢"答案是显而易见的,他们当然希望从已经取得的成果着手,以之为基础展开工作.
于是他们又投了一次票,同意在WHATWG工作成果的基础上继续开展工作.

第二个问题就是如何理顺两个工作组之间的关系.
W3C这个工作组的编辑应该由谁担任是不是还让WHATWG的编辑,也就是现在Google的伊恩·希克森来兼任于是他们又投了一次票,赞成让伊恩·希克森担任W3CHTML5规范的编辑,同时兼任WHATWG的编辑,更有助于新工作组开展工作.
这就是他们投票的结果,也就是我们今天看到的局面:一种格式,两个版本.
WHATWG的网站上有这个规范,而W3C的站点上同样也有一份.
如果不了解内情,你很可能会产生这样的疑问:"哪个版本才是真正的规范"当然,这两个版本内容是一样的,基本上相同,但这两个版本将来还会分道扬镳.
现在已经有分道扬镳的迹象了:W3C最终要制定一个具体的规范,这个规范会成为一个工作草案,定格在某个历史时刻,而WHATWG还在不断地迭代,即使是目前的HTML5也不能完全涵盖WHATWG正在从事的工作.
最准确的理解就是WHATWG正在开发一项简单的HTML或Web技术,因为这才是他们工作的核心目标.
然而,同时存在两个这样的工作组,这两个工作组同时开发一个基本相同的规范,这无论如何也容易让人产生误解,误解就可能造成麻烦.

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

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

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

1.
2.
3HTML5设计理念HTML5是一个里程碑式的规范,它为下一代Web发展指明了方向,下面我们就来探析HTML5语言的设计理念.
这个设计理念相当于共同行动纲领,无论W3C与WHATWG之间有多大的分歧,他们都将遵循这个设计理念.

避免不必要的复杂性例如,使用HTML4.
01规范时,如果定义doctype,需要输入很长的字符串:很少有人能够记住这行代码,本来它要告诉浏览器的是"这个文档是XHTML1.
0的文档".
那么在HTML5中,省掉不必要的复杂性,doctype就简化成了:第一次看到这个doctype的时候,或许很难想到,这个doctype要告诉浏览器什么呢这个文档是HTML吗难道这是有史以来唯一一个HTML版本吗HTML今后永远不会再有新版本了吗实际上这个doctype并没有HTML版本区分的意思.
我们先搞清楚为什么文档一开头就要写doctype.
这不是写给浏览器看的,而是写给验证器看的.
也就是说,之所以要在文档一开头写那行XHTML1.
0的doctype,是为了让验证器按照该doctype来验证我的文档.
浏览器反倒无所谓了.
假设写的是HTML3.
2文档,文档开头写的是HTML3.
2的doctype,而在文档中某个地方使用了HTML4.
01中才出现的一个元素,浏览器会怎么处理这种情况它会因为这个元素出现在比doctype声明的HTML版本更晚的规范中,就不解释呈现该元素吗不会,它照样会解释呈现该元素,别忘了伯斯塔尔法则,浏览器在接收的时候必须要开放.
因此,它不会检查任何格式类型,而验证器会,验证器才关心格式类型.
这才是存在doctype的真正原因.

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

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

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

还有一个例子,同样可以说明规范是如何省略不必要的复杂性,避免不必要的复杂性的.
如果前面的文档使用的是HTML4.
01,假设要指定文档的字符编码,理想的方式是通过服务器在头部信息中发送字符编码,不过也可以在文档这个级别上指定:如果想指定文档使用UTF-8编码,只能添加上面一行代码.
在HTML4.
01中需要这样做.
要是在XHTML1.
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中可以随意使用下列语法.

HelloworldHelloworldHelloworldHelloworldHTML5同时允许这些写法,对于那些写了很多年XHTML1.
0代码,已经非常适应严格的语法的开发人员来说,是难以适应的,但站在浏览器的角度上,这些写法实际上都是一样的,确实没有什么问题.
HTML5必须支持已经存在的内容,而已有的内容就是这个样子的.
根据伯斯塔尔法则,浏览器没有别的选择.
有人可能会说"这样不行.
我觉得语言本身应该提供一种开关,让作者能够表明自己想做什么.
"比如说,想使用某种特定的语法,像XHTML,而不是使用其他语法.
这些人的想法可以理解,但没必要在语言里设置开关.
因为我们讨论的只是编码风格或者写作风格,跟哪种语法正确与否无关.
专业人士可以使用lint工具(一种软件质量保证工具,或者说是一种更加严格的编译器.
它不仅可以像普通编译器那样检查出一般的语法错误,还可以检查出那些虽然完全合乎语法要求,但很可能是潜在的、不易发现的错误).

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

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

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

解决现实的问题HTML5的另一个设计原理是解决现实的问题.
显而易见的是,解决各种问题的格式和规范已经比比皆是了,因此,这个原理其实是要解决理论问题,而非解决现实问题.
这条设计原理是要从理论上承认人们普遍存在的问题,消除敏感问题.
但是,那些格式和规范要解决的都是理论问题,而非现实问题.
这条设计原理才是真正要解决今天人们所面临的现实问题、令人头疼的问题.

【示例2】假设使用HTML4或XHTML1,页面中已经有了一块内容,想给整块内容添加一个链接,怎么办问题是这块内容里包含一个标题,一个段落,也许还有一张图片.
如果想使它们全部都可以生成链接,必须使用3个链接元素.
于是,得先把光标放在标题(比如说h2元素)中,写一个链接标签,然后再选中所有要包含到链接里的文本.
接着,把光标放在段落里,写一个链接标签,然后把段落中的文本放在链接里.

标题文本段落文本在HTML5中,只要简单地把所有内容都写在一个链接元素中就可以了.
标题文本段落文本链接包含的都是块级元素,但现在可以用一个元素包含它们.
这样,碰到类似的情形,就必须给几个块级元素加上相同的链接,因为这样做解决了一个现实的问题:不必因此重新写代码来支持这种写法.
这种写法其实早就存在于浏览器中了,因为早就有人这样写了,当然以前这样写是不合乎规范的.
所以说HTML5解决了现实的问题,允许这样写了.

求真务实求真务实对于HTML的含义是:在解决那些令人头痛的问题之前,先看看人们为应对这些问题都想出了哪些办法.
集中精力去理解这些解决方案才是当务之急.
HTML5中新的语义元素就是遵循求真务实原理的反映.
新增的元素不算多,谈不上无限的扩展性,但却不失为一件好事,尽管数量屈指可数,但意义却非同一般.
这些新元素涉及头部(header)、脚部(footer)、分区(section)、文章(article)等,相信大家都不会觉得陌生.
即便不使用HTML5,也应该熟悉这些名称,它们都是曾经使用过的类名,如class="header"/"head"/"heading",或class="footer"/"foot".
当然,也可能是ID,如id="header"或id="footer".