W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > September 2010

一些意见和proposal

From: John Hax <johnhax@gmail.com>
Date: Wed, 8 Sep 2010 02:02:09 +0800
Message-ID: <AANLkTi=D37Qqx=h6W8YY2u3=7jE3fxXz+hhbf6Np30Vu@mail.gmail.com>
To: (wrong string) 樂會ML <public-html-ig-zh@w3.org>
这是我目前想到的一些跟HTML和CSS有关的意见和proposal,其实有些可能应该用英文写直接发到各个讨论列表里,不过我英文差,又懒啊。先用中文写出来,大家看看。

一、CITE标签的用法

如之前所提到的,社区在讨论是否要扩展CITE标签的用法,从单纯的书名扩展为可以mark人。具体的讨论见:
http://wiki.whatwg.org/wiki/FAQ#The_.3Ccite.3E_element_should_allow_names_of_people_to_be_marked_up
http://wiki.whatwg.org/wiki/Cite_element#opinions

我坚定地反对这个动议。

反对意见如下:

1.
创制标签的原意是标记书而不是人。尽管在HTML5的设计思路是将常见的用法给标准化下来,但是必须有一个限度。一个标签用于两个完全不同的语义是不妥当的。

比如<p><cite>黑猫警长</cite>很好看。</p>,我们就知道这是指《黑猫警长》这部动画作品很好看,而不是“黑猫警长”这个角色长得很好看。即使大陆以外的人不知道这部作品,至少知道这是指一个作品而不是一个人物。当然,作品本身会有歧义,比如是指原版动画片还是新的电影版,抑或是漫画版。但是这种歧义比将作品误解为人物角色要次要得多。

2.
以我的经验,CITE标签本身就用得很少。社区有足够的数据能支持“许多人都这样用CITE”的说法吗?如果用CITE标签的人本来就只占HTML作者的0.01%,其中就算有50%的人会误用CITE去标记人,也不能构成应该鼓励这种用法的地步。相反的反例是b/i标签。这两个标签可能有99%的HTML作者都会使用,因此b/i的实践用法才有价值被标准化下来。

3.
CITE标签的改变没有考虑国际化。根据这里代表的中文社区的经验,CITE首先用得很少(我只看到过个位数次的使用,且属于完全的误用,即差不多是在Q的意义上使用),尤其没有看到类似英文世界的用来标记人的做法。主要原因除了CITE标签本身知名度不高,可能是中文用户习惯使用标点符号书名号来标记书,没有像英文用户那样去针对CITE做出样式区分的需求。将CITE扩展到可以标记人,对于中文用户来说,就更不能理解这个标签的意义了,因为我们从来没有经验是在这两种意义上混合使用它。而且对于标记作品和标记人,在中文是完全不同的。本身英文中书名是斜体,人标为斜体不合常规,但是至少不是很大的问题。但是对于中文来说,CITE的样式要被用来附加书名号(无论是横排中的《》或直排中的波浪线),用在人上就不是不好看的问题,而是完全错误的问题。

4. CITE同时标记书和人,引起UserAgent提供额外功能的困难。
比如考虑亚马逊的书库,imdb的电影库,wikipedia的词条库……某种浏览器可以根据cite上的内容,比如<cite>黑猫警长</cite>,来提供给用户额外的功能,比如直接引用到douban的词条、或imdb的评分。但是允许CITE也用来标记人,就使得这样的功能可能变得很糟糕。


二、cite标签需要一个uri属性

目前CITE标签上没有任何一个link类的属性,而标记作品其实需要这样的属性,如:
<cite uri="urn:isbn:9789573327103">雷峰塔</cite>
这个URI标识了这本书是张爱玲的《雷峰塔》,皇冠文化2010年9月出版的版本。
又如
<cite uri="http://www.imdb.com/title/tt0926084/">哈利·波特—死亡圣器(上)</cite>
<cite uri="http://www.imdb.com/title/tt0926084/">哈利波特—死神的聖物(上集)</cite>
虽然写法不同,但是因为引用了相同的imdb链接,我们知道实际上说的是一部作品。

属性名的可能候选包括:cite、href、src、uri、urn等
cite是XHTML2的做法,不过写成<cite
cite="...">实在有点难看。href和src在现在的实践中都是指实际要获取资源的,而cite上的uri其实首要是用来标识的。urn限定必须是urn,好像没有什么特别意义。因此最终我提议用uri作为属性名。


三、CSS3 selector [att~=val] 的问题

[attr~=val]是attr为空格分隔的词中包含val。按照现在的规定Val本身不能含空格,如果含空格是不可能match的。

建议修改这个行为,如果val包含空格,则表示attr的词列表中包含任意一个val中空格分隔的词

为什么有这个提议,考虑如下case:

我为几种不同的链接点设计置于链接之前的图标样式:

a[rel~="external"]::before { content:url(external.png) }
nav a[rel~="prev"]::before { content: url(prev.png) }
nav a[rel~="next"]::before { content: url(next.png) }
nav a[rel~="first"]::before { content: url(first.png) }
nav a[rel~="last"]::before { content: url(last.png) }
nav a[rel~="up"]::before { content: url(up.png) }

如果需要对rel="external next"(同时包含两种关系)定义样式,可以这样:
nav a[rel~="external"][rel~="next"]::before { content:url(external-next.png)
}
还是挺简单的。

但是如果需要对所有导航链接做统一样式(假设都是圆角边框加相同背景图上叠放不同的箭头指示),就麻烦了:
nav a[rel~="prev"]::before, nav a[rel~="next"]::before, nav
a[rel~="first"]::before, nav a[rel="last"]::before, nav a[rel~="up"]::before
{
  border-radius: 4px;
  background: url(nav-link-bg.png)
}

注意到这个selector序列会非常冗长(复杂的情况下会更长到不可思议),而且不幸的,很容易写错而且很难看出来(各位能看出来我哪里写错了吗?)

如果还需要和external组合?就需要再复制一份。
nav a[rel~="prev"][rel~="external"]::before, nav
a[rel~="next"][rel~="external"]::before, nav
a[rel~="first"][rel~="external"]::before, nav
a[rel="last"][rel~="external"]::before, nav
a[rel~="up"][rel~="external"]::before {
  background: url(external-nav-link-bg.png)
}

假设这个时候,我发现我漏掉了index和search类型,要再添加进去?我疯了。。。


这时候如果支持前述定义,就可大大简化了:

nav a[rel~="prev next first last up"]::before {
  border-radius: 4px;
  background: url(nav-link-bg.png)
}
nav a[rel~="prev next first last up"][rel~="external"]::before {
  background: url(external-nav-link-bg.png)
}

以后我要加上其他的如index和search支持,也非常直观:

nav a[rel~="prev next first last up index search"]::before {
  border-radius: 4px;
  background: url(nav-link-bg.png)
}
nav a[rel~="prev next first last up index search"][rel~="external"]::before
{
  background: url(external-nav-link-bg.png)
}

而且从CSS原理上说,这样的selector比前述5个(后来要7个)逗号分开的selector要简单高效。


以上。
Received on Tuesday, 7 September 2010 18:02:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 September 2010 18:02:43 GMT