<time> 元素更改提議書（change proposal）

摘要

以下述方式改善 HTML5 <time> 元素

• 保有現有的機能，但是以下述方式簡化：
  • 丟棄 'pubdate' 屬性（額外議題）
  • 丟棄 DOM 屬性 'pubDate'（額外議題）
  • 丟棄 DOM 屬性 'valueAsData'
  • 渲染元素的內容（而不是根據本地的語言環境呈現屬性值）
• 支援「只有年分」的日期[1]（例：vCard4 RFC6350 / hCard 'bday' 使用情節）
• 支援「只有年月」的日期[2]（""）
• 支援「只有月日」的日期[3]（""）
• 時區[4]
• 間隔[5]

以上列表已在 2011-11-03 於 HTML 工作組發表，並在支持 time 元素的開發者中沒有任何的反對。

由見面會討論得到的共識的層度來看，我認為這個更改提議書裡的這個列表已該凍結。

本更改提議書不包含 http://wiki.whatwg.org/wiki/Time_element 裡的其他提議，但是我鼓勵想推額外功能的人寫下跟這個更改提議書的差異。

理由

使用情節：time 元素可以讓內容供應者用數字與文字表達時間，以供轉換、索引時間相關內容的應用程式使用，以讓使用者用自己喜歡的格式（語言環境）讀（或聽）時間與日期。

相較於其他提案的好處：time 元素語意上比廣義的 data 元素（可能對其他有不同的人類 vs 機器表現的資料種類有用）還具體。雖然上述的使用情節可以部份靠從廣義的 data 元素機器可讀日期與時間的微語法（ISO8601）推論出來，這種作法有幾個瑕疵：

1. 存在不唯一的微語法。有些微語法，例如年份（YYYY）跟數字沒有區別。其他如年—月（YYYY-MM）或年—月—日（YYYY-MM-DD）可能跟用破折號分開數字的數字序列的微語法有衝突。時間（HH:MM）可能被誤認為聖經詩句的引用，例如 "20:30" 或是音樂軌的長度，例如 "2:28"。
2. 未來友好性。日期時間相關的微語法在未來的其他資料型態可能也會用到。靠微語法的唯一性推斷資料型態會使得來無法使用這些微語法。

細節

請看摘要。必要的時候根據編輯的要求增加這個部份。

影響

正面效果

• 增進親和力。若內容供應者使用 <time> 元素，這會讓親和力工具以使用者的喜好或是依語言環境呈現（講出）日期或時間的值，使得內容更容易閱讀。另一方面，僅僅使用 <data> 元素不會有這種效果，因為不能假設屬性值是任何一種的內容。
• 幫助搜尋相關的使用情節。Google 搜尋的使用界面提供搜尋某個日期範圍（但是這是發表日期還是更改日期尚不清楚）。有了 <time> 元素之後，這些搜尋相關的情形可以提供更精確的結果。如今 Google 必須猜測日期並有很多錯誤結果。例如，從 site:microsoft.com 搜尋早期的 ActiveX 文檔並限制結果的年份會得到 1972（Microsoft 在 1975 年創立）與 1977（在 IE 出現很久之前）的結果。

負面效果

• 多一個元素。任何一個更多的元素都會讓學習這個語言產生更多的負荷。

規範符合類別

與之前草案裡的 time 元素相同，但是加上上面註明的額外功能

潛在危險

• 內容供應者可能錯誤標示資訊的日期與時間
• 潛在的 DRY 違反。當網頁作者同時出版人類可讀的內容與機器可讀的日期時間資訊的時候，兩者的差異變得可能，機器資訊也可能過時，畢竟看到人類可讀內容的人比較多也比較會被修復。

參考資料

參考資料在內文。

相關資料

• W3C TR HTML5 time 元素
• W3C ED HTML5 time 元素
• WHATWG HTML time 元素