微格式 的概念最初出現於二十年前，那時它是一種把豐富語義嵌入主格式（如 HTML/XHTML 和 Atom）的方法。HTML 無法直接表示聯系人信息，但是一種叫做 hCard 的微格式允許我們把 Html 中平常的 divs 和 spans 轉換成結構體，用以指定聯系人姓名、街道地址、郵政編碼等信息。微格式內部的一些基本思想是相當合理的，不過它的作用被大肆誇大了，以致於人們有些時侯不會去考慮微格式的適用范圍和適用緣由。微格式應該成為一個可用於在 Web 上表示豐富內容的工具，並且應該補充（而不是替代）一些其他的此類技術，例如 Web 上的 XML 甚至 Ajax。這篇文章旨在介紹微格式的適用范圍，以及一些值得重點注意的地方。
細微差別和害處
微格式最擅於在某個主體語言（如 HTML、XHtml 或 Atom）中對一些通常的結構加入少量細微的差別。rel-license 就是一個例子，它允許我們表示出一個鏈接，並且通過這個鏈接能識別出源頁面內容的用法許可。鏈接 <a href="http://creativecommons.org/licenses/by/2.0/" rel="license">cc by 2.0</a> 不論位於頁面何處都意味著頁面的內容在 Creative Commons 2.0 Attribution Required 許可下可用。我曾經看到有人濫用過這種微格式，他們為某個頁面所描述的軟件（而不是為頁面本身）聲明了一個許可，但是我們並不能為此就去真的責備微格式的開發人員。 還有一點更突出的問題，就是此類約定有可能會產生沖突，不過對於大部分情況，微格式都會忽略此類問題，它期望輕量級協議能在問題剛出現的時候就及時地解決它們。像 rel-license 這樣的微格式對一個 Html 屬性的用法提供了約定，該屬性用於支持這種約定。其約定不過是在主體語言詞匯的此類結構中提供了一些細微的差別，我把這種微格式稱為具有細微差別的微格式（nuance microformats）。其中大部分是微格式開發人員所稱的基本微格式（elemental microformats），基本微格式就是完全在某個元素內部構造而成的微格式。
一些微格式試圖把專有的結構嵌入到主體語言的結構中去。我把這些微格式稱作有害的微格式（nuance microformats）是因為它們在一些方面是相當有害的，不過在這篇文章中我將會使用微格式開發人員所采用的一種比較中立的術語：復合微格式（compound microformats）。 XOXO 就是一個很好的例子，它是一種用於表示概要的微格式。您可能會設計一些 XML 來替代 XOXO，因為 XOXO 要遠比這些 XML 難於理解和處理。當然，XML 是設計用於表示復雜的和專有的內容結構的，而且它似乎倒退了一步，使用表現力更弱的結構卻只是為了在 HTML 中嵌入這些結構。微格式開發者這樣做的原因是他們感到 XML 太復雜了，而且還不夠普及，更重要的是 XML 並不允許適度的降級，這意味著微格式對不懂 XML 之類比較高級的技術的用戶代理來說就像是常規的 Html。這是相當站不住腳的說法，其部分原因是現在大部分的用戶代理都可以支持 XML，還有一部分原因是有的時候一個可伸縮的 Web 設計是值得這樣的代價和麻煩的。盡管那時一些其他的 RSS 語言已經普及，但是後來還是開發了 Atom，一種更佳的 Web 提要格式。盡管對於懶惰的 Web 發行人員來說，使用 font 和 center 標記會更加地輕松和方便，甚至嘗試應用 CSS 的 Web 開發人員在開發過程中遭遇了浏覽器所帶來的困難和阻礙，但是他們還是開發出了層疊樣式表（Cascading Stylesheets，CSS）用於將 Web 頁面中的內容和表示分離開來，盡管留下了很重的負擔，但是這兩種技術都表現良好，而遺留問題不過是糟糕的微格式設計的可憐借口。
不要忘記了超文本
Web 日志是微格式的一個熱點用例。其想法是作者使用 hAtom 標出條目，使用 XOXO 實現 blogroll，使用 rel-license 指定許可，並使用 hCard 內聯聯系人信息，等等。微格式提供了一種更簡單的方式，即通過更新 Weblog 引擎模板在經過改變少量結構的表單中發布所有這些數據。同時，適度的降級功能也使得 Weblog 受益不少，因此即便讀者沒有支持微格式的軟件，他們也仍然能夠直接閱讀這些信息。
這些聽上去都很合理，但是它也可能忽略 Web 的基本價值。Html 支持把普通的文字組織到頁面中。我們使用鏈接把頁面連接在一起。使用到一些對象（如圖像、樣式表之類的）的鏈接表示特殊的數據。如今這種方式運行地很好。我們沒有什麼理由不表示地址簿，Web 提要及類似的數據，這些可以通過鏈接到 XML 文檔來完成。XML 支持半結構化的數據。有時，XML 並不是最合適的數據格式。對於高度結構化的數據，JavaScript 對象表示法也許（JavaScript Object Notation，JSON）是更好的選擇。無論如何，上述每一項技術對於其擅長的領域都易於使用，並且仍然能夠對 Web 浏覽器、甚至移動浏覽器技術保持最大的兼容性。
我准備先從 hAtom 開始介紹，因為很明顯它在 Atom 中可以使用 XML 替代方案。其中已經有了一個 XML 形式的 Atom。它得到了健康的發展和支持。甚至約定了從常規 Web 頁面到 Atom 提要的鏈接：
<link rel="alternate" type="application/atom+XML" title="BobSutor's blog feed"
href="/developerworks/blogs/rss/BobSutor?flavor=atomdw" />
添加這種提要鏈接比起在 hAtom 中的各種循環中來回跳轉要簡單得多。任何有可能對 hAtom 提供支持的 Weblog 軟件甚至更有可能支持純 Atom。大多數搜索引擎都為有鏈接的 Atom 文件編制了索引，就和頁面本身編制索引一樣樂此不疲。搜索引擎軟件能通過 Web 提要鏈接約定（自身內部的一種微格式）知道如何解釋鏈接的 Atom 文件。並且對於那些文字 Web 工具和服務，Atom 比 hAtom 更易於解析和處理。我們能獲得更多嚴格的 XML 語法並且無需使用一個含兩個語義層的堆棧就可以使用 hAtom。盡管事實上比起有細微差別的微格式來說更像是有害的微格式，但是正確的 XML Atom 還是有優勢的。
樣板文件還是內聯內容？
我們繼續學習 XOXO 例子中 Weblog（aka "blogroll"）相關的列表，本例中的 XML 標准並不像 Atom 中那麼顯而易見。把 XOXO 插入 Weblog 是相當容易的事情，因為 blogroll 通常並不是條目內聯內容的構成部分，而是整體 Weblog 模板樣板文件的一部分。清單 1 是 XOXO Blogroll 的一個例子：
清單 1. XOXO blogroll 的例子
<ol class="xoxo">
<li>
<p>My favorite Weblogs</p>
<ol>
<li>
<a href="http://example.com/bud/" type="text/Html">Buddy blog</a>
<a href="http://example.com/bud/atom" type="application/atom+XML">Buddy feed</a>
<dl>
<dt>description</dt>
<dd>My buddy's Weblog</dd>
</dl>
</li>
</ol>
</li>
</ol>
真的，我無法用其他方法來演示 — 這太可怕了。十個元素所完成的任務對於任何合理的 XML 格式來說只需四個或五個元素就夠了（無格式的 HTML 中也只需六個元素）。清單 1 是 XOXO 的一個簡化的例子。我曾經見過很多更復雜的例子。此處的問題是在濫用 Html 表示 blogroll 的語義的過程中，XOXO 引入了復雜性並增加了出錯的風險。並且難以測量收獲。某個作者可能會使用清單 2 中的示例樣板文件來表示 blogroll：
清單 2. 無格式的 Html blogroll 例子
<div class="blogroll">
<h3>My favorite Weblogs</h3>
<ol>
<li>
<a href="http://example.com/bud/" type="text/Html">Buddy blog</a>
(<a href="http://example.com/bud/atom"
type="application/atom+XML">Buddy feed</a>): My buddy's Weblog
</li>
</div>
這非常易於效仿，並且不會造成混淆或者錯誤。
即使用 JSON 也能完成任務
相對於 XOXO（清單 1）來說，無格式 Html 例子（清單 2）的一個不足之處就是 blogroll 的結構不適合機器閱讀。要解決這個問題，需要提供一個到結構化的 blogroll 數據的鏈接，它畢竟只是一個鏈接的集合。該數據是高度結構化的，並且服從除 XML 之外的一切數據格式，包括 JSON。清單 3 是 JSON Blogroll 的一個例子：
清單 3. JSON blogroll 數據的例子
[
{"blog": "http://example.com/bud/",
"feed": "http://example.com/bud/atom",
"description": "My buddy's Weblog",
"tags": ["buddy"]
}
]
我們可以把它保存為一個簡單的文件並使之可用，並使用 AJax 腳本技術通過前面的鏈接列表動態地構建 清單 2 中的無格式的 Html blogroll。要處理適度降級的問題，應選擇理解良好的技術用於可行的 AJax 設計，IBM developerWork 網站上對其中的很多技術進行了討論。
結束語
微格式宣稱擁有的社區應該在微格式日行漸遠的時候向大家發出警告。Weblog 軟件是基於 Web 改進的一個令人驚異的引擎，它不斷地引入一些思想和技術，這些努力應該能消除復合微格式的一些比較惡劣的有害特性。並且當它們生成這些改進時，我們通常都不必選擇查看源代碼來效仿它們。Weblog 開發人員經常會發表采用其技術的詳細說明。毫無疑問，有細微差別的微格式是很實用的，構建它時考慮了有關開發的大致共識和現有的運行代碼。它們與 MIME 類型、文件名擴展等文件的正式注冊相似，不過在中心控制方面有所不如。當微格式的作者開始誤用主格式而不是基於它進行構建時，一些問題就是隨之而來了。在這類情況中使用使合適的格式會好很多，而且 Web 中到處都是有用的方法足以為我們提供健康的選擇。