1.7.1. ~script実行の直列化-能

~multithreadingの複階性を~web作者に公開するのを避けるため、 ~HTMLと各種~DOM~APIは，どの~scriptも — `Worker$I であっても — 他の~scriptの同時的な実行を検出し得ない【したがって依存し得ない】ように設計されている。 その意図は、 実装の挙動を［ すべての大域~obj内のすべての~scriptの実行は、 完全に直列化される ］ものとして捉えれるようにすることにある。 ◎ To avoid exposing web authors to the complexities of multithreading, the HTML and DOM APIs are designed such that no script can ever detect the simultaneous execution of other scripts. Even with workers, the intent is that the behavior of implementations can be thought of as completely serializing the execution of all scripts in all globals.

この一般的な設計~原則の例外は、 ~JSの `SharedArrayBuffer$I ~classである。 事実、 `SharedArrayBuffer^I ~objを利用すれば， 他の`~agent$内の~scriptが同時的に実行しているのを観測できる。 さらには，~JS~memory~modelに因り、 それらの~scriptどうしでは，［ 直列化された`~script^emの実行を介することでは表現-不能のみならず，直列化された`~statement^emの実行を介することでも表現-不能 ］な状況がある。【何が表現-不能？】 ◎ The exception to this general design principle is the JavaScript SharedArrayBuffer class. Using SharedArrayBuffer objects, it can in fact be observed that scripts in other agents are executing simultaneously. Furthermore, due to the JavaScript memory model, there are situations which not only are un-representable via serialized script execution, but also un-representable via serialized statement execution among those scripts.

1.7.2. 拡張能

~HTMLには、 安全な方式で意味論を追加するために利用できる，多種多様な拡張能の仕組みがある： ◎ HTML has a wide array of extensibility mechanisms that can be used for adding semantics in a safe manner:

