标记标签云

最新推荐文章于 2024-11-12 22:56:44 发布

MinistoneNap

最新推荐文章于 2024-11-12 22:56:44 发布

阅读量2k

点赞数

文章标签： class css web html 工作 div

译者序：

Web2.0确实是一个很有意思的东东,有许多新技术,也出现了一些新概念。最近对这个东东关注比较多。昨晚和同学讨论web2.0的自组织方式的问题时，提到了 TagCloud这个问题。虽然早就听说过这个词，也见过它长什么样，但并不知道如何去设计和组织它，也不知道该如何去评价标签云的好坏。在网上搜集了一下资料，发现了 “给你朋友留下深刻印象的 24 种方式”这个站点上发现了一篇好文章，觉得很有意思，于是就将其翻译出来。由于是第一次做这种翻译，并且涉及到一些专业术语和技术问题，有不妥的地方还望多多指教，我将努力修正。当然，如果你觉得翻译得还不错，想转载一下的话，请注明本翻译的 出处和链接，毕竟是本人的劳动成果哈。

在翻译本文的过程中，由于笔者知识面狭窄，对一些专业术语并不怎么了解，查阅了一些资料查弄明白。为了方便大家的阅读，我把相关术语的解释列于此处。

Anchor ：锚点，可以理解为超文本的链接点。在HTM文档中，通常会对某些对象来设置超链接，被设置超链接的这个地方称为锚点，例如一个词组或一张图片的某一部分等，点击锚点可以返回锚点对象的引用。

Accessibility ：可获得性，是使残疾人更容易地使用应用程序的惯例。例如 1990 年的美国残疾人法案（The American Disabilities Act）、1996 年的电信法案（The Telecommunications Act）、1998 年的康复法案修正案（Rehabilitation Act Amendments）508 条款、万维网联盟（W3C）的 Web 可访问性倡议（Web Accessibility Initiative(WAI)），这些都是可获得性标准。

Screen Reader ：屏幕阅读器，是为视觉上有障碍的人设计的读取屏幕内容的程序。

Class ：类，包含多个标签元素。

译文：

原作者： Mark Norman Francis 原文标题：Marking Up a Tag Cloud

人人都在做标签云，但问题是，人人都做错了。你或许认为这些话很刺耳。虽然有一些相当好的标记存在，但是在这个领域，它的罪恶也是很多的。你知道，在某种程度上，我是一个标记和语义的痴迷者。因此，我将会分析因特网上的一些比较著名的标签云，解释什么是错误的，然后告诉你一种更好的标记标签云的方式。

del.icio.us

我认为我曾经看到的第一个标签云是在 del.icio.us上。下面的代码显示了他们的标记方式。

<div class="alphacloud">

<a href="/tag/.net" class="lb s2">.net</a>

<a href="/tag/advertising" class=" s3">advertising</a>

<a href="/tag/ajax" class=" s5">ajax</a>

</div>

来源: /code/marking-up-a-tag-cloud/delicious.txt

不幸的是，这是我所见到的所有标签云中最差的一个。这个页面中声明，标签云是标签的列表，标签的大小反映了流行度。然而，尽管该页面的作者用这种方式向人类阅读者描述，但却没有用这种方式在标记中描述。那根本不是一个标签的列表，只是<div>中的一束锚点。这样做是没有 可获得性 的，因为一个屏幕阅读器不会在相邻的链接间停顿，并且在一些配置中，它不会广播（指的是读出声音来报告给残疾人阅读者）单个的链接，而是将所有的标签作为包含整个词束的一个链接读取。这是标记的第一宗罪。

Flickr

啊，Flickr。因特网上亲爱的相片共享网站，也是所有标准视觉的最大盲点。原谅它那些残暴的标记和偶尔混乱的用户界面吧，因为我们可以对它开太多带有谴责的玩笑。让我们来看看他们是怎么做的吧。

 <a href="/photos/tags/06/" style="font-size: 14px;">06</a> 

 <a href="/photos/tags/africa/" style="font-size: 12px;">africa</a> 

 <a href="/photos/tags/amsterdam/" style="font-size: 14px;">amsterdam</a> 

