[ac] (0) Try to clarify some confusion.
[whatwg:webapps.git] / source
1 <!-- EDITOR NOTES  -*- mode: Text; fill-column: 100 -*-
2  !
3  !   Adding a new element involves editing the following sections:
4  !    - section for the element itself
5  !    - descriptions of the element's categories
6  !    - images/content-venn.svg
7  !    - syntax, if it's void or otherwise special
8  !    - parser, if it's not phrasing-level
9  !    - rendering
10  !    - obsolete section
11  !    - element, attribute, content model, and interface indexes
12  !    - adding it to the section with ARIA mappings
13  !
14  !-->
15 <!--START validation-->
16 <pre class="idl">
17  interface Screen { }; // CSSOM
18  interface URL { }; // URL API
19  interface Blob { }; // File API
20  interface File : Blob { }; // File API
21  interface FileList { }; // File API
22  interface WebGLRenderingContext { }; // WebGL
23  interface ArrayBuffer { }; // TypedArray
24  interface ArrayBufferView { }; // TypedArray
25  interface Uint8ClampedArray { }; // TypedArray
26  interface XMLDocument { }; // DOM
27  interface HTMLCollection { }; // DOM
28  interface DOMTokenList { }; // DOM
29  interface DOMSettableTokenList { attribute any value; }; // DOM
30  interface SVGMatrix { }; // SVG
31 </pre>
32 <!--DEFER snapshot complete-->
33 <!--START complete--><!--START dev-html-->
34
35    <!-- An advisory for those reading this source. -->
36
37    <!-- In this specification, there are a number of comments (like
38         this one) that have three consecutive Xs. These indicate known
39         problems that are expected to be resolved in the future. -->
40
41    <!-- There are also comments with the string "v2", "v3", "v4", or
42         higher numbers. These indicate ideas for future versions of
43         the specification that have not yet been included, usually
44         because it's too early (one has to move slowly lest the
45         browser vendors get overwhelmed with changes). -->
46
47    <!-- Finally, there may also be some known issues in this
48         specification marked with the following punctuation: -->
49
50            <!--!-->
51
52    <!-- These are issues that are known to the editor but cannot be
53         currently fixed because they were introduced by W3C decisions.
54         In theory we could fork the WHATWG copy of the spec, but doing
55         so would introduce normative differences between the W3C and
56         WHATWG specs and these issues are not worth the hassle that
57         this would cause. We'll probably be able to fix them some day,
58         but for now we are living with them. -->
59
60 <!--START storage-->
61 <!--SET FINGERPRINT=<a href="#fingerprint" class="fingerprint"><img src="images/fingerprint.png" alt="(This is a fingerprinting vector.)" width=46 height=64></a>-->
62 <!--END storage-->
63
64
65   <h2 id="introduction">Introduction</h2>
66
67 <!--END dev-html-->
68   <h3 id="abstract">Where does this specification fit?</h3>
69
70   <p>This specification defines a big part of the Web platform, in
71   lots of detail. Its place in the Web platform specification stack
72   relative to other specifications can be best summed up as
73   follows:</p>
74
75   <p><img src="images/abstract.png" width="398" height="359" alt="It consists of everything else, above such core technologies as HTTP, URI/IRIs, DOM, XML, Unicode, and ECMAScript; below presentation-layer technologies like CSS, XBL, and the NPAPI; and to the side of technologies like Geolocation, SVG, MathML, and XHR."></p>
76 <!--START dev-html-->
77
78
79   <h3 id="is-this-html5?">Is this HTML5?</h3><!--VERSION-->
80
81   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
82
83   <p>In short: Yes.</p>
84
85   <p>In more length: The term "HTML5" is widely used as a buzzword to
86   refer to modern Web technologies, many of which (though by no means
87   all) are developed at the WHATWG, in some cases in conjunction with
88   the W3C and IETF.</p>
89
90   <p>The WHATWG work is all published in one specification
91 <!--END dev-html-->
92   (the one you are reading right now),
93 <!--START dev-html-->
94   parts of which are republished in an edition optimized for Web developers
95 <!--END complete-->
96   (which you are reading right now).
97 <!--START complete-->
98   </p>
99
100   <p>The W3C also publishes parts of this specification as separate
101   documents. One of these parts is called "HTML5"; it is a forked subset of
102 <!--END dev-html-->
103   this specification (the HTML Living Standard).
104 <!--END complete-->
105 <!--START dev-html-->
106   the <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">HTML Living Standard</a>.
107 <!--START complete-->
108   There are numerous differences between 
109 <!--END dev-html-->
110   this specification (the HTML Living Standard)
111 <!--END complete-->
112 <!--START dev-html-->
113   the <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">HTML Living Standard</a>
114 <!--START complete-->
115   and the W3C version, some minor, some major. Unfortunately these are not currently accurately
116   documented anywhere, so there is no way to know which are intentional and which are not.</p>
117
118
119
120   <h3>Background</h3>
121
122   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
123
124   <p>The World Wide Web's markup language has always been HTML. HTML was primarily designed as a
125   language for semantically describing scientific documents, although its general design and
126   adaptations over the years have enabled it to be used to describe a number of other types of
127   documents.</p>
128
129   <p>The main area that has not been adequately addressed by HTML is a vague subject referred to as
130   Web Applications. This specification attempts to rectify this, while at the same time updating the
131   HTML specifications to address issues raised in the past few years.</p>
132
133
134   <h3>Audience</h3>
135
136   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
137
138   <p>This specification is intended for authors of documents and scripts that use the features
139   defined in this specification<span class="impl">, implementors of tools that operate on pages that
140   use the features defined in this specification, and individuals wishing to establish the
141   correctness of documents or implementations with respect to the requirements of this
142   specification</span>.</p>
143
144   <p>This document is probably not suited to readers who do not already have at least a passing
145   familiarity with Web technologies, as in places it sacrifices clarity for precision, and brevity
146   for completeness. More approachable tutorials and authoring guides can provide a gentler
147   introduction to the topic.</p>
148
149   <p>In particular, familiarity with the basics of DOM is necessary for a complete understanding of
150   some of the more technical parts of this specification. An understanding of Web IDL, HTTP, XML,
151   Unicode, character encodings, JavaScript, and CSS will also be helpful in places but is not
152   essential.</p>
153
154
155   <h3>Scope</h3>
156
157   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
158
159   <p>This specification is limited to providing a semantic-level markup language and associated
160   semantic-level scripting APIs for authoring accessible pages on the Web ranging from static
161   documents to dynamic applications.</p>
162
163   <p>The scope of this specification does not include providing mechanisms for media-specific
164   customization of presentation (although default rendering rules for Web browsers are included at
165   the end of this specification, and several mechanisms for hooking into CSS are provided as part of
166   the language).</p>
167
168   <p>The scope of this specification is not to describe an entire operating system. In particular,
169   hardware configuration software, image manipulation tools, and applications that users would be
170   expected to use with high-end workstations on a daily basis are out of scope. In terms of
171   applications, this specification is targeted specifically at applications that would be expected
172   to be used by users on an occasional basis, or regularly but from disparate locations, with low
173   CPU requirements. Examples of such applications include online purchasing systems, searching
174   systems, games (especially multiplayer online games), public telephone books or address books,
175   communications software (e-mail clients, instant messaging clients, discussion software), document
176   editing software, etc.</p>
177
178
179   <h3>History</h3>
180
181   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
182
183   <p>For its first five years (1990-1995), HTML went through a number of revisions and experienced a
184   number of extensions, primarily hosted first at CERN, and then at the IETF.</p>
185
186   <p>With the creation of the W3C, HTML's development changed venue again. A first abortive attempt
187   at extending HTML in 1995 known as HTML 3.0 then made way to a more pragmatic approach known as
188   HTML 3.2, which was completed in 1997. HTML4 quickly followed later that same year.</p>
189
190   <p>The following year, the W3C membership decided to stop evolving HTML and instead begin work on
191   an XML-based equivalent, called XHTML. <!-- http://www.w3.org/MarkUp/future/#summary --> This
192   effort started with a reformulation of HTML4 in XML, known as XHTML 1.0, which added no new
193   features except the new serialization, and which was completed in 2000. After XHTML 1.0, the W3C's
194   focus turned to making it easier for other working groups to extend XHTML, under the banner of
195   XHTML Modularization. In parallel with this, the W3C also worked on a new language that was not
196   compatible with the earlier HTML and XHTML languages, calling it XHTML2.</p>
197
198   <p>Around the time that HTML's evolution was stopped in 1998, parts of the API for HTML developed
199   by browser vendors were specified and published under the name DOM Level 1 (in 1998) and DOM Level
200   2 Core and DOM Level 2 HTML (starting in 2000 and culminating in 2003). These efforts then petered
201   out, with some DOM Level 3 specifications published in 2004 but the working group being closed
202   before all the Level 3 drafts were completed.</p>
203
204   <p>In 2003, the publication of XForms, a technology which was positioned as the next generation of
205   Web forms, sparked a renewed interest in evolving HTML itself, rather than finding replacements
206   for it. This interest was borne from the realization that XML's deployment as a Web technology was
207   limited to entirely new technologies (like RSS and later Atom), rather than as a replacement for
208   existing deployed technologies (like HTML).</p>
209
210   <p>A proof of concept to show that it was possible to extend HTML4's forms to provide many of the
211   features that XForms 1.0 introduced, without requiring browsers to implement rendering engines
212   that were incompatible with existing HTML Web pages, was the first result of this renewed
213   interest. At this early stage, while the draft was already publicly available, and input was
214   already being solicited from all sources, the specification was only under Opera Software's
215   copyright.</p>
216
217   <p>The idea that HTML's evolution should be reopened was tested at a W3C workshop in 2004, where
218   some of the principles that underlie the HTML5 work (described below), as well as the
219   aforementioned early draft proposal covering just forms-related features, were presented to the
220   W3C jointly by Mozilla and Opera. The proposal was rejected on the grounds that the proposal
221   conflicted with the previously chosen direction for the Web's evolution; the W3C staff and
222   membership voted to continue developing XML-based replacements instead.</p>
223
224   <p>Shortly thereafter, Apple, Mozilla, and Opera jointly announced their intent to continue
225   working on the effort under the umbrella of a new venue called the WHATWG. A public mailing list
226   was created, and the draft was moved to the WHATWG site. The copyright was subsequently amended to
227   be jointly owned by all three vendors, and to allow reuse of the specification.</p>
228
229   <p>The WHATWG was based on several core principles, in particular that technologies need to be
230   backwards compatible, that specifications and implementations need to match even if this means
231   changing the specification rather than the implementations, and that specifications need to be
232   detailed enough that implementations can achieve complete interoperability without
233   reverse-engineering each other.</p>
234
235   <p>The latter requirement in particular required that the scope of the HTML5 specification include
236   what had previously been specified in three separate documents: HTML4, XHTML1, and DOM2 HTML. It
237   also meant including significantly more detail than had previously been considered the norm.</p>
238
239   <p>In 2006, the W3C indicated an interest to participate in the development of HTML5 after all,
240   and in 2007 formed a working group chartered to work with the WHATWG on the development of the
241   HTML5 specification. Apple, Mozilla, and Opera allowed the W3C to publish the specification under
242   the W3C copyright, while keeping a version with the less restrictive license on the WHATWG
243   site.</p>
244
245   <p>For a number of years, both groups then worked together. In 2011, however, the groups came to
246   the conclusion that they had different goals: the W3C wanted to publish a "finished" version of
247   "HTML5", while the WHATWG wanted to continue working on a Living Standard for HTML, continuously
248   maintaining the specification rather than freezing it in a state with known problems, and adding
249   new features as needed to evolve the platform.</p>
250
251   <p>Since then, the WHATWG has been working on this specification (amongst others), and the W3C has
252   been copying fixes made by the WHATWG into their fork of the document, as well as making other
253   changes, many of which are described <a href="#is-this-html5?">above</a>.</p>
254
255
256
257
258   <h3>Design notes</h3>
259
260   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
261
262   <p>It must be admitted that many aspects of HTML appear at first glance to be nonsensical and
263   inconsistent.</p>
264
265   <p>HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been
266   developed over a period of several decades by a wide array of people with different priorities
267   who, in many cases, did not know of each other's existence.</p>
268
269   <p>Features have thus arisen from many sources, and have not always been designed in especially
270   consistent ways. Furthermore, because of the unique characteristics of the Web, implementation
271   bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally
272   written in ways that rely on them before they can be fixed.</p>
273
274   <p>Despite all this, efforts have been made to adhere to certain design goals. These are described
275   in the next few subsections.</p>
276
277
278   <h4>Serializability of script execution</h4>
279
280   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
281
282   <p>To avoid exposing Web authors to the complexities of multithreading, the HTML and DOM APIs are
283   designed such that no script can ever detect the simultaneous execution of other scripts. Even
284   with <span title="Worker">workers</span>, the intent is that the behavior of implementations can
285   be thought of as completely serializing the execution of all scripts in all <span title="browsing
286   context">browsing contexts</span>.</p>
287
288   <p class="note">The <code
289   title="dom-navigator-yieldForStorageUpdates">navigator.yieldForStorageUpdates()</code> method, in
290   this model, is equivalent to allowing other scripts to run while the calling script is
291   blocked.</p>
292
293
294   <h4>Compliance with other specifications</h4>
295
296   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
297
298   <p>This specification interacts with and relies on a wide variety of other specifications. In
299   certain circumstances, unfortunately, conflicting needs have led to this specification violating
300   the requirements of these other specifications. Whenever this has occurred, the transgressions
301   have each been noted as a "<dfn>willful violation</dfn>", and the reason for the violation has
302   been noted.</p>
303
304
305
306
307   <h3>HTML vs XHTML</h3>
308
309   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
310
311   <p>This specification defines an abstract language for describing documents and applications, and
312   some APIs for interacting with in-memory representations of resources that use this language.</p>
313
314   <p>The in-memory representation is known as "DOM HTML", or "the DOM" for short.</p>
315
316   <p>There are various concrete syntaxes that can be used to transmit resources that use this
317   abstract language, two of which are defined in this specification.</p>
318
319   <p>The first such concrete syntax is the HTML syntax. This is the format suggested for most
320   authors. It is compatible with most legacy Web browsers. If a document is transmitted with the
321   <code>text/html</code> <span>MIME type</span>, then it will be processed as an HTML document by
322   Web browsers. This specification defines the latest HTML syntax, known simply as "HTML".</p>
323
324   <p>The second concrete syntax is the XHTML syntax, which is an application of XML. When a document
325   is transmitted with an <span>XML MIME type</span>, such as <code>application/xhtml+xml</code>,
326   then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors
327   are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors
328   will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in
329   the HTML syntax. This specification defines the latest XHTML syntax, known simply as "XHTML".</p>
330
331   <p>The DOM, the HTML syntax, and the XHTML syntax cannot all represent the same content. For
332   example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM
333   and in the XHTML syntax. Similarly, documents that use the <code>noscript</code> feature can be
334   represented using the HTML syntax, but cannot be represented with the DOM or in the XHTML syntax.
335   Comments that contain the string "<code title="">--&gt;</code>" can only be represented in the
336   DOM, not in the HTML and XHTML syntaxes.</p>
337
338
339   <h3>Structure of this specification</h3>
340
341   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
342
343   <p>This specification is divided into the following major sections:</p>
344
345   <dl>
346
347
348    <dt><a href="#introduction">Introduction</a></dt>
349
350    <dd>Non-normative materials providing a context for the HTML standard.</dd>
351
352
353    <dt><a href="#infrastructure">Common infrastructure</a></dt>
354
355    <dd>The conformance classes, algorithms, definitions, and the common underpinnings of the rest of
356    the specification.</dd>
357
358
359    <dt><a href="#dom">Semantics, structure, and APIs of HTML documents</a></dt>
360
361    <dd>Documents are built from elements. These elements form a tree using the DOM. This section
362    defines the features of this DOM, as well as introducing the features common to all elements, and
363    the concepts used in defining elements.</dd>
364
365
366    <dt><a href="#semantics">The elements of HTML</a></dt>
367
368    <dd>Each element has a predefined meaning, which is explained in this section. Rules for authors
369    on how to use the element<span class="impl">, along with user agent requirements for how to
370    handle each element,</span> are also given. This includes large signature features of HTML such
371    as video playback and subtitles, form controls and form submission, and a 2D graphics API known
372    as the HTML canvas.</dd>
373
374
375    <dt><a href="#microdata">Microdata</a></dt>
376
377    <dd>This specification introduces a mechanism for adding machine-readable annotations to
378    documents, so that tools can extract trees of name-value pairs from the document. This section
379    describes this mechanism<span class="impl"> and some algorithms that can be used to convert HTML
380    documents into other formats</span>. This section also defines some sample Microdata vocabularies
381    for contact information, calendar events, and licensing works.</dd>
382
383
384    <dt><a href="#browsers">Loading Web pages</a></dt>
385
386    <dd>HTML documents do not exist in a vacuum &mdash; this section defines many of the features
387    that affect environments that deal with multiple pages, such as Web browsers and offline
388    caching of Web applications.</dd>
389
390
391    <dt><a href="#webappapis">Web application APIs</a></dt>
392
393    <dd>This section introduces basic features for scripting of applications in HTML.</dd>
394
395
396    <dt><a href="#editing">User interaction</a></dt>
397
398    <dd>HTML documents can provide a number of mechanisms for users to interact with and modify
399    content, which are described in this section, such as how focus works, and drag-and-drop.</dd>
400
401
402 <!--END dev-html-->
403    <dt><a href="#workers">Web workers</a></dt>
404
405    <dd>This section defines an API for background threads in JavaScript.</dd>
406 <!--START dev-html-->
407
408
409    <dt><a href="#comms">The communication APIs</a></dt>
410
411    <dd>This section describes some mechanisms that applications written in HTML can use to
412    communicate with other applications from different domains running on the same client.
413
414 <!--END dev-html-->
415    It also introduces a server-push event stream mechanism known as Server Sent Events or
416    <code>EventSource</code>, and a two-way full-duplex socket protocol for scripts known as Web
417    Sockets.
418 <!--START dev-html-->
419
420    </dd>
421
422
423 <!--END dev-html-->
424    <dt><a href="#webstorage">Web storage</a></dt>
425
426    <dd>This section defines a client-side storage mechanism based on name-value pairs.</dd>
427 <!--START dev-html-->
428
429
430    <dt><a href="#syntax">The HTML syntax</a></dt>
431    <dt><a href="#xhtml">The XHTML syntax</a></dt>
432
433    <dd>All of these features would be for naught if they couldn't be represented in a serialized
434    form and sent to other people, and so these sections define the syntaxes of HTML and XHTML<span
435    class="impl">, along with rules for how to parse content using those syntaxes</span>.</dd>
436
437
438    <dt><a href="#rendering">Rendering</a></dt>
439
440    <dd>This section defines the default rendering rules for Web browsers.</dd>
441
442
443   </dl>
444
445   <p>There are also some appendices, listing <a href="#obsolete">obsolete features</a> and <a
446   href="#iana">IANA considerations</a>, and several indices.</p>
447
448
449
450   <h4>How to read this specification</h4>
451
452   <p>This specification should be read like all other specifications. First, it should be read
453   cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be
454   read by picking random sections from the contents list and following all the cross-references.</p>
455
456   <p>As described in the conformance requirements section below, this specification describes
457   conformance criteria for a variety of conformance classes. In particular, there are conformance
458   requirements that apply to <em>producers</em>, for example authors and the documents they create,
459   and there are conformance requirements that apply to <em>consumers</em>, for example Web browsers.
460   They can be distinguished by what they are requiring: a requirement on a producer states what is
461   allowed, while a requirement on a consumer states how software is to act.</p>
462
463   <div class="example">
464
465    <p>For example, "the <code title="">foo</code> attribute's value must be a <span>valid
466    integer</span>" is a requirement on producers, as it lays out the allowed values; in contrast,
467    the requirement "the <code title="">foo</code> attribute's value must be parsed using the
468    <span>rules for parsing integers</span>" is a requirement on consumers, as it describes how to
469    process the content.</p>
470
471   </div>
472
473   <p><strong>Requirements on producers have no bearing whatsoever on consumers.</strong></p>
474
475   <div class="example">
476
477    <p>Continuing the above example, a requirement stating that a particular attribute's value is
478    constrained to being a <span>valid integer</span> emphatically does <em>not</em> imply anything
479    about the requirements on consumers. It might be that the consumers are in fact required to treat
480    the attribute as an opaque string, completely unaffected by whether the value conforms to the
481    requirements or not. It might be (as in the previous example) that the consumers are required to
482    parse the value using specific rules that define how invalid (non-numeric in this case) values
483    are to be processed.</p>
484
485   </div>
486
487
488
489   <h4>Typographic conventions</h4>
490
491   <p>This is a definition, requirement, or explanation.</p>
492
493   <p class="note">This is a note.</p>
494
495   <p class="example">This is an example.</p>
496
497   <p class="&#x0058;&#x0058;&#x0058;">This is an open issue.</p>
498
499   <p class="warning">This is a warning.</p>
500
501   <pre class="idl extract">interface <dfn title="">Example</dfn> {
502   // this is an IDL definition
503 };</pre>
504
505   <dl class="domintro">
506
507    <dt><var title="">variable</var> = <var title="">object</var> . <code title="">method</code>( [ <var title="">optionalArgument</var> ] )</dt>
508
509    <dd>
510
511     <p>This is a note to authors describing the usage of an interface.</p>
512
513    </dd>
514
515   </dl>
516
517   <pre class="css">/* this is a CSS fragment */</pre>
518
519   <p>The defining instance of a term is marked up like <dfn title="x-this">this</dfn>. Uses of that
520   term are marked up like <span title="x-this">this</span> or like <i title="x-this">this</i>.</p>
521
522   <p>The defining instance of an element, attribute, or API is marked up like <dfn
523   title="x-that"><code>this</code></dfn>. References to that element, attribute, or API are marked
524   up like <code title="x-that">this</code>.</p>
525
526   <p>Other code fragments are marked up <code title="">like this</code>.</p>
527
528   <p>Variables are marked up like <var title="">this</var>.</p>
529
530   <p class="impl">This is an implementation requirement.</p>
531
532   <p>In an algorithm, steps in <span title="synchronous section">synchronous sections</span> are
533   marked with &#x231B;.</p>
534
535
536   <h3 id="fingerprint">Privacy concerns</h3>
537
538   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
539
540   <p>Some features of HTML trade user convenience for a measure of user privacy.</p>
541
542   <p>In general, due to the Internet's architecture, a user can be distinguished from another by the
543   user's IP address. IP addresses do not perfectly match to a user; as a user moves from device to
544   device, or from network to network, their IP address will change; similarly, NAT routing, proxy
545   servers, and shared computers enable packets that appear to all come from a single IP address to
546   actually map to multiple users. Technologies such as onion routing can be used to further
547   anonymize requests so that requests from a single user at one node on the Internet appear to come
548   from many disparate parts of the network.</p>
549
550   <p>However, the IP address used for a user's requests is not the only mechanism by which a user's
551   requests could be related to each other. Cookies, for example, are designed specifically to enable
552   this, and are the basis of most of the Web's session features that enable you to log into a site
553   with which you have an account.</p>
554
555   <p>There are other mechanisms that are more subtle. Certain characteristics of a user's system can
556   be used to distinguish groups of users from each other; by collecting enough such information, an
557   individual user's browser's "digital fingerprint" can be computed, which can be as good, if not
558   better, as an IP address in ascertaining which requests are from the same user.</p>
559
560   <p>Grouping requests in this manner, especially across multiple sites, can be used for both benign
561   (and even arguably positive) purposes, as well as for malevolent purposes. An example of a
562   reasonably benign purpose would be determining whether a particular person seems to prefer sites
563   with dog illustrations as opposed to sites with cat illustrations (based on how often they visit
564   the sites in question) and then automatically using the preferred illustrations on subsequent
565   visits to participating sites. Malevolent purposes, however, could include governments combining
566   information such as the person's home address (determined from the addresses they use when getting
567   driving directions on one site) with their apparent political affiliations (determined by
568   examining the forum sites that they participate in) to determine whether the person should be
569   prevented from voting in an election.</p>
570
571   <p>Since the malevolent purposes can be remarkably evil, user agent implementors are encouraged to
572   consider how to provide their users with tools to minimize leaking information that could be used
573   to fingerprint a user.</p>
574
575   <p>Unfortunately, as the first paragraph in this section implies, sometimes there is great benefit
576   to be derived from exposing the very information that can also be used for fingerprinting
577   purposes, so it's not as easy as simply blocking all possible leaks. For instance, the ability to
578   log into a site to post under a specific identity requires that the user's requests be
579   identifiable as all being from the same user, more or less by definition. More subtly, though,
580   information such as how wide text is, which is necessary for many effects that involve drawing
581   text onto a canvas (e.g. any effect that involves drawing a border around the text) also leaks
582   information that can be used to group a user's requests. (In this case, by potentially exposing,
583   via a brute force search, which fonts a user has installed, information which can vary
584   considerably from user to user.)</p>
585
586   <p>Features in this specification which can be used to fingerprint the user are marked as this
587   paragraph is.
588   <!--INSERT FINGERPRINT-->
589   </p>
590
591   <p>Other features in the platform can be used for the same purpose, though, including, though not
592   limited to:</p>
593
594   <ul>
595
596    <li>The exact list of which features a user agents supports.</li>
597
598    <li>The maximum allowed stack depth for recursion in script.</li>
599
600    <li>Features that describe the user's environment, like Media Queries and the <code>Screen</code>
601    object. <a href="#refsMQ">[MQ]</a> <a href="#refsCSSOMVIEW">[CSSOMVIEW]</a></li>
602
603    <li>The user's time zone.</li>
604
605   </ul>
606
607
608   <h3>A quick introduction to HTML</h3>
609
610   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
611
612   <p>A basic HTML document looks like this:</p>
613
614   <pre id="intro-early-example">&lt;!DOCTYPE html>
615 &lt;html>
616  &lt;head>
617   &lt;title>Sample page&lt;/title>
618  &lt;/head>
619  &lt;body>
620   &lt;h1>Sample page&lt;/h1>
621   &lt;p>This is a &lt;a href="demo.html">simple&lt;/a> sample.&lt;/p>
622   &lt;!-- this is a comment -->
623  &lt;/body>
624 &lt;/html></pre>
625
626   <p>HTML documents consist of a tree of elements and text. Each element is denoted in the source by
627   a <span title="syntax-start-tag">start tag</span>, such as "<code title="">&lt;body></code>", and
628   an <span title="syntax-end-tag">end tag</span>, such as "<code title="">&lt;/body></code>".
629   (Certain start tags and end tags can in certain cases be <span
630   title="syntax-tag-omission">omitted</span> and are implied by other tags.)</p>
631
632   <p>Tags have to be nested such that elements are all completely within each other, without
633   overlapping:</p>
634
635   <pre class="bad">&lt;p>This is &lt;em>very &lt;strong>wrong&lt;/em>!&lt;/strong>&lt;/p></pre>
636   <pre>&lt;p>This &lt;em>is &lt;strong>correct&lt;/strong>.&lt;/em>&lt;/p></pre>
637
638   <p>This specification defines a set of elements that can be used in HTML, along with rules about
639   the ways in which the elements can be nested.</p>
640
641   <p>Elements can have attributes, which control how the elements work. In the example below, there
642   is a <span>hyperlink</span>, formed using the <code>a</code> element and its <code
643   title="attr-hyperlink-href">href</code> attribute:</p>
644
645   <pre>&lt;a href="demo.html">simple&lt;/a></pre>
646
647   <p><span title="syntax-attributes">Attributes</span> are placed inside the start tag, and consist
648   of a <span title="syntax-attribute-name">name</span> and a <span
649   title="syntax-attribute-value">value</span>, separated by an "<code title="">=</code>" character.
650   The attribute value can remain <a href="#unquoted">unquoted</a> if it doesn't contain <span
651   title="space character">space characters</span> or any of <code title="">"</code> <code
652   title="">'</code> <code title="">`</code> <code title="">=</code> <code title="">&lt;</code> or
653   <code title="">&gt;</code>. Otherwise, it has to be quoted using either single or double quotes.
654   The value, along with the "<code title="">=</code>" character, can be omitted altogether if the
655   value is the empty string.</p>
656
657   <pre>&lt;!-- empty attributes -->
658 &lt;input name=address disabled>
659 &lt;input name=address disabled="">
660
661 &lt;!-- attributes with a value -->
662 &lt;input name=address maxlength=200>
663 &lt;input name=address maxlength='200'>
664 &lt;input name=address maxlength="200"></pre>
665
666   <p>HTML user agents (e.g. Web browsers) then <i>parse</i> this markup, turning it into a DOM
667   (Document Object Model) tree. A DOM tree is an in-memory representation of a document.</p>
668
669   <p>DOM trees contain several kinds of nodes, in particular a <code>DocumentType</code> node,
670   <code>Element</code> nodes, <code>Text</code> nodes, <code>Comment</code> nodes, and in some cases
671   <code>ProcessingInstruction</code> nodes.</p>
672
673   <p>The <a href="#intro-early-example">markup snippet at the top of this section</a> would be
674   turned into the following DOM tree:</p>
675
676   <ul class="domTree"><li class="t10">DOCTYPE: <code title="">html</code></li><li class="t1"><code>html</code><ul><li class="t1"><code>head</code><ul><li class="t3"><code>#text</code>: <span title="">&#x23CE;&#x2423;&#x2423;</span></li><li class="t1"><code>title</code><ul><li class="t3"><code>#text</code>: <span title="">Sample page</span></li></ul></li><li class="t3"><code>#text</code>: <span title="">&#x23CE;&#x2423;</span></li></ul></li><li class="t3"><code>#text</code>: <span title="">&#x23CE;&#x2423;</span></li><li class="t1"><code>body</code><ul><li class="t3"><code>#text</code>: <span title="">&#x23CE;&#x2423;&#x2423;</span></li><li class="t1"><code>h1</code><ul><li class="t3"><code>#text</code>: <span title="">Sample page</span></li></ul></li><li class="t3"><code>#text</code>: <span title="">&#x23CE;&#x2423;&#x2423;</span></li><li class="t1"><code>p</code><ul><li class="t3"><code>#text</code>: <span title="">This is a <!--grammar-check-override--></span></li><li class="t1"><code>a</code> <span title="" class="t2"><code class="attribute name">href</code>="<code class="attribute value">demo.html</code>"</span><ul><li class="t3"><code>#text</code>: <span title="">simple</span></li></ul></li><li class="t3"><code>#text</code>: <span title=""> sample.</span></li></ul></li><li class="t3"><code>#text</code>: <span title="">&#x23CE;&#x2423;&#x2423;</span></li><li class="t8"><code>#comment</code>: <span title=""> this is a comment </span></li><li class="t3"><code>#text</code>: <span title="">&#x23CE;&#x2423;&#x23CE;</span></li></ul></li></ul></li></ul>
677
678   <p>The <span>root element</span> of this tree is the <code>html</code> element, which is the
679   element always found at the root of HTML documents. It contains two elements, <code>head</code>
680   and <code>body</code>, as well as a <code>Text</code> node between them.</p>
681
682   <p>There are many more <code>Text</code> nodes in the DOM tree than one would initially expect,
683   because the source contains a number of spaces (represented here by "&#x2423;") and line breaks
684   ("&#x23CE;") that all end up as <code>Text</code> nodes in the DOM. However, for historical
685   reasons not all of the spaces and line breaks in the original markup appear in the DOM. In
686   particular, all the whitespace before <code>head</code> start tag ends up being dropped silently,
687   and all the whitespace after the <code>body</code> end tag ends up placed at the end of the
688   <code>body</code>.</p>
689
690   <p>The <code>head</code> element contains a <code>title</code> element, which itself contains a
691   <code>Text</code> node with the text "Sample page". Similarly, the <code>body</code> element
692   contains an <code>h1</code> element, a <code>p</code> element, and a comment.</p>
693
694   <hr>
695
696   <p>This DOM tree can be manipulated from scripts in the page. Scripts (typically in JavaScript)
697   are small programs that can be embedded using the <code>script</code> element or using <span>event
698   handler content attributes</span>. For example, here is a form with a script that sets the value
699   of the form's <code>output</code> element to say "Hello World":</p>
700
701   <pre>&lt;<span>form</span> <span title="attr-form-name">name</span>="main">
702  Result: &lt;<span>output</span> <span title="attr-fe-name">name</span>="result">&lt;/output>
703  &lt;<span>script</span>>
704   <span title="Document">document</span>.<span title="dom-document-forms">forms</span>.main.<span title="dom-form-elements">elements</span>.result.<span title="dom-output-value">value</span> = 'Hello World';
705  &lt;/script>
706 &lt;/form></pre>
707
708   <p>Each element in the DOM tree is represented by an object, and these objects have APIs so that
709   they can be manipulated. For instance, a link (e.g. the <code>a</code> element in the tree above)
710   can have its "<code title="attr-hyperlink-href">href</code>" attribute changed in several
711   ways:</p>
712
713   <pre>var a = <span title="Document">document</span>.<span title="dom-document-links">links</span>[0]; // obtain the first link in the document
714 a.<span title="dom-url-href">href</span> = 'sample.html'; // change the destination URL of the link
715 a.<span title="dom-url-protocol">protocol</span> = 'https'; // change just the scheme part of the URL
716 a.setAttribute('href', 'http://example.com/'); // change the content attribute directly</pre>
717
718   <p>Since DOM trees are used as the way to represent HTML documents when they are processed and
719   presented by implementations (especially interactive implementations like Web browsers), this
720   specification is mostly phrased in terms of DOM trees, instead of the markup described above.</p>
721
722   <hr>
723
724   <p>HTML documents represent a media-independent description of interactive content. HTML documents
725   might be rendered to a screen, or through a speech synthesizer, or on a braille display. To
726   influence exactly how such rendering takes place, authors can use a styling language such as
727   CSS.</p>
728
729   <p>In the following example, the page has been made yellow-on-blue using CSS.</p>
730
731   <pre>&lt;!DOCTYPE html>
732 &lt;html>
733  &lt;head>
734   &lt;title>Sample styled page&lt;/title>
735   &lt;style>
736    body { background: navy; color: yellow; }
737   &lt;/style>
738  &lt;/head>
739  &lt;body>
740   &lt;h1>Sample styled page&lt;/h1>
741   &lt;p>This page is just a demo.&lt;/p>
742  &lt;/body>
743 &lt;/html></pre>
744
745   <p>For more details on how to use HTML, authors are encouraged to consult tutorials and guides.
746   Some of the examples included in this specification might also be of use, but the novice author is
747   cautioned that this specification, by necessity, defines the language with a level of detail that
748   might be difficult to understand at first.</p>
749
750 <!--ADD-TOPIC:Security-->
751   <h4>Writing secure applications with HTML</h4>
752
753   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
754
755   <p>When HTML is used to create interactive sites, care needs to be taken to avoid introducing
756   vulnerabilities through which attackers can compromise the integrity of the site itself or of the
757   site's users.</p>
758
759   <p>A comprehensive study of this matter is beyond the scope of this document, and authors are
760   strongly encouraged to study the matter in more detail. However, this section attempts to provide
761   a quick introduction to some common pitfalls in HTML application development.</p>
762
763   <p>The security model of the Web is based on the concept of "origins", and correspondingly many of
764   the potential attacks on the Web involve cross-origin actions. <a
765   href="#refsORIGIN">[ORIGIN]</a></p>
766
767   <dl>
768
769    <dt>Not validating user input</dt>
770    <dt>Cross-site scripting (XSS)</dt>
771    <dt>SQL injection</dt>
772
773    <dd>
774
775     <p>When accepting untrusted input, e.g. user-generated content such as text comments, values in
776     URL parameters, messages from third-party sites, etc, it is imperative that the data be
777     validated before use, and properly escaped when displayed. Failing to do this can allow a
778     hostile user to perform a variety of attacks, ranging from the potentially benign, such as
779     providing bogus user information like a negative age, to the serious, such as running scripts
780     every time a user looks at a page that includes the information, potentially propagating the
781     attack in the process, to the catastrophic, such as deleting all data in the server.</p>
782
783     <p>When writing filters to validate user input, it is imperative that filters always be
784     whitelist-based, allowing known-safe constructs and disallowing all other input. Blacklist-based
785     filters that disallow known-bad inputs and allow everything else are not secure, as not
786     everything that is bad is yet known (for example, because it might be invented in the
787     future).</p>
788
789     <div class="example">
790
791      <p>For example, suppose a page looked at its URL's query string to determine what to display,
792      and the site then redirected the user to that page to display a message, as in:</p>
793
794      <pre>&lt;ul>
795  &lt;li>&lt;a href="message.cgi?say=Hello">Say Hello&lt;/a>
796  &lt;li>&lt;a href="message.cgi?say=Welcome">Say Welcome&lt;/a>
797  &lt;li>&lt;a href="message.cgi?say=Kittens">Say Kittens&lt;/a>
798 &lt;/ul></pre>
799
800      <p>If the message was just displayed to the user without escaping, a hostile attacker could
801      then craft a URL that contained a script element:</p>
802
803      <pre>http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E</pre>
804
805      <p>If the attacker then convinced a victim user to visit this page, a script of the attacker's
806      choosing would run on the page. Such a script could do any number of hostile actions, limited
807      only by what the site offers: if the site is an e-commerce shop, for instance, such a script
808      could cause the user to unknowingly make arbitrarily many unwanted purchases.</p>
809
810      <p>This is called a cross-site scripting attack.</p>
811
812     </div>
813
814     <p>There are many constructs that can be used to try to trick a site into executing code. Here
815     are some that authors are encouraged to consider when writing whitelist filters:</p>
816
817     <ul>
818
819      <li>When allowing harmless-seeming elements like <code>img</code>, it is important to whitelist
820      any provided attributes as well. If one allowed all attributes then an attacker could, for
821      instance, use the <code title="handler-onload">onload</code> attribute to run arbitrary
822      script.</li>
823
824      <li>When allowing URLs to be provided (e.g. for links), the scheme of each URL also needs to be
825      explicitly whitelisted, as there are many schemes that can be abused. The most prominent
826      example is "<code title="javascript-protocol">javascript:</code>", but user agents can
827      implement (and indeed, have historically implemented) others.</li> <!-- IE had vbscript:,
828      Netscape had livescript:, etc. -->
829
830      <li>Allowing a <code>base</code> element to be inserted means any <code>script</code> elements
831      in the page with relative links can be hijacked, and similarly that any form submissions can
832      get redirected to a hostile site.</li>
833
834     </ul>
835
836    </dd>
837
838
839    <dt>Cross-site request forgery (CSRF)</dt>
840
841    <dd>
842
843     <p>If a site allows a user to make form submissions with user-specific side-effects, for example
844     posting messages on a forum under the user's name, making purchases, or applying for a passport,
845     it is important to verify that the request was made by the user intentionally, rather than by
846     another site tricking the user into making the request unknowingly.</p>
847
848     <p>This problem exists because HTML forms can be submitted to other origins.</p>
849
850     <p>Sites can prevent such attacks by populating forms with user-specific hidden tokens, or by
851     checking <code title="http-origin">Origin</code> headers on all requests.</p>
852
853    </dd>
854
855
856
857    <dt>Clickjacking</dt>
858
859    <dd>
860
861     <p>A page that provides users with an interface to perform actions that the user might not wish
862     to perform needs to be designed so as to avoid the possibility that users can be tricked into
863     activating the interface.</p>
864
865     <p>One way that a user could be so tricked is if a hostile site places the victim site in a
866     small <code>iframe</code> and then convinces the user to click, for instance by having the user
867     play a reaction game. Once the user is playing the game, the hostile site can quickly position
868     the iframe under the mouse cursor just as the user is about to click, thus tricking the user
869     into clicking the victim site's interface.</p>
870
871     <p>To avoid this, sites that do not expect to be used in frames are encouraged to only enable
872     their interface if they detect that they are not in a frame (e.g. by comparing the <code
873     title="dom-window">window</code> object to the value of the <code title="dom-top">top</code>
874     attribute).</p>
875
876    </dd>
877
878   </dl>
879 <!--REMOVE-TOPIC:Security-->
880
881
882   <h4>Common pitfalls to avoid when using the scripting APIs</h4>
883
884   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
885
886   <p>Scripts in HTML have "run-to-completion" semantics, meaning that the browser will generally run
887   the script uninterrupted before doing anything else, such as firing further events or continuing
888   to parse the document.</p>
889
890   <p>On the other hand, parsing of HTML files happens asynchronously and incrementally, meaning that
891   the parser can pause at any point to let scripts run. This is generally a good thing, but it does
892   mean that authors need to be careful to avoid hooking event handlers after the events could have
893   possibly fired.</p>
894
895   <p>There are two techniques for doing this reliably: use <span>event handler content
896   attributes</span>, or create the element and add the event handlers in the same script. The latter
897   is safe because, as mentioned earlier, scripts are run to completion before further events can
898   fire.</p>
899
900   <div class="example">
901
902    <p>One way this could manifest itself is with <code>img</code> elements and the <code
903    title="event-load">load</code> event. The event could fire as soon as the element has been
904    parsed, especially if the image has already been cached (which is common).</p>
905
906    <p>Here, the author uses the <code title="handler-onload">onload</code> handler on an
907    <code>img</code> element to catch the <code title="event-load">load</code> event:</p>
908
909    <pre>&lt;img src="games.png" alt="Games" onload="gamesLogoHasLoaded(event)"></pre>
910
911    <p>If the element is being added by script, then so long as the event handlers are added in the
912    same script, the event will still not be missed:</p>
913
914    <pre>&lt;script>
915  var img = new Image();
916  img.src = 'games.png';
917  img.alt = 'Games';
918  img.onload = gamesLogoHasLoaded;
919  // img.addEventListener('load', gamesLogoHasLoaded, false); // would work also
920 &lt;/script></pre>
921
922    <p>However, if the author first created the <code>img</code> element and then in a separate
923    script added the event listeners, there's a chance that the <code title="event-load">load</code>
924    event would be fired in between, leading it to be missed:</p>
925
926    <pre class="bad">&lt;!-- Do not use this style, it has a race condition! -->
927  &lt;img id="games" src="games.png" alt="Games">
928  &lt;!-- the 'load' event might fire here while the parser is taking a
929       break, in which case you will not see it! -->
930  &lt;script>
931   var img = document.getElementById('games');
932   img.onload = gamesLogoHasLoaded; // might never fire!
933  &lt;/script></pre>
934
935   </div>
936
937
938
939   <h3>Conformance requirements for authors</h3>
940
941   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
942
943   <p>Unlike previous versions of the HTML specification, this specification defines in some detail
944   the required processing for invalid documents as well as valid documents.</p> <!-- This has led to
945   some questioning the purpose of conformance criteria: if there is no ambiguity in how something
946   will be processed, why disallow it? -->
947
948   <p>However, even though the processing of invalid content is in most cases well-defined,
949   conformance requirements for documents are still important: in practice, interoperability (the
950   situation in which all implementations process particular content in a reliable and identical or
951   equivalent way) is not the only goal of document conformance requirements. This section details
952   some of the more common reasons for still distinguishing between a conforming document and one
953   with errors.</p>
954
955
956   <h4>Presentational markup</h4>
957
958   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
959
960   <p>The majority of presentational features from previous versions of HTML are no longer allowed.
961   Presentational markup in general has been found to have a number of problems:</p>
962
963   <dl>
964
965    <dt>The use of presentational elements leads to poorer accessibility</dt>
966
967    <dd>
968
969     <p>While it is possible to use presentational markup in a way that provides users of assistive
970     technologies (ATs) with an acceptable experience (e.g. using ARIA), doing so is significantly
971     more difficult than doing so when using semantically-appropriate markup. Furthermore, even using
972     such techniques doesn't help make pages accessible for non-AT non-graphical users, such as users
973     of text-mode browsers.</p>
974
975     <p>Using media-independent markup, on the other hand, provides an easy way for documents to be
976     authored in such a way that they work for more users (e.g. text browsers).</p>
977
978    </dd>
979
980
981    <dt>Higher cost of maintenance</dt>
982
983    <dd>
984
985     <p>It is significantly easier to maintain a site written in such a way that the markup is
986     style-independent. For example, changing the color of a site that uses
987     <code>&lt;font&nbsp;color=""></code> throughout requires changes across the entire site, whereas
988     a similar change to a site based on CSS can be done by changing a single file.</p>
989
990    </dd>
991
992
993    <dt>Larger document sizes</dt>
994
995    <dd>
996
997     <p>Presentational markup tends to be much more redundant, and thus results in larger document
998     sizes.</p>
999
1000    </dd>
1001
1002   </dl>
1003
1004   <p>For those reasons, presentational markup has been removed from HTML in this version. This
1005   change should not come as a surprise; HTML4 deprecated presentational markup many years ago and
1006   provided a mode (HTML4 Transitional) to help authors move away from presentational markup; later,
1007   XHTML 1.1 went further and obsoleted those features altogether.</p>
1008
1009   <p>The only remaining presentational markup features in HTML are the <code
1010   title="attr-style">style</code> attribute and the <code>style</code> element. Use of the <code
1011   title="attr-style">style</code> attribute is somewhat discouraged in production environments, but
1012   it can be useful for rapid prototyping (where its rules can be directly moved into a separate
1013   style sheet later) and for providing specific styles in unusual cases where a separate style sheet
1014   would be inconvenient. Similarly, the <code>style</code> element can be useful in syndication or
1015   for page-specific styles, but in general an external style sheet is likely to be more convenient
1016   when the styles apply to multiple pages.</p>
1017
1018   <p>It is also worth noting that some elements that were previously presentational have been
1019   redefined in this specification to be media-independent: <code>b</code>, <code>i</code>,
1020   <code>hr</code>, <code>s</code>, <code>small</code>, and <code>u</code>.</p>
1021
1022
1023   <h4>Syntax errors</h4>
1024
1025   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
1026
1027   <p>The syntax of HTML is constrained to avoid a wide variety of problems.</p>
1028
1029   <dl>
1030
1031    <dt>Unintuitive error-handling behavior</dt>
1032
1033    <dd>
1034
1035     <p>Certain invalid syntax constructs, when parsed, result in DOM trees that are highly
1036     unintuitive.</p>
1037
1038     <div class="example">
1039
1040      <p>For example, the following markup fragment results in a DOM with an <code>hr</code> element
1041      that is an <em>earlier</em> sibling of the corresponding <code>table</code> element:</p>
1042
1043      <pre class="bad">&lt;table>&lt;hr>...</pre>
1044
1045     </div>
1046
1047    </dd>
1048
1049
1050    <dt>Errors with optional error recovery</dt>
1051
1052    <dd>
1053
1054     <p>To allow user agents to be used in controlled environments without having to implement the
1055     more bizarre and convoluted error handling rules, user agents are permitted to fail whenever
1056     encountering a <span>parse error</span>.</p>
1057
1058    </dd>
1059
1060
1061    <dt>Errors where the error-handling behavior is not compatible with streaming user agents</dt>
1062
1063    <dd>
1064
1065     <p>Some error-handling behavior, such as the behavior for the <code
1066     title="">&lt;table>&lt;hr>...</code> example mentioned above, are incompatible with streaming
1067     user agents (user agents that process HTML files in one pass, without storing state). To avoid
1068     interoperability problems with such user agents, any syntax resulting in such behavior is
1069     considered invalid.</p>
1070
1071    </dd>
1072
1073
1074    <dt>Errors that can result in infoset coercion</dt>
1075
1076    <dd>
1077
1078     <p>When a user agent based on XML is connected to an HTML parser, it is possible that certain
1079     invariants that XML enforces, such as comments never containing two consecutive hyphens, will be
1080     violated by an HTML file. Handling this can require that the parser coerce the HTML DOM into an
1081     XML-compatible infoset. Most syntax constructs that require such handling are considered
1082     invalid.</p>
1083
1084    </dd>
1085
1086
1087    <dt>Errors that result in disproportionally poor performance</dt>
1088
1089    <dd>
1090
1091     <p>Certain syntax constructs can result in disproportionally poor performance. To discourage the
1092     use of such constructs, they are typically made non-conforming.</p>
1093
1094     <div class="example">
1095
1096      <p>For example, the following markup results in poor performance, since all the unclosed
1097      <code>i</code> elements have to be reconstructed in each paragraph, resulting in progressively
1098      more elements in each paragraph:</p>
1099
1100      <pre class="bad">&lt;p>&lt;i>He dreamt.
1101 &lt;p>&lt;i>He dreamt that he ate breakfast.
1102 &lt;p>&lt;i>Then lunch.
1103 &lt;p>&lt;i>And finally dinner.</pre>
1104
1105      <p>The resulting DOM for this fragment would be:</p>
1106
1107      <ul class="domTree"><li class="t1"><code>p</code><ul><li class="t1"><code>i</code><ul><li class="t3"><code>#text</code>: <span title="">He dreamt.</span></li></ul></li></ul></li><li class="t1"><code>p</code><ul><li class="t1"><code>i</code><ul><li class="t1"><code>i</code><ul><li class="t3"><code>#text</code>: <span title="">He dreamt that he ate breakfast.</span></li></ul></li></ul></li></ul></li><li class="t1"><code>p</code><ul><li class="t1"><code>i</code><ul><li class="t1"><code>i</code><ul><li class="t1"><code>i</code><ul><li class="t3"><code>#text</code>: <span title="">Then lunch.</span></li></ul></li></ul></li></ul></li></ul></li><li class="t1"><code>p</code><ul><li class="t1"><code>i</code><ul><li class="t1"><code>i</code><ul><li class="t1"><code>i</code><ul><li class="t1"><code>i</code><ul><li class="t3"><code>#text</code>: <span title="">And finally dinner.</span></li></ul></li></ul></li></ul></li></ul></li></ul></li></ul>
1108
1109     </div>
1110
1111    </dd>
1112
1113
1114    <dt>Errors involving fragile syntax constructs</dt>
1115
1116    <dd>
1117
1118     <p>There are syntax constructs that, for historical reasons, are relatively fragile. To help
1119     reduce the number of users who accidentally run into such problems, they are made
1120     non-conforming.</p>
1121
1122     <div class="example">
1123
1124      <p>For example, the parsing of certain named character references in attributes happens even
1125      with the closing semicolon being omitted. It is safe to include an ampersand followed by
1126      letters that do not form a named character reference, but if the letters are changed to a
1127      string that <em>does</em> form a named character reference, they will be interpreted as that
1128      character instead.</p>
1129
1130      <p>In this fragment, the attribute's value is "<code title="">?bill&amp;ted</code>":</p>
1131
1132      <pre class="bad">&lt;a href="?bill&amp;ted">Bill and Ted&lt;/a></pre>
1133
1134      <p>In the following fragment, however, the attribute's value is actually "<code
1135      title="">?art&copy;</code>", <em>not</em> the intended "<code title="">?art&amp;copy</code>",
1136      because even without the final semicolon, "<code title="">&amp;copy</code>" is handled the same
1137      as "<code title="">&amp;copy;</code>" and thus gets interpreted as "<code
1138      title="">&copy;</code>":</p>
1139
1140      <pre class="bad">&lt;a href="?art&amp;copy">Art and Copy&lt;/a></pre>
1141
1142      <p>To avoid this problem, all named character references are required to end with a semicolon,
1143      and uses of named character references without a semicolon are flagged as errors.</p>
1144
1145      <p>Thus, the correct way to express the above cases is as
1146      follows:</p>
1147
1148      <pre>&lt;a href="?bill&amp;ted">Bill and Ted&lt;/a> &lt;!-- &amp;ted is ok, since it's not a named character reference --></pre>
1149      <pre>&lt;a href="?art&amp;amp;copy">Art and Copy&lt;/a> &lt;!-- the &amp; has to be escaped, since &amp;copy <em>is</em> a named character reference --></pre>
1150
1151     </div>
1152
1153    </dd>
1154
1155
1156    <dt>Errors involving known interoperability problems in legacy user agents</dt>
1157
1158    <dd>
1159
1160     <p>Certain syntax constructs are known to cause especially subtle or serious problems in legacy
1161     user agents, and are therefore marked as non-conforming to help authors avoid them.</p>
1162
1163     <div class="example">
1164
1165      <p>For example, this is why the U+0060 GRAVE ACCENT character (`) is not allowed in unquoted
1166      attributes. In certain legacy user agents, <!-- namely IE --> it is sometimes treated as a
1167      quote character.</p>
1168
1169     </div>
1170
1171     <div class="example">
1172
1173      <p>Another example of this is the DOCTYPE, which is required to trigger <span>no-quirks
1174      mode</span>, because the behavior of legacy user agents in <span>quirks mode</span> is often
1175      largely undocumented.</p>
1176
1177     </div>
1178
1179    </dd>
1180
1181
1182 <!--ADD-TOPIC:Security-->
1183    <dt>Errors that risk exposing authors to security attacks</dt>
1184
1185    <dd>
1186
1187     <p>Certain restrictions exist purely to avoid known security problems.</p>
1188
1189     <div class="example">
1190
1191      <p>For example, the restriction on using UTF-7 exists purely to avoid authors falling prey to a
1192      known cross-site-scripting attack using UTF-7.</p>
1193
1194     </div>
1195
1196    </dd>
1197 <!--REMOVE-TOPIC:Security-->
1198
1199
1200    <dt>Cases where the author's intent is unclear</dt>
1201
1202    <dd>
1203
1204     <p>Markup where the author's intent is very unclear is often made non-conforming. Correcting
1205     these errors early makes later maintenance easier.</p>
1206
1207     <div class="example">
1208
1209      <p>For example, it is unclear whether the author intended the following to be an
1210      <code>h1</code> heading or an <code>h2</code> heading:</p>
1211
1212      <pre class="bad">&lt;h1>Contact details&lt;/h2></pre>
1213
1214     </div>
1215
1216    </dd>
1217
1218
1219    <dt>Cases that are likely to be typos</dt>
1220
1221    <dd>
1222
1223     <p>When a user makes a simple typo, it is helpful if the error can be caught early, as this can
1224     save the author a lot of debugging time. This specification therefore usually considers it an
1225     error to use element names, attribute names, and so forth, that do not match the names defined
1226     in this specification.</p>
1227
1228     <div class="example">
1229
1230      <p>For example, if the author typed <code>&lt;capton></code> instead of
1231      <code>&lt;caption></code>, this would be flagged as an error and the author could correct the
1232      typo immediately.</p>
1233
1234     </div>
1235
1236    </dd>
1237
1238
1239    <dt>Errors that could interfere with new syntax in the future</dt>
1240
1241    <dd>
1242
1243     <p>In order to allow the language syntax to be extended in the future, certain otherwise
1244     harmless features are disallowed.</p>
1245
1246     <div class="example">
1247
1248      <p>For example, "attributes" in end tags are ignored currently, but they are invalid, in case a
1249      future change to the language makes use of that syntax feature without conflicting with
1250      already-deployed (and valid!) content.</p>
1251
1252     </div>
1253
1254    </dd>
1255
1256
1257   </dl>
1258
1259   <p>Some authors find it helpful to be in the practice of always quoting all attributes and always
1260   including all optional tags, preferring the consistency derived from such custom over the minor
1261   benefits of terseness afforded by making use of the flexibility of the HTML syntax. To aid such
1262   authors, conformance checkers can provide modes of operation wherein such conventions are
1263   enforced.</p>
1264
1265
1266
1267   <h4>Restrictions on content models and on attribute values</h4>
1268
1269   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
1270
1271   <p>Beyond the syntax of the language, this specification also places restrictions on how elements
1272   and attributes can be specified. These restrictions are present for similar reasons:</p>
1273
1274   <dl>
1275
1276
1277    <dt>Errors involving content with dubious semantics</dt>
1278
1279    <dd>
1280
1281     <p>To avoid misuse of elements with defined meanings, content models are defined that restrict
1282     how elements can be nested when such nestings would be of dubious value.</p>
1283
1284     <p class="example">For example, this specification disallows nesting a <code>section</code>
1285     element inside a <code>kbd</code> element, since it is highly unlikely for an author to indicate
1286     that an entire section should be keyed in.</p>
1287
1288    </dd>
1289
1290
1291    <dt>Errors that involve a conflict in expressed semantics</dt>
1292
1293    <dd>
1294
1295     <p>Similarly, to draw the author's attention to mistakes in the use of elements, clear
1296     contradictions in the semantics expressed are also considered conformance errors.</p>
1297
1298     <div class="example">
1299
1300      <p>In the fragments below, for example, the semantics are nonsensical: a separator cannot
1301      simultaneously be a cell, nor can a radio button be a progress bar.</p>
1302
1303      <pre class="bad">&lt;hr role="cell"></pre>
1304      <pre class="bad">&lt;input type=radio role=progressbar></pre>
1305
1306     </div>
1307
1308     <p class="example">Another example is the restrictions on the content models of the
1309     <code>ul</code> element, which only allows <code>li</code> element children. Lists by definition
1310     consist just of zero or more list items, so if a <code>ul</code> element contains something
1311     other than an <code>li</code> element, it's not clear what was meant.</p>
1312
1313    </dd>
1314
1315
1316    <dt>Cases where the default styles are likely to lead to confusion</dt>
1317
1318    <dd>
1319
1320     <p>Certain elements have default styles or behaviors that make certain combinations likely to
1321     lead to confusion. Where these have equivalent alternatives without this problem, the confusing
1322     combinations are disallowed.</p>
1323
1324     <p class="example">For example, <code>div</code> elements are rendered as block boxes, and
1325     <code>span</code> elements as inline boxes. Putting a block box in an inline box is
1326     unnecessarily confusing; since either nesting just <code>div</code> elements, or nesting just
1327     <code>span</code> elements, or nesting <code>span</code> elements inside <code>div</code>
1328     elements all serve the same purpose as nesting a <code>div</code> element in a <code>span</code>
1329     element, but only the latter involves a block box in an inline box, the latter combination is
1330     disallowed.</p>
1331
1332     <p class="example">Another example would be the way <span>interactive content</span> cannot be
1333     nested. For example, a <code>button</code> element cannot contain a <code>textarea</code>
1334     element. This is because the default behavior of such nesting interactive elements would be
1335     highly confusing to users. Instead of nesting these elements, they can be placed side by
1336     side.</p>
1337
1338    </dd>
1339
1340
1341    <dt>Errors that indicate a likely misunderstanding of the specification</dt>
1342
1343    <dd>
1344
1345     <p>Sometimes, something is disallowed because allowing it would likely cause author
1346     confusion.</p>
1347
1348     <p class="example">For example, setting the <code title="attr-fe-disabled">disabled</code>
1349     attribute to the value "<code title="">false</code>" is disallowed, because despite the
1350     appearance of meaning that the element is enabled, it in fact means that the element is
1351     <em>disabled</em> (what matters for implementations is the presence of the attribute, not its
1352     value).</p>
1353
1354    </dd>
1355
1356
1357    <dt>Errors involving limits that have been imposed merely to simplify the language</dt>
1358
1359    <dd>
1360
1361     <p>Some conformance errors simplify the language that authors need to learn.</p>
1362
1363     <p class="example">For example, the <code>area</code> element's <code
1364     title="attr-area-shape">shape</code> attribute, despite accepting both <code
1365     title="attr-area-shape-keyword-circ">circ</code> and <code
1366     title="attr-area-shape-keyword-circle">circle</code> values in practice as synonyms, disallows
1367     the use of the <code title="attr-area-shape-keyword-circ">circ</code> value, so as to simplify
1368     tutorials and other learning aids. There would be no benefit to allowing both, but it would
1369     cause extra confusion when teaching the language.</p>
1370
1371    </dd>
1372
1373
1374    <dt>Errors that involve peculiarities of the parser</dt>
1375
1376    <dd>
1377
1378     <p>Certain elements are parsed in somewhat eccentric ways (typically for historical reasons),
1379     and their content model restrictions are intended to avoid exposing the author to these
1380     issues.</p>
1381
1382     <div class="example">
1383
1384      <p>For example, a <code>form</code> element isn't allowed inside <span>phrasing content</span>,
1385      because when parsed as HTML, a <code>form</code> element's start tag will imply a
1386      <code>p</code> element's end tag. Thus, the following markup results in two <span
1387      title="paragraph">paragraphs</span>, not one:</p>
1388
1389      <pre>&lt;p>Welcome. &lt;form>&lt;label>Name:&lt;/label> &lt;input>&lt;/form></pre>
1390
1391      <p>It is parsed exactly like the following:</p>
1392
1393      <pre>&lt;p>Welcome. &lt;/p>&lt;form>&lt;label>Name:&lt;/label> &lt;input>&lt;/form></pre>
1394
1395     </div>
1396
1397    </dd>
1398
1399
1400    <dt>Errors that would likely result in scripts failing in hard-to-debug ways</dt>
1401
1402    <dd>
1403
1404     <p>Some errors are intended to help prevent script problems that would be hard to debug.</p>
1405
1406     <p class="example">This is why, for instance, it is non-conforming to have two <code
1407     title="attr-id">id</code> attributes with the same value. Duplicate IDs lead to the wrong
1408     element being selected, with sometimes disastrous effects whose cause is hard to determine.</p>
1409
1410    </dd>
1411
1412
1413    <dt>Errors that waste authoring time</dt>
1414
1415    <dd>
1416
1417     <p>Some constructs are disallowed because historically they have been the cause of a lot of
1418     wasted authoring time, and by encouraging authors to avoid making them, authors can save time in
1419     future efforts.</p>
1420
1421     <p class="example">For example, a <code>script</code> element's <code
1422     title="attr-script-src">src</code> attribute causes the element's contents to be ignored.
1423     However, this isn't obvious, especially if the element's contents appear to be executable script
1424     &mdash; which can lead to authors spending a lot of time trying to debug the inline script
1425     without realizing that it is not executing. To reduce this problem, this specification makes it
1426     non-conforming to have executable script in a <code>script</code> element when the <code
1427     title="attr-script-src">src</code> attribute is present. This means that authors who are
1428     validating their documents are less likely to waste time with this kind of mistake.</p>
1429
1430    </dd>
1431
1432
1433    <dt>Errors that involve areas that affect authors migrating to and from XHTML</dt>
1434
1435    <dd>
1436
1437     <p>Some authors like to write files that can be interpreted as both XML and HTML with similar
1438     results. Though this practice is discouraged in general due to the myriad of subtle
1439     complications involved (especially when involving scripting, styling, or any kind of automated
1440     serialization), this specification has a few restrictions intended to at least somewhat mitigate
1441     the difficulties. This makes it easier for authors to use this as a transitionary step when
1442     migrating between HTML and XHTML.</p>
1443
1444     <p class="example">For example, there are somewhat complicated rules surrounding the <code
1445     title="attr-lang">lang</code> and <code title="attr-xml-lang">xml:lang</code> attributes
1446     intended to keep the two synchronized.</p>
1447
1448     <p class="example">Another example would be the restrictions on the values of <code
1449     title="">xmlns</code> attributes in the HTML serialization, which are intended to ensure that
1450     elements in conforming documents end up in the same namespaces whether processed as HTML or
1451     XML.</p>
1452
1453    </dd>
1454
1455
1456    <dt>Errors that involve areas reserved for future expansion</dt>
1457
1458    <dd>
1459
1460     <p>As with the restrictions on the syntax intended to allow for new syntax in future revisions
1461     of the language, some restrictions on the content models of elements and values of attributes
1462     are intended to allow for future expansion of the HTML vocabulary.</p>
1463
1464     <p class="example">For example, limiting the values of the <code
1465     title="attr-hyperlink-target">target</code> attribute that start with an U+005F LOW LINE
1466     character (_) to only specific predefined values allows new predefined values to be introduced
1467     at a future time without conflicting with author-defined values.</p>
1468
1469    </dd>
1470
1471
1472    <dt>Errors that indicate a mis-use of other specifications</dt>
1473
1474    <dd>
1475
1476     <p>Certain restrictions are intended to support the restrictions made by other
1477     specifications.</p>
1478
1479     <p class="example">For example, requiring that attributes that take media queries use only
1480     <em>valid</em> media queries reinforces the importance of following the conformance rules of
1481     that specification.</p>
1482
1483    </dd>
1484
1485   </dl>
1486
1487
1488
1489   <h3>Suggested reading</h3>
1490
1491   <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
1492
1493   <p>The following documents might be of interest to readers of this specification.</p>
1494
1495   <dl>
1496
1497    <dt><cite>Character Model for the World Wide Web 1.0: Fundamentals</cite> <a href="#refsCHARMOD">[CHARMOD]</a></dt>
1498
1499    <dd><blockquote><p>This Architectural Specification provides authors of specifications, software
1500    developers, and content developers with a common reference for interoperable text manipulation on
1501    the World Wide Web, building on the Universal Character Set, defined jointly by the Unicode
1502    Standard and ISO/IEC 10646. Topics addressed include use of the terms 'character', 'encoding' and
1503    'string', a reference processing model, choice and identification of character encodings,
1504    character escaping, and string indexing.</p></blockquote></dd>
1505
1506    <dt><cite>Unicode Security Considerations</cite> <a href="#refsUTR36">[UTR36]</a></dt>
1507
1508    <dd><blockquote><p>Because Unicode contains such a large number of characters and incorporates
1509    the varied writing systems of the world, incorrect usage can expose programs or systems to
1510    possible security attacks. This is especially important as more and more products are
1511    internationalized. This document describes some of the security considerations that programmers,
1512    system analysts, standards developers, and users should take into account, and provides specific
1513    recommendations to reduce the risk of problems.</p></blockquote></dd>
1514
1515    <dt><cite>Web Content Accessibility Guidelines (WCAG) 2.0</cite> <a href="#refsWCAG">[WCAG]</a></dt>
1516
1517    <dd><blockquote><p>Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of
1518    recommendations for making Web content more accessible. Following these guidelines will make
1519    content accessible to a wider range of people with disabilities, including blindness and low
1520    vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited
1521    movement, speech disabilities, photosensitivity and combinations of these. Following these
1522    guidelines will also often make your Web content more usable to users in
1523    general.</p></blockquote></dd>
1524
1525    <dt class="impl"><cite>Authoring Tool Accessibility Guidelines (ATAG) 2.0</cite> <a href="#refsATAG">[ATAG]</a></dt>
1526
1527    <dd class="impl"><blockquote><p>This specification provides guidelines for designing Web content
1528    authoring tools that are more accessible for people with disabilities. An authoring tool that
1529    conforms to these guidelines will promote accessibility by providing an accessible user interface
1530    to authors with disabilities as well as by enabling, supporting, and promoting the production of
1531    accessible Web content by all authors.</p></blockquote></dd>
1532
1533    <dt class="impl"><cite>User Agent Accessibility Guidelines (UAAG) 2.0</cite> <a href="#refsUAAG">[UAAG]</a></dt>
1534
1535    <dd class="impl"><blockquote><p>This document provides guidelines for designing user agents that
1536    lower barriers to Web accessibility for people with disabilities. User agents include browsers
1537    and other types of software that retrieve and render Web content. A user agent that conforms to
1538    these guidelines will promote accessibility through its own user interface and through other
1539    internal facilities, including its ability to communicate with other technologies (especially
1540    assistive technologies). Furthermore, all users, not just users with disabilities, should find
1541    conforming user agents to be more usable.</p></blockquote></dd>
1542
1543   </dl>
1544
1545
1546
1547   <h2 id="infrastructure">Common infrastructure</h2>
1548
1549   <h3>Terminology</h3>
1550
1551   <p>This specification refers to both HTML and XML attributes and IDL attributes, often in the same
1552   context. When it is not clear which is being referred to, they are referred to as <dfn
1553   title="">content attributes</dfn> for HTML and XML attributes, and <dfn title="">IDL
1554   attributes</dfn> for those defined on IDL interfaces. Similarly, the term "properties" is used for
1555   both JavaScript object properties and CSS properties. When these are ambiguous they are qualified
1556   as <dfn title="">object properties</dfn> and <dfn title="">CSS properties</dfn> respectively.</p>
1557
1558   <p>Generally, when the specification states that a feature applies to <span>the HTML syntax</span>
1559   or <span>the XHTML syntax</span>, it also includes the other. When a feature specifically only
1560   applies to one of the two languages, it is called out by explicitly stating that it does not apply
1561   to the other format, as in "for HTML, ... (this does not apply to XHTML)".</p>
1562
1563   <p>This specification uses the term <dfn title="">document</dfn> to refer to any use of HTML,
1564   ranging from short static documents to long essays or reports with rich multimedia, as well as to
1565   fully-fledged interactive applications. The term is used to refer both to <code>Document</code>
1566   objects and their descendant DOM trees, and to serialized byte streams using the <span title="the
1567   HTML syntax">HTML syntax</span> or <span title="the XHTML syntax">XHTML syntax</span>, depending
1568   on context.</p>
1569
1570   <p>In the context of the DOM structures, the terms <span title="HTML documents">HTML
1571   document</span> and <span title="XML documents">XML document</span> are used as defined in the DOM
1572   specification, and refer specifically to two different modes that <code>Document</code> objects
1573   can find themselves in. <a href="#refsDOM">[DOM]</a> (Such uses are always hyperlinked to their
1574   definition.)</p>
1575
1576   <p>In the context of byte streams, the term HTML document refers to resources labeled as
1577   <code>text/html</code>, and the term XML document refers to resources labeled with an <span>XML
1578   MIME type</span>.</p>
1579
1580   <p>The term <dfn>XHTML document</dfn> is used to refer to both <code>Document</code>s in the <span
1581   title="XML documents">XML document</span> mode that contains element nodes in the <span>HTML
1582   namespace</span>, and byte streams labeled with an <span>XML MIME type</span> that contain
1583   elements from the <span>HTML namespace</span>, depending on context.</p>
1584
1585   <hr>
1586
1587   <p>For simplicity, terms such as <dfn title="">shown</dfn>, <dfn title="">displayed</dfn>, and
1588   <dfn title="">visible</dfn> might sometimes be used when referring to the way a document is
1589   rendered to the user. These terms are not meant to imply a visual medium; they must be considered
1590   to apply to other media in equivalent ways.</p>
1591
1592   <div class="impl">
1593
1594   <p>When an algorithm B says to return to another algorithm A, it implies that A called B. Upon
1595   returning to A, the implementation must continue from where it left off in calling B.</p>
1596
1597   </div>
1598
1599   <!-- should find somewhere more appropriate to put this -->
1600   <p>The term "transparent black" refers to the color with red, green, blue, and alpha channels all
1601   set to zero.</p>
1602
1603
1604   <h4>Resources</h4>
1605
1606   <p>The specification uses the term <dfn title="">supported</dfn> when referring to whether a user
1607   agent has an implementation capable of decoding the semantics of an external resource. A format or
1608   type is said to be <i>supported</i> if the implementation can process an external resource of that
1609   format or type without critical aspects of the resource being ignored. Whether a specific resource
1610   is <i>supported</i> can depend on what features of the resource's format are in use.</p>
1611
1612   <p class="example">For example, a PNG image would be considered to be in a supported format if its
1613   pixel data could be decoded and rendered, even if, unbeknownst to the implementation, the image
1614   also contained animation data.</p>
1615
1616   <p class="example">An MPEG-4 video file would not be considered to be in a supported format if the
1617   compression format used was not supported, even if the implementation could determine the
1618   dimensions of the movie from the file's metadata.</p>
1619
1620   <p>What some specifications, in particular the HTTP specification, refer to as a
1621   <i>representation</i> is referred to in this specification as a <dfn title="">resource</dfn>. <a
1622   href="#refsHTTP">[HTTP]</a></p>
1623
1624   <p>The term <dfn>MIME type</dfn> is used to refer to what is sometimes called an <i>Internet media
1625   type</i> in protocol literature. The term <i>media type</i> in this specification is used to refer
1626   to the type of media intended for presentation, as used by the CSS specifications. <a
1627   href="#refsRFC2046">[RFC2046]</a> <a href="#refsMQ">[MQ]</a></p>
1628
1629   <p>A string is a <dfn>valid MIME type</dfn> if it matches the <code title="">media-type</code>
1630   rule defined in section 3.7 "Media Types" of RFC 2616. In particular, a <span>valid MIME
1631   type</span> may include MIME type parameters. <a href="#refsHTTP">[HTTP]</a></p>
1632
1633   <p>A string is a <dfn>valid MIME type with no parameters</dfn> if it matches the <code
1634   title="">media-type</code> rule defined in section 3.7 "Media Types" of RFC 2616, but does not
1635   contain any U+003B SEMICOLON characters (;). In other words, if it consists only of a type and
1636   subtype, with no MIME Type parameters. <a href="#refsHTTP">[HTTP]</a></p>
1637
1638   <p>The term <dfn>HTML MIME type</dfn> is used to refer to the <span>MIME type</span>
1639   <code>text/html</code>.</p>
1640
1641   <p>A resource's <dfn>critical subresources</dfn> are those that the resource needs to have
1642   available to be correctly processed. Which resources are considered critical or not is defined by
1643   the specification that defines the resource's format.</p>
1644
1645   <p>The term <dfn title="data protocol"><code title="">data:</code> URL</dfn> refers to <span
1646   title="URL">URLs</span> that use the <code title="">data:</code> scheme. <a
1647   href="#refsRFC2397">[RFC2397]</a></p>
1648
1649
1650   <h4>XML</h4>
1651
1652   <p id="html-namespace">To ease migration from HTML to XHTML, UAs conforming to this specification
1653   will place elements in HTML in the <code>http://www.w3.org/1999/xhtml</code> namespace, at least
1654   for the purposes of the DOM and CSS. The term "<dfn>HTML elements</dfn>", when used in this
1655   specification, refers to any element in that namespace, and thus refers to both HTML and XHTML
1656   elements.</p>
1657
1658   <p>Except where otherwise stated, all elements defined or mentioned in this specification are in
1659   the <span>HTML namespace</span> ("<code>http://www.w3.org/1999/xhtml</code>"), and all attributes
1660   defined or mentioned in this specification have no namespace.</p>
1661
1662   <p>The term <dfn>element type</dfn> is used to refer to the set of elements that have a given
1663   local name and namespace. For example, <code>button</code> elements are elements with the element
1664   type <code>button</code>, meaning they have the local name "<code title="">button</code>" and
1665   (implicitly as defined above) the <span>HTML namespace</span>.</p>
1666
1667   <p>Attribute names are said to be <dfn>XML-compatible</dfn> if they match the <a
1668   href="http://www.w3.org/TR/REC-xml/#NT-Name"><code title="">Name</code></a> production defined in
1669   XML, they contain no U+003A COLON characters (:), and their first three characters are not an
1670   <span>ASCII case-insensitive</span> match for the string "<code title="">xml</code>". <a
1671   href="#refsXML">[XML]</a></p>
1672
1673   <p>The term <dfn>XML MIME type</dfn> is used to refer to the <span title="MIME type">MIME
1674   types</span> <code title="">text/xml</code>, <code title="">application/xml</code>, and any
1675   <span>MIME type</span> whose subtype ends with the four characters "<code title="">+xml</code>".
1676   <a href="#refsRFC3023">[RFC3023]</a></p>
1677
1678
1679   <h4>DOM trees</h4>
1680
1681   <p>The <dfn>root element of a <code>Document</code> object</dfn> is that <code>Document</code>'s
1682   first element child, if any. If it does not have one then the <code>Document</code> has no root
1683   element.</p>
1684
1685   <p>The term <dfn>root element</dfn>, when not referring to a <code>Document</code> object's root
1686   element, means the furthest ancestor element node of whatever node is being discussed, or the node
1687   itself if it has no ancestors. When the node is a part of the document, then the node's <span>root
1688   element</span> is indeed the document's root element; however, if the node is not currently part
1689   of the document tree, the root element will be an orphaned node.</p>
1690
1691   <p>When an element's <span>root element</span> is the <span>root element of a
1692   <code>Document</code> object</span>, it is said to be <dfn>in a <code>Document</code></dfn>. An
1693   element is said to have been <dfn title="insert an element into a document">inserted into a
1694   document</dfn> when its <span>root element</span> changes and is now the document's <span>root
1695   element</span>. Analogously, an element is said to have been <dfn title="remove an element from a
1696   document">removed from a document</dfn> when its <span>root element</span> changes from being the
1697   document's <span>root element</span> to being another element.</p>
1698
1699   <p>A node's <dfn>home subtree</dfn> is the subtree rooted at that node's <span>root
1700   element</span>. When a node is <span>in a <code>Document</code></span>, its <span>home
1701   subtree</span> is that <code>Document</code>'s tree.</p>
1702
1703   <p>The <code>Document</code> of a <code>Node</code> (such as an element) is the
1704   <code>Document</code> that the <code>Node</code>'s <code
1705   title="dom-Node-ownerDocument">ownerDocument</code> IDL attribute returns. When a
1706   <code>Node</code> is <span>in a <code>Document</code></span> then that <code>Document</code> is
1707   always the <code>Node</code>'s <code>Document</code>, and the <code>Node</code>'s <code
1708   title="dom-Node-ownerDocument">ownerDocument</code> IDL attribute thus always returns that
1709   <code>Document</code>.</p>
1710
1711   <p>The <code>Document</code> of a content attribute is the <code>Document</code> of the
1712   attribute's element.</p>
1713
1714   <p>The term <dfn>tree order</dfn> means a pre-order, depth-first traversal of DOM nodes involved
1715   (through the <code title="dom-Node-parentNode">parentNode</code>/<code
1716   title="dom-Node-childNodes">childNodes</code> relationship).</p>
1717
1718   <p>When it is stated that some element or attribute is <dfn title="ignore">ignored</dfn>, or
1719   treated as some other value, or handled as if it was something else, this refers only to the
1720   processing of the node after it is in the DOM. <span class="impl">A user agent must not mutate the
1721   DOM in such situations.</span></p>
1722
1723   <p>A content attribute is said to <dfn title="">change</dfn> value only if its new value is
1724   different than its previous value; setting an attribute to a value it already has does not change
1725   it.</p>
1726
1727   <p>The term <dfn title="">empty</dfn>, when used of an attribute value, <code>Text</code> node, or
1728   string, means that the length of the text is zero (i.e. not even containing spaces or control
1729   characters).</p>
1730
1731
1732   <h4>Scripting</h4>
1733
1734   <p>The construction "a <code>Foo</code> object", where <code>Foo</code> is actually an interface,
1735   is sometimes used instead of the more accurate "an object implementing the interface
1736   <code>Foo</code>".</p>
1737
1738   <p>An IDL attribute is said to be <dfn title="">getting</dfn> when its value is being retrieved
1739   (e.g. by author script), and is said to be <dfn title="">setting</dfn> when a new value is
1740   assigned to it.</p>
1741
1742   <p>If a DOM object is said to be <dfn>live</dfn>, then the attributes and methods on that object
1743   <span class="impl">must</span> operate on the actual underlying data, not a snapshot of the
1744   data.</p>
1745
1746   <p>In the contexts of events, the terms <i>fire</i> and <i>dispatch</i> are used as defined in the
1747   DOM specification: <dfn title="concept-event-fire">firing</dfn> an event means to create and <span
1748   title="concept-event-dispatch">dispatch</span> it, and <dfn
1749   title="concept-event-dispatch">dispatching</dfn> an event means to follow the steps that propagate
1750   the event through the tree. The term <dfn title="concept-events-trusted">trusted event</dfn> is
1751   used to refer to events whose <code title="dom-event-isTrusted">isTrusted</code> attribute is
1752   initialized to true. <a href="#refsDOM">[DOM]</a></p>
1753
1754
1755   <h4>Plugins</h4>
1756
1757   <p>The term <dfn>plugin</dfn> refers to a user-agent defined set of content handlers used by the
1758   user agent that can take part in the user agent's rendering of a <code>Document</code> object, but
1759   that neither act as <span title="child browsing context">child browsing contexts</span> of the
1760   <code>Document</code> nor introduce any <code>Node</code> objects to the <code>Document</code>'s
1761   DOM.</p>
1762
1763   <p>Typically such content handlers are provided by third parties, though a user agent can also
1764   designate built-in content handlers as plugins.</p>
1765
1766   <div class="impl">
1767
1768   <p>A user agent must not consider the types <code>text/plain</code> and
1769   <code>application/octet-stream</code> as having a registered <span>plugin</span>.</p> <!-- because
1770   of the way <object> handles those types, if nothing else (it also doesn't make any sense to have a
1771   plugin registered for those types, of course) -->
1772
1773   </div>
1774
1775   <p class="example">One example of a plugin would be a PDF viewer that is instantiated in a
1776   <span>browsing context</span> when the user navigates to a PDF file. This would count as a plugin
1777   regardless of whether the party that implemented the PDF viewer component was the same as that
1778   which implemented the user agent itself. However, a PDF viewer application that launches separate
1779   from the user agent (as opposed to using the same interface) is not a plugin by this
1780   definition.</p>
1781
1782   <p class="note">This specification does not define a mechanism for interacting with plugins, as it
1783   is expected to be user-agent- and platform-specific. Some UAs might opt to support a plugin
1784   mechanism such as the Netscape Plugin API; others might use remote content converters or have
1785   built-in support for certain types. Indeed, this specification doesn't require user agents to
1786   support plugins at all. <a href="#refsNPAPI">[NPAPI]</a></p>
1787
1788   <p>A plugin can be <dfn title="concept-plugin-secure">secured</dfn> if it honors the semantics of
1789   the <code title="attr-iframe-sandbox">sandbox</code> attribute.</p>
1790
1791   <p class="example">For example, a secured plugin would prevent its contents from creating pop-up
1792   windows when the plugin is instantiated inside a sandboxed <code>iframe</code>.</p>
1793
1794   <div class="impl">
1795
1796   <p class="warning">Browsers should take extreme care when interacting with external content
1797   intended for <span title="plugin">plugins</span>. When third-party software is run with the same
1798   privileges as the user agent itself, vulnerabilities in the third-party software become as
1799   dangerous as those in the user agent.</p>
1800
1801   </div>
1802
1803
1804
1805   <h4 id="encoding-terminology">Character encodings</h4>
1806
1807   <p>A <dfn title="encoding">character encoding</dfn>, or just <i>encoding</i> where that is not
1808   ambiguous, is a defined way to convert between byte streams and Unicode strings, as defined in the
1809   WHATWG Encoding standard. An <span>encoding</span> has an <dfn>encoding name</dfn> and one or more
1810   <dfn title="encoding label">encoding labels</dfn>, referred to as the encoding's <i>name</i> and
1811   <i>labels</i> in the Encoding specification. <a
1812   href="#refsENCODING">[ENCODING]</a></p>
1813
1814   <p>An <dfn>ASCII-compatible character encoding</dfn> is a single-byte or variable-length
1815   <span>encoding</span> in which the bytes 0x09, 0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C -
1816   0x3F, 0x41 - 0x5A, and 0x61 - 0x7A<!-- is that list ok? do any character sets we want to support
1817   do things outside that range? -->, ignoring bytes that are the second and later bytes of multibyte
1818   sequences, all correspond to single-byte sequences that map to the same Unicode characters as
1819   those bytes in ANSI_X3.4-1968 (US-ASCII). <a href="#refsRFC1345">[RFC1345]</a></p>
1820
1821   <p class="note">This includes such encodings as Shift_JIS, HZ-GB-2312, and variants of ISO-2022,
1822   even though it is possible in these encodings for bytes like 0x70 to be part of longer sequences
1823   that are unrelated to their interpretation as ASCII. It excludes UTF-16 variants, as well as
1824   obsolete legacy encodings such as UTF-7, GSM03.38, and EBCDIC variants.</p>
1825
1826   <!--
1827    We'll have to change that if anyone comes up with a way to have a document that is valid as two
1828    different encodings at once, with different <meta charset> elements applying in each case.
1829   -->
1830
1831   <p>The term <dfn>a UTF-16 encoding</dfn> refers to any variant of UTF-16: self-describing UTF-16
1832   with a BOM, ambiguous UTF-16 without a BOM, raw UTF-16LE, and raw UTF-16BE. <a
1833   href="#refsRFC2781">[RFC2781]</a></p>
1834
1835   <p>The term <dfn>code unit</dfn> is used as defined in the Web IDL specification: a 16 bit
1836   unsigned integer, the smallest atomic component of a <code>DOMString</code>. (This is a narrower
1837   definition than the one used in Unicode, and is not the same as a <i>code point</i>.) <a
1838   href="#refsWEBIDL">[WEBIDL]</a></p>
1839
1840   <p>The term <dfn>Unicode code point</dfn> means a <i title="">Unicode scalar value</i> where
1841   possible, and an isolated surrogate code point when not. When a conformance requirement is defined
1842   in terms of characters or Unicode code points, a pair of <span title="code unit">code units</span>
1843   consisting of a high surrogate followed by a low surrogate must be treated as the single code
1844   point represented by the surrogate pair, but isolated surrogates must each be treated as the
1845   single code point with the value of the surrogate. <a href="#refsUNICODE">[UNICODE]</a></p>
1846
1847   <p>In this specification, the term <dfn>character</dfn>, when not qualified as <em>Unicode</em>
1848   character, is synonymous with the term <span>Unicode code point</span>.</p>
1849
1850   <p>The term <dfn>Unicode character</dfn> is used to mean a <i title="">Unicode scalar value</i>
1851   (i.e. any Unicode code point that is not a surrogate code point). <a
1852   href="#refsUNICODE">[UNICODE]</a></p>
1853
1854   <p>The <dfn>code-unit length</dfn> of a string is the number of <span title="code unit">code
1855   units</span> in that string.</p>
1856
1857   <p class="note">This complexity results from the historical decision to define the DOM API in
1858   terms of 16 bit (UTF-16) <span title="code unit">code units</span>, rather than in terms of <span
1859   title="Unicode character">Unicode characters</span>.</p>
1860
1861
1862
1863 <!--END dev-html-->
1864
1865   <h3>Conformance requirements</h3>
1866
1867   <p>All diagrams, examples, and notes in this specification are non-normative, as are all sections
1868   explicitly marked non-normative. Everything else in this specification is normative.</p>
1869
1870   <p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL NOT",--> "SHOULD", "SHOULD
1871   NOT", <!--"RECOMMENDED", "NOT RECOMMENDED",--> "MAY", and "OPTIONAL" in the normative parts of
1872   this document are to be interpreted as described in RFC2119. The key word "OPTIONALLY" in the
1873   normative parts of this document is to be interpreted with the same normative meaning as "MAY" and
1874   "OPTIONAL". For readability, these words do not appear in all uppercase letters in this
1875   specification. <a href="#refsRFC2119">[RFC2119]</a></p>
1876
1877   <div class="impl">
1878
1879   <p>Requirements phrased in the imperative as part of algorithms (such as "strip any leading space
1880   characters" or "return false and abort these steps") are to be interpreted with the meaning of the
1881   key word ("must", "should", "may", etc) used in introducing the algorithm.</p>
1882
1883   <div class="example">
1884
1885    <p>For example, were the spec to say:</p>
1886
1887    <pre>To eat an orange, the user must:
1888 1. Peel the orange.
1889 2. Separate each slice of the orange.
1890 3. Eat the orange slices.</pre>
1891
1892    <p>...it would be equivalent to the following:</p>
1893
1894    <pre>To eat an orange:
1895 1. The user must peel the orange.
1896 2. The user must separate each slice of the orange.
1897 3. The user must eat the orange slices.</pre>
1898
1899    <p>Here the key word is "must".</p>
1900
1901    <p>The former (imperative) style is generally preferred in this specification for stylistic
1902    reasons.</p>
1903
1904   </div>
1905
1906   <p>Conformance requirements phrased as algorithms or specific steps may be implemented in any
1907   manner, so long as the end result is equivalent. (In particular, the algorithms defined in this
1908   specification are intended to be easy to follow, and not intended to be performant.)</p>
1909
1910   </div>
1911
1912
1913
1914   <div class="impl">
1915
1916   <h4>Conformance classes</h4>
1917
1918   <p>This specification describes the conformance criteria for <span class="impl">user agents
1919   (relevant to implementors) and</span> documents<span class="impl"> (relevant to authors and
1920   authoring tool implementors)</span>.</p>
1921
1922   <p><dfn>Conforming documents</dfn> are those that comply with all the conformance criteria for
1923   documents. For readability, some of these conformance requirements are phrased as conformance
1924   requirements on authors; such requirements are implicitly requirements on documents: by
1925   definition, all documents are assumed to have had an author. (In some cases, that author may
1926   itself be a user agent &mdash; such user agents are subject to additional rules, as explained
1927   below.)</p>
1928
1929   <p class="example">For example, if a requirement states that "authors must not use the <code
1930   title="">foobar</code> element", it would imply that documents are not allowed to contain elements
1931   named <code title="">foobar</code>.</p>
1932
1933   <p class="note impl">There is no implied relationship between document conformance requirements
1934   and implementation conformance requirements. User agents are not free to handle non-conformant
1935   documents as they please; the processing model described in this specification applies to
1936   implementations regardless of the conformity of the input documents.</p>
1937
1938   <p>User agents fall into several (overlapping) categories with different conformance
1939   requirements.</p>
1940
1941   <dl>
1942
1943    <dt id="interactive">Web browsers and other interactive user agents</dt>
1944
1945    <dd>
1946
1947     <p>Web browsers that support <span>the XHTML syntax</span> must process elements and attributes
1948     from the <span>HTML namespace</span> found in XML documents as described in this specification,
1949     so that users can interact with them, unless the semantics of those elements have been
1950     overridden by other specifications.</p>
1951
1952     <p class="example">A conforming XHTML processor would, upon finding an XHTML <code>script</code>
1953     element in an XML document, execute the script contained in that element. However, if the
1954     element is found within a transformation expressed in XSLT (assuming the user agent also
1955     supports XSLT), then the processor would instead treat the <code>script</code> element as an
1956     opaque element that forms part of the transform.</p>
1957
1958     <p>Web browsers that support <span>the HTML syntax</span> must process documents labeled with an
1959     <span>HTML MIME type</span> as described in this specification, so that users can interact with
1960     them.</p>
1961
1962     <p>User agents that support scripting must also be conforming implementations of the IDL
1963     fragments in this specification, as described in the Web IDL specification. <a
1964     href="#refsWEBIDL">[WEBIDL]</a></p>
1965
1966     <p class="note">Unless explicitly stated, specifications that override the semantics of HTML
1967     elements do not override the requirements on DOM objects representing those elements. For
1968     example, the <code>script</code> element in the example above would still implement the
1969     <code>HTMLScriptElement</code> interface.</p>
1970
1971    </dd>
1972
1973    <dt id="non-interactive">Non-interactive presentation user agents</dt>
1974
1975    <dd>
1976
1977     <p>User agents that process HTML and XHTML documents purely to render non-interactive versions
1978     of them must comply to the same conformance criteria as Web browsers, except that they are
1979     exempt from requirements regarding user interaction.</p>
1980
1981     <p class="note">Typical examples of non-interactive presentation user agents are printers
1982     (static UAs) and overhead displays (dynamic UAs). It is expected that most static
1983     non-interactive presentation user agents will also opt to <a href="#non-scripted">lack scripting
1984     support</a>.</p>
1985
1986     <p class="example">A non-interactive but dynamic presentation UA would still execute scripts,
1987     allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus"
1988     is irrelevant when the user cannot interact with the document, the UA would not need to support
1989     any of the focus-related DOM APIs.</p>
1990
1991    </dd>
1992
1993    <dt id="renderingUA">Visual user agents that support the suggested default rendering</dt>
1994
1995    <dd>
1996
1997     <p>User agents, whether interactive or not, may be designated (possibly as a user option) as
1998     supporting the suggested default rendering defined by this specification.</p>
1999
2000     <p>This is not required. In particular, even user agents that do implement the suggested default
2001     rendering are encouraged to offer settings that override this default to improve the experience
2002     for the user, e.g. changing the color contrast, using different focus styles, or otherwise
2003     making the experience more accessible and usable to the user.</p>
2004
2005     <p>User agents that are designated as supporting the suggested default rendering must, while so
2006     designated, implement the rules in <a href="#rendering">the rendering section</a> that that
2007     section defines as the behavior that user agents are <em>expected</em> to implement.</p>
2008
2009    </dd>
2010
2011    <dt id="non-scripted">User agents with no scripting support</dt>
2012
2013    <dd>
2014
2015     <p>Implementations that do not support scripting (or which have their scripting features
2016     disabled entirely) are exempt from supporting the events and DOM interfaces mentioned in this
2017     specification. For the parts of this specification that are defined in terms of an events model
2018     or in terms of the DOM, such user agents must still act as if events and the DOM were
2019     supported.</p>
2020
2021     <p class="note">Scripting can form an integral part of an application. Web browsers that do not
2022     support scripting, or that have scripting disabled, might be unable to fully convey the author's
2023     intent.</p>
2024
2025    </dd>
2026
2027
2028    <dt>Conformance checkers</dt>
2029
2030    <dd id="conformance-checkers">
2031
2032     <p>Conformance checkers must verify that a document conforms to the applicable conformance
2033     criteria described in this specification. Automated conformance checkers are exempt from
2034     detecting errors that require interpretation of the author's intent (for example, while a
2035     document is non-conforming if the content of a <code>blockquote</code> element is not a quote,
2036     conformance checkers running without the input of human judgement do not have to check that
2037     <code>blockquote</code> elements only contain quoted material).</p>
2038
2039     <p>Conformance checkers must check that the input document conforms when parsed without a
2040     <span>browsing context</span> (meaning that no scripts are run, and that the parser's
2041     <span>scripting flag</span> is disabled), and should also check that the input document conforms
2042     when parsed with a <span>browsing context</span> in which scripts execute, and that the scripts
2043     never cause non-conforming states to occur other than transiently during script execution
2044     itself. (This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be
2045     impossible. <a href="#refsCOMPUTABLE">[COMPUTABLE]</a>)</p>
2046
2047     <p>The term "HTML validator" can be used to refer to a conformance checker that itself conforms
2048     to the applicable requirements of this specification.</p>
2049
2050     <div class="note">
2051
2052      <p>XML DTDs cannot express all the conformance requirements of this specification. Therefore, a
2053      validating XML processor and a DTD cannot constitute a conformance checker. Also, since neither
2054      of the two authoring formats defined in this specification are applications of SGML, a
2055      validating SGML system cannot constitute a conformance checker either.</p>
2056
2057      <p>To put it another way, there are three types of conformance criteria:</p>
2058
2059      <ol>
2060
2061       <li>Criteria that can be expressed in a DTD.</li>
2062
2063       <li>Criteria that cannot be expressed by a DTD, but can still be checked by a machine.</li>
2064
2065       <li>Criteria that can only be checked by a human.</li>
2066
2067      </ol>
2068
2069      <p>A conformance checker must check for the first two. A simple DTD-based validator only checks
2070      for the first class of errors and is therefore not a conforming conformance checker according
2071      to this specification.</p>
2072
2073     </div>
2074    </dd>
2075
2076
2077    <dt>Data mining tools</dt>
2078
2079    <dd id="data-mining">
2080
2081     <p>Applications and tools that process HTML and XHTML documents for reasons other than to either
2082     render the documents or check them for conformance should act in accordance with the semantics
2083     of the documents that they process.</p>
2084
2085     <p class="example">A tool that generates <span title="outline">document outlines</span> but
2086     increases the nesting level for each paragraph and does not increase the nesting level for each
2087     section would not be conforming.</p>
2088
2089    </dd>
2090
2091
2092    <dt id="editors">Authoring tools and markup generators</dt>
2093
2094    <dd>
2095
2096     <p>Authoring tools and markup generators must generate <span>conforming documents</span>.
2097     Conformance criteria that apply to authors also apply to authoring tools, where appropriate.</p>
2098
2099     <p>Authoring tools are exempt from the strict requirements of using elements only for their
2100     specified purpose, but only to the extent that authoring tools are not yet able to determine
2101     author intent. However, authoring tools must not automatically misuse elements or encourage
2102     their users to do so.</p>
2103
2104     <p class="example">For example, it is not conforming to use an <code>address</code> element for
2105     arbitrary contact information; that element can only be used for marking up contact information
2106     for the author of the document or section. However, since an authoring tool is likely unable to
2107     determine the difference, an authoring tool is exempt from that requirement. This does not mean,
2108     though, that authoring tools can use <code>address</code> elements for any block of italics text
2109     (for instance); it just means that the authoring tool doesn't have to verify that when the user
2110     uses a tool for inserting contact information for a section, that the user really is doing that
2111     and not inserting something else instead.</p>
2112
2113     <p class="note">In terms of conformance checking, an editor has to output documents that conform
2114     to the same extent that a conformance checker will verify.</p>
2115
2116     <p>When an authoring tool is used to edit a non-conforming document, it may preserve the
2117     conformance errors in sections of the document that were not edited during the editing session
2118     (i.e. an editing tool is allowed to round-trip erroneous content). However, an authoring tool
2119     must not claim that the output is conformant if errors have been so preserved.</p>
2120
2121     <p>Authoring tools are expected to come in two broad varieties: tools that work from structure
2122     or semantic data, and tools that work on a What-You-See-Is-What-You-Get media-specific editing
2123     basis (WYSIWYG).</p>
2124
2125     <p>The former is the preferred mechanism for tools that author HTML, since the structure in the
2126     source information can be used to make informed choices regarding which HTML elements and
2127     attributes are most appropriate.</p>
2128
2129     <p>However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are
2130     appropriate, and should not use elements that they do not know to be appropriate. This might in
2131     certain extreme cases mean limiting the use of flow elements to just a few elements, like
2132     <code>div</code>, <code>b</code>, <code>i</code>, and <code>span</code> and making liberal use
2133     of the <code title="attr-style">style</code> attribute.</p>
2134
2135     <p>All authoring tools, whether WYSIWYG or not, should make a best effort attempt at enabling
2136     users to create well-structured, semantically rich, media-independent content.</p>
2137
2138    </dd>
2139
2140   </dl>
2141
2142   <p id="hardwareLimitations">User agents may impose implementation-specific limits on otherwise
2143   unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of
2144   memory, or to work around platform-specific limitations.</p>
2145
2146   <p>For compatibility with existing content and prior specifications, this specification describes
2147   two authoring formats: one based on XML (referred to as <span>the XHTML syntax</span>), and one
2148   using a <a href="#writing">custom format</a> inspired by SGML (referred to as <span>the HTML
2149   syntax</span>). Implementations must support at least one of these two formats, although
2150   supporting both is encouraged.</p>
2151
2152   <p>Some conformance requirements are phrased as requirements on elements, attributes, methods or
2153   objects. Such requirements fall into two categories: those describing content model restrictions,
2154   and those describing implementation behavior. Those in the former category are requirements on
2155   documents and authoring tools. Those in the second category are requirements on user agents.
2156   Similarly, some conformance requirements are phrased as requirements on authors; such requirements
2157   are to be interpreted as conformance requirements on the documents that authors produce. (In other
2158   words, this specification does not distinguish between conformance criteria on authors and
2159   conformance criteria on documents.)</p>
2160
2161   </div>
2162
2163
2164   <div class="impl">
2165
2166   <h4>Dependencies</h4>
2167
2168   <p>This specification relies on several other underlying specifications.</p>
2169
2170   <dl>
2171
2172    <dt>Unicode and Encoding</dt>
2173
2174    <dd>
2175
2176     <p>The Unicode character set is used to represent textual data, and the WHATWG Encoding standard
2177     defines requirements around <span title="encoding">character encodings</span>. <a
2178     href="#refsUNICODE">[UNICODE]</a></p>
2179
2180     <p class="note">This specification <a href="#encoding-terminology">introduces terminology</a>
2181     based on the terms defined in those specifications, as described earlier.</p>
2182
2183     <p>The following terms are used as defined in the Encoding specification: <a
2184     href="#refsENCODING">[ENCODING]</a></p>
2185
2186     <ul class="brief">
2187
2188      <li><dfn>Getting an encoding</dfn>
2189
2190      <li>The <dfn>encoder</dfn> and <dfn>decoder</dfn> algorithms for various encodings, including
2191      the <dfn>UTF-8 encoder</dfn> and <dfn>UTF-8 decoder</dfn>
2192
2193      <li>The generic <dfn>decode</dfn> algorithm which takes a byte stream and an encoding and
2194      returns a character stream
2195
2196      <li>The <dfn>UTF-8 decode</dfn> algorithm which takes a byte stream and returns a character
2197      stream, additionally stripping one leading UTF-8 Byte Order Mark (BOM), if any
2198
2199     </ul>
2200
2201     <p class="note">The <span>UTF-8 decoder</span> is distinct from the <i>UTF-8 decode
2202     algorithm</i>. The latter first strips a Byte Order Mark (BOM), if any, and then invokes the
2203     former.</p>
2204
2205    </dd>
2206
2207
2208    <dt>XML</dt>
2209
2210    <dd>
2211
2212     <p>Implementations that support <span>the XHTML syntax</span> must support some version of XML,
2213     as well as its corresponding namespaces specification, because that syntax uses an XML
2214     serialization with namespaces. <a href="#refsXML">[XML]</a> <a href="#refsXMLNS">[XMLNS]</a></p>
2215
2216    </dd>
2217
2218
2219    <dt>URLs</dt>
2220
2221    <dd>
2222
2223     <p>The following terms are defined in the URL standard: <a href="#refsURL">[URL]</a></p>
2224
2225     <ul class="brief">
2226      <li><dfn>URL</dfn>
2227      <li><dfn>Absolute URL</dfn>
2228      <li><dfn>Relative URL</dfn>
2229      <li><dfn title="concept-url-scheme-relative">Relative schemes</dfn>
2230      <li>The <dfn>URL parser</dfn>
2231      <li><dfn>Parsed URL</dfn>
2232      <li>The <dfn title="concept-url-scheme">scheme</dfn> component of a <span>parsed URL</span>
2233      <li>The <dfn title="concept-url-scheme data">scheme data</dfn> component of a <span>parsed URL</span>
2234      <li>The <dfn title="concept-url-username">username</dfn> component of a <span>parsed URL</span>
2235      <li>The <dfn title="concept-url-password">password</dfn> component of a <span>parsed URL</span>
2236      <li>The <dfn title="concept-url-host">host</dfn> component of a <span>parsed URL</span>
2237      <li>The <dfn title="concept-url-port">port</dfn> component of a <span>parsed URL</span>
2238      <li>The <dfn title="concept-url-path">path</dfn> component of a <span>parsed URL</span>
2239      <li>The <dfn title="concept-url-query">query</dfn> component of a <span>parsed URL</span>
2240      <li>The <dfn title="concept-url-fragment">fragment</dfn> component of a <span>parsed URL</span>
2241      <li><dfn title="concept-url-parse-error">Parse errors</dfn> from the <span>URL parser</span>
2242      <li>The <dfn title="concept-url-serializer">URL serializer</dfn>
2243      <li><dfn>Default encode set</dfn>
2244      <li><dfn>Percent encode</dfn>
2245      <li><dfn>UTF-8 percent encode</dfn>
2246      <li><dfn>Percent decode</dfn>
2247      <li><dfn>Decoder error</dfn>
2248      <li><dfn><code>URLUtils</code></dfn> interface
2249      <li><dfn><code>URLUtilsReadOnly</code></dfn> interface
2250      <li><dfn title="dom-url-href"><code>href</code> attribute</dfn>
2251      <li><dfn title="dom-url-protocol"><code>protocol</code> attribute</dfn>
2252      <li>The <dfn title="concept-uu-get-the-base">get the base</dfn> hook for <code>URLUtils</code>
2253      <li>The <dfn title="concept-uu-update">update steps</dfn> hook for <code>URLUtils</code>
2254      <li>The <dfn title="concept-uu-set-the-input">set the input</dfn> algorithm for <code>URLUtils</code>
2255      <li>The <dfn title="concept-uu-query-encoding">query encoding</dfn> of an <code>URLUtils</code> object
2256      <li>The <dfn title="concept-uu-input">input</dfn> of an <code>URLUtils</code> object
2257      <li>The <dfn title="concept-uu-url">url</dfn> of an <code>URLUtils</code> object
2258     </ul>
2259
2260    </dd>
2261
2262
2263    <dt>Cookies</dt>
2264
2265    <dd>
2266
2267     <p>The following terms are defined in the Cookie specification: <a
2268     href="#refsCOOKIES">[COOKIES]</a></p>
2269
2270     <ul class="brief">
2271      <li><dfn>cookie-string</dfn>
2272      <li><dfn>receives a set-cookie-string</dfn>
2273     </ul>
2274
2275    </dd>
2276
2277
2278    <dt>CORS</dt>
2279
2280    <dd>
2281
2282     <p>The following terms are defined in the CORS specification: <a href="#refsCORS">[CORS]</a></p>
2283
2284     <ul class="brief">
2285      <li><dfn>cross-origin request</dfn>
2286      <li><dfn>cross-origin request status</dfn>
2287      <li><dfn>custom request headers</dfn>
2288      <li><dfn>simple cross-origin request</dfn>
2289      <li><dfn>redirect steps</dfn>
2290      <li><dfn>omit credentials flag</dfn>
2291      <li><dfn>resource sharing check</dfn>
2292     </ul>
2293
2294    </dd>
2295
2296
2297 <!--TOPIC:DOM APIs-->
2298
2299    <dt>Web IDL</dt>
2300
2301    <dd>
2302
2303     <p>The IDL fragments in this specification must be interpreted as required for conforming IDL
2304     fragments, as described in the Web IDL specification. <a href="#refsWEBIDL">[WEBIDL]</a></p>
2305
2306     <p>The terms <dfn>supported property indices</dfn>, <dfn>determine the value
2307     of an indexed property</dfn>, <dfn>support named properties</dfn>, <dfn>supported property
2308     names</dfn>, <dfn>determine the value of a named property</dfn>, <dfn>platform array
2309     objects</dfn>, and <dfn title="dfn-read-only-array">read only</dfn> (when applied to arrays) are
2310     used as defined in the Web IDL specification. The algorithm to <dfn>convert a DOMString to a
2311     sequence of Unicode characters</dfn> is similarly that defined in the Web IDL specification.</p>
2312
2313     <p>Where this specification says an interface or exception is <dfn>exposed to JavaScript</dfn>,
2314     it refers to the manner, described in the Web IDL specification, in which an ECMAScript global
2315     environment <i title="dfn-expose">exposes</i> interfaces and exceptions.</p>
2316
2317     <p>When this specification requires a user agent to <dfn>create a <code>Date</code> object</dfn>
2318     representing a particular time (which could be the special value Not-a-Number), the milliseconds
2319     component of that time, if any, must be truncated to an integer and the time value of the newly
2320     created <code>Date</code> object must represent the time after that truncation.</p>
2321
2322     <p class="example">For instance, given the time 23045 millionths of a second after 01:00 UTC on
2323     January 1st 2000, i.e. the time 2000-01-01T00:00:00.023045Z, then the <code>Date</code> object
2324     created representing that time would represent the same time as that created representing the
2325     time 2000-01-01T00:00:00.023Z, 45 millionths earlier. If the given time is NaN, then the result
2326     is a <code>Date</code> object that represents a time value NaN (indicating that the object does
2327     not represent a specific instant of time).</p>
2328
2329    </dd>
2330
2331
2332    <dt>JavaScript</dt>
2333
2334    <dd>
2335
2336     <p>Some parts of the language described by this specification only support JavaScript as the
2337     underlying scripting language. <a href="#refsECMA262">[ECMA262]</a></p>
2338
2339     <p class="note">The term "JavaScript" is used to refer to ECMA262, rather than the official term
2340     ECMAScript, since the term JavaScript is more widely known. Similarly, the <span>MIME
2341     type</span> used to refer to JavaScript in this specification is <code
2342     title="">text/javascript</code>, since that is the most commonly used type, <span title="willful
2343     violation">despite it being an officially obsoleted type</span> according to RFC 4329. <a
2344     href="#refsRFC4329">[RFC4329]</a></p>
2345
2346     <p>The term <dfn>JavaScript global environment</dfn> refers to the <i title="">global
2347     environment</i> concept defined in the ECMAScript specification.</p>
2348
2349     <p>The ECMAScript <dfn title="js-SyntaxError"><code>SyntaxError</code></dfn> exception is also
2350     defined in the ECMAScript specification. <a href="#refsECMA262">[ECMA262]</a></p>
2351
2352    </dd>
2353
2354
2355    <dt>DOM</dt>
2356
2357    <dd>
2358
2359     <p>The Document Object Model (DOM) is a representation &mdash; a model &mdash; of a document and
2360     its content. The DOM is not just an API; the conformance criteria of HTML implementations are
2361     defined, in this specification, in terms of operations on the DOM. <a
2362     href="#refsDOM">[DOM]</a></p>
2363
2364     <p>Implementations must support DOM and the events defined in DOM Events, because this
2365     specification is defined in terms of the DOM, and some of the features are defined as extensions
2366     to the DOM interfaces. <a href="#refsDOM">[DOM]</a> <a href="#refsDOMEVENTS">[DOMEVENTS]</a></p>
2367
2368     <p>In particular, the following features are defined in the DOM specification: <a
2369     href="#refsDOM">[DOM]</a></p>
2370
2371     <ul class="brief">
2372
2373      <li><dfn><code>Attr</code></dfn> interface</li>
2374      <li><dfn><code>Comment</code></dfn> interface</li>
2375      <li><dfn><code>DOMImplementation</code></dfn> interface</li>
2376      <li><dfn title="DOM Document"><code>Document</code></dfn> interface</li>
2377      <li><dfn><code>DocumentFragment</code></dfn> interface</li>
2378      <li><dfn><code>DocumentType</code></dfn> interface</li>
2379      <li><dfn><code>DOMException</code></dfn> interface</li>
2380      <li><dfn><code>Element</code></dfn> interface</li>
2381      <li><dfn><code>Node</code></dfn> interface</li>
2382      <li><dfn><code>NodeList</code></dfn> interface</li>
2383      <li><dfn><code>ProcessingInstruction</code></dfn> interface</li>
2384      <li><dfn><code>Text</code></dfn> interface</li>
2385
2386      <li><dfn><code>HTMLCollection</code></dfn> interface</li>
2387      <li><dfn title="dom-HTMLCollection-item"><code>item()</code> method</dfn>
2388      <li>The terms <dfn>collections</dfn> and <dfn>represented by the collection</dfn></li>
2389
2390      <li><dfn><code>DOMTokenList</code></dfn> interface</li>
2391      <li><dfn><code>DOMSettableTokenList</code></dfn> interface</li>
2392
2393      <li><dfn title="dom-DOMImplementation-createDocument"><code>createDocument()</code></dfn> method</li>
2394      <li><dfn title="dom-DOMImplementation-createHTMLDocument"><code>createHTMLDocument()</code></dfn> method</li>
2395      <li><dfn title="dom-Document-createElement"><code>createElement()</code></dfn> method</li>
2396      <li><dfn title="dom-Document-createElementNS"><code>createElementNS()</code></dfn> method</li>
2397      <li><dfn title="dom-Document-getElementById"><code>getElementById()</code></dfn> method</li>
2398      <li><dfn title="dom-Node-insertBefore"><code>insertBefore()</code></dfn> method</li>
2399
2400      <li><dfn title="dom-Node-ownerDocument"><code>ownerDocument</code></dfn> attribute</li>
2401      <li><dfn title="dom-Node-childNodes"><code>childNodes</code></dfn> attribute</li>
2402      <li><dfn title="dom-Node-localName"><code>localName</code></dfn> attribute</li>
2403      <li><dfn title="dom-Node-parentNode"><code>parentNode</code></dfn> attribute</li>
2404      <li><dfn title="dom-Node-namespaceURI"><code>namespaceURI</code></dfn> attribute</li>
2405      <li><dfn title="dom-Element-tagName"><code>tagName</code></dfn> attribute</li>
2406      <li><dfn title="dom-Element-id"><code>id</code></dfn> attribute</li>
2407      <li><dfn><code>textContent</code></dfn> attribute</li>
2408
2409      <li>The <dfn title="concept-node-insert">insert</dfn>, <dfn title="concept-node-append">append</dfn>, <dfn title="concept-node-remove">remove</dfn>, and <dfn title="concept-node-replace">replace</dfn> algorithms for nodes</li>
2410      <li>The <dfn>nodes are inserted</dfn> and <dfn>nodes are removed</dfn> concepts</li>
2411      <li>The <dfn>attribute list</dfn> concept.</li>
2412      <li>The <dfn title="concept-cd-data">data</dfn> of a text node.</li>
2413
2414      <li><dfn><code>Event</code></dfn> interface</li>
2415      <li><dfn><code>EventTarget</code></dfn> interface</li>
2416      <li><dfn><code>EventInit</code></dfn> dictionary type</li>
2417      <li><dfn title="dom-Event-target"><code>target</code></dfn> attribute</li>
2418      <li><dfn title="dom-Event-isTrusted"><code>isTrusted</code></dfn> attribute</li>
2419      <li>The <dfn title="concept-event-type">type</dfn> of an event</li>
2420      <li>The concept of an <dfn title=concept-event-listener>event listener</dfn> and the <span title=concept-event-listener>event listeners</span> associated with an <code>EventTarget</code></li>
2421      <li>The concept of a regular <dfn>event parent</dfn> and a <dfn>cross-boundary event parent</dfn></li> <!-- see bug 18780 -->
2422
2423      <li>The <dfn title="document's character encoding">encoding</dfn> (herein the <i>character encoding</i>) and <dfn title="concept-document-content-type">content type</dfn> of a <code>Document</code></li>
2424      <li>The distinction between <dfn>XML documents</dfn> and <dfn>HTML documents</dfn></li>
2425      <li>The terms <dfn>quirks mode</dfn>, <dfn>limited-quirks mode</dfn>, and <dfn>no-quirks mode</dfn></li>
2426      <li>The algorithm to <dfn title="concept-node-clone">clone</dfn> a <code>Node</code>, and the concept of <dfn title="concept-node-clone-ext">cloning steps</dfn> used by that algorithm</li>
2427      <li>The concept of <dfn>base URL change steps</dfn> and the definition of what happens when an element is <dfn>affected by a base URL change</dfn></li>
2428      <li>The concept of an element's <dfn title="concept-id">unique identifier (ID)</dfn></li>
2429
2430      <li>The concept of a DOM <dfn title="concept-range">range</dfn>, and the terms <dfn title="concept-range-start">start</dfn>, <dfn title="concept-range-end">end</dfn>, and <dfn title="concept-range-bp">boundary point</dfn> as applied to ranges.</li>
2431
2432      <li><dfn><code>MutationObserver</code></dfn> interface</li>
2433      <li>The <dfn><code>MutationObserver</code> <var title="">scripting environment</var></dfn> concept</li>
2434      <li>The <dfn title="concept-mo-invoke">invoke <code>MutationObserver</code> objects</dfn> algorithm</li>
2435
2436     </ul>
2437
2438     <p>The term <dfn>throw</dfn> in this specification is used as defined in the DOM specification.
2439     The following <code>DOMException</code> types are defined in the DOM specification: <a
2440     href="#refsDOM">[DOM]</a></p>
2441
2442     <ol class="brief">
2443      <li value="1"><dfn><code>IndexSizeError</code></dfn></li>
2444      <li value="3"><dfn><code>HierarchyRequestError</code></dfn></li>
2445      <li value="4"><dfn><code>WrongDocumentError</code></dfn></li>
2446      <li value="5"><dfn><code>InvalidCharacterError</code></dfn></li>
2447      <li value="7"><dfn><code>NoModificationAllowedError</code></dfn></li>
2448      <li value="8"><dfn><code>NotFoundError</code></dfn></li>
2449      <li value="9"><dfn><code>NotSupportedError</code></dfn></li>
2450      <li value="11"><dfn><code>InvalidStateError</code></dfn></li>
2451      <li value="12"><dfn><code>SyntaxError</code></dfn></li>
2452      <li value="13"><dfn><code>InvalidModificationError</code></dfn></li>
2453      <li value="14"><dfn><code>NamespaceError</code></dfn></li>
2454      <li value="15"><dfn><code>InvalidAccessError</code></dfn></li>
2455      <li value="18"><dfn><code>SecurityError</code></dfn></li>
2456      <li value="19"><dfn><code>NetworkError</code></dfn></li>
2457      <li value="20"><dfn><code>AbortError</code></dfn></li>
2458      <li value="21"><dfn><code>URLMismatchError</code></dfn></li>
2459      <li value="22"><dfn><code>QuotaExceededError</code></dfn></li>
2460      <li value="23"><dfn><code>TimeoutError</code></dfn></li>
2461      <li value="24"><dfn><code>InvalidNodeTypeError</code></dfn></li>
2462      <li value="25"><dfn><code>DataCloneError</code></dfn></li>
2463     </ol>
2464
2465     <p class="example">For example, to <i>throw a <code>TimeoutError</code> exception</i>, a user
2466     agent would construct a <code>DOMException</code> object whose type was the string "<code
2467     title="">TimeoutError</code>" (and whose code was the number 23, for legacy reasons) and
2468     actually throw that object as an exception.</p>
2469
2470     <p>The <span title="concept-document-URL">URL</span> associated with a <code>Document</code>, as
2471     defined in the DOM specification, is referred to in this specification as <span>the document's
2472     address</span>.</p>
2473
2474     <p>The following features are defined in the DOM Events specification: <a
2475     href="#refsDOMEVENTS">[DOMEVENTS]</a></p>
2476
2477     <ul class="brief">
2478
2479      <li><dfn><code>MouseEvent</code></dfn> interface</li>
2480      <li><dfn><code>MouseEventInit</code></dfn> dictionary type</li>
2481
2482      <li>The <dfn><code>UIEvent</code></dfn> interface's <dfn title="dom-UIEvent-detail"><code>detail</code></dfn> attribute</li>
2483
2484      <li><dfn title="event-click"><code>click</code></dfn> event</li>
2485
2486     </ul>
2487
2488     <p>This specification sometimes uses the term <dfn
2489     title="">name</dfn> to refer to the event's <code
2490     title="dom-event-type">type</code>; as in, "an event named <code
2491     title="">click</code>" or "if the event name is <code
2492     title="">keypress</code>". The terms "name" and "type" for events
2493     are synonymous.</p>
2494
2495     <p>The following features are defined in the DOM Parsing and
2496     Serialization specification: <a
2497     href="#refsDOMPARSING">[DOMPARSING]</a></p>
2498
2499     <ul class="brief">
2500      <li><dfn title="dom-innerHTML"><code>innerHTML</code></dfn></li>
2501      <li><dfn title="dom-outerHTML"><code>outerHTML</code></dfn></li>
2502     </ul>
2503
2504     <p class="note">User agents are also encouraged to implement the
2505     features described in the <cite>HTML Editing APIs</cite> and
2506     <cite><code>UndoManager</code> and DOM Transaction</cite>
2507     specifications.
2508     <a href="#refsEDITING">[EDITING]</a>
2509     <a href="#refsUNDO">[UNDO]</a>
2510     </p>
2511
2512     <p>The following parts of the Fullscreen specification are referenced from this specification,
2513     in part to define the rendering of <code>dialog</code> elements, and also to define how the
2514     Fullscreen API interacts with the sandboxing features in HTML: <a
2515     href="#refsFULLSCREEN">[FULLSCREEN]</a></p>
2516
2517     <ul class="brief">
2518      <li>The <dfn>top layer</dfn> concept</li>
2519      <li><dfn title="dom-element-requestFullscreen"><code>requestFullscreen()</code></dfn>
2520      <li>The <dfn>fullscreen enabled flag</dfn></li>
2521      <li>The <dfn>fully exit fullscreen</dfn> algorithm</li>
2522     </ul>
2523
2524    </dd>
2525
2526
2527    <dt>Typed Arrays</dt>
2528
2529    <dd>
2530
2531     <p>The <dfn>ArrayBuffer</dfn> and <dfn>ArrayBufferView</dfn> interfaces and underlying concepts
2532     from the Typed Array Specification are used for several features in this specification. The
2533     <dfn>Uint8ClampedArray</dfn> interface type is specifically used in the definition of the
2534     <code>canvas</code> element's 2D API. <a href="#refsTYPEDARRAY">[TYPEDARRAY]</a></p>
2535
2536    </dd>
2537
2538
2539    <dt>File API</dt>
2540
2541    <dd>
2542
2543     <p>This specification uses the following features defined in the File API specification: <a
2544     href="#refsFILEAPI">[FILEAPI]</a></p>
2545
2546     <ul class="brief">
2547
2548      <li><dfn><code>Blob</code></dfn></li>
2549      <li><dfn><code>File</code></dfn></li>
2550      <li><dfn><code>FileList</code></dfn></li>
2551      <li><dfn><code title="dom-Blob-close">Blob.close()</code></dfn></li>
2552      <li><dfn><code title="dom-Blob-type">Blob.type</code></dfn></li>
2553      <li>The concept of <dfn title="file-error-read">read errors</dfn></li>
2554     </ul>
2555
2556    </dd>
2557
2558
2559    <dt>XMLHttpRequest</dt>
2560
2561    <dd>
2562
2563     <p>This specification references the XMLHttpRequest specification to define how the two
2564     specifications interact and to use its <code>ProgressEvent</code> features. The following
2565     features and terms are defined in the XMLHttpRequest specification: <a
2566     href="#refsXHR">[XHR]</a></p>
2567
2568     <ul class="brief">
2569
2570      <li><dfn>Document response entity body</dfn>
2571      <li><dfn><code>XMLHttpRequest</code> base URL</dfn>
2572      <li><dfn><code>XMLHttpRequest</code> origin</dfn>
2573      <li><dfn><code>XMLHttpRequest</code> referrer source</dfn>
2574
2575      <li><dfn><code>ProgressEvent</code></dfn>
2576      <li><dfn title="fire a progress event">Fire a progress event named <var title="">e</var></dfn>
2577
2578     </ul>
2579
2580    </dd>
2581
2582
2583 <!--TOPIC:HTML-->
2584
2585    <dt>Media Queries</dt>
2586
2587    <dd>
2588
2589     <p>Implementations must support the Media Queries language. <a href="#refsMQ">[MQ]</a></p>
2590
2591    </dd>
2592
2593
2594    <dt>CSS modules</dt>
2595
2596    <dd>
2597
2598     <p>While support for CSS as a whole is not required of implementations of this specification
2599     (though it is encouraged, at least for Web browsers), some features are defined in terms of
2600     specific CSS requirements.</p>
2601
2602     <p>In particular, some features require that a string be <dfn>parsed as a CSS &lt;color&gt;
2603     value</dfn>. When parsing a CSS value, user agents are required by the CSS specifications to
2604     apply some error handling rules. These apply to this specification also. <a
2605     href="#refsCSSCOLOR">[CSSCOLOR]</a> <a href="#refsCSS">[CSS]</a></p>
2606
2607     <p class="example">For example, user agents are required to close all open constructs upon
2608     finding the end of a style sheet unexpectedly. Thus, when parsing the string "<code
2609     title="">rgb(0,0,0</code>" (with a missing close-parenthesis) for a color value, the close
2610     parenthesis is implied by this error handling rule, and a value is obtained (the color 'black').
2611     However, the similar construct "<code title="">rgb(0,0,</code>" (with both a missing parenthesis
2612     and a missing "blue" value) cannot be parsed, as closing the open construct does not result in a
2613     viable value.</p>
2614
2615     <p>The term <dfn>CSS element reference identifier</dfn> is used as defined in the <cite>CSS
2616     Image Values and Replaced Content</cite> specification to define the API that declares
2617     identifiers for use with the CSS 'element()' function. <a
2618     href="#refsCSSIMAGES">[CSSIMAGES]</a></p>
2619
2620     <p>Similarly, the term <dfn>provides a paint source</dfn> is used as defined in the <cite>CSS
2621     Image Values and Replaced Content</cite> specification to define the interaction of certain HTML
2622     elements with the CSS 'element()' function. <a href="#refsCSSIMAGES">[CSSIMAGES]</a></p>
2623
2624     <p>Support for the CSS Object Model is required for implementations that support scripting. The
2625     following features and terms are defined in the CSSOM specifications: <a
2626     href="#refsCSSOM">[CSSOM]</a> <a href="#refsCSSOMVIEW">[CSSOMVIEW]</a>
2627
2628     <ul class="brief">
2629      <li><dfn><code>Screen</code></dfn></li>
2630      <li><dfn><code>LinkStyle</code></dfn></li>
2631      <li><dfn><code>CSSStyleDeclaration</code></dfn></li>
2632      <li><dfn title="dom-CSSStyleDeclaration-cssText"><code>cssText</code></dfn> attribute of <code>CSSStyleDeclaration</code></li>
2633      <li><dfn><code>StyleSheet</code></dfn></li>
2634      <li><dfn title="dom-linkstyle-sheet"><code>sheet</code></dfn></li>
2635      <li><dfn title="dom-stylesheet-disabled"><code>disabled</code></dfn></li>
2636      <li><dfn>Alternative style sheet sets</dfn> and the <dfn>preferred style sheet set</dfn></li>
2637      <li><dfn>Serializing a CSS value</dfn></li>
2638      <li><dfn>Scroll an element into view</dfn></li>
2639     </ul>
2640
2641     <p>The term <dfn>CSS styling attribute</dfn> is defined in the <cite>CSS Style Attributes</cite>
2642     specification. <a href="#refsCSSATTR">[CSSATTR]</a></p>
2643
2644     <p>The <code>CanvasRenderingContext2D</code> object's use of fonts depends on the features
2645     described in the CSS Fonts specification, including in particular
2646     <dfn><code>FontLoader</code></dfn>. <a href="#refsCSSFONTS">[CSSFONTS]</a></p>
2647
2648    </dd>
2649
2650
2651 <!--TOPIC:Canvas-->
2652
2653    <dt>SVG</dt>
2654
2655    <dd>
2656
2657     <p>The following interface is defined in the SVG specification: <a href="#refsSVG">[SVG]</a></p>
2658
2659     <ul class="brief">
2660      <li><dfn><code>SVGMatrix</code></dfn>
2661     </ul>
2662
2663     <!-- mention that the parser supports it? -->
2664
2665    </dd>
2666
2667
2668    <dt>WebGL</dt>
2669
2670    <dd>
2671
2672     <p>The following interface is defined in the WebGL specification: <a
2673     href="#refsWEBGL">[WEBGL]</a></p>
2674
2675     <ul class="brief">
2676      <li><dfn><code>WebGLRenderingContext</code></dfn>
2677     </ul>
2678
2679    </dd>
2680
2681
2682 <!--TOPIC:HTML-->
2683
2684    <!-- mention that the parser supports mathml? -->
2685
2686
2687 <!--TOPIC:Video Text Tracks-->
2688
2689    <dt>WebVTT</dt>
2690
2691    <dd>
2692
2693     <p>Implementations may support <dfn>WebVTT</dfn> as a text track format for subtitles, captions,
2694     chapter titles, metadata, etc, for media resources. <a href="#refsWEBVTT">[WEBVTT]</a></p>
2695
2696     <p>The following terms, used in this specification, are defined in the WebVTT specification:</p>
2697
2698     <ul class="brief">
2699      <li><dfn>WebVTT file</dfn>
2700      <li><dfn>WebVTT file using cue text</dfn>
2701      <li><dfn>WebVTT file using chapter title text</dfn>
2702      <li><dfn>WebVTT file using only nested cues</dfn>
2703      <li><dfn>WebVTT parser</dfn>
2704      <li>The <dfn>rules for updating the display of WebVTT text tracks</dfn>
2705      <li>The <dfn>rules for interpreting WebVTT cue text</dfn>
2706      <li>The WebVTT <dfn>text track cue writing direction</dfn>
2707     </ul>
2708
2709    </dd>
2710
2711
2712 <!--TOPIC:WebSocket API-->
2713
2714    <dt>The WebSocket protocol</dt>
2715
2716    <dd>
2717
2718     <p>The following terms are defined in the WebSocket protocol specification: <a
2719     href="#refsWSP">[WSP]</a></p>
2720
2721     <ul class="brief">
2722
2723      <li><dfn>establish a WebSocket connection</dfn>
2724      <li><dfn>the WebSocket connection is established</dfn>
2725      <li><dfn>validate the server's response</dfn>
2726      <li><dfn>extensions in use</dfn>
2727      <li><dfn>subprotocol in use</dfn>
2728      <li><dfn>headers to send appropriate cookies</dfn>
2729      <li><dfn>cookies set during the server's opening handshake</dfn>
2730      <li><dfn>a WebSocket message has been received</dfn>
2731      <li><dfn>fail the WebSocket connection</dfn>
2732      <li><dfn>close the WebSocket connection</dfn>
2733      <li><dfn>start the WebSocket closing handshake</dfn>
2734      <li><dfn>the WebSocket closing handshake is started</dfn>
2735      <li><dfn>the WebSocket connection is closed</dfn> (possibly <i title="">cleanly</i>)
2736      <li><dfn>the WebSocket connection close code</dfn>
2737      <li><dfn>the WebSocket connection close reason</dfn>
2738
2739     </ul>
2740
2741    </dd>
2742
2743
2744 <!--TOPIC:HTML-->
2745
2746    <dt>ARIA</dt>
2747
2748    <dd>
2749
2750     <p>The terms <dfn>strong native semantics</dfn> is used as defined in the ARIA specification.
2751     The term <dfn>default implicit ARIA semantics</dfn> has the same meaning as the term <i>implicit
2752     WAI-ARIA semantics</i> as used in the ARIA specification. <a href="#refsARIA">[ARIA]</a></p>
2753
2754     <p>The <dfn title="attr-aria-role"><code>role</code></dfn> and <code title="">aria-*</code>
2755     attributes are defined in the ARIA specification. <a href="#refsARIA">[ARIA]</a></p>
2756
2757
2758    </dd>
2759
2760
2761   </dl>
2762
2763   <p>This specification does not <em>require</em> support of any particular network protocol, style
2764   sheet language, scripting language, or any of the DOM specifications beyond those required in the
2765   list above. However, the language described by this specification is biased towards CSS as the
2766   styling language, JavaScript as the scripting language, and HTTP as the network protocol, and
2767   several features assume that those languages and protocols are in use.</p>
2768
2769   <p>A user agent that implements the HTTP protocol must implement the Web Origin Concept
2770   specification and the HTTP State Management Mechanism specification (Cookies) as well. <a
2771   href="#refsHTTP">[HTTP]</a> <a href="#refsORIGIN">[ORIGIN]</a> <a
2772   href="#refsCOOKIES">[COOKIES]</a></p>
2773
2774   <p class="note">This specification might have certain additional requirements on character
2775   encodings, image formats, audio formats, and video formats in the respective sections.</p>
2776
2777   </div>
2778
2779
2780 <!--START dev-html-->
2781 <!--FIXUP dev-html -1-->
2782   <h4>Extensibility</h4>
2783 <!--FIXUP dev-html +1-->
2784
2785   <p>HTML has a wide number of extensibility mechanisms that can be used for adding semantics in a
2786   safe manner:</p>
2787
2788   <ul>
2789
2790    <li>Authors can use the <code title="attr-class">class</code> attribute to extend elements,
2791    effectively creating their own elements, while using the most applicable existing "real" HTML
2792    element, so that browsers and other tools that don't know of the extension can still support it
2793    somewhat well. This is the tack used by microformats, for example.</li>
2794
2795    <li>Authors can include data for inline client-side scripts or server-side site-wide scripts to
2796    process using the <code title="attr-data-*">data-*=""</code> attributes. These are guaranteed to
2797    never be touched by browsers, and allow scripts to include data on HTML elements that scripts can
2798    then look for and process.</li>
2799
2800    <li>Authors can use the <code title="meta">&lt;meta name="" content=""></code> mechanism to
2801    include page-wide metadata by registering <span title="concept-meta-extensions">extensions to the
2802    predefined set of metadata names</span>.</li>
2803
2804    <li>Authors can use the <code title="attr-hyperlink-rel">rel=""</code> mechanism to annotate
2805    links with specific meanings by registering <span title="concept-rel-extensions">extensions to
2806    the predefined set of link types</span>. This is also used by microformats.</li>
2807
2808    <li>Authors can embed raw data using the <code title="script">&lt;script type=""></code>
2809    mechanism with a custom type, for further handling by inline or server-side scripts.</li>
2810
2811    <li>Authors can create <span title="plugin">plugins</span> and invoke them using the
2812    <code>embed</code> element. This is how Flash works.</li>
2813
2814    <li>Authors can extend APIs using the JavaScript prototyping mechanism. This is widely used by
2815    script libraries, for instance.</li>
2816
2817    <li>Authors can use the microdata feature (the <code title="attr-itemscope">itemscope=""</code>
2818    and <code title="attr-itemprop">itemprop=""</code> attributes) to embed nested name-value pairs
2819    of data to be shared with other applications and sites.</li>
2820
2821   </ul>
2822
2823   <hr>
2824
2825   <p>Vendor-specific proprietary user agent extensions to this specification are strongly
2826   discouraged. Documents must not use such extensions, as doing so reduces interoperability and
2827   fragments the user base, allowing only users of specific user agents to access the content in
2828   question.</p>
2829
2830   <div class="impl">
2831
2832   <p>If such extensions are nonetheless needed, e.g. for experimental purposes, then vendors are
2833   strongly urged to use one of the following extension mechanisms:</p>
2834
2835   <p>For markup-level features that can be limited to the XML serialization and need not be
2836   supported in the HTML serialization, vendors should use the namespace mechanism to define custom
2837   namespaces in which the non-standard elements and attributes are supported.</p>
2838
2839   <p>For markup-level features that are intended for use with <span>the HTML syntax</span>,
2840   extensions should be limited to new attributes of the form "<code title="">x-<var
2841   title="">vendor</var>-<var title="">feature</var></code>", where <var title="">vendor</var> is a
2842   short string that identifies the vendor responsible for the extension, and <var
2843   title="">feature</var> is the name of the feature. New element names should not be created. Using
2844   attributes for such extensions exclusively allows extensions from multiple vendors to co-exist on
2845   the same element, which would not be possible with elements. Using the "<code title="">x-<var
2846   title="">vendor</var>-<var title="">feature</var></code>" form allows extensions to be made
2847   without risk of conflicting with future additions to the specification.</p>
2848
2849   <div class="example">
2850
2851    <p>For instance, a browser named "FerretBrowser" could use "ferret" as a vendor prefix, while a
2852    browser named "Mellblom Browser" could use "mb". If both of these browsers invented extensions
2853    that turned elements into scratch-and-sniff areas, an author experimenting with these features
2854    could write:</p>
2855
2856    <pre>&lt;p>This smells of lemons!
2857 &lt;span x-ferret-smellovision x-ferret-smellcode="LEM01"
2858       x-mb-outputsmell x-mb-smell="lemon juice">&lt;/span>&lt;/p></pre>
2859
2860   </div>
2861
2862   <p>Attribute names beginning with the two characters "<code title="">x-</code>" are reserved for
2863   user agent use and are guaranteed to never be formally added to the HTML language. For
2864   flexibility, attributes names containing underscores (the U+005F LOW LINE character) are also
2865   reserved for experimental purposes and are guaranteed to never be formally added to the HTML
2866   language.</p>
2867
2868   <p class="note">Pages that use such attributes are by definition non-conforming.</p>
2869
2870   <p>For DOM extensions, e.g. new methods and IDL attributes, the new members should be prefixed by
2871   vendor-specific strings to prevent clashes with future versions of this specification.</p>
2872
2873   <p>For events, experimental event types should be prefixed with vendor-specific strings.</p>
2874
2875   <div class="example">
2876
2877    <p>For example, if a user agent called "Pleas<!--e h-->old" were to add an event to indicate when
2878    the user is going up in an elevator, it could use the prefix "<code title="">pleasold</code>" and
2879    thus name the event "<code title="">pleasoldgoingup</code>", possibly with an event handler
2880    attribute named "<code title="">onpleasoldgoingup</code>".</p>
2881
2882   </div>
2883
2884   <p>All extensions must be defined so that the use of extensions neither contradicts nor causes the
2885   non-conformance of functionality defined in the specification.</p> <!-- thanks to QA Framework -->
2886
2887   <div class="example">
2888
2889    <p>For example, while strongly discouraged from doing so, an implementation "Foo Browser" could
2890    add a new IDL attribute "<code title="">fooTypeTime</code>" to a control's DOM interface that
2891    returned the time it took the user to select the current value of a control (say). On the other
2892    hand, defining a new control that appears in a form's <code
2893    title="dom-form-elements">elements</code> array would be in violation of the above requirement,
2894    as it would violate the definition of <code title="dom-form-elements">elements</code> given in
2895    this specification.</p>
2896
2897   </div>
2898
2899   <p>When adding new <span title="reflect">reflecting</span> IDL attributes corresponding to content
2900   attributes of the form "<code title="">x-<var title="">vendor</var>-<var
2901   title="">feature</var></code>", the IDL attribute should be named "<code title=""><var
2902   title="">vendor</var><var title="">Feature</var></code>" (i.e. the "<code title="">x</code>" is
2903   dropped from the IDL attribute's name).</p>
2904
2905   </div>
2906
2907   <hr>
2908
2909   <p>When vendor-neutral extensions to this specification are needed, either this specification can
2910   be updated accordingly, or an extension specification can be written that overrides the
2911   requirements in this specification. When someone applying this specification to their&