请选择 进入手机版 | 继续访问电脑版

HTML5星空

HTML5星空 首页 HTML5教程 查看内容

HTML5设计原理

2013-11-22 14:18| 发布者: admin| 查看: 1164| 评论: 0

摘要: 设计原理是Web发展背后的驱动力,也是通过HTML5反映出来的某种思维方式。软件就像所有技术一样,具有天然的独裁性。代码必然会反映作者的选择、偏见和期望。任何开放的标准,都应该追求以下几点: 简化最常见的任 ...
    设计原理是Web发展背后的驱动力,也是通过HTML5反映出来的某种思维方式。软件就像所有技术一样,具有天然的独裁性。代码必然会反映作者的选择、偏见和期望。任何开放的标准,都应该追求以下几点:

      简化最常见的任务,让不常见的任务不至于太麻烦。
      只为80%设计。
      给内容创建者最大的权力。
      默认设置智能化。

    在制定设计原理时,很多人用了很多时间却抓不住重点,因为他们想取悦所有人。关键在于我们不是要取悦所有人,而是要明确哪些人是最重要的。
    意大利经济学家帕累托提出“世界上20%的人口拥有80%的财富”。这个比例又暗合了自然界各个领域的幂律分布现象。总之,无论是编写软件,还是制造什么东西,都是一样的,即20%的努力可以触及80%的用例,最后20%的用例则需要付出80%甚至更多的努力。因此,有时候据此确定只为80%设计是很合理的,因为我们知道为此只要付出20%的努力即可。

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

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

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

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

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

    到了2000年,Web标准项目(Web Standards Project)的活动开展得如火如茶,开发人员对浏览:器里包含的那些乱七八糟的专有特性已经忍无可忍了。当时CSS有了长足的发展,而且与XHTML l.0
的结合也很紧密,CSS+XHTML l.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有点脱离现实,而用户不想把文档以XMI。格式发送给那些能够理解XML的浏览器,则是因为XML的错误处理模型。XML的语法,无论是属性小写,元素小写,还是始终要给属性值加引号,这些都没有问题,但XML的错误处理模型却是这样的:如果解析器遇到错误,停止解析。如果把XHTML 1.1标记为XML文档类型,假谡用Firefox打开这个文档,而文档中有一个符号没有正确编码,就算整个页面中只有这一处错误,浏览器也会死掉,用户将看不到任何网页内容。根据xrvn。规范,这样处理是正确的,对Firefox而言,遇到错误就停止解析,并且不呈现其他任何内容是严格按照XML规范处理的。因为它不是HTML,HTML根本没有错误处理模型,但根据XML规范,这样做没错。这就是为什么人们不会把文档标记为XML的另一个原因。   

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

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

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

HTML5开发动力
    在20世纪末期,W3C琢磨着改良HTML语言,“HTML也许还可以更长寿一点,只要把我们放在XHTML上的时间和精力拿出一部分来,就可以提升一下HTML中的表单,可以让HTML更接近