来源: /code/marking-up-a-tag-cloud/flickr.txt

再一次，这是一个del.icio.us一样的一个简单的锚的集合，只不过这次是在一个段落中。但是它不是用一个类来代表标签的大小，而是使用了一个行内样式。行内样式使用的是基于象素的字体大小尺寸。他们或许会使用这个标签，这远远达不到将样式从内容中分离出来的目标。理论上，你可以对其进行分析以抽取信息，但是为了猜测象素大小所代表的含义你还需要做更多的工作。这是标记的第二宗罪。

Technorati

啊，现在。对于这个网站，你将会期望看到一些相当好的东西。毕竟，微格式（ microformats）的霸主和语义 Tantek Çelik 之王在那里工作。那我们真的可以在这里看到一些相当好的东西吗？

<ol class="heatmap">

<li><a href="/tag/Britney+Spears">Britney Spears</a></li>

<li><a href="/tag/Bush">Bush</a></li>

<li><a href="/tag/Christmas">Christmas</a></li>

...

<li><a href="/tag/SEO">SEO</a></li>

<li><a href="/tag/Shopping">Shopping</a></li>

</ol>

来源: /code/marking-up-a-tag-cloud/technorati.txt

不幸的是，最后证明它还不是那么的好，所以不要再叫我乌鸦嘴了。那些并不完全是极差的代码。它将一个标签云认为是一个链接的列表，而且，因为他们是字顺表，是一个有序的链接列表。那很好。然而。。。15个嵌套的标签？15？那是对你表示强调。是的，它是可分析的，但是又是一种看起来比较奇怪的强调重点的方式。这种HTML格式说明， 是强调的重点，而那个是更加强调的重点。嵌套标签看起来与原来的将不同层次的重点的标签区分出来的想法是相背的。另外，如果你的屏幕阅读器在重点内容上发重音的话，将会发生什么事？对你大喊大叫？这是标记的第三宗罪。

那到底应该怎样呢？

就象del.icio.us所告诉我们的一样，一个标签云是一个标签的列表，标签云的大小包含着额外的信息。然而，通过用CSS或HTML标签完全隐藏这额外的语境，对于某些用户来说，你这是拒绝向他们提供语境。因为其基本假设前提是，所有的用户能够看出字体大小的不同，然而这却是错误的。

对标签云编码的一种好一点的方法是，将标签云的语境放在内容中，而不仅仅是单纯的标记或CSS。例如，以我喜欢的 flickr 标签为例，我将他们放在一个能够传递每个标签的相对频率的云中。

开始制作一个标签云的最基本的方式是将其作为一个链接的列表。我将它们按字顺排列展示，所以我用的是一个有序列表。在每个列表项中，我向相对应的标签中添加相片的数量。标签本身则链接到包含那些相片的flickr页面上去。现在我们以第一个例子来结束标签云的制作过程。在这个例子中，为了以一种传统标签云的方式来显示它，我们需要做以下几个变换：

列表项应当相互相邻显示，而不是在一个单行中；

语境信息应当被隐藏，而不能将其显示出来（但不能对屏幕阅读器隐藏）；

标签应当链接到包含那个标签项的页面。

将列表项相互相邻显示仅仅意味着设置列表元素显示为内联的。语境信息用包装，然后用 off-left方法来隐藏。这种链接仅仅意味着增加一个锚点。所以，现在在我们的第二个例子，我们有了一个简单的链接的集合。

最后一步是添加大小尺寸。因为我们已经在内容中有了语境，尺寸纯粹是为了可视化的任务，所以我们可以仅仅用类来定义不同的尺寸。在我的例子中，我使用了有一定范围的类名，如从不流行（not-popular）到过于流行（ultra-popular），从最小到最大等，然后用CSS来定义不同的字体大小。如果你愿意，你可还以使用一些不那么冗长的类名，例如从size1到size6。不管怎样，增加类和CSS给我们一个语义的和更加可获取的标签云，如我们最后一个例子所示。

谢谢您阅读完此日志，为了支持日志原创和外文翻译，请点击右边广告，给我带点薄利，在此先行谢过。