我們這次來討論hAtom微格式,這個微格式用來為網頁內容添加結構和語義從而使得網頁內容或者局部內容可以被廣播(syndication),比如博客日志或者新聞文章等。
hAtom微格式是建立在Atom XML同步格式基礎之上的。跟之前hCard和hCalendar不同,hCard和hCalendar都和傳統數據格式有著1:1的對應關系,但是hAtom同Atom之間卻沒有這種直接的對應關系。Atom是一個很穩定的模型,能夠為內容廣播提供非常多的功能。而hAtom僅僅是提供必須的元素,因此更像是Atom的子集。由此說來,hAtom具有的屬性和子屬性也都是基於Atom原有的術語而來的。
盡管hAtom基於Atom,hAtom本身並不是一個廣播格式。hAtom的作者和編輯──David Janes──解釋說:
“… hAtom was never intended to be a “syndication format” nor to compete with Atom or RSS. It’s simply designed to describe the microcontent on webpages, such as blog posts. We used Atom because it provides a well-defined nomenclature for describing such elements.”(譯:hAtom從來都不是為了作為“廣播格式”存在,更不是為了同Atom或者RSS之間競爭。他就是用來描述網頁中的為內容,比如博客日志。我們使用Atom是因為他提供了很好的術語可以描述這樣的元素。)
所以,hAtom不是專門為了那些需要廣播的網頁內容的。不過,為了這篇文章的目的,我會在博客日志的基礎上討論,而博客日志通常是需要支持廣播的網頁內容。
在討論hAtom細節之前,讓我們來看一下基礎的規則(同hCard和hCalendar類似):
還是,對所有微格式適用:包含他們的標記元素是什麼不重要(雖然應該是有效並且具有語義的)。Class的值(屬性或子屬性)決定了hAtom微格式。
如果您選擇使用hAtom,同樣應該在網頁的<head>代碼中加上他的Profile說明:
<head profile=”http://purl.org/uF/hAtom/0.1/”>
對hCard和hCalendar,我提過使用組合Profile,可以覆蓋所有非提案微格式:
<head profile="http://purl.org/uF/2008/03/“>
不過,hAtom是提案規范,他的Profile沒有涵蓋在組合Profile裡面,所以,還是需要明確的指明他。如果您還引用組合Profile,可以簡單的添加hAtom Profile(W3C 允許 多個profile值,使用空格隔開即可):
<head profile="http://purl.org/uF/2008/03/http://purl.org/uF/hAtom/0.1/“>
背景信息差不多了,現在我們來看實際的hAtom,下面的hAtom信息是描述我的博客日志全文的:
hAtom的根屬性是hfeed,他可以包含一個或者更多條目(在上面例子上,條目就是博客日志)。這個根屬性是可選的。如果沒有明確包含根屬性,默認假設他已經存在於頁面中了,上面的例子中就沒有包含根屬性。如果必要的話,頁面中可以包含多個hfeed。
每個條目必須包含在hentry屬性中。如之前提過的,可以應用一個或多個hentry屬性。上面例子中,只有一個hentry是因為這個實現是應用在顯示博客某一日志全文的頁面中。我會在文章後面討論如何使用多個條目。
hentry屬性包括了條目的所有信息。
entry-title是必需的子屬性之一,用來說明條目的題目。在上面例子中,我為<h3>應用了entry-title屬性,因為作為題目,把他放在“頭條”結構中是具有一定語義信息的。
author是另一條必需的子屬性,用來說明條目的作者。根據規范說米功能,包含在author子屬性中的內容必須使用標記上hCard的<address>元素。
但是,也還有很多實際操作的例子中,發布者並不在意列舉出作者名字,包括我的博客。hAtom的規范默認了這種情況並允許可以不在hentry屬性中包含作者信息,不過是在當頁面本身已經包括了hCard的信息,並含有指定class="author"子屬性的<address>元素。這個方案也在hAtom 的FAQ中作了解釋。
因為我在我所有頁面的頁腳中都包括了hCard實現,所以,我沒有在hAtom信息中包含author子屬性,這樣做是有效的。對於那些多作者協作的博客,如果他們不希望顯示作者名字,目前還沒有有效的方案。author必須出現在hentry屬性中。我可以想象使用CSS方案來取消顯示(display:none)可能也是可以接受的。
上面的討論涉及到另外一個問題:實現hCard時使用<address>。
在第三部分討論中曾經提到過,為hCard使用<address>元素只有在hCard是文檔擁有者時才有效。hCard的FAQ中也強烈建議不要在hCard不是文檔擁有者時候使用<address>。因此,如果hAtom的條目由不是文檔擁有者創作的話,<address>不是合適的語義元素。
這個問題目前還在討論中。目前的建議是取消<address>的限制。
updated子屬性也是必需的,他表明條目最後被修改和更新的日期/時間。這裡也有需要注意的事情:如果updated子屬性沒有被定義,子屬性published將會用來表明日志更新的日期/時間。在上面的例子中,您會注意到我並沒有包含updated子屬性,不過使用了published。
published是可選的子屬性,基本上同updated的語義是一致的,都是表明條目的更新時間。盡有的區別在於,published更傾向於描述條目第一次發布的時間,而updated可以是發布的時間或者是條目後來更新的時間。如果同時包含published和updated來描述條目的日期時間信息也是有效的:
<abbr class="published updated” title=”2008-08-28T13:14:37-07:00″>Aug 28, 2008</abbr>
在我的例子中,僅僅使用published就符合我的目的了,所以我選擇只使用他。
對於updated和published,hAtom推薦使用的時間和日期格式跟我們之前討論的日期時間設計模式相同:
<abbr class=”published” title=”2008-08-28T13:14:37-07:00″>Aug 28, 2008</abbr>
該模式定義容器元素為<abbr>,在title屬性中指定機器可讀的日期/時間信息,而在內容中指定人類可讀的日期/時間信息。而且,在title中包含的時間日期信息應該遵循ISO 8601格式要求。
entry-summary是可選的子屬性。他說明條目的摘要信息。這個子屬性可以在hentry中多次使用。在我的博客中,我沒有為文章生成這樣的摘要,所以我沒有提供這個子屬性的實現。
entry-content是另一個可選的子屬性,用來說明條目的全文內容。在上面的例子中,所有的文章內容都被包含在<div class="entry-content">元素中。同樣,可以在hentry中使用多次entry-content屬性。
hAtom還定義了一個rel屬性值來說明條目的永久鏈接:bookmark。在第一部分中,我們討論了很多基於rel-的微格式,用來表明鏈接(<a>)和文檔之間的關系。rel-bookmark也是用來描述鏈接關系的,不過不能作為微格式單獨使用。必須作為hAtom的屬性存在,描述文檔內容的永久鏈接。
使用hAtom,您可以簡單的在條目的永久鏈接上添加rel="bookmark":
<a href="http://www.ablognotlimited.com/articles/web-Accessibility-is-important/" rel=”bookmark”>Web Accessibility Is Important</a>
您可能會注意到,在我的例子中沒有提供永久鏈接。這是因為我通常遵循一條規則:不在頁面中提供本文鏈接(NIElsen’s #10 of the Ten Most Violated Homepage Design Guidelines)。而且因為rel-bookmark是可選的,所以我的實現是有效的。如果hentry沒有指明永久鏈接,那麼就會缺省認為本頁鏈接為條目永久鏈接。如果hentry中定義了id屬性,該值會被拼接到URL後面來為條目定義唯一值。
之前我們在第一部分中討論過rel-tag 微格式。他用來添加到鏈接(<a>)) 說明網頁──或者網頁的局部內容──是關於什麼內容的。基本來說,通過標簽來組織/分類已經在博客中廣泛使用。hAtom可以充分發揮rel-tag的作用,只需要在hfeed和hentry中做出實現:
在前面的例子中,我在hentry中使用了rel-tag鏈接:
<p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentarIEs/” rel=”tag”>CommentarIEs</a></p>
<dd><a href="http://www.ablognotlimited.com/articles/tag/web+design/”rel=”tag”>web design</a></dd>
注意就是rel-tag規范中要求鏈接目的地址(href)中必須包括“標簽”的值作為URL的最後一段,這被設計為“標簽空間”。
上面已經討論了hAtom的大部分細節,應該給出一個例子說明如何應用在多日志的頁面中。在我的博客上,在首頁中添加了hAtom信息,用來描述我最近的三篇日志:
在這個例子中,我使用了多個hentry實例,每一個用來描述一篇日志。並且,我為每一篇日志都指定了永久鏈接,因為他們並沒有指向當前頁面。除了上出兩個不同之外,hAtom基本上跟我之前的例子是一樣的。
除了我上面的兩個例子,還有很多可以實現hAtom的頁面:
我正在考慮在存檔和搜索結果頁面中實現hAtom(還包括評論頁面,因為那裡需要hCard實現)。
在這個系列中提及的微格式中,hAtom是最難的一個。我個人覺得這是因為這個微格式還是一個提案狀態的規范。不過,我遇到的實現困難還都是很小的,不過也有點小挫敗:
所以,從個人角度,我認為畢竟他還處於提案狀態,還需要被修改和討論。但我並不認為就不去實現hAtom,最起碼也可以先熟悉熟悉他。只要注意他還在提案狀態就可以了。
雖然前面提過現在支持hAtom的工具和資源還很少,我們還是可以列舉一些:
盡管hAtom是提案規范,但是還是有很多服務提供支持:
還有更多實際的hAtom支持。
我想hAtom最酷的一個好處就是他為XHTML廣播帶來的潛力。在工具和資源列表中,我提到了幾個轉換器,他們利用XSLT把帶有hAtom的XHtml轉換為XML,從而提供Atom或者RSS的源。這意味著不需要再為了廣播去生成或者維護單獨的Atom或者RSS的XML文件。簡單的利用hAtom和這些轉換器就可以完成廣播XML的自動生成。
自己試試吧。需要做的僅僅是在包含hAtom信息的URL前面拼接這些轉換器(http://transformr.co.uk/hatom/):
<a href="http://transformr.co.uk/hatom/http://www.ablognotlimited.com/“>Atom feed for A Blog Not Limited</a>
產生的鏈接會自動生成Atom格式的XML:
我還沒有為我的站點實現這個轉換,因為我使用自定義的RSS源。不過這些轉換器絕對在我的實驗列表中。
您不會認為我忘了這點吧?
借助於已有的標准(XHtml元素和屬性),微格式為網絡內容添加結構和語義。語義能夠同時幫助人類和機器來處理、搜索和理解互聯網。微格式鼓勵您使用互聯網標准……標記內容的標准化方法,應用class信息,還包括開發的正確流程。
語義很棒。標准很棒。微格式很棒。
譯注:Syndication翻譯為“廣播”不知道合適不合適,以前一直提RSS,但是還真從來沒想過或者查過如何翻譯合適。