Web Applications 1.0

Contexts in which this element may be used:: In a head element containing no other title elements.
Content model:: Text (for details, see prose).
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The title element represents the document's title or name. Authors should use titles that identify their documents even when they are used out of context, for example in a user's history or bookmarks, or in search results. The document's title is often different from its first header, since the first header does not have to stand alone when taken out of context.

Here are some examples of appropriate titles, contrasted with the top-level headers that might be used on those same pages.

  <title>Introduction to The Mating Rituals of Bees</title>
    ...
  <h1>Introduction</h1>
  <p>This companion guide to the highly successful
  <cite>Introduction to Medieval Bee-Keeping</cite> book is...

The next page might be a part of the same site. Note how the title describes the subject matter unambiguously, while the first header assumes the reader knowns what the context is and therefore won't wonder if the dances are Salsa or Waltz:

  <title>Dances used during bee mating rituals</title>
    ...
  <h1>The Dances</h1>

In HTML (as opposed to XHTML), the title element must not contain content other than text and entities; user agents parse the element so that entities are recognised and processed, but all other markup is interpreted as literal text.

In XHTML, the title element must not contain any elements.

User agents must concatenate the contents of all the text nodes and CDATA nodes that are direct children of the title element (ignoring any other nodes such as comments or elements), in tree order, to get the string to use as the document's title. User agents should use the document's title when referring to the document in their user interface.

2.5.3. The `base` element

Contexts in which this element may be used:

In a head element, before any elements that use relative URIs, and only if there are no other base elements anywhere in the document. Only in HTML documents (never in XML documents).

Content model:

Empty.

Element-specific attributes:

href

DOM interface:

interface HTMLBaseElement : HTMLElement {
           attribute DOMString href;
};

The base element allows authors to specify the document's base URI for the purposes of resolving relative URIs.

The href content attribute, if specified, must contain a URI (or IRI).

User agents must use the value of the href attribute on the first base element in the document as the document entity's base URI for the purposes of section 5.1.1 of RFC 2396 ("Establishing a Base URI": "Base URI within Document Content"). [RFC2396] Note that this base URI from RFC 2396 is referred to by the algorithm given in XML Base, which is a normative part of this specification.

If the base URI given by this attribute is a relative URI, it must be resolved relative to the higher-level base URIs (i.e. the base URI from the encapsulating entity or the URI used to retrieve the entity) to obtain an absolute base URI.

The href content attribute must be reflected by the DOM href attribute.

Authors must not use the base element in XML documents. Authors should instead use the xml:base attribute. [XMLBASE]

2.5.4. The `link` element

Contexts in which this element may be used:

In a head element.

Content model:

Empty.

Element-specific attributes:

href

rel

media

hreflang

type

Also, the title attribute has special semantics on this element.

DOM interface:

interface HTMLLinkElement : HTMLElement {
           attribute boolean disabled;
           attribute DOMString href;
           attribute DOMString rel;
           attribute DOMString media;
           attribute DOMString hreflang;
           attribute DOMString type;
};

The LinkStyle interface defined in DOM2 Style must also be implemented by this element. [DOM2STYLE]

The link element allows authors to indicate explicit relationships between their document and other resources.

The destination of the link is given by the href attribute, which must be a URI (or IRI). If the href attribute is absent, then the element does not define a link.

The type of link indicated (the relationship) is given by the value of the rel attribute. The allowed values and their meanings are defined in a later section. If the rel attribute is absent, or if the value used is not allowed according to the definitions in this specification, then the element does not define a link.

Two categories of links can be created using the link element. Links to external resources are links to resources that are to be used to augment the current document, and hyperlinks are links to other documents. The link types section defines whether a particular link type is an external resource or a hyperlink. One element can create multiple links (of which some might be external resource links and some might be hyperlinks). User agents should process the links on a per-link basis, not a per-element basis.

The exact behaviour for links to external resources depends on the exact relationship, as defined for the relevant link type. Some of the attributes control whether or not the external resource is to be applied (as defined below). For external resources that are represented in the DOM (for example, style sheets), the DOM representation must be made available even if the resource is not applied. (However, user agents may opt to only fetch such resources when they are needed, instead of pro-actively downloading all the external resources that are not applied.)

Interactive user agents should provide users with a means to follow the hyperlinks created using the link element, somewhere within their user interface. The exact interface is not defined by this specification, but it should include the following information (obtained from the element's attributes, again as defined below), in some form or another (possibly simplified), for each hyperlink created with each link element in the document:

The relationship between this document and the resource (given by the rel attribute)
The title of the resource (given by the title attribute).
The URI of the resource (given by the href attribute).
The language of the resource (given by the hreflang attribute).
The optimum media for the resource (given by the media attribute).

User agents may also include other information, such as the type of the resource (as given by the type attribute).

The media attribute says which media the resource applies to. The value must be a valid media query. [MQ]

If the link is a hyperlink then the media attribute is purely advisory, and describes for which media the document in question was designed.

However, if the link is an external resource link, then the media attribute is prescriptive. The user agent must only apply the external resource to views while their state match the listed media.

The default, if the media attribute is omitted, is all, meaning that by default links apply to all media.

The hreflang attribute gives the language of the linked resource. It is purely advisory. The value must be a valid RFC 3066 language code. RFC3066 User agents must not consider this attribute authoritative — upon fetching the resource, user agents must only use language information associated with the resource to determine its language, not metadata included in the link to the resource.

The type attribute gives the MIME type of the linked resource. It is purely advisory. The value must be a valid MIME type, optionally with parameters. [RFC2046]

For external resource links, user agents may use the type given in this attribute to decide whether or not to consider using the resource at all. If the UA does not support the given MIME type for the given link relationship, then the UA may opt not to download and apply the resource.

User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must only use the Content-Type information associated with the resource to determine its type, not metadata included in the link to the resource.

If the attribute is omitted, then the UA must fetch the resource to determine its type and thus determine if it supports (and can apply) that external resource.

If a document contains three style sheet links labelled as follows:

<link rel="stylesheet" href="A" type="text/css">
<link rel="stylesheet" href="B" type="text/plain">
<link rel="stylesheet" href="C">

...then a compliant UA that supported only CSS style sheets would fetch the A and C files, and skip the B file (since text/plain is not the MIME type for CSS style sheets). For these two files, it would then check the actual types returned by the UA. For those that are sent as text/css, it would apply the styles, but for those labelled as text/plain, or any other type, it would not.

The title attribute gives the title of the link. With one exception, it is purely advisory. The value is text. The exception is for style sheet links, where the title attribute defines alternate style sheet sets.

The title attribute on link elements differs from the global title attribute of most other elements in that a link without a title does not inherit the title of the parent element: it merely has no title.

Some versions of HTTP defined a Link: header, to be processed like a series of link elements. When processing links, those must be taken into consideration as well. For the purposes of ordering, links defined by HTTP headers must be assumed to come before any links in the document, in the order that they were given in the HTTP entity header. Relative URIs in these headers must be resolved according to the rules given in HTTP, not relative to base URIs set by the document (e.g. using a base element or xml:base attributes). [RFC2616] [RFC2068]

The DOM attributes href, rel, media, hreflang, and type each reflect the respective content attributes of the same name.

The DOM attribute disabled only applies to style sheet links. When the link element defines a style sheet link, then the disabled attribute behaves as defined for the alternate style sheets DOM. For all other link elements it must always return false and must do nothing on setting.

2.5.5. The `meta` element

Contexts in which this element may be used:

In a head element.

Content model:

Empty.

Element-specific attributes:

name

http-equiv (HTML only, optional)

content

DOM interface:

interface HTMLMetaElement : HTMLElement {
           attribute DOMString content;
           attribute DOMString name;
};

The meta element allows authors to specify document metadata that cannot be expressed using the title, base, link, style, and script elements. The metadata is expressed in terms of name/value pairs: the name attribute on the meta element gives the name, and the content attribute on the same element gives the value.

To set metadata with meta elements, authors must first specify a profile that defines metadata names, using the profile attribute. The value of the name attribute must be defined by one of the profiles, and the value of the content attribute must conform to the syntax given by the profile.

How user agents handle metadata set in this way depends on the definitions of the profiles involved.

If a meta element has no name attribute, it does not set document metadata. If a meta element has no content attribute, then the value part of the metadata name/value pair is the empty string.

The DOM attributes name and content reflect the respective content attributes of the same name.

2.5.5.1. Specifying and establishing the document's character encoding

The meta element may also be used, in HTML only (not in XHTML) to provide UAs with character encoding information for the file. To do this, the meta element must be the first element in the head element, it must have the http-equiv attribute set to the literal value Content-Type, and must have the content attribute set to the literal value text/html; charset= immediately followed by the character encoding, which must be a valid character encoding name. [IANACHARSET] When the meta element is used in this way, there must be no other attributes set on the element, and the http-equiv attribute must be listed first in the source. Other than for giving the document's character encoding in this way, the http-equiv attribute must not be used.

We should allow those strings to be case-insensitive, and for zero-or-more spaces where we currently require just one.

In XHTML, the XML declaration should be used for inline character encoding information, if necessary.

Authors should avoid including inline character encoding information. Character encoding information should instead be included at the transport level (e.g. using the HTTP Content-Type header).

2.5.6. The `style` element

Contexts in which this element may be used:

In a head element.

Content model:

Depends on the value of the type attribute.

Element-specific attributes:

type

media

Also, the title attribute has special semantics on this element.

DOM interface:

interface HTMLStyleElement : HTMLElement {
           attribute boolean disabled;
           attribute DOMString media;
           attribute DOMString type;
};

The LinkStyle interface defined in DOM2 Style must also be implemented by this element. [DOM2STYLE]

The style element allows authors to embed style information in their documents.

If the type attribute is given, it must contain a MIME type, optionally with parameters, that designates a styling language. [RFC2046] If the attribute is absent, the type defaults to text/css. [RFC2138]

If the UA supports the given styling language, then the UA must use the given styles as appropriate for that language.

When examining types to determine if they support the language, user agents must not ignore unknown MIME parameters — types with unknown parameters must be assumed to be unsupported.

The media attribute says which media the styles apply to. The value must be a valid media query. [MQ] User agents must only apply the styles to views while their state match the listed media.

The default, if the media attribute is omitted, is all, meaning that by default styles apply to all media.

The title attribute on style elements defines alternate style sheet sets. If the style element has no title attribute, then it has no title; the title attribute of ancestors does not apply to the style element.

The title attribute on style elements, like the title attribute on link elements, differs from the global title attribute in that a style block without a title does not inherit the title of the parent element: it merely has no title.

All descendant elements must be processed, according to their semantics, before the style element itself is evaluated. For styling languages that consist of pure text, user agents must evaluate style elements by passing the concatenation of the contents of all the text nodes and CDATA nodes that are direct children of the style element (not any other nodes such as comments or elements), in tree order, to the style system. For XML-based styling languages, user agents must pass all the children nodes of the style element to the style system.

This specification does not specify a style system, but CSS is expected to be supported by most Web browsers. [CSS21]

The DOM attributes media and type each reflect the respective content attributes of the same name.

The DOM disabled attribute behaves as defined for the alternate style sheets DOM.

2.6. Sections

Sectioning elements are elements that divide the page into, for lack of a better word, sections. This section describes HTML's sectioning elements and elements that support them.

Some elements are scoped to their nearest ancestor sectioning element. For example, address elements apply just to their section. For such elements x, the elements that apply to a sectioning element e are all the x elements whose nearest sectioning element is e.

2.6.1. The `body` element

Sectioning element.

Contexts in which this element may be used:: As the second element in an html element.
Content model:: Zero or more block-level elements.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The body element represents the main content of the document.

The body element potentially has a heading. See the section on headings and sections for further details.

Some DOM operations (for example, parts of the drag and drop model) are defined in terms of "the body element". See the definition of the document.body DOM attribute for details.

2.6.2. The `section` element

Contexts in which this element may be used:: Where block-level elements are expected.
Content model:: Zero or more block-level elements.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a header, possibly with a footer.

Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, contact information.

Each section element potentially has a heading. See the section on headings and sections for further details.

2.6.3. The `nav` element

Contexts in which this element may be used:: Where block-level elements are expected.
Content model:: Zero or more block-level elements, or inline-level content (but not both).
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

When used as an inline-level content container, the element represents a paragraph.

Each nav element potentially has a heading. See the section on headings and sections for further details.

2.6.4. The `article` element

Contexts in which this element may be used:: Where block-level elements are expected.
Content model:: Zero or more block-level elements.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.

An article element is "independent" in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well.

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a Web log entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the Web log entry.

Author information associated with an article element (q.v. the address element) does not apply to nested article elements.

Each article element potentially has a heading. See the section on headings and sections for further details.

2.6.5. The `blockquote` element

Sectioning block-level element, and structured inline-level element.

Contexts in which this element may be used:

Where block-level elements are expected.

Where structured inline-level elements are allowed.

Content model:

Zero or more block-level elements.

Element-specific attributes:

cite

DOM interface:

interface HTMLQuoteElement : HTMLElement {
           attribute DOMString cite;
};

The HTMLQuoteElement interface is also used by the q element.

The blockquote element represents a section that is quoted from another source.

Content inside a blockquote must be quoted from another source, whose URI, if it has one, should be cited in the cite attribute.

If the cite attribute is present, it must be a URI (or IRI). User agents should allow users to follow such citation links.

Each blockquote element potentially has a heading. See the section on headings and sections for further details.

The cite DOM attribute reflects the element's cite content attribte.

The blockquote element can be used with the ol and cite elements to mark up dialogue. This example demonstrates this using an extract from Abbot and Costello's famous sketch, Who's on first:

<ol>
 <li> <cite>Costello</cite>
      <blockquote> <p> Look, you gotta first baseman? </p> </blockquote>
 <li> <cite>Abbott</cite>
      <blockquote> <p> Certainly. </p> </blockquote>
 <li> <cite>Costello</cite>
      <blockquote> <p> Who's playing first? </p> </blockquote>
 <li> <cite>Abbott</cite>
      <blockquote> <p> That's right. </p> </blockquote>
 <li> <cite>Costello</cite>
      <blockquote> <p> When you pay off the first baseman every month, who gets the money? </p> </blockquote>
 <li> <cite>Abbott</cite>
      <blockquote> <p> Every dollar of it. </p> </blockquote>
</ol>

2.6.6. The `aside` element

Contexts in which this element may be used:: Where block-level elements are expected.
Content model:: Zero or more block-level elements, or inline-level content (but not both).
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

When used as an inline-level content container, the element represents a paragraph.

Each aside element potentially has a heading. See the section on headings and sections for further details.

2.6.7. The `h1`, `h2`, `h3`, `h4`, `h5`, and `h6` elements

Block-level elements.

Contexts in which these elements may be used:: Where block-level elements are expected.
Content model:: Significant strictly inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

These elements define headers for their sections.

The semantics and meaning of these elements are defined in the section on headings and sections.

These elements have a rank given by the number in their name. The h1 element is said to have the highest rank, the h6 element has the lowest rank, and two elements with the same name have equal rank.

These elements must not be empty.

2.6.8. The `header` element

Contexts in which this element may be used:: Where block-level elements are expected and there are no header ancestors.
Content model:: Zero or more block-level elements, including at least one descendant h1, h2, h3, h4, h5, or h6 element, but no sectioning element descendants, no header element descendants, and no footer element descendants.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The header element represents the header of a section. Headers may contain more than just the section's heading — for example it would be reasonable for the header to include version history information.

header elements must not contain any header elements, footer elements, or any sectioning elements (such as section) as descendants.

header elements must have at least one h1, h2, h3, h4, h5, or h6 element as a descendant.

For the purposes of document summaries, outlines, and the like, header elements are equivalent to the highest ranked h1-h6 element descendant (the first such element if there are multiple elements with that rank).

Other heading elements indicate subheadings or subtitles.

Here are some examples of valid headers. In each case, the emphasised text represents the text that would be used as the header in an application extracting header data and ignoring subheadings.

<header>
 <h1>The reality dysfunction</h1>
 <h2>Space is not the only void</h2>
</header>

<header>
 <p>Welcome to...</p>
 <h1>Voidwars!</h1>
</header>

<header>
 <h1>Scalable Vector Graphics (SVG) 1.2</h1>
 <h2>W3C Working Draft 27 October 2004</h2>
 <dl>
  <dt>This version:</dt>
  <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20041027/">http://www.w3.org/TR/2004/WD-SVG12-20041027/</a></dd>
  <dt>Previous version:</dt>
  <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20040510/">http://www.w3.org/TR/2004/WD-SVG12-20040510/</a></dd>
  <dt>Latest version of SVG 1.2:</dt>
  <dd><a href="http://www.w3.org/TR/SVG12/">http://www.w3.org/TR/SVG12/</a></dd>
  <dt>Latest SVG Recommendation:</dt>
  <dd><a href="http://www.w3.org/TR/SVG/">http://www.w3.org/TR/SVG/</a></dd>
  <dt>Editor:</dt>
  <dd>Dean Jackson, W3C, <a href="mailto:dean@w3.org">dean@w3.org</a>></dd>
  <dt>Authors:</dt>
  <dd>See <a href="#authors">Author List</a></dd>
 </dl>
 <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notic ...
</header>

The section on headings and sections defines how header elements are assigned to individual sections.

The rank of a header element is the same as for an h1 element (the highest rank).

Contexts in which this element may be used:: Where block-level elements are expected.
Content model:: Either zero or more block-level elements, but with no h1, h2, h3, h4, h5, h6, header, or footer elements as descendants, and with no sectioning elements as descendants; or, inline-level content (but not both).
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The footer element represents the footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

footer elements must not contain any footer, header, h1, h2, h3, h4, h5, or h6 elements, or any of the sectioning elements (such as section), as descendants.

When used as an inline-level content container, the element represents a paragraph.

Contact information for the section given in a footer should be marked up using the address element.

2.6.10. The `address` element

Contexts in which this element may be used:: Where block-level elements are expected.
Content model:: Inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The address element represents a paragraph of contact information for the section it applies to.

For example, a page at the W3C Web site related to HTML might include the following contact information:

<ADDRESS>
 <A href="../People/Raggett/">Dave Raggett</A>, 
 <A href="../People/Arnaud/">Arnaud Le Hors</A>, 
 contact persons for the <A href="Activity">W3C HTML Activity</A>
</ADDRESS>

The address element must not be used to represent arbitrary addresses (e.g. postal addresses), unless those addresses are contact information for the section. (The p element is the appropriate element for marking up such addresses.)

The address element must not contain information other than contact information.

For example, the following is non-conforming use of the address element:

<ADDRESS>Last Modified: 1999/12/24 23:37:50</ADDRESS>

Typically, the address element would be included with other information in a footer element.

To determine the contact information for a sectioning element (such as the body element, which would give the contact information for the page), UAs must collect all the address elements that apply to that sectioning element and its ancestor sectioning elements. The contact information is the collection of all the information given by those elements.

Contact information for one sectioning element, e.g. a aside element, does not apply to its ancestor elements, e.g. the page's body.

2.6.11. Headings and sections

The h1-h6 elements and the header element are headings.

The first heading in a sectioning element gives the header for that section. Subsequent headers of equal or higher rank start new (implied) sections, headers of lower rank start subsections that are part of the previous one.

Sectioning elements other than blockquote are always considered subsections of their nearest ancestor sectioning element, regardless of what implied sections other headings may have created. However, blockquote elements are associated with implied sections. Effectively, blockquote elements act like sections on the inside, and act opaquely on the outside.

For the following fragment:

<body>
 <h1>Foo</h1>
 <h2>Bar</h2>
 <blockquote>
  <h3>Bla</h3>
 </blockquote>
 <p>Baz</p>
 <h2>Quux</h2>
 <section>
  <h3>Thud</h3>
 </section>
 <p>Grunt</p>
</body>

...the structure would be:

Foo (heading of explicit body section)
1. Bar (heading starting implied section)
  1. Bla (heading of explicit blockquote section)
  Baz (paragraph)
2. Quux (heading starting implied section)
3. Thud (heading of explicit section section)
Grunt (paragraph)

Notice how the blockquote nests inside an implicit section while the section does not (and in fact, ends the earlier implicit section so that a later paragraph is back at the top level).

Sections may contain headers of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level.

Authors are also encouraged to explictly wrap sections in sectioning elements, instead of relying on the implicit sections generated by having multiple heading in one sectioning element.

For example, the following is correct:

<body>
 <h4>Apples</h4>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <h6>Sweet</h6>
  <p>Red apples are sweeter than green ones.</p>
  <h1>Colour</h1>
  <p>Apples come in various colours.</p>
 </section>
</body>

However, the same document would be more clearly expressed as:

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Colour</h2>
  <p>Apples come in various colours.</p>
 </section>
</body>

Both of the documents above are semantically identical and would produce the same outline in compliant user agents.

2.6.11.1. Creating an outline

HTML documents can be viewed as a tree of sections, which defines how each element in the tree is semantically related to the others, in terms of the overall section structure. This tree is related to the document tree, but there is not a one-to-one relationship between elements in the DOM and the document's sections.

The tree of sections should be used when generating document outlines, for example when generating tables of contents.

To derive the tree of sections from the document tree, a hypothetical tree is used, consisting of a view of the document tree containing only the h1-h6 and header elements, and the sectioning elements other than blockquote. Descendants of h1-h6, header, and blockquote elements must be removed from this view.

The hypothetical tree must be rooted at the root element or at a sectioning element. In particular, while the sections inside blockquotes do not contribute to the document's tree of sections, blockquotes can have outlines of their own.

UAs must take this hypothetical tree (which will become the outline) and mutate it by walking it depth first in tree order and, for each h1-h6 or header element that is not the first element of its parent sectioning element, inserting a new sectioning element, as follows:

If the element is a header element, or if it is an h1-h6 node of rank equal to or higher than the first element in the parent sectioning element (assuming that is also an h1-h6 node), or if the first element of the parent sectioning element is a sectioning element:: Insert the new sectioning element as the immediately following sibling of the parent sectioning element, and move all the elements from the current heading element up to the end of the parent sectioning element into the new sectioning element.
Otherwise:: Move the current heading element, and all subsequent siblings up to but excluding the next sectioning element, header element, or h1-h6 of equal or higher rank, whichever comes first, into the new sectioning element, then insert the new sectioning element where the current header was.

The outline is then the resulting hypothetical tree. The ranks of the headers become irrelevant at this point: each sectioning element in the hypothetical tree contains either no or one heading element child. If there is one, then it gives the section's heading, of there isn't, the section has no heading.

Sections are nested as in the hypothetical tree. If a sectioning element is a child of another, that means it is a subsection of that other section.

When creating an interactive table of contents, entries should jump the user to the relevant section element, if it was a real element in the original document, or to the heading, if the section element was one of those created during the above process.

Selecting the first section of the document therefore always takes the user to the top of the document, regardless of where the first header in the body is to be found.

The hypothetical tree (before mutations) could be generated by creating a TreeWalker with the following NodeFilter (described here as an anonymous ECMAScript function). [DOMTR] [ECMA262]

function (n) {
  // This implementation only knows about HTML elements.
  // An implementation that supports other languages might be
  // different.

  // Reject anything that isn't an element.
  if (n.nodeType != Node.ELEMENT_NODE)
    return NodeFilter.FILTER_REJECT;

  // Skip any descendants of headings.
  if (n.parentNode && n.parentNode.namespaceURI == 'http://www.w3.org/1999/xhtml') &&
      (n.parentNode.localName == 'h1' || n.parentNode.localName == 'h2' ||
       n.parentNode.localName == 'h3' || n.parentNode.localName == 'h4' ||
       n.parentNode.localName == 'h5' || n.parentNode.localName == 'h6' ||
       n.parentNode.localName == 'header')
    return NodeFilter.FILTER_REJECT;

  // Skip any blockquotes.
  if (n.namespaceURI == 'http://www.w3.org/1999/xhtml') &&
      (n.localName == 'blockquote'))
    return NodeFilter.FILTER_REJECT;

  // Accept HTML elements in the list given in the prose above.
  if ((n.namespaceURI == 'http://www.w3.org/1999/xhtml') &&
      (n.localName == 'body' || /*n.localName == 'blockquote' ||*/
       n.localName == 'section' || n.localName == 'nav' ||
       n.localName == 'article' || n.localName == 'aside' ||
       n.localName == 'h1' || n.localName == 'h2' ||
       n.localName == 'h3' || n.localName == 'h4' ||
       n.localName == 'h5' || n.localName == 'h6' ||
       n.localName == 'header'))
    return NodeFilter.FILTER_ACCEPT;

  // Skip the rest.
  return NodeFilter.FILTER_SKIP;
}

2.6.11.2. Determining which heading and section applies to a particular node

Given a particular node, user agents must use the following algorithm, in the given order, to determine which heading and section the node is most closely associated with. The processing of this algorithm must stop as soon as the associated section and heading are established (even if they are established to be nothing).

If the node has an ancestor that is a header element, then the associated heading is the most distant such ancestor. The associated section is that header's associated section (i.e. repeat this algorithm for that header).
If the node has an ancestor that is an h1-h6 element, then the associated heading is the most distant such ancestor. The associated section is that heading's section (i.e. repeat this algorithm for that heading element).
If the node is an h1-h6 element or a header element, then the associated heading is the element itself. The UA must then generate the hypothetical section tree described in the previous section, rooted at the nearest section ancestor (or the root element if there is no such ancestor). If the parent of the heading in that hypothetical tree is an element in the real document tree, then that element is the associated section. Otherwise, there is no associated section element.
If the node is a sectioning element, then the associated section is itself. The UA must then generate the hypothetical section tree described in the previous section, rooted at the section itself. If the section element, in that hypothetical tree, has a child element that is an h1-h6 element or a header element, then that element is the associated heading. Otherwise, there is no associated heading element.
If the node is a footer or address element, then the associated section is the nearest ancestor sectioning element, if there is one. The node's associated heading is the same as that sectioning element's associated heading (i.e. repeat this algorithm for that sectioning element). If there is no ancestor sectioning element, the element has no associated section nor an associated heading.
Otherwise, the node is just a normal node, and the document has to be examined more closely to determine its section and heading. Create a view rooted at the nearest ancestor sectioning element (or the root element if there is none) that has just h1-h6 elements, header elements, the node itself, and sectioning elements other than blockquote elements. (Descendants of any of the nodes in this view can be ignored, as can any node later in the tree than the node in question, as the algorithm below merely walks backwards up this view.)
Let n be an iterator for this view, initialised at the node in question.
Let c be the current best candidate heading, initially null, and initially not used. It is used when top-level heading candidates are to be searched for (see below).
Repeat these steps (which effectively goes backwards through the node's previous siblings) until an answer is found:
1. If n points to a node with no previous sibling, and c is null, then return the node's parent node as the answer. If the node has no parent node, return null as the answer.
2. Otherwise, if n points to a node with no previous sibling, return c as the answer.
3. Adjust n so that it points to the previous sibling of the current position.
4. If n is pointing at an h1 or header element, then return that element as the answer.
5. If n is pointing at an h2-h6 element, and heading candidates are not being searched for, then return that element as the answer.
6. Otherwise, if n is pointing at an h2-h6 element, and either c is still null, or c is a heading of lower rank than this one, then set c to be this element, and continue going backwards through the previous siblings.
7. If n is pointing at a sectioning element, then from this point on top-level heading candidates are being searched for. (Specifically, we are looking for the nearest top-level header for the current section.) Continue going backwards through the previous siblings.
If the answer from the previous step (the loop) is null, which can only happen if the node has no preceeding headings and is not contained in a sectioning element, then there is no associated heading and no associated section.
Otherwise, if the answer from the earlier loop step is a sectioning element, then the associated section is that element and the associated heading is that sectioning element's associated heading (i.e. repeat this algorithm for that section).
Otherwise, if the answer from that same earlier step is an h1-h6 element or a header element, then the associated heading is that element and the associated section is that heading element's associated section (i.e. repeat this algorithm for that heading).

Not all nodes have an associated header or section. For example, if a section is implied, as when multiple headers are found in one sectioning element, then a node in that section has an anonymous associated section (its section is not represented by a real element), and the algorithm above does not associate that node with any particular sectioning element.

For the following fragment:

<body>
 <h1>X</h1>
 <h2>X</h2>
 <blockquote>
  <h3>X</h3>
 </blockquote>
 <p id="a">X</p>
 <h4>Text Node A</h4>
 <section>
  <h5>X</h5>
 </section>
 <p>Text Node B</p>
</body>

The associations are as follows (not all associations are shown):

Node	Associated heading	Associated section
`<body>`	`<h1>`	`<body>`
`<h1>`	`<h1>`	`<body>`
`<h2>`	`<h2>`	None.
`<blockquote>`	`<h2>`	None.
`<h3>`	`<h3>`	`<blockquote>`
`<p id="a">`	`<h2>`	None.
`Text Node A`	`<h4>`	None.
`Text Node B`	`<h1>`	`<body>`

2.7. Paragraphs

A paragraph is typically a block of text with one or more sentences that discuss a particular topic, as in typography, but can also be used for more general thematic grouping. For instance, an address is also a paragraph, as is a part of a form, a byline, or a stanza in a poem.

Paragraphs can be represented by several elements. The address element always represents a paragraph of contact information for its section, the aside, nav, footer, li, and dd elements represent paragraphs with various specific semantics when they are used as inline-level content containers, and the p element represents all the other kinds of paragraphs, for which there are no dedicated elements.

2.7.1. The `p` element

Interactive, strictly inline-level content.

Contexts in which this element may be used:: Where block-level elements are expected.
Content model:: Significant inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The p element represents a paragraph.

p elements can contain a mixture of strictly inline-level content, such as text, images, hyperlinks, etc, and structured inline-level elements, such as lists, tables, and block quotes. p elements must not be empty.

The following examples are conforming HTML fragments:

<p>The little kitten gently seated himself on a piece of
carpet. Later in his life, this would be referred to as the time the
cat sat on the mat.</p>

<fieldset>
 <legend>Personal information</legend>
 <p>
   <label>Name: <input name="n"></label>
   <label><input name="anon" type="checkbox"> Hide from other users</label>
 </p>
 <p><label>Address: <textarea name="a"></textarea></label></p>
</fieldset>

<p>There was once an example from Femley,<br>
Whose markup was of dubious quality.<br>
The validator complained,<br>
So the author was pained,<br>
To move the error from the markup to the rhyming.</p>

The p element should not be used when a more specific element is more appropriate.

The following example is technically correct:

<section>
 <!-- ... -->
 <p>Last modified: 2001-04-23</p>
 <p>Author: fred@example.com</p>
</section>

However, it would be better marked-up as:

<section>
 <!-- ... -->
 <footer>Last modified: 2001-04-23</footer>
 <address>Author: fred@example.com</address>
</section>

Or:

<section>
 <!-- ... -->
 <footer>
  <p>Last modified: 2001-04-23</p>
  <address>Author: fred@example.com</address>
 </footer>
</section>

2.7.2. The `hr` element [TBW]

thematic separator. break. transition. hinge realignment. reconstruction, refinement, remodeling, reversal, revision, revolution. Maybe an 'html respite' or a 'hypertext rest'? .

2.8. Preformatted text

2.8.1. The `pre` element

Block-level element, and structured inline-level element.

Contexts in which this element may be used:: Where block-level elements are expected.; Where structured inline-level elements are allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The pre element represents a block of preformatted text, in which structure is represented by typographic conventions rather than by elements.

Some examples of cases where the pre element could be used:

Including an e-mail, with paragraphs indicated by blank lines, lists indicated by lines prefixed with a bullet, and so on.
Including fragments of computer code, with structure indicated according to the conventions of that language.
Displaying ASCII art.

If, ignoring text nodes consisting only of white space, the only child of a pre is a code element, then the pre element represents a block of computer code.

If, ignoring text nodes consisting only of white space, the only child of a pre is a samp element, then the pre element represents a block of computer output.

2.9. Lists

2.9.1. The `ol` element

Block-level element, and structured inline-level element.

Contexts in which this element may be used:

Where block-level elements are expected.

Where structured inline-level elements are allowed.

Content model:

Zero or more li elements.

Element-specific attributes:

start

DOM interface:

interface HTMLOListElement : HTMLElement {
           attribute long start;
};

The ol element represents an ordered list of items (which are represented by li elements).

The start attribute, if present, must have a value that consists of an optional U+002D HYPHEN-MINUS followed by one or more digits (U+0030 to U+0039) expressing a base ten integer giving the ordinal value of the first list item.

If the start attribute is present, user agents must convert the value to a numeric type, truncating any fractional part, in order to determine the attribute's value. The default value, used if the attribute is missing or if the value cannot be converted to a number according to the referenced algorithm, is 1.

The items of the list are the li element child nodes of the ol element, in tree order.

The first item in the list has the ordinal value given by the ol element's start attribute (unless it is further overridden by that li element's value attribute).

Each subsequent item in the list has the ordinal value given by its value attribute, if it has one, or, if it doesn't, the ordinal value of the previous item, plus one.

The start DOM attribute must reflect the value of the start content attribute.

2.9.2. The `ul` element

Block-level element, and structured inline-level element.

Contexts in which this element may be used:: Where block-level elements are expected.; Where structured inline-level elements are allowed.
Content model:: Zero or more li elements.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The ul element represents an unordered list of items (which are represented by li elements).

The items of the list are the li element child nodes of the ul element.

2.9.3. The `li` element

Contexts in which this element may be used:

Inside ol elements.

Inside ul elements.

Inside menu elements.

Content model:

When the element is a child of an ol or ul element and the grandchild of an element that is being used as an inline-level content container, or, when the element is a child of a menu element: inline-level content.

Otherwise: zero or more block-level elements, or inline-level content (but not both).

Element-specific attributes:

If the element is a child of an ol element: value

If the element is not the child of an ol element: None.

DOM interface:

interface HTMLLIElement : HTMLElement {
           attribute long value;
};

The li element represents a list item. If its parent element is an ol, ul, or menu element, then the element is an item of the parent element's list, as defined for those elements. Otherwise, the list item has no defined list-related relationship to any other li element.

When the list item is the child of an ol or ul element, the content model of the item depends on the way that parent element was used. If it was used as structured inline content (i.e. if that element's parent was used as an inline-level content container), then the li element must only contain inline-level content. Otherwise, the element may be used either for inline content or block-level elements.

When the list item is the child of a menu element, the li element must contain only inline-level content.

When the list item is not the child of an ol, ul, or menu element, e.g. because it is an orphaned node not in the document, it may contain either for inline content or block-level elements.

When used as an inline-level content container, the list item represents a single paragraph.

The value attribute, if present, must have a value that consists of an optional U+002D HYPHEN-MINUS followed by one or more digits (U+0030 to U+0039) expressing a base ten integer giving the ordinal value of the first list item.

If the value attribute is present, user agents must convert the value to a numeric type, truncating any fractional part, in order to determine the attribute's value. If the attribute's value cannot be converted to a number, it is treated as if the attribute was absent. The attribute has no default value.

The value attribute is processed relative to the element's parent ol element, if there is one. If there is not, the attribute has no effect.

The value DOM attribute must reflect the value of the value content attribute.

2.9.4. The `dl` element

Block-level element, and structured inline-level element.

Contexts in which this element may be used:: Where block-level elements are expected.; Where structured inline-level elements are allowed.
Content model:: Zero or more groups each consisting of one or more dt elements followed by one or mode dd elements.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The dl element introduces an unordered association list consisting of zero or more name-value groups. Each group must consist of one or more names (dt elements) followed by one or more values (dd elements).

Name-value groups may be terms and definitions, metadata topics and values, or any other groups of name-value data.

The following are all conforming HTML fragments.

In the following example, one entry ("Authors") is linked to two values ("John" and "Luke").

<dl>
 <dt> Authors
 <dd> John
 <dd> Luke
 <dt> Editor
 <dd> Frank
</dl>

In the following example, one definition is linked to two terms.

<dl>
 <dt lang="en-US"> <dfn>color</dfn> </dt>
 <dt lang="en-GB"> <dfn>colour</dfn> </dt>
 <dd> A sensation which (in humans) derives from the ability of
 the fine structure of the eye to distinguish three differently
 filtered analyses of a view. </dd>
</dl>

The following example illustrates the use of the dl element to mark up metadata of sorts. At the end of the example, one group has two metadata labels ("Authors" and "Editors") and two values ("Robert Rothman" and "Daniel Jackson").

<dl>
 <dt> Last modified time </dt>
 <dd> 2004-12-23T23:33Z </dd>
 <dt> Recommended update interval </dt>
 <dd> 60s </dd>
 <dt> Authors </dt>
 <dt> Editors </dt>
 <dd> Robert Rothman </dd>
 <dd> Daniel Jackson </dd>
</dl>

If a dl element is empty, it contains no groups.

If a dl element contains non-whitespace text nodes, or elements other than dt and dd, then those elements or text nodes do not form part of any groups in that dl, and the document is non-conforming.

If a dl element contains only dt elements, then it consists of one group with names but no values, and the document is non-conforming.

If a dl element contains only dd elements, then it consists of one group with values but no names, and the document is non-conforming.

The dl element is inappropriate for marking up dialogue, since dialogue is ordered (each speaker/line pair comes after the next). For an example of how to mark up dialogue, see the blockquote element.

2.9.5. The `dt` element

Contexts in which this element may be used:: Before dd elements inside dl elements.
Content model:: Strictly inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The dt element represents the term, or name, part of a name-value group in a dl element.

The dt element itself does not indicate that its contents are a term being defined, but this can be indicated using the dfn element.

2.9.6. The `dd` element

Contexts in which this element may be used:: After dt elements inside dl elements.
Content model:: When the element is a child of a dl element and the grandchild of an element that is being used as an inline-level content container: inline-level content.; Otherwise: zero or more block-level elements, or inline-level content (but not both).
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The dd element represents the definition, or value, part of a name-value group in a dl element.

The content model of a dd element depends on the way its parent element is being used. If the parent element is a dl element that is being used as structured inline content (i.e. if the dl element's parent element is being used as an inline-level content container), then the dd element must only contain inline-level content.

Otherwise, the element may be used either for inline content or block-level elements.

2.10. Phrase elements

2.10.1. The `a` element

Contexts in which this element may be used:

Where strictly inline-level content is allowed, if there are no ancestor interactive elements.

Content model:

When used in an element whose content model is only strictly inline-level content: only significant strictly inline-level content, but there must be no interactive descendants.

Otherwise: any significant inline-level content, but there must be no interactive descendants.

Element-specific attributes:

href

rel

media

hreflang

type

ping

DOM interface:

interface HTMLAnchorElement : HTMLElement {
           attribute DOMString href;
           attribute DOMString rel;
           attribute DOMString media;
           attribute DOMString hreflang;
           attribute DOMString type;
           attribute DOMString ping;
};

The Command interface must also be implemented by this element.

If the a element has an href attribute, then it represents a hyperlink.

If the a element has no href attribute, then the element is a placeholder for where a link might otherwise have been placed, if it had been relevant.

If a site uses a consistent navigation toolbar on every page, then the link that would normally link to the page itself could be marked up using an a element:

<nav>
 <ul>
  <li> <a href="/">Home</a> </li>
  <li> <a href="/news">News</a> </li>
  <li> <a>Examples</a> </li>
  <li> <a href="/legal">Legal</a> </li>
 </ul>
</nav>

The href attribute, if present, must have a value that is a URI (or IRI).

The relationship between the document containing the hyperlink and the destination resource indicated by the hyperlink is given by the value of the rel attribute. The allowed values and their meanings are defined in a later section. The rel attribute has no default value. If the attribute is omitted or if none of the values in the attribute are recognised by the UA, then the document has no particular relationship with the destination resource other than there being a hyperlink between the two.

Interactive user agents should allow users to follow hyperlinks created using the a element. The rel, media, hreflang, and type attributes may be used to indicate to the user the likely nature of the target resource.

The media attribute describes for which media the target document was designed. It is purely advisory. The value must be a valid media query. [MQ] The default, if the media attribute is omitted or has an invalid value, is all.

The hreflang attribute, if present, gives the language of the linked resource. It is purely advisory. The value must be a valid RFC 3066 language code. RFC3066 User agents must not consider this attribute authoritative — upon fetching the resource, user agents must only use language information associated with the resource to determine its language, not metadata included in the link to the resource.

The type attribute, if present, gives the MIME type of the linked resource. It is purely advisory. The value must be a valid MIME type, optionally with parameters. [RFC2046] User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must only use the Content-Type information associated with the resource to determine its type, not metadata included in the link to the resource.

The ping attribute, if present, gives the URIs of the resources that are interested in being notified if the user follows the hyperlink. The value must be a space separated list of one or more URIs.

If the element has an href attribute and a ping attribute and the user follows the hyperlink, the user agent should take the ping attribute's value, strip leading and trailing spaces (U+0020), split the value on sequences of spaces, treat each resulting part as a URI (resolving relative URIs according to element's base URI) and then send a request to each of the resulting URIs. This may be done in parallel with the primary request, and is independent of the result of that request.

User agents should allow the user to adjust this behaviour, for example in conjunction with a setting that disables the sending of HTTP Referrer headers. Based on the user's preferences, UAs may either ignore the ping attribute altogether, or selectively ignore URIs in the list (e.g. ignoring any third-party URIs).

For URIs that are HTTP URIs, the requests must be performed using the POST method (with an empty entity body in the request). User agents must ignore any entity bodies returned in the responses, but must, unless otherwise specified by the user, honour the HTTP headers — in particular, HTTP cookie headers. [RFC2965]

To save bandwidth, implementors might wish to consider omitting optional headers such as Accept from these requests.

When the ping attribute is present, user agents should clearly indicate to the user that following the hyperlink will also cause secondary requests to be sent in the background, possibly including listing the actual target URIs.

The ping attribute is redundant with pre-existing technologies like HTTP redirects and JavaScript in allowing Web pages to track which off-site links are most popular or allowing advertisers to track click-through rates.

However, the ping attribute provides these advantages to the user over those alternatives:

It allows the user to see the final target URI unobscured.
It allows the UA to inform the user about the out-of-band notifications.
It allows the paranoid user to disable the notifications without losing the underlying link functionality.
It allows the UA to optimise the use of available network bandwidth so that the target page loads faster.

Thus, while it is possible to track users without this feature, authors are encouraged to use the ping attribute so that the user agent can improve the user experience.

The a element must not be empty.

The DOM attributes href, rel, media, hreflang, type, and ping each reflect the respective content attributes of the same name.

2.10.2. The `q` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: When used in an element whose content model is only strictly inline-level content: only strictly inline-level content.; Otherwise: any inline-level content.
Element-specific attributes:: cite
DOM interface:: The q element uses the HTMLQuoteElement interface.

The q element represents a part of a paragraph quoted from another source.

Content inside a q element must be quoted from another source, whose URI, if it has one, should be cited in the cite attribute.

If the cite attribute is present, it must be a URI (or IRI). User agents should allow users to follow such citation links.

2.10.3. The `cite` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The cite element represents a citation: the source, or reference, for a quote or statement made in the document.

A citation is not a quote (for which the q element is appropriate).

This is incorrect usage:

<p><cite>This is wrong!</cite>, said Ian.</p>

This is the correct way to do it:

<p><q>This is correct!</q>, said <cite>Ian</cite>.</p>

This is also wrong, because the title and the name are not references or citations:

<p>My favourite book is <cite>The Reality Dysfunction</cite>
by <cite>Peter F. Hamilton</cite>.</p>

2.10.4. The `em` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: When used in an element whose content model is only strictly inline-level content: only strictly inline-level content.; Otherwise: any inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The em element represents stress emphasis of its contents.

The level of emphasis that a particlar piece of content has is given by its number of ancestor em elements.

The placement of emphasis changes the meaning of the sentence. The element thus forms an integral part of the content. The precise way in which emphasis is used in this way depends on the language.

These examples show how changing the emphasis changes the meaning. First, a general statement of fact, with no emphasis:

<p>Cats are cute animals.</p>

By emphasising the first word, the statement implies that the kind of animal under discussion is in question (maybe someone is asserting that dogs are cute):

<p><em>Cats</em> are cute animals.</p>

Moving the emphasis to the verb, one highlights that the truth of the entire sentence is in question (maybe someone is saying cats are not cute):

<p>Cats <em>are</em> cute animals.</p>

By moving it to the adjective, the exact nature of the the cats is reasserted (maybe someone suggested cats were mean animals):

<p>Cats are <em>cute</em> animals.</p>

Similarly, if someone asserted that cats were vegetables, someone correcting this might emphasise the last word:

<p>Cats are cute <em>animals</em>.</p>

By emphasising the entire sentence, it becomes clear that the speaker is fighting hard to get the point across. This kind of emphasis also typically affects the punctuation, hence the exclamation mark here.

<p><em>Cats are cute animals!</em></p>

Anger mixed with emphasising the cuteness could lead to markup such as:

<p><em>Cats are <em>cute</em> animals!</em></p>

2.10.5. The `strong` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: When used in an element whose content model is only strictly inline-level content: only strictly inline-level content.; Otherwise: any inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The strong element represents strong importance for its contents.

The relative level of importance of a piece of content is given by its number of ancestor strong elements; each strong element increases the importance of its contents.

Changing the importance of a piece of text with the strong element does not change the meaning of the sentence.

Here is an example of a warning notice in a game, with the various parts marked up according to how important they are:

<p><strong>Warning.</strong> This dungeon is dangerous.
<strong>Avoid the ducks.</strong> Take any gold you find.
<strong><strong>Do not take any of the diamonds</strong>,
they are explosive and <strong>will destroy anything within
ten meters.</strong></strong> You have been warned.</p>

2.10.6. The `small` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: When used in an element whose content model is only strictly inline-level content: only strictly inline-level content.; Otherwise: any inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The small element represents small print (part of a document often describing legal restrictions, such as copyrights or other disadvantages), or other side comments.

The small element does not "de-emphasise" or lower the importance of text emphasised by the em element or marked as important with the strong element.

In this example the footer contains contact information and a copyright.

<footer>
 <address>
  For more details, contact
  <a href="mailto:js@example.com">John Smith</a>.
 </address>
 <p><small>© copyright 2038 Example Corp.</small></p>
</footer>

In this second example, the small element is used for a side comment.

<p>Example Corp today announced record profits for the
second quarter <small>(Full Disclosure: Foo News is a subsidiary of
Example Corp)</small>, leading to speculation about a third quarter
merger with Demo Group.</p>

In this last example, the small element is marked as being important small print.

<p><strong><small>Continued use of this service will result in a kiss.</small></strong></p>

2.10.7. The `m` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: When used in an element whose content model is only strictly inline-level content: only strictly inline-level content.; Otherwise: any inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The m element represents a run of text marked or highlighted.

Should we just repurpose u or b for this semantic instead? What would they stand for?

In the following snippet, a paragraph of text refers to a specific part of a code fragment.

<p>The highlighted part below is where the error lies:</p>
<pre><code>var i: Integer;
begin
   i := <m>1.1</m>;
end.</code></pre>

Another example of the m element is highlighting parts of a document that are matching some search string. If someone looked at a document, and the server knew that the user was searching for the word "kitten", then the server might return the document with one paragraph modified as follows:

<p>I also have some <m>kitten</m>s who are visiting me
these days. They're really cute. I think they like my garden!</p>

2.10.8. The `dfn` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed, if there are no ancestor dfn elements.
Content model:: Strictly inline-level content, but there must be no descendant dfn elements.
Element-specific attributes:: None, but the title attribute has special semantics on this element.
DOM interface:: No difference from HTMLElement.

The dfn element represents the defining instance of a term. The paragraph, definition list group, or section that contains the dfn element contains the definition for the term given by the contents of the dfn element.

dfn elements must not be nested.

Defining term: If the dfn element has a title attribute, then the exact value of that attribute is the term being defined. Otherwise, if it contains exactly one element child node and no child text nodes, and that child element is an abbr element with a title attribute, then the exact value of that attribute is the term being defined. Otherwise, it is the exact textContent of the dfn element that gives the term being defined.

If the title attribute of the dfn element is present, then it must only contain the term being defined.

There must only be one dfn element per document for each term defined (i.e. there must not be any duplicate terms).

The title attribute of ancestor elements does not affect dfn elements.

The dfn element enables automatic cross-references. Specifically, any span, abbr, code, var, samp, or i element that has a non-empty title attribute whose value exactly equals the term of a dfn element in the same document, or which has no title attribute but whose textContent exactly equals the term of a dfn element in the document, and that has no interactive elements or dfn elements either as ancestors or descendants, and has no other elements as ancestors that are themselves matching these conditions, should be presented in such a way that the user can jump from the element to the first dfn element giving the defining instance of that term.

In the following fragment, the term "GDO" is first defined in the first paragraph, then used in the second. A compliant UA could provide a link from the abbr element in the second paragraph to the dfn element in the first.

<p>The <dfn><abbr title="Garage Door Opener">GDO</abbr></dfn>
is a device that allows off-world teams to open the iris.</p>
<!-- ... later in the document: -->
<p>Teal'c activated his <abbr title="Garage Door Opener">GDO</abbr>
and so Hammond ordered the iris to be opened.</p>

2.10.9. The `abbr` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: None, but the title attribute has special semantics on this element.
DOM interface:: No difference from HTMLElement.

The abbr element represents an abbreviation or acronym. The title attribute should be used to provide an expansion of the abbreviation. If present, the attribute must only contain an expansion of the abbreviation.

The paragraph below contains an abbreviation marked up with the abbr element.

<p>The <abbr title="Web Hypertext Application Technology
Working Group">WHATWG</abbr> is a loose unofficial collaboration of
Web browser manufacturers and interested parties who wish to develop
new technologies designed to allow authors to write and deploy
Applications over the World Wide Web.</p>

The title attribute may be omitted if there is a dfn element in the document whose defining term is the abbreviation (the textContent of the abbr element).

In the example below, the word "Zat" is used as an abbreviation in the second paragraph. The abbreviation is defined in the first, so the explanatory title attribute has been omitted. Because of the way dfn elements are defined, the second abbr element in this example would be connected (in some UA-specific way) to the first.

<p>The <dfn><abbr>Zat</abbr></dfn>, short for Zat'ni'catel, is a weapon.</p>
<p>Jack used a <abbr>Zat</abbr> to make the boxes of evidence disappear.</p>

2.10.10. The `i` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: None, but the title attribute has special semantics on this element when used with the dfn element.
DOM interface:: No difference from HTMLElement.

The i element represents an instance of the use of a term, such as a taxonomic designation, technical term, an idiomatic phrase from another language, or similar.

Terms in languages different from the main text should be annotated with lang attributes (xml:lang in XML).

The examples below show uses of the i element:

<p>The <i>felis silvestris catus</i> is cute.</p>
<p>The <i>block-level elements</i> are defined above.</p>
<p>There is a certain <i lang="fr">je ne sais quoi</i> in the air.</p>

The i element is not appropriate for marking up names (e.g. of people, or of ships).

actually maybe we shouldn't be stealing i's "semantics", it'll be confusing especially if we still let WYSYWIG authoring tools use it to mean italics...

2.10.11. The `t` element [WIP]

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: datetime
DOM interface:: No difference from HTMLElement.

The t element represents a date and/or a time.

...

2.10.12. The `meter` element

Contexts in which this element may be used:

Where strictly inline-level content is allowed.

Content model:

Element-specific attributes:

value

min

low

high

max

optimum

DOM interface:

interface HTMLMeterElement : HTMLElement {
           attribute long value;
           attribute long min;
           attribute long max;
           attribute long low;
           attribute long high;
           attribute long optimum;
};

The meter element represents a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate.

This is also known as a gauge.

The meter element should not be used to indicate progress (as in a progress bar). For that role, HTML provides a separate progress element.

There are six attributes that determine the semantics of the gauge represented by the element.

The min attribute specifies the lower bound of the range, and the max attribute specifies the upper bound. The value attribute specifies the value to have the gauge indicate as the "measured" value.

The other three attributes can be used to segment the gauge's range into "low", "medium", and "high" parts, and to indicate which part of the gauge is the "optimum" part. The low attribute specifies the range that is considered to be the "low" part, and the high attribute specifies the range that is considered to be the "high" part. The optimum attribute gives the position that is "optimum"; if that is higher than the "high" value then this indicates that the higher the value, the better; if it's lower than the "low" mark then it indicates that lower values are better, and naturally if it is in between then it indicates that neither high nor low values are good.

Authoring requirements: The recommended way of giving the value is to include it as contents of the element, either as two numbers (the higher number represents the maximum, the other number the current value), or as a percentage or similar (using one of the characters such as "%"), or as a fraction.

The value, min, low, high, max, and optimum attributes are all optional. When present, they must have values that are valid floating point numbers.

The following examples all represent a measurement of three quarters (of the maximum of whatever is being measured):

<meter>75%</meter>
<meter>750‰</meter>
<meter>3/4</meter>
<meter>6 blocks used (out of 8 total)</meter>
<meter>max: 100; current: 75</meter>
<meter><object data="graph75.png">0.75</object></meter>
<meter min="0" max="100" value="75"></meter>

User agent requirements: User agents must parse the min, max, value, low, high, and optimum attributes using the rules for parsing floating point number values.

If the value attribute has been omitted, the user agent must also process the textContent of the element according to the steps for finding one or two numbers in a string. These steps will return nothing, one number, one number with a denominator punctuation character, or two numbers.

User agents must then use all these numbers to obtain values for six points on the gauge, as follows. (The order in which these are evaluated is important, as some of the values refer to earlier ones.)

The minimum value

If the min attribute is specified and a value could be parsed out of it, then the minimum value is that value. Otherwise, the minimum value is zero.

The maximum value

If the max attribute is specified and a value could be parsed out of it, the maximum value is that value.

Otherwise, if the max attribute is specified but no value could be parsed out of it, or if it was not specified, but either or both of the min or value attributes were specified, then the maximum value is 1.

Otherwise, none of the max, min, and value attributes were specified. If the result of processing the textContent of the element was either nothing or just one number with no denominator punctuation character, then the maximum value is 1; if the result was one number but it had an associated denominator punctuation character, then the maximum value is the value associated with that denominator punctuation character; and finally, if there were two numbers parsed out of the textContent, then the maximum is the higher of those two numbers.

If the above machinations result in a maximum value less than the minimum value, then the maximum value is actually the same as the minimum value.

The actual value

If the value attribute is specified and a value could be parsed out of it, then that value is the actual value.

If the value attribute is not specified but the max attribute is specified and the result of processing the textContent of the element was one number with no associated denominator punctuation character, then that number is the actual value.

If neither of the value and max attributes are specified, then, if the result of processing the textContent of the element was one number (with or without an associated denominator punctuation character), then that is the actual value, and if the result of processing the textContent of the element was two numbers, then the actual value is the lower of the two numbers found.

Otherwise, if none of the above apply, the actual value is zero.

If the above procedure results in an actual value less than the minimum value, then the actual value is actually the same as the minimum value.

If, on the other hand, the result is an actual value greater than the maximum value, then the actual value is the maximum value.

The low boundary

If the low attribute is specified and a value could be parsed out of it, then the low boundary is that value. Otherwise, the low boundary is the same as the minimum value.

If the above results in a low boundary that is less than the minimum value, the low boundary is the minimum value.

The high boundary

If the high attribute is specified and a value could be parsed out of it, then the high boundary is that value. Otherwise, the high boundary is the same as the maximum value.

If the above results in a high boundary that is higher than the maximum value, the high boundary is the maximum value.

The optimum point

If the optimum attribute is specified and a value could be parsed out of it, then the optimum point is that value. Otherwise, the optimum point is the midpoint between the minimum value and the maximum value.

If the optimum point is then less than the minimum value, then the optimum point is actually the same as the minimum value. Similarly, if the optimum point is greater than the maximum value, then it is actually the maximum value instead.

All of which should result in the following inequalities all being true:

minimum value ≤ actual value ≤ maximum value
minimum value ≤ low boundary ≤ high boundary ≤ maximum value
minimum value ≤ optimum point ≤ maximum value

UA requirements for regions of the gauge: If the optimum point is equal to the low boundary or the high boundary, or anywhere in between them, then the region between the low and high boundaries of the gauge must be treated as the optimum region, and the low and high parts, if any, must be treated as suboptimal. Otherwise, if the optimum point is less than the low boundary, then the region between the minimum value and the low boundary must be treated as the optimum region, the region between the low boundary and the high boundary must be treated as a suboptimal region, and the region between the high boundary and the maximum value must be treated as an even less good region. Finally, if the optimum point is higher than the high boundary, then the situation is reversed; the region between the high boundary and the maximum value must be treated as the optimum region, the region between the high boundary and the low boundary must be treated as a suboptimal region, and the remaining region between the low boundary and the minimum value must be treated as an even less good region.

UA requirements for showing the gauge: When representing a meter element to the user, the UA should indicate the relative position of the actual value to the minimum and maximum values, and the relationship between the actual value and the three regions of the gauge.

The following markup:

<h3>Suggested groups</h3>
<menu type="toolbar">
 <a href="?cmd=hsg" onclick="hideSuggestedGroups()">Hide suggested groups</a>
</menu>
<ul>
 <li>
  <p><a href="/group/comp.infosystems.www.authoring.stylesheets/view">comp.infosystems.www.authoring.stylesheets</a> -
     <a href="/group/comp.infosystems.www.authoring.stylesheets/subscribe">join</a></p>
  <p>Group description: <strong>Layout/presentation on the WWW.</strong></p>
  <p><meter value="0.5">Moderate activity,</meter> Usenet, 618 subscribers</p>
 </li>
 <li>
  <p><a href="/group/netscape.public.mozilla.xpinstall/view">netscape.public.mozilla.xpinstall</a> -
     <a href="/group/netscape.public.mozilla.xpinstall/subscribe">join</a></p>
  <p>Group description: <strong>Mozilla XPInstall discussion.</strong></p>
  <p><meter value="0.25">Low activity,</meter> Usenet, 22 subscribers</p>
 </li>
 <li>
  <p><a href="/group/mozilla.dev.general/view">mozilla.dev.general</a> -
     <a href="/group/mozilla.dev.general/subscribe">join</a></p>
  <p><meter value="0.25">Low activity,</meter> Usenet, 66 subscribers</p>
 </li>
</ul>

Might be rendered as follows:

With the <meter> elements rendered as inline green bars of
varying lengths.

The min, max, value, low, high, and optimum DOM attributes must reflect the elements' content attributes of the same name. When the relevant content attributes are absent, the DOM attributes must return zero. The value parsed from the textContent never affects the DOM values.

Would be cool to have the value DOM attribute update the textContent in-line...

2.10.13. The `progress` element

Contexts in which this element may be used:

Where strictly inline-level content is allowed.

Content model:

Element-specific attributes:

value

max

DOM interface:

interface HTMLProgressElement : HTMLElement {
           attribute long value;
           attribute long max;
};

The progress element represents the completion progress of a task. The progress is either indeterminate, indicating that progress is being made but that it is not clear how much more work remains to be done before the task is complete (e.g. because the task is waiting for a remote host to respond), or the progress is a number in the range zero to a maximum, giving the fraction of work that has so far been completed.

There are two attributes that determine the current task completion represented by the element.

The value attribute specifies how much of the task has been completed, and the max attribute specifies how much work the task requires in total. The units are arbitrary and not specified.

Instead of using the attributes, authors are recommended to simply include the current value and the maximum value inline as text inside the element.

Here is a snippet of a Web application that shows the progress of some automated task:

<section>
 <h2>Task Progress</h2>
 <p><label>Progress: <progress><span id="p">0</span>%</progress></p>
 <script>
  var progressBar = document.getElementById('p');
  function updateProgress(newValue) {
    progressBar.textContent = newValue;
  }
 <</script>
</section>

(The updateProgress() method in this example would be called by some other code on the page to update the actual progress bar as the task progressed.)

Author requirements: The max and value attributes, when present, must have values that are valid floating point numbers.

User agent requirements: User agents must parse the max and value attributes according to the rules for parsing floating point number attribute values.

If the value attribute is omitted, then user agents must also parse the textContent of the progress element in question using the steps for finding one or two numbers in a string. These steps will return nothing, one number, one number with a denominator punctuation character, or two numbers.

Using the results of this processing, user agents must determine whether the progress bar is an indeterminate progress bar, or whether it is a determinate progress bar, and in the latter case, what its current and maximum values are, all as follows:

If the max attribute is omitted, and the value is omitted, and the results of parsing the textContent was nothing, then the progress bar is an indeterminate progress bar. Abort these steps.
Otherwise, it is a determinate progress bar.
If the max attribute is included, then, if a value could be parsed out of it, then the maximum value is that value.
Otherwise, if the max attribute is absent but the value attribute is present, or, if the max attribute is present but no value could be parsed from it, then the maximum is 1.
Otherwise, if neither attribute is included, then, if the textContent contained one number with an associated denominator punctuation character, then the maximum value is the value associated with that denominator punctuation character; otherwise, if the textContent contained two numbers, the maximum value is the higher of the two values; otherwise, the maximum value is 1.
If the value attribute is present on the element and a value could be parsed out of it, that value is the current value of the progress bar. Otherwise, if the attribute is present but no value could be parsed from it, the current value is zero.
Otherwise if the value attribute is absent and the max attribute is present, then, if the textContent was parsed and found to contain just one number, with no associated denominator punctuation character, then the current value is that number. Otherwise, if the value attribute is absent and the max attribute is present then the current value is zero.
Otherwise, if neither attribute is present, then the current value is the lower of the one or two numbers that were found in the textContent of the element.
Finally, if the maximum value is less than zero, then it is reset to 1, and if the current value is less than the maximum value, then it is reset to the maximum value.

UA requirements for showing the progress bar: When representing a progress element to the user, the UA should indicate whether it is a determinate or indeterminate progress bar, and in the former case, should indicate the relative position of the current value relative to the maximum value.

The max and value DOM attributes must reflect the elements' content attributes of the same name. When the relevant content attributes are absent, the DOM attributes must return zero. The value parsed from the textContent never affects the DOM values.

Would be cool to have the value DOM attribute update the textContent in-line...

2.10.14. The `code` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: When used in an element whose content model is only strictly inline-level content: only strictly inline-level content.; Otherwise: any inline-level content.
Element-specific attributes:: None, but the title attribute has special semantics on this element when used with the dfn element.
DOM interface:: No difference from HTMLElement.

The code element represents a fragment of computer code. This could be an XML element name, a filename, a computer program, or any other string that a computer would recognise.

See the pre element for more detais.

The following example shows how a block of code could be marked up using the pre and code elements.

<pre><code>var i: Integer;
begin
   i := 1;
end.</code></pre>

2.10.15. The `var` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: None, but the title attribute has special semantics on this element when used with the dfn element.
DOM interface:: No difference from HTMLElement.

The var element represents a variable. This could be an actual variable in a mathematical expression or programming context, or it could just be a term used as a placeholder in prose.

In the paragraph below, the letter "n" is being used as a variable in prose:

<p>If there are <var>n</var> pipes leading to the ice
cream factory then I expect at <em>least</em> <var>n</var>
flavours of ice cream to be available for purchase!</p>

2.10.16. The `samp` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: When used in an element whose content model is only strictly inline-level content: only strictly inline-level content.; Otherwise: any inline-level content.
Element-specific attributes:: None, but the title attribute has special semantics on this element when used with the dfn element.
DOM interface:: No difference from HTMLElement.

The samp element represents (sample) output from a program or computing system.

See the pre and kbd elements for more detais.

This example shows the samp element being used inline:

<p>The computer said <samp>Too much cheese in tray
two</samp> but I didn't know what that meant.</p>

This second example shows a block of sample output. Nested samp and kbd elements allow for the styling of specific elements of the sample output using a style sheet.

<pre><samp><samp class="prompt">jdoe@mowmow:~$</samp> <kbd>ssh demo.example.com</kbd>
Last login: Tue Apr 12 09:10:17 2005 from mowmow.example.com on pts/1
Linux demo 2.6.10-grsec+gg3+e+fhs6b+nfs+gr0501+++p3+c4a+gr2b-reslog-v6.189 #1 SMP Tue Feb 1 11:22:36 PST 2005 i686 unknown

<samp class="prompt">jdoe@demo:~$</samp> <samp class="cursor">_</samp></samp></pre>

2.10.17. The `kbd` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The kbd element represents user input (typically keyboard input, although it may also be used to represent other input, such as voice commands).

When the kbd element is nested inside a samp element, it represents the input as it was echoed by the system.

When the kbd element contains a samp element, it represents input based on system output, for example invoking a menu item.

When the kbd element is nested inside another kbd element, it represents an actual key or other single unit of input as appropriate for the input mechanism.

Here the kbd element is used to indicate keys to press:

<p>To make George eat an apple, press <kbd><kbd>Shift</kbd>+<kbd>F3</kbd></kbd></p>

In this second example, the user is told to pick a particular menu item. The outer kbd element marks up a block of input, with the inner kbd elements representing each individual step of the input, and the samp elements inside them indicating that the steps are input based on something being displayed by the system, in this case menu labels:

<p>To make George eat an apple, select
    <kbd><kbd><samp>File</samp></kbd>|<kbd><samp>Eat Apple...</samp></kbd></kbd>
</p>

2.10.18. The `sup` and `sub` elements

Contexts in which these elements may be used:: Where strictly inline-level content is allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The sup element represents a superscript and the sub element represents a subscript.

These elements must only be used to mark up typographical conventions with specific meanings, not for typographical presentation for presentation's sake. For example, it would be inappropriate for the sup and sub elements to be used in the name of the LaTeX document preparation system. In general, authors should not use these elements if the absence of those elements would not change the meaning of the content.

When the sub element is used inside a var element, it represents the subscript that identifies the variable in a family of variables.

<p>The coordinate of the <var>i</var>th point is
(<var>x<sub><var>i</var></sub></var>, <var>y<sub><var>i</var></sub></var>).
For example, the 10th point has coordinate
(<var>x<sub>10</sub></var>, <var>y<sub>10</sub></var>).</p>

In certain languages, superscripts are part of the typographical conventions for some abbreviations.

<p>The most beautiful women are
<span lang="fr"><abbr>M<sup>lle</sup></abbr> Gwendoline</span> and 
<span lang="fr"><abbr>M<sup>me</sup></abbr> Denise</span>.</p>

Mathematical expressions often use subscripts and superscripts. Authors are encouraged to use MathML for marking up mathematics, but authors may opt to use sub and sup if detailed mathematical markup is not desired. [MathML]

<var>E</var>=<var>m</var><var>c</var><sup>2</sup>

f(<var>x</var>, <var>n</var>) = log<sub>4</sub><var>x</var><sup><var>n</var></sup>

2.10.19. The `span` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: When used in an element whose content model is only strictly inline-level content: only strictly inline-level content.; Otherwise: any inline-level content.
Element-specific attributes:: None, but the title attribute has special semantics on this element when used with the dfn element.
DOM interface:: No difference from HTMLElement.

The span element doesn't mean anything on its own, but can be useful when used together with other attributes, e.g. lang or dir, or when used in conjunction with the dfn element.

Now that we have i, do we need span to work with dfn?

2.10.20. The `bdo` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: Strictly inline-level content.
Element-specific attributes:: None, but the dir global attribute is required on this element.
DOM interface:: No difference from HTMLElement.

The bdo element allows authors to override the Unicode bidi algorithm by explicitly specifying a direction override. [BIDI]

Authors must specify the dir attribute on this element, with the value ltr to specify a left-to-right override and with the value rtl to specify a right-to-left override.

If the element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element.

If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element.

The requirements on handling the bdo element for the bidi algorithm may be implemented indirectly through the style layer. For example, an HTML+CSS user agent should implement these requirements by implementing the CSS unicode-bidi property. [CSS21]

2.10.21. The `br` element

Contexts in which this element may be used:: Where strictly inline-level content is allowed.
Content model:: Empty.
Element-specific attributes:: None.
DOM interface:: No difference from HTMLElement.

The br element represents a line break.

br elements must be empty. Any content inside br elements must not be considered part of the surrounding text.

br elements must only be used for line breaks that are actually part of the content, as in poems or addresses.

The following example is correct usage of the br element:

<p>P. Sherman<br>
42 Wallaby Way<br>
Sydney</p>

br elements must not be used for separating thematic groups in a paragraph.

The following examples are non-conforming, as they abuse the br element:

<p><a ...>34 comments.</a><br>
<a ...>Add a comment.<a></p>

<p>Name: <input name="name"><br>
Address: <input name="address"></p>

Here are alternatives to the above, which are correct:

<p><a ...>34 comments.</a></p>
<p><a ...>Add a comment.<a></p>

<p>Name: <input name="name"></p>
<p>Address: <input name="address"></p>

2.11. Edits

The ins and del elements represent edits to the document.

2.11.1. The `ins` element

Block-level element, and strictly inline-level content.

Contexts in which this element may be used:: Where block-level elements is expected.; Where strictly inline-level content is allowed.
Content model:: When the element is a child of an element with only one content model (i.e. an element that only allows strictly inline-level content, or only allows inline-level content, or only allows block-level elements): same content model as the parent element.; Otherwise, when the element is a child of an element that only contains inter-element whitespace, ins elements, and del elements: same content model as the parent element, with the additional restriction that if the parent element allows a choice in content models (e.g. block or inline) then if all the children of all the sibling ins elements were placed directly in the parent element, the document would still be conforming.; Otherwise, when the element is a child of an element that is being used as an inline-level content container: inline-level content.; Otherwise, when the element is a child of an element that is being used as a block-level element container: block-level elements.; Otherwise: zero or more block-level elements, or inline-level content (but not both).
Element-specific attributes:: cite; datetime
DOM interface:: Uses the HTMLModElement interface.

The ins element represents an addition to the document.

The ins element must be used only where block-level elements or strictly inline-level content can be used.

An ins element must only contain content that would still be conformant if all ins elements were replaced by their contents.

The following would be syntactically legal:

<aside>
 <ins>
  <p>...</p>
 </ins>
</aside>

As would this:

<aside>
 <ins>
  <em>...</em>
 </ins>
</aside>

However, this last example would be illegal, as em and p cannot both be used inside an aside element at the same time:

<aside>
 <ins>
  <p>...</p>
 </ins>
 <ins>
  <em>...</em>
 </ins>
</aside>

2.11.2. The `del` element

Block-level element, and strictly inline-level content.

Contexts in which this element may be used:: Where block-level elements is expected.; Where strictly inline-level content is allowed.
Content model:: When the element has a parent: same content model as the parent element.; Otherwise: zero or more block-level elements, or inline-level content (but not both).
Element-specific attributes:: cite; datetime
DOM interface:: Uses the HTMLModElement interface.

The del element represents a removal from the document.

The del element must only contain content that would be allowed inside the parent element (regardless of what the parent element actually contains).

The following would be syntactically legal:

<aside>
 <del>
  <p>...</p>
 </del>
 <ins>
  <em>...</em>
 </ins>
</aside>

...even though the p and em elements would never be allowed side by side in the aside element. This is allowed because the del element represents content that was removed, and it is quite possible that an edit could cause an element to go from being an inline-level container to a block-level container, or vice-versa.

2.11.3. Attributes common to `ins` and `del` elements

The cite attribute may be used to specify a URI that explains the change. When that document is long, for instance the minutes of a meeting, authors are encouraged to include a fragment identifier pointing to the specific part of that document that discusses the change.

If the cite attribute is present, it must be a URI (or IRI) that explains the change. User agents should allow users to follow such citation links.

The datetime attribute may be used to specify the time and date of the change.

This next bit should be extracted to the "common microsyntaxes" section

If the datetime attribute is present, it must have a value consisting of four digits representing the year, a literal hyphen, two digits representing the month, a literal hyphen, two digits representing the day, a literal T, two digits for the hour, a colon, two digits for the minutes, another colon, two digits for the seconds, optionally a decimal point followed by one or more digits for the fraction of a second, and finally either a literal Z, or, a plus sign or a minus sign followed by two digits for the hour offset, a colon, and two digits for the minute offset.

In other words: YYYY-MM-DDThh:mm:ss.sTZ

Digits must be in the range 0-9 (U+0030 to U+0039), interpreted in base ten. The hyphen must be U+002D, the T must be U+0054, the colon must be U+003A, the Z must be U+005A, the plus must be U+002B, and the minus U+002D (same as the hyphen).

To interpret this value, user agents must first check to see if the value matches the pattern described here. If it does, then the values must be extracted and interpreted as a date and time with a timezone offset, as per ISO 8601. [ISO8601]

If the attribute value does not match the format, or, if the date or time given is not a valid date and time (e.g. because the month is out of range) then the user agent must ignore the attribute (the modification has no associated timestamp).

The ins and del elements must implement the HTMLModElement interface:

interface HTMLModElement : HTMLElement {
           attribute DOMString cite;
           attribute DOMString datetime;
};

The cite and datetime DOM attributes must reflect the elements' content attributes of the same name.

2.12. Embedded content [TBW]

2.12.1. The `img` element

Interactive, block-level element.

Contexts in which this element may be used:

Where strictly inline-level content is allowed.

Content model:

Empty.

Element-specific attributes:

src (required)

alt (required)

height

width

usemap

ismap

DOM interface:

interface HTMLImageElement : HTMLElement {
           attribute DOMString src;
           attribute DOMString alt;
           attribute long height;
           attribute long width;
           attribute boolean isMap;
           attribute DOMString useMap;
};

The img element represents a piece of text with an alternate graphical representation. The text is given by the alt attribute, and the URI to the graphical representation of that text is given by the src attribute.

This section is (obviously) incomplete.

The alt attribute on images must not be shown in a tooltip in visual browsers.

2.13. Tabular data [TBW]

This section will contain definitions of the table element and so forth.

2.14. Forms [TBW]

This section will contain definitions of the form element and so forth.

2.15. Scripting

2.15.1. The `script` element

Block-level element, strictly inline-level content, and metadata element.

Contexts in which this element may be used:

In a head element.

Where block-level elements are expected.

Where inline-level content is expected.

Content model:

If there is no src attribute, depends on the value of the type attribute.

If there is a src attribute, the element must be empty.

Element-specific attributes:

src

type

defer (if the src attribute is present)

async (if the src attribute is present)

DOM interface:

interface HTMLScriptElement : HTMLElement {
           attribute DOMString text;
           attribute DOMString src;
           attribute DOMString type;
           attribute boolean defer;
           attribute boolean async;
};

The script element allows authors to include dynamic script in their documents.

When the src attribute is set, the script element refers to an external file, which must (if it uses a supported scripting language) be downloaded and executed. The user agent must delay the execution of other scripts associated with the page that are invoked during the download (e.g. event handlers) until after the external script has been downloaded and executed.

The language of the script is given by the type attribute. The value must be a valid MIME type, optionally with parameters. [RFC2046]

For script elements that have the src attribute set, user agents may use the type given in this attribute to decide whether or not to consider using the resource at all. If the UA does not support the given MIME type as a scripting language, then the UA may opt not to download the script.

User agents must not consider the type attribute authoritative, however — upon fetching the script, user agents must only use the Content-Type information associated with it to determine whether or not to execute it; user agents must not use the type attribute in the document to determine the actual type of the script.

If the type attribute is omitted but the src attribute is set, then the UA must fetch the resource to determine its type and thus determine if it supports (and can execute) that external script.

If the src attribute is not set, then the script is given by the contents of the element. The language is given by the type attribute. If it is omitted, then the default is the ECMAScript MIME type.

When examining types to determine if they support the language, user agents must not ignore unknown MIME parameters — types with unknown parameters must be assumed to be unsupported.

User agents that support scripting must execute scripts (written in languages that they support) immediately upon parsing a script element's end tag, and immediately upon having a dynamically created script element inserted into the DOM. Once a script element has been executed, it must be flagged as such and never re-executed again. When an element with this flag set is cloned, the new element must not have the flag set.

For scripting languages that consist of pure text, user agents must use the value of the DOM text attribute (defined below) as the script to execute. For XML-based scripting languages, user agents must use all the children nodes of the script element as the script.

The DOM attributes src and type each reflect the respective content attributes of the same name.

The DOM attribute text must return a concatenation of the contents of all the text nodes and CDATA nodes that are direct children of the script element (ignoring any other nodes such as comments or elements), in tree order. On setting, it must act the same way as the textContent DOM attribute.

2.15.1.1. Script languages

The following lists some MIME types and the languages to which they refer:

text/javascript: ECMAScript. [ECMA262]
text/javascript;e4x=1: ECMAScript with ECMAScript for XML. [ECMA357]

2.15.2. The `noscript` element [TBW]

The noscript element needs to be defined too.

2.16. Other new elements [TBW]

all the new things in WA1: menu, calendar, card, canvas, switch, datagrid, datatree, switch, etc

2.17. Notes (draft sections to be moved elsewhere) [TBW]

2.17.1. Classes

This section may somehow introduce some predefined classes with actual semantic meanings; possibly by defining a profile.

2.17.2. Link types

This section might at some future point list a small set of link relationship types and more exactly define their semantics than HTML4. This section (or indeed this specification in general) is unlikely to specify anything related to the profile attribute and how to extend the link types in HTML. Work in this area is currently being done by GMPG and others.

2.17.3. Document sections

User agents must support all of the common attributes and event handlers on the section element, as well as the active attribute (for use with mutually exclusive sections).

In CSS-aware user agents, the default presentation of this element should be achieved by including the following rules, or their equivalent, in the UA's user agent style sheet:

@namespace xh url(http://www.w3.org/1999/xhtml);
xh|section { display: block; margin: 1em 0; }

2.17.4. Section headers

For h1 elements, CSS-aware visual user agents should derive the size of the header from the level of section nesting. This effect should be achieved by including the following rules, or their equivalent, in the UA's user agent style sheet:

@namespace xh url(http://www.w3.org/1999/xhtml);
xh|section xh|h1 { /* same styles as h2 */ }
xh|section xh|section xh|h1 { /* same styles as h4 */ }
xh|section xh|section xh|section xh|h1 { /* same styles as h4 */ }
xh|section xh|section xh|section xh|section xh|h1 { /* same styles as h5 */ }
xh|section xh|section xh|section xh|section xh|section xh|h1 { /* same styles as h6 */ }

Authors should use h1 elements to denote headers in sections. Authors may instead use h2 ... h6 elements, for backwards compatibility with user agents that do not support section elements.

2.17.5. Section groups (tabs)

This section should probably die.

A group of related, order-neutral sections may be denoted using the tabbox element. The default presentation in a visual media (as described below) is to render each section as a separate tab in a tab box, allowing the user to switch between them. Sections can also be represented by links to other documents, instead of them being included literally in the markup.

The tabbox element is a block-level element that should only contain section, fieldset, and a elements.

Authors should only use a elements that cause the user agent to change the active page to a page with a similar structure. Other behaviours are likely to be highly confusing to users.

Each section, fieldset, and a child can have a title. If the element is a section element, then the title is taken from the title attribute of the element, if specified, or, if absent, from the textContent DOM attribute of the first element child of the section element, if that is an h1 ... h6 element. (If it is taken from a header child, then that child is hidden from the rendering.) If the element is a fieldset element, then the title is taken from the the textContent DOM attribute of the first element child of the fieldset element, if that is an legend element. If the element is an a element, then the title is taken from the textContent DOM attribute of the element. (Titles may be the empty string.)

The titles obtained in this way, and the section, fieldset, and a elements from which they were derived, represent the list of sections in the tabbox. This list is live, in that dynamic changes to the DOM immediately affect the representation of the tabbox element.

All the other child nodes of the tabbox shall be ignored for the purposes of rendering the tabbox. Authors may use this in order to obtain acceptable renderings even in UAs that do not support tabbox.

In CSS-aware user agents, the default presentation of the tabbox element should, in part, be achieved by including the following rules, or their equivalent, in the UA's user agent style sheet:

@namespace xh url(http://www.w3.org/1999/xhtml);
xh|tabbox { display: block; }
xh|tabbox > xh|section:not([title]) > xh|h1:first-child,
xh|tabbox > xh|section:not([title]) > xh|h2:first-child,
xh|tabbox > xh|section:not([title]) > xh|h3:first-child,
xh|tabbox > xh|section:not([title]) > xh|h4:first-child,
xh|tabbox > xh|section:not([title]) > xh|h5:first-child,
xh|tabbox > xh|section:not([title]) > xh|h6:first-child,
xh|tabbox > xh|fieldset > xh|legend:first-child { display: none; }

These rules do not come even close to fully describing the full behaviour of a tabbox element, however.

The behaviour of the tabbox should be to provide quick access to any of the children of the tabbox that have a title (as described above). UAs may keep track of which section is the selected section, and report this information to the user.

When the user specifies a section to access, the relevant element must have a click event dispatched to it, whose default action is to further dispatch a DOMActivate event to the element.

For section and fieldset elements, the default action of DOMActivate events is to display, or jump to, the relevant section. For a elements, the default action is the normal default action for a elements (activating the link, command, or whatever). In addition to these default actions, when a child of a tabbox is accessed, it becomes the selected section.

If the DOMActivate event is canceled (or if the click event is canceled, causing the DOMActivate event to never be fired in the first place), then the selected section does not change.

If an a element has a command attribute, it can be disabled. In such cases, the UA should not allow the user to select that section.

The initially selected section shall be the first element from the tabbox element's child list that is:

an a element whose href attribute matches the URI of the current document, if there is one,
otherwise, the first a element whose href attribute matches the URI given by the href attribute of the first link element in the document that has a rel attribute whose value contains the keyword up (treating that attribute as a space-separated list), if there is one,
otherwise, the first section or fieldset element that has a title, if there is one.

If no elements match, then initially no section shall be selected.

In the above algorithm, URI comparisons should be done after canonicalisation, and should ignore fragment identifiers unless the a element in question has one.

In non-interactive or non-spatial media (such as in print, on braille systems, or with speech synthesis) the UA may automatically switch the selected section to the next section once the selected section has been rendered.

Which section is selected if the element representing the currently selected section is dynamically removed from the document is up to the UA.

In interactive visual media, the tabbox element should be rendered as a tab box, with the section titles listed as the tabs, and the selected section (if it is a section or fieldset element) displayed in the tab panel area. When the selected section is an a element, the tab panel area should be empty.

This specification does not describe how CSS properties apply to tabbox elements when the UA uses this rendering, but the children rendered in the tab panel area must be styled using CSS, as if the tab panel area defined a new containing block and new block formatting context.

User agents must support all of the common attributes and event handlers on the tabbox element.

Here is an example of a tabbox used to allow the user to read three different parts of the document:

<tabbox>
 <section>
  <h2>About</h2>
  <p><img src="logo" alt=""></p>
  <p>The Application.</p>
  <p>© copyright 2004 by The First Team.</p>
 </section>
 <section>
  <h2>Credits</h2>
  <ul>
   <li>Jack O'Neill</li>
   <li>Samantha Carter</li>
   <li>Daniel Jackson</li>
   <li>Teal'c</li>
   <li>Jonas Quinn</li>
  </ul>
 </section>
</tabbox>

Next, an example of a form that has been split into little groups of controls:

<tabbox>
 <fieldset>
  <legend>Identity</legend>
  <p><label>First name: <input name="fn"></label></p>
  <p><label>Last name: <input name="ln"></label></p>
  <p><label>Date of Birth: <input name="dob" type="date"></label></p>
 </fieldset>
 <fieldset>
  <legend>Food</legend>
  <p><label>Favourite appetizer: <input name="fa"></label></p>
  <p><label>Favourite meal: <input name="fm"></label></p>
  <p><label>Favourite desert: <input name="fd"></label></p>
 </fieldset>
</tabbox>

Finally, an example of a page using a tabbox to point to sections outside the document. Note the use of fallback content (elements and text in the tabbox element that are not fieldset, section, or a elements) for backwards compatibility.

<div>
 <tabbox>
  <strong>Navigation:</strong>
  <a href="/"><span>Home</span></a>,
  <a href="/news/"><span>News</span></a>,
  <a href="/games/"><span>Games</span></a>,
  <a href="/help/"><span>Help</span></a>,
  <a href="/contact/"><span>Contact</span></a>.
 </tabbox>
</div>

This would be semantically equivalent to the following:

<tabbox>
 <section><h2>Home</h2> ...content... </section>
 <section><h2>News</h2> ...content... </section>
 <section><h2>Games</h2> ...content... </section>
 <section><h2>Help</h2> ...content... </section>
 <section><h2>Contact</h2> ...content... </section>
</tabbox>

2.17.6. Mutually exclusive sections

The switch element represents a block of mutually exclusive sections.

For example, in an application for an online mutiplayer game, there could be four mutually exclusive sections: one for the login page, one for the network status page displayed while the user is logging in, one for a "lobby" where players get together to organise a game, and one for the actual game. The different sections are the various states that the application can reach.

The switch element must contain only block-level elements. User agents must support all of the common attributes and event handlers on the switch element.

All child elements of a switch element shall be hidden except those that have active attributes (or, for non-XHTML elements, active attributes in the XHTML namespace).

In CSS-aware user agents, the default presentation of this element should be achieved by including the following rules, or their equivalent, in the UA's user agent style sheet:

@namespace xh url(http://www.w3.org/1999/xhtml);
xh|switch { display: block; }
xh|switch xh|*:not([active]) { display: none; }
xh|switch *:not([xh|active]) { display: none; }

2.17.7. Using `switch` and `section`

interface HTMLSwitchElement : HTMLElement {
  readonly attribute Element           activeElement;
  void setActive(in Element element);
};

interface HTMLSectionElement : HTMLElement {
  readonly attribute boolean           active;
  void setActive();
};

...

When an element is added to a switch element as a child (whether during parsing, or later), the element is examined. If the element has an active attribute (or, if it is a non-XHTML element, if it has an active attribute in the XHTML namespace), or, if the switch element's activeElement DOM attribute is null, then the switch element's setActive method is called with that element as the argument. This causes the element to be made the active element for the switch, and causes any other elements to be deactivated if needed.

A side-effect of this definition is that the first element in a switch element is the default element if none have been explicitly marked as active.

2.18. [SCS] Calendars: event data [TBW]

The calendar element may be used for indicating hCalendar fragments that should be processed and rendered, e.g. as inline calendars.

The calendar element is a block-level element whose content model is any block-level elements. User agents must support all the common attributes and event handlers on calendar elements.

Web browsers should render the calendar element by replacing the element by a representation of the calendar data contained within it.

2.18.1. Intepreting calendar data

UAs must process the contents of calendar data as described in the hCalendar specification. [HCALENDAR]

2.18.2. Rendering examples

These examples will need updating to track hCalendar as it evolves.

The following fragment:

<calendar>
 <div class="vcalendar">
  <span class="prodid">-//hCalendar//EN</span>
  <span class="version">2.0</span> 
  <p class="vevent">
   <a href="http://www.web2con.com/">
    <span class="dtstart">20041005</span>-
    <span class="dtend">20041007</span> 
    <span class="summary">Web 2.0 Conference</span>
   </a>
  </p>
 </div>
</calendar>

...might render as the following:

2.19. [SCS] Business cards: personal data [TBW]

The card element may be used for indicating hCard fragments that should be processed and rendered, e.g. as inline business cards.

The card element is a block-level element whose content model is any block-level elements. User agents must support all the common attributes and event handlers on card elements.

Web browsers should render the card element by replacing the element by a representation of the personal data contained within it.

2.19.1. Intepreting card data

UAs must process the contents of card data as described in the hCard specification. [HCARD]

2.19.2. Rendering examples

These examples will need updating to track hCard as it evolves.

The following fragment:

<card>
 <p class="vcard"> 
  <a class="fn n" href="http://tantek.com/">
   <span class="Given-Name">Tantek</span> 
   <span class="Family-Name">Çelik</span>
  </a>
 </p>
</card>

...might render as the following:

A business card with contact information for Tantek
Çelik.

2.20. Disclosure widget [TBW]

The "more details" widget.

2.21. Interactive elements

2.21.1. [SCS] The `datagrid` element

It has been suggested that instead of this flattened-row API, we should have all the "row" arguments in the API below be arrays of integers, and instead of getParentRow(), we would have getRowCount() get the number of children that a row had. A future version of this specification will make this change, along with adding a way to detect when a row/selection has been deleted, activated, etc.

This element is defined as interactive, which means it can't contain other interactive elements, despite the fact that we expect it to work with other interactive elements e.g. checkboxes and input fields. It should be called something like a Leaf Interactive Element or something, which counts for ancestors looking in and not descendants looking out.

Contexts in which this element may be used:

Where block-level elements are expected, if there are no ancestor interactive elements.

Content model:

Zero or more block-level elements.

Element-specific attributes:

multiple

disabled

DOM interface:

interface HTMLDataGridElement : HTMLElement {
        attribute DataGridDataProvider data;
        attribute SelectedRowRanges selection;
        attribute boolean multiple;
        attribute boolean disabled;
  void updateEverything();
  void updateRowsChanged(in long row, in long count);
  void updateRowsInserted(in long row, in long count);
  void updateRowsRemoved(in long row, in long count);
  void updateRowChanged(in long row);
  void updateColumnChanged(in long column);
  void updateCellChanged(in long row, in long column);
};

The datagrid element represents an interactive representation of tree, list, or tabular data.

The data being presented can come either from the content, as elements given as children of the datagrid element, or from a scripted data provider given by the data DOM attribute.

The multiple attribute, if present, must be either empty or have the literal value multiple. Similarly, the disabled attribute, if present, must be either empty or have the literal value disabled. (The actual values do not have any effect on how these attributes are processed, only the presence or absence of the attributes is important.)

The multiple and disabled DOM attributes reflect the multiple and disabled content attributes respectively.

2.21.1.1. The `datagrid` data model

This section is non-normative.

In the datagrid data model, data is structured as a set of rows representing a tree, each row being split into a number of columns. The columns are always present in the data model, although individual columns may be hidden in the presentation.

Each row can have a parent row. If a row r has a parent row p, then all the rows between it and its parent will also have a parent row, and for each row i between p and r the parent row of i will be either p or another row between p and i.

Rows that have other rows claiming them as their parent row are open. Rows can be closed, hiding all the data that would form child rows, but when a row is closed its child data does not appear in the data model.

The columns can have captions. Those captions are not considered a row in their own right, they are obtained separately.

Selection of data in a datagrid operates at the row level. If the multiple attribute is present, multiple rows can be selected at once, otherwise the user can only select one row at a time.

The datagrid element can be disabled entirely by setting the disabled attribute.

Columns, rows, and cells can each have specific flags, known as classes, applied to them by the data provider. These classes affect the functionality of the datagrid element, and are also passed to the style system. They are similar in concept to the class attribute, except that they are not specified on elements but are given by scripted data providers.

2.21.1.2. The data provider interface

The conformance criteria in this section apply to any implementation of the DataGridDataProvider, including (and most commonly) the content author's implementation(s).

// To be implemented by Web authors as a JS object
interface DataGridDataProvider {
  void initialize(in HTMLDataGridElement datagrid);
  long getRowCount();
  long getColumnCount();
  DOMString getCaptionText(in long column);
  void getCaptionClasses(in long column, in DOMTokenString classes);
  long getRowParent(in long row);
  DOMString getRowImage(in long row);
  HTMLMenuElement getRowMenu(in long row);
  void getRowClasses(in long row, in DOMTokenString classes);
  DOMString getCellData(in long row, in long column);
  void getCellClasses(in long row, in long column, in DOMTokenString classes);
  void toggleRowOpenState(in long row);
  void toggleColumnSortState(in long column);
  void setCellCheckedState(in long row, in long column, in int state);
  void cycleCell(in long row, in long column);
  void editCell(in long row, in long column, in DOMString data);
};

The DataGridDataProvider interface represents the interface that objects must implement to be used as custom data views for datagrid elements.

Not all the methods are required. The minimum number of methods that must be implemented in a useful view is two: the getRowCount() and getCellData() methods.

Once the object is written, it must be hooked up to the datagrid using the data DOM attribute.

The following methods may be usefully implemented:

initialize(datagrid)

Called by the datagrid element (the one given by the datagrid argument) after it has first populated itself. This would typically be used to set the initial selection of the datagrid element when it is first loaded. The data provider could also use this method call to register a select event handler on the datagrid in order to monitor selection changes.

getRowCount()

Must return the number of rows currently in the data model, including rows that are off-screen. If the value that this method would return changes, the relevant update methods on the datagrid must be called first. Otherwise, this method must always return the same number.

getColumnCount()

Must return the number of columns currently in the data model (including columns that might be hidden). May be omitted if there is only one column. If the value that this method would return changes, the datagrid's updateEverything() method must be called.

getCaptionText(column)

Must return the caption, or label, for column column. May be omitted if the columns have no captions. If the value that this method would return changes, the datagrid's updateColumnChanged() method must be called with the appropriate column index.

getCaptionClasses(column, classes)

Must add the classes that apply to column column to the classes object. May be omitted if the columns have no special classes. If the classes that this method would add changes, the datagrid's updateColumnChanged() method must be called with the appropriate column index. Some classes have predefined meanings.

getRowParent(row)

Must return the index to the row that is the parent of row row, or a negative number if this is a top-level row. If, for a row r, this method returns the index of parent row p, then for each row i between p and r the method must return either p or another row between p and i. May be omitted if the datagrid is a list and not a tree. If the value that this method would return changes, the datagrid's update methods must be called to update all the rows in the range that covers the old parent, the new parent, and the row in question.

getRowImage(row)

Must return a URI to an image that represents row row, or the empty string if there is no applicable image. May be omitted if no rows have associated images. If the value that this method would return changes, the datagrid's update methods must be called to update the row in question.

getRowMenu(row)

Must return an HTMLMenuElement object that is to be used as a context menu for row row, or null if there is no particular context menu. May be omitted if none of the rows have a special context menu. As this method is called immediately before showing the menu in question, no precautions need to be taken if the return value of this method changes.

getRowClasses(row, classes)

Must add the classes that apply to row row to the classes object. May be omitted if the rows have no special classes. If the classes that this method would add changes, the datagrid's update methods must be called to update the row in question. Some classes have predefined meanings.

getCellData(row, column)

Must return the value of the cell on row row in column column. For text cells, this must be the text to show for that cell. For progress bar cells, this must be either a floating point number in the range 0.0 to 1.0 (converted to a string representation), indicating the fraction of the progress bar to show as full (1.0 meaning complete), or the empty string, indicating an indeterminate progress bar. If the value that this method would return changes, the datagrid's update methods must be called to update the rows that changed. If only one cell changed, the updateCellChanged() method may be used.

getCellClasses(row, column, classes)

Must add the classes that apply to cell on row row in column column to the classes object. May be omitted if the cells have no special classes. If the classes that this method would add changes, the datagrid's update methods must be called to update the rows or cells in question. Some classes have predefined meanings.

toggleRowOpenState(row)

Called by the datagrid when the user tries to open or close a row. When it is called on a closed row, the data provider must update its state so that the rows now include the child rows, and must call the updateRowsInserted() method appropriately. Similarly, when it is called on an open row, the data provider must update its state so that the rows that were shown under the row in question are now removed from the data model, and must then call the updateRowsRemoved() method appropriately. There is no need to tell the datagrid that the row itself has changed (as it should; in particular its classes should change to reflect the new open/closed state), as the datagrid automatically assumes that the row will need updating.

toggleColumnSortState(column)

Called by the datagrid when the user tries to sort the data using a particular column column. The data provider must update its state so that the rows are in the new order, and update the classes of the columns to represent the new sort status. There is no need to tell the datagrid that it the data has changed, as the datagrid automatically assumes that the entire data model will need updating.

It is the data provider's responsibility to ensure that the user's selection persists through a sort. Typically this will involve taking a note of which rows were selected before the sort (using the getRangeStart() and getRangeLength() methods of the selection DOM attribute, for instance), and then clearing the selection and reselecting all the rows in their new positions (e.g. using the addRange() method).

setCellCheckedState(row, column, state)

Called by the datagrid when the user changes the state of a checkbox cell on row row, column column. The checkbox should be toggled to the state given by state, which is a positive integer (1) if the checkbox is to be checked, zero (0) if it is to be unchecked, and a negative number (-1) if it is to be set to the indeterminate state. There is no need to tell the datagrid that the cell has changed, as the datagrid automatically assumes that the given cell will need updating.

cycleCell(row, column)

Called by the datagrid when the user changes the state of a cyclable cell on row row, column column. The data provider should change the state of the cell to the new state, as appropriate. There is no need to tell the datagrid that the cell has changed, as the datagrid automatically assumes that the given cell will need updating.

editCell(row, column, data)

Called by the datagrid when the user edits the cell on row row, column column. The new value of the cell is given by data. The data provider should update the cell accordingly. There is no need to tell the datagrid that the cell has changed, as the datagrid automatically assumes that the given cell will need updating.

The following classes (for rows, columns, and cells) may be usefully used in conjunction with this interface:

Class name	Applies to	Description
`checked`	Cells	The cell has a checkbox and it is checked. (The `cyclable` and `progress` classes override this, though.)
`closed`	Rows	The row can be opened and closed, and, unless the `open` class is also present, the row is currently closed.
`cyclable`	Cells	The cell can be cycled through multiple values. (The `progress` class overrides this, though.)
`editable`	Cells	The cell can be edited. (The `cyclable`, `progress`, `checked`, `unchecked` and `indeterminate` classes override this, though.)
`header`	Rows	The row is a heading, not a data row.
`indeterminate`	Cells	The cell has a checkbox, and it can be set to an indeterminate state. If neither the `checked` nor `unchecked` classes are present, then the checkbox is in that state, too. (The `cyclable` and `progress` classes override this, though.)
`initially-hidden`	Columns	The column will not be shown when the `datagrid` is initially rendered.
`open`	Rows	The row can be opened and closed, and is currently open.
`progress`	Cells	The cell is a progress bar.
`reversed`	Columns	If the cell is sorted, the sort direction is descending, instead of ascending.
`selectable-separator`	Rows	The row is a normal, selectable, data row, except that instead of having data, it only has a separator. (The `header` and `separator` classes override this, though.)
`separator`	Rows	The row is a separator row, not a data row. (The `header` class overrides this, though.)
`sortable`	Columns	The data can be sorted by this column.
`sorted`	Columns	The data is sorted by this column. Unless the `reversed` class is also present, the sort direction is ascending.
`unchecked`	Cells	The cell has a checkbox and, unless the `checked` class is present as well, it is unchecked. (The `cyclable` and `progress` classes override this, though.)

2.21.1.3. The default data provider

The user agent must supply a default data provider for the case where the datagrid's data attribute is null. It must act as described in this section.

The behaviour of the default data provider depends on the nature of the first element child of the datagrid.

While the first element child is a table

getRowCount(): The number of rows returned by the default data provider must be the number of tr elements that are children of tbody elements that are children of the table, if there are any such child tbody elements. If there are no such tbody elements then the number of rows returned must be the number of tr elements that are children of the table.

Rows in thead elements do not contribute to the number of rows returned, although they do affect the columns and column captions. Rows in tfoot elements are ignored completely by this algorithm.

getColumnCount(): The number of columns returned must be the number of td element children in the first tr element child of the first tbody element child of the table, if there are any such tbody elements. If there are no such tbody elements, then it must be the number of td element children in the first tr element child of the table, if any, or otherwise 1. If the number that would be returned by these rules is 0, then 1 must be returned instead.

getCaptionText(i): If the table has no thead element child, or if its first thead element child has no tr element child, the default data provider must return the empty string for all captions. Otherwise, the value of the textContent attribute of the ith th element child of the first tr element child of the first thead element child of the table element must be returned. If there is no such th element, the empty string must be returned.

getCaptionClasses(i, classes): If the table has no thead element child, or if its first thead element child has no tr element child, the default data provider must not add any classes for any of the captions. Otherwise, each class in the class attribute of the ith th element child of the first tr element child of the first thead element child of the table element must be added to the classes. If there is no such th element, no classes must be added. The user agent must then:

Remove the sorted and reversed classes.
If the table element has a class attribute that includes the sortable class, add the sortable class.
If the column is the one currently being used to sort the data, add the sorted class.
If the column is the one currently being used to sort the data, and it is sorted in descending order, add the reversed class as well.

The various row- and cell- related methods operate relative to a particular element, the element of the row or cell specified by their arguments.

For rows: Since the view of the data can be sorted, the positions of the rows in the data model might not be the same as the positions of the real rows in the DOM. When the data is sorted, the row given by the method's argument has to be mapped to the real row. Initially, the mapping is the identity transform, but the mapping can be changed if the user sorts the rows.

Once the method's argument has been translated into an index for the real row, the row's element is found as follows. If the table has tbody element children, the element for the ith real row is the ith tr element that is a child of a tbody element that is a child of the table element. If the table does not have tbody element children, then the element for the ith real row is the ith tr element that is a child of the table element.

For cells: Given a row and its element, the row's ith cell's element is the ith td element child of the row element.

The colspan and rowspan attributes are ignored by this algorithm.

getRowParent(i): The default data provider must always return -1 as the parent row of any row.

The table-based default data provider cannot represent a tree.

getRowImage(i): If the row's first cell's element has an img element child, then the URI of the row's image is the URI of the first img element child of the row's first cell's element. Otherwise, the URI of the row's image is the empty string.

getRowMenu(i): If the row's first cell's element has a menu element child, then the row's menu is the first menu element child of the row's first cell's element. Otherwise, the row has no menu.

getRowClasses(i, classes): The default data provider must never add a class to the row's classes.

toggleColumnSortState(i): If the data is already being sorted on the given column, then the user agent must change the current sort mapping to be the inverse of the current sort mapping; if the sort order was ascending before, it is now descending, otherwise it is now ascending. Otherwise, if the current sort column is another column, or the data model is currently not sorted, the user agent must create a new mapping, which maps rows in the data model to rows in the DOM so that the rows in the data model are sorted by the specified column, in ascending order. (Which sort comparison operator to use is left up to the UA to decide.)

getCellData(i, j), getCellClasses(i, j, classes), getCellCheckedState(i, j, state), cycleCell(i, j), and editCell(i, j, data): See the common definitions below.

The data provider must call the datagrid's update methods appropriately whenever the descendants of the datagrid mutate. For example, if a tr is removed, then the updateRowsRemoved() methods would probably need to be invoked, and any change to a cell or its descendants must cause the cell to be updated. If the table element stops being the first child of the datagrid, then the data provider must call the updateEverything() method on the datagrid. Any change to a cell that is in the column that the data provider is currently using as its sort column must also cause the sort to be reperformed, with a call to updateEverything() if the change did affect the sort order.

While the first element child is a select

The default data provider must return 1 for the column count, the empty string for the column's caption, and must not add any classes to the column's classes.

For the rows, assume the existence of a linear node iterator view of the children of the first select element child of the datagrid element, that skips all nodes other than optgroup and option elements, as well as any descendents of any option elements, and descendants of optgroup elements with the closed token in their class attribute.

Given this view, each element in the view represents a row in the data model: the ith element in the view is the ith row's element. The row of a particular method call is the row given by its arguments.

getRowCount() must return the number of elements in this view.

getRowParent(i) must return the index in the view of the nearest ancestor optgroup element of the row's element, -1 if there is no such ancestor.

getRowImage(i) must return the empty string, getRowMenu(i) must return null.

getRowClasses(i, classes) must add the classes from the following list to classes when their condition is met:

If the row's element contains other elements that are also in the view, and the element's class attribute contains the closed class: closed
If the row's element contains other elements that are also in the view, and the element's class attribute doesn't contain the closed class: open

The toggleRowOpenState(i) method must add a closed class to that row's element's class attribute and remove any open class, unless it already has a closed class and has no open class, in which case it must instead remove the closed class and add an open class. It must then invoke the appropriate update methods to inform the datagrid of the newly added or removed rows.

The getCellData(i, j) method must return the value of the label attribute if the row's element is an optgroup element, otherwise, if the row's element is an optionelement, its label attribute if it has one, otherwise the value of its textContent DOM attribute.

The getCellClasses(i, j, classes) method must add no classes.

The data provider must call the datagrid's update methods appropriately whenever the descendants of the datagrid mutate.

While the first element child is another element

The default data provider must return 1 for the column count, the empty string for the column's caption, and must not add any classes to the column's classes.

For the rows, assume the existence of a linear node iterator view of the children of the datagrid that skips all nodes other than li, h1-h6, and hr elements, and skips all elements that are descendants of elements with the closed token in their class attribute, and any descendants of menu elements.

getRowCount() must return the number of elements in this view.

getRowParent(i) must return the index in the view of the nearest ancestor (in the real DOM) of the row's element that is also in the view, -1 if there is no such ancestor.

In the following example, the row numbered 2 returns 1 as its parent, and the other rows return -1:

<datagrid>
 <ol>
  <li> row 0 </li>
  <li> row 1
   <ol>
    <li> row 2 </li>
   </ol>
  </li>
  <li> row 3 </li>
 </ol>
</datagrid>

getRowImage(i) must return the URI of the image given by the first img element descendant (in the real DOM) of the row's element, that is not also a descendant of another element that has a later position in the view.

In the following example, the row numbered 2 returns "http://example.com/a" as its image URI, and the other rows (including row 1) return the empty string:

<datagrid>
 <ol>
  <li> row 0 </li>
  <li> row 1
   <ol>
    <li> row 2 <img src="http://example.com/a" alt=""> </li>
   </ol>
  </li>
  <li> row 3 </li>
 </ol>
</datagrid>

getRowMenu(i) must return the first menu element descendant (in the real DOM) of the row's element, that is not also a descendant of another element that has a later position in the view. (This is analogous to the image case above.)

getRowClasses(i, classes) must add the classes from the following list to classes when their condition is met:

If the row's element contains other elements that are also in the view, and the element's class attribute contains the closed class: closed
If the row's element contains other elements that are also in the view, and the element's class attribute doesn't contain the closed class: open
If the row's element is an h1-h6 element: header
If the row's element is an hr element: separator

The getCellData(i, j), getCellClasses(i, j, classes), getCellCheckedState(i, j, state), cycleCell(i, j), and editCell(i, j, data) methods must act as described in the common definitions below, treating the row's element as being the cell's element.

The data provider must call the datagrid's update methods appropriately whenever the descendants of the datagrid mutate.

Otherwise, while there is no element child

The data provider must return 0 for the number of rows, 1 for the number of columns, the empty string for the first column's caption, and must add no classes when asked for that column's classes. If the datagrid's child list changes such that the first element child is one of the above, then the data provider must call the updateEverything() method on the datagrid.

2.21.1.3.1. Common default data provider method definitions for cells

These definitions are used for the cell-specific methods of the default data providers (other than in the select case). How they behave is based on the contents of an element that represents the cell given by their first two arguments (which are the row and column indices respectively). Which element that is is defined in the previous section.

Cyclable cells

If the first element child of a cell's element is a select element that has a no multiple attribute and has at least one option element descendent, then the cell acts as a cyclable cell.

The "current" option element is the selected option element, or the first option element if none is selected.

The getCellData() method must return the textContent of the current option element (the label attribute is ignored in this context as the optgroups are not displayed).

The getCellClasses() method must add the cyclable class and then all the classes of the current option element.

The cycleCell() method must change the selection of the select element such that the next option element after the current option element is the only one that is selected (in tree order). If the current option element is the last option element descendent of the select, then the first option element descendent must be selected instead.

The setCellCheckedState() and editCell() methods must do nothing.

Progress bar cells

If the first element child of a cell's element is a progress element, then the cell acts as a progress bar cell.

The getCellData() method must return the value returned by the progress element's position DOM attribute.

The getCellClasses() method must add the progress class.

The setCellCheckedState(), cycleCell(), and editCell() methods must do nothing.

Checkbox cells

If the first element child of a cell's element is an input element that has a type attribute with the value checkbox, then the cell acts as a check box cell.

The getCellData() method must return the textContent of the cell element.

The getCellClasses() method must add the checked class if the input element is checked, and the unchecked class otherwise.

The setCellCheckedState() method must set the input element's checkbox state to checked if the method's third argument is 1, and to unchecked otherwise.

The cycleCell() and editCell() methods must do nothing.

Editable cells

If the first element child of a cell's element is an input element that has a type attribute with the value text or that has no type attribute at all, then the cell acts as an editable cell.

The getCellData() method must return the value of the input element.

The getCellClasses() method must add the editable class.

The editCell() method must set the input element's value DOM attribute to the value of the third argument to the method.

The setCellCheckedState() and cycleCell() methods must do nothing.

2.21.1.4. Populating the `datagrid` element

A datagrid must be disabled until its end tag has been parsed (in the case of a datagrid element in the original document markup) or until it has been inserted into the document (in the case of a dynamically created element). After that point, the element must fire a single load event at itself, which doesn't bubble and cannot be canceled.

The datagrid must then populate itself using the data provided by the data provider assigned to the data DOM attribute. After the view is populated (using the methods described below), the datagrid must invoke the initialize() method on the data provider specified by the data attribute, passing itself (the HTMLDataGridElement object) as the only argument.

When the data attribute is null, the datagrid must use the default data provider described in the previous section.

To obtain data from the data provider, the element must invoke methods on the data provider object in the following ways:

To determine the total number of rows

Invoke the getRowCount() method with no arguments. The return value is the number of rows. If the return value is negative, not an integer, or simply not a numeric type, or if the method is not defined, then zero must be used instead.

To determine the total number of columns

Invoke the getColumnCount() method with no arguments. The return value is the number of columns. If the return value is zero or negative, not an integer, or simply not a numeric type, or if the method is not defined, then 1 must be used instead.

To get the captions to use for the columns

Invoke the getCaptionText() method with the index of the column in question. The index i must be in the range 0 ≤ i < N, where N is the total number of columns. The return value is the string to use when referring to that column. If the method returns null or the empty string, the column has no caption. If the method is not defined, then none of the columns have any captions.

To establish what classes apply to a column

Invoke the getCaptionClasses() method with the index of the column in question, and an object implementing the DOMTokenString interface, initialised to empty. The index i must be in the range 0 ≤ i < N, where N is the total number of columns. The values contained in the DOMTokenString object when the method returns represent the classes that apply to the given column. If the method is not defined, no classes apply to the column.

To establish whether a column should be initially included in the visible columns

Check whether the initially-hidden class applies to the column. If it does, then the column should not be initially included; if it does not, then the column should be initially included.

To establish whether the data can be sorted relative to a particular column

Check whether the sortable class applies to the column. If it does, then the user should be able to ask the UA to display the data sorted by that column; if it does not, then the user agent must not allow the user to ask for the data to be sorted by that column.

To establish if a column is a sorted column

If the user agent can handle multiple columns being marked as sorted simultaneously: Check whether the sorted class applies to the column. If it does, then that column is the sorted column, otherwise it is not.

If the user agent can only handle one column being marked as sorted at a time: Check each column in turn, starting with the first one, to see whether the sorted class applies to that column. The first column that has that class, if any, is the sorted column. If none of the columns have that class, there is no sorted column.

To establish the sort direction of a sorted column

Check whether the reversed class applies to the column. If it does, then the sort direction is descending (down; first rows have the highest values), otherwise it is ascending (up; first rows have the lowest values).

To establish a row's parent row

Invoke the getRowParent() method with the index of the row in question. The index i must be in the range 0 ≤ i < N, where N is the total number of rows. The return value p is the index of the parent row. If the method returns a number outside the range 0 ≤ p < i, or if the returned value is non-numeric, or if the method is not defined, then the row has no parent row (it is an unparented top-level row).

If a row r has a parent row p, but not all the rows between it and its parent also have a parent row, or if there is a row i between p and r the parent of which is neither p nor another row between p and i, then the user agent may present the tree structure in an inconsistent way instead of attempting to render the actual described tree structure.

To obtain a URI to an image representing a row

Invoke the getRowImage() method with the index of the row in question. The index i must be in the range 0 ≤ i < N, where N is the total number of rows. The return value is a string representing a URI or IRI to an image. Relative URIs must be interpreted relative to the datagrid's base URI. If the method returns the empty string, null, or if the method is not defined, then the row has no associated image.

To obtain a context menu appropriate for a particular row

Invoke the getRowMenu() method with the index of the row in question. The index i must be in the range 0 ≤ i < N, where N is the total number of rows. The return value is a reference to an object implementing the HTMLMenuElement interface, i.e. a menu element DOM node. (This element must then be interpreted as described in the section on context menus to obtain the actual context menu to use.) If the method returns something that is not an HTMLMenuElement, or if the method is not defined, then the row has no associated context menu. User agents may provide their own default context menu, and may add items to the author-provided context menu. For example, such a menu could allow the user to change the presentation of the datagrid element.

To establish what classes apply to a row

Invoke the getRowClasses() method with the index of the row in question, and an object implementing the DOMTokenString interface, initialised to empty. The index i must be in the range 0 ≤ i < N, where N is the total number of rows. The values contained in the DOMTokenString object when the method returns represent the classes that apply to the row in question. If the method is not defined, no classes apply to the row.

To establish whether a row is a data row or a special row

Examine the classes that apply to the row. If the header class applies to the row, then it is not a data row, it is a subheading. The data from the first cell of the row is the text of the subheading, the rest of the cells must be ignored. Otherwise, if the separator class applies to the row, then in the place of the row, a separator should be shown. Otherwise, if the selectable-separator class applies to the row, then the row should be a data row, but represented as a separator. (The difference between a separator and a selectable-separator is that the former is not an item that can be actually selected, whereas the second can be selected and thus has a context menu that applies to it, and so forth.) For both kinds of separator rows, the data of the rows' cells must all be ignored. If none of those three classes apply then the row is a simple data row.

To establish whether a row is openable

Check whether one of the open or closed classes applies to the row. If one (or both) of these are present, then the row can be opened and closed, otherwise neither are present and the row cannot be opened or closed. (It might still have rows that consider this row a parent, however.)

To establish whether an openable row is open or closed

Check whether the open class applies to the row. If it does, the row is open. Otherwise, the row is closed. The closed class is not examined to make this determination (although either it or the open class must be present to make the row openable in the first place). If a closed row has rows that consider it a parent, those rows must still be included in the rendering.

To establish the value of a particular cell

Invoke the getCellData() method with the first argument being the index of the cell's row and the second argument being the index of its column. The two arguments must be zero or positive integers less than the total number of rows and columns respectively. The return value is the value of the cell. If the return value is null or the empty string, or if the method is not defined, then the cell has no data. (For progress bar cells, the cell's value must be further interpreted, as described below.)

To establish what classes apply to a cell

Invoke the getCellClasses() method with the first argument being the index of the cell's row, the second argument being the index of its column, and the third being an object implementing the DOMTokenString interface, initialised to empty. The first two arguments must be zero or positive integers less than the total number of rows and columns respectively. The values contained in the DOMTokenString object when the method returns represent the classes that apply to that cell. If the method is not defined, no classes apply to the cell.

To establish how the type of a cell

Examine the classes that apply to the cell. If the progress class applies to the cell, it is a progress bar. Otherwise, if the cyclable class applies to the cell, it is a cycling cell whose value can be cycled between multiple states. Otherwise, none of these classes apply, and the cell is a simple text cell.

To establish the value of a progress bar cell

If the value x of the cell is a string that can be converted to a floating point number in the range 0.0 ≤ x ≤ 1.0, then the progress bar has that value (0.0 means no progress, 1.0 means complete). Otherwise, the progress bar is an indeterminate progress bar.

To establish how a simple text cell should be presented

Check whether one of the checked, unchecked, or indeterminate classes applies to the cell. If any of these are present, then the cell has a checkbox, otherwise none are present and the cell does not have a checkbox. If the cell has no checkbox, check whether the editable class applies to the cell. If it does, then the cell value is editable, otherwise the cell value is static.

To establish the state of a cell's checkbox, if it has one

Check whether the checked class applies to the cell. If it does, the cell is checked. Otherwise, check whether the unchecked class applies to the cell. If it does, the cell is unchecked. Otherwise, the indeterminate class appplies to the cell and the cell's checkbox is in an indeterminate state. When the indeterminate class appplies to the cell, the checkbox is a tristate checkbox, and the user can set it to the indeterminate state. Otherwise, only the checked and/or unchecked classes apply to the cell, and the cell can only be toggled betwen those two states.

If the data provider ever raises an exception while the datagrid is invoking one of its methods, the datagrid must act, for the purposes of that particular method call, as if the relevant method had not been defined.

The data model is considered stable: user agents may assume that subsequent calls to the data provider methods will return the same data, until one of the update methods is called on the datagrid element. If a user agent is returned inconsistent data, for example if the number of rows returned by getRowCount() varies in ways that do not match the calls made to the update methods, the user agent may disable the datagrid. User agents that do not disable the datagrid in inconsistent cases must honour the most recently returned values.

User agents may cache returned values so that the data provider is never asked for data that could contradict earlier data. User agents must not cache the return value of the getRowMenu method.

The exact algorithm used to populate the data grid is not defined here, since it will differ based on the presentation used. However, the behaviour of user agents must be consistent with the descriptions above. For example, it would be non-conformant for a user agent to make cells have both a checkbox and be editable, as the descriptions above state that cells that have a checkbox cannot be edited.

2.21.1.5. Updating the `datagrid`

Whenever the data attribute is set to a new value, the datagrid must clear the current selection, remove all the displayed rows, and plan to repopulate itself using the information from the new data provider at the earliest opportunity.

There are a number of update methods that can be invoked on the datagrid element to cause it to refresh itself in slightly less drastic ways:

When the updateEverything() method is called, the user agent must repopulate the entire datagrid. If the number of rows decreased, the selection must be updated appropriately. If the number of rows increased, the new rows should be left unselected.

When the updateRowsChanged(row, count) method is called, the user agent must refresh the rendering of the rows in the range from row row to row row+count-1.

When the updateRowsInserted(row, count) method is called, the user agent must assume that count new rows have been inserted between what used to be row row-1 and row row. The user agent must update its rendering and the selection accordingly. The new rows should not be selected.

When the updateRowsRemoved(row, count) method is called, the user agent must assume that count rows have been removed starting from row row. The user agent must update its rendering and the selection accordingly.

The updateRowChanged(row) method must be exactly equivalent to calling updateRowsChanged(row, 1).

When the updateColumnChanged(column) method is called, the user agent must refresh the rendering of the specified column column, for all rows.

When the updateCellChanged(row, column) method is called, the user agent must refresh the rendering of the cell on row row, in column column.

Any effects the update methods have on the datagrid's selection is not considered a change to the selection, and must therefore not fire the select event.

These update methods should only be called by the data provider, or code acting on behalf of the data provider. In particular, calling the updateRowsInserted() and updateRowsRemoved() methods without actually inserting or removing rows from the data provider is likely to result in inconsistent renderings.

2.21.1.6. Requirements for interactive user agents

This section only applies to interactive user agents.

If the datagrid element has a disabled attribute, then the user agent must disable the datagrid, preventing the user from interacting with it. The datagrid element should still continue to update itself when the data provider signals changes to the data, though. Obviously, conformance requirements stating that datagrid elements must react to users in particular ways do not apply when one is disabled.

If a row is openable, then the user must be able to toggle its open/closed state. When the user does so, then the datagrid must invoke the data provider's toggleRowOpenState() method, with the row's index as the only argument. The datagrid must then act as if the datagrid's updateRowChanged() method had been invoked with that row's index immediately before the provider's method was invoked.

If a cell is a cell whose value can be cycled between multiple states, then the user must be able to activate the cell to cycle its value. When the user activates this "cycling" behaviour of a cell, then the datagrid must invoke the data provider's cycleCell() method, with the cell's row index as the first argument and its column index as the second. The datagrid must then act as if the datagrid's updateCellChanged() method had been invoked with those same arguments immediately before the provider's method was invoked.

When a cell has a checkbox, the user must be able to set the checkbox's state. When the user changes the state of a checkbox in such a cell, the datagrid must invoke the data provider's setCellCheckedState() method, with the cell's row index as the first argument, its column index as the second, and the checkbox's new state as the third. The state should be represented by the number 1 if the new state is checked, 0 if the new state is unchecked, and -1 if the new state is indeterminate (which must only be possible if the cell has the indeterminate class set). The datagrid must then act as if the datagrid's updateCellChanged() method had been invoked, specifying the same cell, immediately before the provider's method was invoked.

If a cell is editable, the user must be able to edit the data for that cell, and doing so must cause the user agent to invoke the editCell() method of the data provider with three arguments: the row number and column number of the cell, and the new text entered by the user. The user agent must then act as if the updateCellChanged() method had been invoked, with the same row and column specified.

2.21.1.7. The selection

This section only applies to interactive user agents. For other user agents, the selection attribute must return null.

interface SelectedRowRanges {
  readonly attribute long count;
  long getRangeStart(in long index);
  long getRangeLength(in long index);
  void addRange(in long start, in long count);
  void removeRange(in long index);
  void setSelected(in long row, in boolean selected);
  boolean isSelected(in long row);
  void selectAll();
  void invert();
  void clear();
};

Each datagrid element must keep track of which rows are currently selected. Initially no rows are selected, but this can be changed via the methods described in this section.

The selection of a datagrid is represented by its selection DOM attribute, which must be a SelectedRowRanges object.

The SelectedRowRanges object represents the selection using ranges. Each range has a starting index and a length. The starting index is relative to the first row (index 0) of the datagrid. The length states how many of the rows are selected, starting from the starting index. A range of length one implies that only the row indicated by its starting index is selected.

The ranges in a selection must not overlap. Ranges may be adjacent (e.g. one range starting at index zero with length two, and a second range starting at index two) but user agents should coalesce adjacent ranges.

The start index of a range must not be negative, and must not be greater than the index of the last row. The length of a range must not be such that the range's start index plus its length yields a value greater than the number of rows.

The count attribute must return the number of ranges currently present in the selection. The getRangeStart() and getRangeLength() methods must return the starting index and length (respectively) of the range specified by their argument. If the argument is out of range (less than zero or greater than the number of ranges minus one), then they must raise an INDEX_SIZE_ERR exception. [DOM3CORE]

The ranges must be returned in ascending numerical order. That is, the value returned by the getRangeStart() method for an index x must always be greater than the value it returns for any index less than x.

The addRange() method takes two arguments, an index and a length, specifying a range of rows to select. If the specified range is invalid or would contain rows outside the datagrid (e.g. the starting index is negative, or the length would take the selection beyond the end of the datagrid), then the method must raise an INDEX_SIZE_ERR exception. Otherwise, the specified range must be added to the selection. If the range overlaps, grows, or joins existing selections, the user agent must adjust the ranges so that no two ranges overlap, and should adjust them so that no two ranges are adjacent. Thus, calling addRange() may actually reduce the total number of ranges in the selection.

The removeRange() method takes two arguments, an index and a length, specifying a range of rows to unselect. If the specified range is invalid or would contain rows outside the datagrid (e.g. the starting index is negative, or the length would take the selection beyond the end of the datagrid), then the method must raise an INDEX_SIZE_ERR exception. Otherwise, the specified rows must be removed from the selection. Calling removeRange() may actually increase the total number of ranges in the selection, e.g. if a range had to be split in order to unselect a row in the middle.

The setSelected() method takes two arguments, row and selected. When invoked, it must set the selection state of row row to selected if selected is true, and unselected if it is false, by adjusting the selection's ranges accordingly. If row is less than zero or greater than the index of the last row then the method must raise an INDEX_SIZE_ERR exception.

The isSelected() method must return the selected state of the row specified by its argument. If the specified row exists and is in one of the ranges of the selection, it must return true, otherwise it must return false.

The selectAll() method must replace all the current ranges in the selection with a single selection range having index zero and a length equal to the number of rows in the datagrid. If there are no rows in the datagrid then this method must instead only remove all the current ranges. (In a compliant UA, there would not be any ranges to remove.)

The invert() method must adjust the selections such that the selection is inverted. That is, the ranges must be adjusted such that only the rows that were previously not a part of the selection must be made a part of the new selection.

The clear() method must remove all the ranges in the selection.

If the datagrid element has a multiple attribute, then the user must be able to select any number of rows (zero or more). If the attribute is not present, then the user must only be able to select a single row at a time, and selecting another one must unselect all the other rows.

This only applies to the user. Scripts can select multiple rows even when the multiple attribute is absent.

Whenever the selection of a datagrid changes, whether due to the user interacting with the element, or as a result of calls to methods of the selection object, a select event that bubbles but is not cancelable must be fired on the datagrid element. If multiple changes are made to the selection via calls to the object's methods during a single execution of a script, then the select events should be coalesced into one (which later fires once the script execution has completed).

The SelectedRowRanges interface has no relation to the Selection and Range interfaces.

2.21.1.8. Columns and captions

This section only applies to interactive user agents.

Each datagrid element must keep track of which columns are currently being rendered. User agents should initially show all the columns except those with the initially-hidden class, but may allow users to hide or show columns. User agents should initially display the columns in the order given by the data provider, but may allow this order to be changed by the user.

If columns are not being used, as might be the case if the data grid is being presented in an icon view, or if an overview of data is being read in an aural context, then the text of the first column of each row should be used to represent the row.

If none of the columns have any captions (i.e. if the data provider does not provide a getCaptionText() method), then user agents may avoid showing the column headers at all. This may prevent the user from performing actions on the columns (such as reordering them, changing the sort column, and so on).

Whatever the order used for rendering, and irrespective of what columns are being shown or hidden, the "first column" as referred to in this specification is always the column with index zero, and the "last column" is always the column with the index one less than the value returned by the getColumnCount() method of the data provider.

If a column is sortable, then the user must be able to invoke it to sort the data. When the user does so, then the datagrid must invoke the data provider's toggleColumnSortState() method, with the column's index as the only argument. The datagrid must then act as if the datagrid's updateEverything() method had been invoked.

2.21.2. The `command` element

Metadata element, and strictly inline-level content.

Contexts in which this element may be used:

In a head element.

Where strictly inline-level content is allowed.

Content model:

Empty.

Element-specific attributes:

type

label

icon

hidden

disabled

checked

radiogroup

default

Also, the title attribute has special semantics on this element.

DOM interface:

interface HTMLCommandElement : HTMLElement {
           attribute DOMString type;
           attribute DOMString label;
           attribute DOMString icon;
           attribute boolean hidden;
           attribute boolean disabled;
           attribute boolean checked;
           attribute DOMString radiogroup;
           attribute boolean default;
 void click();
};

The Command interface must also be implemented by this element.

The command element represents a command that the user can invoke.

The type attribute indicates the kind of command: either a normal command with an associated action, or a state or option that can be toggled, or a selection of one item from a list of items.

The attribute's value must be either "command", "checkbox", or "radio", denoting each of these three types of commands respectively. The attribute may also be omitted if the element is to represent the first of these types, a simple command.

The label attribute gives the name of the command, as shown to the user.

The title attribute gives a hint describing the command, which might be shown to the user to help him.

The icon attribute gives a picture that represents the command. If the attribute is specified, the attribute's value must contain a URI.

The hidden attribute indicates, if present, that the command is not relevant and is to be hidden. If present, the attribute must have the exact value hidden.

The disabled attribute indicates, if present, that the command is not available in the current state. If present, the attribute must have the exact value disabled.

The distinction between Disabled State and Hidden State is subtle. A command should be Disabled if, in the same context, it could be enabled if only certain aspects of the situation were changed. A command should be marked as Hidden if, in that situation, the command will never be enabled. For example, in the context menu for a water faucet, the command "open" might be Disabled if the faucet is already open, but the command "eat" would be marked Hidden since the faucet could never be eaten.

The checked attribute indicates, if present, that the command is selected. If present, the attribute must have the exact value checked.

The radiogroup attribute gives the name of the group of commands that will be toggled when the command itself is toggled, for commands whose type attribute has the value "radio". The scope of the name is the child list of the parent element.

If the command element is used when generating a context menu, then the default attribute indicates, if present, that the command is the one that would have been invoked if the user had directly activated the menu's subject instead of using its context menu.

Need an example that shows an element that, if double-clicked, invokes an action, but that also has a context menu, showing the various command attributes off, and that has a default command.

The type, label, icon, hidden, disabled, checked, radiogroup, and default DOM attributes must reflect their respective namesake content attributes.

The click() method's behaviour depends on the value of the type attribute of the element, as follows:

If the type attribute has the value checkbox

If the element has a checked attribute, the UA must remove that attribute. Otherwise, the UA must add a checked attribute, with the literal value checked. The UA must then fire a click event at the element.

If the type attribute has the value radio

If the element has a parent, then the UA must walk the list of child nodes of that parent element, and for each node that is a command element, if that element has a radiogroup attribute whose value exactly matches the current element's (treating missing radiogroup attributes as if they were the empty string), and has a checked attribute, must remove that attribute and fire a click event at the element.

Then, the element's checked attribute attribute must be set to the literal value checked and a click event must be fired at the element.

Otherwise

The UA must fire a click event at the element.

Firing a synthetic click event at the element does not cause any of the actions described above to happen.

Need to define the command="" attribute

command elements are not rendered unless they form part of a menu.

Block-level element, and structured inline-level element.

Contexts in which this element may be used:

Where block-level elements are expected.

Where structured inline-level elements are allowed.

Content model:

Zero or more li elements, or inline-level content (but not both).

Element-specific attributes:

type

label

autosubmit

DOM interface:

interface HTMLCommandElement : HTMLElement {
           attribute DOMString type;
           attribute DOMString label;
           attribute boolean autosubmit;
};

The menu element represents a list of commands.

The type attribute indicates the kind of menu. It must have either the value popup (to declare a context menu) or the value toolbar (to define a tool bar). The attribute may also be omitted, to indicate that the element is merely a list of commands that is neither declaring a context menu nor defining a tool bar.

If a menu element has a type attribute with the value popup, then it represents the commands of a context menu, and the user can only interact with the commands if that context menu is activated.

If a menu element has a type attribute with the value toolbar, then it represents a list of active commands that the user can immediately interact with.

Otherwise, if a menu element has no type attribute, or if has a type attribute with a value other than popup or toolbar, then it either represents an unordered list of items (each represented by an li element), each of which represents a command that the user may perform or activate, or, if the element has no li element children, a paragraph describing available commands.

The label attribute gives the label of the menu. It is used by user agents to display nested menus in the UI. For example, a context menu containing another menu would use the nested menu's label attribute for the submenu's menu label.

The autosubmit attribute indicates whether selections made to form controls in this menu should result in the control's form being immediately submitted. If the attribute is present, its value must be autosubmit.

If a change event bubbles through a menu element, then, in addition to any other default action that that event might have, the UA must act as if the following was an additional default action for that event: if (when it comes time to execute the default action) the menu element has an autosubmit attribute, and the target of the event is an input element, and that element has a type attribute whose value is either radio or checkbox, and the input element in question has a non-null form DOM attribute, then the UA must invoke the submit() method of the form element indicated by that DOM attribute.

The processing model for menus is described in the next section.

3. Processing models

3.1. Navigating across documents

This section will end up defining what the UA should do when the user clicks a link. This will probably involve being honest about the fact that UAs typically content sniff for RSS/Atom feeds at this point. It should also reference the registerProtocolHandler and registerContentHandler methods and their stuff.

3.2. Commands

A command is the abstraction behind menu items, buttons, and links. Once a command is defined, other parts of the interface can refer to the same command, allowing many access points to a single feature to share aspects such as the disabled state.

Type: The kind of command: "command", meaning it is a normal command; "radio", meaning that triggering the command will, amongst other things, set the Checked State to true (and probably uncheck some other commands); or "checkbox", meaning that triggering the command will, amongst other things, toggle the value of the Checked State.
ID: The name of the command, for referring to the command from the markup or from script. If a command has no ID, it is an anonymous command.
Label: The name of the command as seen by the user.
Hint: A helpful or descriptive string that can be shown to the user.
Icon: A graphical image that represents the action.
Hidden State: Whether the command is hidden or not (basically, whether it should be shown in menus).
Disabled State: Whether the command can be triggered or not. If the Hidden State is true (hidden) then the Disabled State will be true (disabled) regardless. We could make this into a string value that acts as a Hint for why the command is disabled.
Checked State: Whether the command is checked or not.
Action: The actual effect that triggering the command will have. This could be a scripted event handler, a URI to which to navigate, or a form submission.
Triggers: The list of elements that can trigger the command. The element defining a command is always in the list of elements that can trigger the command. For anonymous commands, only the element defining the command is on the list, since other elements have no way to refer to it.

Commands are represented by elements in the DOM. Any element that can define a command also implements the Command interface:

interface Command {
  readonly attribute DOMString commandType;          
  readonly attribute DOMString id;
  readonly attribute DOMString label;
  readonly attribute DOMString title;
  readonly attribute DOMString icon;
  readonly attribute boolean hidden;
  readonly attribute boolean disabled;              
  readonly attribute boolean checked;              
  void click();
  readonly attribute HTMLCollection triggers;
  readonly attribute Command command;
};

The Command interface is implemented by any element capable of defining a command. (If an element can define a command, its definition will list this interface explicitly.) All the attributes of the Command interface are read-only. Elements implementing this interface may implement other interfaces that have attributes with identical names but that are mutable; in bindings that simply flatten all supported interfaces on the object, the mutable attributes must shadow the readonly attributes defined in the Command interface.

The commandType attribute must return a string whose value is either "command", "radio", or "checked", depending on whether the Type of the command defined by the element is "command", "radio", or "checked" respectively. If the element does not define a command, it must return null.

The id attribute must return the command's ID, or null if the element does not define a command or defines an anonymous command. This attribute will be shadowed by the id DOM attribute on the HTMLElement interface.

The label attribute must return the command's Label, or null if the element does not define a command or does not specify a Label. This attribute will be shadowed by the label DOM attribute on option and command elements.

The title attribute must return the command's Hint, or null if the element does not define a command or does not specify a Hint. This attribute will be shadowed by the title DOM attribute on the HTMLElement interface.

The icon attribute must return an absolute URI to the command's Icon. If the element does not specify an icon, or if the element does not define a command, then the attribute must return null. This attribute will be shadowed by the icon DOM attribute on command elements.

The hidden attribute must return true if the command's Hidden State is that the command is hidden, and false if it is that the command is not hidden. If the element does not define a command, the attribute must return false. This attribute will be shadowed by the hidden DOM attribute on command elements.

The disabled attribute must return true if the command's Disabled State is that the command is disabled, and false if the command is not disabled. This attribute is not affected by the command's Hidden State. If the element does not define a command, the attribute must return false. This attribute will be shadowed by the disabled attribute on button, input, option, and command elements.

The checked attribute must return true if the command's Checked State is that the command is checked, and false if it is that the command is not checked. If the element does not define a command, the attribute must return false. This attribute will be shadowed by the checked attribute on input and command elements.

The click() method must trigger the Action for the command. If the element does not define a command, this method must do nothing. This method will be shadowed by the click() method on button, input, and command elements.

The triggers attribute must return a list containing the elements that can trigger the command (the command's Triggers). The list must be live. While the element does not define a command, the list must be empty.

All the commands that have IDs must be in the list returned by the commands attribute of the document's DocumentWindow interface. The collection represented by this attribute is live; as commands are defined in or removed from the document, the attribute is updated.

The following elements may define commands: a, button, input, option, command.

3.2.1. Using the `a` element to define a command

An a element with an href attribute defines a command.

The Type of the command is "command".

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command is the string given by the element's textContent DOM attribute.

The Hint of the command is the value of the title attribute of the a element. If the attribute is not present, the Hint is the empty string.

The Icon of the command is the absolute URI of the first image in the element. Specifically, in a depth-first search of the children of the element, the first element that is img element with a src attribute is the one that is used as the image. The URI must be taken from the element's src attribute. Relative URIs must be resolved relative to the base URI of the image element. If no image is found, then the Icon facet is left blank.

The Hidden State and Disabled State facets of the command are always false. (The command is always enabled.)

The Checked State of the command is always false. (The command is never checked.)

The Action of the command is to fire a click event at the element.

3.2.2. Using the `button` element to define a command

A button element always defines a command.

The Type, ID, Label, Hint, Icon, Hidden State, Checked State, and Action facets of the command are determined as for a elements (see the previous section).

The Disabled State of the command mirrors the disabled state of the button. Typically this is given by the element's disabled attribute, but certain button types become disabled at other times too (for example, the move-up button type is disabled when it would have no effect).

3.2.3. Using the `input` element to define a command

An input element whose type attribute is one of submit, reset, button, radio, checkbox, move-up, move-down, add, and remove defines a command.

The Type of the command is "radio" if the type attribute has the value radio, "checkbox" if the type attribute has the value checkbox, and "command" otherwise.

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command depends on the Type of the command:

If the Type is "command", then it is the string given by the value attribute, if any, and a UA-dependent value that the UA uses to label the button itself if the attribute is absent.

Otherwise, the Type is "radio" or "checkbox". If the element has a label element associated with it, the textContent of the first such element is the Label (in DOM terms, this the string given by element.labels[0].textContent). Otherwise, the value of the value attribute, if present, is the Label. Otherwise, the Label is the empty string.

The Hint of the command is the value of the title attribute of the input element. If the attribute is not present, the Hint is the empty string.

There is no Icon for the command.

The Hidden State of the command is always false. (The command is never hidden.)

The Disabled State of the command mirrors the disabled state of the control. Typically this is given by the element's disabled attribute, but certain input types become disabled at other times too (for example, the move-up input type is disabled when it would have no effect).

The Checked State of the command is true if the command is of Type "radio" or "checkbox" and the element has a checked attribute, and false otherwise.

The Action of the command is to fire a click event at the element.

3.2.4. Using the `option` element to define a command

An option element with an ancestor select element and either no value attribute or a value attribute that is not the empty string defines a command.

The Type of the command is "radio" if the option's nearest ancestor select element has no multiple attribute, and "checkbox" if it does.

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command is the value of the option element's label attribute, if there is one, or the value of the option element's textContent DOM attribute if it doesn't.

The Hint of the command is the string given by the element's title attribute, if any, and the empty string if the attribute is absent.

There is no Icon for the command.

The Hidden State of the command is always false. (The command is never hidden.)

The Disabled State of the command is true (disabled) if the element has a disabled attribute, and false otherwise.

The Checked State of the command is true (checked) if the element's selected DOM attribute is true, and false otherwise.

The Action of the command depends on its Type. If the command is of Type "radio" then this must set the selected DOM attribute of the option element to true, otherwise it must toggle the state of the selected DOM attribute (set it to true if it is false and vice versa). Then a change event must be fired on the option element's nearest ancestor select element (if there is one), as if the selection had been changed directly.

3.2.5. Using the `command` element to define a command

A command element defines a command.

The Type of the command is "radio" if the command's type attribute is "radio", "checkbox" if the attribute's value is "checkbox", and "command" otherwise.

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command is the value of the element's label attribute, if there is one, or the empty string if it doesn't.

The Hint of the command is the string given by the element's title attribute, if any, and the empty string if the attribute is absent.

The Icon for the command is the absolute URI resulting from resolving the value of the element's icon attribute as a URI relative to the element's base URI. If the element has no icon attribute then the command has no Icon.

The Hidden State of the command is true (hidden) if the element has a hidden attribute, and false otherwise.

The Disabled State of the command is true (disabled) if the element has either a disabled attribute or a hidden attribute (or both), and false otherwise.

The Checked State of the command is true (checked) if the element has a checked attribute, and false otherwise.

The Action of the command is to invoke the behaviour described in the definition of the click() method of the HTMLCommandElement interface.

3.3. Forms [TBW]

See WF2 for now

3.3.1. Form submission [TBW]

See WF2 for now

3.4. Menus

3.4.1. Introduction [TBW]

...

3.4.2. Building menus

A menu consists of a list of zero or more of the following components:

Commands, which can be marked as default commands
Separators
Other menus (which allows the list to be nested)

The list corresponding to a particular element is built by iterating over its child nodes.

For each child node in document order, the required behaviour depends on what the node is, as follows:

An element that defines a command: Append the command to the menu. If the element is a command element with a default attribute, mark the command as being a default command.
An hr element
An option element that has a value attribute set to the empty string, and has a disabled attribute, and whose textContent consists of a string of one or more hyphens (U+002D HYPHEN-MINUS): Append a separator to the menu.
An li element: Iterate over the children of the li element.
A menu element with no label attribute
A select element: Append a separator to the menu, then iterate over the children of the menu or select element, then append another separator.
A menu element with a label attribute
An optgroup element: Append a submenu to the menu, using the value of the element's label attribute as the label of the menu. The submenu must be constructed by taking the element and creating a new menu for it using the complete process described in this section.
Any other node: Ignore the node.

Once all the nodes have been processed as described above, the user agent must the post-process the menu as follows:

Any menu item with no label, or whose label is the empty string, must be removed.
Any sequence of two or more separators in a row must be collapsed to a single separator.
Any separator at the start or end of the menu must be removed.

3.4.3. Context menus

The contextmenu attribute associates an element with a menu element.

When an element's context menu is requested (e.g. by the user right-clicking the element, or pressing a context menu key), the UA must fire a contextmenu event on the element for which the menu was requested.

Typically, therefore, the firing of the contextmenu event will be the default action of a mouseup or keyup event. The exact sequence of events is UA-dependent, as it will vary based on platform conventions.

The default action of the contextmenu event depends on whether the element has a context menu assigned (using the contextmenu attribute) or not. If it does not, the default action must be for the user agent to show its default context menu, if it has one.

If the element does have a context menu assigned, then the user agent must fire a show event on the relevant menu element.

The default action of this event is that the user agent must show a context menu built from the menu element.

The user agent may also provide access to its default context menu, if any, with the context menu shown. For example, it could merge the menu items from the two menus together, or provide the page's context menu as a submenu of the default menu.

If the user dismisses the menu without making a selection, nothing in particular happens.

If the user selects a menu item that represents a command, then the UA must invoke that command's Action, as defined above.

Context menus must not, while being shown, reflect changes in the DOM; they are constructed as the default action of the show event and must remain like that until dismissed.

User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus. For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu.

3.4.4. Toolbars

Toolbars are a kind of menu that is always visible.

When a menu element has a type attribute with the value toolbar, then the user agent must build the menu for that menu element and render it in the document in a position appropriate for that menu element.

The user agent must reflect changes made to the menu's DOM immediately in the UI.

3.5. Repetition templates [TBW]

See WF2 for now

4. Browsing contexts

Web browsers and other user agents that display HTML documents to the user in the context of a browsing environment may display one or more views of those documents to the user.

Each set of one or more views is considered a browsing context.

In a tabbed Web browser, for instance, each tab in the browser window represents a browsing context.

A browsing context may have further browsing contexts nested within it; the iframe element, for instance, instantiates a browsing context within the context of a parent document. The lifetime of a nested browsing context is bounded by the lifetime of the document in which it lives, or by the UA if the browsing context does not have a parent document.

A browsing context that does not have a parent document or browsing context is the top-level browsing context for any browsing contexts nested within it (and their documents).

Each browsing context must have a single unique session history, consisting of one or more documents, each represented by an object implementing the DocumentWindow interface.

A document can have more than one entry in the session history of a particular browsing context. All the entries related to a particular DocumentWindow object are contiguous.

Each view of each document in a browsing context must be represented by an object implementing the Window interface. In each set of such objects there is a default view, represented by one of the Window objects, which is the primary output mode of the document (and, for interactive user agents, nominally the user's primary way of interacting with the document).

When a UI event is fired, the view attribute of the UIEvent object must point to the Window object representing the view in which the user triggered the event.

Typically Web browsers only have one view per document, but a Web browser that rendered document to a screen while simultaneously providing a speech synthesis version would be one example where two views were present.

It would be good to have a summary or diagram for the above relationships.

4.1. The `DocumentWindow` interface

The DocumentWindow interface extends the DocumentView interface defined in DOM2 Views. [DOM2VIEWS]

Every Document object that is being rendered in a browsing context must implement the DocumentWindow interface.

interface DocumentWindow : DocumentView {

  // helper objects
           attribute Location location; /* performs magic on setting */
  Selection getSelection();
  readonly attribute HTMLCollection commands;

  // editing
           attribute boolean designMode;
  boolean execCommand(in DOMString commandID);
  boolean execCommand(in DOMString commandID, in boolean doShowUI);
  boolean execCommand(in DOMString commandID, in boolean doShowUI, in DOMString value);
};

The domain of a DocumentWindow object is the domain given by the hostname attribute of the Location object returned by the DocumentWindow object's location attribute, if that hostname attribute is not the empty string. If it is, the domain of the document is UA-defined. For now.

The domain of a script is the domain of the DocumentWindow object that is returned by the document attribute of the script's primary Window object (in UAs that implement ECMAScript, that is the global scope object).

The the string representing the script's domain in IDNA format is obtained as follows: take the script's domain and apply the IDNA ToASCII algorithm and then the IDNA ToUnicode algorithm to each component of the domain name (with both the AllowUnassigned and UseSTD3ASCIIRules flags set both times). [RFC3490] If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then the string representing the script's domain in IDNA format cannot be obtained. (ToUnicode is defined to never fail.)

4.2. The `Window` interface

The Window interface extends the AbstractView interface defined in DOM2 Views. [DOM2VIEWS]

interface Window : AbstractView {

  // self-reference
  readonly attribute Window window;

  // timers
  long setTimeout(in TimeoutHandler handler, in long timeout);
  long setTimeout(in TimeoutHandler handler, in long timeout, arguments...);
  long setTimeout(in DOMString code, in long timeout);
  long setTimeout(in DOMString code, in long timeout, in DOMString language);
  void clearTimeout(in long handle);
  long setInterval(in TimeoutHandler handler, in long timeout);
  long setInterval(in TimeoutHandler handler, in long timeout, arguments...);
  long setInterval(in DOMString code, in long timeout);
  long setInterval(in DOMString code, in long timeout, in DOMString language);
  void clearInterval(in long handle);

  // convenient event handlers
           attribute ErrorHandler onerror;

  // helper objects
  readonly attribute History history;
           attribute Location location; /* performs magic on setting */
  readonly attribute Storage sessionStorage;
  readonly attribute StorageList globalStorage;
  readonly attribute ClientInformation navigator; 
  readonly attribute UndoManager undoManager;
  Selection getSelection();

}; 

interface TimeoutHandler {
  void handleEvent(arguments...);
};

interface ErrorHandler {
  void handleEvent(in DOMString errorMessage, in DOMString fileName, in DOMString lineNumber);
};

Objects implementing the Window interface must also implement the EventTarget interface.

In UAs that expose the DOM to ECMAScript [ECMA262] scripts, the global scope object must implement the Window interface described above.

The window attribute of an object implementing the Window interface must always point to the object itself. In other words, the following equality must also always hold:

x.window == x

...where x is an object implementing the Window interface.

Thus, in ECMAScript, the ECMAScript global object must have a property window pointing at the global object itself.

The document attribute inherited from the AbstractView interface must return the document associated with this view.

4.3. Events

We need a section to define how events all work, default actions, etc. For example, how does clicking on a span in a link that is in another link actually cause a link to be followed? which one? (where should this section be?)

4.4. Focus [WIP]

This entire section will be merged with earlier sections in due course.

When an element is focused, key events are targetted at that element instead of at the document's root element.

4.4.1. The `tabindex` Attribute

This section on the tabindex attribute needs to be checked for backwards-compatibility.

The tabindex attribute defined in HTML4 is extended to apply to all HTML elements by defining it as a common attribute.

The tabindex attribute specifies the relative order of elements for the purposes of sequential focus navigation. The name "tab index" comes from the common use of the "tab" key to navigate through the focusable elements. The term "tabbing" refers to moving forward through the focusable elements.

The tabindex attribute can take any integer (an optional U+002D HYPHEN-MINUS representing negativity followed by one or more digits in the range 0-9, U+0030 to U+0039, interpreted as base ten).

A positive integer (including zero) specifies the index of the element in the current scope's tab order. Elements with the same index are sorted in document order for the purposes of tabbing.

A negative integer specifies that the element should be removed from the tab order. If the element does normally take focus, it may still be focused using other means (e.g. it could be focussed by a click).

Other values are ignored, as if the attribute was absent. Certain elements may default absent tabindex attributes to zero, at the user agent's discretion. (In other words, some elements are focusable by default, and they are assumed to have tab index 0. Text fields will typically be in the tab order by default, for instance.)

When an element that does not normally take focus has the tabindex attribute specified with a positive value, then it is added to the tab order and is made focusable. When focused, the element matches the CSS :focus pseudo-class and key events are dispatched on that element when appropriate, just like focusing a link.

Since all HTML elements can thus be focused and unfocusd, the onfocus and onblur attributes shall also apply to all HTML elements.

4.4.2. The `ElementFocus` interface

The ElementFocus interface contains methods for moving focus to and from an element. It can be obtained from objects that implement the Element interface using binding-specific casting methods.

interface ElementFocus {
           attribute long                    tabIndex;
  void focus();
  void blur();
};

The tabIndex DOM attribute reflects the value of the related content attribute. If the attribute is not present (or has an invalid value) then the DOM attribute should return the UA's default value for that element, typically either 0 (for elements in the tab order) or -1 (for elements not in the tab order).

The focus() and blur() methods focus and unfocus the element respectively, if the element is focusable.

4.4.3. The `DocumentFocus` interface

The DocumentFocus interface contains methods for moving focus around the document. It can be obtained from objects that implement the Document interface using binding-specific casting methods.

interface DocumentFocus {
  readonly attribute Element                 currentFocus;
  void moveFocusForward();
  void moveFocusBackward();
  void moveFocusUp();
  void moveFocusRight();
  void moveFocusDown();
  void moveFocusLeft();
};

The currentFocus attribute returns the element to which key events will be sent when the document receives key events.

The moveFocusForward method uses the 'nav-index' property and the tabindex attribute to find the next focusable element and focuses it.

The moveFocusBackward method uses the 'nav-index' property and the tabindex attribute to find the previous focusable element and focuses it.

The moveFocusUp method uses the 'nav-up' property and the tabindex attribute to find an appropriate focusable element and focuses it.

In a similar manner, the moveFocusRight, moveFocusDown, and moveFocusLeft methods use the 'nav-right', 'nav-down', and 'nav-left' properties (respectively), and the tabindex attribute, to find an appropriate focusable element and focus it.

The 'nav-index', 'nav-up', 'nav-right', 'nav-down', and 'nav-left' properties are defined in [CSS3UI].

4.5. [SCS] Runtime script errors

The onerror attribute takes a reference to an object implementing the ErrorHandler interface. In ECMAScript, such an interface is implemented by any function that takes three arguments and returns a boolean value, as well as by the null value and the undefined value.

The function to which the onerror attributes points must be invoked whenever a runtime script error occurs in the context of the window object, before the error is reported to the user. If the function is null or if the function returns true then the error should not reported to the user. If the function is undefined or if the function doesn't returns true, then the message must be reported as normal.

The three arguments passed to the function are all DOMStrings; the first gives the message that the UA is considering reporting, the second gives the URI to the resource in which the error occured, and the third gives the line number in tha resource on which the error occured.

The initial value of onerror must be undefined.

4.6. [SCS] Timers

The setTimeout and setInterval methods allow authors to schedule timer-based events.

The setTimeout(handler, timeout[, arguments...]) method takes a reference to a TimeoutHandler object and a length of time in milliseconds. It must return a handle to the timeout created, and then asynchronously wait timeout milliseconds and then invoke handleEvent() on the handler object. If any arguments... were provided, they must be passed to the handler as arguments to the handleEvent() function.

In the ECMAScript DOM binding, the ECMAScript native Function type must implement the TimeoutHandler interface such that invoking the handleEvent() method of that interface on the object from another language binding invokes the function itself, with the arguments passed to handleEvent() as the arguments passed to the function. In the ECMAScript binding itself, however, the handleEvent() method of the interface is not directly accessible on Function objects. Such functions must be called in the global scope.

Alternatively, setTimeout(code, timeout[, language]) may be used. This variant takes a string instead of a TimeoutHandler object. That string must be parsed using the specified language (defaulting to ECMAScript if the third argument is omitted) and executed in the global scope.

Need to define language values.

The setInterval(...) variants must work in the same way as the setTimeout variants except that the handler or code must be invoked again every timeout milliseconds, not just the once.

The clearTimeout() and clearInterval() methods take one integer (the value returned by setTimeout and setInterval respectively) and must cancel the specified timeout. When called with a value that does not correspond to an active timeout or interval, the methods must return without doing anything.

Timeouts must never fire while another script is executing. (Thus the HTML scripting model is strictly single-threaded and not reentrant.)

4.7. `document.write()`, `innerHTML` [TBW]

...

4.8. [SCS] Session history and navigation

4.8.1. The session history of browsing contexts

History objects provide a representation of the pages in the session history of their Window object's browsing context. Each browsing context (frame, iframe, etc) has a distinct session history.

Each DocumentWindow object in a browsing context's session history is associated with a unique instance of the History object, although they all must model the same underlying session history.

The history attribute of the Window interface must return the object implementing the History interface for that Window object's associated DocumentWindow object.

History objects represent their browsing context's session history as a flat list of URIs and state objects. (This does not imply that the UI need be linear. See the notes below.)

Typically, the history list will consist of only URIs. However, a page can add state objects between its entry in the session history and the next ("forward") entry. These are then returned to the script when the user (or script) goes back in the history, thus enabling authors to use the "navigation" metaphor even in one-page applications.

Entries that consist of state objects share the same DocumentWindow as the entry for the URI itself. Contiguous entries that differ just by fragment identifier must also share the same DocumentWindow.

All entries that share the same DocumentWindow (and that are therefore merely different states of one particular document) are contiguous by definition.

At any point, one of the entries in the session history is the current entry. This is the entry representing the page in this browsing context that is considered the "current" page by the UA. The current entry is usually an entry for the location of the DocumentWindow. However, it can also be one of the entries for state objects added to the history by that document.

When the browser's navigation model differs significantly from the sequential model represented by the History interface, for example if separate DocumentWindow objects in the session history are all simulatenously displayed and active, then the current entry could even be an entry unrelated to the History object's own DocumentWindow object. If, when a method is invoked on a History object, the current entry for that browsing context's session history has a different DocumentWindow object than the History object's own DocumentWindow object, then the user agent must raise a NO_MODIFICATION_ALLOWED_ERR DOM exception. (This can only happen if scripts are allowed to run in documents that are not the current document. Typically, however, user agents only allow scripts from the current entry to execute.)

User agents may discard the DOMs of entries other than the current entry, reloading the pages afresh when the user or script navigates back to such pages. This specification does not specify when user agents should discard pages' DOMs and when they should cache them. See the section on the load and unload events for more details.

Entries that have had their DOM discarded must, for the purposes of the algorithms given below, act as if they had not. When the user or script navigates back or forwards to a page which has no in-memory DOM objects, any other entries that shared the same DocumentWindow object with it must share the new object as well.

When a user agent discards the DOM from an entry in the session history, it must also discard all the entries from the first state object entry for that DocumentWindow object up to and including the last entry for that DocumentWindow object (including any non-state-object entries in that range, such as entries where the user navigated using fragment identifiers). These entries are not recreated if the user or script navigates back to the page. If there are no state object entries for that DocumentWindow object then no entries are removed.

4.8.2. The `History` interface

interface History {
  readonly attribute long length;
  void go(in long delta);
  void go();
  void back();
  void forward();
  void pushState(in DOMObject data);
  void clearState();
};

The length attribute of the History interface must return the number of entries in this session history.

The actual entries are not accessible from script.

The go(delta) method causes the UA to move the number of steps specified by delta in the session history.

If the index of the current entry plus delta is less than zero or greater than or equal to the number of items in the session history, then the user agent must do nothing.

If the delta is zero, then the user agent must act as if the location.reload() method was called instead.

Otherwise, the user agent must cause the current browsing context to navigate to the specified entry, as described below. The specified entry is the one whose index equals the index of the current entry plus delta.

If there are any entries with state objects between the current entry and the specified entry (not inclusive), then the user agent must iterate through every entry between the current entry and the specified entry, starting with the entry closest to the current entry, and ending with the one closest to the specified entry. For each entry, if the entry is a state object, the user agent must activate the state object.

If the specified entry has a different DocumentWindow object than the current entry then the user agent must make that DocumentWindow object the user's "current" one for that browsing context.

If the specified entry is a state object, the user agent must activate that state object. Otherwise, the user agent must update the current location object to the new location.

User agents may also update other aspects of the document view when the location changes in this way, for instance the scroll position, values of form fields, etc.

When the user navigates through a browsing context, e.g. using a browser's back and forward buttons, the user agent must translate this action into the equivalent invocations of the history.go(delta) method on the various affected window objects.

Some of the other members of the History interface are defined in terms of the go() method, as follows:

Member	Definition
`go()`	Must do the same as `go(0)`
`back()`	Must do the same as `go(-1)`
`forward()`	Must do the same as `go(1)`

The pushState(data) method adds a state object to the history.

When this method is invoked, the user agent must first remove from the session history any entries for that DocumentWindow from the entry after the current entry up to the last entry in the session history that references the same DocumentWindow object, if any. If the current entry is the last entry in the session history, or if there are no entries after the current entry that reference the same DocumentWindow object, then no entries are removed.

Then, the user agent must add a state object entry to the session history, after the current entry, with the specified data as the state object.

Finally, the user agent must update the current entry to be the this newly added entry.

There has been a suggestion that pushState() should take a URI and a string; the URI to allow for the page to be bookmarked, and the string to allow the UA to give the page a meaningful title in the history state, if it shows history state.

User agents may limit the number of state objects added to the session history per page. If a page hits the UA-defined limit, user agents must remove the entry immediately after the first entry for that DocumentWindow object in the session history after having added the new entry. (Thus the state history acts as a FIFO buffer for eviction, but as a LIFO buffer for navigation.)

The clearState() method removes all the state objects for the DocumentWindow object from the session history.

When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that DocumentWindow object up to the last entry that references that same DocumentWindow object, if any.

Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that DocumentWindow object in the session history.

4.8.3. Activating state objects

When a state object in the session history is activated (which happens in the cases described above), the user agent must fire a popstate event in the http://www.w3.org/2001/xml-events namespace on the the body element using the PopStateEvent interface, with the state object in the state attribute. This event bubbles but is not cancelable and has no default action.

If there is no "the body element" then the event must be fired on the document's Document object instead.

interface PopStateEvent : Event {
  readonly attribute DOMObject state;
  void               initPopStateEvent(in DOMString typeArg, 
                                       in boolean canBubbleArg, 
                                       in boolean cancelableArg, 
                                       in DOMObject statetArg);
  void               initPopStateEventNS(in DOMString namespaceURIArg,
                                         in DOMString typeArg, 
                                         in boolean canBubbleArg, 
                                         in boolean cancelableArg, 
                                         in DOMObject stateArg);
};

The initPopStateEvent() and initPopStateEventNS() methods must initialise the event in a manner analogous to the similarly-named methods in the DOM3 Events interfaces. [DOM3EVENTS]

The state attribute represents the context information for the event.

4.8.4. The `Location` interface

The location attribute of the Window interface must return an object implementing the Location interface.

For historical reasons, the location attribute of the DocumentWindow interface must return the same object as the location attribute on its associated Window object.

Location objects provide a representation of the URI of their document, and allow the current entry of the browsing context's session history to be changed, by adding or replacing entries in the history object.

interface Location {
  readonly attribute DOMString hash;
  readonly attribute DOMString host;
  readonly attribute DOMString hostname;
  readonly attribute DOMString href;
  readonly attribute DOMString pathname;
  readonly attribute DOMString port;
  readonly attribute DOMString protocol;
  readonly attribute DOMString search; 
  void assign(in DOMString url);
  void replace(in DOMString url);
  void reload();
};

In the ECMAScript DOM binding, objects implementing this interface must stringify to the same value as the href attribute.

In the ECMAScript DOM binding, the location members of the DocumentWindow and Window interfaces behave as if they had a setter: user agents must treats attempts to set these location attribute as attempts at setting the href attribute of the relevant Location object instead.

The href attribute returns the address of the page represented by the associated DocumentWindow object, as an absolute IRI reference.

On setting, the user agent must act as if the assign() method had been called with the new value as its argument.

When the assign(url) method is invoked, the UA must remove all the entries after the current entry in its DocumentWindow's History object, add a new entry, with the given url, at the end of the list (asynchronously loading the new page if necessary), and then advance to that page as if the history.forward() method had been invoked.

When the replace(url) method is invoked, the UA must act as if the assign() method had been invoked, but with the additional step of removing the entry that was the current entry before the method call after the above steps (thus simply causing the current page to be replaced by the new one).

In both cases, if the location before the method call would differ from the location after the method only in terms of the fragment identifier, then the user agent must use the same DocumentWindow object, updating only the scroll position in the document's view(s) appropriately.

Relative url arguments for assign() and replace() must be resolved relative to the base URI of the script that made the method call.

The component parts and .reload() are yet to be defined. If anyone can come up with a decent definition, let me know.

4.8.5. Implementation notes for session history

This section is non-normative.

The History interface is not meant to place restrictions on how implementations represent the session history to the user.

For example, session history could be implemented in a tree-like manner, with each page having multiple "forward" pages. This specification doesn't define how the linear list of pages in the history object are derived from the actual session history as seen from the user's perspective.

Similarly, a page containing two iframes has a history object distinct from the iframes' history objects, despite the fact that typical Web browsers present the user with just one "Back" button, with a session history that interleaves the navigation of the two inner frames and the outer page.

Security: It is suggested that to avoid letting a page "hijack" the history navigation facilities of a UA by abusing pushState(), the UA provide the user with a way to jump back to the previous page (rather than just going back to the previous state). For example, the back button could have a drop down showing just the pages in the session history, and not showing any of the states. Similarly, an aural browser could have two "back" commands, one that goes back to the previous state, and one that jumps straight back to the previous page.

In addition, a user agent could ignore calls to pushState() that are invoked on a timer, or from event handlers that do not represent a clear user action, or that are invoked in rapid succession.

4.9. [SCS] Client-side session and persistent storage

4.9.1. Introduction

This section is non-normative.

This specification introduces two related mechanisms, similar to HTTP session cookies [RFC2965], for storing structured data on the client side.

The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.

Cookies don't really handle this case well. For example, a user could be buying plane tickets in two different windows, using the same site. If the site used cookies to keep track of which ticket the user was buying, then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same flight without really noticing.

To address this, this specification introduces the sessionStorage DOM attribute. Sites can add data to the session storage, and it will be accessible to any page from that domain opened in that window.

For example, a page could have a checkbox that the user ticks to indicate that he wants insurance:

<label>
 <input type="checkbox" onchange="sessionStorage.insurance = checked">
 I want insurance on this trip.
</label>

A later page could then check, from script, whether the user had checked the checkbox or not:

if (sessionStorage.insurance) { ... }

If the user had multiple windows opened on the site, each one would have its own individual copy of the session storage object.

The second storage mechanism is designed for storage that spans multiple windows, and lasts beyond the current session. In particular, Web applications may wish to store megabytes of user data, such as entire user-authored documents or a user's mailbox, on the clientside for performance reasons.

Again, cookies do not handle this case well, because they are transmitted with every request.

The globalStorage DOM attribute is used to access the global storage areas.

The site at example.com can display a count of how many times the user has loaded its page by putting the following at the bottom of its page:

<p>
  You have viewed this page
  <span id="count">an untold number of</span>
  time(s).
</p>
<script>
  var storage = globalStorage['example.com'];
  if (!storage.pageLoadCount)
    storage.pageLoadCount = 0;
  storage.pageLoadCount += 1;
  document.getElementById('count').textContent = storage.pageLoadCount;
</script>

Each domain and each subdomain has its own separate storage area. Subdomains can access the storage areas of parent domains, and domains can access the storage areas of subdomains.

globalStorage[''] is accessible to all domains.
globalStorage['com'] is accessible to all .com domains
globalStorage['example.com'] is accessible to example.com and any of its subdomains
globalStorage['www.example.com'] is accessible to www.example.com and example.com, but not www2.example.com.

Storage areas (both session storage and global storage) store strings. To store structured data in a storage area, you must first convert it to a string.

4.9.2. The `Storage` interface

interface Storage {
  readonly attribute unsigned long length;
  DOMString key(in unsigned long index);
  StorageItem getItem(in DOMString key);
  void setItem(in DOMString key, in DOMString data);
  void removeItem(in DOMString key);
};

Each Storage object provides access to a list of key/value pairs, which are sometimes called items. Keys are strings, and any string (including the empty string) is a valid key. Values are strings with associated metadata, represented by StorageItem objects.

Each Storage object is associated with a list of key/value pairs when it is created, as defined in the sections on the sessionStorage and globalStorage attributes. Multiple separate objects implementing the Storage interface can all be associated with the same list of key/value pairs simultaneously.

Key/value pairs have associated metadata. In particular, a key/value pair can be marked as either "safe only for secure content", or as "safe for both secure and insecure content".

A key/value pair is accessible if either it is marked as "safe for both secure and insecure content", or it is marked as "safe only for secure content" and the script in question is running in a secure scripting context.

The length attribute must return the number of key/value pairs currently present and accessible in the list associated with the object.

The key(n) method must return the name of the nth accessible key in the list. The order of keys is user-agent defined, but must be consistent within an object between changes to the number of keys. (Thus, adding or removing a key may change the order of the keys, but merely changing the value of an existing key must not.) If n is less than zero or greater than or equal to the number of key/value pairs in the object, then this method must raise an INDEX_SIZE_ERR exception.

The getItem(key) method must return the StorageItem object representing the key/value pair with the given key. If the given key does not exist in the list associated with the object, or is not accessible, then this method must return null. Subsequent calls to this method with the same key must return different instances of the StorageItem interface.

The setItem(key, value) method must first check if a key/value pair with the given key already exists in the list associated with the object.

If it does not, then a new key/value pair must be added to the list, with the given key and value, such that any current or future StorageItem objects referring to this key/value pair will return the value given in the value argument. If the script setting the value is running in a secure scripting context, then the key/value pair must be marked as "safe only for secure content", otherwise it must be marked as "safe for both secure and insecure content".

If the given key does exist in the list, then, if the key/value pair with the given key is accessible, it must have its value updated so that any current or future StorageItem objects referring to this key/value pair will return the value given in the value argument. If it is not accessible, the method must raise a security exception.

When the setItem() method is successfully invoked (i.e. when it doesn't raise an exception), events are fired on other DocumentWindow objects that can access the newly stored data, as defined in the sections on the sessionStorage and globalStorage attributes.

The removeItem(key) method must cause the key/value pair with the given key to be removed from the list associated with the object, if it exists and is accessible. If no item with that key exists, the method must do nothing. If an item with that key exists but is not accessible, the method must raise a security exception.

The setItem() and removeItem() methods must be atomic with respect to failure. That is, changes to the data storage area must either be successful, or the data storage area must not be changed at all.

In the ECMAScript binding, enumerating a Storage object must enumerate through the currently stored and accessible keys in the list the object is associated with. (It must not enumerate the values or the actual members of the interface). In the ECMAScript binding, Storage objects must support dereferencing such that getting a property that is not a member of the object (i.e. is neither a member of the Storage interface nor of Object) must invoke the getItem() method with the property's name as the argument, and setting such a property must invoke the setItem() method with the property's name as the first argument and the given value as the second argument.

4.9.3. The `StorageItem` interface

Items in Storage objects are represented by objects implementing the StorageItem interface.

interface StorageItem {
           attribute boolean secure;
           attribute DOMString value;
};

In the ECMAScript binding, StorageItem objects must stringify to their value attribute's value.

The value attribute must return the current value of the key/value pair represented by the object. When the attribute is set, the user agent must invoke the setItem() method of the Storage object that the StorageItem object is associated with, with the key that the StorageItem object is associated with as the first argument, and the new given value of the attribute as the second argument.

StorageItem objects must be live, meaning that as the underlying Storage object has its key/value pairs updated, the StorageItem objects must always return the actual value of the key/value pair they represent.

If the key/value pair has been deleted, the StorageItem object must act as if its value was the empty string. On setting, the key/value pair will be recreated.

The secure attribute must raise an INVALID_ACCESS_ERR exception when accessed or set from a script whose script context is not considered secure. (Basically, if the page is not an SSL page.)

If the scripting context is secure, then the secure attribute must return true if the key/value pair is considered "safe only for secure content", and false if it is considered "safe for both secure and insecure content". If it is set to true, then the key/value pair must be flagged as "safe only for secure content". If it is set to false, then the key/value pair must be flagged as "safe for both secure and insecure content".

If a StorageItem object is obtained by a script that is not running in a secure scripting context, and the item is then marked with the "safe only for secure content" flag by a script that is running in a secure context, the StorageItem object must continue to be available to the first script, who will be able to read the value of the object. However, any attempt to set the value would then start raising exceptions as described in the previous section, and the key/value pair would no longer appear in the appropriate Storage object.

4.9.4. The `sessionStorage` attribute

The sessionStorage attribute represents the storage area specific to the current top-level browsing context.

Each top-level browsing context has a unique set of session storage areas, one for each domain.

User agents should not expire data from a browsing context's session storage areas, but may do so when the user requests that such data be deleted, or when the UA detects that it has limited storage space, or for security reasons. User agents should always avoid deleting data while a script that could access that data is running. When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user) the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever be subsequently retrieved.

The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.

When a new DocumentWindow is created, the user agent must check to see if the document's top-level browsing context has allocated a session storage area for that document's domain. If it has not, a new storage area for that document's domain must be created.

The Storage object for the document's associated Window object's sessionStorage attribute must then be associated with the domain's session storage area.

When a new top-level browsing context is created by cloning an existing browsing context, the new browsing context must start with the same session storage areas as the original, but the two sets must from that point on be considered separate, not affecting each other in any way.

When a new top-level browsing context is created by a script in an existing browsing context, or by the user following a link in an existing browsing context, or in some other way related to a specific DocumentWindow, then, if the new context's first DocumentWindow has the same domain as the DocumentWindow from which the new context was created, the new browsing context must start with a single session storage area. That storage area must be a copy of that domain's session storage area in the original browsing context, which from that point on must be considered separate, with the two storage areas not affecting each other in any way.

When the setItem() method is called on a Storage object x that is associated with a session storage area, then, if the method does not raise a security exception, in every DocumentWindow object whose Window object's sessionStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired, as described below.

4.9.5. The `globalStorage` attribute

interface StorageList {
  Storage namedItem(in DOMString domain);
};

The globalStorage object provides a Storage object for each domain.

In the ECMAScript binding, StorageList objects must support dereferencing such that getting a property that is not a member of the object (i.e. is neither a member of the StorageList interface nor of Object) must invoke the namedItem() method with the property's name as the argument.

User agents must have a set of global storage areas, one for each domain.

User agents should only expire data from the global storage areas for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running. Data stored in global storage areas should be considered potentially user-critical. It is expected that Web applications will use the global storage areas for storing user-written documents.

The namedItem(domain) method tries to returns a Storage object associated with the given domain, according to the rules that follow.

The domain must first be split into an array of strings, by splitting the string at "." characters (U+002E FULL STOP). If the domain argument is the empty string, then the array is empty as well. If the domain argument is not empty but has no dots, then the array has one item, which is equal to the domain argument. If the domain argument contains consecutive dots, there will be empty strings in the array (e.g. the string "hello..world" becomes split into the three strings "hello", "", and "world", with the middle one being the empty string).

Each component of the array must then have the IDNA ToASCII algorithm applied to it, with both the AllowUnassigned and UseSTD3ASCIIRules flags set. [RFC3490] If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then the user agent must raise a SYNTAX_ERR exception. [DOM3CORE] The components after this step consist of only US-ASCII characters.

The components of the array must then be converted to lowercase. Since only US-ASCII is involved at this step, this only requires converting characters in the range A-Z to the corresponding characters in the range a-z.

The resulting array is used in a comparison with another array, as described below. In addition, its components are concatenated together, each part separated by a dot (U+002E), to form the normalised requested domain.

If the original domain was "Åsgård.Example.Com", then the resulting array would have the three items "xn--sgrd-poac", "example", and "com", and the normalised requested domain would be "xn--sgrd-poac.example.com".

Next, the script's own domain is processed to find if it is allowed to access the requested domain.

If the script's domain name in not known, e.g. if only the server's IP address is known, and the normalised requested domain is not the empty string, then the user agent must raise a security exception.

If the normalised requested domain is the empty string, then the rest of this algorithm can be skipped. This is because in that situation, the comparison of the two arrays below will always find them to be the same — the first array in such a situation is also empty and so permission to access that storage area will always be given.

If the script's domain contains no dots (U+002E) then the string ".localdomain" must be appended to the script's domain.

Then, the script's domain must be turned into an array, being split, converted to ASCII, and lowercased as described for the domain argument above.

Of the two arrays, the longest one must then be shortened to the length of the shorter one, by dropping items from the start of the array.

If the domain argument is "www.example.com" and the script's domain is "example.com" then the first array will be a three item array ("www", "example", "com"), and the second will be a two item array ("example", "com"). The first array is therefore shortened, dropping the leading parts, making both into the same array ("example", "com").

If the two arrays are not component-for-component identical in literal string comparisons, then the user agent must then raise a security exception.

Otherwise, the user agent must check to see if it has allocated global storage area for the normalised requested domain. If it has not, a new storage area for that domain must be created.

The user agent must then create a Storage object associated with that domain's global storage area, and return it.

When the requested domain is a top level domain, or the empty string, or a country-specific sub-domain like "co.uk" or "ca.us", the associated global storage area is known as public storage area

The setItem() method might be called on a Storage object that is associated with a global storage area for a domain d, created by a StorageList object associated with a Window object x. Whenever this occurs, if the method didn't raise an exception, a storage event must be fired, as described below, in every DocumentWindow object that matches the following conditions:

Its Window object is not x, and
Its Window object's globalStorage attribute's StorageList object's namedItem() method would not raise a security exception according to the rules above if it was invoked with the domain d.

In other words, every other document that has access to that domain's global storage area is notified of the change.

4.9.6. The `storage` event

The storage event is fired in a DocumentWindow when a storage area changes, as described in the previous two sections (for session storage, for global storage).

When this happens, a storage event in the http://www.w3.org/2001/xml-events namespace, which bubbles, is not cancelable, has no default action, and which uses the StorageEvent interface described below, must be fired on the body element, or, if there isn't one, on the DocumentWindow object itself.

However, it is possible (indeed, for session storage areas, likely) that the target DocumentWindow object is not active at that time. For example, it might not be the current entry in the session history; user agents typically stop scripts from running in pages that are in the history. In such cases, the user agent must instead delay the firing of the event until such time as the DocumentWindow object in question becomes active again.

When there are multiple delayed storage events for the same DocumentWindow object, user agents should coalesce events with the same domain value (dropping duplicates).

If the DOM of a page that has delayed storage events queued up is discarded, then the delayed events are dropped as well.

interface StorageEvent : Event {
  readonly attribute DOMString domain;
  void               initStorageEvent(in DOMString typeArg, 
                                      in boolean canBubbleArg, 
                                      in boolean cancelableArg, 
                                      in DOMString domainArg);
  void               initStorageEventNS(in DOMString namespaceURIArg,
                                        in DOMString typeArg, 
                                        in boolean canBubbleArg, 
                                        in boolean cancelableArg, 
                                        in DOMString domainArg);
};

The initStorageEvent() and initStorageEventNS() methods must initialise the event in a manner analogous to the similarly-named methods in the DOM3 Events interfaces. [DOM3EVENTS]

The domain attribute of the StorageEvent event object must be set to the name of the domain associated with the storage area that changed if that storage area is a global storage area, or the string "#session" if it was a session storage area.

4.9.7. Miscellaneous implementation requirements for storage areas

4.9.7.1. Disk space

User agents should limit the total amount of space allowed for a domain based on the domain of the page setting the value.

User agents should not limit the total amount of space allowed on a per-storage-area basis, otherwise a site could just store data in any number of subdomains, e.g. storing up to the limit in a1.example.com, a2.example.com, a3.example.com, etc, circumventing per-domain limits.

User agents should consider additional quota mechanisms (for example limiting the amount of space provided to a domain's subdomains as a group) so that hostile authors can't run scripts from multiple subdomains all adding data to the global storage area in an attempted denial-of-service attack.

User agents may prompt the user when per-domain space quotas are reached, allowing the user to grant a site more space. This enables sites to store many user-created documents on the user's computer, for instance.

User agents should allow users to see how much space each domain is using.

If the storage area space limit is reached during a setItem() call, the user agent should raise an exception.

A mostly arbitrary limit of five megabytes per domain is recommended. Implementation feedback is welcome and will be used to update this suggestion in future.

4.9.7.2. Threads

Multiple browsing contexts must be able to access the global storage areas simultaneously in a predictable manner. Scripts must not be able to detect any concurrent script execution.

This is required to guarentee that the length attribute of a Storage object never changes while a script is executing, other than in a way that is predictable by the script itself.

There are various ways of implementing this requirement. One is that if a script running in one browsing context accesses a global storage area, the UA blocks scripts in other browsing contexts when they try to access any global storage area until the first script has executed to completion. (Similarly, when a script in one browsing context accesses its session storage area, any scripts that have the same top level browsing context and the same domain would block when accessing their session storage area until the first script has executed to completion.) Another (potentially more efficient but probably more complex) implementation strategy is to use optimistic transactional script execution. This specification does not require any particular implementation strategy, so long as the requirement above is met.

4.9.8. Security and privacy

4.9.8.1. User tracking

A third-party advertiser (or any entity capable of getting content distributed to multiple sites) could use a unique identifier stored in its domain's global storage area to track a user across multiple sessions, building a profile of the user's interests to allow for highly targetted advertising. In conjunction with a site that is aware of the user's real identity (for example an e-commerce site that requires authenticated credentials), this could allow oppressive groups to target individuals with greater accuracy than in a world with purely anonymous Web usage.

The globalStorage object also introduces a way for sites to cooperate to track users over multiple domains, by storing identifying data in "public" top-level domain storage area, accessible by any domain.

There are a number of techniques that can be used to mitigate the risk of user tracking:

Blocking third-party storage: user agents may restrict access to the globalStorage object to scripts originating at the domain of the top-level document of the browsing context.

This blocks a third-party site from using its private storage area for tracking a user, but top-level sites could still cooperate with third parties to perferm user tracking by using the "public" storage area.
Expiring stored data: user agents may automatically delete stored data after a period of time.

For example, a user agent could treat the global storage area as session-only storage, deleting the data once the user had closed all the browsing contexts that could access it.

This can restrict the ability of a site to track a user, as the site would then only be able to track the user across multiple sessions when he authenticates with the site itself (e.g. by making a purchase or logging in to a service).
Blocking access to the top-level domain ("public") storage areas: user agents may prevent domains from storing data in and reading data from the top-level domain entries in the globalStorage object.

In practice this requires a detailed list of all the "public" second-level (and third-level) domains. For example, content at the domain www.example.com would be allowed to access example.com data but not com data; content at the domain example.co.uk would be allowed access to example.co.uk but not co.uk or uk; and content at example.chiyoda.tokyo.jp would be allowed access to example.chiyoda.tokyo.jp but not chiyoda.tokyo.jp, tokyo.jp, or jp, while content at example.metro.tokyo.jp would be allowed access to both example.metro.tokyo.jp and metro.tokyo.jp but not tokyo.jp or jp. The problem is even more convoluted when one considers private domains with third-party subdomains such as dyndns.org or uk.com.

Blocking access to the "public" storage areas can also prevent innocent sites from cooperating to provide services beneficial to the user.
Treating persistent storage as cookies: user agents may present the persistent storage feature to the user in a way that does not distinguish it from HTTP session cookies. [RFC2965]

This might encourage users to view persistent storage with healthy suspicion.
Site-specific white-listing of access to "public" storage area: user agents may allow sites to access persistent storage for their own domain and subdomains in an unrestricted manner, but require the user to authorise access to the storage area of higher-level domains.

For example, code at example.com would be always allowed to read and write data for www.example.com and example.com, but if it tried to access com, the user agent could display a non-modal message informing the user that the page requested access to com and offering to allow it.
Origin-tracking of persistent storage data: user agents may record the domain of the script that caused data to be stored.

If this information is then used to present the view of data currently in persistent storage, it would allow the user to make informed decisions about which parts of the persistent storage to prune. Combined with a blacklist ("delete this data and prevent this domain from ever storing data again"), the user can restrict the use of persistent storage to sites that he trusts.
Shared blacklists: user agents may allow users to share their persistent storage domain blacklists.

This would allow communities to act together to protect their privacy.

While these suggestions prevent trivial use of this API for user tracking, they do not block it altogether. Within a single domain, a site can continue to track the user across multiple sessions, and can then pass all this information to the third party along with any identifying information (names, credit card numbers, addresses) obtained by the site. If a third party cooperates with multiple sites to obtain such information, a profile can still be created.

However, user tracking is to some extent possible even with no cooperation from the user agent whatsoever, for instance by using session identifiers in URIs, a technique already commonly used for innocuous purposes but easily repurposed for user tracking (even retroactively). This information can then be shared with other sites, using using visitors' IP addresses and other user-specific data (e.g. user-agent headers and configuration settings) to combine separate sessions into coherent user profiles.

If the user interface for persistent storage presents data in the persistent storage feature separately from data in HTTP session cookies, then users are likely to delete data in one and not the other. This would allow sites to use the two features as redundant backup for each other, defeating a user's attempts to protect his privacy.

4.9.8.3. Integrity of "public" storage areas

Since the "public" global storage areas are accessible by content from many different parties, it is possible for third-party sites to delete or change information stored in those areas in ways that the originating sites may not expect.

Authors must not use the "public" global storage areas for storing sensitive data. Authors must not trust information stored in "public" global storage areas.

4.9.8.4. Cross-protocol and cross-port attacks

This API makes no distinction between content served over HTTP, FTP, or other host-based protocols, and does not distinguish between content served from different ports at the same host.

Thus, for example, data stored in the global persistent storage for domain "www.example.com" by a page served from HTTP port 80 will be available to a page served in http://example.com/:18080, even if the latter is an experimental server under the control of a different user.

Since the data is not sent over the wire by the user agent, this is not a security risk in its own right. However, authors must take proper steps to ensure that all hosts that have fully qualified host names that are subsets of hosts dealing with sensitive information are as secure as the originating hosts themselves.

Similarly, authors must ensure that all Web servers on a host, regardless of the port, are equally trusted if any of them are to use persistent storage. For instance, if a Web server runs a production service that makes use of the persistent storage feature, then other users that have access to that machine and that can run a Web server on another port will be able to access the persistent storage added by the production service (assuming they can trick a user into visiting their page).

However, if one is able to trick users into visiting a Web server with the same host name but on a different port as a production service used by these users, then one could just as easily fake the look of the site and thus trick users into authenticating with the fake site directly, forwarding the request to the real site and stealing the credentials in the process. Thus, the persistent storage feature is considered to only minimally increase the risk involved.

4.9.8.5. DNS spoofing attacks

Because of the potential for DNS spoofing attacks, one cannot guarentee that a host claiming to be in a certain domain really is from that domain. The secure attribute is provided to mark certain key/value pairs as only being accessible to pages that have been authenticated using secure certificates (or similar mechanisms).

Authors must ensure that they do not mark sensitive items as "safe for both secure and insecure content". (To prevent the risk of a race condition, data stored by scripts in secure contexts default to being marked as "safe only for secure content".)

4.9.8.6. Cross-directory attacks

Different authors sharing one host name, for example users hosting content on geocities.com, all share one persistent storage object. There is no feature to restrict the access by pathname. Authors on shared hosts are therefore recommended to avoid using the persistent storage feature, as it would be trivial for other authors to read from and write to the same storage area.

Even if a path-restriction feature was made available, the usual DOM scripting security model would make it trivial to bypass this protection and access the data from any path.

4.9.8.7. Implementation risks

The two primary risks when implementing this persistent storage feature are letting hostile sites read information from other domains, and letting hostile sites write information that is then read from other domains.

Letting third-party sites read data that is not supposed to be read from their domain causes information leakage, For example, a user's shopping wishlist on one domain could be used by another domain for targetted advertising; or a user's work-in-progress confidential documents stored by a word-processing site could be examined by the site of a competing company.

Letting third-party sites write data to the storage areas of other domains can result in information spoofing, which is equally dangerous. For example, a hostile site could add items to a user's wishlist; or a hostile site could set a user's session identifier to a known ID that the hostile site can then use to track the user's actions on the victim site.

A risk is also presented by servers on local domains having host names matching top-level domain names, for instance having a host called "com" or "net". Such hosts might, if implementations fail to correctly implement the .localdomain suffixing, have full access to all the data stored in a UA's persistent storage for that top level domain.

Thus, strictly following the model described in this specification is important for user security.

4.10. Browser state

The navigator attribute of the Window interface must return an instance of the ClientInformation interface, which represents the identity and state of the user agent (the client), and allows Web pages to register themselves as potential protocol and content handlers:

interface ClientInformation {
  readonly attribute boolean onLine;
  void registerProtocolHandler(in DOMString protocol, in DOMString uri, in DOMString title);
  void registerContentHandler(in DOMString mimeType, in DOMString uri, in DOMString title);
};

4.10.1. [SCS] Offline Web applications

The navigator.onLine attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page (or knows that such an attempt would fail), and must return true otherwise.

The offline event must be fired when the value of the navigator.onLine attribute of the Window changes from true to false.

The online event must be fired when the value of the navigator.onLine attribute of the Window changes from false to true.

These events are in the http://www.w3.org/2001/xml-events namespace, do bubble, are not cancelable, have no default action, and use the normal Event interface. They must be fired on the body element, or, if there isn't a "the body element", on the DocumentWindow object. (As the events bubble, they will reach the Window object.)

4.10.2. [SCS] Custom protocol and content handlers

The registerProtocolHandler() method allows Web sites to register themselves as possible handlers for particular protocols. For example, an online fax service could register itself as a handler of the fax: protocol ([RFC2806]), so that if the user clicks on such a link, he is given the opportunity to use that Web site. Analogously, the registerContentHandler() method allows Web sites to register themselves as possible handlers for content in a particular MIME type. For example, the same online fax service could register itself as a handler for image/g3fax files ([RFC1494]), so that if the user has no native application capable of handling G3 Facsimile byte streams, his Web browser can instead suggest he use that site to view the image.

The arguments to the methods have the following meanings:

protocol (registerProtocolHandler() only)

A scheme, such as ftp or fax. The scheme must be treated case-insensitively by user agents for the purposes of comparing with the scheme part of URIs that they consider against the list of registered handlers.

The protocol value, if it contains a colon (as in "ftp:"), will never match anything, since schemes don't contain colons.

mimeType (registerContentHandler() only)

A MIME type, such as model/vrml or text/richtext. The MIME type must be treated case-insensitively by user agents for the purposes of comparing with MIME types of documents that they consider against the list of registered handlers.

User agents must compare the given values only to the MIME type/subtype parts of content types, not to the complete type including parameters. Thus, if mimeType values passed to this method include characters such as commas or whitespace, or include MIME parameters, then the handler being registered will never be used.

uri

The URI of the page that will handle the requests. When the user agent uses this URI, it must replace the first occurrence of the exact literal string "%s" with an escaped version of the URI of the content in question (as defined below), and then fetch the resulting URI using the GET method (or equivalent for non-HTTP URIs).

To get the escaped version of the URI, first, the domain part of the URI (if any) must be converted to its punycode representation, and then, every character in the URI that is not in the ranges given in the next paragraph must be replaced by its UTF-8 byte representation, each byte being represented by a U+0025 (%) character and two digits in the range U+0030 (0) to U+0039 (9) and U+0041 (A) to U+0046 (F) giving the hexadecimal representation of the byte.

The ranges of characters that must not be escaped are: U+002D (-), U+002E (.), U+0030 (0) to U+0039 (9), U+0041 (A) to U+005A (Z), U+005F (_), U+0061 (a) to U+007A (z), and U+007E (~).

If the user had visited a site that made the following call:

navigator.registerContentHandler('application/x-soup', 'http://example.com/soup?url=%s', 'SoupWeb™')

...and then clicked on a link such as:

<a href="http://www.example.net/chickenkïwi.soup">Download our Chicken Kiwi soup!</a>

...then, assuming this chickenkiwi.soup file was served with the MIME type application/x-soup, the UA might instead navigate to the following URI:

http://example.com/soup?url=http%3A%2F%2Fwww.example.net%2Fchickenk%C3%AFwi.soup

This site could then fetch the chickenkiwi.soup file and do whatever it is that it does with soup (synthesise it and ship it to the user, or whatever).

title

A descriptive title of the handler, which the UA might use to remind the user what the site in question is.

User agents may, within the constraints described in this section, do whatever they like when the methods are called. A UA could, for instance, prompt the user and offer the user the opportunity to add the site to a shortlist of handlers, or make the handlers his default, or cancel the request. UAs could provide such a UI through modal UI or through a non-modal transient notification interface. UAs could also simply silently collect the information, providing it only when relevant to the user.

User agents should raise security exceptions if the methods are called with protocol or mimeType values that the UA deems to be "privileged". For example, a site attempting to register a handler for http URIs or text/html content in a Web browser would likely cause an exception to be raised.

User agents must raise a SYNTAX_ERR exception if the uri argument passed to one of these methods does not contain the exact literal string "%s".

User agents must not raise any other exceptions (other than binding-specific exceptions, such as for an incorrect number of arguments in an ECMAScript implementation).

This section does not define how the pages registered by these methods are used, beyond the requirements on how to process the uri value (see above). To some extent, the processing model for navigating across documents defines some cases where these methods are relevant, but in general UAs may use this information wherever they would otherwise consider handing content to native plugins or helper applications.

UAs must not use registered content handlers to handle content that was returned as part of a non-GET transaction (or rather, as part of any non-idempotent transaction), as the remote site would not be able to fetch the same data.

4.10.2.1. Security and privacy

These mechanisms can introduce a number of concerns, in particular privacy concerns.

Hijacking all Web usage. User agents should not allow protocols that are key to its normal operation, such as http or https, to be rerouted through third-party sites. This would allow a user's activities to be trivially tracked, and would allow user information, even in secure connections, to be collected.

Hijacking defaults. It is strongly recommended that user agents do not automatically change any defaults, as this could lead the user to send data to remote hosts that the user is not expecting. New handlers registering themselves should never automatically cause those sites to be used.

Registration spamming. User agents should consider the possibility that a site will attempt to register a large number of handlers, possibly from multiple domains (e.g. by redirecting through a series of pages each on a different domain, and each registering a handler for video/mpeg — analogous practices abusing other Web browser features have been used by pornography Web sites for many years). User agents should gracefully handle such hostile attempts, protecting the user.

Misleading titles. User agents should not rely wholy on the title argument to the methods when presenting the registered handlers to the user, since sites could easily lie. For example, a site hostile.example.net could claim that it was registering the "Cuddly Bear Happy Content Handler". User agents should therefore use the handler's domain in any UI along with any title.

Hostile handler metadata. User agents should protect against typical attacks against strings embedded in their interface, for example ensuring that markup or escape characters in such strings are not executed, that null bytes are properly handled, that over-long strings do not cause crashes or buffer overruns, and so forth.

Leaking Intranet URIs. The mechanism described in this section can result in secret Intranet URIs being leaked, in the following manner:

The user registers a third-party content handler as the default handler for a content type.
The user then browses his corporate Intranet site and accesses a document that uses that content type.
The user agent contacts the third party and hands the third party the URI to the Intranet content.

No actual confidential file data is leaked in this manner, but the URIs themselves could contain confidential information. For example, the URI could be https://www.corp.example.com/upcoming-aquisitions/samples.egf, which might tell the third party that Example Corporation is intending to merge with Samples LLC. Implementors might wish to consider allowing administrators to disable this feature for certain subdomains, content types, or protocols.

Leaking secure URIs. User agents should not send HTTPS URIs to third party sites registered as content handlers, in the same way that user agents do not send Referer headers from secure sites to third party sites.

Leaking credentials. User agents must never send username or password information in the URIs that are escaped and included sent to the handler sites. User agents may even avoid attempting to pass to Web-based handlers the URIs of resources that are known to require authentication to access, as such sites would be unable to access the resources in question without prompting the user for credentials themselves (a practice that would require the user to know whether to trust the third party handler, a decision many users are unable to make or even understand).

4.11. [SCS] Alternate style sheets: the `DocumentStyle` interface

This specification extends the DocumentStyle interface introduced in DOM2 Style. [DOM2STYLE]

// Introduced in DOM Level 2: [DOM2STYLE]
interface DocumentStyle {
  readonly attribute StyleSheetList styleSheets;

  // New in this specification:
           attribute DOMString selectedStylesheetSet;
  readonly attribute DOMString lastStylesheetSet;
  readonly attribute DOMString preferredStylesheetSet;
  readonly attribute DOMStringList stylesheetSets;
  void enableStylesheetsForSet(in DOMString name);
};

Any object implementing the DocumentWindow interface must also implement the DocumentStyle interface.

For this interface, the DOMString values "null" and "the empty string" are distinct, and must not be considered equivalent.

A style sheet is said to have a title if the title attribute or pseudo-attribute of the DOM node that introduced the style sheet is present and has a non-empty value (i.e. if the title attribute of the StyleSheet object returned by the sheet attribute of the LinkStyle interface of that DOM node is neither null nor the empty string).

The new members are defined as follows:

selectedStylesheetSet of type DOMString

This attribute indicates which style sheet set ([HTML4]) is in use. This attribute is live; changing the disabled attribute on style sheets directly will change the value of this attribute.

If all the sheets that are enabled and have a title have the same title (by case-sensitive comparisons) then the value of this attribute must be exactly equal to the title of the first enabled style sheet with a title in the styleSheets list. Otherwise, if style sheets from different sets are enabled, then the return value must be null (there is no way to determine what the currently selected style sheet set is in those conditions). Otherwise, either all style sheets that have a title are disabled, or there are no alternate style sheets, and selectedStylesheetSet must return the empty string.

Setting this attribute to the null value must have no effect.

Setting this attribute to a non-null value must call enableStylesheetsForSet() with that value as the function's argument, and set lastStylesheetSet to that value.

From the DOM's perspective, all views have the same selectedStylesheetSet. If a UA supports multiple views with different selected alternate style sheets, then this attribute (and the StyleSheet interface's disabled attribute) must return and set the value for the default view.

lastStylesheetSet of type DOMString, readonly

This property must initially have the value null. Its value changes when the selectedStylesheetSet attribute is set.

preferredStylesheetSet of type DOMString, readonly

This attribute must return the preferred style sheet set as set by the author. It is determined from the order of style sheet declarations and the Default-Style HTTP headers, as eventually defined elsewhere in this specification. If there is no preferred style sheet set, this attribute must return the empty string. The case of this attribute must exactly match the case given by the author where the preferred style sheet is specified or implied. This attribute must never return null.

stylesheetSets of type DOMStringList, readonly

This must return the live list of the currently available style sheet sets. This list is constructed by enumerating all the style sheets for this document available to the implementation, in the order they are listed in the styleSheets attribute, adding the title of each style sheet with a title to the list, avoiding duplicates by dropping titles that match (case-sensitively) titles that have already been added to the list.

enableStylesheetsForSet(name), method

Calling this method must change the disabled attribute on each StyleSheet object with a title attribute with a length greater than 0 in the styleSheets attribute, so that all those whose title matches the name argument are enabled, and all others are disabled. Title matches must be case-sensitive. Calling this method with the empty string disables all alternate and preferred style sheets (but does not change the state of persistent style sheets, that is those with no title attribute).

Calling this method with a null value must have no effect.

Style sheets that do not have a title are never affected by this method. This method does not change the values of the lastStylesheetSet or preferredStylesheetSet attributes.

4.11.1. Dynamically adding new style sheets

If new style sheets with titles are added to the document, the UA must decide whether or not the style sheets should be initially enabled or not. How this happens depends on the exact state of the document at the time the style sheet is added, as follows.

4.11.1.1. Adding style sheets

First, if the style sheet is a preferred style sheet (it has a title, but is not marked as alternate), and there is no current preferred style sheet (the preferredStylesheetSet attribute is equal to the empty string) then the preferredStylesheetSet attribute is set to the exact value of this style sheet's title. (This changes the preferred style sheet set, which causes further changes — see below.)

Then, for all sheets, if any of the following is true, then the style sheet must be enabled:

The style sheet has an empty title.
The lastStylesheetSet is null, and the style sheet's title matches (by case-sensitive match) the value of the preferredStylesheetSet attribute.
The style sheet's title matches (by case-sensitive match) the value of the lastStylesheetSet attribute.

Otherwise, the style sheet must be disabled.

4.11.1.2. Changing the preferred style sheet set

The first time the preferred style sheet set is set, which is either before any alternate style sheets are seen (e.g. using a "Default-Style" HTTP header), or is the first time a titled, non-alternate style sheet is seen (in the absence of information to the contrary, the first titled non-alternate sheet sets the name of the preferred set), the preferredStylesheetSet attribute's value must be set to the name of that preferred style sheet set. This does not change the lastStylesheetSet attribute.

If the UA has the preferred style sheet set changed, for example if it receives a "Default-Style:" HTTP header after it receives HTTP "Link:" headers implying another preferred style sheet, then the preferredStylesheetSet attribute's value must be changed appropriately, and, if the lastStylesheetSet is null, the enableStylesheetsForSet() method must be called with the new preferredStylesheetSet value. (The lastStylesheetSet attribute is, again, not changed.)

4.11.1.3. Examples

Thus, in the following HTML snippet:

<link rel="alternate stylesheet" title="foo" href="a">
<link rel="alternate stylesheet" title="bar" href="b">
<script>
  document.selectedStylesheetSet = 'foo';
  document.styleSheets[1].disabled = false;
</script>
<link rel="alternate stylesheet" title="foo" href="c">
<link rel="alternate stylesheet" title="bar" href="d">

...the style sheets that end up enabled are style sheets "a", "b", and "c", the selectedStylesheetSet attribute would return null, lastStylesheetSet would return "foo", and preferredStylesheetSet would return "".

Similarly, in the following HTML snippet:

<link rel="alternate stylesheet" title="foo" href="a">
<link rel="alternate stylesheet" title="bar" href="b">
<script>
  var before = document.preferredStylesheetSet;
  document.styleSheets[1].disabled = false;
</script>
<link rel="stylesheet" title="foo" href="c">
<link rel="alternate stylesheet" title="bar" href="d">
<script>
  var after = document.preferredStylesheetSet;
</script>

...the "before" variable will be equal to the empty string, the "after" variable will be equal to "foo", and style sheets "a" and "c" will be enabled. This is the case even though the first script block sets style sheet "b" to be enabled, because upon parsing the following <link> element, the preferredStylesheetSet is set and the enableStylesheetsForSet() method is called (since selectedStylesheetSet was never set explicitly, leaving lastStylesheetSet at null throughout), which changes which style sheets are enabled and which are not.

4.11.2. Interaction with the User Interface

The user interface of Web browsers that support style sheets should list the style sheet titles given in the stylesheetSets list, showing the selectedStylesheetSet as the selected style sheet set, leaving none selected if it is null or the empty string, and selecting an extra option "Basic Page Style" (or similar) if it is the empty string and the preferredStylesheetSet is the empty string as well.

Selecting a style sheet from this list should set the selectedStylesheetSet attribute. This (by definition) affects the lastStylesheetSet attribute.

4.11.2.1. Persisting the selected style sheet set

If UAs persist the selected style sheet set, they should use the value of the selectedStylesheetSet attribute, or if that is null, the lastStylesheetSet attribute, when leaving the page (or at some other time) to determine the set name to store. If that is null then the style sheet set should not be persisted.

When re-setting the style sheet set to the persisted value (which can happen at any time, typically at the first time the style sheets are needed for styling the document, after the <head> of the document has been parsed, after any scripts that are not dependent on computed style have executed), the style sheet set should be set by setting the selectedStylesheetSet attribute as if the user had selected the set manually.

This specification does not give any suggestions on how UAs should decide to persist the style sheet set or whether or how to persist the selected set across pages.

4.11.3. Future compatibility

Future versions of CSS may introduce ways of having alternate style sheets declared at levels lower than the top level, i.e. embedded within other style sheets. Implementations of this specification that also support this proposed declaration of alternate style sheets are expected to perform depth-first traversals of the styleSheets list, not simply enumerations of the styleSheets list that only contains the top level.

5. Browser environment integration

5.1. [SCS] Editing and the `contenteditable` attribute

The contenteditable attribute is a common attribute. User agents must support this attribute on all HTML elements.

If an HTML element has a contenteditable attribute set to the empty string or the exact literal value true, or if its nearest ancestor with the contenteditable attribute set has its attribute set to the empty string or the exact the literal value true, then the UA must treat the element as editable (as described below).

If an HTML element has a contenteditable attribute set but the value of the attribute is not the empty string or the literal value true, or if its nearest ancestor with the contenteditable attribute set is not editable, or if it has no ancestor with the contenteditable attribute set, then the element is not editable.

Authors must only use the values true and false with the contenteditable attribute.

If an element is editable and its parent element is not, then the element is an editing host. Editable elements can be nested. User agents must make editing hosts focusable (which typicially means they enter the tab order). An editing host can contain non-editable sections, these are handled as described below. An editing host can contain non-editable sections that contain further editing hosts.

When an editing host has focus, it must have a caret position that specifies where the current editing position is. It may also have a selection.

How the caret and selection are represented depends entirely on the UA.

5.1.1. User editing actions

There are several actions that the user agent should allow the user to perform while the user is interacting with an editing host. How exactly each action is triggered is not defined for every action, but when it is not defined, suggested key bindings are provided to guide implementors.

Move the caret

User agents must allow users to move the caret to any position within an editing host, even into nested editable elements. This could be triggered as the default action of keydown events with various key identifiers and as the default action of mouseydown events.

Change the selection

User agents must allow users to change the selection within an editing host, even into nested editable elements. This could be triggered as the default action of keydown events with various key identifiers and as the default action of mouseydown events.

Insert text

This action must be triggered as the default action of a textInput event, and may be triggered by other commands as well. It must cause the user agent to insert the specified text (given by the event object's data attribute in the case of the textInput event) at the caret.

If the caret is positioned somewhere where inline-level content is not allowed (e.g. because the element accepts "both block-level and inline-level content but not both", and the element already contains block-level content), then the user agent must not insert the text directly at the caret position. In such cases the behaviour is UA-dependent, but user agents must not, in response to a request to insert text, generate a DOM that is less conformant than the DOM prior to the request.

User agents should allow users to insert new paragraphs into elements that only contain block-level content.

For example, given the markup:

<section>
 <dl>
  <dt> Ben </dt>
  <dd> Goat </dd>
 </dl>
</section>

...the user agent should allow the user to insert p elements before and after the dl element, as children of the section element.

Break block

UAs should offer a way for the user to request that the current block be broken at the caret, e.g. as the default action of a keydown event whose identifier is the "Enter" key and that has no modifiers set.

The exact behaviour is UA-dependent, but user agents must not, in response to a request to break a block, generate a DOM that is less conformant than the DOM prior to the request.

Insert a line separator

UAs should offer a way for the user to request an explicit line break at the caret position without breaking the block, for example as in a poem verse or an address. To insert a line break, the user agent must insert a br element.

If the caret is positioned somewhere where inline-level content is not allowed (e.g. because the element accepts "both block-level and inline-level content but not both", and the element already contains block-level content), then the user agent must not insert the br element directly at the caret position. In such cases the behaviour is UA-dependent, but user agents must not, in response to a request to insert a line separator, generate a DOM that is less conformant than the DOM prior to the request.

Delete

UAs should offer a way for the user to delete text and elements, e.g. as the default action of keydown events whose identifiers are "U+0008" or "U+007F".

Five edge cases in particular need to be considered carefully when implementing this feature: backspacing at the start of an element, backspacing when the caret is immediately after an element, forward-deleting at the end of an element, forward-deleting when the caret is immediately before an element, and deleting a selection whose start and end points do not share a common parent node.

In any case, the exact behaviour is UA-dependent, but user agents must not, in response to a request to delete text or an element, generate a DOM that is less conformant than the DOM prior to the request.

Insert, and wrap text in, semantic elements

UAs should offer a way for the user to mark text as having stress emphasis and as being important, and may offer the user the ability to mark text and blocks with other semantics.

UAs should similarly offer a way for the user to insert empty semantic elements (such as, again, em, strong, and others) to subsequently fill by entering text manually.

UAs should also offer a way to remove those semantics from marked up text, and to remove empty semantic element that have been inserted.

The exact behaviour is UA-dependent, but user agents must not, in response to a request to wrap semantics around some text or to insert or remove a semantic element, generate a DOM that is less conformant than the DOM prior to the request.

Select and move non-editable elements nested inside editing hosts

UAs should offer a way for the user to move images and other non-editable parts around the content within an editing host. This may be done using the drag and drop mechanism. User agents must not, in response to a request to move non-editable elements nested inside editing hosts, generate a DOM that is less conformant than the DOM prior to the request.

Edit form controls nested inside editing hosts

When an editable form control is edited, the changes must be reflected in both its current value and its default value. For input elements this means updating the defaultValue DOM attribute as well as the value DOM attribute; for select elements it means updating the option elements' defaultSelected DOM attribute as well as the selected DOM attribute; for textarea elements this means updating the defaultValue DOM attribute as well as the value DOM attribute. (Updating the default* DOM attributes causes content attributs to be updated as well.)

User agents may perform several commands per user request; for example if the user selects a block of text and hits Enter, the UA might interpret that as a request to delete the content of the selection followed by a request to break the block at that position.

5.2. [SCS] Drag and drop

This section defines an event-based drag-and-drop mechanism.

This specification does not define exactly what a drag and drop operation actually is.

On a visual medium with a pointing device, a drag operation could be the default action of a mousedown event that is followed by a series of mousemove events, and the drop could be triggered by the mouse being released.

On media without a pointing device, the user would probably have to explicitly indicate his intention to perform a drag-and-drop operation, stating what he wishes to drag and what he wishes to drop, respectively.

However it is implemented, drag and drop operations must have a starting point (e.g. where the mouse was clicked, or the start of the selection or element that was selected for the drag), may have any number of intermediate steps (elements that the mouse moves over during a drag, or elements that the user picks as possible drop points as he cycles through possibilities), and must either have an end point (the element above which the mouse button was released, or the element that was finally selected), or be canceled. The end point must be the last element selected as a possible drop point before the drop occurs (so if the operation is not canceled, there must be at least one element in the middle step).

5.2.1. Drag-and-drop processing model

There are two processing models for drag-and-drop: one for when a drag is initiated within the document, and one for when a drag is initiated in another (DOM-based) document or another application altogether, but the user has selected a node in the document as a drop target.

5.2.1.1. For drags initiated within the document

When the user attempts to begin a drag operation, the user agent must first determine what is being dragged. If the drag operation was invoked on a selection, then it is the selection that is being dragged. Otherwise, it is the first element, going up the ancestor chain, starting at the node that the user tried to drag, that has the DOM attribute draggable set to true. If there is no such element, then nothing is being dragged, the drag-and-drop operation is never started, and the user agent must not continue with this algorithm.

If the user agent determines that something can be dragged, a dragstart event must then be fired.

If it is a selection that is being dragged, then this event must be fired on the node that the user started the drag on (typically the text node that the user originally clicked). If the user did not specify a particular node, for example if the user just told the user agent to begin a drag of "the selection", then the event must be fired on the deepest node that is a common ancestor of all parts of the selection.

If it is not a selection that is being dragged, then the event must be fired on the element that is being dragged.

The node on which the event is fired is the source node. Multiple events are fired on this node during the course of the drag-and-drop operation.

The dataTransfer member of the event must initially contain no nodes if a selection is being dragged, and just the source node otherwise.

If the event is canceled, then the drag and drop operation must not occur; the user agent must not continue with this algorithm.

If it is not canceled, then the drag and drop operation must be initiated.

Since events with no event handlers registered are, almost by definition, never canceled, drag and drop is always available to the user if the author does not specifically prevent it.

The drag-and-drop feedback must be generated from the selection if the user is dragging a selection, or from the nodes that were in the dataTransfer object's list after the event has been handled otherwise. In visual media, if an image was specified, then that image must be used instead.

The user agent must take a note of the data that was placed in the dataTransfer object.

From this point until the end of the drag-and-drop operation, mouse and key events must be suppressed. In addition, the user agent must track all DOM changes made during the drag-and-drop operation, and add them to its undo history as one atomic operation once the drag-and-drop operation has ended.

During the drag operation, the element directly indicated by the user as the drop target is called the immediate user selection. (Only elements can be selected by the user; other nodes must not be made available as drop targets.)

However, the immediate user selection is not necessarily the element the current target element, the element currently selected for the drop part of the drag-and-drop operation.

The immediate user selection changes as the user selects different elements (either by pointing at them with a pointing device, or by selecting them in some other way). The current target element changes when the immediate user selection changes, based on the results of event handlers in the document, as described below.

Both the current target element and the immediate user selection can be null, which means no target element is selected. They can also both be elements in other (DOM-based) documents, or other (non-Web) programs altogether. (For example, a user could drag text to a word-processor.) The current target element is initially null.

In addition, there is also a current drag operation, which can take on the values "none", "copy", "link", and "move". Initially it has the value "none". It is updated by the user agent as described in the steps below.

User agents must, every 350ms (±200ms), perform the following steps in sequence. (If the user agent is still performing the previous iteration of the sequence when the next iteration becomes due, the user agent must not execute the overdue iteration, effectively "skipping missed frames" of the drag and drop operation.)

First, the user agent must fire a drag event at the source node.

Next, if the drag event was not canceled and the user has not ended the drag-and-drop operation, the user agent must check the state of the drag-and-drop operation, as follows:

First, if the user is indicating a different immediate user selection than during the last iteration (or if this is the first iteration), and if this immediate user selection is not the same as the current target element, then the current target element must be updated, as follows:
1. If the new immediate user selection is null, or is in a non-DOM document or application, then set the current target element to the same value.
2. Otherwise, the user agent must fire a dragenter event at the immediate user selection.
3. If the event is canceled, then the current target element must be set to the immediate user selection.
4. Otherwise, if the current target element is not the body element, the user agent must fire a dragenter event at the body element, and the current target element must be set to the body element, regardless of whether the event was canceled or not.
If the previous step caused the current target element to change, and if the previous target element was not null or a part of a non-DOM document, the user agent must fire a dragleave event at the previous target element.

If the current target element is a DOM element, the user agent must fire a dragover event at this current target element.

If the dragover event is not canceled, the dataTransfer object's dropEffect attribute must then be reset to the value it was given when the event was fired.

Then, regardless of whether the event was canceled or not, the drag feedback (e.g. the mouse cursor) must be updated to match the kind of drag-and-drop operation indicated by the event's dataTransfer object's dropEffect attribute, as follows:

`dropEffect`	Drag operation
`none`	No operation allowed.
`copy`	Data will be copied.
`link`	Data will be linked.
`move`	Data will be moved.

The drag operation in question is the new current drag operation.

Otherwise, if the current target element is not a DOM element, the user agent must use platform-specific mechanisms to determine what drag operation is being performed (none, copy, link, or move). This sets the current drag operation.

Otherwise, if the user ended the drag and drop operation (e.g. by releasing the mouse button in a mouse-driven drag-and-drop interface), then this will be the last iteration. The user agent should follow the following steps, then stop looping.
1. If the current drag operation is none (no drag operation), or, if the user ended the drag-and-drop operation by canceling it (e.g. by hitting the Escape key), or if the current target element is null, then the drag operation failed. If the current target element is a DOM element, the user agent must fire a dragleave event at it; otherwise, if it is not null, it must use platform-specific conventions for drag cancellation.
2. Otherwise, the drag operation was as success. If the current target element is a DOM element, the user agent must fire a drop event at it; otherwise, it must use platform-specific conventions for indicating a drop.
  
  When the target is a DOM element, the dropEffect attribute of the event's dataTransfer object must be given the value representing the current drag operation (copy, link, or move), and the object must be set up so that the getData() method will return the data that was added during the dragstart event.
  
  Some elements have a default behaviour for "drop", e.g. textarea receives new text. Cancelable.
3. Finally, the user agent must fire a dragend event at the source node.
  
  Some elements have a default behaviour for "dragend", e.g. textarea deletes source text in a move. NOT cancelable.

The events must be fired as described above, even if the nodes are in different documents (assuming those are DOM-based). User agents should handle cases where the target is not in a DOM-based document according to the platform conventions.

5.2.1.2. For drags initiated in other documents or applications [TBW]

...

5.2.2. The `draggable` attribute [TBW]

...

The draggable DOM attribute reflects the draggable content attribute. However, the default value varies based on the element type For img elements, the default is true. For a elements, the default is true if the element has an href content attribute, and false otherwise. For all other elements, the default is false.

5.2.3. The `DragEvent` interface and the `dataTransfer` object [WIP]

Need to define DragEvent interface.

interface DataTransfer {
           attribute DOMString dropEffect;
           attribute DOMString effectAllowed;
  void clearData(in DOMString format);
  void setData(in DOMString format, in DOMString data);
  DOMString getData(in DOMString format);

// XXX addElement, dragImage, etc
};

Need to define DataTransfer members

When a DragEvent event object is initialised by the user agent for the purposes of the drag-and-drop model described above (as opposed to when a custom DragEvent event object is created by author script), the object must be initialised as follows.

Its dataTransfer member must be initialised to a new instance of a DataTransfer object.
That object must initially contain no elements and have no associated image.
The dataTransfer object's effectAllowed attribute must be set to "uninitialized" for dragstart events, and to whatever value the field had after the last drag-and-drop event was fired for all other events (only counting events fired by the user agent for the purposes of the drag-and-drop model described above).

The dropEffect attribute must be set to "none" for dragstart, drag, dragleave, and dragend events (except when stated otherwise in the algorithms given in the earlier sections), and to a value based on the effectAllowed attribute's value and to the drag-and-drop source, as given by the following table, for other events:

`effectAllowed`	`dropEffect`
`none`	`none`
`copy`, `copyLink`, `copyMove`, `all`	`copy`
`link`, `linkMove`	`link`
`move`	`move`
`uninitialised` when what is being dragged is a selection from a text field	`move`
`uninitialised` when what is being dragged is a selection	`copy`
`uninitialised` when what is being dragged is an `a` element with an `href` attribute	`link`
Any other case	`copy`

5.2.4. Events fired during a drag-and-drop action

This section is non-normative. It merely summarises the preceeding sections.

The following events are involved in the drag-and-drop model. They all use the DragEvent interface.

Event Name	Target	Bubbles?	Cancelable?	`dataTransfer`	`effectAllowed`	`dropEffect`	Default Action
`dragstart`	Source node	✓ Bubbles	✓ Cancelable	Contains source node unless a selection is being dragged, in which case it is empty	`uninitialized`	`none`	Initiate the drag-and-drop operation
`drag`	Source node	✓ Bubbles	✓ Cancelable	—	Same as last event	`none`	Continue the drag-and-drop operation
`dragenter`	Immediate user selection or the `body` element	✓ Bubbles	✓ Cancelable	—	Same as last event	Based on `effectAllowed` value	Reject immediate user selection as potential target element
`dragleave`	Previous target element	✓ Bubbles	—	—	Same as last event	`none`	None
`dragover`	Current target element	✓ Bubbles	✓ Cancelable	—	Same as last event	Based on `effectAllowed` value	Reset `dropEffect` based on `effectAllowed` value
`drop`	Current target element	✓ Bubbles	✓ Cancelable	`getData()` returns data set in `dragstart` event	Same as last event	Current drag operation	Varies
`dragend`	Source node	✓ Bubbles	✓ Cancelable	—	Same as last event	`none`	Varies

5.3. [SCS] Undo history

There has got to be a better way of doing this, surely.

The user agent must associate an undo transaction history with each DocumentWindow object.

The undo transaction history is a list of entries. The entries are of two type: DOM changes and undo objects.

Each DOM changes entry in the undo transaction history consists of batches of one or more of the following:

Changes to the content attributes of an Element node.
Changes to the DOM attributes of a Node.
Changes to the DOM hierarchy of nodes that are descendants of the DocumentWindow object (parentNode, childNodes).

Undo object entries consist of objects representing state that scripts running in the document are managing. For example, a Web mail application could use an undo object to keep track of the fact that a user has moved an e-mail to a particular folder, so that the user can undo the action and have the e-mail return to its former location.

Broadly speaking, DOM changes entries are handled by the UA in response to user edits of form controls and editing hosts on the page, and undo object entries are handled by script in response to higher-level user actions (such as interactions with server-side state, or in the implementation of a drawing tool).

5.3.1. The `UndoManager` interface

This API sucks. Seriously. It's a terrible API. Really bad. I hate it. Here are the requirements:

Has to cope with cases where the server has undo state already when the page is loaded, that can be stuffed into the undo buffer onload.
Has to support undo/redo.
Has to cope with the "undo" action being "contact the server and tell it to undo", rather than it being the opposite of the "redo" action.
Has to cope with some undo states expiring from the undo history (e.g. server can only remember one undelete action) but other states not expiring (e.g. client can undo arbitrary amounts of local edits).

To manage undo object entries in the undo transaction history, the UndoManager interface can be used:

interface UndoManager {
  unsigned long add(in DOMObject data, in DOMStrong title);
  void remove(in unsigned long index);
  void clearUndo();
  void clearRedo();
  DOMObject item(in unsigned long index);
  readonly attribute unsigned long length;
  readonly attribute unsigned long position;
};

The undoManager attribute of the Window interface must return the object implementing the UndoManager interface for that Window object's associated DocumentWindow object.

In the ECMAScript binding, objects implementing this interface must also support being dereferenced using the square bracket notation, such that dereferencing with an integer index is equivalent to invoking the item() method with that index (e.g. undoManager[1] returns the same as undoManager.item(1)).

UndoManager objects represent their document's undo transaction history. Only undo object entries are visible with this API, but this does not mean that DOM changes entries are absent from the undo transaction history.

The length attribute must return the number of undo object entries in the undo transaction history.

The item(n) method must return the nth undo object entry in the undo transaction history.

The undo transaction history has a current position. This is the position between two entries in the undo transaction history's list where the previous entry represents what needs to happen if the user invokes the "undo" command (the "undo" side, lower numbers), and the next entry represents what needs to happen if the user invokes the "redo" command (the "redo" side, higher numbers).

The position attribute must return the index of the undo object entry nearest to the undo position, on the "redo" side. If there are no undo object entries on the "redo" side, then the attribute must return the same as the length attribute. If there are no undo object entries on the "undo" side of the undo position, the position attribute returns zero.

Since the undo transaction history contains both undo object entries and DOM changes entries, but the position attribute only returns indices relative to undo object entries, it is possible for several "undo" or "redo" actions to be performed without the value of the position attribute changing.

The add(data, title) method's behaviour depends on the current state. Normally, it must insert the data object passed as an argument into the undo transaction history immediately before the undo position, optionally remembering the given title to use in the UI. If the method is called during an undo operation, however, the object must instead be added immediately after the undo position.

If the method is called and there is neither an undo operation in progress nor a redo operation in progress then any entries in the undo transaction history after the undo position must be removed (as if clearRedo() had been called).

We could fire events when someone adds something to the undo history -- one event per undo object entry before the position (or after, during redo addition), allowing the script to decide if that entry should remain or not. Or something. Would make it potentially easier to expire server-held state when the server limitations come into play.

The remove(index) method must remove the undo object entry with the specified index. If the index is less than zero or greater than or equal to length then the method must raise an INDEX_SIZE_ERR exception. DOM changes entries are unaffected by this method.

The clearUndo() method must remove all entries in the undo transaction history before the undo position, be they DOM changes entries or undo object entries.

The clearRedo() method must remove all entries in the undo transaction history after the undo position, be they DOM changes entries or undo object entries.

Another idea is to have a way for scripts to say "startBatchingDOMChangesForUndo()" and after that the changes to the DOM go in as if the user had done them.

5.3.2. Undo: moving back in the undo transaction history

When the user invokes an undo operation, or when the execCommand() method is called with the undo command, the user agent must perform an undo operation.

If the undo position is at the start of the undo transaction history, then the user agent must do nothing.

If the entry immediately before the undo position is a DOM changes entry, then the user agent must remove that DOM changes entry, reverse the DOM changes that were listed in that entry, and, if the changes were reversed with no problems, add a new DOM changes entry (consisting of the opposite of those DOM changes) to the undo transaction history on the other side of the undo position.

If the DOM changes cannot be undone (e.g. because the DOM state is no longer consistent with the changes represented in the entry), then the user agent must simply remove the DOM changes entry, without doing anything else.

If the entry immediately before the undo position is an undo object entry, then the user agent must first remove that undo object entry from the undo transaction history, and then must fire an undo event on the Document object, using the undo object entry's associated undo object as the event's data.

Any calls to add() while the event is being handled will be used to populate the redo history, and will then be used if the user invokes the "redo" command to undo his undo.

5.3.3. Redo: moving forward in the undo transaction history

When the user invokes a redo operation, or when the execCommand() method is called with the redo command, the user agent must perform a redo operation.

This is mostly the opposite of an undo operation, but the full definition is included here for completeness.

If the undo position is at the end of the undo transaction history, then the user agent must do nothing.

If the entry immediately after the undo position is a DOM changes entry, then the user agent must remove that DOM changes entry, reverse the DOM changes that were listed in that entry, and, if the changes were reversed with no problems, add a new DOM changes entry (consisting of the opposite of those DOM changes) to the undo transaction history on the other side of the undo position.

If the DOM changes cannot be redone (e.g. because the DOM state is no longer consistent with the changes represented in the entry), then the user agent must simply remove the DOM changes entry, without doing anything else.

If the entry immediately after the undo position is an undo object entry, then the user agent must first remove that undo object entry from the undo transaction history, and then must fire a redo event on the Document object, using the undo object entry's associated undo object as the event's data.

5.3.4. The `UndoManagerEvent` interface and the `undo` and `redo` events

interface UndoManagerEvent : Event {
  readonly attribute DOMObject data;
  void               initUndoManagerEvent(in DOMString typeArg, 
                                          in boolean canBubbleArg, 
                                          in boolean cancelableArg, 
                                          in DOMObject dataArg);
  void               initUndoManagerEventNS(in DOMString namespaceURIArg,
                                            in DOMString typeArg, 
                                            in boolean canBubbleArg, 
                                            in boolean cancelableArg, 
                                            in DOMObject dataArg);
};

The initUndoManagerEvent() and initUndoManagerEventNS() methods must initialise the event in a manner analogous to the similarly-named methods in the DOM3 Events interfaces. [DOM3EVENTS]

The data attribute represents the undo object for the event.

The undo and redo events do not bubble, cannot be canceled, and have no default action. When the user agent fires one of these events it must use the UndoManagerEvent interface, with the data field containing the relevant undo object.

5.3.5. Implementation notes

How user agents present the above conceptual model to the user is not defined. The undo interface could be a filtered view of the undo transaction history, it could manipulate the undo transaction history in ways not described above, and so forth. For example, it is possible to design a UA that appears to have separate undo transaction histories for each form control; similarly, it is possible to design systems where the user has access to more undo information than is present in the offical (as described above) undo transaction history (such as providing a tree-based approach to document state). Such UI models should be based upon the single undo transaction history described in this section, however, such that to a script there is no detectable difference.

5.4. [SCS] Command APIs

The execCommand(commandID, doShowUI, value) method on the DocumentWindow interface allows scripts to perform actions on the current selection or at the current caret position. Generally, these commands would be used to implement editor UI, for example having a "delete" button on a toolbar.

There are three variants to this method, with one, two, and three arguments respectively. The doShowUI and value parameters, even if specified, are ignored unless otherwise stated.

In this specification, in fact, the doShowUI parameter is always ignored, regardless of its value. It is included for historical reasons only.

When any of these methods are invoked, user agents must act as described in the list below.

For actions marked "editing hosts only", if the selection is not entirely within an editing host, of if there is no selection and the caret is not inside an editing host, then the user agent must do nothing.

If the commandID is undo

The user agent must move back one step in its undo transaction history, restoring the associated state. If there is no further undo information the user agent must do nothing. See the undo history.

If the commandID is redo

The user agent must move forward one step in its undo transaction history, restoring the associated state. If there is no further undo (well, "redo") information the user agent must do nothing. See the undo history.

If the commandID is selectAll

The user agent must change the selection so that all the content in the currently focused editing host is selected. If no editing host is focused, then the content of the entire document must be selected.

If the commandID is unselect

The user agent must change the selection so that nothing is selected.

We need some sort of way in which the user can make a selection without risk of script clobbering it.

If the commandID is superscript

Editing hosts only. The user agent must act as if the user had requested that the selection be wrapped in the semantics of the sup element (or unwrapped, or, if there is no selection, have that semantic inserted or removed — the exact behaviour is UA-defined).

If the commandID is subscript

Editing hosts only. The user agent must act as if the user had requested that the selection be wrapped in the semantics of the sub element (or, again, unwrapped, or have that semantic inserted or removed, as defined by the UA).

If the commandID is formatBlock

Editing hosts only. This command changes the semantics of the blocks containing the selection.

If there is no selection, then, where in the description below refers to the selection, the user agent must act as if the selection was an empty range at the caret position.

If the value parameter is not specified or has a value other than one of the following literal strings:

<address>
<aside>
<h1>
<h2>
<h3>
<h4>
<h5>
<h6>
<nav>
<p>
<pre>

...then the user agent must do nothing.

Otherwise, the user agent must, for every position in the selection, take the furthest block-level element ancestor of that position that contains only inline-level content and is not being used as a structured inline-level element, and, if that element is a descendant of the editing host, rename it according to the value, by stripping the leading < character and the trailing > character and using the rest as the new tag name.

If the commandID is delete

Editing hosts only. The user agent must act as if the user had performed a backspace operation.

If the commandID is forwardDelete

Editing hosts only. The user agent must act as if the user had performed a forward delete operation.

If the commandID is insertLineBreak

Editing hosts only. The user agent must act as if the user had requested a line separator.

If the commandID is insertParagraph

Editing hosts only. The user agent must act as if the user had performed a break block editing action.

If the commandID is insertText

Editing hosts only. The user agent must act as if the user had inserted text corresponding to the value parameter.

If the commandID is vendorID-customCommandID

User agents may implement vendor-specific extensions to this API. Vendor-specific extensions to the list of commands should use the syntax vendorID-customCommandID so as to prevent clashes between extensions from different vendors and future additions to this specification.

If the commandID is something else

User agents must do nothing.

5.5. [SCS] The text selection APIs

Every browsing context has a selection. The selection may be empty, and the selection may have more than one range (a disjointed selection). The user should be able to change the selection. User agents are not required to let the user select more than one range, and may collapse multiple ranges in the selection to a single range when the user interacts with the selection. (But, of course, the user agent may let the user create selections with multiple ranges.)

This one selection must be shared by all the content of the browsing context (though not by nested browsing contexts), including any editing hosts in the document. (Editing hosts that are not inside a document cannot have a selection.)

If the selection is empty (collapsed, so that it has only one segment and that segment's start and end points are the same) then the selection's position should equal the caret position. When the selection is not empty, this specification does not define the caret position; user agents should follow platform conventions in deciding whether the caret is at the start of the selection, the end of the selection, or somewhere else.

On some platforms (such as those using Wordstar editing conventions), the caret position is totally independent of the start and end of the selection, even when the selection is empty. On such platforms, user agents may ignore the requirement that the cursor position be linked to the position of the selection altogether.

Mostly for historical reasons, in addition to the browsing context's selection, each textarea and input element has an independent selection. These are the text field selections.

The datagrid and select elements also have selections, indicating which items have been picked by the user. These are not discussed in this section.

This specification does not specify how selections are presented to the user. The Selectors specification, in conjunction with CSS, can be used to style text selections using the ::selection pseudo-element. [SELECTORS] [CSS21]

5.5.1. APIs for the browsing context selection

The getSelection() method on the Window interface must return the Selection object representing the selection of that Window object's browsing context.

For historical reasons, the getSelection() method on the DocumentWindow interface must return the same Selection object.

interface Selection {
  readonly attribute Node anchorNode;
  readonly attribute long anchorOffset;
  readonly attribute Node focusNode;
  readonly attribute long focusOffset;
  readonly attribute boolean isCollapsed;
  void collapse(in Node parentNode, in long offset);
  void collapseToStart();
  void collapseToEnd();
  void selectAllChildren(in Node parentNode);
  void deleteFromDocument();
  readonly attribute long rangeCount;
  Range getRangeAt(in long index);
  void addRange(in Range range);
  void removeRange(in Range range);
  void removeAllRanges();
  DOMString toString();
};

The Selection interface is represents a list of Range objects. The first item in the list has index 0, and the last item has index count-1, where count is the number of ranges in the list. [DOM2RANGE]

All of the members of the Selection interface are defined in terms of operations on the Range objects represented by this object. These operations can raise exceptions, as defined for the Range interface; this can therefore result in the members of the Selection interface raising exceptions as well, in addition to any explicitly called out below.

The anchorNode attribute must return the value returned by the startContainer attribute of the last Range object in the list, or null if the list is empty.

The anchorOffset attribute must return the value returned by the startOffset attribute of the last Range object in the list, or 0 if the list is empty.

The focusNode attribute must return the value returned by the endContainer attribute of the last Range object in the list, or null if the list is empty.

The focusOffset attribute must return the value returned by the endOffset attribute of the last Range object in the list, or 0 if the list is empty.

The isCollapsed attribute must return true if there are zero ranges, or if there is exactly one range and its collapsed attribute is itself true. Otherwise it must return false.

The collapse(parentNode, offset) method must raise a WRONG_DOCUMENT_ERR DOM exception if parentNode's ownerDocument is not the DocumentWindow object with which the Selection object is associated. Otherwise it is, and the method must remove all the ranges in the Selection list, then create a new Range object, add it to the list, and invoke its setStart() and setEnd() methods with the parentNode and offset values as their arguments.

The collapseToStart() method must raise an INVALID_STATE_ERR DOM exception if there are no ranges in the list. Otherwise, it must invoke the collapse() method with the startContainer and startOffset values of the first Range object in the list as the arguments.

The collapseToEnd() method must raise an INVALID_STATE_ERR DOM exception if there are no ranges in the list. Otherwise, it must invoke the collapse() method with the endContainer and endOffset values of the last Range object in the list as the arguments.

The selectAllChildren(parentNode) method must invoke the collapse() method with the parentNode value as the first argument and 0 as the second argument, and must then invoke the selectNodeContents() method on the first (and only) range in the list with the parentNode value as the argument.

The deleteFromDocument() method must invoke the deleteContents() method on each range in the list, if any, from first to last.

The rangeCount attribute must return the number of ranges in the list.

The getRangeAt(index) method must return the indexth range in the list. If index is less than zero or greater or equal to the value returned by the rangeCount attribute, then the method must raise an INDEX_SIZE_ERR DOM exception.

The addRange(range) method must add the given range Range object to the list of selections, at the end (so the newly added range is the new last range). Duplicates are not prevented; a range may be added more than once in which case it appears in the list more than once, which (for example) will cause toString() to return the range's text twice.

The removeRange(range) method must remove the first occurrence of range in the list of ranges, if it appears at all.

The removeAllRanges() method must remove all the ranges from the list of ranges, such that the rangeCount attribute returns 0 after the removeAllRanges() method is invoked (and until a new range is added to the list, either through this interface or via user interaction).

The toString() method must return a concatenation of the results of invoking the toString() method of the Range object on each of the ranges of the selection, in the order they appear in the list (first to last).

In language bindings where this is supported, objects implementing the Selection interface must stringify to the value returned by the object's toString() method.

In the following document fragment, the emphasised parts indicate the selection.

<p>The cute girl likes the <cite>Oxford English Dictionary</cite>.</p>

If a script invoked window.getSelection().toString(), the return value would be "the Oxford English".

The Selection interface has no relation to the SelectedRowRanges interface.

5.5.2. APIs for the text field selections

This section will refer to the IDLs for HTMLTextAreaElement and HTMLInputElement, most notably their select() method, the selectionStart and selectionEnd attributes, and the setSelectionRange() method.

6. Multimedia

should we move all the img, object, embed, iframe, etc, elements here?

6.1. [SCS] Dynamic graphics: The bitmap canvas

This needs to be reviewed for normative criteria. As it stands there is terrible abuse of the word "should", for example.

The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.

When authors use the canvas element, they should also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element.

Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies such as XBL.

In non-visual media, and in visual media with scripting disabled, the canvas element should be treated as an ordinary block-level element and the fallback content should therefore be used instead.

In non-interactive, static, visual media, if the canvas element has been previously painted on (e.g. if the page was viewed in an interactive visual media and is now being printed, or if some script that ran during the page layout process painted on the element), then the canvas element should be treated as a replaced inline-level element with the current image and size. Otherwise, the element should be treated as an ordinary inline-level element and the fallback content should therefore be used instead.

In interactive visual media with scripting enabled, the canvas element is an inline-level replaced element.

The canvas element has two attributes to control the size of the coordinate space: height and width. These attributes each take a positive integer value (one digit in the range 1-9 followed by zero or more digits in the range 0-9, interpreted in base ten). If an attribute is missing, or if it has a value that does not match this syntax, then its default value must be used instead. The width attribute defaults to 300, and the height attribute defaults to 150.

The intrinsic dimensions of the canvas element equal the size of the coordinate space, with the numbers interpreted in CSS pixels. However, the element can be sized arbitrarily by a style sheet. During rendering, the image is scaled to fit this layout size.

The size of the coordinate space does not necessarily represent the size of the actual bitmap that the user agent will use internally or during rendering. On high-definition displays, for instance, the user agent may internally use a bitmap with two device pixels per unit in the coordinate space, so that the rendering remains at high quality throughout.

If the width and height attributes are dynamically modified, the bitmap and any associated contexts must be cleared back to their initial state and reinitialised with the newly specified coordinate space dimensions.

The canvas is initially fully transparent black. Whenever the width and height attributes are changed, the canvas must be cleared back to this state.

As with any replaced element, the CSS background properties do apply to canvas elements; they are rendered below the canvas image.

interface HTMLCanvasElement : HTMLElement {

  // returns the values of the width and height attributes, or the assumed
  // defaults if the attributes were not specified or invalid
  // sets the relevant content attributes on setting
         attribute long                    width;
         attribute long                    height;

  // returns a data: URI representing the current image as a PNG
  DOMString toDataURL();

  // returns a data: URI representing the current image in the specified format
  DOMString toDataURL(in DOMString type);

  // returns the context with which to paint, see below
  DOMObject getContext(in DOMString contextID);

};

To draw on the canvas, authors must first obtain a reference to a context using the getContext method of the canvas element.

This specification only defines one context, with the name "2d". If getContext() is called with that exact string, then the UA must return a reference to an object implementing CanvasRenderingContext2D. Other specifications may define their own contexts, which would return different objects.

Vendors may also define experimental contexts using the syntax vendorname-context, for example, moz-3d.

When the UA is passed an empty string or a string specifying a context that it does not support, then it must return null. String comparisons should be literal and case-sensitive.

A future version of this specification will probably define a 3d context (probably based on the OpenGL ES API).

The toDataURL() method must, when called with no arguments, return a data: URI containing a representation of the image as a PNG file. [PNG].

The toDataURL(type) method (when called with one or more arguments) must return a data: URI containing a representation of the image in the format given by type. The possible values are MIME types with no parameters, for example image/png, image/jpeg, or even maybe image/svg+xml if the implementation actually keeps enough information to reliably render an SVG image from the canvas.

Only support for image/png is required. User agents may support other types. If the user agent does not support the requested type, it must return the image using the PNG format.

User agents must convert the provided type to lower case before establishing if they support that type and before creating the data: URL.

When trying to use types other than image/png, authors can check if the image was really returned in the requested format by checking to see if the returned string starts with the exact string "data:image/png" or not. If it does, the image is PNG, and thus the requested type was not supported.

Arguments other than the type must be ignored, and must not cause the user agent to raise an exception (as would normally occur if a method was called with the wrong number of arguments). A future version of this specification will probably allow extra parameters to be passed to toDataURL() to allow authors to more carefully control compression settings, image metadata, etc.

Security: To prevent information leakage, the toDataURL() methods should raise a security exception if the canvas ever had images painted on it that originate from a domain other than the domain of the script that painted the images onto the canvas.

6.1.1. The 2D context

When the getContext() method of a canvas element is invoked with 2d as the argument, a CanvasRenderingContext2D object is returned.

There is only one CanvasRenderingContext2D object per canvas, so calling the getContext() method with the 2d argument a second time must return the same object.

The 2D context represents a flat cartesian surface whose origin (0,0) is at the top left corner, with the coordinate space having x values increasing when going right, and y values increasing when going down.

interface CanvasRenderingContext2D {

  // back-reference to the canvas
  readonly attribute HTMLCanvasElement       canvas;

  // state
  void save(); // push state on state stack
  void restore(); // pop state stack and restore state

  // transformations (default transform is the identity matrix)
  void scale(in float x, in float y);
  void rotate(in float angle);
  void translate(in float x, in float y);

  // compositing
           attribute float                   globalAlpha; // (default 1.0)
           attribute DOMString               globalCompositeOperation; // (default over)

  // colours and styles
           attribute DOMObject               strokeStyle; // (default black)
           attribute DOMObject               fillStyle; // (default black)
  CanvasGradient createLinearGradient(in float x0, in float y0, in float x1, in float y1);
  CanvasGradient createRadialGradient(in float x0, in float y0, in float r0, in float x1, in float y1, in float r1);
  CanvasPattern createPattern(in HTMLImageElement image, DOMString repetition);
  CanvasPattern createPattern(in HTMLCanvasElement image, DOMString repetition);

  // line caps/joins
           attribute float                   lineWidth; // (default 1)
           attribute DOMString               lineCap; // "butt", "round", "square" (default "butt")
           attribute DOMString               lineJoin; // "round", "bevel", "miter" (default "miter")
           attribute float                   miterLimit; // (default 10)

  // shadows
           attribute float                   shadowOffsetX; // (default 0)
           attribute float                   shadowOffsetY; // (default 0)
           attribute float                   shadowBlur; // (default 0)
           attribute DOMString               shadowColor; // (default black)

  // rects
  void clearRect(in float x, in float y, in float w, in float h);
  void fillRect(in float x, in float y, in float w, in float h);
  void strokeRect(in float x, in float y, in float w, in float h);

  // path API
  void beginPath();
  void closePath();
  void moveTo(in float x, in float y);
  void lineTo(in float x, in float y);
  void quadraticCurveTo(in float cpx, in float cpy, in float x, in float y);
  void bezierCurveTo(in float cp1x, in float cp1y, in float cp2x, in float cp2y, in float x, in float y);
  void arcTo(in float x1, in float y1, in float x2, in float y2, in float radius);
  void rect(in float x, in float y, in float w, in float h);
  void arc(in float x, in float y, in float radius, in float startAngle, in float endAngle, in boolean anticlockwise);
  void fill();
  void stroke();
  void clip();
  boolean isPointInPath(in float x, in float y);

  // drawing images
  void drawImage(in HTMLImageElement image, in float dx, in float dy);
  void drawImage(in HTMLImageElement image, in float dx, in float dy, in float dw, in float dh);
  void drawImage(in HTMLImageElement image, in float sx, in float sy, in float sw, in float sh, in float dx, in float dy, in float dw, in float dh);
  void drawImage(in HTMLCanvasElement image, in float dx, in float dy);
  void drawImage(in HTMLCanvasElement image, in float dx, in float dy, in float dw, in float dh);
  void drawImage(in HTMLCanvasElement image, in float sx, in float sy, in float sw, in float sh, in float dx, in float dy, in float dw, in float dh);

  // drawing text is not supported in this version of the API
  // (there is no way to predict what metrics the fonts will have,
  // which makes fonts very hard to use for painting)

};

interface CanvasGradient {
  // opaque object
  void addColorStop(in float offset, in DOMString color);
};

interface CanvasPattern {
  // opaque object
};

The canvas attribute returns the canvas element that the context paints on.

6.1.1.1. The canvas state

Each context maintains a stack of drawing states. Drawing states consist of:

The current transformation matrix.
The current clip region.
The current values of the following attributes: strokeStyle, fillStyle, globalAlpha, lineWidth, lineCap, lineJoin, miterLimit, shadowOffsetX, shadowOffsetY, shadowBlur, shadowColor, globalCompositeOperation.

The current path and the current bitmap are not part of the drawing state. The current path is persistent, and can only be reset using the beginPath() method. The current bitmap is a property of the canvas, not the context.

The save() method pushes a copy of the current drawing state onto the drawing state stack.

The restore() method pops the top entry in the drawing state stack, and resets the drawing state it describes. If there is no saved state, the method does nothing.

6.1.1.2. Transformations

The transformation matrix is applied to all drawing operations prior to their being rendered. It is also applied when creating the clip region.

When the context is created, the transformation matrix must initially be the identity transform. It may then be adjusted using the three transformation methods.

The transformations must be performed in reverse order. For instance, if a scale transformation that doubles the width is applied, followed by a rotation transformation that rotates drawing operations by a quarter turn, and a rectangle twice as wide as it is tall is then drawn on the canvas, the actual result will be a square.

The scale(x, y) method must add the scaling transformation described by the arguments to the transformation matrix. The x argument represents the scale factor in the horizontal direction and the y argument represents the scale factor in the vertical direction. The factors are multiples.

The rotate(angle) method must add the rotation transformation described by the argument to the transformation matrix. The angle argument represents a clockwise rotation angle expressed in radians.

The translate(x, y) method must add the translation transformation described by the arguments to the transformation matrix. The x argument represents the translation distance in the horizontal direction and the y argument represents the translation distance in the vertical direction. The arguments are in coordinate space units.

6.1.1.3. Compositing

All drawing operations are affected by the global compositing attributes, globalAlpha and globalCompositeOperation.

The globalAlpha attribute gives an alpha value that is applied to shapes and images before they are composited onto the canvas. The valid range of values is from 0.0 (fully transparent) to 1.0 (no additional transparency). If an attempt is made to set the attribute to a value outside this range, the attribute must retain its previous value. When the context is created, the globalAlpha attribute must initially have the value 1.0.

The globalCompositeOperation attribute sets how shapes and images are drawn onto the existing bitmap, once they have had globalAlpha and the current transformation matrix applied. It may be set to any of the values in the following list. In the descriptions below, the source image is the shape or image being rendered, and the destination image is the current state of the bitmap.

The source-* descriptions below don't define what should happen with semi-transparent regions.

source-atop: Display the source image wherever both images are opaque. Display the destination image wherever the destination image is opaque but the source image is transparent. Display transparency elsewhere.
source-in: Display the source image wherever both the source image and destination image are opaque. Display transparency elsewhere.
source-out: Display the source image wherever the source image is opaque and the destination image is transparent. Display transparency elsewhere.
source-over (default): Display the source image wherever the source image is opaque. Display the destination image elsewhere.
destination-atop: Same as source-atop but using the destination image instead of the source image and vice versa.
destination-in: Same as source-in but using the destination image instead of the source image and vice versa.
destination-out: Same as source-out but using the destination image instead of the source image and vice versa.
destination-over: Same as source-over but using the destination image instead of the source image and vice versa.
darker: Display the sum of the source image and destination images, with color values approaching 0 as a limit.
lighter: Display the sum of the source image and destination image, with color values approaching 1 as a limit.
copy: Display the source image instead of the destination image.
xor: Exclusive OR of the source and destination images.
vendorName-operationName: Vendor-specific extensions to the list of composition operators should use this syntax.

On setting, if the user agent does not recognise the specified value, it must be ignored, leaving the value of globalCompositeOperation unaffected.

When the context is created, the globalCompositeOperation attribute must initially have the value source-over.

6.1.1.4. Colours and styles

The strokeStyle attribute represents the colour or style to use for the lines around shapes, and the fillStyle attribute represents the colour or style to use inside the shapes.

Both attributes can be either strings, CanvasGradients, or CanvasPatterns. On setting, strings should be parsed as CSS <color> values. [CSS3COLOR] If the value is a string but is not a valid colour, or is neither a string, a CanvasGradient, nor a CanvasPattern, then it must be ignored, and the attribute must retain its previous value.

On getting, if the value is a color, then: if it has alpha equal to 1.0, then the colour must be returned as an uppercase six-digit hex value, prefixed with a "#" character (U+0023 NUMBER SIGN), with the first two digits representing the red component, the next two digits representing the green component, and the last two digits representing the blue component, the digits being in the range 0-9 A-F (U+0030 to U+0039 and U+0041 to U+0046). If the value has alpha less than 1.0, then the value must instead be returned in the CSS rgba() functional-notation format: the literal string rgba (U+0072 U+0067 U+0062 U+0061) followed by a U+0028 LEFT PARENTHESIS, a base-ten integer in the range 0-255 representing the red component (using digits 0-9, U+0030 to U+0039), a literal U+0020 SPACE and U+002C COMMA, an integer for the green component, a space and a comma, an integer for the blue component, another space and comma, a U+0030 DIGIT ZERO, a U+002E FULL STOP (representing the decimal point), one or more digits in the range 0-9 (U+0030 to U+0039) representing the fractional part of the alpha value, and finally a U+0029 RIGHT PARENTHESIS.

Otherwise, if it is not a color but a CanvasGradient or CanvasPattern, then an object supporting those interfaces must be returned. Such objects are opaque and therefore only useful for assigning to other attributes or for comparison to other gradients or patterns.

When the context is created, the strokeStyle and fillStyle attributes must initially have the string value #000000.

There are two types of gradients, linear gradients and radial gradients, both represented by objects implementing the opaque CanvasGradient interface.

Once a gradient has been created (see below), stops must be placed along it to define how the colours are distributed along the gradient. Between each such stop, the colours and the alpha component are interpolated over the RGBA space to find the colour to use at that offset. Immediately before the 0 offset and immediately after the 1 offset, transparent black stops are assumed.

The addColorStop(offset, color) method on the CanvasGradient interface adds a new stop to a gradient. If the offset is less than 0 or greater than 1 then an INDEX_SIZE_ERR exception is raised. If the color cannot be parsed as a CSS colour, then a SYNTAX_ERR exception is raised. Otherwise, the gradient is updated with the new stop information.

The createLinearGradient(x0, y0, x1, y1) method takes four arguments, representing the start point (x0, y0) and end point (x1, y1) of the gradient, in coordinate space units, and returns a linear CanvasGradient initialised with that line.

Linear gradients are rendered such that at the starting point on the canvas the colour at offset 0 is used, that at the ending point the color at offset 1 is used, that all points on a line perpendicular to the line between the start and end points have the colour at the point where those two lines cross, and that any points beyond the start or end points are a transparent black. (Of course, the colours are only painted where the shape they are being painted on needs them.)

The createRadialGradient(x0, y0, r0, x1, y1, r1) method takes six arguments, the first three representing the start circle with origin (x0, y0) and radius r0, and the last three representing the end circle with origin (x1, y1) and radius r1. The values are in coordinate space units. The method returns a radial CanvasGradient initialised with those two circles.

Radial gradients are rendered such that a cone is created from the two circles, so that at the circumference of the starting circle the colour at offset 0 is used, that at the circumference around the ending circle the color at offset 1 is used, that the circumference of a circle drawn a certain fraction of the way along the line between the two origins with a radius the same fraction of the way between the two radii has the colour at that offset, that the end circle appear to be above the start circle when the end circle is not completely enclosed by the start circle, and that any points not described by the gradient are a transparent black.

If a gradient has no stops defined, then the gradient is treated as a solid transparent black. Gradients are, naturally, only painted where the stroking or filling effect requires that they be drawn.

Support for actually painting gradients is optional. Instead of painting the gradients, user agents may instead just paint the first stop's colour. However, createLinearGradient() and createRadialGradient() must always return objects when passed valid arguments.

Patterns are represented by objects implementing the opaque CanvasPattern interface.

To create objects of this type, the createPattern(image, repetition) method is used. The first argument gives the image to use as the pattern (either an HTMLImageElement or an HTMLCanvasElement). Modifying this image after calling the createPattern() method must not affect the pattern. The second argument must be a string with one of the following values: repeat, repeat-x, repeat-y, no-repeat. If the empty string or null is specified, repeat is assumed. If an unrecognised value is given, then the user agent must raise a SYNTAX_ERR exception. The method returns a CanvasPattern object suitably initialised.

Patterns are painted so that the top left of the first image is anchored at the origin of the coordinate space, and images are then repeated horizontally to the left and right (if the repeat-x string was specified) or vertically up and down (if the repeat-y string was specified) or in all four directions all over the canvas (if the repeat string was specified). The images are not be scaled by this process; one CSS pixel of the image must be painted on one coordinate space unit. Of course, patterns must only actually painted where the stroking or filling effect requires that they be drawn, and are affected by the current transformation matrix.

Support for patterns is optional. If the user agent doesn't support patterns, then createPattern() must return null.

6.1.1.5. Line styles

The lineWidth attribute gives the default width of lines, in coordinate space units. On setting, zero and negative values must be ignored, leaving the value unchanged.

When the context is created, the lineWidth attribute must initially have the value 1.0.

The lineCap attribute defines the type of endings that UAs shall place on the end of lines. The three valid values are butt, round, and square. The butt value means that the end of each line is a flat edge perpendicular to the direction of the line. The round value means that a semi-circle with the diameter equal to the width of the line is then added on to the end of the line. The square value means that at the end of each line is a rectangle with the length of the line width and the width of half the line width, placed flat against the edge perpendicular to the direction of the line. On setting, any other value than the literal strings butt, round, and square must be ignored, leaving the value unchanged.

When the context is created, the lineCap attribute must initially have the value butt.

The lineJoin attribute defines the type of corners that that UAs shall place where two lines meet. The three valid values are round, bevel, and miter.

On setting, any other value than the literal strings round, bevel and miter must be ignored, leaving the value unchanged.

When the context is created, the lineJoin attribute must initially have the value miter.

The round value means that a filled arc connecting the corners on the outside of the join, with the diameter equal to the line width, and the origin at the point where the inside edges of the lines touch, is rendered at the join. The bevel value means that a filled triangle connecting those two corners with a straight line, the third point of the triangle being the point where the lines touch on the inside of the join, is rendered at the join. The miter value means that a filled four- or five-sided polygon is placed at the join, with two of the lines being the perpendicular edges of the joining lines, and the other two being continuations of the outside edges of the two joining lines, as long as required to intersect without going over the miter limit.

The miter length is the distance from the point where the lines touch on the inside of the join to the intersection of the line edges on the outside of the join. The miter limit is the maximum allowed ratio of the miter length to the line width. If the miter limit would be exceeded, then a fifth line is added to the polygon, connecting the two outside lines, such that the distance from the inside point of the join to the point in the middle of this fifth line is the maximum allowed value for the miter length.

The miter limit ratio can be explicitly set using the miterLimit attribute. On setting, zero and negative values must be ignored, leaving the value unchanged.

When the context is created, the miterLimit attribute must initially have the value 10.0.

6.1.1.6. Shadows

All drawing operations are affected by the four global shadow attributes. Shadows form part of the source image during composition.

The shadowColor attribute sets the colour of the shadow.

When the context is created, the shadowColor attribute initially must be fully-transparent black.

The shadowOffsetX and shadowOffsetY attributes specify the distance that the shadow should be offset in the positive horizontal and positive vertical distance respectively. Their values are in coordinate space units.

When the context is created, the shadow offset attributes initially have the value 0.

The shadowBlur attribute specifies the number of coordinate space units that the blurring should cover. On setting, negative numbers must be ignored, leaving the attribute unmodified.

When the context is created, the shadowBlur attribute must initially have the value 0.

Support for shadows is optional.

6.1.1.7. Simple shapes (rectangles)

There are three methods that immediately draw rectangles to the bitmap. They each take four arguments; the first two give the x and y coordinates of the top left of the rectangle, and the second two give the width and height of the rectangle, respectively.

Shapes are painted without affecting the current path, and are subject to transformations, shadow effects, global alpha, clipping paths, and global composition operators.

Negative values for width and height must cause the implementation to raise an INDEX_SIZE_ERR exception.

The clearRect() method clears the pixels in the specified rectangle to a fully transparent black, erasing any previous image.

The fillRect() method paints the specified rectangular area using the fillStyle.

The strokeRect() method draws a rectangular outline of the specified size using the strokeStyle, lineWidth, lineJoin, and (if appropriate) miterLimit attributes.

6.1.1.8. Complex shapes (paths)

The context always has a current path. There is only one current path, it is not part of the drawing state.

A path has a list of subpaths and a current position. Each subpath consists of a list of points, some of which may be connected by straight and curved lines, and a flag indicating whether the subpath is closed or not.

The beginPath() method resets the list of subpaths to an empty list, and calls moveTo() with the point (0,0). When the context is created, a call to beginPath() is implied.

The moveTo(x, y) method sets the current position to the given coordinate and creates a new subpath with that point as its first (and only) point. If there was a previous subpath, and it consists of just one point, then that subpath is removed from the path.

The closePath() method adds a straight line from the current position to the first point in the last subpath and marks the subpath as closed, if the last subpath isn't closed, and if it has more than one point in its list of points. If the last subpath is not open or has only one point, it does nothing.

The lineTo(x, y) method adds the given coordinate (x, y) to the list of points of the subpath, and connects the current position to that point with a straight line. It then sets the current position to the given coordinate (x, y).

The quadraticCurveTo(cpx, cpy, x, y) method adds the given coordinate (x, y) to the list of points of the subpath, and connects the current position to that point with a quadratic curve with control point (cpx, cpy). It then sets the current position to the given coordinate (x, y).

The bezierCurveTo(cp1x, cp1y, cp2x, cp2y, x, y) method adds the given coordinate (x, y) to the list of points of the subpath, and connects the two points with a bezier curve with control points (cp1x, cp1y) and (cp2x, cp2y). It then sets the current position to the given coordinate (x, y).

The arcTo(x1, y1, x2, y2, radius) method adds an arc to the current path. The arc is given by the circle that has one point tangent to the line from the current position to point (x1, y1), one point tangent to the line from from the point (x1, y1) to the point (x2, y2), and that has radius radius. The points at which this circle touches these two lines are called the start and end tangent points respectively.

If the point (x2, y2) is on the line from the current position to point (x1, y1) then this method does nothing. Otherwise, the arc is the shortest path along the circle's circumference between those two points. If the first tangent point is not equal to the current position then the first tangent point is added to the list of points of the subpath and the current position is joined to that point by a straight line. Then, the second tangent point is added to the list of points and the two tangent points are joined by the arc described above. Finally, the current position is set to the second tangent point.

Negative or zero values for radius must cause the implementation to raise an INDEX_SIZE_ERR exception.

The arc(x, y, radius, startAngle, endAngle, anticlockwise) method adds an arc to the current path. The arc is given by the circle that has its origin at (x, y) and that has radius radius. The points at startAngle and endAngle along the circle, measured in radians clockwise from the positive x-axis, are the start and end points. The arc is the path along the circumference of the circle from the start point to the end point going anti-clockwise if the anticlockwise argument is true, and clockwise otherwise.

The start point is added to the list of points of the subpath and the current position is joined to that point by a straight line. Then, the end point is added to the list of points and these last two points are joined by the arc described above. Finally, the current position is set to the end point.

Negative or zero values for radius must cause the implementation to raise an INDEX_SIZE_ERR exception.

The rect(x, y, w, h) method creates a new subpath containing just the rectangle with top left coordinate (x, y), width w and height h, and marks it as closed. It then calls moveTo with the point (0,0).

Negative values for w and h must cause the implementation to raise an INDEX_SIZE_ERR exception.

The fill() method fills each subpath of the current path in turn, using fillStyle, and using the non-zero winding number rule. Open subpaths are implicitly closed when being filled (without affecting the actual subpaths).

The stroke() method strokes each subpath of the current path in turn, using the strokeStyle, lineWidth, lineJoin, and (if appropriate) miterLimit attributes.

Paths, when filled or stroked, are painted without affecting the current path, and are subject to transformations, shadow effects, global alpha, clipping paths, and global composition operators.

The clip() method creates a new clipping path by calculating the intersection of the current clipping path and the area described by the current path, using the non-zero winding number rule. Open subpaths are implicitly closed without affecting the actual subpaths).

When the context is created, the initial clipping path is the rectangle with the top left corner at (0,0) and the width and height of the coordinate space.

The isPointInPath(x, y) method must return true if the point given by the x and y coordinates passed to the method, when treated as coordinates in the canvas' coordinate space unaffected by the current transformation, is within the area of the canvas that is inside the current path; and must return false otherwise.

6.1.1.9. Images

To draw images onto the canvas, the drawImage method may be used.

This method is overloaded with three variants: drawImage(image, dx, dy), drawImage(image, dx, dy, dw, dh), and drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh). (Actually it is overloaded with six; each of those three can take either an HTMLImageElement or an HTMLCanvasElement for the image argument.) If not specified, the dw and dh arguments default to the values of sw and sh, interpreted such that one CSS pixel in the image is treated as one unit in the canvas coordinate space. If the sx, sy, sw, and sh arguments are omitted, they default to 0, 0, the image's intrinsic width in image pixels, and the image's intrinsic height in image pixels, respectively.

The image argument must be an instance of an HTMLImageElement or HTMLCanvasElement. If the image is of the wrong type, the implementation must raise a TYPE_MISMATCH_ERR exception. If one of the sy, sw, sw, and sh arguments is outside the size of the image, or if one of the dw and dh arguments is negative, the implementation must raise an INDEX_SIZE_ERR exception.

When drawImage is invoked, the specified region of the image specified by the source rectangle (sx, sy, sw, sh) must be painted on the region of the canvas specified by the destination rectangle (dx, dy, dw, dh).

Images are painted without affecting the current path, and are subject to transformations, shadow effects, global alpha, clipping paths, and global composition operators.

6.1.1.10. Drawing model

When a shape or image is painted, user agents must follow these steps, in the order given (or act as if they do):

The coordinates are transformed by the current transformation matrix.
The shape or image is rendered, creating image A, as described in the previous sections. For shapes, the current fill, stroke, and line styles must be honoured.
The shadow is rendered from image A, using the current shadow styles, creating image B.
Image A is composited over image B creating the source image.
The source image has its alpha adjusted by globalAlpha.
Within the clip region (as affected by the current transformation matrix), the source image is composited over the current canvas bitmap using the current composition operator.

6.1.2. The 3D context

Well, one day.

6.2. [SCS] Sound

The Audio interface allows scripts to play sound clips.

There is no markup element that corresponds to Audio objects, they are only accessible from script.

User agents should allow users to dynamically enable and disable sound output, but doing so must not affect how Audio objects act in any way other than whether sounds are physically played back or not. For instance, sound files must still be downloaded, load events must still fire, and if two identical clips are started with a two second interval then when the sound is reenabled they must still be two seconds out of sync.

When multiple sounds are played simultaneously, the user agent must mix the sounds together.

interface Audio {
           attribute EventListener onload;
  void play();
  void loop();
  void loop(in unsigned long repeatCount);
  void stop();
};

Audio objects must also implement the EventTarget interface. [DOM3EVENTS]

In ECMAScript, an instance of Audio can be created using the Audio(uri) constructor:

var a = new Audio("test.wav");

The Audio() constructor takes a single argument, a URI (or IRI), which is resolved using the script context's window.location.href value as the base, and which returns an Audio object that will, at the completion of the current script, start loading that URI.

Once the URI is loaded, a load event must be fired on the Audio object.

Audio objects have a current position and a repeat count. Both are initially zero.

The Audio interface has the following members:

onload: An event listener that is invoked along with any other appropriate event listeners that are registered on this object when a load event is fired on it.
play(): Begins playing the sound at the current position, setting the repeat count to 1.
loop(): Begins playing the sound at the current position, setting the repeat count to infinity.
loop(repeatCount): Begins playing the sound at the current position, setting the repeat count to repeatCount.
stop(): Stops playing the clip and resets the current position and repeat count to zero.

When playback of the sound reaches the end of the available data, its current position is reset to the start of the clip, and the repeat count is decreased by one (unless it is infinite). If the repeat count is greater than zero, then the sound is played again.

7. Communication

7.1. [SCS] Server-sent DOM events

This section describes a mechanism for allowing servers to dispatch DOM events into documents that expect it.

7.1.1. The `event-source` element

To specify an event source in an HTML document authors use a new (empty) element event-source, with an attribute src="" that takes a URI (or IRI) to open as a stream and, if the data found at that URI is of the appropriate type, treat as an event source.

The event-source element may also have an onevent="" attribute. If present, the attribute must be treated as script representing an event handler registered as non-capture listener of events with name event and the namespace uuid:755e2d2d-a836-4539-83f4-16b51156341f or null, that are targetted at or bubble through the element.

UAs must also support all the common attributes on the event-source element.

7.1.2. The `RemoteEventTarget` interface

Any object that implements the EventTarget interface shall also implement the RemoteEventTarget interface.

interface RemoteEventTarget {
  void addEventSource(in DOMString src);
  void removeEventSource(in DOMString src);
};

The addEventSource(src) method shall register the URI (or IRI) specified in src as an event source on the object. The removeEventSource(src) method shall remove the URI (or IRI) specified in src from the list of event sources for that object. If a single URI is added multiple times, each instance must be handled individually. Removing a URI must only remove one instance of that URI. If the specified URI cannot be added or removed, the method must return without doing anything or raising an exception.

7.1.3. Processing model

When an event-source element in a document has a src attribute set, the UA should fetch the resource indicated by the attribute's value.

Similarly, when the addEventSource() method is invoked on an object, the UA should, at the completion of the script's current execution, fetch the resource identified by the method's argument (unless the removeEventSource() was called removing the URI from the list first).

When an event-source element is removed from the document, or when an event source is removed from the list of event sources for an object using the removeEventSource() method, the relevant connection must be closed (and not reopened unless the element is returned to the document or the addEventSource() method is called with the same URI again).

Should event-source elements be allowed to point to any remote server, or only origin hosts?

Since connections established to remote servers for such resources are expected to be long-lived, UAs should ensure that appropriate buffering is used. In particular, while line buffering may be safe if lines are defined to end with a single U+000A LINE FEED character, block buffering or line buffering with different expected line endings can cause delays in event dispatch.

In general, the semantics of the transport protocol specified by the "src" attribute must be followed. Clients should re-open event-source connections that get closed after a short interval (such as 5 seconds), unless they were closed due to problems that aren't expected to be resolved, as described in this section.

DNS errors must be considered fatal, and cause the user agent to not open any connection for the event-source.

HTTP 200 OK responses that have a Content-Type other than application/x-dom-event-stream must be ignored and must prevent the user agent from reopening the connection for that event-source. HTTP 200 OK responses with the right MIME type, however, should, when closed, be reopened after a small delay.

Resource with the type application/x-dom-event-stream must be processed line by line as described below.

HTTP 201 Created, 202 Accepted, 203 Non-Authoritative Information, and 206 Partial Content responses must be treated like HTTP 200 OK responses for the purposes of reopening event-source connections. They are, however, likely to indicate an error has occurred somewhere and may cause the user agent to emit a warning.

HTTP 204 No Content, and 205 Reset Content responses must be treated as if they were 200 OK responses with the right MIME type but no content, and should therefore cause the user agent to reopen the connection after a short delay.

HTTP 300 Multiple Choices responses should be handled automatically if possible (treating the responses as if they were 302 Moved Permanently responses pointing to the appropriate resource), and otherwise must be treated as HTTP 404 responses.

HTTP 301 Moved Permanently responses must cause the user agent to use the server specified URI instead of the one specified in the event-source's "src" attribute for future connections.

HTTP 302 Found, 303 See Other, and 307 Temporary Redirect responses must cause the user agent to use the server specified URI instead of the one specified in the event-source's "src" attribute for the next connection, but if the user agent needs to reopen the connection at a later point, it must once again start from the "src" attribute (or the last URI given by a 301 Moved Permanently response in complicated cases where such responses are chained).

HTTP 304 Not Modified responses should be handled like HTTP 200 OK responses, with the content coming from the user agent cache. A new connection attempt should then be made after a short wait.

HTTP 305 Use Proxy, HTTP 401 Unauthorized, and 407 Proxy Authentication Required should be treated transparently as for any other subresource.

HTTP 400 Bad Request, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 406 Not Acceptable, 408 Request Timeout, 409 Conflict, 410 Gone, 411 Length Required, 412 Precondition Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415 Unsupported Media Type, 416 Requested Range Not Satisfiable, 417 Expectation Failed, 500 Internal Server Error, 501 Not Implemented, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout, and 505 HTTP Version Not Supported responses, and any other HTTP response code not listed here, should cause the user agent to stop trying to process this event-source element.

For non-HTTP protocols, UAs should act in equivalent ways.

7.1.4. The event stream format

The event stream MIME type is application/x-dom-event-stream.

The event stream must always be encoded as UTF-8. Line must always be terminated by a single U+000A LINE FEED character.

The event stream format is (in pseudo-BNF):

<stream>  ::= <event>*
<event>   ::= [ <comment> | <command> | <field> ]* <newline>

<comment> ::= ';' <data> <newline>
<command> ::= ':' <data> <newline>
<field>   ::= <name> [ ':' <space>? <data> ]? <newline>

<name>    ::= one or more UNICODE characters other than ':', ';', and U+000A LINE FEED
<data>    ::= zero or more UNICODE characters other than U+000A LINE FEED
<space>   ::= a single U+0020 SPACE character (' ')
<newline> ::= a single U+000A LINE FEED character

Bytes that are not valid UTF-8 sequences must be interpreted as the U+FFFD REPLACEMENT CHARACTER.

The stream is parsed by reading everything line by line, in blocks separated by blank lines (blank lines are those consisting of just a single lone line feed character). Comment lines (those starting with the character ';') and command lines (those starting with the character ':') are ignored. Command lines are reserved for future use and should not be used.

For each non-blank, non-comment line, the field name is first taken. This is everything on the line up to but not including the first colon (':') or the line feed, whichever comes first. Then, if there was a colon, the data for that line is taken. This is everything after the colon, ignoring a single space after the colon if there is one, up to the end of the line. If there was no colon the data is the empty string.

Examples:

Field name: Field data

This is a blank field

1. These two lines: have the same data
2. These two lines:have the same data

1. But these two lines:  do not
2. But these two lines: do not

If a field name occurs multiple times, the data values for those lines are concatenated with a newline between them.

For example, the following:

Test: Line 1
Foo: Bar
Test: Line 2

...is treated as having two fields, one called Test with the value Line 1\nLine 2 (where \n represents a newline), and one called Foo with the value Bar.

Since any random stream of characters matches the above format, there is no need to define any error handling.

7.1.5. Event stream interpretation

Once the fields have been parsed, they are interpreted as follows (these are case-sensitive exact comparisons):

Event is the name of the event. For example, load, DOMActivate, updateTicker. If there is no field with this name, then no event will be synthesised, and the other data will be ignored.
Namespace is the DOM3 namespace for the event. For normal DOM events this would be http://www.w3.org/2001/xml-events. If it isn't specified the event namespace is null.
Class is the interface used for the event, for instance Event, UIEvent, MutationEvent, KeyboardEvent, etc. For compatibility with DOM3 Events, the values UIEvents, MouseEvents, MutationEvents, and HTMLEvents are valid values and must be treated respectively as meaning the interfaces UIEvent, MouseEvent, MutationEvent, and Event. (This value can therefore be used as the argument to createEvent().) If the value is not specified it is defaulted based on the event name as follows:
- If Namespace is http://www.w3.org/2001/xml-events or null and the Event field exactly matches one of the events specified by DOM3 Events in section 1.4.2 "Complete list of event types", then the Class defaults to the interface relevant for that event type. [DOM3EVENTS]
  For example:
```
Event: click
```
  ...would cause Class to be treated as MouseEvent.
- If Namespace is uuid:755e2d2d-a836-4539-83f4-16b51156341f or null and the Event doesn't match any of the known events, then the RemoteEvent interface (described below) is used.
- Otherwise, if the UA doesn't have special knowledge of which class to use for the given event in the given namespace, then the Event interface is used.
It is quite possible to give the wrong class for an event. This is equivalent to creating an event in the DOM using the DOM Event APIs, but using the wrong interface for it.
Bubbles specifies whether the event is to bubble. If it is specified and has the value No, the event does not bubble. If it is specified and has any other value (including no or No\n) then the event bubbles. If it is not specified it is defaulted based on the event name as follows:
- If Namespace is http://www.w3.org/2001/xml-events or null and the Event field exactly matches one of the events specified by DOM3 Events in section 1.4.2 "Complete list of event types", then whether the event bubbles depends on whether the DOM3 Events spec specifies that that event should bubble or not. [DOM3EVENTS]
  For example:
```
Event: load
```
  ...would cause Bubbles to be treated as No.
- Otherwise, if the UA doesn't have special knowledge of which class to use for the given event in the given namespace, then the event bubbles.
Cancelable specifies whether the event may have its default action prevented. If it is specified and has the value No, the event may not have its default action prevented. If it is specified and has any other value (including no or No\n) then the event may be canceled. If it is not specified it is defaulted based on the event name as follows:
- If Namespace is http://www.w3.org/2001/xml-events or null and the Event field exactly matches one of the events specified by DOM3 Events in section 1.4.2 "Complete list of event types", then whether the event is cancelable depends on whether the DOM3 Events spec specifies that that event should be cancelable or not. [DOM3EVENTS]
  For example:
```
Event: load
```
  ...would cause Cancelable to be treated as No.
- Otherwise, if the UA doesn't have special knowledge of which class to use for the given event in the given namespace, then the event may be canceled.
Target is the element that the event is to be dispatched on. If its value starts with a # character then the remainder of the value represents an ID, and the event must be dispatched on the same node as would be obtained by the getElementById() method on the ownerDocument of the event-source element responsible for the event being dispatched.
For example,
```
Target: #test
```
...would target the element with ID test.
If the value does not start with a # but has the literal value Document, then the event is dispatched at the ownerDocument of the event-source element responsible for the event being dispatched.

Otherwise, the event is dispatched at the event-source element itself.
Other fields depend on the interface specified (or possibly implied) by the Class field. If the specified interface has an attribute that exactly matches the name of the field, and the value of the field can be converted (using the type conversions defined in ECMAScript) to the type of the attribute, then it must be used. Any attributes (other than the Event interface attributes) that do not have matching fields are initialised to zero, null, false, or the empty string.
For example:
```
; ...some other fields...
Class: MouseEvent
button: 2
```
...would result in a MouseEvent event that had button set to 2 but screenX, screenY, etc, set to 0, false, or null as appropriate.
If a field does not match any of the attributes on the event, it is ignored.
For example:
```
Event: keypress
Class: MouseEvent
keyIdentifier: 0
```
...would result in a MouseEvent event with its fields all at their default values, with the event name being keypress. The ctrlKey field would be ignored. (If the author had not included the Class field explicitly, it would have just worked, since the class would have defaulted as described above.)

Once a blank line is reached, an event of the appropriate type is synthesized and dispatched to the appropriate node as described by the fields above. No event is dispatched until a blank line has been received.

If the Event field was omitted, then no event is synthesised and the data is ignored.

The following stream contains four blocks yet synthesises no events, since none of the blocks have a field called Event. (The first block has just a comment, the second block has two fields with names "load" and "Target" respectively, the third block is empty, and the fourth block has two comments.)

; test

load
Target: #image1


; if any real events follow this block, they will not be affected by
; the "Target" and "load" fields above.

7.1.6. The `RemoteEvent` interface

The RemoteEvent interface is defined as follows:

interface RemoteEvent : Event {
  readonly attribute DOMString       data;
  void               initRemoteEvent(in DOMString typeArg,
                                     in boolean canBubbleArg,
                                     in boolean cancelableArg,
                                     in DOMString dataArg);
  void               initRemoteEventNS(in DOMString namespaceURI,
                                       in DOMString typeArg,
                                       in boolean canBubbleArg,
                                       in boolean cancelableArg,
                                       in DOMString dataArg);
};

Events that use the RemoteEvent interface never have any default action associated with them.

7.1.7. Example

The following event description, once followed by a blank line:

Event: stock change
data: YHOO
data: -2
data: 10

...would cause an event stock change with the interface RemoteEvent to be dispatched on the event-source element, which would then bubble up the DOM, and whose data attribute would contain the string YHOO\n-2\n10 (where \n again represents a newline).

This could be used as follows:

<event-source src="http://stocks.example.com/ticker.php" id="stock">
<script type="text/javascript">
document.getElementById('stock').addEventListener('stock change',
  function () {
    var data = event.data.split('\n');
    updateStocks(data[0], data[1], data[2]);
  }, false);
</script>

...where updateStocks is a function defined as:

function updateStocks(symbol, delta, value) { ... }

...or some such.

7.2. [SCS] Network connections

To enable Web applications to communicate with each other in local area networks, and to maintain bidirectional communications with their originating server, this specification introduces the Connection interface.

The Window interface provides three constructors for creating Connection objects: TCPConnection(), for creating a direct (possibly encrypted) link to another node on the Internet using TCP/IP; LocalBroadcastConnection(), for creating a connection to any listening peer on a local network (which could be a local TCP/IP subnet using UDP, a Bluetooth PAN, or another kind of network infrastructure); and PeerToPeerConnection(), for a direct peer-to-peer connection (which could again be over TCP/IP, Bluetooth, IrDA, or some other type of network).

This interface does not allow for raw access to the underlying network. For example, this interface could not be used to implement an IRC client without proxying messages through a custom server.

7.2.1. Introduction [TBW]

This section is non-normative.

An introduction to the client-side and server-side of using the direct connection APIs.

An example of a party-line implementation of a broadcast service, and direct peer-to-peer chat for direct local connections.

7.2.2. The `Connection` interface

interface Connection {
  readonly attribute DOMString network;
  readonly attribute DOMString peer;
  readonly attribute int readyState;
           attribute EventListener onopen;
           attribute EventListener onread;
           attribute EventListener onclose;
  void send(in DOMString data);
  void disconnect();
};

Connection objects must also implement the EventTarget interface. [DOM3EVENTS]

When a Connection object is created, the UA must try to establish a connection, as described in the sections below describing each connection type.

The network attribute represents the name of the network connection (the value depends on the kind of connection being established). The peer attribute identifies the remote host for direct (non-broadcast) connections.

The network attribute must be set as soon as the Connection object is created, and keeps the same value for the lifetime of the object. The peer attribute must initially be set to the empty string and must be updated once, when the connection is established, after which point it must keep the same value for the lifetime of the object.

The readyState attribute represents the state of the connection. When the object is created it must be set to 0. It can have the following values:

0 Connecting: The connection has not yet been established.
1 Connected: The connection is established and communication is possible.
2 Closed: The connection has been closed.

Once a connection is established, the readyState attribute's value must be changed to 1, and the open event must be fired on the Connection object.

When data is received, the read event will be fired on the Connection object.

When the connection is closed, the readyState attribute's value must be changed to 2, and the close event must be fired on the Connection object.

The onopen, onread, and onclose attributes must, when set, register their new value as an event listener for their respective events (namely open, read, and close), and unregister their previous value if any.

The send() method transmits data using the connection. If the connection is not yet established, it must raise an INVALID_STATE_ERR exception. If the connection is established, then the behaviour depends on the connection type, as described below.

The disconnect() method must close the connection, if it is open. If the connection is already closed, it must do nothing. Closing the connection causes a close event to be fired and the readyState attribute's value to change, as described above.

7.2.3. Connection Events

All the events described in this section are events in the http://www.w3.org/2001/xml-events namespace, which do not bubble, are not cancelable, and have no default action.

The open event is fired when the connection is established. UAs must use the normal Event interface when firing this event.

The close event is fired when the connection is closed (whether by the author, calling the disconnect() method, or by the server, or by a network error). UAs must use the normal Event interface when firing this event as well.

No information regarding why the connection was closed is passed to the application in this version of this specification.

The read event is fired when when data is received for a connection. UAs must use the ConnectionReadEvent interface for this event.

interface ConnectionReadEvent : Event {
  readonly attribute DOMString data;
  readonly attribute DOMString source;
  void               initConnectionReadEvent(in DOMString typeArg, 
                                            in boolean canBubbleArg, 
                                            in boolean cancelableArg, 
                                            in DOMString dataArg);
  void               initConnectionReadEventNS(in DOMString namespaceURI, 
                                              in DOMString typeArg, 
                                              in boolean canBubbleArg, 
                                              in boolean cancelableArg, 
                                              in DOMString dataArg);
};

The data attribute must contain the data that was transmitted from the peer.

The source attribute must contain the name of the peer. This is primarily useful on broadcast connections; on direct connections it is equal to the peer attribute on the Connection object.

The initConnectionReadEvent() and initConnectionReadEventNS() methods must initialise the event in a manner analogous to the similarly-named methods in the DOM3 Events interfaces. [DOM3EVENTS]

Events that would be fired during script execution (e.g. between the connection object being created — and thus the connection being established — and the current script completing; or, during the execution of a read event handler) must be buffered, and those events queued up and each one individually fired after the script has completed.

7.2.4. TCP connections

The TCPConnection(subdomain, port, secure) constructor on the Window interface returns a new object implementing the Connection interface, set up for a direct connection to a specified host on the page's domain.

When this constructor is invoked, the following steps must be followed.

First, if the script's domain is not a host name (e.g. it is an IP address) then the UA must raise a security exception. We currently don't allow connections to be set up back to an originating IP address, but we could, if the subdomain is the empty string.

Then, if the subdomain argument is null or the empty string, the target host is the script's domain. Otherwise, the subdomain argument is prepended to the script's domain with a dot separating the two strings, and that is the target host.

If the target host is not a valid host name, or if the port argument is not either equal to 80, 443, or greater than 1024 and less then 65537, then the UA must raise a security exception.

Otherwise, the user agent must verify that the the string representing the script's domain in IDNA format can be obtained without errors. If it cannot, then the user agent must raise a security exception.

The user agent may also raise a security exception at this time if, for some reason, permission to create a direct TCP connection to the relevant host is denied. Reasons could include the UA being instructed by the user to not allow direct connections, or the UA establishing (for instance using UPnP) that the network topology will cause connections on the specified port to be directed at the wrong host.

If no exceptions are raised by the previous steps, then a new Connection object must be created, its peer attribute must be set to a string consisting of the name of the target host, a colon (U+003A COLON), and the port number as decimal digits, and its network attribute must be set to the same value as the peer attribute.

This object must then be returned.

The user agent must then begin trying to establish a connection with the target host and specified port. (This typically would begin in the backgound, while the script continues to execute.)

If the secure boolean argument is set to true, then the user agent must establish a secure connection with the target host and specified port using TLS or another protocol, negotiated with the server. [RFC2246] If this fails the user agent must act as if it had closed the connection.

Once a secure connection is established, or if the secure boolean argument is not set to true, then the user agent must continue to connect to the server using the protocol described in the section entitled clients connecting over TCP. All data on connections made using TLS must be sent as "application data".

Once the connection is established, the UA must act as described in the section entitled sending and receiving data over TCP.

User agents should allow multiple TCP connections to be established per host. In particular, user agents should not apply per-host HTTP connection limits to connections established with the TCPConnection constructor.

7.2.5. Broadcast connections

The LocalBroadcastConnection() constructor on the Window interface returns a new object implementing the Connection interface, set up to broadcast on the local network.

When this constructor is invoked, a new Connection object must be created.

The network attribute of the object must be set to the string representing the script's domain in IDNA format. If this string cannot be obtained, then the user agent must raise a security exception exception when the constructor is called.

The peer attribute must be set to the empty string.

The object must then be returned, unless, for some reason, permission to broadcast on the local network is to be denied. In the latter case, a security exception must be raised instead. User agents may deny such permission for any reason, for example a user preference.

If the object is returned (i.e. if no exception is raised), the user agent must the begin broadcasting and listening on the local network, in the background, as described below. The user agent may define "the local network" in any way it considers appropriate and safe; for instance the user agent may ask the user which network (e.g. Bluetooth, IrDA, Ethernet, etc) the user would like to broadcast on before beginning broadcasting.

UAs may broadcast and listen on multiple networks at once. For example, the UA could broadcast on both Bluetooth and Wifi at the same time.

As soon as the object is returned, the connection has been established, which implies that the open event must be fired. Broadcast connections are never closed.

7.2.5.1. Broadcasting over TCP/IP

We need to register a UDP port for this. For now this spec refers to port 18080/udp.

Since this feature requires that the user agent listen to a particular port, typically only one user agent per IP address can use this feature at any one time.

On TCP/IP networks, broadcast connections transmit data using UDP over port 18080.

When the send(data) method is invoked on a Connection object that was created by the LocalBroadcastConnection() constructor, the user agent must follow these steps:

Create a string consisting of the value of the network attribute of the Connection object, a U+0020 SPACE character, a U+0002 START OF TEXT character, and the data argument.
Encode the string as UTF-8.
If the resulting byte stream is longer than 65487 bytes, raise an INDEX_SIZE_ERR DOM exception and stop.
Create a UDP packet whose data is the byte stream, with the source and destination ports being 18080, and with appropriate length and checksum fields. Transmit this packet to IPv4 address 255.255.255.255 or IPv6 address ff02::1, as appropriate. IPv6 applications will also have to enable reception from this address.

When a broadcast connection is opened on a TCP/IP network, the user agent should listen for UDP packets on port 18080.

When the user agent receives a packet on port 18080, the user agent must attempt to decode that packet's data as UTF-8. If the data is not fully correct UTF-8 (i.e. if there are decoding errors) then the packet must be ignored. Otherwise, the user agent must check to see if the decoded string contains a U+0020 SPACE character. If it does not, then the packet must again be ignored (it might be a peer discovery packet from a PeerToPeerConnection() constructor). If it does then the user agent must split the the string at the first space character. All the characters before the space are then known as d, and all the characters after the space are known as s. If s is not at least one character long, or if the first character of s is not a U+0002 START OF TEXT character, then the packet must be ignored. (This allows for future extension of this protocol.)

Otherwise, for each Connection object that was created by the LocalBroascastConnection() constructor and whose network attribute exactly matches d, a read event must be fired on the Connection object. The string s, with the first character removed, must be used as the data, and the source IP address of the packet as the source.

Making the source IP available means that if two or more machines in a private network can be made to go to a hostile page simultaneously, the hostile page can determine the IP addresses used locally (i.e. on the other side of any NAT router). Is there some way we can keep link-local IP addresses secret while still allowing for applications to distinguish between multiple participants?

7.2.5.2. Broadcasting over Bluetooth

Does anyone know enough about Bluetooth to write this section?

7.2.5.3. Broadcasting over IrDA

Does anyone know enough about IrDA to write this section?

7.2.6. Peer-to-peer connections

The PeerToPeerConnection() constructor on the Window interface returns a new object implementing the Connection interface, set up for a direct connection to a user-specified host.

When this constructor is invoked, a new Connection object must be created.

The peer attribute must be set to the empty string.

The object must then be returned, unless, for some reason, permission to establish peer-to-peer connections is generally disallowed, for example due to administrator settings. In the latter case, a security exception must be raised instead.

The user agent must then, typically while the script resumes execution, find a remote host to establish a connection to. To do this it must start broadcasting and listening for peer discovery messages and listening for incoming connection requests on all the supported networks. How this is performed depends on the type of network and is described below.

The UA should inform the user of the clients that are detected, and allow the user to select one to connect to. UAs may also allow users to explicit specify hosts that were not detected, e.g. by having the user enter an IP address.

If an incoming connection is detected before the user specifies a target host, the user agent should ask the user to confirm that this is the host they wish to connect to. If it is, the connection should be accepted and the UA will act as the server in this connection. (Which UA acts as the server and which acts as the client is not discernible at the DOM API level.)

If no incoming connection is detected and if the user specifies a particular target host, a connection should be established to that host, with the UA acting as the client in the connection.

No more than one connection must be established per Connection object, so once a connection has been established, the user agent must stop listening for further connections (unless, or until such time as, another Connection object is being created).

If at any point the user cancels the connection process or the remote host refuses the connection, then the user agent must act as if it had closed the connection, and stop trying to connect.

7.2.6.1. Peer-to-peer connections over TCP/IP

We need to register ports for this. For now this spec refers to port 18080/udp and 18080/tcp.

Since this feature requires that the user agent listen to a particular port, typically only one user agent per IP address can use this feature at any one time.

When using TCP/IP, broadcasting peer discovery messages must be done by creating UDP packets every few seconds containing as their data the value of the connection's network attribute, encoded as UTF-8, with the source and destination ports being set to 18080 and appropriate length and checksum fields, and sending these packets to address (in IPv4) 255.255.255.255 or (in IPv6) ff02::1, as appropriate.

Listening for peer discovery messages must be done by examining incoming UDP packets on port 18080. IPv6 applications will also have to enable reception from the ff02::1 address. If their payload is exactly byte-for-byte equal to a UTF-8 encoded version of the value of the connection's network attribute, then the source address of that packet represents the address of a host that is ready to accept a peer-to-peer connection, and it should therefore be offered to the user.

Incoming connection requests must be listened for on TCP port 18080. If an incoming connection is received, the UA acts as a server, as described in the section entitled servers accepting connections over TCP.

If no incoming connection requests are accepted and the user instead specifies a target host to connect to, the UA acts as a client: the user agent must attempt to connect to the user-specified host on port 18080, as described in the section entitled clients connecting over TCP.

Once the connection is established, the UA must act as described in the section entitled sending and receiving data over TCP.

This specification does not include a way to establish secure (encrypted) peer-to-peer connections at this time. If you can see a good way to do this, let me know.

7.2.6.2. Peer-to-peer connections over Bluetooth

Does anyone know enough about Bluetooth to write this section?

7.2.6.3. Peer-to-peer connections over IrDA

Does anyone know enough about IrDA to write this section?

7.2.7. The common protocol for TCP-based connections

The same protocol is used for TCPConnection and PeerToPeerConnection connection types. This section describes how such connections are established from the client and server sides, and then describes how data is sent and received over such connections (which is the same for both clients and servers).

7.2.7.1. Clients connecting over TCP

This section defines the client-side requirements of the protocol used by the TCPConnection and PeerToPeerConnection connection types.

If a TCP connection to the specified target host and port cannot be established, for example because the target host is a domain name that cannot be resolved to an IP address, or because packets cannot be routed to the host, the user agent should retry creating the connection. If the user agent gives up trying to connect, the user agent must act as if it had closed the connection.

No information regarding the state of the connection is passed to the application while the connection is being established in this version of this specification.

Once a TCP/IP connection to the remote host is established, the user agent must transmit the following sequence of bytes, represented here in hexadecimal form:

0x48 0x65 0x6C 0x6C 0x6F 0x0A

This represents the string "Hello" followed by a newline, encoded in UTF-8.

The user agent must then read all the bytes sent from the remote host, up to the first 0x0A byte (inclusive). That string of bytes is then compared byte-for-byte to the following string of bytes:

0x57 0x65 0x6C 0x63 0x6F 0x6E 0x65 0x0A

This says "Welcome".

If the server sent back a string in any way different to this, then the user agent must close the connection and give up trying to connect.

Otherwise, the user agent must then take the string representing the script's domain in IDNA format, encode it as UTF-8, and send that to the remote host, followed by a 0x0A byte (a U+000A LINE FEED in UTF-8).

The user agent must then read all the bytes sent from the remote host, up to the first 0x0A byte (inclusive). That string of bytes must then be compared byte-for-byte to the string that was just sent to the server (the one with the IDNA domain name and ending with a newline character). If the server sent back a string in any way different to this, then the user agent must close the connection and give up trying to connect.

Otherwise, the connection has been established (and events and so forth get fired, as described above).

If at any point during this process the connection is closed prematurely, then the user agent must close the connection and give up trying to connect.

7.2.7.2. Servers accepting connections over TCP

This section defines the server side of the protocol described in the previous section. For authors, it should be used as a guide for how to implement servers that can communicate with Web pages over TCP. For UAs these are the requirements for the server part of PeerToPeerConnections.

Once a TCP/IP connection from a remote host is established, the user agent must transmit the following sequence of bytes, represented here in hexadecimal form:

0x57 0x65 0x6C 0x63 0x6F 0x6E 0x65 0x0A

This says "Welcome" and a newline in UTF-8.

The user agent must then read all the bytes sent from the remote host, up to the first 0x0A byte (inclusive). That string of bytes is then compared byte-for-byte to the following string of bytes:

0x48 0x65 0x6C 0x6C 0x6F 0x0A

"Hello" and a newline.

If the remote host sent back a string in any way different to this, then the user agent must close the connection and give up trying to connect.

The user agent must then read all the bytes sent from the remote host, up to the first 0x0A byte (inclusive). That string of bytes must then be compared byte-for-byte to the string that was just sent to that host (the one with the IDNA domain name and ending with a newline character). If the remote host sent back a string in any way different to this, then the user agent must close the connection and give up trying to connect.

Otherwise, the connection has been established (and events and so forth get fired, as described above).

For author-written servers (as opposed to the server side of a peer-to-peer connection), the script's domain would be replaced by the hostname of the server. Alternatively, such servers might instead wait for the client to send its domain string, and then simply echo it back. This would allow connections from pages on any domain, instead of just pages originating from the same host. The client compares the two strings to ensure they are the same before allowing the connection to be used by author script.

If at any point during this process the connection is closed prematurely, then the user agent must close the connection and give up trying to connect.

7.2.7.3. Sending and receiving data over TCP

When the send(data) method is invoked on the connection's corresponding Connection object, the user agent must take the data argument, replace any U+0000 NULL and U+0017 END OF TRANSMISSION BLOCK characters in it with U+FFFD REPLACEMENT CHARACTER characters, then transmit a U+0002 START OF TEXT character, this new data string and a single U+0017 END OF TRANSMISSION BLOCK character (in that order) to the remote host, all encoded as UTF-8.

When the user agent receives bytes on the connection, the user agent must buffer received bytes until it receives a 0x17 byte (a U+0017 END OF TRANSMISSION BLOCK character). If the first buffered byte is not a 0x02 byte (a U+0002 START OF TEXT character encoded as UTF-8) then all the data up to the 0x17 byte, inclusive, must be dropped. (This allows for future extension of this protocol.) Otherwise, all the data from (but not including) the 0x02 byte and up to (but not including) the 0x17 byte must be taken, interpreted as a UTF-8 string, and a read event must be fired on the Connection object with that string as the data. If that string cannot be decoded as UTF-8 without errors, the packet should be ignored.

This protocol does not yet allow binary data (e.g. an image or video data) to be efficiently transmitted. A future version of this protocol might allow this by using the prefix character U+001F INFORMATION SEPARATOR ONE, followed by binary data which uses a particular byte (e.g. 0xFF) to encode byte 0x17 somehow (since otherwise 0x17 would be treated as transmission end by down-level UAs).

7.2.8. Security

Need to write this section.

If you have an unencrypted page that is (through a man-in-the-middle attack) changed, it can access a secure service that is using IP authentication and then send that data back to the attacker. Ergo we should probably stop unencrypted pages from accessing encrypted services, on the principle that the actual level of security is zero. Then again, if we do that, we prevent insecure sites from using SSL as a tunneling mechanism.

Should consider dropping the subdomain-only restriction. It doesn't seem to add anything, and prevents cross-domain chatter.

7.2.9. Relationship to other standards

Should have a section talking about the fact that we blithely ignoring IANA's port assignments here.

Should explain why we are not reusing HTTP for this. (HTTP is too heavy-weight for such a simple need; requiring authors to implement an HTTP server just to have a party line is too much of a barrier to entry; cannot rely on prebuilt components; having a simple protocol makes it much easier to do RAD; HTTP doesn't fit the needs and doesn't have the security model needed; etc)

7.3. [SCS] Cross-document messaging

Web browsers, for security and privacy reasons, prevent documents in different domains from affecting each other; that is, cross-site scripting is disallowed.

While this is an important security feature, it prevents pages from different domains from communicating even when those pages are not hostile. This section introduces a messaging system that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks.

7.3.1. Definitions

Any Document object that supports this cross-document messaging API must implement the DocumentMessaging interface.

interface DocumentMessaging {
  void postMessage(in DOMString message);
};

Such Document objects must also implement the EventTarget interface. [DOM3EVENTS]

The postMessage() method causes an event to be dispatched (as defined below). This event uses the following interface:

interface CrossDocumentMessageEvent : Event {
  readonly attribute DOMString data;
  readonly attribute DOMString domain;
  readonly attribute DOMString uri;
  readonly attribute Document source;
  void initCrossDocumentMessageEvent(in DOMString typeArg,
                                     in boolean canBubbleArg,
                                     in boolean cancelableArg,
                                     in DOMString dataArg,
                                     in DOMString domainArg,
                                     in DOMString uriArg,
                                     in Document documentArg);
  void initCrossDocumentMessageEventNS(in DOMString namespaceURI,
                                       in DOMString typeArg,
                                       in boolean canBubbleArg,
                                       in boolean cancelableArg,
                                       in DOMString dataArg,
                                       in DOMString domainArg,
                                       in DOMString uriArg,
                                       in Document documentArg);
};

7.3.2. Processing model

When a script invokes the postMessage() method on a document, the user agent must create an event that uses the CrossDocumentMessageEvent interface, with the event name message in the uuid:7f37e11a-3a5c-4f3d-a82e-83b611439f37 namespace, which bubbles, is cancelable, and has no default action. The data attribute must be set to the value passed as the argument to the postMessage() method, the domain attribute must be set to the domain of the document that the script that invoked the methods is associated with, the uri attribute must be set to the URI of that document, and the source attribute must be set to the object representing that document.

Authors should check the domain attribute to ensure that messages are only accepted from domains that they expect to receive messages from. Otherwise, bugs in the author's message handling code could be exploited by hostile sites.

For example, if document A contains an object element that contains document B, and script in document A calls postMessage() on document B, then a message event will be fired on that element, marked as originating from document A. The script in document A might look like:

var o = document.getElementsByTagName('object')[0];
o.contentDocument.postMessage('Hello world');

To register an event handler for incoming events, the script would use addEventListener() (or similar mechanisms). For example, the script in document B might look like:

document.addEventListener('message', receiver, false);
function receiver(e) {
  if (e.domain == 'example.com') {
    if (e.data == 'Hello world') {
      e.source.postMessage('Hello');
    } else {
      alert(e.data);
    }
  }
}

This script first checks the domain is the expected domain, and then looks at the message, which it either displays to the user, or responds to by sending a message back to the document which sent the message in the first place.

Implementors are urged to take extra care in the implementation of this feature. It allows authors to transmit information from one domain to another domain, which is normally disallowed for security reasons. It also requires that UAs be careful to allow access to certain properties but not others.

The initCrossDocumentMessageEvent() and initCrossDocumentMessageEventNS() methods must initialise an event object in a manner analogous to other initXXXEvent metheds.

8. The HTML syntax

8.1. Writing HTML documents [TBW]

This section only applies to authors and markup generators.

This section needs writing.

8.2. [SCS] Parsing HTML documents

This section only applies to user agents.

Yet to be defined: how this integrates with document.open() and document.close() -- something about opening at the start and closing at the end, once all pending document.write()s have been processed. Interaction with tokeniser's EOF character is important, since the tokeniser can hit this character, emit a <script> block causing more characters to be introduced, and then has to ignore the EOF it hit before.

The rules for parsing XHTML documents into DOM trees are covered by the XML and Namespaces in XML specifications, and are out of scope of this specification.

For HTML documents, user agents must use the parsing rules described in this section to generate the DOM trees.

While the HTML form of HTML5 bears a close resemblance to SGML and XML, it is a separate language with its own parsing rules.

Some earlier versions of HTML (in particular from HTML2 to HTML4) were based on SGML and used SGML parsing rules. However, few (if any) web browsers ever implemented true SGML parsing for HTML documents; the only user agents to strictly handle HTML as an SGML application have historically been validators. The resulting confusion — with validators claiming documents to have one representation while widely deployed Web browsers interoperably implemented a different representation — has resulted in this version of HTML returning to a non-SGML basis.

Authors interested in using SGML tools in their authoring pipeline are encouraged to use the XML serialisation of HTML5 instead of the HTML serialisation.

This specification defines the parsing rules for HTML documents, whether they are syntactically valid or not. Certain points in the parsing algorithm are said to be parse errors. The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below.

Conformance checkers must report at least one parse error condition to the user if one or more parse error conditions exist in the document and must not report parse error conditions if none exist in the document. Conformance checkers may report more than one parse error condition if more than one parse error conditions exist in the document. Conformance checkers are not required to recover from parse errors.

Parse errors are only errors with the syntax of HTML. In addition to checking for parse errors, conformance checkers will also verify that the document obeys all the other conformance requirements described in this specification.

The input to the HTML parsing process consists of a stream of Unicode characters, which is passed through a tokenisation stage (lexical analysis) followed by a tree construction stage (semantic analysis). The output is a Document object.

Implementations that do not support scripting do not have to actually create a DOM Document object, but the DOM tree in such cases is still used as the model for the rest of the specification.

For HTML, user agents must use the following algorithm in determining the character encoding of a document:

If the transport layer specifies an encoding, use that.
Otherwise, if the user agent can find a meta element that specifies character encoding information, then use that. (The exact parsing rules for finding and using this information are not yet described in this specification.) This needs to be fleshed out a whole heck of a lot more.
Otherwise, the user agent may attempt to autodetect the character encoding from applying frequency analysis or other algorithms to the data stream. If autodetection succeeds in determining a character encoding, then use that.
Otherwise, use an implementation-defined or user-specified default character encoding (ISO-8859-1, windows-1252, and UTF-8 are recommended as defaults, and can in many cases be identified by inspection as they have different ranges of valid bytes).

For XHTML documents, the algorithm user agents must use to determine the character encoding is given by the XML specification. This section does not apply to XHTML documents. [XML]

Bytes or sequences of bytes in the original byte stream that could not be converted to Unicode characters must be converted to U+FFFD REPLACEMENT CHARACTER code points.

A leading U+FEFF BYTE ORDER MARK (BOM) must be dropped if present.

All U+0000 NULL characters in the input must be replaced by U+FFFD REPLACEMENT CHARACTERs.

U+000D CARRIAGE RETURN (CR) characters, and U+000A LINE FEED (LF) characters, are treated specially. Any CR characters that are followed by LF characters must be removed, and any CR characters not followed by LF characters must be converted to LF characters. Thus, newlines in HTML DOMs are represented by LF characters, and there are never any CR characters in the input to the tokenisation stage.

8.2.1. Tokenisation

Implementations must act as if they used the following state machine to tokenise HTML. The state machine must start in the data state. Most states consume a single character, which may have various side-effects, and either switches the state machine to a new state to reconsume the same character, or switches it to a new state (to consume the next character), or repeats the same state (to consume the next character). Some states have more complicated behaviour and can consume several characters before switching to another state.

The "EOF" character in the tables below is a conceptual character representing the end of the input file. It is not a real character in the stream, but rather the lack of any further characters.

The exact behaviour of certain states depends on a content model flag that is set after certain tokens are emitted. The flag has several states: PCDATA, RCDATA, CDATA, and PLAINTEXT. Initially it is in the PCDATA state.

The output of the tokenisation step is a series of zero or more of the following tokens: DOCTYPE, start tag, end tag, comment, character, end-of-file. DOCTYPE tokens have names and can be either correct or in error. Start and end tag tokens have a tagname and a list of attributes, each of which has a name and a value. Comment and character tokens have data.

When a token is emitted, it must immediately be handled by the tree construction stage. The tree construction stage can affect the state of the content model flag, and can insert additional characters into the stream. (For example, the script element can result in scripts executing and using the document.write() API to insert characters into the stream being tokenised.)

Data state

Consume the next input character:

U+0026 AMPERSAND (&): When the content model flag is set to one of the PCDATA or RCDATA states: switch to the entity data state.; Otherwise: treat it as per the "anything else" entry below.
U+003C LESS-THAN SIGN (<): When the content model flag is set to a state other than the PLAINTEXT state: switch to the tag open state.; Otherwise: treat it as per the "anything else" entry below.
EOF: Emit an end-of-file token.
Anything else: Emit the input character as a character token. Stay in the data state.

Entity data state

(This cannot happen if the content model flag is set to the CDATA state.)

Attempt to consume an entity.

If nothing is returned, emit a U+0026 AMPERSAND character token.

Otherwise, emit the character token that was returned.

Finally, switch to the data state.

Tag open state

The behaviour of this state depends on the content model flag.

If the content model flag is set to the RCDATA or CDATA states

If the next input character is a U+002F SOLIDUS (/) character, consume it and switch to the close tag open state. If the next input character is not a U+002F SOLIDUS (/) character, emit a U+003C LESS-THAN SIGN character token and reconsume the current input character in the data state.

If the content model flag is set to the PCDATA state

Consume the next input character:

U+0021 EXCLAMATION MARK (!): Switch to the marked section open state.
U+002F SOLIDUS (/): Switch to the close tag open state.
U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL LETTER Z: Create a new start tag token, set its tag name to the lowercase version of the input character (add 0x0020 to the character's codepoint), then switch to the tag name state. (Don't emit the token yet; further details will be filled in before it is emitted.)
U+0061 LATIN SMALL LETTER A through to U+007A LATIN SMALL LETTER Z: Create a new start tag token, set its tag name to the input character, then switch to the tag name state. (Don't emit the token yet; further details will be filled in before it is emitted.)
U+003E GREATER-THAN SIGN (>): Parse error. Emit a U+003C LESS-THAN SIGN character token and a U+003E GREATER-THAN SIGN character token. Switch to the data state.
U+003F QUESTION MARK (?): Parse error. Switch to the bogus comment state.
EOF: Parse error. Emit a U+003C LESS-THAN SIGN character token, then emit an end-of-file token.
Anything else: Parse error. Emit a U+003C LESS-THAN SIGN character token and reconsume the current input character in the data state.

Close tag open state

If the content model flag is set to the RCDATA or CDATA states then examine the next few characters. If they do not match the tag name of the last start tag token emitted (case insensitively), or if they do but they are not immediately followed by one of the following characters:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE
U+003E GREATER-THAN SIGN (>)
U+002F SOLIDUS (/)
U+003C LESS-THAN SIGN (<)
EOF

...then there is a parse error. Emit a U+003C LESS-THAN SIGN character token, a U+002F SOLIDUS character token, and reconsume the current input character in the data state.

Otherwise, if the content model flag is set to the PCDATA state, or if the next few characters do match that tag name, consume the next input character:

U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL LETTER Z: Create a new end tag token, set its tag name to the lowercase version of the input character (add 0x0020 to the character's codepoint), then switch to the tag name state. (Don't emit the token yet; further details will be filled in before it is emitted.)
U+0061 LATIN SMALL LETTER A through to U+007A LATIN SMALL LETTER Z: Create a new end tag token, set its tag name to the input character, then switch to the tag name state. (Don't emit the token yet; further details will be filled in before it is emitted.)
U+003E GREATER-THAN SIGN (>): Parse error. Switch to the data state.
EOF: Parse error. Emit a U+003C LESS-THAN SIGN character token and a U+002F SOLIDUS character token, then emit an end-of-file token.
Anything else: Parse error. Switch to the bogus comment state.

Tag name state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Switch to the before attribute name state.
U+003E GREATER-THAN SIGN (>): Emit the current tag token. Switch to the data state.
U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL LETTER Z: Append the lowercase version of the current input character (add 0x0020 to the character's codepoint) to the current tag token's tag name. Stay in the tag name state.
U+003C LESS-THAN SIGN (<): Parse error. Emit the current tag token. Reconsume the character in the data state.
U+002F SOLIDUS (/): Parse error. Switch to the before attribute name state.
EOF: Parse error. Emit the current tag token and an end-of-file token.
Anything else: Append the current input character to the current tag token's tag name. Stay in the tag name state.

Before attribute name state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Stay in the before attribute name state.
U+003E GREATER-THAN SIGN (>): Emit the current tag token. Switch to the data state.
U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL LETTER Z: Start a new attribute in the current tag token. Set that attribute's name to the lowercase version of the current input character (add 0x0020 to the character's codepoint), and its value to the empty string. Switch to the attribute name state.
U+002F SOLIDUS (/): Parse error. Stay in the before attribute name state.
U+003C LESS-THAN SIGN (<): Parse error. Emit the current tag token. Reconsume the character in the data state.
EOF: Parse error. Emit the current tag token and an end-of-file token.
Anything else: Start a new attribute in the current tag token. Set that attribute's name to the current input character, and its value to the empty string. Switch to the attribute name state.

Attribute name state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Switch to the after attribute name state.
U+003D EQUALS SIGN (=): Switch to the before attribute value state.
U+003E GREATER-THAN SIGN (>): Emit the current tag token. Switch to the data state.
U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL LETTER Z: Append the lowercase version of the current input character (add 0x0020 to the character's codepoint) to the current attribute's name. Stay in the attribute name state.
U+002F SOLIDUS (/): Parse error. Switch to the before attribute name state.
U+003C LESS-THAN SIGN (<): Parse error. Emit the current tag token. Reconsume the character in the data state.
EOF: Parse error. Emit the current tag token and an end-of-file token.
Anything else: Append the current input character to the current attribute's name. Stay in the attribute name state.

When the user agent leaves the attribute name state (and before emitting the tag token, if appropriate), the complete attribute's name must be compared to the other attributes on the same token; if it is a duplicate, then it must be dropped, along with the value that gets associated with it (if any).

After attribute name state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Stay in the after attribute name state.
U+003D EQUALS SIGN (=): Switch to the before attribute value state.
U+003E GREATER-THAN SIGN (>): Emit the current tag token. Switch to the data state.
U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL LETTER Z: Start a new attribute in the current tag token. Set that attribute's name to the lowercase version of the current input character (add 0x0020 to the character's codepoint), and its value to the empty string. Switch to the attribute name state.
U+002F SOLIDUS (/): Parse error. Switch to the before attribute name state.
U+003C LESS-THAN SIGN (<): Parse error. Emit the current tag token. Reconsume the character in the data state.
EOF: Parse error. Emit the current tag token and an end-of-file token.
Anything else: Start a new attribute in the current tag token. Set that attribute's name to the current input character, and its value to the empty string. Switch to the attribute name state.

Before attribute value state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Stay in the before attribute value state.
U+0022 QUOTATION MARK ("): Switch to the attribute value (double-quoted) state.
U+0026 AMPERSAND (&): Switch to the attribute value (unquoted) state and reconsume this input character.
U+0027 APOSTROPHE ('): Switch to the attribute value (single-quoted) state.
U+003E GREATER-THAN SIGN (>): Emit the current tag token. Switch to the data state.
U+003C LESS-THAN SIGN (<): Parse error. Emit the current tag token. Reconsume the character in the data state.
EOF: Parse error. Emit the current tag token and an end-of-file token.
Anything else: Append the current input character to the current attribute's value. Switch to the attribute value (unquoted) state.

Attribute value (double-quoted) state

Consume the next input character:

U+0022 QUOTATION MARK ("): Switch to the before attribute name state.
U+0026 AMPERSAND (&): Switch to the entity in attribute value state.
EOF: Parse error. Emit the current tag token and an end-of-file token.
Anything else: Append the current input character to the current attribute's value. Stay in the attribute value (double-quoted) state.

Attribute value (single-quoted) state

Consume the next input character:

U+0027 APOSTROPHE ('): Switch to the before attribute name state.
U+0026 AMPERSAND (&): Switch to the entity in attribute value state.
EOF: Parse error. Emit the current tag token and an end-of-file token.
Anything else: Append the current input character to the current attribute's value. Stay in the attribute value (single-quoted) state.

Attribute value (unquoted) state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Switch to the before attribute name state.
U+0026 AMPERSAND (&): Switch to the entity in attribute value state.
U+003E GREATER-THAN SIGN (>): Emit the current tag token. Switch to the data state.
U+003C LESS-THAN SIGN (<): Parse error. Emit the current tag token. Reconsume the character in the data state.
EOF: Parse error. Emit the current tag token and an end-of-file token.
Anything else: Append the current input character to the current attribute's value. Stay in the attribute value (unquoted) state.

Entity in attribute value state

Attempt to consume an entity.

If nothing is returned, append a U+0026 AMPERSAND character to the current attribute's value.

Otherwise, append the returned character token to the current attribute's value.

Finally, switch back to the attribute value state that you were in when were switched into this state.

Bogus comment state

(This can only happen if the content model flag is set to the PCDATA state.)

Consume every character up to the first U+003E GREATER-THAN SIGN character (>) or the end of the file (EOF), whichever comes first. Emit a comment token whose data is the concatenation of all the characters from the character that caused the state machine to switch into the bogus comment state, up to the last consumed character before the U+003E character, if any, or up to the end of the file otherwise.

Switch to the data state.

If the end of the file was reached, reconsume the EOF character.

Marked section open state

(This can only happen if the content model flag is set to the PCDATA state.)

If the next two characters are both U+002D HYPHEN-MINUS (-) characters, consume those two characters, create a comment token whose data is the empty string, and switch to the comment state.

Otherwise if the next seven chacacters are a case-insensitive match for the word "DOCTYPE" then switch to the DOCTYPE state.

Otherwise, is is a parse error. Switch to the bogus comment state.

Comment state

Consume the next input character:

U+002D HYPHEN-MINUS (-): Switch to the comment dash state
EOF: Parse error. Emit the comment token and an end-of-file token.
Anything else: Append the input character to the comment token's data. Stay in the comment state.

Comment dash state

Consume the next input character:

U+002D HYPHEN-MINUS (-): Switch to the comment end state
EOF: Parse error. Emit the comment token and an end-of-file token.
Anything else: Append a U+002D HYPHEN-MINUS (-) character and the input character to the comment token's data. Switch to the comment state.

Comment end state

Consume the next input character:

U+002D HYPHEN-MINUS (-): Parse error. Append a U+002D HYPHEN-MINUS (-) character to the comment token's data. Stay in the comment end state.
U+003E GREATER-THAN SIGN (>): Emit the comment token. Switch to the data state.
EOF: Parse error. Emit the comment token and an end-of-file token.
Anything else: Append two U+002D HYPHEN-MINUS (-) characters and the input character to the comment token's data. Switch to the comment state.

DOCTYPE state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Switch to the before DOCTYPE name state.
Anything else: Parse error. Reconsume the current character in the before DOCTYPE name state.

Before DOCTYPE name state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Stay in the before DOCTYPE name state.
U+0061 LATIN SMALL LETTER A through to U+007A LATIN SMALL LETTER Z: Create a new DOCTYPE token. Set the token's name name to the uppercase version of the current input character (subtract 0x0020 from the character's codepoint), and mark it as being in error. Switch to the DOCTYPE name state.
U+003E GREATER-THAN SIGN (>): Parse error. Emit a DOCTYPE token whose name is the empty string and that is marked as being in error. Switch to the data state.
EOF: Parse error. Emit a DOCTYPE token whose name is the empty string and that is marked as being in error, then emit an end-of-file token.
Anything else: Create a new DOCTYPE token. Set the token's name name to the current input character, and mark it as being in error. Switch to the DOCTYPE name state.

DOCTYPE name state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Switch to the after DOCTYPE name state.
U+003E GREATER-THAN SIGN (>): Emit the current DOCTYPE token. Switch to the data state.
U+0061 LATIN SMALL LETTER A through to U+007A LATIN SMALL LETTER Z: Append the uppercase version of the current input character (subtract 0x0020 from the character's codepoint) to the current DOCTYPE token's name. Stay in the DOCTYPE name state.
EOF: Parse error. Emit the current DOCTYPE token and an end-of-file token.
Anything else: Append the current input character to the current DOCTYPE token's name. Stay in the DOCTYPE name state.

If the name of the DOCTYPE token is exactly the four letters "HTML", then mark the token as being correct. Otherwise, mark it as being in error.

After DOCTYPE name state

Consume the next input character:

U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+0020 SPACE: Stay in the after DOCTYPE name state.
U+003E GREATER-THAN SIGN (>): Emit the current DOCTYPE token. Switch to the data state.
EOF: Parse error. Emit the current DOCTYPE token and an end-of-file token.
Anything else: Parse error. Mark the DOCTYPE token as being in error, if it is not already. Switch to the bogus DOCTYPE state.

Bogus DOCTYPE state

Consume the next input character:

U+003E GREATER-THAN SIGN (>): Emit the current DOCTYPE token. Switch to the data state.
EOF: Parse error. Emit the current DOCTYPE token and an end-of-file token.
Anything else: Stay in the bogus DOCTYPE state.

8.2.1.1. Tokenising entities

This section defines how to consume an entity. This definition is used when parsing entities in text and in attributes.

The behaviour depends on the identity of the next character (the one immediately after the U+0026 AMPERSAND character):

U+0023 NUMBER SIGN (#)

Consume the U+0023 NUMBER SIGN.

The behaviour further depends on the character after the U+0023 NUMBER SIGN:

U+0078 LATIN SMALL LETTER X

U+0058 LATIN CAPITAL LETTER X

Consume the X.

Follow the steps below, but using the range of characters U+0030 DIGIT ZERO through to U+0039 DIGIT NINE, U+0061 LATIN SMALL LETTER A through to U+007A LATIN SMALL LETTER Z, and U+0041 LATIN CAPITAL LETTER A, through to U+005A LATIN CAPITAL LETTER Z (in other words, 0-9, A-Z, a-z).

When it comes to interpreting the number, interpret it as a hexadecimal number.

Anything else

Follow the steps below, but using the range of characters U+0030 DIGIT ZERO through to U+0039 DIGIT NINE (i.e. just 0-9).

When it comes to interpreting the number, interpret it as a decimal number.

Consume as many characters as match the range of characters given above.

If no characters match the range, then don't consume any characters (and unconsume the U+0023 NUMBER SIGN character and, if appropriate, the X character). This is a parse error; nothing is returned.

Otherwise, if the next character is a U+003B SEMICOLON, consume that too. If it isn't, there is a parse error.

If one or more characters match the range, then take them all and interpret the string of characters as a number (either hexadecimal or decimal as appropriate), and return a character token for the Unicode character whose codepoint is that number. If the number is not a valid Unicode character (e.g. if the number is higher than 1114111), or if the number is zero, then return a character token for the U+FFFD REPLACEMENT CHARACTER character instead.

Anything else

Consume the maximum number of characters possible, with the consumed characters case-sensitively matching one of the identifiers in the first column of the entities table.

If no match can be made, then this is a parse error. No characters are consumed, and nothing is returned.

Otherwise, if the next character is a U+003B SEMICOLON, consume that too. If it isn't, there is a parse error.

Return a character token for the character corresponding to the entity name (as given by the second column of the entities table).

If, just as an end-of-file token is about to be emitted, new characters are found in the input stream, the end-of-file token must be not actually be emitted, and instead, the tokensiser must continue with those new characters. (This can happen if an EOF input character caused both an end tag and the end-of-file token to be emitted, if the element that was closed was a script element.)

When an end tag or end-of-file token is emitted, the content model flag must be switched to the PCDATA state.

When an end tag token is emitted with attributes, that is a parse error.

8.2.2. Tree construction

The input to the tree construction stage is a sequence of tokens from the tokenisation stage. The tree construction stage must create a DOM Document object immediately upon being invoked. This is the only formal "output" of this stage; most of the real "output" consists of dynamically modifying or extending that document's DOM tree.

The Document object must initially have null doctype and documentElement attributes, and its other attributes must be set such that the implementation is in conformance with DOM3 Core. [DOM3CORE]

Tree construction passes through several phases. Initially, UAs must act according to the steps described as being those of the initial phase.

This specification does not define when an interactive user agent has to render the Document available to the user, or when it has to begin accepting user input.

When the steps below require the UA to append a character to a node, the UA must collect it and all subsequent consecutive characters that would be appended to that node, and insert one Text node whose data is the concatenation of all those characters.

Not all of the tag names mentioned below are conformant tag names in this specification; many are included to handle legacy content. They still form part of the algorithm that implementations are required to implement to claim conformance.

The algorithm described below places no limit on the depth of the DOM tree generated, or on the length of tag names, attribute names, attribute values, text nodes, etc. While implementators are encouraged to avoid arbitrary limits, it is recognised that practical concerns will likely force user agents to impose nesting depths.

8.2.2.1. The initial phase

Initially, the tree construction phase must handle each token emitted from the tokenisation stage as follows:

A DOCTYPE token that is marked as being in error

A comment token

A start tag token

An end tag token

A character token that is not one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE

An end-of-file token

This specification does not define how to handle this case. In particular, user agents may ignore the entirety of this specification altogether for such documents, and instead invoke special parse modes with a greater emphasis on backwards compatibility.

Browsers in particular have generally used DOCTYPE-based sniffing to invoke an "alternative conformance mode" known as quirks mode on certain documents. In this mode, emphasis is put on legacy compatibility rather than on standards compliance. This specification takes no position on this behaviour; documents without DOCTYPEs or with DOCTYPEs that do not conform to the syntax allowed by this specification are considered to be out of scope of this specification.

As far as parsing goes, the quirks I know of are:

Comment parsing is different.

The following is considered one script block (!):

<script><!-- document.write('</script>'); --></script>

</br> and </p> do magical things.
p can contain table
Safari and IE have special parsing rules for <% ... %> (even in standards mode, though clearly this should be quirks-only).

Maybe we should just adopt all those and be done with it. One parsing mode to rule them all. Or legitimise/codify the quirks mode parsing in some way.

Would be interesting to do a search to see how many pages hit each of the above.

A DOCTYPE token marked as being correct

Append a DocumentType node to the Document node, with the name attribute set to the name given in the DOCTYPE token (which will be "HTML"), and the other attributes specific to DocumentType objects set to null, empty lists, or the empty string as appropriate.

Then, switch to the root element phase of the tree construction stage.

A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE

Append that character to the Document node.

8.2.2.2. The root element phase

After the initial phase, as each token is emitted from the tokenisation stage, it must be processed as described in this section.

A DOCTYPE token: Parse error. Ignore the token.
A comment token: Append a Comment node to the Document object with the data attribute set to the data given in the comment token.
A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE: Append that character to the Document node.
A character token that is not one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE
A start tag token
An end tag token
An end-of-file token: Create an HTMLElement node with the tag name html, in the HTML namespace. Append it to the Document object. Switch to the main phase and reprocess the current token.

The root element can end up being removed from the Document object, e.g. by scripts; nothing in particular happens in such cases, content continues being appended to the nodes as described in the next section.

8.2.2.3. The main phase

After the root element phase, each token emitted from the tokenisation stage must be processed as described in this section. This is by far the most involved part of parsing an HTML document.

The tree construction stage in this phase has several pieces of state: a stack of open elements, a list of active formatting elements, a head element pointer, a form element pointer, and an insertion mode.

8.2.2.3.1. The stack of open elements

Initially the stack of open elements contains just the html root element node created in the last phase before switching to this phase. That's the topmost node of the stack. It never gets popped off the stack. (This stack grows downwards.)

The current node is the bottommost node in this stack.

Elements in the stack fall into the following categories:

Special: The following HTML elements have varying levels of special parsing rules: address, area, base, basefont, bgsound, blockquote, body, br, center, col, colgroup, dd, dir, div, dl, dt, embed, fieldset, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, hr, iframe, image, img, input, isindex, li, link, listing, menu, meta, noembed, noframes, noframes, noscript, ol, optgroup, option, p, param, plaintext, pre, script, select, spacer, style, tbody, textarea, tfoot, thead, title, tr, and ul.
Scoping: The following HTML elements introduce new scopes for various parts of the parsing: button, caption, html, marquee, object, table, td and th.
Formatting: The following HTML elements are those that end up in the list of active formatting elements: a, b, big, em, font, i, nobr, s, small, strike, strong, tt, u, and wbr.
Phrasing: All other elements found while parsing an HTML document.

Still need to add these new elements to the lists: event-source, section, nav, article, aside, header, footer, datagrid, command

The stack of open elements is said to have an element in scope or have an element in table scope when the following algorithm terminates in a match state:

Initialise node to be the current node (the bottommost node of the stack).
If node is the target node, terminate in a match state.
Otherwise, if node is a table element, terminate in a failure state.
Otherwise, if the algorithm is the "has an element in scope" variant (rather than the "has an element in table scope" variant), and node is one of the following, terminate in a failure state:
- caption
- td
- th
- button
- marquee
- object
Otherwise, if node is an html element, terminate in a failure state. (This can only happen if the node is the topmost node of the stack of open elements, and prevents the next step from being invoked if there are no more elements in the stack.)
Otherwise, set node to the previous entry in the stack of open elements and return to step 2. (This will never fail, since the loop will always terminate in the previous step if the top of the stack is reached.)

Nothing happens if at any time any of the elements in the stack of open elements is moved to a new location in, or removed from, the Document tree. In particular, the stack is not changed in this situation. This can cause, amongst other strange effects, content to be appended to nodes that are no longer in the DOM.

In some cases (namely, when closing misnested formatting elements), the stack is manipulated in a random-access fashion.

8.2.2.3.2. The list of active formatting elements

Initially the list of active formatting elements is empty. It is used to handle mis-nested formatting element tags.

The list contains elements in the formatting category, and scope markers. The scope markers are inserted when entering buttons, object elements, marquees, table cells, and table captions, and are used to prevent formatting from "leaking" into tables, buttons, object elements, and marquees.

When the steps below require the UA to reconstruct the active formatting elements, the UA must perform the following steps:

If the last (most recently added) entry in the list of active formatting elements is a marker, or if it is an element that is in the stack of open elements, then there is nothing to reconstruct; stop this algorithm.
Let entry be the last (most recently added) element in the list of active formatting elements.
Let entry be the entry one earlier than entry in the list of active formatting elements.
If entry is neither a marker nor an element that is also in the stack of open elements, go to step 3.
Let entry be the element one later than entry in the list of active formatting elements.
Perform a shallow clone of the element entry to obtain clone. [DOM3CORE]
Append clone to the current node and push it onto the stack of open elements so that it is the new current node.
Replace the entry for entry in the list with an entry for clone.
If the entry for clone in the list of active formatting elements is not the last entry in the list, return to step 5.

This has the effect of reopening all the formatting elements that were opened in the current body, cell, or caption (whichever is youngest) that haven't been explicitly closed.

The way this specification is written, the list of active formatting elements always consists of elements in chronological order with the least recently added element first and the most recently added element last (except for while steps 5 to 9 of the above algorithm are being executed, of course).

When the steps below require the UA to clear the list of active formatting elements up to the last marker, the UA must perform the following steps:

Let entry be the last (most recently added) entry in the list of active formatting elements.
Remove entry from the list of active formatting elements.
If entry was a marker, then stop the algorithm at this point. The list has been cleared up to the last marker.
Go to step 1.

8.2.2.3.3. Inserting HTML elements

When the steps below require the UA to insert an HTML element for a token, the UA must create a node implementing the interface appropriate for that element type (as given in the section of this specification that defines that element, e.g. for an a element it would be the HTMLAnchorElement interface), with the tag name being the name of that element, with the node being in the HTML namespace, and with the attributes on the node being those given in the given token. The UA must then append this node to the current node, and push it onto the stack of open elements so that it is the new current node.

The steps below may also require that the UA insert an HTML element in a particular place, in which case all the steps described in the previous paragraph must be followed with the exception that instead of appending the new node to the current node, the UA must insert or append the new node in the location specified. (This happens in particular during the parsing of tables with invalid content.)

The interface appropriate for an element that is not defined in this specification is HTMLElement.

8.2.2.3.4. Closing elements that have implied end tags

When the steps below require the UA to generate implied end tags, then, if the current node is a dd element, a dt element, an li element, a p element, a td element, a th element, or a tr element, the UA must act as if an end tag with the respective tag name had been seen and then generate implied end tags again.

The step that requires the UA to generate implied end tags but lists an element to exclude from the process, then the UA must perform the above steps as if that element was not in the list.

8.2.2.3.5. The element pointers

Initially the head element pointer and the form element pointer are both null.

Once a head element has been parsed (whether implicitly or explicitly) the head element pointer gets set to point to this node.

The form element pointer points to the last form element that was opened and whose end tag has not yet been seen. It is used to make form controls associate with forms in the face of dramatically bad markup, for historical reasons.

8.2.2.3.6. The insertion mode

Initially the insertion mode is "before head". It can change to "in head", "after head", "in body", "in table", "in caption", "in column group", "in table body", "in row", "in cell", "in select", "after body", "in frameset", and "after frameset" during the course of the parsing, as described below. It affects how certain tokens are processed.

If the tree construction stage is switched from the main phase to the trailing end phase and back again, the various pieces of state are not reset; the UA must act as if the state was maintained.

When the steps below require the UA to reset the insertion mode appropriately, it means the UA must follow these steps:

If the stack of open elements has a td or th element in table scope, then switch the insertion mode to "in cell".
Otherwise, if the stack of open elements has a tr element in table scope, then switch the insertion mode to "in row".
Otherwise, if the stack of open elements has a tbody, tfoot, or thead element in table scope, then switch the insertion mode to "in table body".
Otherwise, if the stack of open elements has a caption element in table scope, then switch the insertion mode to "in caption".
Otherwise, if the stack of open elements has a table element in table scope, then switch the insertion mode to "in table".
Otherwise, switch the insertion mode to "in body".

8.2.2.3.7. How to handle tokens in the main phase

Tokens in the main phase must be handled as follows:

A DOCTYPE token

Parse error. Ignore the token.

A start tag token with the tag name "html"

If this start tag token was not the first start tag token, then it is a parse error.

For each attribute on the token, check to see if the attribute is already present on the top element of the stack of open elements. If it is not, add the attribute and its corresponding value to that element.

Anything else

Depends on the insertion mode:

If the insertion mode is "before head"

Handle the token as follows:

A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE

A comment token

Append a Comment node to the current node with the data attribute set to the data given in the comment token.

A start tag token with the tag name "head"

Create a new HTMLHeadElement node with the tag name "head", in the HTML namespace, with the same attributes as on the token.

Set the head element pointer to this new element node.

Append the new element to the current node and push it onto the stack of open elements.

Change the insertion mode to "in head".

A start tag token whose tag name is one of: "base", "link", "meta", "script", "style", "title"

Act as if a start tag token with the tag name "head" and no attributes had been seen, then reprocess the current token.

This will result in a head element being generated, and with the current token being reprocessed in the "in head" insertion mode.

An end tag with the tag name "html"

Switch to the trailing end phase.

Any other end tag

Parse error. Ignore the token.

Anything else

Act as if a start tag token with the tag name "head" and no attributes had been seen, then reprocess the current token.

This will result in an empty head element being generated, with the current token being reprocessed in the "after head" insertion mode.

If the insertion mode is "in head"

Handle the token as follows.

The rules for handling "title", "style", and "script" start tags are similar, but not identical.

A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE

A comment token

Append a Comment node to the current node with the data attribute set to the data given in the comment token.

A start tag with the tag name "title"

Create a new HTMLElement node with the tag name "title", in the HTML namespace, with the same attributes as on the token.

Append the new element to the node pointed to by the head element pointer.

Switch the tokeniser's content model flag to the RCDATA state.

Then, collect all the characters tokens that the tokeniser returns until it returns a token that is not a character token.

If this process resulted in a collection of character tokens, append a single Text node to the title element node whose contents is the concatenation of all those tokens' characters.

The tokeniser's content model flag will have switched back to the PCDATA state.

If the next token is an end tag token with the tag name "title", ignore it.

A start tag with the tag name "style"

Create a new HTMLStyleElement node with the tag name "style", in the HTML namespace, with the same attributes as on the token.

Append the new element to the node pointed to by the head element pointer.

Switch the tokeniser's content model flag to the CDATA state.

Then, collect all the characters tokens that the tokeniser returns until it returns a token that is not a character token, or until it stops tokenising.

If this process resulted in a collection of character tokens, append a single Text node to the style element node whose contents is the concatenation of all those tokens' characters.

The tokeniser's content model flag will have switched back to the PCDATA state.

If the next token is an end tag token with the tag name "style", ignore it.

A start tag with the tag name "script"

Create a new HTMLScriptElement node with the tag name "script", in the HTML namespace, with the same attributes as on the token.

Switch the tokeniser's content model flag to the CDATA state.

Then, collect all the characters tokens that the tokeniser returns until it returns a token that is not a character token, or until it stops tokenising.

If this process resulted in a collection of character tokens, append a single Text node to the script element node whose contents is the concatenation of all those tokens' characters.

The tokeniser's content model flag will have switched back to the PCDATA state.

If the next token is not an end tag token with the tag name "script", then mark the script element as "already executed", otherwise, ignore it. (Marking the script element as "already executed" prevents it from executing when it is inserted into the document in the next paragraph.)

Append the new element to the current node, unless the insertion mode is "in head", in which case append it to the node pointed to by the head element pointer. This might cause some script to execute, and might cause new characters to be inserted into the tokeniser.

A start tag with the tag name "base", "link", or "meta"

Create a new HTMLBaseElement, HTMLLinkElement, or HTMLMetaElement node (respectively) with the tag name "base", "link", or "meta" (respectively), in the HTML namespace, with the same attributes as on the token.

Append the new element to the node pointed to by the head element pointer.

Need to cope with second and subsequent base elements affecting subsequent elements magically.

An end tag with the tag name "head"

If the current node is a head element, pop the current node off the stack of open elements. Otherwise, this is a parse error.

Change the insertion mode to "after head".

An end tag with the tag name "html"

Act as described in the "anything else" entry below.

A start tag with the tag name "head"

Any other end tag

Parse error. Ignore the token.

Anything else

If the current node is a head element, act as if an end tag token with the tag name "head" had been seen.

Otherwise, change the insertion mode to "after head".

Then, reprocess the current token.

If the insertion mode is "after head"

Handle the token as follows:

A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE

A comment token

Append a Comment node to the current node with the data attribute set to the data given in the comment token.

A start tag token with the tag name "body"

Insert a body element for the token.

Change the insertion mode to "in body".

A start tag token with the tag name "frameset"

Insert a frameset element for the token.

Change the insertion mode to "in frameset".

A start tag token whose tag name is one of: "base", "link", "meta", "script", "style", "title"

Parse error. Switch the insertion mode back to "in head" and reprocess the token.

Anything else

Act as if a start tag token with the tag name "body" and no attributes had been seen, and then reprocess the current token.

If the insertion mode is "in body"

Handle the token as follows:

A character token

Reconstruct the active formatting elements, if any.

Append the token's character to the current node.

A comment token

Append a Comment node to the current node with the data attribute set to the data given in the comment token.

A start tag token whose tag name is "script"

Process the token as if the insertion mode had been "in head".

A start tag token whose tag name is one of: "base", "link", "meta", "style", "title"

Parse error. Process the token as if the insertion mode had been "in head".

A start tag token whose tag name is one of: "head", "frameset", "frame"

Parse error. Ignore the token.

A start tag token with the tag name "body"

For each attribute on the token, check to see if the attribute is already present on the body element (the second element) on the stack of open elements. If it is not, add the attribute and its corresponding value to that element.

An end tag with the tag name "body"

Change the insertion mode to "after body".

An end-of-file token

Act as if an end tag with tag name "body" had been seen, then reprocess the end-of-file token.

A start tag whose tag name is one of: "address", "blockquote", "center", "dir", "div", "dl", "fieldset", "h1", "h2", "h3", "h4", "h5", "h6", "listing", "menu", "ol", "p", "pre", "ul"

Need to make <hx> close open Hx elements

If the stack of open elements has a p element in scope, then act as if an end tag with the tag name p had been seen.

Insert an HTML element for the token.

A start tag whose tag name is "form"

If the form element pointer is not null, ignore the token with a parse error.

Otherwise:

If the stack of open elements has a p element in scope, then act as if an end tag with the tag name p had been seen.

Insert an HTML element for the token, and set the form element pointer to point to the element created.

A start tag whose tag name is "li"

If the stack of open elements has a p element in scope, then act as if an end tag with the tag name p had been seen.

Run the following algorithm:

Initialise node to be the current node (the bottommost node of the stack).
If node is an li element, then pop all the nodes from the current node up to node, including node, then stop this algorithm.
If node is not in the formatting category, and is not in the phrasing category, and is not an address or div element, then stop this algorithm.
Otherwise, set node to the previous entry in the stack of open elements and return to step 2.

Finally, insert an li element.

A start tag whose tag name is "dd" or "dt"

If the stack of open elements has a p element in scope, then act as if an end tag with the tag name p had been seen.

Run the following algorithm:

Initialise node to be the current node (the bottommost node of the stack).
If node is a dd or dt element, then pop all the nodes from the current node up to node, including node, then stop this algorithm.
If node is not in the formatting category, and is not in the phrasing category, and is not an address or div element, then stop this algorithm.
Otherwise, set node to the previous entry in the stack of open elements and return to step 2.

Finally, insert an HTML element with the same tag name as the token's.

A start tag token whose tag name is "plaintext"

If the stack of open elements has a p element in scope, then act as if an end tag with the tag name p had been seen.

Insert an HTML element for the token.

Switch the content model flag to the PLAINTEXT state.

Once a start tag with the tag name "plaintext" has been seen, that will be the last token ever seen other than character tokens (and the EOF token), there is no way to switch the content model flag out of the PLAINTEXT state.

An end tag whose tag name is one of: "address", "blockquote", "center", "dir", "div", "dl", "fieldset", "listing", "menu", "ol", "pre", "ul"

If the stack of open elements has an element in scope with the same tag name as that of the token, then generate implied end tags.

Now, if the current node is not an element with the same tag name as that of the token, then this is a parse error.

If the stack of open elements has an element in scope with the same tag name as that of the token, then pop elements from this stack until an element with that tag name has been popped from the stack.

An end tag whose tag name is "form"

If the stack of open elements has an element in scope with the same tag name as that of the token, then generate implied end tags.

Now, if the current node is not an element with the same tag name as that of the token, then this is a parse error.

In any case, set the form element pointer to null.

An end tag whose tag name is "p"

If the stack of open elements has a p element in scope, then generate implied end tags, except for p elements.

If the current node is not a p element, then this is a parse error.

If the stack of open elements has a p element in scope, then pop elements from this stack until the stack no longer has a p element in scope.

An end tag whose tag name is "dd", "dt", or "li"

If the stack of open elements has an element in scope whose tag name matches the tag name of the token, then generate implied end tags, except for elements with the same tag name as the token.

If the current node is not an element with the same tag name as the token, then this is a parse error.

If the stack of open elements has an element in scope whose tag name matches the tag name of the token, then pop elements from this stack until an element with that tag name has been popped from the stack.

An end tag whose tag name is one of: "h1", "h2", "h3", "h4", "h5", "h6"

If the stack of open elements has in scope an element whose tag name is one of "h1", "h2", "h3", "h4", "h5", or "h6", then generate implied end tags.

Now, if the current node is not an element with the same tag name as that of the token, then this is a parse error.

If the stack of open elements has in scope an element whose tag name is one of "h1", "h2", "h3", "h4", "h5", or "h6", then pop elements from the stack until an element with one of those tag names has been popped from the stack.

A start tag whose tag name is one of: "a", "b", "big", "em", "font", "i", "nobr", "s", "small", "strike", "strong", "tt", "u", "wbr"

Need to make <a> close open A elements

Reconstruct the active formatting elements, if any.

Insert an HTML element for the token. Add that element to the list of active formatting elements.

An end tag whose tag name is one of: "a", "b", "big", "em", "font", "i", "nobr", "s", "small", "strike", "strong", "tt", "u", "wbr"

Follow these steps:

Let the formatting element be the bottommost node in the stack of open elements that is in scope and whose tag name matches the tag name of the end tag token. There might not be one. If there isn't, then it is a parse error; skip the subsequent steps (the end tag is ignored).

If the formatting element is not the current node, then it is a parse error.
Let the common ancestor be the element immediately above the formatting element in the stack of open elements.
Let the nearest block be the bottommost node in the stack of open elements that is lower in the stack than the formatting element, and is not an element in the phrasing or formatting categories.

There might not be one; if there isn't, then the UA must skip the subsequent steps and instead just pop all the nodes from the bottom of the stack of open elements, from the current node up to the formatting element, and remove the formatting element from the list of active formatting elements.
Let the furthest block be the topmost node in the stack of open elements that is lower in the stack than the formatting element, and is not an element in the phrasing or formatting categories. There will always be one (otherwise the UA would have bailed at the last step), but it might be the same as the nearest block.
If the furthest block has a parent node, then remove the furthest block from its parent node.
Let a bookmark note the relative position of the formatting element in the list of active formatting elements.
Let node and last node be the furthest block. Follow these steps:
1. Let node be the element immediately prior to node in the stack of open elements.
2. If node is the formatting element, then go to the next step in the overall algorithm. Otherwise:
3. If last node is the furthest block, then move the aforementioned bookmark to be immediately after the node in the list of active formatting elements.
4. If node has any children, perform a shallow clone of node, replace the entry for node in the list of active formatting elements with an entry for the clone, replace the entry for node in the stack of open elements with an entry for the clone, and let node be the clone.
5. Insert last node into node.
6. Let last node be node.
7. Return to step 1 of this inner set of steps.
If the furthest block had a parent node in step 5, insert whatever last node ended up being in the previous step into the common ancestor node.
Perform a shallow clone of the formatting element.
Take all of the child nodes of the furthest block and append them to the clone created in the last step.
Append that clone to the furthest block.
Remove the formatting element from the list of active formatting elements, and insert the clone into the list of active formatting elements at the position of the aforementioned bookmark.
Remove the formatting element from the stack of open elements, and insert the clone into the stack of open elements immediately after (i.e. in a more deeply nested position than) the position of the furthest block in that stack.
Jump back to step 1 in this series of steps.

The way these steps are defined, only elements in the formatting category ever get cloned by this algorithm.

Because of the way this algorithm causes elements to change parents, it has been dubbed the "adoption agency algorithm" (in contrast with other possibly algorithms for dealing with misnested content, which included the "incest algorithm", the "secret affair algorithm", and the "Heisenberg algorithm").

A start tag token whose tag name is "button"

If the stack of open elements has a button element in scope, then this is a parse error; act as if an end tag with the tag name "button" had been seen, then reprocess the token.

Otherwise:

Reconstruct the active formatting elements, if any.

Insert an HTML element for the token.

Insert a marker at the end of the list of active formatting elements.

A start tag token whose tag name is one of: "marquee", "object"

Reconstruct the active formatting elements, if any.

Insert an HTML element for the token.

Insert a marker at the end of the list of active formatting elements.

An end tag token whose tag name is one of: "button", "marquee", "object"

If the stack of open elements has in scope an element whose tag name is the same as the tag name of the token, then generate implied end tags.

Now, if the current node is not an element with the same tag name as the token, then this is a parse error.

Now, if the stack of open elements has an element in scope whose tag name matches the tag name of the token, then pop elements from the stack until that element has been popped from the stack, and clear the list of active formatting elements up to the last marker.

A start tag token whose tag name is "xmp"

Reconstruct the active formatting elements, if any.

Insert an HTML element for the token.

Switch the content model flag to the CDATA state.

A start tag whose tag name is "table"

If the stack of open elements has a p element in scope, then act as if an end tag with the tag name p had been seen.

Insert an HTML element for the token.

Change the insertion mode to "in table".

A start tag whose tag name is one of: "area", "basefont", "bgsound", "br", "embed", "img", "param", "spacer"

Reconstruct the active formatting elements, if any.

Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.

A start tag whose tag name is "hr"

If the stack of open elements has a p element in scope, then act as if an end tag with the tag name p had been seen.

Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.

A start tag whose tag name is "image"

Parse error. Change the token's tag name to "img" and reprocess it. (Don't ask.)

A start tag whose tag name is "input"

Reconstruct the active formatting elements, if any.

Insert an input element for the token.

If the form element pointer is not null, then associate the input element with the form element pointed to by the form element pointer.

Pop that input element off the stack of open elements.

A start tag whose tag name is "isindex"

If the form element pointer is not null, then ignore the token.

Otherwise:

Act as if a start tag token with the tag name "form" had been seen.

Act as if a start tag token with the tag name "hr" had been seen.

Act as if a start tag token with the tag name "p" had been seen.

Act as if a start tag token with the tag name "label" had been seen.

Act as if a stream of character tokens had been seen (see below for what they should say).

Act as if a start tag token with the tag name "input" had been seen, with all the attributes from the "isindex" token, except with the "name" attribute set to the value "isindex" (ignoring any explicit "name" attribute).

Act as if a stream of character tokens had been seen (see below for what they should say).

Act as if an end tag token with the tag name "label" had been seen.

Act as if an end tag token with the tag name "p" had been seen.

Act as if a start tag token with the tag name "hr" had been seen.

Act as if an end tag token with the tag name "form" had been seen.

The two streams of character tokens together should, together with the input element, express the equivalent of "This is a searchable index. Insert your search keywords here: (input field)" in the user's preferred language.

Then need to specify that if the form submission causes just a single form control, whose name is "isindex", to be submitted, then we submit just the value part, not the "isindex=" part.

A start tag whose tag name is "textarea"

Create a new HTMLTextareaElement node with the tag name "textarea", in the HTML namespace, with the same attributes as on the token.

If the form element pointer is not null, then associate the textarea element with the form element pointed to by the form element pointer.

Append the new element to the current node.

Switch the tokeniser's content model flag to the RCDATA state.

Then, collect all the characters tokens that the tokeniser returns until it returns a token that is not a character token, or until it stops tokenising.

If this process resulted in a collection of character tokens, append a single Text node, whose contents is the concatenation of all those tokens' characters, to the new element node.

The tokeniser's content model flag will have switched back to the PCDATA state.

If the next token is an end tag token with the tag name "textarea", ignore it.

A start tag whose tag name is one of: "iframe", "noembed", "noframes", "noscript"

Create a new node with the tag name given in the token, in the HTML namespace, with the same attributes as on the token.

For "iframe" tags, the node must be an HTMLIFrameElement object, for the other tags it must be an HTMLElement object.

Append the new element to the current node.

Switch the tokeniser's content model flag to the CDATA state.

Then, collect all the characters tokens that the tokeniser returns until it returns a token that is not a character token, or until it stops tokenising.

If this process resulted in a collection of character tokens, append a single Text node, whose contents is the concatenation of all those tokens' characters, to the new element node.

The tokeniser's content model flag will have switched back to the PCDATA state.

If the next token is an end tag token with the same tag name as the start tag token, ignore it.

Need something here for when scripting is disabled.

A start tag whose tag name is "select"

Reconstruct the active formatting elements, if any.

Insert an HTML element for the token.

Change the insertion mode to "in select".

A start or end tag whose tag name is one of: "caption", "col", "colgroup", "tbody", "td", "tfoot", "th", "thead", "tr"

An end tag whose tag name is one of: "area", "basefont", "bgsound", "br", "embed", "hr", "iframe", "image", "img", "input", "isindex", "noembed", "noframes", "noscript", "param", "spacer", "table", "textarea"

Parse error. Ignore the token.

A start or end tag whose tag name is one of: "event-source", "section", "nav", "article", "aside", "header", "footer", "datagrid", "command"

Work in progress!

A start tag token not covered by the previous entries

Reconstruct the active formatting elements, if any.

Insert an HTML element for the token.

This element will be a phrasing element.

An end tag token not covered by the previous entries

Run the following algorithm:

Initialise node to be the current node (the bottommost node of the stack).
If node has the same tag name as the end tag token, then:
1. Generate implied end tags.
2. If the tag name of the end tag token does not match the tag name of the current node, this is a parse error.
3. Pop all the nodes from the current node up to node, including node, then stop this algorithm.
Otherwise, if node is in neither the formatting category nor the phrasing category, then this is a parse error. Stop this algorithm. The end tag token is ignored.
Set node to the previous entry in the stack of open elements.
Return to step 2.

If the insertion mode is "in table"

A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE

Generate implied end tags.

A comment token

Append a Comment node to the current node with the data attribute set to the data given in the comment token.

A start tag whose tag name is "caption"

Clear the stack back to a table context. (See below.)

Insert a marker at the end of the list of active formatting elements.

Insert an HTML element for the token, then switch the insertion mode to "in caption".

A start tag whose tag name is "colgroup"

Clear the stack back to a table context. (See below.)

Insert an HTML element for the token, then switch the insertion mode to "in column group".

A start tag whose tag name is "col"

Act as if a start tag token with the tag name "colgroup" had been seen, then reprocess the current token.

A start tag whose tag name is one of: "tbody", "tfoot", "thead"

Clear the stack back to a table context. (See below.)

Insert an HTML element for the token, then switch the insertion mode to "in table body".

A start tag whose tag name is one of: "td", "th", "tr"

Act as if a start tag token with the tag name "tbody" had been seen, then reprocess the current token.

A start tag whose tag name is "table"

Parse error. Act as if an end tag token with the tag name "table" had been seen, then reprocess the current token.

An end tag whose tag name is "table"

Now, if the current node is not a table element, then this is a parse error.

Pop elements from this stack until a table element has been popped from the stack.

Reset the insertion mode appropriately.

An end tag whose tag name is one of: "body", "caption", "col", "colgroup", "html", "tbody", "td", "tfoot", "th", "thead", "tr"

Parse error. Ignore the token.

An end-of-file token

Parse error. Act as if an end tag with tag name "table" had been seen, then reprocess the end-of-file token.

Anything else

Parse error. Process the token as if the insertion mode was "in body", with the following exception:

If the current node is a table, tbody, tfoot, thead, or tr element, then, whenever a node would be inserted into the current node, it must instead be inserted into the element that comes immediately before the last table element in the stack of open elements (the foster parent element). If the last table element in the stack of open elements is a child of this foster parent element, then the new node must be inserted immediately before the last table element in the stack of open elements in this foster parent element, otherwise, the new node must be appended to this foster parent element.

When the steps above require the UA to clear the stack back to a table context, it means that the UA must, while the current node is not a table element, pop elements from the stack of open elements. If this causes any elements to be popped from the stack, then this is a parse error.

If the insertion mode is "in caption"

An end tag whose tag name is "caption"

Generate implied end tags.

Now, if the current node is not a caption element, then this is a parse error.

Pop elements from this stack until a caption element has been popped from the stack.

Clear the list of active formatting elements up to the last marker.

Switch the insertion mode to "in table".

A start tag whose tag name is one of: "caption", "col", "colgroup", "tbody", "td", "tfoot", "th", "thead", "tr"

An end tag whose tag name is "table"

An end-of-file token

Parse error. Act as if an end tag with the tag name "caption" had been seen, then reprocess the current token.

An end tag whose tag name is one of: "body", "col", "colgroup", "html", "tbody", "td", "tfoot", "th", "thead", "tr"

Parse error. Ignore the token.

Anything else

Process the token as if the insertion mode was "in body".

If the insertion mode is "in column group"

A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE: Append the character to the current node.
A comment token: Append a Comment node to the current node with the data attribute set to the data given in the comment token.
A start tag whose tag name is "col": Insert a col element for the token. Immediately pop the current node off the stack of open elements.
An end tag whose tag name is "colgroup": Pop the current node (which will be a colgroup element) from the stack of open elements. Switch the insertion mode to "in table".
An end tag whose tag name is "col": Parse error. Ignore the token.
Anything else: Act as if an end tag with the tag name "colgroup" had been seen, and then reprocess the current token.

If the insertion mode is "in table body"

A start tag whose tag name is "tr"

Clear the stack back to a table body context. (See below.)

Insert a tr element for the token, then switch the insertion mode to "in row".

A start tag whose tag name is one of: "th", "td"

Parse error. Act as if a start tag with the tag name "tr" had been seen, then reprocess the current token.

An end tag whose tag name is one of: "tbody", "tfoot", "thead"

If the stack of open elements does not have an element in table scope with the same tag name as the token, this is a parse error. Ignore the token.

Otherwise:

Clear the stack back to a table body context. (See below.)

Pop the current node from the stack of open elements. Switch the insertion mode to "in table".

A start tag whose tag name is one of: "caption", "col", "colgroup", "tbody", "tfoot", "thead"

An end tag whose tag name is "table"

An end-of-file token

Clear the stack back to a table body context. (See below.)

Act as if an end tag with the same tag name as the current node ("tbody", "tfoot", or "thead") had been seen, then reprocess the current token.

An end tag whose tag name is one of: "body", "caption", "col", "colgroup", "html", "td", "th", "tr"

Parse error. Ignore the token.

Anything else

Process the token as if the insertion mode was "in table".

When the steps above require the UA to clear the stack back to a table body context, it means that the UA must, while the current node is not a tbody, tfoot, or thead element, pop elements from the stack of open elements. If this causes any elements to be popped from the stack, then this is a parse error.

If the insertion mode is "in row"

A start tag whose tag name is one of: "th", "td"

Clear the stack back to a table row context. (See below.)

Insert an HTML element for the token, then switch the insertion mode to "in cell".

Insert a marker at the end of the list of active formatting elements.

An end tag whose tag name is "tr"

Clear the stack back to a table row context. (See below.)

Pop the current node (which will be a tr element) from the stack of open elements. Switch the insertion mode to "in table body".

A start tag whose tag name is one of: "caption", "col", "colgroup", "tbody", "tfoot", "thead", "tr"

An end tag whose tag name is "table"

An end-of-file token

Act as if an end tag with the tag name "tr" had been seen, then reprocess the current token.

An end tag whose tag name is one of: "tbody", "tfoot", "thead"

If the stack of open elements does not have an element in table scope with the same tag name as the token, this is a parse error. Ignore the token.

Otherwise, act as if an end tag with the tag name "tr" had been seen, then reprocess the current token.

An end tag whose tag name is one of: "body", "caption", "col", "colgroup", "html", "td", "th", "tr"

Parse error. Ignore the token.

Anything else

Process the token as if the insertion mode was "in table".

When the steps above require the UA to clear the stack back to a table row context, it means that the UA must, while the current node is not a tr element, pop elements from the stack of open elements. If this causes any elements to be popped from the stack, then this is a parse error.

If the insertion mode is "in cell"

An end tag whose tag name is one of: "td", "th"

If the stack of open elements does not have an element in table scope with the same tag name as that of the token, then this is a parse error and the token must be ignored.

Otherwise:

Generate implied end tags, except for elements with the same tag name as the token.

Now, if the current node is not a an element with the same tag name as the token, then this is a parse error.

Pop elements from this stack until an element with the same tag name as the token has been popped from the stack.

Clear the list of active formatting elements up to the last marker.

Switch the insertion mode to "in row". (The current node will be a tr element at this point.)

A start tag whose tag name is one of: "caption", "col", "colgroup", "tbody", "td", "tfoot", "th", "thead", "tr"

Close the cell (see below) and reprocess the current token.

An end tag whose tag name is one of: "body", "col", "colgroup", "html"

Parse error. Ignore the token.

An end tag whose tag name is one of: "table", "tbody", "tfoot", "thead", "tr"

If the stack of open elements does not have an element in table scope with the same tag name as that of the token (which can only happen for "tbody", "tfoot" and "thead"), then this is a parse error and the token must be ignored.

Otherwise, close the cell (see below) and reprocess the current token.

An end-of-file token

Close the cell and reprocess the end-of-file token.

Anything else

Process the token as if the insertion mode was "in body".

Where the steps above say to close the cell, they mean to follow the following algorithm:

If the stack of open elements has a td element in table scope, then act as if an end tag token with the tag name "td" had been seen.
Otherwise, the stack of open elements will have a th element in table scope; act as if an end tag token with the tag name "th" had been seen.

The stack of open elements cannot have both a td and a th element in table scope at the same time, nor can it have neither when the insertion mode is "in cell".

If the insertion mode is "in select"

Handle the token as follows:

A character token

Append the token's character to the current node.

A comment token

Append a Comment node to the current node with the data attribute set to the data given in the comment token.

A start tag token whose tag name is "optgroup"

If the current node is an option element, act as if an end tag with the tag name "option" had been seen.

Insert an HTML element for the token.

An end tag token whose tag name is "optgroup"

First, if the current node is an option element, and the node immediately before it in the stack of open elements is an optgroup element, then act as if an end tag with the tag name "option" had been seen.

If the current node is an optgroup element, then pop that node from the stack of open elements. Otherwise, this is a parse error, ignore the token.

A start tag token whose tag name is "option"

If the current node is an option element, act as if an end tag with the tag name "option" had been seen, then reprocess the token.

Insert an HTML element for the token.

An end tag token whose tag name is "option"

If the current node is an option element, then pop that node from the stack of open elements. Otherwise, this is a parse error, ignore the token.

An end tag whose tag name is "select"

Pop elements from the stack of open elements until a select element has been popped from the stack.

Reset the insertion mode appropriately.

A start tag whose tag name is "select"

Parse error. Act as if the token had been an end tag with the tag name "select" instead.

An end tag whose tag name is one of: "caption", "table", "tbody", "tfoot", "thead", "tr", "td", "th"

If the stack of open elements has an element in table scope with the same tag name as that of the token, then act as if an end tag with the tag name "select" had been seen, and reprocess the token. Otherwise, ignore the token.

An end-of-file token

Parse error. Act as if an end tag token with the tag name "select" had been seen, then reprocess the current token.

Anything else

Parse error. Ignore the token.

If the insertion mode is "after body"

Handle the token as follows:

A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE: Append the character to the first element in the stack of open elements (the html element).
A comment token: Append a Comment node to the first element in the stack of open elements (the html element), with the data attribute set to the data given in the comment token.
An end tag with the tag name "html": Switch to the trailing end phase.
An end-of-file token: Act as if an end tag with tag name "html" had been seen, then reprocess the end-of-file token.
Anything else: Parse error. Set the insertion mode to "in body" and reprocess the token.

If the insertion mode is "in frameset"

Handle the token as follows:

A character token that is one of one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), or U+0020 SPACE

A comment token

Append a Comment node to the current node with the data attribute set to the data given in the comment token.

A start tag with the tag name "frameset"

Insert a frameset element for the token.

An end tag with the tag name "frameset"

Pop the current node from the stack of open elements. If the current node is no longer a frameset element, then change the insertion mode to "after frameset".

A start tag with the tag name "frame"

Create an HTMLFrameElement node in the HTML namespace with the tag name given in the token, and with the attributes given in the token, and append it to the current node.

A start tag with the tag name "noframes"

Process the token as if the insertion mode had been "in body".

An end-of-file token