编程语言,就可以让它更上一层楼。”
    于是,在2004年W3C成员内部的一次研讨会上,Opera公司的代表伊恩·希克森(lan 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设计原理。

HTML5设计理念
    HTML5是一个里程碑式的规范,它为下一代Web发展指明了方向,下面我们就来探析HTML5语言的设计理念。这个设计理念相当于共同行动纲领,无论W3C与WHATWG之间有多大的分歧,
他们都将遵循这个设计理念。
      避免不必要的复杂性
    例如,使用HTML 4.01规范时,如果定义doctype,需要输入很长的字符串:
    <!DOCTYPE html PUBLIC”-//W3C/DTD HTML 4.OI//EN"”http://www.w3 .org/TR/htm14/strict.dtd">
    很少有人能够记住这行代码,本来它要告诉浏览器的是“这个文档是XHTML 1.0的文档”。那么在HTML5中,省掉不必要的复杂性,doctype就简化成了:
   <!DOCTYPE html>。

    第一次看到这个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,假设要指定文档的字符编码,理想的方式是通过服务器在头部信息中
发送字符编码,不过也可以在文档这个级别上指定:
  <meta http-equiv="Content-Type” content=”text/html; charsetxutf-8">   
  如果想指定文档使用UTF-8编码,只能添加上面一行代码。在HTML 4.01中需要这样做。要是在XHTML 1.0指定同样的编码,就得在一个开始的XML标签中声明meta元素。
  <?xml version=”1.0”encoding="UTF-8”?>
  <meta http-equiv=”Content-Type”content=”text/html; charset  utf-8">
  在HTML5中,只要输入下面代码即可。
<meta charset="utf-8">
    同样,这样写也是有效的。它不仅适用于最新版本的浏览器,仍在使用的以往版本的浏览器中也同样有效,因为在把这些meta元素输入浏览器时,浏览器都会正确解释。
    关于省略不必要的复杂性的例子还有很多,但关键是既能避免不必要的复杂性,又不会妫碍在现有浏览器中使用。在HTML5中,如果使用link元素链接到一个样式表,先定义rel=”stylesheet”,然
后再定义type=”text/css”,这样就重复了。对浏览器而言,不需要同时看到这两个属性,只要看到rel-”stylesheet”就够了,因为它可以猜出来要链接的是一个CSS样式表,所以就不用再指定type属
性了。
    同样,如果使用scnpt元素,定义type=”text/j avascript”,浏览器也可以识别。对Web开发而言,谁还使用其他的脚本语言吗?愿意的话,可以添加一个type属性,也可以什么都不写,浏览器自然
会假设在使用JavaScript。

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

  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的另一个设计原理是解决现实的问题。显而易见的是,解决各种问题的格式和规范已经比比皆是了,因此,这个原理其实是要解决理论问题,而非解决现实问题。这条设计原理是要从理论
上承认人们普遍存在的问题,消除敏感问题。但是,那些格式和规范要解决的都是理论问题,而非现实问题。这条设计原理才是真正要解决今天人们所面临的现实问题、令人头疼的问题。
    【假设使用HTML 4或XHTML 1,页面中已经有了一块内容,想给整块内容添加一个链接,怎么办?问题是这块内容里包含一个标题,一个段落,也许还有一张图片。如果想使它们全部都可以生成链接,必须使用3个链接元素。于是,得先把光标放在标题(比如说h2元素)中,写一个链接标签,然后再选中所有要包含到链接里的文本。接着,把光标放在段落里,写一个链接标签,然后把段落中的文本放在链接里。
    <h2> <a href="#">标题文本</a></h2>
   <p> <a href="#">段落文本</a></p2>
茌HTML5中,只要简单地把所有内容都写在一个链接元素中就可以了。
<a href=”#”>
    <h2>标题文本</h2>
    <p>段落文本</p>
</a>
    链接包含的都是块级元素,但现在可以用一个元素包含它们。这样,碰到类似的情形,就必须给几个块级元素加上相同的链接,因为这样做解决了一个现实的问题:不必因此重新写代码来支持这种写法。这种写法其实早就存在于浏览器中了,因为早就有人这样写了,当然以前这样写是不合乎规范的。所以说HTML5解决了现实的问题,允许这样写了。
    
 求真务实
    求真务实对于HTML的含义是:在解决那些令人头痛的问题之前,先看看人们为应对这些问题都想出了哪些办法。集中精力去理解这些解决方案才是当务之急。
    HTML5中新的语义元素就是遵循求真务实原理的反映。新增的元素不算多,谈不上无限的扩展性,但却不失为一件好事,尽管数量屈指可数,但意义却非同一般。这些新元素涉及头部( header)、
脚部( footer)、分区(section)、文章(article)等,相信大家都不会觉得陌生。即便不使用HTML5,也应该熟悉这些名称,它们都是曾经使用过的类名,如class=”header”/”head'/”heading”,或
class-”footer”/”foot”。当然,也可能是ID,如id="header"或id="footer"。
     <body>
           <div id="header">...</div>
            <div id="navigation">..S/div>
           <div id="main">...</div>
            <div  id="sidebar">. . s/div>
           <div id="footer">.. .</div>
     </body>
    在HTML5中,这些元素都可以换掉。说起新增的语义元素,它们价值的一方面就是可以用HTML5新增的元素把这些div都替换掉。
    在文档级别上使用这些元素没有问题,但是,假如新增这些元素仅仅是为了取代原来的div,那就没有必要了。

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

    这4个新元素是sectionarticleasidenav,之所以说它们强大,原因在于它们代表了一种新的内容模型,一种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
也都没有问题,因为现在可以把每个内容分区想象成一个独立的、能够从页面中拿出来的部分。此时,根据上下文的不同,这个独立部分中的Hl在整个页面中也许会扮演H2或H3的角色,这取决于它
在文档中出现的位置。面对这个突如其来的变化,也许有的人暂时不能理解,但这才是HTML5中这些新语义标记的真正价值所在。换句话说,现在有了独立的元素,这些元素中的标题级别可以重新
定义。
    文档中可能会包含一个分区,这个分区中可能会嵌套另一个分区,或者一篇文章,然后文章再嵌套分区,分区再嵌套文章、嵌套分区,文章再嵌套文章。而且每个分区和文章都可以拥有自己的HI~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属性来指定不同的视频格式。
    <video>
           <source src="movie.mp4">
          <source src="movie.ogv">
        <object data="movie.swf'>
              <a href="movie.mp4">download</a>
        </object>
     </video>
    土面的代码中包含了4个不同的层次。
      如果浏览器支持video元素,也支持H264,则直接用第一个视频。
      如果浏览器支持video元素,也支持Ogg,那么用第二个视频。
      如果浏览器不支持video元素,就要试试Flash影片了。
      如果浏览器不支持video元素,也不支持Flash,代码中还给出了下载链接。

    总之,无论是HTML5和Flash -个也不能少。如果只使用video元素提供视频,难免会遇到问题。而如果只提供Flash影片,性质是一样的。所以还是应该两者兼顾。
    为什么要兼顾这两种技术呢?假设你需要面向某些不支持Flash的手持设备提供视频,当然希望手持设备的用户能够看到视频了。

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

      最终用户优先
    这个设计原理本质上是一种解决冲突的机制。换旬话说,当面临一个要解决的问题时,如果W3C和WHATWG给出了不同的解决方案,一旦遇到冲突,最终用户优先,然后是作者,其次是实现者,
    再次是标准制定者,最后才是理论上的完满。 理论上的完满,大致是指尽可能创建出最完美的格式。标准制定者指的是WHATWG、W3C等。
    实现者指的是浏览器厂商。作者就是开发人员。用户是第一位的。

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

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





鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

快讯

     京ICP备14042305号

html5star team © 2012-2013 html5星空 Comsenz Inc.

GMT+8, 2019-10-24 05:32 , Processed in 0.088725 second(s), 30 queries .

返回顶部