注:标题比较辛辣,仅为引起注意而已,不代表观点极端。

标识需要整理

新增的大部分标识,包括<header><nav><hgroup><article><section><aside><footer><ruby><summary><rp><output><mark>,增加了系统复杂性、掌握难度,降低了处理效率。

比如:

<section id="xxx">

<div id="xxx">
  1. 很明显,下面的比上面的简单。
  2. 上面所列的标识,大部分是布局用的。原因是原来只需要处理div即可获知整个文档的结构,现在需要多处理几个标识,这些标识和原先的div相互嵌套的话,处理复杂性大幅度上升。也因此,有人说语义化标签可以更方便搜索引擎处理也是很成疑问。

标识数增加,必然导致解析器复杂,影响解析器效率,而且精确性不好,比如本来一个div就可以表示区块,所有div内的渲染都限定在该div内,继承关系简单。而如果多了一个section和div都是负责区块渲染的,那么这段区块渲染代码的继承关系则必然变成 多重继承,虽然引用的代码可能也就一句,但多一句也是多。

虽然,多一个标识,可以逼迫渲染器开发者优化这些新标识,提升效率,但这些标识如果和原先的差别不大的呢?比如同样表示区块。其实要是浮动区块和固定区块倒是需要区分开来,进行优化,比如浮动区块由于需要动态渲染,调用系统的 图形加速,而不浮动的区块,则直接普通图形渲染即可。——这在用canvas做游戏上体现出来这个必要性了:

需要经常性更新渲染的也就一两个层,其他都是普通的图片,一次渲染即可。

——相信做页面分析的人,很早就意识到这个问题了。

<div>

<header>

<section>

<div>

<section>

<section>

<div>

……
  1. 使用div方式,早在21世纪初,就通过dreamweaver和frontpage的战争中获胜,并发展成熟,甚至在后来div+css大行其道。

那么,这种方式有没必要进一步改进呢?有必要,因为在div+css模式下,布局和文内特殊格式之间,都用的div,需要拆分开来,布局仍然用div,文内特殊格式用别的标签,比如<p></span>,但机制应该参考div这种优秀的模式,比如可指定class或id,可以组合出无穷尽的效果。

  1. 部分新增标签 通用性不足的:比如ruby标识,难道在标准中设定所有的注音都要新增一个标识?那标准何时完成?还是用<ruby class="zh">这种方式通用且灵活。

  2. 另外,原先html4的部分标签,有必要清理掉。比如上下标 <sub><sup> ,用label class="sub"即可,比如关于列表的几个标签<ul><ol><dl>,可以统一为一个,然后通过class或者id来控制实现的效果。

总之,多几个规律性不足的语义性标签,会加大了掌握的难度,而且降低了灵活性。

有必要减少一些格式标签,汇总之后,可以获得更大的灵活性,提高学习的效率。

<div class="content" id=""> 用于表示固定的布局
<splash> 浮动区块:需经常更新渲染的区块,和canvas一样调用系统图形加速——也可以就canvas,然后通过class来区分画图和浮动区块。——添加兼容代码,使得canvas应用更广泛。
<label class="sub sup"> 用于表示上下标
<header class="h1 h2 "> 用于表示文档大纲级结构
<p class="abstract" id=""> 用于表示段落:摘要
<span class="" id=""> 用于表示段落内文本的特殊样式
<list class="orderlist" id=""> 用于表示列表
<ruby class="zh"> 用于表示中文注音
<pre class="python"> 用于表示程序语言类别

更大的改进:后台内建机制

改进方法不是在前台的标签,而是后台的处理策略,这方面由于html标准长年的停滞,而改进不大。发展到今天,竟然是通过前台来倒逼后台改进。

html5最终落到实处,对用户和开发者最有用部分或者说最终沉淀下来的话,也就后台策略部分,比如内建调用图形芯片加速,或者内建一个常用的动画,或者内建对多媒体解码器的调用等等。

其他需要改进的

对跨语种的标识支持至今仍没提上日程。

经验教训:

  1. 核心标准应该尽可能小且稳定

    ,这样方便掌握和组合,前台方面尽量不变,但后台方面的改进应该是个持续不断的过程,而不应该标准设立后就停滞。

  2. 标准应该内建扩展方法。
  3. 应该把扩展后的成果作为模板,而不是统一扩展方向为新版本的标准。