Warning:
This wiki has been archived and is now read-only.

HTML5/infrastructure

From HTML5 Chinese Interest Group Wiki
Jump to: navigation, search


通用设施

术语

本规范会涉及到HTML/XML attributes和IDL attributes。为避免混淆,我们用content attributes来描述HTML/XML attributes,用IDL attributes来描述IDL接口中的属性。类似的,properties可以用来描述JavaScript对象或CSS的properties。为区分这两种properties,我们分别用object properties和CSS properties来描述上两种不同的properties.

一般来说,如果一个feature既适用于HTML语法,也适用于XHTML语法,则会说该feature适用于HTML或者XHTML。如果某feature只适用于其中的一种语言,则会明确指出该feature不适用于另一种语法,比如:在HTML里......(注意不适用于XHTML)

本规范的document可以是任何HTML格式的文件,包括简短的静态文档,较大的带有多媒体数据的文档,还有复杂的交互应用。

当提到一个文档被呈现给用户的方式时,规范中会用到shown, displayed或者visible.

如果说从算法B返回到算法A。这说明A调用了B。当回到A时,程序将会继续执行调用B的语句的下一条语句。

“透明的黑色”表示R,G,B和alpha通道都被设成了0.


资源

本规范使用术语支持与否来指代一个用户代理是否能够从语义上解码一个外部资源。当一个实现器能够处理一种格式或类型的外部资源并保证其关键内容不被忽略,则认为该实现器支持这种格式或类型。一个特定的资源是否被支持取决于所使用的该资源格式的特性。

例如,对于一个PNG图而言,如果它的像素点数据能够被解码和渲染,则认为支持该文件,即使图片中包含实现器未知的动画数据。
对于一个MPEG视频文件而言,如果不能支持它的压缩格式,则认为不支持该文件,即使实现器能够从该文件的元数据中获取到视频的尺寸信息。

一些规范,尤其是HTTP规范,其表示在本规范中被称为一种资源[HTTP]

术语MIME类型(MIME type)指代在协议文献中的因特网媒体类型。而媒体类型(media type)在本规范中指代用于表现的媒体类型,就像CSS规范中使用的那样。[RFC2046] [MQ]

如果一个字符串符合RFC2616中3.7节“媒体类型”定义的media-type规范,则它是一个有效的MIME类型。特别是,一个有效的MIME类型可能包含MIME类型参数。[HTTP]

如果一个字符串符合RFC2616中3.7节“媒体类型”定义的media-type规范但不包含任何 ";" (U+003B)字符,则它是一个有效的无参数MIME类型。换句话说,它只包含一个类型和一个子类型,没有MIME类型参数。[HTTP]

术语HTML MIME类型(HTML MIME type)用于指代MIME类型text/html

一个资源的关键子资源是那些对该资源而言所需的必须被正确处理的资源。子资源关键与否由定义该资源格式的规范来定义。

术语数据地址(data: URL)指代使用data:格式的地址 [RFC2397]

XML

为了简化从HTML到XHTML的移植,至少为了DOM和CSS,遵循本规范的用户代理将把HTML中的元素置于 http://www.w3.org/1999/xhtml 命名空间中。本规范中使用的术语HTML元素指代任何此命名空间中的元素,即同时指代HTML和XHTML元素。

除非另外声明,本规范中定义或提到的所有元素位于HTML命名空间("http://www.w3.org/1999/xhtml")中,而本规范中定义或提到的所有属性(attributes)都没有命名空间。

术语元素类型指代拥有特定本地名称和命名空间的元素集合。例如[button]元素指拥有元素类型[button]的元素,也即它们拥有本地名称"button"以及(如上隐式定义的)HTML命名空间

属性名称如果符合XML中定义的名称被称为XML兼容(XML-Compatible),它们不包含":" (U+003A)字符,并且它们的前三个字符不匹配ASCII大小写不敏感的字符串“xml”[XML]

术语XML MIME类型用于指代MIME类型text/xml, application/xml,以及任何子类型由"+xml"四字符结尾的MIME类型[RFC3023]

DOM树

脚本

插件

字符编码

規範要求

本規範的所有圖表、範例、備註皆沒有規範性,直接標示無規範性的章節也是如此。本規範其餘的部份具有規範性。

在具有規範性的部份裡,關鍵詞「必須(MUST)」、「必不可(MUST NOT)」、「本規範要求…(REQUIRED)」、「應該(SHOULD)」、「不應(SHOULD NOT)」、「本規範建議…(RECOMMENDED)」、「可(MAY)」、「可以選擇(OPTIONAL)」 按照 RFC2119 的敘述解讀。為方便閱讀,本規範翻譯使用中文的這些關鍵詞。[RFC2119]

