W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > August 2011

貢獻 HTML 規範的步驟(非常簡單,內含真實案例)

From: Kang-Hao (Kenny) Lu <kennyluck@w3.org>
Date: Wed, 31 Aug 2011 23:12:30 +0800
Message-ID: <4E5E4F5E.40708@w3.org>
To: 中文HTML5同樂會ML <public-html-ig-zh@w3.org>
CC: 劭非程 <csf178@gmail.com>
最近 winter 大大在翻譯 HTML 規範的時候發現了並回報了一個錯誤,在這裡把這
個回報的步驟寫出來給大家參考,非常簡單!這裡的 HTML 規範指的是 WHATWG 的
那份 HTML Living Standard[1],它除了 HTML、DOM 0 以外還有 Canvas API、
WebVTT、WebRTC、Microdata 等等。

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/

== 步驟 ==
1. 發現規範上的錯誤(比如說與瀏覽器不符,但是覺得瀏覽器實作比較合理的情
形),或是完全不曉得規範在講什麼的地方,抑或是對於 HTML 新功能的要求(新
標簽、API 等等)。
(註:我不知道各位有沒有那種看原文書,在某些地方覺得書上的邏輯不通順的那
種經驗,如果你在翻譯規範的時後出現類似的情形,這次你有抗議的機會 了!)

2.(可選)在 W3C 的 bugzilla[2] 搜尋一下這個問題是不是被回報過了。如果已
被回報過,可以把自己加到 CC 列表裡以追蹤後續發展並取消這些步驟。

3.(可選)在 WHATWG 規範的右上角的地方按 "Login..." 登入,沒帳號的可以按
"Request Account...",HTML 規範編輯會親自寄密碼到你信箱喔,呵呵。(其實
是自動的)登入的好處是在可以在回報的錯誤上留下你的郵件,總是給自己一點記
錄功績的機會吧!

4. 在規範有問題的地方用滑鼠點一下,下面的評論條會變成 "Section "XXXX"
selected"。

5. 在評論條用英文寫上對規範不滿之處,這之後還有補充內容的機會,你可以考
慮一行之內把問題描述清楚,也可以標題盡量簡單扼要,之後補充內容的地方可以
再多 描述一點。按下 "Submit Review Comment"。
(註:一、應該先寫規範的*問題*而不是如何改進,改進方法可以寫在放詳情的地
方,也可以讓編輯決定,畢竟他比較清楚整個規範的結構、用語等等。 二、沒什
麼好怕的,送出去就對了,認真思考過的意見比 50% 其他人的意見有用。)

6. 之後你會得到一個 W3C bugzilla 的 bug 代碼,按進去就可以看到你的意見對
應的 bug。在 W3C HTML 工作組的郵件群[3]也會出現你的 bug 的對應郵件。
(註:你沒看錯,在 WHATWG 規範送出去的意見會跑到 W3C 的 bugzilla。事實上
扣除微軟的人員,WHATWG 與 W3C 基本上是差不多的一群人,WHATWG 跟 W3C 的關
係有點難解釋,不過基本上不是兩群沒交集的人。另外如果你看看[3]你會發現有
很多人在評論條亂打,所以我前面說的 50% 絕對沒有騙人!)

7. 註冊一個 W3C bugzilla 帳號,在你的 bug 寫上詳細資訊,規範的修改建議等等。
(註:如果你之前一行已經夠清楚你可以跳過這步驟,你也可以跳過 4.5.6. 直接
在 bugzilla 上發 bug,不過從 WHATWG 規範進來的 bug 有「規範哪裡是錯的」
的資料,其實比較方便追蹤一點。)

8. 等待你的 bug 的結果,也可以在 bugzilla 上跟人討論,繼續表達意見等等。
bug 的結果有 FIXED、WONTFIX 等等,請參考[4]的說明。若你對結果不滿,請參
考該文件的說明上訴,不過這裡可能就需要加入 HTML 工作組了。

9.(可選)跟朋友炫耀,或是來中文興趣小組炫耀一下。我寫真封信也是帶有炫耀
的目的的。哈哈。不管怎麼樣,我個人歡迎大家自己找規範的錯誤自行 回報,畢
竟自己做的效率比較高一點,也不會有中英文傳達漏掉的資訊。不過若是想不出
5. 需要用的英文敘述,也歡迎來這裡跟大家檢討一下,不過效率就比較難以保證了。

[2] http://www.w3.org/Bugs/Public/
[3] http://lists.w3.org/Archives/Public/public-html/latest
[4]
http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#basic-step-2

另外,同樣的步驟也適用在 Web Applications 1.0 那份規範上,所以包括 Web

== 真實案例 ==
1. winter 大大在翻譯規範上 base 元素的說明[5]的時候,注意到了「IDL属性
href,在get时应该返回文档基址URL,在set时则将href属性写入新的值。 」這段
敘述。

而計算「文档基址URL」[6]有一個很複雜的演算法,不過幾本上一個 document 只
有一個「文档基址URL」,所以這段敘述在下面這個例子裡:

data:text/html, <base id="a" href="http://www.google.com"/><base id="b"
href="http://www.baidu.com"/><script>alert(document.getElementById("b").href)</script>

根據規範的話結果應為 "http://www.google.com/",但是 winter 測試了幾個瀏
覽器的結果都是 "http://www.baidu.com/",也就是規範與目前瀏覽器的實作不
符,而規範描述的情形也不見得是一個比較好的結果(a 元素的 href IDL 屬性就
直接回傳內容屬性(content attribute))。

2.(我幫 winter 稍微搜尋了一下 W3C bugzilla,沒發現類似問題)

3. winter 註冊了一個 WHATWG 規範帳號

4. winter 在 4.2.3 base 元素的章節點了一下,評論條變成 Section
"the-base-element" selected.

5. winter 在評論條上寫上 "It seems href IDL attribute on base element
doesn't reflect content attribute when there is more than one base
element with "href"."

6. winter 得到對應的代碼:13859

7. winter 註冊了一個 W3C bugzilla 帳號,並在該 bug[7]上描述了 1. 提到的
例子。

8.(等待結果中,不過基本上已經確認了 WebKit 與 Gecko 在這個部分不符,所
以有兼容問題。這個 bug 也被 Mozilla 裡面一個極強大的工程師,俗稱「無所不
在的 Boris Zbarksy 追蹤」了。)

9.(經過同意,我幫 winter 大大代寫這篇炫耀文)

[5] http://www.w3.org/html/ig/zh/wiki/HTML5#base.E5.85.83.E7.B4.A0
[6]
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#document-base-url
[7] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13859

== 結語 ==
在 W3C 規範的發展過程中,若一份規範要進展到推薦標準,規範裡面的每一句話
都需要有一個測試資料證明有兩個兼容的實作,所以會有很多的 改規範/實作→寫
測資→沒有兩個兼容實作→改規範/實作 的輪回(CSS2.1 就經歷了十年的輪回)。
在這裡感謝 winter 挑出了其中一個問題,讓 HTML5 規範更早完成!也歡迎大家
一起來翻 HTML5 規範,享受挑錯的樂趣!


此致

呂 康豪(Kenny), 中文興趣小組W3C連絡人
Google+: https://plus.google.com/112088462407783855918/posts
新浪微博: http://t.sina.com.cn/1950042164
Received on Wednesday, 31 August 2011 15:13:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:49 UTC