• 作者は、 `class$a 属性を利用して要素を拡張することにより， 実質的に自前の要素を作成できる — ［ ~browserや他の~toolが、 その拡張を知らずとも，それをいくぶん きちんと~supportできる ］よう，最も適用-可能な既存の “本物の” ~HTML要素を利用する下で。 これは例えば、 ~microformatが利用する索を成す。 ◎ Authors can use the class attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by microformats, for example.
• 作者は、 `data-*$a 属性を利用して，`~script$【！inline client-side scripts or server-side site-wide scripts】が処理するための~dataを内包できる。 これらは、 ~browserからは決して触れられないことが保証され，［ ~scriptが後で探し出して処理できる~data ］を~HTML要素に内包することを~scriptに許容する。 ◎ Authors can include data for inline client-side scripts or server-side site-wide scripts to process using the data-*="" attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
• 作者は、 `meta$e 要素の［ `name^a 属性, `content^a 属性 ］の仕組みを利用して，~page全般~用の~metadataを内包できる。 ◎ Authors can use the <meta name="" content=""> mechanism to include page-wide metadata.
• 作者は、 `rel$a 属性の仕組みを利用して［ `定義済みな~link型の集合に対する拡張$を登録する ］ことにより，~linkに特定の意味を注釈できる。 これは、 ~microformatでも利用される。 ◎ Authors can use the rel="" mechanism to annotate links with specific meanings by registering extensions to the predefined set of link types. This is also used by microformats.
• 作者は、 ~customな型を伴う `script$e の仕組みを利用して， `~script$【！inline or server-side scripts】による更なる取扱い用に生の~dataを埋込める。 ◎ Authors can embed raw data using the <script type=""> mechanism with a custom type, for further handling by inline or server-side scripts.
• 作者は、 ~JSによる~prototype法の仕組みを利用して， ~APIを拡張できる。 これは、 一例として，~script~libraryで広く利用されている。 ◎ Authors can extend APIs using the JavaScript prototyping mechanism. This is widely used by script libraries, for instance.
• 作者は、 ~microdata特能（ `itemscope$a 属性, `itemprop$a 属性）を利用して， 入子な［ 名前, 値 ］が成す~pairたちを［ 他の~appや~siteと共有される~data ］として埋込める。 ◎ Authors can use the microdata feature (the itemscope="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
• 作者は、 `~custom要素$を［ 定義する／共有する／利用する ］ことで，~HTMLの語彙を拡張できる。 `妥当な~custom要素~名$を成すための要件は、 前方-互換性を確保する （将来に［ ~hyphenを包含している局所~名を伴う要素 ］が［ ~HTML ／ ~SVG ／ ~MathML ］に追加されることはないので）。 ◎ Authors can define, share, and use custom elements to extend the vocabulary of HTML. The requirements of valid custom element names ensure forward compatibility (since no elements will be added to HTML, SVG, or MathML with hyphen-containing local names in the future).

1.9.1. この仕様を読む方法

この仕様は、 他のすべての仕様と同じ様に読むべきである。 まずは、 全編を通して複数回 読むべきである。 次に、 少なくとも 1 回は後ろから読むべきである。 それから、 目次から~randomに節を選び取って，すべての相互-参照を追いながら読むべきである。 ◎ This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references.

`§ 適合性の要件＠~HTMLINFRA#conformance-classes$ に述べられるとおり，この仕様は、 各種 適合性~class用に適合性の判定基準を述べる。 特に，適合性~要件には、 `生産器^em（例：作者, 作者が作成する文書）に適用されるもの, `消費器^em（例：~web~browser）に適用されるものがある。 これらの要件は、 それが何を要求しているかにより判別できる — 生産器に対する要件は，何が許容されるかを言明する一方で、 消費器に対する要件は，~softwareがどう動作するかを言明する。 ◎ As described in the conformance requirements section below, this specification describes conformance criteria for a variety of conformance classes. In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.

生産器に対する要件は、 消費器に対する要件とは何ら~~関係ない。 ◎ Requirements on producers have no bearing whatsoever on consumers.

1.9.2. ~~表記上の規約

【 以下に呈示される~styleには、 （~markupは同じでも）原文から違えているものもある （より細かい~~分類に応じて，異なる色を利用するなど）。 】

これは、［ 定義／要件／説明 ］。 【特定の~styleは伴わない。】 ◎ This is a definition, requirement, or explanation.

これは、 注記。 ◎ This is a note.

これは、 例。 ◎ This is an example.

これは、 ~openな課題。 ◎ This is an open issue.

これは、 警告。 ◎ This is a warning.

[Exposed=Window]
interface Example {
  /* 
これは~IDL定義。
◎
this is an IDL definition
 */
};

%variable = %object.method([ %optionalArgument ])

これは、 ある~interfaceの用法を述べている，作者~向けの注記。 ◎ This is a note to authors describing the usage of an interface.

/* 
これは~CSS~code片。
◎
this is a CSS fragment
 */

ある用語の~instanceを定義するときは、 この様に ~mark-upされる。 その用語の利用は、［ `この様に＠#_this-0$／ `この様に＠#_this-0$i ］~mark-upされる。 ◎ The defining instance of a term is marked up like this. Uses of that term are marked up like this or like this.

［ 要素／属性／~API ］を定義している~instanceは、 それが "this" と命名されるなら，［ `this＠#_this-1@e ／ `this＠#_this-2@a ／ `this＠#_this-3@m ］の様に~mark-upされる。 その［ 要素／属性／~API ］への参照は、［ `this＠#_this-1$e ／ `this＠#_this-2$a ／ `this＠#_this-3$m ］の様に~mark-upされる。 ◎ The defining instance of an element, attribute, or API is marked up like this. References to that element, attribute, or API are marked up like this.

他の~code片は、 `example code^c の様に~mark-upされる。 ◎ Other code fragments are marked up like this.

変数は、 %この様に ~mark-upされる。 ◎ Variables are marked up like this.

ある~algo内の`同期区間$を成す各~段には、 ⌛ が付与される。 ◎ In an algorithm, steps in synchronous sections are marked with ⌛.

一部の事例では、 要件は，何個かの［ 条件（たち）, それに対応する要件 ］からなる~listによる形で与えられる。 そのような事例で適用される要件は、 最初に該当する条件に対応する要件になる。 そのような事例は、 次のように呈示される： ◎ In some cases, requirements are given in the form of lists with conditions and corresponding requirements. In such cases, the requirements that apply to a condition are always the first set of requirements that follow the condition, even in the case of there being multiple sets of conditions for those requirements. Such cases are presented as follows:

これは、 ある条件 ◎ This is a condition

これは、 別の条件 ◎ This is another condition

これは、 上の条件に適用される要件。 ◎ This is the requirement that applies to the conditions above.

これは、 第三の条件 ◎ This is a third condition

これは、 第三の条件に適用される要件。 ◎ This is the requirement that applies to the third condition.

【 これは，［ ~IF, ~ELIF, ..., ~ELSE ］からなる一連の段で記しても論理的に同じなので、 和訳では，そのように記すこともある。 】

1.10.1. ~HTMLによる~secureな~appの書き方

~HTMLを利用してヤリトリありな~siteを作成するときは、 脆弱性 — 攻撃者が それを通して［ ~site自体や~siteの利用者 ］【の~data】の完全性を弱体化し得るような脆弱性 — を導入するのを避けるよう~careする必要がある。 ◎ When HTML is used to create interactive sites, care needs to be taken to avoid introducing vulnerabilities through which attackers can compromise the integrity of the site itself or of the site's users.

この問題mについての包括的な研究は，この文書の視野を超えるが、 作者には，当の問題mの詳細を もっと研究することが強く奨励される。 しかしながら，この節では、 ~HTMLの~app開発において共通的な陥穽のうち一部について，簡易な導入を供するよう試みる。 ◎ A comprehensive study of this matter is beyond the scope of this document, and authors are strongly encouraged to study the matter in more detail. However, this section attempts to provide a quick introduction to some common pitfalls in HTML application development.

~webの~security~modelは、 “生成元（ `origins^en ）” の概念に基づく。 それに対応して、 ~web上にあり得る攻撃の多くは，非同一-生成元による動作を孕む。 `ORIGIN$r ◎ The security model of the web is based on the concept of "origins", and correspondingly many of the potential attacks on the web involve cross-origin actions. [ORIGIN]

利用者-入力を検証しないとき ◎ Not validating user input

~XSS（ `cross-site scripting^en ） ◎ Cross-site scripting (XSS)

~SQL注入 ◎ SQL injection

信用できない入力 — 例： 利用者が生成した内容 ~text~comment, ~URL~parameter内の値, 第三者-主体~siteからの~message, 等々 — を受容するときは、 それらの~dataを［ 利用する前に検証すること，および 適正に~escapeした上で表示する ］ことが絶対要件である。 これを行うのに失敗した場合、 各種~攻撃を遂行することを敵対的な利用者に許容し得る — それは、 善意的にもなり得るものから, デタラメな利用者~情報（例：負な年齢）を供するもの, 深刻なもの（例：利用者が その情報を内包する~pageを見るたびに毎回~scriptを走らすような）, 果ては壊滅的になるもの（例：当の~process内の攻撃が伝播して，~server内のすべての~dataを削除するなど）までに至り得る。 ◎ When accepting untrusted input, e.g. user-generated content such as text comments, values in URL parameters, messages from third-party sites, etc, it is imperative that the data be validated before use, and properly escaped when displayed. Failing to do this can allow a hostile user to perform a variety of attacks, ranging from the potentially benign, such as providing bogus user information like a negative age, to the serious, such as running scripts every time a user looks at a page that includes the information, potentially propagating the attack in the process, to the catastrophic, such as deleting all data in the server.

利用者-入力を検証する~filterを書くときは、 常に安全~listに基づくこと — 安全なことが既知な構成子は許容する一方で、 他の入力は，すべて許容しないようにすること — が絶対要件である。 阻止-~listに基づく~filter — 不良なことが既知な入力は許容しない一方で、 他は，すべて許容するような~filter — は、 ~secureでない — 不良なものには、 まだ既知でないものがあるので （例えば，未来に考案されるかもしれない）。 ◎ When writing filters to validate user input, it is imperative that filters always be safelist-based, allowing known-safe constructs and disallowing all other input. Blocklist-based filters that disallow known-bad inputs and allow everything else are not secure, as not everything that is bad is yet known (for example, because it might be invented in the future).

例えば，ある~site【 `https://example.com^c 】のある~pageは、 ~URLの~query文字列を調べて何を表示するか決定してから， ある~messageを表示する~pageへ利用者を~redirectするとする — 次のように： ◎ For example, suppose a page looked at its URL's query string to determine what to display, and the site then redirected the user to that page to display a message, as in:

`writing-secure-1^xCode

~messageが~escapeされずに利用者に表示される場合、 敵対的な攻撃者は，~script要素を包含するよう~URLを細工することもできる： ◎ If the message was just displayed to the user without escaping, a hostile attacker could then craft a URL that contained a script element:

`https://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E^

攻撃者が次に，被害者になる利用者を この~pageを訪問するよう仕向けた場合、 攻撃者が選んだ~scriptを~page上で走らすことになる。 そのような~scriptは、 敵対的な動作を — 当の~siteが提供するものに制限される下で 【言い換えれば、［利用者が当の~siteに有する権限］を代理する下で】 — 何回でも行える。 一例として，当の~siteが電子商取引店舗であった場合、 そのような~scriptは，利用者が知らないうちに求まれない購入nを何回でも為せる。 ◎ If the attacker then convinced a victim user to visit this page, a script of the attacker's choosing would run on the page. Such a script could do any number of hostile actions, limited only by what the site offers: if the site is an e-commerce shop, for instance, such a script could cause the user to unknowingly make arbitrarily many unwanted purchases.

これは、 ~XSS（ `cross-site scripting^en ）攻撃と呼ばれる。 ◎ This is called a cross-site scripting attack.

構成子には、［ ある~codeを実行するよう，~siteを騙そうと試行する ］ためにも利用され得るものが，数多くある。 ここに，作者が安全~listに基づく~filterを書くとき考慮するよう奨励されるものをいくつか与える： ◎ There are many constructs that can be used to try to trick a site into executing code. Here are some that authors are encouraged to consider when writing safelist filters:

• `img$e の様な無害に見える要素を許容するときでも、 その各~属性は，安全~listに基づいて供することが重要になる。 すべての属性を許容した場合、 攻撃者は，一例として `onload$m 属性を利用して任意な~scriptを走らすこともできる。 ◎ When allowing harmless-seeming elements like img, it is important to safelist any provided attributes as well. If one allowed all attributes then an attacker could, for instance, use the onload attribute to run arbitrary script.
• ~URLを供することを許容するときは（例：~link用に）、 各~URLの~schemeも明示的に安全~listに基づく必要がある — 濫用され得る~schemeは、 いくつもあるので。 真っ先に挙がる例は `javascript:＠~HTMLnav#the-javascript:-url-special-case$sc であるが、 ~UAは，それ以外も実装し得る （~~実際，歴史的に実装されていた）。 ◎ When allowing URLs to be provided (e.g. for links), the scheme of each URL also needs to be explicitly safelisted, as there are many schemes that can be abused. The most prominent example is "javascript:", but user agents can implement (and indeed, have historically implemented) others.
• `base$e 要素を挿入することを許容することは、 ~page内の［ `script$e 要素／~form提出 ］のうち相対-~linkを伴うものは，どれも［ 乗取られ得る／敵対的な~siteへ~redirectされ得る ］ことを意味する。 ◎ Allowing a base element to be inserted means any script elements in the page with relative links can be hijacked, and similarly that any form submissions can get redirected to a hostile site.

~CSRF（ `cross-site request forgery^en ） ◎ Cross-site request forgery (CSRF)

ある~siteが［ 利用者に特有な副作用を伴う~form提出を為す ］ことを利用者に許容する場合 — 例えば［ ある~forumに利用者の名の下で~messageを投稿する／ 購入nを為す／ ある入場許可証を適用する ］ためなど — 当の要請は、［ 別の~siteが利用者が知らないうちに為すよう騙したものではなく， 利用者が意図的に為したものである ］ことを検証yすることが重要になる。 ◎ If a site allows a user to make form submissions with user-specific side-effects, for example posting messages on a forum under the user's name, making purchases, or applying for a passport, it is important to verify that the request was made by the user intentionally, rather than by another site tricking the user into making the request unknowingly.

この問題が存在するのは、 ~HTML~formは，他の生成元へも提出し得ることによる。 ◎ This problem exists because HTML forms can be submitted to other origins.

~siteは、 そのような攻撃を次のいずれかにより防止できる ⇒＃ 利用者に特有な秘密な~tokenで~formを拡充する／ すべての要請に対し `Origin$h ~headerを検査する ◎ Sites can prevent such attacks by populating forms with user-specific hidden tokens, or by checking `Origin` headers on all requests.

~click乗取り ◎ Clickjacking

~pageは、［ 利用者が遂行したいと望まないかもしれない動作を遂行する~interface ］を利用者に供する場合には，［ 当の~interfaceを作動化するよう利用者が騙されるアリ性 ］を避けるよう設計する必要がある。 ◎ A page that provides users with an interface to perform actions that the user might not wish to perform needs to be designed so as to avoid the possibility that users can be tricked into activating the interface.

利用者が そう騙され得る仕方として、 ある敵対的~siteが小さな `iframe$e 内に被害者~siteを配置してから， 利用者が それを~clickするよう — 一例として，利用者が遊びたくなる~gameにより — 仕向ける場合が挙げられる。 敵対的な~siteは、 利用者が~gameを遊び始めたとき， 利用者が~clickしようとした~mouse~cursorの直下に当の `iframe^e を素早く位置でき、 被害者~siteの~interfaceを~clickするよう利用者を騙すことになる。 ◎ One way that a user could be so tricked is if a hostile site places the victim site in a small iframe and then convinces the user to click, for instance by having the user play a reaction game. Once the user is playing the game, the hostile site can quickly position the iframe under the mouse cursor just as the user is about to click, thus tricking the user into clicking the victim site's interface.

~siteは，これを避けるため、 ~frame内での利用を期待しない場合には，［ そうでないことを検出した場合に限り，自身の~interfaceを可能化する ］ことが奨励される （例： `window$m ~objと `top$m 属性の値を比較することにより）。 ◎ To avoid this, sites that do not expect to be used in frames are encouraged to only enable their interface if they detect that they are not in a frame (e.g. by comparing the window object to the value of the top attribute).

1.10.2. ~script用の~APIを利用するときに避けるべき共通的な陥穽

~HTMLにおける~scriptには、 “完了まで走る（ `run-to-completion^en ）” 意味論がある。 それは、 一般に，次を意味する ⇒ ~browserは、 当の~scriptを，他の何かを行う （更に~eventを発火する／文書を構文解析し続ける，など） 前に中断することなく走らすことになる。 ◎ Scripts in HTML have "run-to-completion" semantics, meaning that the browser will generally run the script uninterrupted before doing anything else, such as firing further events or continuing to parse the document.

他方，~HTML~fileの構文解析は、 増分的に起こる — すなわち，構文解析器は、 どの地点でも静止して，~scriptを走らせ得る。 これは，一般には良いものになるが、［ ~event~handlerを~hookする【登録する】のが、 場合によっては，~eventが発火された後になる ］ことを避けるよう，作者は気を付ける必要があることを意味する。 ◎ On the other hand, parsing of HTML files happens incrementally, meaning that the parser can pause at any point to let scripts run. This is generally a good thing, but it does mean that authors need to be careful to avoid hooking event handlers after the events could have possibly fired.

これを依拠-可能に行うための技法には、 次の 2 つがある ⇒＃ `~event~handler内容~属性$を利用する／ 要素を作成するときに，同じ~script内で~event~handlerも追加する ◎終 後者が安全になるのは、 先に言及したとおり，［ 当の~scriptは、 更に~eventが発火され得る前に，完了まで走る ］からである。 ◎ There are two techniques for doing this reliably: use event handler content attributes, or create the element and add the event handlers in the same script. The latter is safe because, as mentioned earlier, scripts are run to completion before further events can fire.

<script>
 var %img = new Image();
 %img.src = 'games.png';
 %img.alt = 'Games';
 %img.onload = gamesLogoHasLoaded;
 // %img.addEventListener('load', gamesLogoHasLoaded, false); /* 
これも働く
◎
would work also
 */
</script>

<!-- 
この~styleは、
競争~条件があるので，利用しないこと。
◎
Do not use this style, it has a race condition!
 -->
 <img id="games" src="games.png" alt="Games">
 <!-- 
`load^et ~eventは、
構文解析器が休んでいる間に，ここで発火されるかもしれない
— その事例では、
~eventを見逃すことになる。
◎
the 'load' event might fire here while the parser is taking a break, in which case you will not see it!
 -->
 <script>
  var %img = document.getElementById('games');
  %img.onload = gamesLogoHasLoaded; /* 
決して発火されないかもしれない。
◎
might never fire!
 */
 </script>

1.10.3. ~HTMLを書くときに過ちを捕える方法： 検証器と適合性~検査器

作者には、 適合性~検査器（ “検証器” としても知られる）を用立てて， 共通的な過ちを捕えることが奨励される。 ~WHATWGは、 そのような~toolたちが成す~listを `https://whatwg.org/validator/＠https://whatwg.org/validator/$ にて保守する。 ◎ Authors are encouraged to make use of conformance checkers (also known as validators) to catch common mistakes. The WHATWG maintains a list of such tools at: https://whatwg.org/validator/

1.11. 作者~向けの適合性~要件

~HTML仕様の以前の~versionと違って、 この仕様は — 妥当な文書に加え — 妥当でない文書を処理するために要求される詳細も，いくつか定義する。 ◎ Unlike previous versions of the HTML specification, this specification defines in some detail the required processing for invalid documents as well as valid documents.

しかしながら，妥当でない内容の処理が ほとんどの事例できちんと定義されていても、 文書に対する適合性~要件は依然として重要になる — 文書に対する適合性~要件の目標は、 実施においては，相互運用能 （すべての実装が，特定0の内容を依拠-可能かつ, 一致するか等価な仕方で処理するような状況） に限られない。 この節では、 適合~文書と~errorを伴う文書を判別するための， もっと共通的な理由の一部を詳細に与える。 ◎ However, even though the processing of invalid content is in most cases well-defined, conformance requirements for documents are still important: in practice, interoperability (the situation in which all implementations process particular content in a reliable and identical or equivalent way) is not the only goal of document conformance requirements. This section details some of the more common reasons for still distinguishing between a conforming document and one with errors.

1.11.1. 呈示~用の~markup

~HTMLの以前の~versionに由来する呈示~用の特能のうち大多数は、 もはや許容されない。 一般に，呈示~用の~markupには、 いくつかの問題があることが見出されている： ◎ The majority of presentational features from previous versions of HTML are no longer allowed. Presentational markup in general has been found to have a number of problems:

呈示~用の要素を利用すると、 ~accessibilityは拙くなる。 ◎ The use of presentational elements leads to poorer accessibility

呈示~用の~markupを［ 支援~技術の利用者に受容-可能な体験を供する仕方 ］で利用することは，アリではあるが（例：~ARIAを利用して）、 そうすることは，意味論的に適切な~markupを利用するときより有意に困難である。 さらには，そのような技法を利用しても、 非~支援~技術かつ非~graphicな~UA（~text~mode~browserなど）の利用者にとって~pageを~access可能にする助けにならない。 ◎ While it is possible to use presentational markup in a way that provides users of assistive technologies (ATs) with an acceptable experience (e.g. using ARIA), doing so is significantly more difficult than doing so when using semantically-appropriate markup. Furthermore, even using such techniques doesn't help make pages accessible for non-AT non-graphical users, such as users of text-mode browsers.

他方，媒体に依存しない~markupを利用することは、 利用者（例：~text~browserの利用者）用にもっと働く仕方で文書を著作するための， 容易な仕方を供する。 ◎ Using media-independent markup, on the other hand, provides an easy way for documents to be authored in such a way that they work for more users (e.g. users of text browsers).

保守の~costが高まる ◎ Higher cost of maintenance

~markupが~styleに依存しない仕方で書かれた~siteを保守する方が、 有意に容易になる。 例えば，ある~siteが `<font color="">^c を利用している場合、 その色を全体を通して変更することは，~site全体にわたる変更を要求する。 一方で，色を~CSSに基づくようにしてあれば、 類似な変更は，単独の~fileを変更することで行える。 ◎ It is significantly easier to maintain a site written in such a way that the markup is style-independent. For example, changing the color of a site that uses <font color=""> throughout requires changes across the entire site, whereas a similar change to a site based on CSS can be done by changing a single file.

文書の~sizeが増える ◎ Larger document sizes

呈示~用の~markupは、 ずっと冗長になる傾向にあり，文書の~sizeは増えることになる。 ◎ Presentational markup tends to be much more redundant, and thus results in larger document sizes.

これらの理由から、 呈示~用の~markupは，この~versionにおける~HTMLからは除去された。 この変更は、 驚くほどのものではないはずである — ~HTML4は、 何年も前に呈示~用の~markupを非推奨にした上で， 作者が呈示~用の~markupから脱却し易くする~mode（ `HTML4 Transitional^cite ）を供した — 後に，~XHTML 1.1 は、 更に先へ進んで，それらの特能を まとめて廃用にした。 ◎ For those reasons, presentational markup has been removed from HTML in this version. This change should not come as a surprise; HTML4 deprecated presentational markup many years ago and provided a mode (HTML4 Transitional) to help authors move away from presentational markup; later, XHTML 1.1 went further and obsoleted those features altogether.

~HTMLにおいて唯一残された呈示~用の~markup特能は、 `style$a 属性と `style$e 要素である。 `style$a 属性の利用は、 本番~環境においては いくぶん忌避されるが，［ 迅速な試作~用 （当の~style規則は、 後で別々な~stylesheetの中に直に移動できる）／ 別々な~stylesheetでは不便になるような通例的でない事例において， ~pageに特有な~styleを供するため ］には有用になり得る。 類似に， `style$e 要素は［ `syndication^en において† ／ ~pageに特有な~style用に ］有用になり得るが、 一般に，~styleを複数の~pageに適用するときは外部~stylesheetの方が簡便になる見込みが高い。 【†不特定多数の~site向けに配信される~stylesheetを利用するため？ あるいは動的に生成される~stylesheetを埋込むため？】 ◎ The only remaining presentational markup features in HTML are the style attribute and the style element. Use of the style attribute is somewhat discouraged in production environments, but it can be useful for rapid prototyping (where its rules can be directly moved into a separate style sheet later) and for providing specific styles in unusual cases where a separate style sheet would be inconvenient. Similarly, the style element can be useful in syndication or for page-specific styles, but in general an external style sheet is likely to be more convenient when the styles apply to multiple pages.

また、 次に挙げる，以前は呈示~用であった要素は、 この仕様により媒体に依存しないものに定義し直された ⇒ `b$e, `i$e, `hr$e, `s$e, `small$e, `u$e ◎ It is also worth noting that some elements that were previously presentational have been redefined in this specification to be media-independent: b, i, hr, s, small, and u.

1.11.2. 構文~error

~HTMLの構文は、 多種多様な問題を避けるよう拘束される。 ◎ The syntax of HTML is constrained to avoid a wide variety of problems.

~errorを取扱う挙動が直感に反するもの ◎ Unintuitive error-handling behavior

ある種の妥当でない構文~構成子は、 構文解析した結果が ひどく直感に反する~DOM~treeになる。 ◎ Certain invalid syntax constructs, when parsed, result in DOM trees that are highly unintuitive.

例えば，次の~markup片による結果の~DOMには、 `hr$e 要素があるが，それは対応する `table$e 要素に`~~先行する^em同胞になる： ◎ For example, the following markup fragment results in a DOM with an hr element that is an earlier sibling of the corresponding table element:

`syntax-errors-1^xCode

任意選択で~error回復を伴う~error ◎ Errors with optional error recovery

制御された環境において利用される~UAが［ より奇妙で込み入った~error取扱い規則 ］を実装しなくとも済むよう、 ~UAには，［ `構文解析-~error$に遭遇したときには，失敗する ］ことも許可される。 ◎ To allow user agents to be used in controlled environments without having to implement the more bizarre and convoluted error handling rules, user agents are permitted to fail whenever encountering a parse error.

~errorを取扱う挙動が~streamしている~UAと互換でない~error ◎ Errors where the error-handling behavior is not compatible with streaming user agents

~errorを取扱う挙動のうち一部は — 上に言及した例 `<table><hr>...^c の挙動など — ~streamしている~UA （~HTML~fileを，状態を格納せずに 1 周回で処理する~UA） と互換でない。 そのような~UAとの相互運用能の問題を避けるため、 結果がそのような挙動になる構文は， どれも妥当でないものと見なされる。 ◎ Some error-handling behavior, such as the behavior for the <table><hr>... example mentioned above, are incompatible with streaming user agents (user agents that process HTML files in one pass, without storing state). To avoid interoperability problems with such user agents, any syntax resulting in such behavior is considered invalid.

~XML~infosetに型強制し得る結果になる~error ◎ Errors that can result in infoset coercion

~XMLに基づく~UAが~HTML構文解析器に接続されるとき，~XMLが施行するある種の不変則 — 要素や属性の名前は複数個の~colonを決して包含しないなど — は、 ~HTML~fileにおいては違反されることもある。 これを取扱うためには、 構文解析器が~HTML~DOMを~XMLに互換な~infosetに型強制することが要求され得る。 そのような取扱いを要求する構文~構成子のほとんどは、 妥当でないものと見なされる。 （【例えば】［ 連続する 2 個の~hyphenを包含している／~hyphenで終端している ］~commentは、 ~HTML構文において許容される例外である。） ◎ When a user agent based on XML is connected to an HTML parser, it is possible that certain invariants that XML enforces, such as element or attribute names never contain multiple colons, will be violated by an HTML file. Handling this can require that the parser coerce the HTML DOM into an XML-compatible infoset. Most syntax constructs that require such handling are considered invalid. (Comments containing two consecutive hyphens, or ending with a hyphen, are exceptions that are allowed in the HTML syntax.)

処理能をひどく劣化させる~error ◎ Errors that result in disproportionately poor performance

ある種の構文~構成子は、 処理能をひどく劣化させる。 そのような構成子は、 その利用を忌避するよう，概して不適合にされる。 ◎ Certain syntax constructs can result in disproportionately poor performance. To discourage the use of such constructs, they are typically made non-conforming.

例えば，次の~markupは、 処理能を劣化させる — 閉じられていない `i$e 要素は，各~段落~内で構築し直す必要があり、 その結果，各~段落（ `p$e 要素）内に生じる要素は次第に増えていくので： ◎ For example, the following markup results in poor performance, since all the unclosed i elements have to be reconstructed in each paragraph, resulting in progressively more elements in each paragraph:

`syntax-errors-2^xCode

この~code片による結果の~DOMは、 次のようになろう： ◎ The resulting DOM for this fragment would be:

• `p^e
  • `i^e
    • `Text$I: `She dreamt.^txt
• `p^e
  • `i^e
    • `i^e
      • `Text^I: `She dreamt that she ate breakfast.^txt
• `p^e
  • `i^e
    • `i^e
      • `i^e
        • `Text^I: `Then lunch.^txt
• `p^e
  • `i^e
    • `i^e
      • `i^e
        • `i^e
          • `Text^I: `And finally dinner.^txt

崩れ易い構文~構成子を孕んでいる~error ◎ Errors involving fragile syntax constructs

歴史的な理由から，他に比して崩れ易い構文~構成子がある。 そのような問題に偶発的に はまる利用者を減らすため、 それらは不適合にされる。 ◎ There are syntax constructs that, for historical reasons, are relatively fragile. To help reduce the number of users who accidentally run into such problems, they are made non-conforming.

例えば，属性~内のある種の`有名~文字~参照$の構文解析は、 それを閉じる~semicolonが省略されても起こる。 有名~文字~参照を形成しない英字~列は， ~ampersandに後続するよう内包しても安全であるが、 当の英字~列が有名~文字~参照を`形成する^em文字列に変更された場合， それが指している文字として解釈されることになる。 ◎ For example, the parsing of certain named character references in attributes happens even with the closing semicolon being omitted. It is safe to include an ampersand followed by letters that do not form a named character reference, but if the letters are changed to a string that does form a named character reference, they will be interpreted as that character instead.

次の~code片においては、 属性の値は `?bill&ted^l になる： ◎ In this fragment, the attribute's value is "?bill&ted":

`syntax-errors-3^xCode

しかしながら，次の~code片における属性の値は、 実際に意図された `?art&copy^l `ではなく^em， `?art©^l になる — `&copy^l には末尾に~semicolonが無いが、 それでも `&copy;^l と同じに取扱われ， その結果 `©^l として解釈されるので： ◎ In the following fragment, however, the attribute's value is actually "?art©", not the intended "?art&copy", because even without the final semicolon, "&copy" is handled the same as "&copy;" and thus gets interpreted as "©":

`syntax-errors-4^xCode

この問題を避けるため、 すべての`有名~文字~参照$は，~semicolonで終端することが要求される — ~semicolonを伴わない有名~文字~参照の利用は、 ~errorとして~flagされる【記録され, 報告される】。 ◎ To avoid this problem, all named character references are required to end with a semicolon, and uses of named character references without a semicolon are flagged as errors.

したがって，上の事例を表出する正しい仕方は： ◎ Thus, the correct way to express the above cases is as follows:

• `syntax-errors-5^xCode

  この `&ted^c は、 有名~文字~参照を成さないので差し支えない。 ◎ <!-- &ted is ok, since it's not a named character reference -->

• `syntax-errors-6^xCode

  この場合の `&^c は~escapeする必要がある — `&copy^c が有名~文字~参照を`成す^emので。 ◎ <!-- the & has to be escaped, since &copy is a named character reference -->

旧来の~UAにおいて既知な相互運用能の問題を孕んでいる~error ◎ Errors involving known interoperability problems in legacy user agents

ある種の構文~構成子は、 旧来の~UAにおいて，とりわけ［ 微妙／深刻 ］な問題をもたらすことが既知であり、 作者が それを避ける助けになるよう，不適合とされる。 ◎ Certain syntax constructs are known to cause especially subtle or serious problems in legacy user agents, and are therefore marked as non-conforming to help authors avoid them.

例えば，引用符~無しの属性において文字 `0060^U `GRAVE ACCENT^cn (`) が許容されないのは、 これが~~理由にある。 ある種の旧来の~UAにおいては、 それは，ときには引用符として扱われる。 ◎ For example, this is why the U+0060 GRAVE ACCENT character (`) is not allowed in unquoted attributes. In certain legacy user agents, it is sometimes treated as a quote character.

別の例は，`~DOCTYPE$であり、 `過去互換なし~mode$を誘発するために要求される — `過去互換~mode$における旧来の~UAの挙動は、 ほとんど文書化されていないことが多いので。 ◎ Another example of this is the DOCTYPE, which is required to trigger no-quirks mode, because the behavior of legacy user agents in quirks mode is often largely undocumented.

作者を~security攻撃に晒す~riskがある~error ◎ Errors that risk exposing authors to security attacks

純粋に，既知な~security問題を避けるため、 ある種の制約が存在する。 ◎ Certain restrictions exist purely to avoid known security problems.

例えば， ~UTF-7を利用しないよう制約することは、 純粋に，作者が［ ~UTF-7を利用している既知な~XSS攻撃 ］の餌食になることを避けるために存在する。 `UTF7$r ◎ For example, the restriction on using UTF-7 exists purely to avoid authors falling prey to a known cross-site-scripting attack using UTF-7. [UTF7]

作者の意図が不明瞭な事例 ◎ Cases where the author's intent is unclear

作者の意図が不明瞭な~markupは、 不適合にされることが多い。 これらの~errorを早期に正すことは、 後からの保守を楽にする。 ◎ Markup where the author's intent is very unclear is often made non-conforming. Correcting these errors early makes later maintenance easier.

例えば，次は、 作者が［ `h1$e, `h2$e ］どちらの見出しを意図したのか不明瞭である： ◎ For example, it is unclear whether the author intended the following to be an h1 heading or an h2 heading:

`syntax-errors-7^xCode

誤記である見込みが高い事例 ◎ Cases that are likely to be typos

利用者が単純な誤記を為したとき、 ~errorを早期に捕えれたなら役立つ — 作者が~debugする時間をかなり節約できるので。 したがって，この仕様は、 この仕様に定義される名前に合致しない［ 要素~名, 属性~名, 等々 ］の利用を通例的に~errorと見なす。 ◎ When a user makes a simple typo, it is helpful if the error can be caught early, as this can save the author a lot of debugging time. This specification therefore usually considers it an error to use element names, attribute names, and so forth, that do not match the names defined in this specification.

例えば，作者が `<caption>^c の代わりに `<capton>^c と打込んだ場合、 ~errorとして~flagされることになり， 作者は その誤記を即時に正せるようにもなる。 ◎ For example, if the author typed <capton> instead of <caption>, this would be flagged as an error and the author could correct the typo immediately.

将来に新たな構文に干渉し得る~error ◎ Errors that could interfere with new syntax in the future

この言語の構文を将来に拡張することを許容するため、 ある種の特能は，他では無害であっても許容されない。 ◎ In order to allow the language syntax to be extended in the future, certain otherwise harmless features are disallowed.

例えば，終了~tag内の “属性” は、 現時点では無視されるが、 この言語が将来に［ そのような構文~特能を — すでに配備-済みな（かつ妥当な）内容と競合することなく — 用立てる ］よう変更されたときには，妥当でなくなる。 ◎ For example, "attributes" in end tags are ignored currently, but they are invalid, in case a future change to the language makes use of that syntax feature without conflicting with already-deployed (and valid!) content.

一部の作者は、［ どの属性も常に引用符で括って，省略可能な どの~tagも常に内包する ］ような実施が役立つと見出す — ~HTML構文の~~寛容さを用立てることで短く記せるようになる小さな便益より，そのような~customな実施から導出される一貫性を選好して。 そのような作者を援助するため、 適合性~検査器は，そのような規約を施行する運用~modeを供せる。 ◎ Some authors find it helpful to be in the practice of always quoting all attributes and always including all optional tags, preferring the consistency derived from such custom over the minor benefits of terseness afforded by making use of the flexibility of the HTML syntax. To aid such authors, conformance checkers can provide modes of operation wherein such conventions are enforced.

1.11.3. 内容~modelと属性~値に対する制約

この仕様は、 ~HTML言語の構文の他にも，［ 要素／属性 ］をどう指定し得るかに対しても制約を課す。 これらの制約が在る理由は、 類似する： ◎ Beyond the syntax of the language, this specification also places restrictions on how elements and attributes can be specified. These restrictions are present for similar reasons:

意味論が疑な内容を孕んでいる~error ◎ Errors involving content with dubious semantics

定義された意味を伴う要素の誤った利用を避けるため、 内容~modelは，［ 要素どうしを どう入子にできるか ］を［ その結果が疑なものにならないよう制約する ］ように定義される。 ◎ To avoid misuse of elements with defined meanings, content models are defined that restrict how elements can be nested when such nestings would be of dubious value.

例えば，この仕様は、 `kbd$e 要素の内側に `section$e 要素を入子にするのを許容しない — 作者が［ ~section全体を~UIkeyで~~入力するべきである ］よう指示することは，まず見込まれないので。 ◎ For example, this specification disallows nesting a section element inside a kbd element, since it is highly unlikely for an author to indicate that an entire section should be keyed in.

表出される意味論における競合を孕む~error ◎ Errors that involve a conflict in expressed semantics

類似に，要素の利用における過ちに作者の注目を引くため、 表出された意味論における明瞭な矛盾もまた，適合性~errorと見なされる。 ◎ Similarly, to draw the author's attention to mistakes in the use of elements, clear contradictions in the semantics expressed are also considered conformance errors.

例えば，次の両~code片における意味論は、 どちらもイミを成さない — 分離子は同時的に~cellにはなり得ないし、 ~radio~buttonは同時的に進捗~barにはなり得ないので。 ◎ In the fragments below, for example, the semantics are nonsensical: a separator cannot simultaneously be a cell, nor can a radio button be a progress bar.

`restrictions-1^xCode `restrictions-2^xCode

別の例は、 `ul$e 要素の内容~modelに対する制約であり，その子として許容するのは `li$e 要素に限られる。 定義により，~listは 0 個以上の~list~itemのみからなるので、 `ul$e 要素が `li$e 要素~以外の何かを包含する場合，何を意味したのか明瞭でなくなる。 ◎ Another example is the restrictions on the content models of the ul element, which only allows li element children. Lists by definition consist just of zero or more list items, so if a ul element contains something other than an li element, it's not clear what was meant.

既定の~styleが混乱を招く見込みが高い事例 ◎ Cases where the default styles are likely to lead to confusion

ある種の要素たちの既定の［ ~style／挙動 ］が成す ある種の組合nには、 混乱を招く見込みが高いものがある。 そのような組合nは、 この問題を伴わない等価な代替がある所では，許容されない。 ◎ Certain elements have default styles or behaviors that make certain combinations likely to lead to confusion. Where these have equivalent alternatives without this problem, the confusing combinations are disallowed.

例えば，［ `div$e ／ `span$e ］要素の内側に［ `div^e ／ `span^e ］要素（順不同）を入子にすることは，どれも同じ目的を~serveするが、 それらのうち［ `span^e 内に `div^e を入子にする組合n ］は許容されない — ［ `div^e 要素は`塊~box$／ `span^e 要素は`行内~box$ ］として具現化され、 `行内~box$内に`塊~box$を置くことは，不必要に惑わすものになるので。 ◎ For example, div elements are rendered as block boxes, and span elements as inline boxes. Putting a block box in an inline box is unnecessarily confusing; since either nesting just div elements, or nesting just span elements, or nesting span elements inside div elements all serve the same purpose as nesting a div element in a span element, but only the latter involves a block box in an inline box, the latter combination is disallowed.

別の例として、 `ヤリトリありな内容$は入子にできない。 例えば， `button$e 要素は `textarea$e 要素を包含し得ない — そのように入子にすると、 その既定の挙動は，利用者を ひどく惑わすものになるので。 これらの要素は、 入子にしないで並べて配置しても用を成す。 ◎ Another example would be the way interactive content cannot be nested. For example, a button element cannot contain a textarea element. This is because the default behavior of such nesting interactive elements would be highly confusing to users. Instead of nesting these elements, they can be placed side by side.

仕様を誤解している見込みが高いことを指示する~error ◎ Errors that indicate a likely misunderstanding of the specification

ときには、 許容すると作者を惑わす見込みが高まるので，許容されないものもある。 ◎ Sometimes, something is disallowed because allowing it would likely cause author confusion.

例えば、 `disabled$a 属性を値 `false^l に設定することは許容されない — それは、 外見上は要素は可能化されることを意味しそうだが、 ~~実際には，要素は`不能化される^em【 `disable^en される】ことを意味する （実装が問うものは、 属性の値ではなく，その有無なので）。 ◎ For example, setting the disabled attribute to the value "false" is disallowed, because despite the appearance of meaning that the element is enabled, it in fact means that the element is disabled (what matters for implementations is the presence of the attribute, not its value).

単に この言語を単純~化するために課される制限sを孕んでいる~error ◎ Errors involving limits that have been imposed merely to simplify the language

一部の適合性~errorは、 この言語を単純~化する — 作者は、 そのことを学習する必要がある。 ◎ Some conformance errors simplify the language that authors need to learn.

例えば， `area$e 要素の `shape$a 属性は、 実施においては［ `circ$v, `circle$v ］両~値を同義語として受容するにもかかわらず — ~tutorialその他の学習~援助を単純~化するため — `circ^v 値の利用を許容しない。 どちらも許容することに便益は無い上、 この言語を教えるときに余計な混乱をもたらすことになろう。 ◎ For example, the area element's shape attribute, despite accepting both circ and circle values in practice as synonyms, disallows the use of the circ value, so as to simplify tutorials and other learning aids. There would be no benefit to allowing both, but it would cause extra confusion when teaching the language.

構文解析器の癖を孕む~error ◎ Errors that involve peculiarities of the parser

ある種の要素は、 （概して，歴史的な理由から）いくぶん風変わりな仕方で構文解析される — それらの内容~modelに対する制約は、 これらの課題を作者に晒すのを避けることが意図される。 ◎ Certain elements are parsed in somewhat eccentric ways (typically for historical reasons), and their content model restrictions are intended to avoid exposing the author to these issues.

例えば `form$e 要素は、 `句ng内容$の内側では許容されない — `form^e 要素の開始~tagは、 ~HTMLとして構文解析されるとき `p$e 要素の終了~tagを含意することになるので。 したがって，次の~markupによる結果は、 1 個ではなく 2 個の`段落$になる： ◎ For example, a form element isn't allowed inside phrasing content, because when parsed as HTML, a form element's start tag will imply a p element's end tag. Thus, the following markup results in two paragraphs, not one:

`restrictions-3^xCode

それは、 正確に次の様に構文解析される： ◎ It is parsed exactly like the following:

`restrictions-4^xCode

~scriptが~debugし難くなる方へ陥れる見込みが高い~error ◎ Errors that would likely result in scripts failing in hard-to-debug ways

一部の~errorは、 ~scriptが~debugし難くなる問題を防止する助けになることが意図される。 ◎ Some errors are intended to help prevent script problems that would be hard to debug.

一例として、 同じ値をとる `id$a 属性を有する要素が複数ある場合，不適合になる。 重複した~IDは、 間違った要素が選定されることへ至らす — ときには、 その原因を決定することが難しい悲惨な効果になる。 ◎ This is why, for instance, it is non-conforming to have two id attributes with the same value. Duplicate IDs lead to the wrong element being selected, with sometimes disastrous effects whose cause is hard to determine.

著作~時間を浪費する~error ◎ Errors that waste authoring time

一部の構成子は、 許容されない — 歴史的に，多くの著作~時間を浪費させた原因を成していたので。 それらを避けるよう奨励することにより、 作者が将来の労において時間を節約できるようにする。 ◎ Some constructs are disallowed because historically they have been the cause of a lot of wasted authoring time, and by encouraging authors to avoid making them, authors can save time in future efforts.

例えば， `script$e 要素の `src$a 属性は、 要素の内容を無視させる。 しかしながら，これは明白ではない — とりわけ，当の要素の内容が実行-可能な~scriptのように現れる場合、 作者が~inline~scriptを — 実行されていないのに気付かずに — ~debugするよう試行することに何時間も費やすことへ至らせ得る。 この問題を抑制するため，この仕様は、 `src$a 属性を有する `script$e 要素~内に実行-可能な~scriptがある場合， それを不適合にする。 これは、 自身の文書を検証している作者が， この種類の過ちで時間を浪費する見込みを抑えることを意味する。 ◎ For example, a script element's src attribute causes the element's contents to be ignored. However, this isn't obvious, especially if the element's contents appear to be executable script — which can lead to authors spending a lot of time trying to debug the inline script without realizing that it is not executing. To reduce this problem, this specification makes it non-conforming to have executable script in a script element when the src attribute is present. This means that authors who are validating their documents are less likely to waste time with this kind of mistake.

作者が~HTML構文と~XML構文の間で移行するときに影響する何かを孕む~error ◎ Errors that involve areas that affect authors migrating between the HTML and XML syntaxes

一部の作者は、［ ~XML, ~HTMLどちらにも解釈でき，類似な結果を得る ］ような~fileを書くことを好む。 この実施は， 無数の微妙な複雑化が孕まれることに因り，一般には忌避されるが （とりわけ［ ~scripting／~style付け／何らかの種類の自動化された直列化 ］を孕むとき）、 この仕様には，［ 少なくとも困難さをいくぶん軽減する ］ことが意図される少数の制約がある。 これは、作者が［ ~HTML構文と~XML構文の間で移行するためのつなぎ ］として利用し易くするためにある。 ◎ Some authors like to write files that can be interpreted as both XML and HTML with similar results. Though this practice is discouraged in general due to the myriad of subtle complications involved (especially when involving scripting, styling, or any kind of automated serialization), this specification has a few restrictions intended to at least somewhat mitigate the difficulties. This makes it easier for authors to use this as a transitionary step when migrating between the HTML and XML syntaxes.

例えば， `lang$a 属性と `xml:lang＠~TR/xml/#sec-lang-tag$a 属性には、 この 2 つの値を同期し続けることが意図される，いくぶん複雑な規則がある。 ◎ For example, there are somewhat complicated rules surrounding the lang and xml:lang attributes intended to keep the two synchronized.

別の例として，［ ~HTML直列化における `xmlns^a 属性の値に対する制約 ］は、［ 適合~文書~内の要素が~HTML, ~XMLどちらで処理されても， 同じ名前空間に属するようになる ］ことを確保することが意図される。 ◎ Another example would be the restrictions on the values of xmlns attributes in the HTML serialization, which are intended to ensure that elements in conforming documents end up in the same namespaces whether processed as HTML or XML.

~HTML語彙を将来に拡げるために予約される区画を孕む~error ◎ Errors that involve areas reserved for future expansion

構文に対する制約のうち［ この言語の将来の改訂において，新たな構文を許容することが意図されるもの ］と同じく，［ 要素の内容~model, 属性の値 ］に対する制約のうち一部は、 ~HTML語彙を将来に拡げることを許容することが意図される。 ◎ As with the restrictions on the syntax intended to allow for new syntax in future revisions of the language, some restrictions on the content models of elements and values of attributes are intended to allow for future expansion of the HTML vocabulary.

例えば， `target$a 属性の値を［ 特定の定義済みな値に限り，文字 `005F^U `LOW LINE^cn (_) から開始する ］よう制限するのは、 将来のある時点に［ 作者が定義した値と競合することなく，新たな定義済みな値を導入する ］ことを許容するためである。 ◎ For example, limiting the values of the target attribute that start with an U+005F LOW LINE character (_) to only specific predefined values allows new predefined values to be introduced at a future time without conflicting with author-defined values.

他の仕様の誤った利用を指示する~error ◎ Errors that indicate a mis-use of other specifications

ある種の制約は、 他の仕様により為された制約を~supportするために意図される。 ◎ Certain restrictions are intended to support the restrictions made by other specifications.

例えば，［ 媒体~query~listをとる属性は、 `妥当な媒体~query~list$に限り利用する ］よう要求することは、 その仕様【 `MQ$r 】の適合性~規則に従うことの重要度を強化する。 ◎ For example, requiring that attributes that take media query lists use only valid media query lists reinforces the importance of following the conformance rules of that specification.