W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > May 2013

(wrong string) 連署支持 HTML 版 ECMAScript 5 規範

From: John Hax <johnhax@gmail.com>
Date: Mon, 27 May 2013 14:09:34 +0800
Message-ID: <CAEeYXHXMpbuowz-NUv8+sBxSYuVKcqD4G6_dpXN=MqEVsUkneg@mail.gmail.com>
To: jobinson <jobinson99@gmail.com>
Cc: (wrong string) 興趣小組 <public-html-ig-zh@w3.org>
@jobinson

首先你回错主题了。


然后你针对html5的批评,我讲一点我的意见:
1. 对于header/footer/section/article等结构标签的批评之前也是有的,可能有一点道理,但是属于少数派意见。
2. 你没搞清楚ruby标签的意思。此ruby并非是指Ruby编程语言,而是指对于正文的附注(比如注音、拼音)。
3. 你对通用化的看法与html5的设计原则相背(我不说你是“错误”的)。所增加的标签是为了更好的match大多数的use
cases。你可以单独说某一个标签不合理,原因是没有那样的use case,或者应该捕捉的use
case没捕捉到。但是说完全退回用class,这违背了html5的设计原则。而且,你只考虑“效果”,我感觉你也完全没有理解html一直以来强调语义化的原因。
4. 不清楚你讲的跨语种标识是指什么。如果是指对人类语言的标识,用lang属性即可。
5. “核心标准小且稳定”,这是关于标准如何设计组合的问题,一句话讲不完,有些人是有这样的批评,不过我个人觉得纯属站着说话不腰疼。

总之,有意见想法都很正常,但是希望你先能搞清楚html5为什么会是这样,然后再提意见会比较有针对性。


2013/5/26 jobinson <jobinson99@gmail.com>

> 【反思】部分html5走火入魔
> 注:标题比较辛辣,仅为引起注意而已,不代表观点极端。
>
>
>
> 新增的大部分标识,包括<header><nav><hgroup><article><section><aside><footer><ruby><summary><rp><output><mark>,增加了系统复杂性、掌握难度,降低了处理效率。
> 比如:
>
> <section id="xxx">
>
>
> <div id="xxx">
>
> 1、很明显,下面的比上面的简单。
>
> 2、上面所列的标识,大部分是布局用的。原因是原来只需要处理div即可获知整个文档的结构,现在需要多处理几个标识,这些标识和原先的div相互嵌套的话,处理复杂性大幅度上升。也因此,有人说语义化标签可以更方便搜索引擎处理也是很成疑问。
> ——相信做页面分析的人,很早就意识到这个问题了。
>
> <div>
>
> <header>
>
> <section>
>
> <div>
>
> <section>
>
> <section>
>
> <div>
>
> ……
>
>
>
> 3、部分是通用性不足的:比如ruby标识,难道在标准中设定所有的编程语言都有一个标识?那标准何时完成?还是用<pre
> class="ruby">这种方式通用且灵活。
> 4、使用div方式,早在21世纪初,就通过dreamweaver和frontpage的战争中获胜,并发展成熟,甚至在后来div+css大行其道。
>
> 那么,这种方式有没必要进一步改进呢?有必要,因为在div+css模式下,布局和文内特殊格式之间,都用的div,需要拆分开来,布局仍然用div,文内特殊格式用别的标签,但机制应该参考div这种优秀的模式,比如可指定class或id,可以组合出无穷尽的效果。
> 另外,原先html4的部分标签,清理掉。比如<sub>
> ,比如关于列表的几个标签<ul><ol><dl>,可以统一为一个,然后通过class或者id来控制现实的效果。
>
> 5、总之,多几个规律性不足的语义性标签,加大了掌握的难度,而且降低了灵活性。减少一些格式标签,汇总之后,可以获得更大的灵活性。
>
> 6、改进方法不是在前台的标签,而是后台的处理策略,这方面由于html标准长年的停滞,而改进不大。发展到今天,竟然是通过前台来倒逼后台改进。
>
> html5最终落到实处,对用户和开发者最有用部分或者说最终沉淀下来的话,也就后台策略部分,比如内建调用图形芯片加速,或者内建一个常用的动画,或者内建对多媒体解码器的调用等等。
>
> 7、对跨语种的标识支持至今仍没提上日程。
> 8、经验教训:核心标准应该尽可能小且稳定,这样方便掌握和组合,前台方面尽量不变,但后台方面的改进应该是个持续不断的过程,而不应该标准设立后就停滞。
> 标准应该内建扩展方法。
> 应该把扩展后的成果作为模板,而不是统一扩展方向为新版本的标准。
>
> --
> 此致敬礼
> 黑传说
> sincerely, jobinson
> email:jobinson99@gmail.com
>
Received on Monday, 27 May 2013 06:10:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:51 UTC