作為演算法一部分指令的要求(例如:「剝離所有前頭空白字符」、「回傳假值並退出這些步驟」)以呼叫演算法所用關鍵字(「必須」、「應該」、「可」等等)的意義解讀。

以演算法或是具體步驟呈現的要求可以任何方式實作,唯一的要求是是結果相等。(特別是本規範定義的演算法以容易理解而不以性能高為目的。)

規範類別

本規範描述了使用者代理(實作者)與文件(網頁作者與創作工具實作者)的規範符合條件。

符合規範的 HTML5 文件遵守以文件為對象的所有規範符合條件。為方便可讀,本規範將這些規範要求說成是對網頁作者的要求,這些要求也間接是對文件的要求 — 根據定義,本規範假設所有文件都有網頁作者。(在某些情形,網頁作者本身也是使用者代理,這些使用者代理還須遵守其他下述規則。)

舉例來說,若「網頁作者必不可使用 foobar元素」的要求存在,則這也代表任何文件不允許含有叫做 foobar 的元素。
注:對文件的規範要求包含語法上的(<table> 在 <body> 下符合規範,但是在 <title> 下不合規範)及語意上的(<table> 元素代表多維度的資料表格,不是家具)。
注:文件的規範要求與實作的規範要求沒有邏輯關係。使用者代理不可任意處理不合規範的文件 — 本規範描述的處理模型與輸入文件符不符合規範沒有關係。

使用者代理有不同(但有交集)的分類,各有不同的規範要求。

瀏覽器與其他可互動的使用者代理

除非其他規範覆蓋了 XML 文件中在 HTML 命名空間下元素、屬性的語意,支援 XHTML 語法的瀏覽器必須照本規範所描述的方式處理這些元素、屬性,使得使用者可以與這些元素、屬性互動。

符合規範的 XHTML 處理器會在在 XML 文件裡找到 XHTML script 元素的時候,執行元素所含的腳本。然後,若這個元素是在一個由 XSLT(假設使用者代理也支援 XSLT)表示的轉換的裡面,則處理器會將該 script 元素當成轉換裡面假元素的一部分。

支援 HTML 語法的瀏覽器必須照本規範所描述的方式處理有 HTML MIME 型態標示的文件,使得使用者可以與文件互動。

支援腳本的使用者代理必須 Web IDL 規範描述的方式實作本規範裡面的各個 IDL 片段。[WEBIDL]

注:除非額外說明,覆蓋 HTML 元素語意的規範不覆蓋對這些元素 DOM 物件的要求。舉例來說,上述例子裡的 script 元素也仍會實作 HTMLScriptElement 界面。

不可互動的使用者代理

本規範豁免對於僅渲染不互動版 HTML、XHTML 文件的使用者代理在使用者互動上的要求,至於其餘部份這些使用者代理必須遵守與瀏覽器相同的符合規範條件。

注:不可互動的使用者代理的典型例子是印表機(靜態)與頭上顯示器(動態)。一般來說大部分靜態不可互動的使用者帶裡也會選擇不支援腳本
不可互動但是動態顯示的使用者代理仍會執行腳本、允許動態的表單提交等等。然而,由於在使用者不能與文件互動的情形下「焦距」的概念沒有意義,這種使用者代理不需要支援任何焦距相關的 DOM API。

支援建議預設渲染的視覺使用者代理

不論是互動還是不互動的使用者代理可選擇(透過使用者選項)支援本規範定義的建議預設渲染。

選擇支援建議預設渲染的使用者代理必須實作渲染章節內描述為「本規範『預期』使用者代理實作…」的行為。

無腳本支援的使用者代理

本規範豁免對於不支援腳本的實作(或是完全停用腳本功能的實作)在支援本規範提及的事件與 DOM 界面上的要求。對於本規範以事件模型與 DOM 定義的部份,這些使用者代理仍必須展現如同已支援事件以及 DOM 的行為。

注:腳本可能是應用程式裡不可分割的部份。不支援腳本或是停用腳本的瀏覽器可能無法完全表達網頁作者的目的。

規範符合檢驗器

規範符合檢驗器必須驗證一份文件是否符合本規範描述的規範符合條件中適用的部份。本規範豁免對於自動化的規範符合檢驗器在偵測需要解讀網頁作者目的才能得到的錯誤上的要求(舉例來說,雖然一份含有內容不是一條引用的 blockquote 元素是不符合規範的,不然人類判斷的符合規範驗證器不需要確認 blockquote 元素是否只含有引用內容)。

