有意義的標籤：POSH 及其超越Emily P. Lewis | 2010 年 6 月 21 日
回到 1998 年，我在一家會計事務所擔任市場行銷，我負責設計和撰寫客戶的新聞稿和許多印刷品為主的活動。有一天，我的老闆要我看一下公司的網站，並且重整內容。 當我經歷編輯和重寫的過程，我對網站背後的機制越來越感興趣。在 Internet 上搜尋之後，我知道了所謂的 HTML。在某個關鍵的一天，我打開了記事本，輸入： 我用 .html 的格式儲存這個文字檔，然後用 Internet Explorer 開啟，結果讓人驚訝。這太神奇了，我可以立即發佈網頁，而我的世界就此改變。此後我離開行銷工作，開始自學 HTML（以及 CSS），並且以專業的網站開發人員身份，開始全新的歷險。 12 年後，HTML 標籤對我而言仍有神奇的魅力。從我的觀點來說，它是 Web 的基礎。它的美麗來自於它的簡單。儘管我的技巧不斷累積，技術也日新月異，我仍然強烈地迷戀標籤。每一個我設計的網站，我都盡可能試著寫出最精簡、有效、並具有語義的標籤。另外我們也別忘了有效性。 令我難過的是，並非每一個人都有志於寫出好的語法。網站充斥著 標籤大雜匯、div 主義者 和 span 狂熱份子。而且老實說，我不知道為什麼會這樣。 當然，我知道當中有些限制。每一個設計師和開發人員身上其實都有，無論是陳舊的系統限制了修改標籤的能力，或是老闆寧願將資源和時間分配給前端開發以外的人。但在這些限制中開發出優秀的網站，才是真正專業的標誌。 大多數我遇到 Web 業界的人，都是真正的專家。他們擁有熱情、把工作當志業，持續地建立優秀的網站和應用程式。然而他們之中有那麼多人，為什麼忘了好的標籤帶來的力量？就我後來的了解，那不全然和限制有關。那和把 HTML 當作成是拖油瓶來對待無關。它甚至也不是懶惰的緣故（雖然我承認有時候的確是）。 這個問題必然是缺少了一些認識和知識。幸運的是，這是我能力所及，並能透過這篇文章帶來的一些改變。我們將會了解語義標籤究竟是什麼，看起來像什麼樣子，以及它帶來的好處。我們也將帶著語義的觀念，超越標籤的範疇，進到 CSS 的領域。最後，我們會看到語義標籤如何擴充，應用到機器解讀意義的應用上。 什麼是語義標籤？語義標籤就是標籤具有意義；標籤描述它所包含的內容，而不是內容應該看起來是什麼樣。這意味著不再用 <font> 標籤，不再用 <b> 標籤，不再用 <table> 元素來排版。 取而代之的是，語義標籤鼓勵你優先思考內容。所以，如果你有個清單，你就應該用清單的元素，像是 <ul>。假如你有一個段落，就應該用 <p> 標籤而不是 <div> 標籤。如果你有一個標題，你就該用標題的元素，像是 <h2>。 相對來說，如果你需要一個內縮的內容，不要使用 <blockquote> ，除非它真的是一段引言。如果你希望內容字體加大、變成粗體字，不要使用 <h1>，除非它是頁面中的主要標題。這些視覺效果的需求，CSS 才是你的好伙伴，而不是標籤。 語義標籤的概念是今日 網頁標準 的基石，它鼓勵分離內容、外觀（CSS）和行為（JavaScript）。事實上，語義標籤通常被當作是「標準相容」（standards-compliant）。而在技客所愛的頭字縮寫中，語義標籤也是所謂的 POSH （Plain Old Semantic HTML，質樸陳舊的語義 HTML）。 暫且不管術語，語義標籤也應該能通過有效性驗證。這意味著你的標籤要能符合指定的 DOCTYPE 驗證。當你在寫 HTML 4、XHTML 甚至是 HTML 5，你的標籤應該保持沒有錯誤發生，而且沒有不合法的元素和屬性。 你要怎麼知道標籤是否有效？很簡單，使用 W3C 的線上驗證。 語義標籤的效益到目前為止，你也許稍稍了解語義標籤的精神，但也許仍然疑惑，這真的重要嗎？ 效率其中一個重要的效益是它的可攜性（portability）。使用 POSH 的網頁不只能用在瀏覽器，也能應用在各種裝置上，包含螢幕閱讀器、行動裝置和文字瀏覽器。所以你一旦你用 POSH 方法寫了一次，你就能把內容應用在許多設備上，無論是現在或以後。 語義標籤也提供了開發階段的效率，尤其是團隊的開發工作。透過 POSH，你建立了網站標籤的共通語彙。開發人員不用花時間去思考標籤和各式各樣內容之間的對應。段落就是用 <p>，循序清單就是用 <ol> 等等。 此外，藉由遵循這些標準，以及消除不必要的 <div>、<span> 和巢狀的 <table> 標籤，它會更容易閱讀。而可閱讀性對於找出問題、除錯、維護都會帶來重大影響。 無障礙另一個語義標籤的效益是它提供了無礙障網站的基礎架構。如同在我這篇 web accessibility and WAI-ARIA primer 文章所說，輔助技術像是螢幕閱讀器，會透過網站結構來導覽網站。舉例來說，使用標題元素（<h1>到<h6>）來傳達內容結構的階層性，可以提供螢幕閱讀器的使用者，跳到階層中的不同章節。 當然 WCAG 2.0 準則也鼓勵語義標籤，不止針對頁面結構，也包含了清單（<ul>、<ol>、<dl>）和需要強調的特別文字（<strong>、<blockquote>、<abbr>）。此外，這些準則並不鼓勵使用 <table> 元素去做表格資料以外的任何用途。 使用者體驗利用 POSH 開發的網頁通常會比標籤大雜匯的更為輕量。這個特性通常可以提供頁面下載和反應時間的正面影響，換句話說，能提昇使用者體驗。記住，不是每個人都使用最新、最好的技術。POSH 允許你可以開發符合最低標準的分母，因此就能更有效率地提供內容給所有使用者。 搜尋引擎最佳化？這些年來，我聽過語義標籤在有機 SEO（Search Engine Optimization，搜尋引擎最佳化）的效益。我也常聽到巢狀表格會影響搜尋引擎會結果；而 Google 會給包含標題的內容更高的評價；精簡、具語義的網頁能讓網頁爬蟲更快、更有效率。 可惜的是，多數的證據顯示這些只是謠傳。我努力找出有效、具語義的標籤能讓主要的搜尋引擎改善搜尋結果的事實。但是 Google 甚至表示，利用 CSS 來代替 table 的佈局，對他們的演算法差別不大。 這和我的認知有些差距，搜尋引擎的演算法似乎這幾年來有所改善。巢狀的 <table> 對於 Google 而言，拜精妙的演算法所賜，已經不再是阻礙了。 話雖如此，我個人保持懷疑，在搜尋引擎和語義標籤之間，必然有什麼關係。例如 Google 建議使用使用 h1 元素時必須有所判斷，以避免潛在的不利因素，而且它也建議適當地使用標題標籤。Google 也鼓勵網站管理員使用較精簡的標籤，以改善效能。對我而言，這些建議意味著 Google 的演算法是關切語義標籤的，並且有所擴充。 撰寫語義標籤現在你已經知道語義標籤的意義和效益，現在讓我們談談實際的使用方法。首先，雖然我得承認如果你剛入門，語義標準是需要多花費一點心力來改變心態。假如你已經開發過 <table> 標籤來控制外觀，或是使用 <div> 元素在每一個區塊等級的內容元素上，在轉換到 POSH 時，會覺得有點奇怪，甚至是感到挫折。 相信我，我知道你的痛苦。我也經歷過。當我開始學 HTML 時，我對 Web 標準沒有什麼概念，更別說是語義標籤是什麼東西了。我的網站那時是非常標準的標籤大雜匯。不過一旦我知道有 HTML 標準，而且能帶來許多我沒想過的效益，我無法繼續用過去開發網站的方式。 假如你也得到相同的結論，那麼這是我建議你如何開始的方法：
當然，這些步驟是我如何撰寫標準的過程。也許你會發現其他更適合你的工作流程（或是你的團隊）。重點是，花時間想一下。相信我，你越常去想它，寫出具語義標籤的過程就會越快、越簡單。不過這個過程的確需要一些信念，也需要你多花一點時間。接受它、深入其中，我相信它會帶來較少挫折感。 一些範例讓我們來試作一些真實世界的例子，就從簡單的導覽連結開始。從內容角度出發，讓我們使用下面這些內容： 首頁 產品 服務 關於我們 我看過有些網站用下面的方式來撰寫標準： 不過，讓我們來思考一下內容：這些連結真的是一個段落嗎？<div> 在這裡出現的目的是什麼？ 從我的觀點來看，導覽連結事實上是一群相關的內容元素。這個性質讓它們非常適合使用無序清單的標籤 <ul>。因此，以 POSH 來處理導覽連結的方式會像這樣： 現在，讓我們來看另外一個例子，這次是網站的聯絡資訊： ABC Company 123 Main Street Albuquerque, NM 87106 info@abc.com 888-555-4567 一個非語義的方法來處理這些內容，寫起來也許像這樣： 就我而言，我會利用另一種方法，專注在語義上，像是： 語義標籤的主觀性撰寫語義標籤的更大挑戰，是找出可以使用的「正確」元素。就某些內容來說，很明確就能判斷應該使用 <p> 或 <h1>。但對另一些內容而言，它可能適用多種語義方法。 想想上面的 ABC Company 的例子。在我的語義標籤中，我使用了定義清單（<dl>）。有些人也許會（強烈地）反對，因為他們遵循學校的思維，定義清單應該嚴格地限制在詞條和定義內容上。 從另一個角度，我則認為定義清單也可以用在內容元素彼此間有直接關係，如同 <dd> 內容相對於 <dt> 一樣。以 ABC Company 的聯絡資訊來說，我看到了地址、電子郵件和電話資訊（使用 <dd> 標籤)，這些和公司的名稱直接相關（使用 <dt> 標籤）。 此外，也許不只有 <dl> 的用法會招來非議。你也許已經注意到我在地址資訊上使用 <ul>。就我的想法，這是因為這些資訊是一組相關的內容元素。 為了進一步說明語義標籤的主觀本質，我寫了另一個方法來包含這些資訊，像是這樣： 就本質而言，並沒有所謂的「正確」語義方法（也許有些語義純粹主義候會反對）。再次重申，我鼓勵你專注於思考你的標籤。知道你為什麼選用某個元素而非另一個，並對不同的方法保持開放的學習精神。今天你覺得合理的語義，有可能會隨著你的知識增長而有所改變。 別忘了 HTML5既然本文的焦點是語義標籤，我一定要花點時間來談談 HTML5。目前它仍然在草案階段，HTML5 引進了一些新的語義標籤，也許能減少或消除在結構上使用 <div> 的需求：
以本文的範圍而言，我不打算深入到 HTML5。此外，我也只開發過一個使用 HTML5 的網站，還在試著努力讓自己能處理規格的細微差別。不過仍建議你可以看看這些優秀的文章，我已經親身體驗過它們的用處： 超越結構到目前為止，多數討論集中在使用語義元素來定義結構。不過語義可以超越標籤元素自身，進入屬性值的語義層面，提供更多的意義。 Class 和 ID 值如同我在 Be a CSS Team Player 這篇文章中提到，語意命名的慣例，對於 class 和 id 而言，可以在 CSS 中提供珍貴的情境（context）和意義。讓我們來想想下面這兩種不同樣式的宣告： 在這個範例中，屬性／值的配對是相同的，但是哪一個更有意義？我希望這個答案是很明顯的，第二個宣告由於 class 命名的緣故，讓它更具意義。「Alert」比起「f23」更具有指示使用情境的意義，而更豐富的使用情境，能夠讓你（和其他需要處理 CSS 的人），更容易理解樣式宣告會影響哪些內容。 不只是使用情境，具有語義的 class 和 id 值（而非針對樣式來思考），能減輕維護和日後開發的負擔。假設一個網站有一個邊欄，它指定「rightSidebar」這樣的 id 名稱。乍看之下似乎具有語義，但它同時也帶著樣式意義。所以，如果這個站需要重新設計時，而這個邊欄被改置到新的視覺位置，「rightSidebar」就不再適用了。 這不止意味著 CSS 的屬性值需要調整，而且包含所有標籤中的有使用到這個 id 的，也都要改變。換過來說，如果它只是一個純語義的值，像是「relatedContent」這樣的 id 名稱，將可為日後帶來更多的彈性。 讓機器能解讀意義除了能幫助開發人員維護和溝通之外，具語義的屬性，也可以為機器（使用代理程式、搜尋引擎、瀏覽器、應用程式等）解讀你的內容，帶來重要的意義。 舉例來說，微格式應用在具語義的 class 名稱，用來描述一般的 Web 內容，像是聯絡資訊、事件、部落格貼文和評論。機器藉由微格式，可以很容易辨識內容，並取出應用在許多範圍。 以之前提到的 ABC 公司作為例子。身為人類，你和我都能立刻辨識出內容是什麼：姓名、地址、電話和電子郵件資訊。然而，機器卻不具備這樣的能力。對機器來說，內容就和網頁中的任何一個段落一樣。 但是如果你套用 hCard 微格式，你就在告訴機器，這個資訊包含了聯絡訊息。透過這種方式，機器就能轉換網頁內容的資訊，舉例來說，做成一個可下載的名片。 另一個例子將內容轉成機器可以閱讀，透過語義屬性值達到機器可讀性，而這個標準就是 WAI-ARIA。如前所述，我的 web accessibility and ARIA primer 文章中，你可以指派角色到標籤元素，協助輔助技術了解文件的結構，以及元件做了什麼，又讓如何與之互動。 深入討論機器可讀屬性在微格式和 ARIA 上的應用，已經超過本文的範圍。不過他們在語義標籤的議題中佔有一席之地，你可以再去深入了解。 想了解微格式，可以看看我在部落格分作 8 篇系列文章 Getting Semantic With Microformats。想了解 ARIA，可以看我寫的 Script Junkie primer。 說到純粹主義者…現在我已經給你語義標籤的基礎概念，並且提供一些資訊和資源，幫助你開始。在結束這段旅程之前，我們先繞出去，談一下我前面提過的純粹主義者思維。 當我開始接觸網頁標準時，我很驕傲地自稱「標準擁護者」，並且反對任何非語義、沒有遵循標準的作法。我採用了純粹主義者的觀點，而且老實說，這些情緒中，許多成份只是自我感覺良好，和滿腔的正義感，而非真心擁抱網頁的本質。 現實是，非語義的標籤在今日仍然存在。只要 CSS 需要支援跨瀏覽器，就必須得用到一些 <div> 和 <span>，才能達到某些目的。只要有系統限制設計師和開發人器去改變標籤，就還是會有非語義元素、甚至是無效的標籤出現。而且別忘了，還有我說過的主觀性… 不是任何人都同意 POSH 的每一項作法。 即使是有效性，仍然有例外。在這篇文章開頭中，我說語義標籤同時也是有效的標準。不過，當你擁抱 WAI-ARIA 角色來增加意義，幫助使用輔助技術的人，你的標籤就無法通過有效性驗證，因為這些屬性沒有定義 HTML 或 XHTML 的 DTD 中。雖有解決的辦法,，不過問題是哪個更為重要，是一些有效性的錯誤，或是讓網站或應用程式更具親和力？ 我的想法是，一個純粹主義者必然會受到限制。成為純粹主義者，會限制你理解現今網頁開發人員究竟受了什麼束縛。成為純粹主義者，也會使得如何在這樣的限制中，展開對話變得更不可能。 就我自己而言，我仍然自認為是個標準擁護者。不過時至今日，我尋求平衡勝過一種尋求語義標籤的「正確感」。我追求精簡的標籤。我追求有效性的標準。但同時也我使用非語義的 <div> 和 <span>。我也許為會了機器的可讀性，犧牲標籤的有效性。我甚至會使用無法通過驗證的 CSS 屬性。而且我不會為此道歉。這樣並不會讓我變成一個差勁的開發人員，而是讓我成為一個務實的開發人員，一個知道規則是什麼，而且可以為我的網站和用戶，聰明地選擇該例外的時候。 延伸閱讀這個語義和標準相容標籤的旅程，只是更大議題的一部分。看看下面這些資源，你可以更深入地理解這些議題：
|
.png "About the Author"){kind=small}
.jpg)
.png "Related Content"){kind=small}