12. ~HTMLの構文
注記: この節は、`~HTML~MIME型$とされた資源に対する規則のみを述べる。 ~XML資源に対する規則は、 ~XML構文~節 にて論じられる。 ◎ This section only describes the rules for resources labeled with an HTML MIME type. Rules for XML resources are discussed in the section below entitled "The XML syntax".
12.1. ~HTML文書の書き方
この節が適用されるのは[ 文書 / 著作~tool /~markup生成器 ]に限られ、特に,適合性~検査器には適用されない — 適合性~検査器は、次~節の ~HTML文書の構文解析-法 に与える要件を利用し~MUST。 ◎ This section only applies to documents, authoring tools, and markup generators. In particular, it does not apply to conformance checkers; conformance checkers must use the requirements given in the next section ("parsing HTML documents").
【 この節における “書く( `write^en )” は、生成器, 等から “書き出す” ことも含まれる。 】
文書は、次に与える順の~~部品から~~構成されてい~MUST: ◎ Documents must consist of the following parts, in the given order:
- 0 〜 1 個の `FEFF^U BYTE ORDER MARK `BOM^smb ◎ Optionally, a single U+FEFF BYTE ORDER MARK (BOM) character.
- 0 個以上の[ `~comment$ / `~ASCII空白$ ] ◎ Any number of comments and ASCII whitespace.
- `~DOCTYPE$ ◎ A DOCTYPE.
- 0 個以上の[ `~comment$ / `~ASCII空白$ ] ◎ Any number of comments and ASCII whitespace.
- `html$e `要素$の形をとる`文書~要素$ ◎ The document element, in the form of an html element.
- 0 個以上の[ `~comment$ / `~ASCII空白$ ] ◎ Any number of comments and ASCII whitespace.
上に言及した各種~内容については、以下の少数の節にて述べる。 ◎ The various types of content mentioned above are described in the next few sections.
加えて、`文字~符号化法~宣言$を直列化する方法にも ある制約があり、その論題をとりあげる節にて論じられる。 ◎ In addition, there are some restrictions on how character encoding declarations are to be serialized, as discussed in the section on that topic.
注記: [ `html$e 要素の前 / `html$e 要素の内側の始端 / `head$e 要素の前 ]にある`~ASCII空白$は、文書の構文解析-時には落とされることになる。 一方で, `html$e 要素の後にある`~ASCII空白$は、 `body$e 要素の終端にあったかのように構文解析される。 したがって,`文書~要素$の前後にある`~ASCII空白$は、往来しない†。 ◎ ASCII whitespace before the html element, at the start of the html element and before the head element, will be dropped when the document is parsed; ASCII whitespace after the html element will be parsed as if it were at the end of the body element. Thus, ASCII whitespace around the document element does not round-trip.
【 “往来する( `round-trip^en )” とは、構文解析してから再び直列化されても(あるいはその逆をしても),元のまま保たれることを意味する。 】
次に該当するものに対しては,その後に改行文字を挿入することが示唆される:
- ~DOCTYPEの後
- 文書~要素の前にある~comment
- `html$e 要素の開始tag
- `html$e 要素の内側にあって, `head$e 要素の前にある~comment
【 ~HTMLにおける文書~要素は `html^e 要素に他ならない(が、そのような `html^e 要素は一つに限られる)。 】
◎ It is suggested that newlines be inserted after the DOCTYPE, after any comments that are before the document element, after the html element's start tag (if it is not omitted), and after any comments that are inside the html element but before the head element.~HTML構文における多くの文字列(例:要素の名前や属性)は、`~ASCII英大文字$と`~ASCII英小文字$に限り,文字大小は区別されない。 この節では、これを簡便に “文字大小無視( `case-insensitive^en )” と称する。 ◎ Many strings in the HTML syntax (e.g. the names of elements and their attributes) are case-insensitive, but only for ASCII upper alphas and ASCII lower alphas. For convenience, in this section this is just referred to as "case-insensitive".
【 と,原文には記されているが、この訳では一律に “~ASCII大小無視” と記すことにする(さして簡便にならないので)。 】
12.1.1. ~DOCTYPE
`~DOCTYPE@ は、要求される “前置き” である。 ◎ A DOCTYPE is a required preamble.
注記: ~DOCTYPEは、旧来の理由から要求される。 省略された場合、~browserは,[ 何らかの仕様と非互換な,異なる具現化~mode ]を利用する傾向にある。 文書~内に~DOCTYPEを含めておけば、[ ~browserは,最善の労をもって関連する仕様に従う ]ことが確保される。 ◎ DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.
~DOCTYPEは、次に与える順の文字~並びで~MUST: ◎ A DOCTYPE must consist of the following components, in this order:
- `~ASCII大小無視$で `<!DOCTYPE^l に合致する文字列 ◎ A string that is an ASCII case-insensitive match for the string "<!DOCTYPE".
- 1 個以上の`~ASCII空白$ ◎ One or more ASCII whitespace.
- `~ASCII大小無視$で `html^l に合致する文字列 ◎ A string that is an ASCII case-insensitive match for the string "html".
- 0 個( “短い~DOCTYPE” )または 1 個の`~DOCTYPE旧来~文字列$ ◎ Optionally, a DOCTYPE legacy string.
- 0 個以上の`~ASCII空白$ ◎ Zero or more ASCII whitespace.
- `003E^U `>^smb ◎ A U+003E GREATER-THAN SIGN character (>).
注記: 言い換えれば、~ASCII大小無視で `<!DOCTYPE html>^l に合致する文字列。 ◎ In other words, <!DOCTYPE html>, case-insensitively.
上の “短い~DOCTYPE” による~HTML~markupを出力できない~HTML生成器の目的においては、~DOCTYPEの中に `~DOCTYPE旧来~文字列@ ( `DOCTYPE legacy string^en )が挿入されても~MAY(上で定義した位置に)。 この文字列は、次に与える順の文字~並びで~MUST: ◎ For the purposes of HTML generators that cannot output HTML markup with the short DOCTYPE "<!DOCTYPE html>", a DOCTYPE legacy string may be inserted into the DOCTYPE (in the position defined above). This string must consist of:
- 1 個以上の`~ASCII空白$ ◎ One or more ASCII whitespace.
- `~ASCII大小無視$で `SYSTEM^l に合致する文字列 ◎ A string that is an ASCII case-insensitive match for the string "SYSTEM".
- 1 個以上の`~ASCII空白$ ◎ One or more ASCII whitespace.
- [ ❝" / ❝' ]( `引用符^i ) ◎ A U+0022 QUOTATION MARK or U+0027 APOSTROPHE character (the quote mark).
- ~literal文字列 "`~about_legacy-compat$" ◎ The literal string "about:legacy-compat".
- 2 つ前に挙げた `引用符^i と同じ文字 ◎ A matching U+0022 QUOTATION MARK or U+0027 APOSTROPHE character (i.e. the same character as in the earlier step labeled quote mark).
注記: 言い換えれば、[ `<!DOCTYPE html SYSTEM "about:legacy-compat">^c / `<!DOCTYPE html SYSTEM 'about:legacy-compat'>^c ]に,引用符で括られた部分は同じになり, 他の部分は~ASCII大小無視で合致する。 ◎ In other words, <!DOCTYPE html SYSTEM "about:legacy-compat"> or <!DOCTYPE html SYSTEM 'about:legacy-compat'>, case-insensitively except for the part in single or double quotes.
`~DOCTYPE旧来~文字列$は、 “短い~DOCTYPE” を出力できない~systemで生成される文書を除き,利用されるべきでない。 ◎ The DOCTYPE legacy string should not be used unless the document is generated from a system that cannot output the shorter string.
12.1.2. 要素
`要素@ ( `element^en )は、次の 6 種に分けられる: ◎ There are six different kinds of elements: void elements, the template element, raw text elements, escapable raw text elements, foreign elements, and normal elements.
- `~void要素@ ( `void element^en )
- `area$e, `base$e, `br$e, `col$e, `embed$e, `hr$e, `img$e, `input$e, `link$e, `meta$e, `param$e, `source$e, `track$e, `wbr$e
- `~template要素@ ( `template element^en )
- `template$e
- `生~text要素@ ( `raw text element^en )
- `script$e, `style$e
- `~escape可能な生~text要素@ ( `escapable raw text element^en )
- `textarea$e, `title$e
- `外来の要素@ ( `foreign element^en )
- [ `~MathML名前空間$ / `~SVG名前空間$ ]に属する要素 ◎ Elements from the MathML namespace and the SVG namespace.
- `通常の要素@ ( `normal element^en )
- 許容される他のすべての`~HTML要素$。 ◎ All other allowed HTML elements are normal elements.
`~tag@ ( `tag^en )は、~markupにおいて要素の始端と終端を区切るために利用される。 [ `生~text要素$ / `~escape可能な生~text要素$ / `通常の要素$ ]には、その 始端を指示する`開始tag$, 終端を指示する`終了tag$ がある。 ある種の`通常の要素$の[ 開始tag/終了tag ]は、下の省略可能な~tag節に述べるように,`省略-$できる。 省略できないものは、省略されては~MUST_NOT。 `~void要素$には、開始tagのみがあり,終了tagは指定されては~MUST_NOT。 `外来の要素$には、開始tagを有していて,かつ その開始tagが[ `自己閉じ$でないならば 終了tagも有してい~MUST / `自己閉じ$であるならば 終了tagを有しては~MUST_NOT ]。 ◎ Tags are used to delimit the start and end of elements in the markup. Raw text, escapable raw text, and normal elements have a start tag to indicate where they begin, and an end tag to indicate where they end. The start and end tags of certain normal elements can be omitted, as described below in the section on optional tags. Those that cannot be omitted must not be omitted. Void elements only have a start tag; end tags must not be specified for void elements. Foreign elements must either have a start tag and an end tag, or a start tag that is marked as self-closing, in which case they must not have an end tag.
要素の`内容$は、開始tagの直後から終了tagの直前までの合間に置かれ~MUST(いずれの~tagも,ある種の事例では黙示され得る)。 個々の要素に許容される正確な内容は、この仕様の他所に述べたように,要素の`内容~model$に依存する。 要素は、その内容~modelに許容されない内容を包含しては~MUST_NOT。 加えて、上の 5 種の要素には追加の構文上の要件もある。 ◎ The contents of the element must be placed between just after the start tag (which might be implied, in certain cases) and just before the end tag (which again, might be implied in certain cases). The exact allowed contents of each individual element depend on the content model of that element, as described earlier in this specification. Elements must not contain content that their content model disallows. In addition to the restrictions placed on the contents by those content models, however, the five types of elements have additional syntactic requirements.
`~void要素$は、内容を有し得ない(終了tagはないので、開始tagと終了tagの合間に置ける内容はない)。 ◎ Void elements can't have any contents (since there's no end tag, no content can be put between the start tag and the end tag).
`~template要素$は`~template内容$を有し得るが, `template$e 要素~自身の子にはならない。 そのような`~template内容$は、主の `Document$I に干渉するのを避けるため,[ `閲覧~文脈$を伴わない, 異なる `Document$I ]に結付けられた `DocumentFragment$I 内に格納される。 `template$e 要素を成す`~template内容$用の~markupは、(他の要素と同じく) `template$e 要素の開始tagの直後から終了tagの直前までに置かれる — それらはどのような[ `~text$, `文字~参照$, `要素$, `~comment$ ]からなっても~MAYが、~textは,文字 `003C^U `<^smb や`多義的amp$を包含しては~MUST_NOT。 ◎ The template element can have template contents, but such template contents are not children of the template element itself. Instead, they are stored in a DocumentFragment associated with a different Document — without a browsing context — so as to avoid the template contents interfering with the main Document. The markup for the template contents of a template element is placed just after the template element's start tag and just before template element's end tag (as with other elements), and may consist of any text, character references, elements, and comments, but but the text must not contain the character U+003C LESS-THAN SIGN (<) or an ambiguous ampersand.
`生~text要素$は、`~text$を内容に有し得る。 また、下に述べる制約もある。 ◎ Raw text elements can have text, though it has restrictions described below.
`~escape可能な生~text要素$は、[ `~text$, `文字~参照$ ]を内容に有し得る — ただし、~textは`多義的amp$を包含しては~MUST_NOT。 また、下に述べる制約もある。 ◎ Escapable raw text elements can have text and character references, but the text must not contain an ambiguous ampersand. There are also further restrictions described below.
`外来の要素$のうち,開始tagが`自己閉じ$とされたものは、内容を有し得ない(これも,終了tagはないので、開始tagと終了tagの合間に置ける内容はない)。 他の`外来の要素$は、[ `~text$, `文字~参照$, `~CDATAsec$, 他の`要素$, `~comment$ ]を内容に有し得る — ただし、~textは[ 文字`003C^U `<^smb / `多義的amp$ ]を包含しては~MUST_NOT。 ◎ Foreign elements whose start tag is marked as self-closing can't have any contents (since, again, as there's no end tag, no content can be put between the start tag and the end tag). Foreign elements whose start tag is not marked as self-closing can have text, character references, CDATA sections, other elements, and comments, but the text must not contain the character U+003C LESS-THAN SIGN (<) or an ambiguous ampersand.
注記: ~HTML構文は、`外来の要素$においても,名前空間~宣言を~supportしない。 ◎ The HTML syntax does not support namespace declarations, even in foreign elements.
具体例として、次の~HTML素片を考える: ◎ For instance, consider the following HTML fragment:
`element-1^xCode最も内縁の要素 `cdr:license^e は、実際には ~SVG名前空間に属する — ~XMLと違って, `xmlns:cdr^l 属性の効果はないので。 上の素片~内の~commentが言ってるように、この素片は,実際には適合していない。 ~SVG仕様は、~SVG名前空間~内に `cdr:license^l と称される要素は定義しないので。 ◎ The innermost element, cdr:license, is actually in the SVG namespace, as the "xmlns:cdr" attribute has no effect (unlike in XML). In fact, as the comment in the fragment above says, the fragment is actually non-conforming. This is because the SVG specification does not define any elements called "cdr:license" in the SVG namespace.
`通常の要素$は、[ `~text$, `文字~参照$, 他の`要素$, `~comment$ ]を内容に有し得る — ただし、~textは[ 文字`003C^U `<^smb / `多義的amp$ ]を包含しては~MUST_NOT。 一部の`通常の要素$には、許容される内容について,[ 内容~modelにより課される制約 / この段落に述べた制約 ]を超えるような制約が,他にもある。 ◎ Normal elements can have text, character references, other elements, and comments, but the text must not contain the character U+003C LESS-THAN SIGN (<) or an ambiguous ampersand. Some normal elements also have yet more restrictions on what content they are allowed to hold, beyond the restrictions imposed by the content model and those described in this paragraph. Those restrictions are described below.
各~tagは、要素の名前を与える `~tag名@ ( `tag name^en )を包含する。 どの~HTML要素も、その名前は`~ASCII英数字$のみからなる。 ~HTML構文においては、~tag名は,`外来の要素$に対しても`~ASCII大小無視$である — すなわち、すべてを小文字~化した結果が要素の~tag名に合致する限り,小文字, 大文字を混ぜて書いても~MAY。 ◎ Tags contain a tag name, giving the element's name. HTML elements all have names that only use ASCII alphanumerics. In the HTML syntax, tag names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the element's tag name; tag names are case-insensitive.
12.1.2.3. 属性
要素の `属性@ ( `attribute^en )は、要素の開始tagの内側にて表される。 各 属性は、名前と値を持つ: ◎ Attributes for an element are expressed inside the element's start tag.
- `属性~名@ ( `attribute name^en )
- 次に挙げるものを除く 1 個以上の文字からなってい~MUST ⇒ `制御文字$ / `0020^U SPACE / ❝" / ❝' / `003E^U `>^smb / ❝/ / ❝= / `非文字$ ◎ Attributes have a name and a value. Attribute names must consist of one or more characters other than controls, U+0020 SPACE, U+0022 ("), U+0027 ('), U+003E (>), U+002F (/), U+003D (=), and noncharacters.\
- ~HTML構文においては、属性~名は,`外来の要素$であっても, `~ASCII英小文字$/`~ASCII英大文字$を混ぜて書いても~MAY。 ◎ In the HTML syntax, attribute names, even those for foreign elements, may be written with any mix of ASCII lower and ASCII upper alphas.
- `属性~値@ ( `attribute value^en )
- `~text$と`文字~参照$の混在 — ただし、~textは`多義的amp$を包含できない。 ◎ Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand.
属性は、次の 4 通りの仕方で指定できる: ◎ Attributes can be specified in four different ways:
- 空~属性~構文 ◎ Empty attribute syntax
- `属性~名$のみ。 値は、暗黙的に空~文字列になる。 ◎ Just the attribute name. The value is implicitly the empty string.
-
次の例の `disabled$a 属性は、空~属性~構文で与えられている: ◎ In the following example, the disabled attribute is given with the empty attribute syntax:
`attribute-1^xCode - ◎ ↓If an attribute using the empty attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two.
- 引用符無しの属性~値~構文 ◎ Unquoted attribute value syntax
-
次に与える順の文字~並び:
- `属性~名$
- 0 個以上の`~ASCII空白$
- ❝=
- 0 個以上の`~ASCII空白$
- 空でない`属性~値$であって,次に挙げる文字は包含しないもの ⇒ `~ASCII空白$ / ❝" / ❝' / ❝= / `003C^U `<^smb / `003E^U `>^smb / ❝`
-
次の例の `value$a 属性は、引用符無しの属性~値~構文で与えられている: ◎ In the following example, the value attribute is given with the unquoted attribute value syntax:
`attribute-2^xCode - この属性~構文を利用している属性に,[ `開始tag$構文の[ `~void要素$/`自己閉じ$ ]に許容される省略可能な ❝/ ]が後続する場合、その 2 つは`~ASCII空白$で分離され~MUST。 ◎ If an attribute using the unquoted attribute syntax is to be followed by another attribute or by the optional U+002F SOLIDUS character (/) allowed in step 6 of the start tag syntax above, then there must be ASCII whitespace separating the two. ↓
- 一重引用符付き属性~値~構文 ◎ Single-quoted attribute value syntax
-
次に与える順の文字~並び:
- `属性~名$
- 0 個以上の`~ASCII空白$
- ❝=
- 0 個以上の`~ASCII空白$
- ❝'
- `属性~値$の要件を満たす文字列であって,~literal ❝' を包含しないもの
- ❝'
-
次の例の `type$a 属性は、一重引用符付き属性~値~構文で与えられている: ◎ In the following example, the type attribute is given with the single-quoted attribute value syntax:
`attribute-3^xCode - ◎ ↓If an attribute using the single-quoted attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two.
- 二重引用符付き属性~値~構文 ◎ Double-quoted attribute value syntax
-
次に与える順の文字~並び:
- `属性~名$
- 0 個以上の`~ASCII空白$
- ❝=
- 0 個以上の`~ASCII空白$
- ❝"
- `属性~値$の要件を満たす文字列であって,~literal ❝" を包含しないもの
- ❝"
-
次の例の `name$a 属性は、二重引用符付き属性~値~構文で与えられている: ◎ In the following example, the name attribute is given with the double-quoted attribute value syntax:
`attribute-4^xCode - ◎ ↓If an attribute using the double-quoted attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two.
同じ開始tag内にある複数の属性は:
- 利用する属性~構文が何であれ、`~ASCII空白$で互いに分離され~MUST。
- 互いの名前は`~ASCII大小無視$で合致しては~MUST_NOT。
`外来の要素$が有する名前空間付き属性のうち,次の表の いずれかの行の ( 1 列目, 2 列目 ) に与える ( 局所~名, 名前空間 ) を持つものは、同じ行の 3 列目に与える名前として書かれ~MUST。 ◎ When a foreign element has one of the namespaced attributes given by the local name and namespace of the first and second cells of a row from the following table, it must be written using the name given by the third cell from the same row.
局所~名 | 名前空間 | 属性~名 |
---|---|---|
`actuate^a | `~XLink名前空間$ | `xlink:actuate^a |
`arcrole^a | `~XLink名前空間$ | `xlink:arcrole^a |
`href^a | `~XLink名前空間$ | `xlink:href^a |
`role^a | `~XLink名前空間$ | `xlink:role^a |
`show^a | `~XLink名前空間$ | `xlink:show^a |
`title^a | `~XLink名前空間$ | `xlink:title^a |
`type^a | `~XLink名前空間$ | `xlink:type^a |
`lang^a | `~XML名前空間$ | `xml:lang^a |
`space^a | `~XML名前空間$ | `xml:space^a |
`xmlns^a | `~XMLNS名前空間$ | `xmlns^a |
`xlink^a | `~XMLNS名前空間$ | `xmlns:xlink^a |
`~HTML構文$においては、他の名前空間付き属性は表せない。 ◎ No other namespaced attribute can be expressed in the HTML syntax.
注記: 上の表~内の属性が適合するかどうかは、他の仕様(例: ~SVG /~MathML仕様)にて定義される。 この節は、これらの属性が~HTML構文を用いて直列化された場合の構文~規則のみを述べる。 ◎ Whether the attributes in the table above are conforming or not is defined by other specifications (e.g. the SVG and MathML specifications); this section only describes the syntax rules if the attributes are serialized using the HTML syntax.
12.1.2.5. 内容~modelに課される制約
歴史的~理由から、ある種の要素には,その内容~modelに与えた制約を超えるような更なる制約がある。 ◎ For historical reasons, certain elements have extra restrictions beyond even the restrictions given by their content model.
`table$e 要素は `tr$e 要素を~~直に包含しては~MUST_NOT — `tr$e 要素は、技術的には,この仕様に述べた内容~modelに則って `table$e 要素の内側に許容されているが。 (~markup内で `tr$e 要素が `table$e の内側に~~直に置かれた場合、その前に `tbody$e 開始tagを黙示することになる。) ◎ A table element must not contain tr elements, even though these elements are technically allowed inside table elements according to the content models described in this specification. (If a tr element is put inside a table in the markup, it will in fact imply a tbody start tag before it.)
[ `pre$e / `textarea$e ]要素の`開始tag$の直後には、 1 個の`改行文字$が置かれても~MAY。 これは、要素の処理に影響しない — すなわち,要素の内容には含まれない。 これ以外の後続の`改行文字$は、要素の内容に含められ~MUST(さもなければ, 内容~内の頭部の改行文字は、省略可能な改行文字の様に扱われ,無視されることになるので)。 ◎ A single newline may be placed immediately after the start tag of pre and textarea elements. This does not affect the processing of the element. The otherwise optional newline must be included if the element's contents themselves start with a newline (because otherwise the leading newline in the contents would be treated like the optional newline, and ignored).
次の 2 個の `pre$e ~blockは、等価になる: ◎ The following two pre blocks are equivalent:
`content-1^xCode `content-2^xCode12.1.2.6. 生~text要素/~escape可能な生~text要素の内容に課される制約
[ `生~text要素$/`~escape可能な生~text要素$ ]内の~textは、次に与える順の文字~並びを包含しては~MUST_NOT:
- `003C^U `<^smb
- ❝/
- 要素の~tag名に`~ASCII大小無視$で合致する文字~並び
- `~ASCII空白$ / `003E^U `>^smb / ❝/
12.1.3. ~text
`~text@ ( `text^en )は、[ `要素$/ `属性~値$ / `~comment$ ]の内側に許容される。 加えて,他の節にて述べられるように、~textが置かれる所に基づいて, ~text内に何が許容され何が許容されないかの拘束が更に課される。 ◎ Text is allowed inside elements, attribute values, and comments. Extra constraints are placed on what is and what is not allowed in text based on where the text is to be put, as described in the other sections.
12.1.3.1. 改行文字
~HTMLにおける `改行文字@ ( `newline^en )は、次のいずれかで表現されて~MAY:
- `000D^U CARRIAGE RETURN `CR^smb
- `000A^U LINE FEED `LF^smb
-
次に与える順の文字~並び:
- `000D^U `CR^smb
- `000A^U `LF^smb
`文字~参照$が許容される所では、 `000A^U `LF^smb を表す文字~参照も`改行文字$を表現する(が、 `000D^U `CR^smb 表す文字~参照はそうでない)。 ◎ Where character references are allowed, a character reference of a U+000A LINE FEED (LF) character (but not a U+000D CARRIAGE RETURN (CR) character) also represents a newline.
12.1.4. 文字~参照
他の節にて述べたある種の事例においては、`~text$には `文字~参照@ ( `character reference^en )を混ぜても~MAY。 これを利用すれば、さもなければ`~text$内に合法に含めれない文字を~escapeできる。 ◎ In certain cases described in other sections, text may be mixed with character references. These can be used to escape characters that couldn't otherwise legally be included in text.
文字~参照は、 `0026^U `&^smb から開始され,次の 3 種いずれかが後続してい~MUST: ◎ Character references must start with a U+0026 AMPERSAND character (&). Following this, there are three possible kinds of character references:
- 有名~文字~参照: ◎ Named character references
-
次に与える順の文字~並び:
- `有名~文字~参照$ 節に与えるいずれかの名前(文字大小は区別される)
- ❝;
- 10 進~数的な文字~参照: ◎ Decimal numeric character reference
-
次に与える順の文字~並び:
- ❝#
- 1 個以上の`~ASCII数字$からなる並びであって,[ 下の定義に則って許容される符号位置 ]に対応する基数 10 の整数を表現するもの
- ❝;
- 16 進~数的な文字~参照: ◎ Hexadecimal numeric character reference
-
次に与える順の文字~並び:
- ❝#
- [ ❝x / ❝X ]
- 1 個以上の`~ASCII~hex数字$からなる並びであって,[ 下の定義に則って許容される符号位置 ]に対応する基数 16 の整数を表現するもの
- ❝;
上に述べた[ 数的な文字~参照 ]の形では、次を除く符号位置を参照することが許容される ⇒ `000D^U `CR^smb / `非文字$ /[ `制御文字$のうち`~ASCII空白$でないもの ] ◎ The numeric character reference forms described above are allowed to reference any code point excluding U+000D CR, noncharacters, and controls other than ASCII whitespace.
`0026^U `&^smb は、次に与える順の文字~並びが後続するならば, `多義的amp@ ( `ambiguous ampersand^en )とされる:
- 1 個以上の`~ASCII英数字$からなる並びであって,`有名~文字~参照$ 節に与えるどの名前にも合致しないもの
- ❝;
12.1.5. ~CDATAsec
`~CDATAsec@ ( `CDATA section^en )は、次に与える順の文字~並びで~MUST: ◎ CDATA sections must consist of the following components, in this order:
- 文字列 `<![CDATA[^l ◎ The string "<![CDATA[".
- 0 〜 1 個の[ `~text$であって,文字列 `]]>^l を包含しないもの ] ◎ Optionally, text, with the additional restriction that the text must not contain the string "]]>".
- 文字列 `]]>^l ◎ The string "]]>".
~CDATAsecを利用できるのは、外来の内容(~MathML/~SVG)内に限られる。 この例では、~CDATAsecを利用して,~MathML `ms$e 要素の内容を~escapeしている: ◎ CDATA sections can only be used in foreign content (MathML or SVG). In this example, a CDATA section is used to escape the contents of a MathML ms element:
`CDATA-1^xCode12.2. ~HTML文書の構文解析-法
【 この節の内容は、別ページにて。 】
12.3. ~HTML素片の直列化-法
`~HTML素片~直列化~algo@ は、所与の ~DOM[ `Element$I / `Document$I / `DocumentFragment$I ]~node %~node に対し,文字列を返す: ◎ The following steps form the HTML fragment serialization algorithm. The algorithm takes as input a DOM Element, Document, or DocumentFragment referred to as the node, and returns a string.
注記: この~algoは、 %~node 自身ではなく,その子たちを直列化する。 ◎ This algorithm serializes the children of the node being serialized, not the node itself.
- %s ~LET 空~文字列 ◎ Let s be a string, and initialize it to the empty string.
- ~IF[ %~node は `template$e 要素である ] ⇒ %~node ~SET %~node の`~template内容$( `DocumentFragment$I ~node ) ◎ If the node is a template element, then let the node instead be the template element's template contents (a DocumentFragment node).
- %~node の~EACH( 子~node %現~node ) に対し,`木~順序$で ⇒ %s に[ 下に与える %現~node を “直列化する下位手続き” を走らせた結果 ]を付加する ◎ For each child node of the node, in tree order, run the following steps: ◎ Let current node be the child node being processed. ◎ Append the appropriate string from the following list to s:
- ~RET %s ◎ ↓↓
上の目的における %現~node を “直列化する下位手続き” は、 %現~node に応じて,次を走らす: ◎ ↑
- `Element^I である ◎ If current node is an Element
-
- %結果 ~LET 空~文字列 ◎ ↓
- %~tag名 ~LET [ %現~node は[ `~HTML名前空間$ / `~MathML名前空間$ / `~SVG名前空間$ ]に属するならば %現~node の局所~名 / ~ELSE_ %現~nodeの有修飾~名 ] ◎ If current node is an element in the HTML namespace, the MathML namespace, or the SVG namespace, then let tagname be current node's local name. Otherwise, let tagname be current node's qualified name.
- %結果 に `003C^U `<^smb を付加する ◎ ↓
-
%結果 に %~tag名 を付加する ◎ Append a U+003C LESS-THAN SIGN character (<), followed by tagname.
注記: [ `~HTML構文解析器$ / `createElement()$m ]により作成された`~HTML要素$に対しては、 %~tag名 は小文字になる。 ◎ For HTML elements created by the HTML parser or createElement(), tagname will be lowercase.
-
~IF[ %現~node の`~is0値$ ~NEQ ~NULL ]~AND[ %現~node は `is$a 属性を有さない ] ⇒ %結果 に次に与える文字~並びを順に付加する:
- ` is="^l
- %現~node の`~is0値$を`属性~mode^iの下で`~escape$した結果
- `0022^U `"^smb
-
%現~node が有する ~EACH( 属性 %属性 ) に対し ⇒ %結果 に次に与える文字~並びを順に付加する:
- `0020^U SPACE
- %属性 の`直列形の名前$
- ❝=
- ❝"
- %属性 の値を`属性~mode^iの下で`~escape$した結果
- ❝"
この段の目的における %属性 の `直列形の名前@ は、 %属性 が属する名前空間に応じて,次にされ~MUST: ◎ An attribute's serialized name for the purposes of the previous paragraph must be determined as follows:
- なし ◎ If the attribute has no namespace
- %属性 の局所~名 ◎ The attribute's serialized name is the attribute's local name.
- 注記: `~HTML要素$において,[ `~HTML構文解析器$ / `Element.setAttribute()^m ]により設定された属性に対しては、局所~名は小文字になる。 ◎ For attributes on HTML elements set by the HTML parser or by Element.setAttribute(), the local name will be lowercase.
- `~XML名前空間$ ◎ If the attribute is in the XML namespace
-
次に与える順の文字~並び:
- 文字列 `xml:^l
- %属性 の局所~名
- `~XMLNS名前空間$
-
%属性 の局所~名 ~EQ `xmlns^c ならば 文字列 `xmlns^l / ~ELSE_ 次に与える順の文字~並び:
- 文字列 `xmlns:^l
- %属性 の局所~名
- `~XLink名前空間$ ◎ If the attribute is in the XLink namespace
-
次に与える順の文字~並び:
- 文字列 `xlink:^l
- %属性 の局所~名
- その他の名前空間 ◎ If the attribute is in some other namespace
- %属性 の有修飾~名 ◎ The attribute's serialized name is the attribute's qualified name.
属性たちの正確な順序は~UAにより定義され,元の~markupにて属性が与えられた順序などの要因にも依存し得るが、~sort順序は,安定的 — すなわち、要素に対しこの~algoを続けて呼出しても,属性たちが直列化される順序は同じ — で~MUST。 ◎ While the exact order of attributes is UA-defined, and may depend on factors such as the order that the attributes were given in the original markup, the sort order must be stable, such that consecutive invocations of this algorithm serialize an element's attributes in the same order.
- %結果 に `003E^U `>^smb を付加する ◎ Append a U+003E GREATER-THAN SIGN character (>).
- ~IF[ %現~node は[ `area$e / `base$e / `basefont$e / `bgsound$e / `br$e / `col$e / `embed$e / `frame$e / `hr$e / `img$e / `input$e / `keygen$e / `link$e / `meta$e / `param$e / `source$e / `track$e / `wbr$e ]要素である ] ⇒ ~RET %結果 ◎ If current node is an area, base, basefont, bgsound, br, col, embed, frame, hr, img, input, keygen, link, meta, param, source, track or wbr element, then continue on to the next child node at this point.
-
%結果 に次に与える順の文字~並びを付加する:
- %現~node に対し`~HTML素片~直列化~algo$を(再帰的に)走らせた結果
- `003C^U `<^smb
- ❝/
- %~tag名
- `003E^U `>^smb
- ~RET %結果 ◎ ↑
- `Text^I である ◎ If current node is a Text node
-
- %data ~LET %現~node の `data^m ~IDL属性の値
- ~IF[ %現~node の親は[ `style$e / `script$e / `xmp$e / `iframe$e / `noembed$e / `noframes$e / `plaintext$e ]要素である ] ⇒ ~RET %data
- ~IF[ %現~node の親は `noscript$e 要素である ]~AND[ %現~node に対する`~scriptingは可能化-$されている ] ⇒ ~RET %data
- ~RET %data を`~escape$した結果
- `Comment^I である ◎ If current node is a Comment
-
~RET 次に与える順の文字~並び
- `003C^U `<^smb
- ❝!
- ❝-
- ❝-
- %現~node の `data^m ~IDL属性の値
- ❝-
- ❝-
- `003E^U `>^smb
- `ProcessingInstruction^I である ◎ If current node is a ProcessingInstruction
-
~RET 次に与える順の文字~並び:
- `003C^U `<^smb
- ❝?
- %現~node の `target^m ~IDL属性の値
- `0020^U SPACE
- %現~node の `data^m ~IDL属性の値
- `003E^U `>^smb
- `DocumentType^I である ◎ If current node is a DocumentType
-
~RET 次に与える順の文字~並び:
- `003C^U `<^smb
- ❝!
- ❝D
- ❝O
- ❝C
- ❝T
- ❝Y
- ❝P
- ❝E
- `0020^U SPACE
- %現~node の `name^m ~IDL属性の値
- `003E^U `>^smb
◎ The result of the algorithm is the string s.
`~HTML素片~直列化~algo$の出力を`~HTML構文解析器$で構文解析した結果は、元の木~構造にならない~~可能性もある。 直列化して再解析する段を往来しないような木~構造は、`~HTML構文解析器$ 自身からも生産され得る — そのような事例は、概して,適合していないが。 ◎ It is possible that the output of this algorithm, if parsed with an HTML parser, will not return the original tree structure. Tree structures that do not roundtrip a serialize and reparse step can also be produced by the HTML parser itself, although such cases are typically non-conforming.
具体例として, `textarea$e 要素に `Comment^I ~nodeが付加されていた場合、要素を直列化して再解析した結果の~commentは,~text~control内に表示されることになる。 同様に、~DOM操作による結果,要素が[ 文字列 `-->^l をそのまま包含するような~comment ]を包含する場合、要素を直列化して再解析した結果の~commentは,その地点で切落とされ、残りの部分は~markupとして解釈されることになる。 他にも、 `script$e 要素に文字列 `</script>^l を伴う `Text$I ~nodeを包含させた場合や, `p$e 要素に `ul$e 要素を包含させた場合などが挙げられる( `ul$e 要素の`開始tag$は `p$e に対する終了tagを黙示するので)。 ◎ For instance, if a textarea element to which a Comment node has been appended is serialized and the output is then reparsed, the comment will end up being displayed in the text control. Similarly, if, as a result of DOM manipulation, an element contains a comment that contains the literal string "-->", then when the result of serializing the element is parsed, the comment will be truncated at that point and the rest of the comment will be interpreted as markup. More examples would be making a script element contain a Text node with the text string "</script>", or having a p element that contains a ul element (as the ul element's start tag would imply the end tag for the p).
これは、~XSS攻撃を可能化し得る。 例えば,ある頁において、利用者に何らかの~font-family名を手入力してもらい,それを~DOMを介して ~CSS `style$e ~blockの中に挿入してから, `innerHTML$m ~IDL属性を用いて `style$e 要素の~HTML直列化を取得しているとする。 利用者が~font-family名として `</style><script>攻撃~code</script>^l を手入力した場合、 `innerHTML$m は[ 他の文脈にて構文解析されたときには,元の~DOM内には存在しない `script$e ~nodeを包含することになる ]ような~markupを返すことになる。 ◎ This can enable cross-site scripting attacks. An example of this would be a page that lets the user enter some font family names that are then inserted into a CSS style block via the DOM and which then uses the innerHTML IDL attribute to get the HTML serialization of that style element: if the user enters "</style><script>attack</script>" as a font family name, innerHTML will return markup that, if parsed in a different context, would contain a script node, even though no script node existed in the original DOM.
例えば、次の~markupを考える: ◎ For example, consider the following markup:
`serializing-1^xCodeこれを構文解析した結果は次になる: ◎ This will be parsed into:
- `html$e
- `head$e
- `body$e
- `form$e `id$a=`outer^l
- `div$e
- `form$e `id$a=`inner^l
- `input$e
- `form$e `id$a=`inner^l
- `div$e
- `form$e `id$a=`outer^l
`input$e 要素は、内縁 `form$e 要素( `inner^l )に所有されることになる。 ここで,この木~構造が直列化され再解析された場合、開始tag `<form id="inner">^e は無視されることになり, `input$e 要素は 外縁 `form$e 要素に所有されることになる。 ◎ The input element will be associated with the inner form element. Now, if this tree structure is serialized and reparsed, the <form id="inner"> start tag will be ignored, and so the input element will be associated with the outer form element instead.
`serializing-2^xCode- `html$e
- `head$e
- `body$e
- `form$e `id$a=`outer^l
- `div$e
- `input$e
- `div$e
- `form$e `id$a=`outer^l
別の例として、次の~markupを考える: ◎ As another example, consider the following markup:
`serializing-3^xCodeこれを構文解析した結果は次になる: ◎ This will be parsed into:
- `html$e
- `head$e
- `body$e
- `a$e
- `a$e
- `table$e
- `a$e
すなわち、2 個の `a$e 要素は入子にされる — 2 個目の `a$e は`親が違えられ$るので。 直列化して再解析する往来~後には、[ `table$e, 2 個の `a$e ]要素は,互いに同胞になる — 2 個目の開始tag `<a>^c が, 1 個目の `a$e 要素を暗黙的に閉じるので。 ◎ That is, the a elements are nested, because the second a element is foster parented. After a serialize-reparse roundtrip, the a elements and the table element would all be siblings, because the second <a> start tag implicitly closes the first a element.
`serializing-4^xCode- `html$e
- `head$e
- `body$e
- `a$e
- `a$e
- `table$e
歴史的な理由から、この~algoでは,[ `pre$e / `textarea$e / `listing$e ]要素~内の先頭の `000A^U `LF^smb 文字は往来しない — ~markupが適合していようが(廃用にされた `listing^e は適合し得ないが)。 `~HTML構文解析器$は、構文解析-時にそのような文字を落とすことになるが、この~algoは,落とされた `000A^U `LF^smb を直列化することはない。 ◎ For historical reasons, this algorithm does not round-trip an initial U+000A LINE FEED (LF) character in pre, textarea, or listing elements, even though (in the first two cases) the markup being round-tripped can be conforming. The HTML parser will drop such a character during parsing, but this algorithm does not serialize an extra U+000A LINE FEED (LF) character.
例えば、次の~markupを考える: ◎ For example, consider the following markup:
`serializing-5^xCodeこの文書を最初に構文解析したとき、この `pre$e 要素の`子~text内容$の頭部にある改行文字は, 1 個だけに減る。 直列化して再解析する往来~後には、また 1 個~減り,`子~text内容$は `Hello.^l だけになる。 ◎ When this document is first parsed, the pre element's child text content starts with a single newline character. After a serialize-reparse roundtrip, the pre element's child text content is simply "Hello.".
`is$a 属性は、`~custom化された組込みの要素$の作成を通達するときに,特別な役割を果たす — そこでは、構文解析された~HTML用に,要素の`~is0値$を設定する仕組みが供される — ので、直列化の間に特別に取扱われる。 これは、直列化して構文解析する往来を通しても,要素の`~is0値$は保全されることを確保する。 ◎ Because of the special role of the is attribute in signaling the creation of customized built-in elements, in that it provides a mechanism for parsed HTML to set the element's is value, we special-case its handling during serialization.This ensures that an element's is value is preserved through serialize-parse roundtrips.
構文解析器を介して,`~custom化された組込みの要素$を作成するとき、開発者は `is$a 属性を直に利用する — そのような事例では、往来は申し分なく働く。 ◎ When creating a customized built-in element via the parser, a developer uses the is attribute directly; in such cases serialize-parse roundtrips work fine.
<script> window.SuperP = class extends HTMLParagraphElement {}; customElements.define("super-p", SuperP, { extends: "p" }); </script> <div id="container"><p is="super-p">Superb!</p></div> <script> console.log(%container.innerHTML); // <p is="super-p"> %container.innerHTML = %container.innerHTML; console.log(%container.innerHTML); // <p is="super-p"> console.assert(%container.firstChild instanceof SuperP); </script>
一方で,~custom化された組込みの要素を[ その`~custom要素~構築子$/ `createElement()$m ]を介して作成した場合、 `is$a 属性は追加されない。 代わりに,`~is0値$(それが~custom要素の機構が利用するものである)は、属性を仲介することなく設定される。 ◎ But when creating a customized built-in element via its constructor or via createElement(), the is attribute is not added. Instead, the is value (which is what the custom elements machinery uses) is set without intermediating through an attribute.
<script> %container.innerHTML = ""; const %p = document.createElement("p", { is: "super-p" }); %container.appendChild(p); /* ~DOM内には `is^a 属性は無い: ◎ The is attribute is not present in the DOM: */ console.assert(!p.hasAttribute("is")); /* が、要素は依然として `super-p^e である: ◎ But the 要素は is still a super-p: */ console.assert(%p instanceof SuperP); </script>
往来が依然として働くことを確保するため、直列化~処理-では,要素の`~is0値$を明示的に `is$a 属性として書き出す: ◎ To ensure that serialize-parse roundtrips still work, the serialization process explicitly writes out the element's is value as an is attribute:
<script> console.log(%container.innerHTML); // <p is="super-p"> %container.innerHTML = %container.innerHTML; console.log(%container.innerHTML); // <p is="super-p"> console.assert(%container.firstChild instanceof SuperP); </script>
(上の~algoの目的において)所与の %文字列 を `~escape@ するときは、次の手続きを走らす: ◎ Escaping a string (for the purposes of the algorithm above) consists of running the following steps:
- %文字列 内の各~文字 `&^l を文字列 `&^l に置換する ◎ Replace any occurrence of the "&" character by the string "&".
- %文字列 内の各~文字 `00A0^U NO-BREAK SPACE を文字列 ` ^l に置換する ◎ Replace any occurrences of the U+00A0 NO-BREAK SPACE character by the string " ".
- ~IF[ この~algoは `属性~mode^i で呼出されている ] ⇒ %文字列 内の各~文字 `"^l を文字列 `"^l に置換する ◎ If the algorithm was invoked in the attribute mode, replace any occurrences of the """ character by the string """.
-
~ELSE:
- %文字列 内の各~文字 `<^l を文字列 `<^l に置換する
- %文字列 内の各~文字 `>^l を文字列 `>^l に置換する
12.4. ~HTML素片の構文解析-法
【 この節の内容は、別ページにて。 】
12.5. 有名~文字~参照
【 この節の内容は、別ページにて。 】
12.1.6. ~comment
`~comment@ ( `comment^en )は、次に与える順の文字~並びで~MUST: ◎ Comments must have the following format:
次をすべて満たすような`~text$:
(特に,空~文字列はこれらを満たす)
◎ Optionally, text, with the additional restriction that the text must not start with the string ">", nor start with the string "->", nor contain the strings "<!--", "-->", or "--!>", nor end with the string "<!-".注記: `~text$は 文字列 `<!^l で終端することは 許容される — 次の様に: `<!--お気に入りの演算子は: > と <!-->^c ◎ The text is allowed to end with the string "<!", as in <!--My favorite operators are > and <!-->.