規範符合檢驗器必須檢驗輸入文件在沒有瀏覽器上下文的情況下解析(也就是不執行腳本,且解析器的沒有腳本標記)可以符合規範,並應該檢驗輸入文件在有腳本執行用的瀏覽器上下文的情況下解析可以符合規範,且腳本絕不會讓不合規範的狀態在執行腳本的瞬間以外發生。(因為已證明不可能,這是一個「應該」要求而不是「必須」要求。[COMPUTABLE]

「HTML5 驗證器」這個詞用來代表一個本身符合本規範可適用要求的規範符合檢驗器。

注:XML DTD 不能描述本規範所有的規範要求。因此,一個 XML 驗證處理器與一個 DTD 不能構成一個規範符合檢驗器。另外,本規範定義的兩種書寫格式都不是 SGML 的應用,SGML 檢驗系統也不能構成規範符合檢驗器。

用另一種說法,符合規範條件有三種:

  1. 能以 DTD 描述的條件。
  2. 不能以 DTD 描述,但是可以用機器檢驗的條件。
  3. 只能由人類檢驗的條件。
規範符合檢驗器必須檢驗前兩種條件。只能檢驗第一種錯誤的簡單 DTD 驗證器不是本規範所述的符合標準的規範符合檢驗器。

資料挖掘工具

不是以渲染文件或是檢驗文件為目的的應用程式與工具應該遵守這些文件的語意。

一個生成文件大綱的工具若是因段落增加巢狀層級而不因節增加巢狀層級,則它不符合規範。

創作工具與標記生成器

創作工具與標記生成器必須生成符合規範的 HTML5 文件。適用於網頁作者的規範符合條件也適用於創作工具。

本規在創作工具還尚無法確定網頁作者的目的的情形下,豁免對於創作工具在按照規範定義的語意使用元素這點上的嚴格要求。然而創作工具必不可自動的使用錯誤元素或鼓勵工具的使用者這樣做。

舉例來說,把任意的聯絡資訊用 address 元素標記是不符合規範的 — 該元素僅可用來標記文件或是小節作者的聯絡資訊。然而,由於創作工具不太可能了解這個差異,因此本規範在這裡豁免這個要求。這不代表使用者代理可以用 address 元素標記斜體字的區塊 — 這只代表創作工具不需要在使用者插入一個小節的聯絡資訊時,驗證該使用者輸入的真的是聯絡資訊而不是其他內容。
注:以規範符合檢驗來說,編輯器必須輸出至少能通過規範符合驗證器檢驗的符合規範程度的文件。

當使用者用創作工具編輯不符合規範的文件時,創作工具可保留在此編輯期間未編輯小節的規範性錯誤(即本規範允許編輯工具往返錯誤內容)。然而在保留錯誤的情形下,創作工具必不可聲稱輸出文件符合規範。

創作工具有兩個種類:操作結構或語意資料的工具與特定媒介的所見即所得(WYSIWYG)工具。

前者是編輯 HTML 較好的機制,畢竟原始資訊裡的結構可用來選擇較適當的元素與屬性。

然而,WYSIWYG 工具也是合法的。WYSIWYG 工具應該使用適合的元素,不該使用還未知是否適合的元素。這在某些極端的情形下代表只能用流式元素中的幾個元素,像 divbispan,並自由地使用 style 屬性。

不管是不是 WYSIWYG 的所有創作工具應該盡全力讓使用者創作有結構、語意豐富、不分媒介的內容。


使用者代理可在輸入上施加特定於實作的限制,例如:以阻止阻斷服務攻擊為目的、以防止記憶體不足為目的、為特定平台的限制繞道。

為與既存的內容與先前的規範兼容,本規範描述了兩種輸出格式:一個以 XML 為基準(稱作 XHTML 語法),一個從 SGML 來的自訂格式(稱作 HTML 語法)。實作必須至少支援兩種格式的其中一種,雖然本規範鼓勵支援兩種。

本規範使用的語言假設使用者代理會展開所有實體引用,並因此在 DOM 裡面不包含實體引用節點。若使用者代理在 DOM 裡含有字符引用節點,則使用者代理必須在實作本規範的時候如同這些節點已展開地處理這些節點。舉個例子,若有一個要求與一個元素的文字子節點相關,則也要使用作為該元素子節點的實體引用節點的所有文字節點。使用者代理必須把引用不明實體的實體引用當作是含有一個空白文字節點,以使用本規範定義的演算法。

本規範將有些規範要求說成是對元素、屬性、方法或物件的要求。這些要求分為兩個種類:描述內容模型限制的,與描述實作行為的。前一個種類的需求是針對文件與創作工具,而後一個種類是對於使用者代理的要求。同樣的,本規範說了一些對網頁作者的要求,這些要求應解讀為對網頁作者所寫的文件的要求。(換句話說,本規範不區分針對網頁作者與針對文件的規範符合條件。)

依賴關係

本規範建構在其他規範規範之上。

XML

因為 XHTML 語法使用帶有名稱空間的 XML 序列化,支援 XHTML 語法的實作必須支援某個版本的 XML 與相應的名稱空間規範。[XML] [XMLNS]

DOM

文件物件模型(Document Object Model,DOM)是文件與其內容的一個描述方式也是一個模型。DOM 不只是一套 API — 本規範以在 DOM 上的操作定義規範符合條件。[DOMCORE]

因為本規範著重以 DOM 描述規則並定義部份功能為 DOM Core 各界面的擴充,實作必須支援某個版本的 DOM Core 與 DOM Events。[DOMCORE] [DOMEVENTS]

其中,DOM Core 規範定義了以下功能:[DOMCORE]

  • Attr 界面
  • CDATASection 界面
  • Comment 界面
  • DOMImplementation 界面
  • Document 界面
  • DocumentFragment 界面
  • DocumentType 界面
  • DOMException 界面
  • Element 界面
  • Node 界面
  • NodeList 界面
  • ProcessingInstruction 界面
  • Text 界面
  • createDocument() 方法
  • createElement() 方法
  • createElementNS() 方法
  • getElementById() 方法
  • insertBefore() 方法
  • ownerDocument 屬性
  • childNodes 屬性
  • localName 屬性
  • parentNode 屬性
  • namespaceURI 屬性
  • tagName 屬性
  • textContent 屬性

DOM Events 規範定義了以下功能:[DOMEVENTS]

  • Event 界面
  • EventTarget 界面
  • UIEvent 界面
  • MouseEvent 界面
  • click 事件
  • target 屬性

File API

本規範使用以下 File API 規範定義的界面:[FILEAPI]

  • Blob
  • File
  • FileList

Web IDL

使用者代理必須將本規範裡的所有 IDL 片段解釋為 Web IDL 所說的必要符合 IDL 片段。[WEBIDL]

本規範使用 WebIDL 規範定義的給予屬性索引給予屬性名這兩個詞彙。

除非另外說明,若腳本賦予型態為浮點數(double)的 IDL 屬性 Infinity 或 Not-a-Number(NaN),則使用者代理必須丟出 NOT_SUPPORTED_ERR 例外。

除非另外說明,若腳本以 Infinity 或 Not-a-Number(NaN)作為型態是浮點數(double)的方法參數,則使用者代理必須丟出 NOT_SUPPORTED_ERR 例外。

除非另外說明,若腳本對型態為 DOMString 的 IDL 屬性賦值,或是呼叫的方法有型態為 DOMString 的參數,則使用者代理必須將該 DOMString 轉換成 Unicode 字符串列以提供本規範裡的演算法使用。[WEBIDL]

JavaScript

本規範描述的語言的一部分僅支援 JavaScript 為腳本語言。[ECMA262]

注:由於 JavaScript 這個術語比較為人所知,這裡使用 "JavaScript" 而不是官方的 ECMAScript 以稱呼 ECMA262。同樣的,本規範以最常使用的 text/javascript 作為 JavaScript 的 MIME 型態,儘管 RFC 4329 已正式廢棄這個型態[RFC4329]

媒體查詢(Media Queries)

實作必須支援媒體查詢(Media Queries)語言的某個版本。[MQ]

URI、IRI、IDNA

實作必須支援 URI 與 IRI 規範定義的 URL 語意,並支援《Internationalizing Domain Names in Applications (IDNA)》規範定義的 IDNA 域名語意。[RFC3986] [RFC3987] [RFC3490]

CSS 模組

雖然本規範不要求實作支援 CSS 全部功能(但是本規範鼓勵瀏覽器這樣做),有些功能以特定的 CSS 要求定義。

具體來說,有些功能要求將字串作為 CSS <color> 取值解析。CSS 規範要求使用者代理在解析 CSS 取值的時候使用某些錯誤處理規則,而這些規則也適用於本規範。[CSSCOLOR] [CSS]

舉例來說,本規範要求使用者代理在無預期的發現樣式終點的情況下,關閉所有開構造。因此,在解析 "rgb(0, 0, 0"(少了關閉誇號)字串以獲得色彩值的情況下,使用者代理依錯誤處理規則假設關閉誇號存在,並獲得一個值(黑色)。但是,使用者代理不能解析類似的構造 "rgb(0, 0,(少了括號跟藍色的數值),畢竟關閉這個開構造無法得到可用的取值。


本規範不「要求」使用者代理支援特定的網路協定、樣式表語言、腳本語言或是任何上述以外的 DOM 規範。但是,本規範描述的語言傾向使用 CSS 作為樣式表語言、JavaScript 作為腳本語言、HTTP 作為網路協定,並在幾個功能的描述上假設使用者代理使用這些語言與協定。

注:本規範可能另外在字符編碼、圖像格式、音頻格式、視頻格式上的要求,在各章節提出。

擴展性

字串比較與大小寫

區分大小寫的方式比較兩個字串是指一個代碼點一個代碼點準確比較。

ASCII 不分大小寫的方式比較兩個字 串是指除了將在範圍 U+0041 到 U+005A(也就是 LATIN CAPITAL LETTER A 到 LATIN CAPITAL LETTER Z)之間的字符與在範圍 U+0061 到 U+007A(也就是 LATIN SMALL LETTER A 到 LATIN SMALL LETTER Z)之間的對應字符視為一樣之 外,一個代碼點一個代碼點準確比較。

兼容無大小寫的方式比較兩個字串是指使用 Unicode「compatibility caseless match」操作比較兩個字串。[UNICODE]

除非有另外說明,字串比較必須以區分大小寫的方式進行。

轉換字串成 ASCII 大寫是指將在範圍 U+0061 到 U+007A(也就是 LATIN SMALL LETTER A 到 LATIN SMALL LETTER Z)之間的所有字符以在範圍 U+0041 到 U+005A(也就是 LATIN CAPITAL LETTER A 到 LATIN CAPITAL LETTER Z)的對應字符取代。

轉換字串成 ASCII 小寫是指將在範圍 U+0041 到 U+005A(也就是 LATIN CAPITAL LETTER A 到 LATIN CAPITAL LETTER Z)之間的所有字符以範圍 U+0061 到 U+007A(也就是 LATIN SMALL LETTER A 到 LATIN SMALL LETTER Z)的對應字符取代。

若將字串 s 截至字串模式的長度會使兩個字串互相批配,則字串模式是字串 s前輟批配

UTF-8

当用户代理需要‘包含错误处理地,以UTF-8解码一个字节的字符串’,它意味着除非出现任何错误,字节流必须通过将其解释为UTF-8从而转化为一个Unicode字符串。出现的错误必须被描述为下列列表中的形式。下面的列表中的字节被表示为十六进制。[RFC3629]

  • 一个FE至FF范围内的字节
  • 超长形式(例如:F0 80 80 A0)
  • 一个C0至C1范围内的字节,其后跟随一个80至BF范围内的字节。
  • 一个F0至F4范围内的字节,其后跟随三个80至BF范围内的字节,这三个字节表示一个高于U+10FFFF的码点。
  • 一个F5至F7范围内的字节,其后跟随三个80至BF范围内的字节。
  • 一个F8至FB范围内的字节,其后跟随四个80至BF范围内的字节。
  • 一个FC至FD范围内的字节,其后跟随五个80至BF范围内的字节。
  • 一个C0至FD范围内的字节,其后不跟随80至BF范围内的字节。
  • 一个E0至FD范围内的字节,其后跟随一个80至BF范围内的字节,该字节后不跟随80至BF范围内的字节。
  • 一个F0至FD范围内的字节,其后跟随两个80至BF范围内的字节,最后一个字节后不跟随80至BF范围内的字节。
  • 一个F8至FD范围内的字节,其后跟随三个80至BF范围内的字节,最后一个字节后不跟随80至BF范围内的字节。
  • 一个FC至FD范围内的字节,其后跟随四个80至BF范围内的字节,最后一个字节后不跟随80至BF范围内的字节。
  • 表示U+D800至U+DFFF范围内码点的任意字节序列
    整个匹配的序列必须使用单一的U+FFFD替换字符替换。
  • 一个80至BF范围内的字符,其不跟随在一个80至FD范围内的字节之后。
  • 一个80至BF范围内的字符,其跟随在一个作为完整UTF-8序列一部分的字节之后,该UTF-8序列不包括该字节。
  • 一个80至BF范围内的字符,其跟随在一个作为已经使用U+FFFD替换字符替换过的序列一部分的字节之后,其既不是独立的也不是序列的一部分。
    每个这样的字节必须被使用U+FFFD替换字符替换。

对于上述需要的目的,一个UTF-8的超长形式指的是,使用超过以UTF-8形式编码一个码点所需的最少数量的字节编码该码点所得的一个序列。

例如:字节串"41 98 BA 42 E2 98 43 E2 98 BA E2 98"将被转换成字符串"A��B�C☺�"。