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 (optional)

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 (optional)

rel (optional)

media (optional)

hreflang (optional)

type (optional)

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 (optional)

http-equiv (HTML only, optional)

content (optional)

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 (optional)

media (optional)

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 (optional)

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 (optional)

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 (optional)

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 (optional)

rel (optional)

media (optional)

hreflang (optional)

type (optional)

ping (optional)

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 (optional)
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 (optional); datetime (optional)
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 (optional); datetime (optional)
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