HTML5/infrastructure

通用设施

术语

本规范会涉及到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.

资源

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

一些规范，尤其是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 文件遵守以文件為對象的所有規範符合條件。為方便可讀，本規範將這些規範要求說成是對網頁作者的要求，這些要求也間接是對文件的要求 — 根據定義，本規範假設所有文件都有網頁作者。（在某些情形，網頁作者本身也是使用者代理，這些使用者代理還須遵守其他下述規則。）

使用者代理有不同（但有交集）的分類，各有不同的規範要求。

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

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

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

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

不可互動的使用者代理

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

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

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

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

無腳本支援的使用者代理

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

規範符合檢驗器

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

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

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

資料挖掘工具

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

創作工具與標記生成器

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

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

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

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

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

然而，WYSIWYG 工具也是合法的。WYSIWYG 工具應該使用適合的元素，不該使用還未知是否適合的元素。這在某些極端的情形下代表只能用流式元素中的幾個元素，像 div、b、i 與 span，並自由地使用 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]

媒體查詢（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]

本規範不「要求」使用者代理支援特定的網路協定、樣式表語言、腳本語言或是任何上述以外的 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形式编码一个码点所需的最少数量的字节编码该码点所得的一个序列。