HTML 5 Publication Notes

Section 1.1, Background # T

This is is a newly titled section that was created during reorganization. It contents were previously in two unsectioned paragraphs directly following the opening title for the section.

Section 1.3, Relationships to other specifications # T

In this section, which describes the relationship of the HTML 5 specification to various other specifications, the following changes were made:

• Text describing the relationship to XHTML 1.x was moved to create a new “Relationship to XHTML 1.x” subsection, with the following content:

  This specification is intended to replace XHTML 1.0 as the normative definition of the XML serialisation of the HTML vocabulary. [XHTML10]

  While this specification updates the semantics and requirements of the vocabulary defined by XHTML Modularization 1.1 and used by XHTML 1.1, it does not attempt to provide a replacement for the modularization scheme defined and used by those (and other) specifications, and therefore cannot be considered a complete replacement for them. [XHTMLMOD] [XHTML11]

  Thus, authors and implementors who do not need such a modularization scheme can consider this specification a replacement for XHTML 1.x, but those who do need such a mechanism are encouraged to continue using the XHTML 1.1 line of specifications.

• A new “Relationship to Web Forms 2.0 and XForms” subsection was added, with the following content:

  This specification will eventually supplant Web Forms 2.0. The current Web Forms 2.0 draft can be considered part of this specification for the time being; its features will eventually be merged into this specification. [WF2]

  As it stands today, this specification is unrelated and orthogonal to XForms. When the forms features defined in HTML4 and Web Forms 2.0 are merged into this specification, then the relationship to XForms described in the Web Forms 2.0 draft will apply to this specification. [XForms]

Section 2.1, Conformance requirements # T

This section — which provides information about conformance requirements for Web browsers and user agents, conformance checkers, data mining tools, authoring tools, and markup generators — had been in the “Introduction” section in previous drafts, and was moved here during reorganization. In this section, the following changes were made:

• In the “Features defined in other specifications” subsection, the following statement was added: If the computed value of the ‘color’ property is undefined for a particular case (e.g. because the element is not in a document), then the “computed value of the ‘color’ property” for the purposes of determining the computed value of the currentColor keyword is fully opaque black.
• In the “Dependencies” subsection, the following statement was removed completely: However, when applying the rules of the Media Queries specification to media queries found in content attributes of HTML elements, user agents must act as if all U+000B LINE TABULATION characters in the attribute were in fact U+0020 SPACE characters. This is required to provide a consistent processing of space characters in HTML.

Section 2.2, Terminology # T

This section — which provides information about specific technical terms used in the specification — had been in the “Introduction” section in previous drafts, and was moved here during reorganization. In this section, the following changes were made:

• The following statement was added:

  Attribute names are said to be XML-compatible if they match the Name production defined in XML, they contain no U+003A COLON (:) characters, and they do not start with three characters “xml”.

Section 2.3 [NEW], Case-sensitivity # T

This newly added section defines, as they are used throughout the specification, the following terms (“comparison operators”):

• comparing two strings in a case-sensitive manner
• comparing two strings in a ASCII case-insensitive manner
• comparing two strings in a compatibility caseless manner
• converting a string to uppercase
• converting a string to lowercase

Also, sections throughout the specification were revised to make use of the above terms.

Section 2.4, URLs # T

In previous drafts, the “URLs” section was a placeholder within the “Semantics and structure of HTML elements” section, with an editorial note about what it would eventually contain; during reorganization, it was moved here and expanded and is now a fairly complete section whose purposes are to:

• define the following terms:
  • URL
  • valid URL
  • absolute URL
  • base URL
  • document base URL
  • input [URL]
  • common setter action [for URLs]
• specify URL parsing rules for user agents
• specify how user agents must resolve a URL (how to obtain an absolute URL by resolving a URL relative to a base URL)
• specify how users agents much behave when the base URL changes
• define interfaces for URL manipulation and related URL decomposition attributes

This section intentionally redefines the term “URL” in a way that is not completely consistent with how that term is used in other existing specifications -- and to make that more clear, the following note was added:

The term “URL” in this specification is used in a manner distinct from the precise technical meaning it is given in RFC 3986. Readers familiar with that RFC will find it easier to read this specification if they pretend the term "URL" as used herein is really called something else altogether.

The rationale for redefining the term “URL” — and for including the sections that specify URL parsing rules for user agents, how user agents must resolve URLs, and how user agents must behave when the base URL of a document changes — is provided in the "URLs" section introduction:

This specification defines the term URL, and defines various algorithms for dealing with URLs, because for historical reasons the rules defined by the URI and IRI specifications are not a complete description of what HTML user agents need to implement to be compatible with Web content.

Also note the throughout the draft, a number of instances of the terms “URI”, and “IRI” have now been replaced with the term “URL” or with statements about resolving a URL to obtain an absolute URL.

Section 2.5, Common microsyntaxes # T

This section — which describes the conformance criteria for instances of particular data types (such as dates or numbers) used in HTML content, as well as describing how to parse such instances — had been in the “Semantics and structure of HTML elements” section in previous drafts, and was moved here during reorganization.

Section 2.7 [NEW], Fetching resources # T

This section is newly added. It is a placeholder with an editorial note that reads:

replace all instances of the word ‘fetch’ or ‘download’ with a reference to this section, and put something here that talks about caching, that redirects to the offline storage stuff when appropriate, that defines that before fetching a URL you have to resolve the URL, so that every case of fetching doesn’t have to independently say to resolve the URL, etc; “once fetched, a resource might have to have its type determined”, pointing to the next section but also explicitly saying that it’s up to the part of the spec doing the fetching to determine how the type is established

Section 2.8, Determining the type of a resource # T

This newly titled section — which specifies content-sniffing behavior — was previously a subsection titled “Determining the type of a new resource in a browsing context” within the “Web browsers” section. It was moved here during reorganization. In addition, the following changes were made:

• Significant revisions were made to text of the algorithm in the “Content-Type sniffing: text or binary” subsection.
• Significant revisions and corrections were made to the algorithm in the “Content-Type sniffing: unknown type” subsection.

Section 3.2, Documents # T

This section — which defines the Document object — had been in the “The Document Object Model” section in previous drafts, and was moved here during reorganization. In this section, the following changes were made:

• In the “DOM tree accessors” subsection, text defining the behavior of the getElementsByClassName() method was revised to state the node list the method return returns must contain the matching elements in document order; also, the following statement was added:

  If the document is in quirks mode, then the comparisons for the classes must be done in an ASCII case-insensitive manner, otherwise, the comparisons must be done in a case-sensitive manner.

• In the “Resource metadata management” subsection, which deals in part with the cookie attribute, references to RFC 2109 were changed to refer to RFC 2109 “or later specifications”.

Section 3.3, Elements # T

This section — which defines the HTMLElement interface and global HTML content attributes and event-handler content attributes — had been in the “The Document Object Model” section in previous drafts, and was moved here during reorganization.

Section 3.6, APIs in HTML documents # T

This section — which provides details about case-insensitivity and case-changing behavior of data returned by certain DOM APIs — had been in the “The Document Object Model” section in previous drafts, and was moved here during reorganization.

Section 3.7, Dynamic markup insertion # T

This section — which defines mechanisms that enable script authors to dynamically insert markup into a document — had been in the “The Document Object Model” section in previous drafts, and was moved here during reorganization. In the section, the following changes were made:

• In the “Dynamic markup insertion in HTML” subsection, an instance of the phrase “script that will execute as soon as the parser resumes” was changed to pending external script.
• In the “Dynamic markup insertion in XML” subsection, a portion of the text was updated to now read, For the innerHTML attribute on HTMLElement objects, if any of the elements in the serialization are in no namespace, the default namespace in scope for those elements must be explicitly declared as the empty string. (This doesn’t apply to the innerHTML attribute on HTMLDocument objects.)

Section 4.2, Document metadata # T

This section defines the semantics and structure of the head element and those of its conformant descendant elements.

Section 4.3, Sections # T

This section defines the semantics and structure of the elements used for dividing documents into sections.

Section 4.9, Grouping content # T

This section concerns elements that are used to group phrasing content into logical structures such as paragraphs and lists.

Section 4.7, Embedded content # T

This section concerns elements used to embed non-text content in HTML pages, primarily binary media content (such as video and audio content, static images, images that are dynamically created through scripting), but also content in other markup languages (SVG and MathML).

Section 4.10, Scripting # T

This section concerns markup and DOM interfaces that authors use to make use of DOM scripting in Web content.

Section 4.11, Interactive elements # T

This section concerns the details, datagrid, command, bb, and menu elements.

Section 5.2, The default view # T

This section defines the interface for the Window object. In this section, the following changes were made:

• The following pair of statements were added:

  Each Document in a browsing context also has an associated list of message ports, which must be initially empty. The list is used during history traversal in much the same way as the list of added properties, to keep track of message ports that need to be reactivated if the Document is made the active document again.

• An interface definition for the WindowBrowsingContext interface was added (this addition effectively splits the previous definition for the Window interface into two parts: one for the Window interface, and one for the WindowBrowsingContext interface.
• The postMessage(message, messagePort, targetOrigin) form (“three argument” form) of the postMessage() method was added to the interface definition for the WindowBrowsingContext interface.
• In the “Security” subsection, text was refined to make it clear that both the postMessage(message, targetOrigin) form (“two argument” form) and postMessage(message, messagePort, targetOrigin) form (“three argument” form) of the postMessage() method are in the set of members of a Window object for which it is not a requirement that a security exception be raised when they are accessed by scripts whose effective script origin is not the same as the Window object’s browsing context’s active document’s effective script origin.
• In the “APIs for creating and navigating browsing contexts by name” subsection, an instance of the phrase “browsing context corresponding to the Window object that is the script execution context” was changed to script browsing context.
• A statement concerning the AbstractView object was updated to now read (added text highlighted): The AbstractView object of default views must also implement the Window, WindowBrowsingContext, and EventTarget interfaces.

Section 5.3, Origin # T

In this section, the following changes were made:

• A statement defining the origin of a resource and the effective script origin of a resource was updated to read (highlighted text added): The origin of a resource and the effective script origin of a resource are both either opaque identifiers or tuples consisting of a scheme component, a host component, a port component, and optionally extra data, and the following statement was added: The extra data could include the certificate of the site when using encrypted connections, to ensure that if the site’s secure certificate changes, the origin is considered to change as well.
• In the algorithm for determining the origin and effective script origin of a URL, the following statement was added: In addition, if the URL is in fact associated with a Document object that was created by parsing the resource obtained from fetching URL, and this was done over a secure connection, then the server’s secure certificate may be added to the origin as additional data.
• In the algorithm for identifying the owner of a script (by which, in turn, the origin and effective script origin are determined), the following case was added: If a script is in an event handler content attribute: The owner is the Document to which the attribute node belongs.
• In the algorithm for determining whether two origins are of the same origin, the following statement was added: If either A [the first origin to be compared] or B [the second origin to be compared] have additional data, but that data is not identical for both, return false.
• Text specifying the serialization of an origin was split into two algorithms, one algorithm for obtaining the Unicode serialization of an origin, and one algorithm for obtaining the ASCII serialization of an origin. Also, “The string representing the script’s domain in IDNA format” subsection was removed (after being made redundant by the revisions to the text specifying the serialization of an origin).

Section 5.4, Scripting # T

This section provides conformance criteria related to mechanisms that can cause author-provided executable code to run in the context of a document scripting, as well as defining the states scripting is enabled and scripting is disabled.

• The following statement was added: When a script is created, it is associated with a script execution context, a script browsing context, and a script document context.
• In the “Script execution contexts” subsection, a statement defining the script execution context was updated to read (added text highlighted): The script execution context of a script is defined when that script is created. It is typically either a Window object or an empty object.
• In the “Script execution contexts” subsection, the following changes were made:
  • The following statement was added: When the script execution context of a script is an empty object, it can’t do anything that interacts with the environment.
  • A related statement was updated to now read (added text highlighted): A script execution context always has an associated browsing context, known as the script browsing context.
  • The following statement was added: Every script whose script execution context is a Window object is also associated with a Document object, known as its script document context. It is used to resolve URLs. The document is assigned when the script is created, as with the script browsing context.
  • A pair of statements defining the script browsing context was updated to now read (changed text highlighted): A script execution context always has an associated browsing context, known as the script browsing context. If the script execution context is a WindowBrowsingContext object, then that object’s browsing context is it (the text had previously referred to the Window object).
• In the “The javascript: protocol” subsection, a statement related to navigating the browsing context to a javascript: protocol URL was updated to read (added text highlighted): When a browsing context is navigated to a javascript: URL, and the active document of that browsing context has the same origin as the script given by that URL, the script execution context must be the Window object of the browsing context being navigated, and the script document context must be that active document.
• In the “Event handler attributes” subsection, a paragraph was updated to read (added text highlighted): The script execution context of the event handler must be the Window object at the end of the scope chain. The script document context of the event handler must be the Document object that owns the event handler content attribute that was set.

Section 5.5, User prompts # T

This section provides conformance criteria related to dialogs presented to users. In this section, the following changes were made:

• In the “Dialogs implemented using separate documents” subsection, in a step in the algorithm that user agents must run when the showModalDialog() method is invoked, the phrase “browsing context of the Window object that is the script execution context” was replaced with the phrase script browsing context.

Section 5.6, Browser state # T

This section defines how Web sites can register themselves as potential protocol and content handlers; for example, how a Web-based mail application can register itself as a potential handler for the mailto: protocol.

In this section, the following changes were made:

• For consistency with the conformance requirements specified in the “URLs” section, in the list of arguments for the registerProtocolHandler() and registerContentHandler() methods, a number of revisions were made to the the text specifying the meaning of the url argument.

Section 5.8, Session history and navigation # T

This section defines the session history for a browsing context and its associated History interface. In this section, the following changes were made:

• In the “The History interface” subsection, for consistency with the conformance requirements specified in the “URLs” section, extensive revisions were made to the algorithm that user agents must run when the pushState() method is invoked.
• In the “The Location interface” subsection, an instance of the phrase “browsing context of the Window object that is the script execution context” was changed to script browsing context.

Section 5.9, Browsing the Web # T

This section specifies user agent behavior related to navigating across documents, page load processing, navigating to fragment identifiers, and history traversal. In this section, the following changes were made:

• In the “Navigating across documents” subsection, within the algorithm which specifies user-agent behavior when a browsing context is navigated to a new resource was revised, the “Resolve the URL of the new resource” step was revised to now read (changed text highlighted):

  Resolve the URL of the new resource. If that fails, the user agent may abort these steps, or may treat the URL as identifying some sort of user-agent defined error resource, which could display some sort of inline content, or could be handled using a mechanism that does not affect the browsing context.

• A number of other revisions were made to the algorithm which specifies user-agent behavior when a browsing context is navigated to a new resource.
• In the “History traversal” subsection, the following statements were added as steps in the history-traversal algorithm:

  If there are any MessagePort objects whose owner is the browsing context’s default view’s Window object and that are entangled with another port, the user agent must deactivate all such ports and let the Document’s list of message ports be a list of those ports.

  …

  If the active document’s list of message ports is not empty, then the user agent must reactivate all the ports in that list. Empty that list of message ports.

• A new “Closing a browsing context” subsection was added. It is currently a placeholder, with editorial notes about its intended purpose.

Section 5.10, Structured client-side storage # T

This section concerns new mechanisms in HTML5 for persistent client-side storage of data. In this section, the following changes were made:

• In a part of the “User tracking” subsection within the “Privacy” section, a reference to RFC 2109 was added to a paragraph related to cookies.

Section 5.11, Links # T

In this section, which concerns handling of hyperlinks, the following changes were made:

• In the “Link types” subsection, a paragraph related to the icon link type was revised to now read (added text highlighted): There is no default type for resources given by the icon keyword. However, for the purposes of determining the type of the resource, user agents must expect the resource to be an image.
• In the “Hyperlink auditing” subsection, a reference to RFC 2109 was added to a paragraph related to cookies.

Section 7.1, Event definitions # T

This section defines the MessageEvent interface. In this section, the following changes were made:

• The messagePort attribute was added to the interface definition for the MessageEvent interface.
• The following statements were added:

  The messagePort attribute represents, in cross-document messaging and channel messaging the MessagePort being sent, if any.

  Unless otherwise specified, when the user agent creates and dispatches a message event in the algorithms described in the following sections, the lastEventId attribute must be the empty string, the origin attribute must be the empty string, the source attribute must be null, and the messagePort attribute must be null.

Section 7.2, Server-sent events # T

This section describes a mechanism for allowing servers to dispatch DOM events into documents that expect it. In this section, the following changes were made.

• The section and the mechanism it describes were renamed to Server-sent events (previous drafts had use the term “Server-sent DOM events”).
• In the “The RemoteEventTarget interface” subsection, statements related to the src parameter for the addEventSource and removeEventSource methods were revised to make reference to resolving (rather than “adding”) the URL given by the src parameter, and to using the resulting absolute URL.
• In the “Interpreting an event stream” subsection, some revisions were made to the part of the algorithm that user agents are required to run when dispatching and event.

Section 7.3, Web sockets [formerly “Network connections”] # T

This section defines a mechanism for enabling Web applications to maintain bidirectional communications with their originating server. The “Web Sockets” section:

• defines a WebSocket interface (which essentially replaces the Connection interface defined in previous drafts)
• defines a single WebSocket constructor, which essentially replaces three constructors defined in previous drafts for creating Connection objects: TCPConnection(), which had been intended for creating a direct link to another node on the Internet using TCP/IP; LocalBroadcastConnection(), which had been intended for creating a connection to any listening peer on a local network (a local TCP/IP subnet using UDP, a Bluetooth PAN, or another kind of network infrastructure); and PeerToPeerConnection(), which had been intended for creating a direct peer-to-peer connection (over TCP/IP, Bluetooth, IrDA, or some other type of network).
• defines a single Web Socket protocol that specifies how a Web-socket-enabled user agent and Web-socket-enabled server communicate

Section 7.4, Cross-document messaging # T

This section introduces a messaging system, using the postMessage() method, that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks.

Section 7.5 [NEW], Channel messaging # T

This newly added section defines the MessageChannel and MessagePort interfaces.

Section 8.1, Writing HTML documents # T

This section provides basic syntax conformance requirements that apply to documents, authoring tools, and markup generators. In this section, the following changes were made:

• The following statement was added:

  Many strings in the HTML syntax (e.g. the names of elements and their attributes) are case-insensitive, but only for characters in the ranges U+0041 .. U+005A (LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) and U+0061 .. U+007A (LATIN SMALL LETTER A to LATIN SMALL LETTER Z). For convenience, in this section this is just referred to as “case-insensitive”.

• In the “Elements” subsection, the command, eventsource, and source elements were added to the list of void elements.
• In the “Optional tags” subsection, the article, aside, datagrid, dialog, dir, div, footer, header, nav, and section elements were added to the list of elements which, if they immediately follow a p element, allow the end tag for the p element to be omitted. Also, a statement was added to specify that the end tag for the p element may be omitted if there is no more content in the parent element.
• Also in the “Optional tags” subsection, the following statements were added:

  An rt element’s end tag may be omitted if the rt element is immediately followed by an rt or rp element, or if there is no more content in the parent element.

  An rp element’s end tag may be omitted if the rp element is immediately followed by an rt or rp element, or if there is no more content in the parent element.

• The phrase “CDATA blocks” was replaced with CDATA sections throughout the specification.

Section 8.2, Parsing HTML documents # T

This section defines parsing rules used by user agents, data mining tools, and conformance checkers in parsing text/html content. In this section, the following changes were made:

• A new “Coercing an HTML DOM into an infoset” subsection was added.
• In the “Parse state” subsection, the following changes were made:
  • Revisions were made to the algorithm for determining whether the stack of open elements has an element in scope.
  • The following elements were added to the list of elements having “varying levels of special parsing rules”: article, aside, command, datagrid, details, dialog, eventsource, figure, footer, header, nav, and section.
  • Revisions were made to the part of the tokenization algorithm that concerns the “bogus comment” state.
• In the “Tree construction” subsection, the following changes were made:
  • Several instances of the phrase “script that will execute as soon as the parser resumes” were changed to pending external script.
  • Instances of the phrases “CDATA parsing algorithm” and “RCDATA parsing algorithm” were changed to CDATA element parsing algorithm and RCDATA element parsing algorithm.
  • In the subsection for the “after after frameset” insertion mode, a final step was added for handling of the case a of a start tag whose tag name is “noframes”, and the algorithm was changed to specify that tokens other than those that it explicitly enumerates must be ignored.
• The details and figure elements were added to the “The ‘after head’ insertion mode” algorithm.

Section 1.2, Structure of this specification # T

This non-normative section provides information about the major divisions of information in the specification. In this section, the following changes were made:

• A note that the specification included an appendix regarding “shims for WYSIWYG editors” was removed (because that appendix was removed from the document).

Section 1.3, Conformance requirements # T

This section provides information about conformance requirements for Web browsers and user agents, conformance checkers, data mining tools, authoring tools, and markup generators. In this section, the following changes were made:

• In the introduction for this section, the words “SHALL” and “SHALL NOT” were removed from the list of words that “are to be interpreted as described in RFC2119”.
• In the “Conformance checkers” subsection, the text of a statement was updated to now read (added text highlighted):

  Automated conformance checkers are exempt from detecting errors that require interpretation of the author’s intent (for example, while a document is non-conforming if the content of a blockquote element is not a quote, conformance checkers running without the input of human judgement do not have to check that blockquote elements only contain quoted material).

  Also, the text of a related statement was updated to reference the concept of the browsing context; the text of that statement now reads:

  Conformance checkers must check that the input document conforms when parsed without a browsing context (meaning that no scripts are run, and that the parser’s scripting flag is disabled), and should also check that the input document conforms when parsed with a browsing context in which scripts execute, and that the scripts never cause non-conforming states to occur other than transiently during script execution itself.

• In the “Common conformance requirements for APIs exposed to JavaScript” subsection, for consistency with the Web IDL specification [WebIDL], statements related to cases for throwing NOT_SUPPORTED_ERR and TYPE_MISMATCH_ERR exceptions were removed.
• In a note that concerns XML processors, the following statement was removed completely: For interoperability, authors are advised to avoid optional features of XML.
• In the “Dependencies” subsection, a note was emended to now read (added text highlighted), It is possible for xml:base attributes to be present even in HTML fragments, as such attributes can be added dynamically using script. (Such scripts would not be conforming, however, as xml:base attributes as not allowed in HTML documents.)

Section 1.4, Terminology # T

This section provides information about specific technical terms used in the specification. In this section, the following changes were made:

• A paragraph regarding usage of IDL in the specification was shortened and refined to read: DOM interfaces defined in this specification use Web IDL. User agents must implement these interfaces as defined by the Web IDL specification.
• The following text related to the term “plugin” was added (with parts of it being moved here from the section for the embed element):

  The term plugin is used to mean any content handler, typically a third-party content handler, for Web content types that are not supported by the user agent natively, or for content types that do not expose a DOM, that supports rendering the content as part of the user agent’s interface.

  One example of a plugin would be a PDF viewer that is instantiated in a browsing context when the user navigates to a PDF file. This would count as a plugin regardless of whether the party that implemented the PDF viewer component was the same as that which implemented the user agent itself. However, a PDF viewer application that launches separate from the user agent (as opposed to using the same interface) is not a plugin by this definition.

  Note: This specification does not define a mechanism for interacting with plugins, as it is expected to be user-agent- and platform-specific. Some UAs might opt to support a plugin mechanism such as the Netscape Plugin API; others might use remote content converters or have built-in support for certain types.

  Warning! Browsers should take extreme care when interacting with external content intended for plugins. When third-party software is run with the same privileges as the user agent itself, vulnerabilities in the third-party software become as dangerous as those in the user agent.

Section 2.1, Documents # T

This section defines the Document object. In this section, the following changes were made:

• The following attributes were added to the definition of the HTMLDocument interface:
  • charset
  • characterSet
  • defaultCharset
  • embeds
  • plugins
  • readyState
  • scripts
  • queryCommandEnabled
  • queryCommandIndeterm
  • queryCommandState
  • queryCommandSupported
  • queryCommandValue
  The interface was also updated for consistency with the Web IDL specification [WebIDL], and to correctly document the hasFocus() method as a method (previously, the interface definition had incorrectly indicated that it was an attribute).
• In the “Resource metadata management” subsection, content that related to the domain DOM attribute (which is “used to enable pages on different hosts of a domain to access each others’ DOMs”) was moved out to form the basis for the algorithm in the “Relaxing the same-origin restriction” in the “Origin” section.
• Also in the “Resource metadata management” subsection, conformance criteria for data returned by the referrer DOM attribute and other parts of the section was refined — in particular, to reference the concepts of the active document and source browsing context — and the following note was added: Typically user agents are configured to not report referrers in the case where the referrer uses an encrypted protocol and the current page does not (e.g. when navigating from an https: page to an http: page). In the latter part of that same subsection, additional language was added that relates to:
  • quirks mode
  • document character encoding and the charset, characterSet, and defaultCharset DOM attributes
  • document readiness, the readystatechanged event, and the readyState DOM attribute

Section 2.2, Elements # T

This section defines the basic DOM interface for all HTML elements, the HTMLElement interface. In this section, the following changes were made:

• The following attributes were added to the definition of the HTMLElement interface:
  • dataset
  • isContentEditable
  • style
  • onstorage
• A number of refinements were made to the language in the “Reflecting content attributes in DOM attributes” subsection, most extensively to the description that relates to handling of DOM attributes that are of the floating-point number type.

Section 2.3, Common DOM interfaces # T

This section defines DOM interfaces known as collections, the DOMTokenList and DOMStringMap interfaces, and DOM feature strings for HTML. In this section, the following changes were made:

• In the “Collections” subsection, for consistency with the Web IDL specification [WebIDL], the definitions for the HTMLCollection, HTMLFormControlsCollection, HTMLOptionsCollection, and DOMTokenList interfaces were updated and language that stated conformance criteria for ECMAScript implementations was removed.
• In the “DOMTokenList” subsection, the algorithms for the add() and toggle() methods were slightly refined.
• The “DOMStringMap” subsection was added. It defines an interface for representing a set of name-value pairs.

Section 2.4, DOM tree accessors # T

This section defines the placement of the html, head, title, and body elements in the DOM tree, associated DOM attributes, and the getElementsByName() and getElementsByClassName() methods. In this section, the following changes were made:

• A refinement was made to the algorithm that must be run on setting the title.
• Conformance criteria related to the embeds, plugins, and scripts DOM attributes was added.

Section 2.5, Dynamic markup insertion # T

This section defines mechanisms that enable script authors to dynamically insert markup into a document. In the section, the following changes were made:

• In the “Controlling the input stream” subsection, a “Change the document’s character encoding to UTF-16” step was added to the algorithm that runs when the open() method is called.
• Some changes were made within the “Dynamic markup insertion in XML” subsection in this section — among them, the addition of a statement that If any of the elements in the serialisation are in the null namespace, the default namespace in scope for those elements must be explicitly declared as the empty string.

Section 2.6, APIs in HTML documents # T

This section provides details about case-insensitivity and case-changing behavior of data returned by certain DOM APIs. No changes have been made in this section.

Section 3.2, Common microsyntaxes # T

This section describes the conformance criteria for instances of particular data types (such as dates or numbers) used in HTML content, as well as describing how to parse such instances. In this section, the following changes were made:

• In the “Boolean attributes” subsection, the conformance criteria for boolean attributes were changed to state that a non-empty boolean-attribute value must be “a case-insensitive match for the attribute’s canonical name” (the statement had previously required non-empty values to be in lowercase).
• A number of change were made to the “rules for parsing a list of integers” algorithm in the “Numbers” subsection.
• A placeholder for a “URLs” subsection was added, with editorial notes about what its intended purpose will be.
• In the “Tokens” subsection, the following statement was added:

  Sets of space-separated tokens sometimes have a defined set of allowed values. When a set of allowed values is defined, the tokens must all be from that list of allowed values; other values are non-conforming. If no such set of allowed values is provided, then all values are conforming.

• In the “References” section, instances of the phrase “hashed ID reference” were changed to “hash-name reference”.

Section 3.3, Documents and document fragments # T

This section introduces the terms “semantics”, “structure”, “transparent”, and “paragraph” in the specific context of the HTML language, as well as defining a number of categories that HTML content can be grouped into. In this section, the following changes were made:

• In the “Semantics” subsection, a general statement about authoring conformance was re-written to now read, Authors must not use elements, attributes, and attribute values for purposes other than their appropriate intended semantic purpose., and a minor refinement was made to the accompanying example.
• In the “Structure” subsection, the following statement was removed completely: Authors must only put elements inside an element if that element allows them to be there according to its content model, and (in a later part of the same subsection), a general statement about authoring conformance was re-written to now read, Authors must not use elements in the HTML namespace anywhere except where they are explicitly allowed, as defined for each element, or as explicitly required by other specifications.
• Also in the “Structure” subsection, a statement was added that cites an example of a structural conformance requirement in the Atom specification, and a statement was added that elements in the HTML namespace may be orphan nodes (i.e. without a parent node), along with an example.
• In the “Kinds of content” subsection (and throughout the rest of the section and the specification), the term “prose content” was changed to flow content.
• In the “Transparent content models” subsection, a minor wording change was made.

Section 3.4, Global attributes # T

This section defines attributes that may be specified on all HTML elements. In this section, the following changes were made:

• The style attribute was added to the list of global attributes, and a subsection defining it was added.
• The onstorage attribute was added to the list of global attributes.
• The following conformance statement was added:

  custom data attributes (e.g. data-foldername or data-msgid) can be specified on any HTML element, to store custom data specific to the page.

  Also, an “Embedding custom non-visible data” subsection was added, with conformance criteria related to data- attributes and the associated dataset DOM attribute.
• The following conformance statement was added:

  In HTML documents, the html element, and any other elements in the HTML namespace whose parent element is not in the HTML namespace, may have an xmlns attribute specified, if, and only if, it has the exact value “http://www.w3.org/1999/xhtml”. This does not apply to XML documents.

  Also, two notes were added regarding the effects of the xmlns attribute in content.
• A new “The xml:base attribute (XML only)” subsection was added, with the following text:

  The xml:base attribute is defined in XML Base.

  The xml:base attribute may be used on elements of XML documents. Authors must not use the xml:base attribute in HTML documents.

• Some wording refinements were made to various subsections.

Section 3.5, Interaction # T

This section defines conformance requirements related to interactive DOM behavior in user agents, including activation of elements, element focus, and scrolling elements into view. In this section, the following changes were made:

• The wording for the entire “Focus” subsection was refactored to make “define .focus(), .blur(), onfocus, and onblur in a way that doesn’t require an infinite loop in the face of a hostile author, and that is better defined in terms of multiple iframes, windows, and orphaned elements”, and to provide the following definition of “focusable”: An element is focusable if the tabindex attribute’s definition above defines the element to be focusable and the element is being rendered. and, for the case where the scrollIntoView() method is called, to provide the following additional requirement: Visual user agents should further scroll horizontally as necessary to bring the element to the attention of the user.
• Also, in the “Focus” subsection, a change was made to correctly document the hasFocus() method as a method (previously, the interface definition had incorrectly indicated that it was an attribute).

Section 3.6, The root element # T

This section defines the semantics and structure of the html element. In this section, the only substantive change made was that a statement related to the xmlns attribute was moved out to an earlier point in the document, to the “Global attributes” section.

Section 3.7, Document metadata # T

This section defines the semantics and structure of the head element and those of its conformant descendant elements.

Section 3.8, Sections # T

This section defines the semantics and structure of the elements used for dividing documents into sections.

Section 3.9, Grouping content # T

This section concerns elements that are used to group phrasing content into logical structures such as paragraphs and lists. The title of the section was changed from “Prose” to “Grouping content”.

Section 3.10 [was 3.12], Text-level semantics # T

This section concerns elements used to mark up content at the “text level” (as opposed to the “sectioning” or “grouping” levels). The title of the section was changed from “Phrase elements” to “Text-level semantics”.

Section 3.11 [was 3.13], Edits # T

This section concerns the ins and del elements. In the introduction to this section, a large note with examples was moved out to form a separate subsection, “Edits and paragraphs” (which notes and illustrates the difficulties of attempting to mark up edits that cross implied paragraphs). The text of the sections on the ins and del themselves remains unchanged.

Section 3.12 [was 3.14], Embedded content # T

This section concerns elements used to embed non-text content in HTML pages, primarily binary media content (such as video and audio content, static images, images that are dynamically created through scripting), but also content in other markup languages (SVG and MathML).

Section 3.13 [was 3.15], Tabular data # T

This section concerns the table element and its descendant-element hierarchy.

Section 3.14 [was 3.16], Forms # T

This section is currently a placeholder without any content except the following editorial notes.

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

This section will be a rewrite of the HTML4 Forms and Web Forms 2.0 specifications, with hopefully no normative changes.

If a form is in a browsing context whose sandboxed forms browsing context flag is set, it must not be submitted.

Section 3.15 [was 3.17], Scripting # T

An introduction was added for this section. The full text of that introduction reads:

Scripts allow authors to add interactivity to their documents.

Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.

For example, instead of using script to show or hide a section to show more details, the details element could be used.

Authors are also encouraged to make their applications degrade gracefully in the absence of scripting support.

For example, if an author provides a link in a table header to dynamically resort the table, the link could also be made to function without scripts by requesting the sorted table from the server.

Section 3.16 [was 3.18], Interactive elements # T

This section concerns the details, datagrid, command, menu elements.

Section 3.17 [was 3.19], Data Templates # T

This section concerns the datatemplate, rule, and nest elements. No substantive changes were added to this section, and support for the datatemplate elements and its associated elements remains unimplemented in any user agents.

Section 3.18 [was 3.20], Miscellaneous elements # T

This section concerns the legend, and div elements. No substantive changes were made in this section (other than global changes that were made to other parts of the specification as well; for example, the replacement of the term “prose content” with the term flow content).

Section 4.1, Browsing context # T

This section defines a browsing context as “a collection of one or more Document objects, and one or more views, as well as particular browsing contexts, including the active document“. In this section, the following changes were made:

• A statement related to creation of a browsing context was updated to read (added text highlighted): When a browsing context is first created, it must be created with a single Document in its session history, whose address is about:blank, which is marked as being an HTML document, and whose character encoding is UTF-8.
• A description was added of how the origin of the about:blank Document object is set.
• In the “Nested browsing contexts” subsection, the following statements were added:

  The transitive closure of parent browsing contexts for a nested browsing context gives the list of ancestor browsing contexts.

  A nested browsing context can have a seamless browsing context flag set, if it is embedded through an iframe element with a seamless attribute.

• A definition of the concept of an ancestor of a browsing context was added.
• A “Security” subsection was added, with a definition of the concept of allowed to navigate.
• In the “Browsing context names” subsection, a number of changes were made — among them, the addition of conformance statements related to the condition of the sandboxed navigation browsing context flag being set — and a statement was added that User agent implementors are encouraged to provide a way for users to configure the user agent to always reuse the current browsing context.

Section 4.2, The default view # T

This section defines the interface for the Window object. In this section, the following changes were made:

• The interface definition was updated for consistency with the Web IDL specification [WebIDL] and to refer to the localStorage attribute (which was previously named globalStorage and to add the showModalDialog and XXX4 methods and onstorage attribute. (Note that the “XXX4“ name is simply a placeholder; it is not intended that the method will be implemented with that literal name.)
• In the “Security” subsection, the XXX4 and frames attribute were added to the list of exceptions.
• In the “APIs for creating and navigating browsing contexts by name” subsection, the phrase “valid browsing context name” was emended to become valid browsing context name or keyword, and conformance requirements related to using the script execution context were added.
• In the “Accessing other browsing contexts” subsection, for consistency with the Web IDL [WebIDL] specification, language that stated conformance requirements for ECMAScript implementations was removed, and requirements were added in relation to the condition of the sandboxed origin browsing context flag being set.

Section 4.3 [was 4.3.2], Origin # T

This section, which had been a subsection of the “Scripting” section, was moved up a level in the section hierarchy to instead become a sibling to section to the “Scripting” section. This section defines the origin and effective script origin of a resource (a URI, a script, or a Document object or image). In this section, the following changes were made:

• The term effective script origin has been introduced, and its characteristics defined along with those of the term origin.
• The word “origin” was replaced by “value” in the sentence that now reads, “If the scheme is ‘file’, then the user agent may return a UA-specific value”
• Some instances of the phrase “the same as the origin” were refined to read “equal to the origin”.
• The criteria for determining origin and effective script origin were reorganized and expanded, with the “Unscripted same-origin checks” subsection being moved to become the “For URIs” part of that list of criteria.
• An algorithm was added for determining the whether any two given origins are of the same origin
• A new “Relaxing the same-origin restriction” subsection was added, with most of the content of that subsection being content moved out from the “Resource metadata management” subsection within the “The Document Object Model” major section. This “Relaxing the same-origin restriction” now more explicitly defines an algorithm that must be run when setting the domain attribute on Document objects.

Section 4.3 [now 4.4], Scripting # T

This section provides conformance criteria related to mechanisms that can cause author-provided executable code to run in the context of a document scripting, as well as defining the states scripting is enabled and scripting is disabled.

• A new “Script execution contexts” subsection was added to define the script execution context of a script. It also introduces the term without script and the term with script (A node is said to be with script if it is not without script), along with the following editorial note: If you can find a better pair of terms than “with script” and “without script” let me know. The only things I can find that are less confusing are also way, way longer.
• In the “The javascript: protocol” subsection, some clarifying language was added, and the case for the “dereference context” that had previously stated that it must be “the browsing context of the Document to which belongs the element for which the URI is being dereferenced, or to which the style sheet for which the URI is being dereferenced applies, whichever is appropriate” was changed to instead say that it must be an empty object for that same case; also, the following note was added: The rules for handling script execution in a script execution context include making the script not execute (and just return void) in certain cases, e.g. in a sandbox or when the user has disabled scripting altogether.
• In the “Events” subsection, a number of changes were made — among them, the addition of the onstorage event to the list of event handler attributes that must be supported by all HTML elements and on Window objects. Also, a statement related to the script execution context was added, and, in the same subsection, a clarifying statement that The listener argument is emphatically not the event handler attribute itself. Also, for consistency with the Web IDL specification [WebIDL], some statements that provided conformance criteria for ECMAScript DOM bindings were removed.

Section 4.4 [now 4.5], User prompts # T

This section provides conformance criteria related to dialogs presented to users. In this section, the following changes were made:

• The existing content of this section was moved, unchanged, to become the “Simple dialogs” subsection.
• A new “Dialogs implemented using separate documents” subsection was added. That subsection defines how user agents must behave when the showModalDialog() method is invoked.
• A new “Notifications” subsection was added. That subsection concerns short, transient messages that bring the user’s attention to new information, or remind the user of scheduled events, and defines a new showNotification() method.
• A new “Printing” subsection was added. It defines steps that take place when the print() method is invoked, including steps related to the beforeprint and afterprint events

Section 4.5 [now 4.6], Browser state # T

This section defines how Web sites can register themselves as potential protocol and content handlers; for example, how a Web-based mail application can register itself as a potential handler for the mailto: protocol.

No changes at all were made to this section since the FPWD.

Section 4.6 [now 4.7], Offline Web applications # T

This section defines a mechanism by which Web applications can maintain an application cache, with an accompanying manifest, that allows some limited use of the application even when the user is offline.

A variety of refinements have been made to this section since the FPWD.

Section 4.7 [now 4.8], Session history and navigation # T

This section defines the session history for a browsing context and its associated History interface. In this section, the following changes were made:

• Language defining the last activated entry was added.
• A significant part of what had been in this section was moved out to form the basis for the “History traversal” subsection in the “Browsing the Web” section.
• A number of other changes were made, including the addition of more explicit steps in the “Activating state object entries” subsection, and, for consistency with the Web IDL specification [WebIDL], the removal of conformance requirements for the ECMAScript DOM binding for the Location interface, and a statement related to the script execution context was added.

Section 4.9 [new], Browsing the Web # T

This section was formed by moving the contents of the existing “Navigating across documents” section down one level in the section hierarchy and adding to it a subsection on “History traversal”, which was moved here from the “Session history and navigation” section.

A number of changes were made to the content that was moved to form this section — among them, the addition of statements related to the source browsing context and some criteria related to the “opportunistic caching namespace” and “opportunistically cached entries”, to setting of document character encoding, and to the sandboxed plugins browsing context flag.

Section 4.9 [now 4.10], Determining the type of a new resource in a browsing context # T

This section provides conformance criteria related to content-type sniffing. In this section, the following changes were made:

• Some changes were made to the algorithm for finding the “sniffed type of a resource”, as well as to the “Content-Type sniffing: feed or HTML” and “Content-Type metadata” subsections.
• References to UTF-32 were removed from the table in the “Content-Type sniffing: text or binary” subsection.
• An item for the image/vnd.microsoft.icon type was added in two tables that list byte sequences used in the type-sniffing algorithm.
• revisions were made to the specific algorithm for extracting an encoding from a Content-Type.
• The following note was added: The above algorithm is a willful violation of the HTTP specification.

Section 4.11 [new], Structured client-side storage # T

This section was formed by combining the existing “Client-side session and persistent storage of name/value pairs” and “Client-side database storage” sections with common sections related to disk space, security, and privacy. A number of changes were made in these content that is now in this section — among those changes are the following:

• Some instances of “origin” were changed to “site”.
• In the “Storing name/value pairs” subsection, the globalStorage DOM attribute was renamed to localStorage.
• The “Storing name/value pairs” subsection also adds an definition for the StorageEvent interface, with initStorageEvent() and initStorageEventNS() methods.
• Also in the “Storing name/value pairs” subsection, some instances of the term “origin” were changed to “site”; for example, in the statement that now reads Each site has its own separate storage area.
• The “Disk space” and “Security and privacy” parts of the “Miscellaneous implementation requirements for storage areas” subsection of the “Client-side session and persistent storage of name/value pairs” section were moved to become shared sibling sections of both the “Storing name/value pairs” and “Database storage” subsections.
• In the “Database storage” subsection, the following editorial note was added:

  Implementation feedback is requested on what to do with arguments that are of types that are not supported by the underlying SQL backend. For example, SQLite doesn’t support booleans, so what should the UA do if passed a boolean? The Gears team suggests failing, not silently converting types.

• Also in the “Database storage” subsection, the interface definition for the SQLResultSetRowList interface was updated for consistency with the Web IDL specification [WebIDL].

Section 4.12, Links # T

This section provides conformance criteria related to handling of hyperlinks. This section remains largely unchanged, though some significant changes were made to — among those, the following:

• In the “Hyperlink elements” subsection, the phrase “valid browsing context name” was emended to become valid browsing context name or keyword.
• In the “Following hyperlinks” subsection, a statement related to the source browsing context was added.
• Particularly significant changes were made to the “Hyperlink auditing” subsection (which states requirements for HTTP-request behavior when a user follows a hyperlink for an a or area element that has a ping attribute); a statement was added that All relevant cookie and HTTP authentication headers must be included in the request. Which other headers are required depends on the URIs involved, and criteria was added for conditions under which Ping-From, Ping-To, and Referer HTTP headers must be included.
• In the “Link types” section, the link type “contact” was removed from the table that lists conformant link types.
• The subsection that defined that “contact” link type was completely removed.
• In the subsection that defines the “icon” link type, the following changes were made:
  • A definition was added for the sizes attribute (for specifying sizes for icon link types) and its conformant values
  • The type attribute was added to the set of attributes that user agents must use when to select the most appropriate icon when multiple icons are available.
  • The following statement was added:

    If the user agent tries to use an icon but that icon is determined, upon closer examination, to in fact be inappropriate (e.g. because it uses an unsupported format), then the user agent must try the next-most-appropriate icon as determined by the attributes.

  • Text which had stated that “If there are multiple equally appropriate icons, user agents must use the first one declared in tree order” was revised to read, If there are multiple equally appropriate icons, user agents must use the last one declared in tree order.
  • In reference to the sizes attribute, the following statement was added:

    If the attribute is not specified, then the user agent must assume that the given icon is appropriate, but less appropriate than an icon of a known and appropriate size.

• In the subsection that defines the “nofollow” link type, a statement was emended to now read (add text highlighted), The nofollow keyword indicates that the link is not endorsed by the original author or publisher of the page, or that the link to the referenced document was included primarily because of a commercial relationship between people affiliated with the two pages.
• In the subsection that defines the “prefetch” link type, a statement was added that There is no default type for resources given by the “prefetch” keyword.
• In the subsection that defines the “stylesheet” link type, a statement was added that The default type for resources given by the stylesheet keyword is text/css, and a description was added of quirks-mode behavior with respect to this link type.
• In the subsection that defines the “UP” link type, a statement was added that Only one link is created for the set of one or more “up” keywords and, if present, the “index” keyword.

Section 4.13, Interfaces for URI manipulation # T

This section specifies a set of attributes for any interface that has a “complement of URI decomposition attributes”. In this section, a statement was added to specify conformant behavior when replacing a component in a URI, and a change was made to the parsing rules for the port attribute.

Section 5.2, The contenteditable attribute # T

This section defines handling of HTML elements that have the contenteditable attribute. In this section, the following changes were made:

• Language defining the inherit state and related handling was added.
• A sentence was added to define handling of the isContentEditable DOM attribute.
• In the “User editing actions” subsection, the following statement was added: “User agents may prevent selections from being made in ways that cross from editable elements into non-editable elements (e.g. by making each non-editable descendant atomically selectable, but not allowing text selection within them).”
• Language was added to state that UAs should should offer a way for the user to delete “non-editable descendants”.
• A general statement that “UAs should offer a way for the user to mark text as having stress emphasis and as being important” was removed, and the following statements were added:

  In response to a request from a user to mark text up in italics, user agents should use the i element to represent the semantic. The em element should be used only if the user agent is sure that the user means to indicate stress emphasis.

  In response to a request from a user to mark text up in bold, user agents should use the b element to represent the semantic. The strong element should be used only if the user agent is sure that the user means to indicate importance.

• In the “Making entire documents editable” subsection, refinements were made to the description of handling for the case when the designMode DOM attribute on the Document object is set.

Section 5.3, Drag and drop # T

This section defines an event-based drag-and-drop mechanism. The bulk of this section remains unchanged from the FPWD, with the exception of a handful of statements that were refined or removed from the section, and the single significant addition to the section being the addition of a types DOM attribute to the DataTransfer interface, and a description of its handling.

Section 5.4, Undo history # T

This section defines how to associate an undo transaction history with each HTMLDocument object, and an UndoManager interface for manipulating that undo transaction history. The bulk of this section remains unchanged from the FPWD, and the mechanism is specifies remains unimplemented in any user agents. The only changes to this section were, for consistency with the Web IDL specification [WebIDL], the removal of a sentence stating conformance requirements for the associated ECMAScript DOM binding for the UndoManager interface, and a change to the interface definition for the UndoManager interface.

Section 5.5 [now 5.6], Command APIs # T

This section defines an execCommand method on the HTMLDocument interface, mainly to allow scripts to editor UI that allows users to perform actions on the current selection or at the current caret position. In this section, the following changes were made:

• The following additional methods were added:
  • queryCommandEnabled
  • queryCommandIndeterm
  • queryCommandState
  • queryCommandSupported
  • queryCommandValue
• A number of additional commands have been added and defined.

Section 5.6 [now 5.5], The text selection APIs # T

This section defines a selection that exists for each instance of a browsing context, and a Selection interface with a getSelection() method for retrieving the selection. In this section, the following changes were made:

• The interface definition for the Selection interface was updated for consistency with the Web IDL specification [WebIDL].
• Explicit references to the toString() method in this section were changed to refer instead to stringification.
• Statements were added to specify that User agents may selectively ignore attempts to use the API to adjust the selection made after the user has modified the selection and may also allow the user to create selections that are not exposed to the API.

Section 6.1, Event definitions # T

This section defines the MessageEvent interface. In this section, the following changes were made:

• The domain attribute was renamed origin (and its definition was refined), the uri attribute was removed, and the lastEventId attribute was added.

Section 6.2, Server-sent DOM events # T

This section describes a mechanism for allowing servers to dispatch DOM events into documents that expect it. In this section, the specification for the server-sent events format was rewritten; among the specific changes made were the addition of language related to reconnection time and the last event ID string, and extensive changes to the “Interpreting an event stream” subsection.

Section 6.3, Network connections # T

This section defines a Connection interface to enable Web applications to communicate with each other in local area networks, and to maintain bidirectional communications with their originating server. In this section, the only substantive changes made were the addition of the readyState attribute to the Connection interface, and corrections in the “TCP connections” subsection to replace some instances of “domain” with “host”. No other significant changes were made (and the interface remains unimplemented in any user agents).

Section 6.4, Cross-document messaging # T

This section introduces a messaging system, using the postMessage() method, that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks. In this section, the following changes were made:

• The postMessage() method was changed from being synchronous to being asynchronous.
• A targetOrigin argument was added to the postMessage() method.
• The description of required user-agent behavior when a script invokes the postMessage() method was expanded and made into a numbered set of steps.
• In the “Processing model”, a clarification related to non-same origin behavior was added to a warning note.

Section 8.1, Writing HTML documents # T

This section provides basic syntax conformance requirements that apply to documents, authoring tools, and markup generators. In this section, the following changes were made:

• The following statement was removed completely: The U+0000 NULL character must not appear anywhere in a document.
• A note describing handling of comments and space characters around the html, head, and body elements and handling of newlines inserted after the DOCTYPE was refined.
• In the “Elements” subsection, the category foreign elements was added to the list of kinds of elements, the definition of foreign elements as Elements from the MathML namespace was added, and other parts of the section were updated to add language related to foreign elements.
• Also in the “Elements” subsection, the range “U+0030 DIGIT ZERO .. U+0039 DIGIT NINE” was added to the set of allowed characters in tag names.
• Also in the “Elements” subsection, the description of allowed characters for attribute names and unquoted attribute value syntax were refined, and statements were added to make it clear that a space is required after a quoted attribute value and any following attribute.
• Also in the “Elements” subsection, refinements were made to the description of conditions under which certain tags can be omitted.
• Also in the “Elements” subsection, the following statement was removed completely:

  A p element must not contain blockquote, dl, menu, ol, pre, table, or ul elements, even though these elements are technically allowed inside p elements according to the content models described in this specification. (In fact, if one of those elements is put inside a p element in the markup, it will instead imply a p element end tag before it.)

• Also in the “Elements” subsection, the definition of escaping text span was refined.
• The title of the “Character entity references” subsection was changed to “Character references”, the term “Named entities” was changed to Named character references, and other instances of the term “character entity references” were changed to “character references”.
• Also in the “Character references” subsection, the definition of ambiguous ampersand was refined.
• A new “CDATA blocks” subsection was added.
• In the “Comments” subsection, the description of comments was refined to add the constraint that comments must not start with a single U+003E GREATER-THAN SIGN (‘>‘) character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN (‘>‘) character

Section 8.2, Parsing HTML documents # T

This section defines parsing rules used by user agents, data mining tools, and conformance checkers in parsing text/html content. In this section, the following changes were made:

• In the “The input stream” subsection, the following changes were made:
  • In the parts of the that deal with preprocessing the input stream, character encoding requirements, and determining the character encoding of the input stream, a number of refinements were made, including the addition of a clarification related to the source browsing context.
  • The following note was added:

    This specification does not make any attempt to support UTF-32 in its algorithms; support and use of UTF-32 can thus lead to unexpected behavior in implementations of this specification.

  • In the “Changing the encoding while parsing” subsection, the first step in the algorithm for changing the encoding, which had read, “If the new encoding is UTF-16, change it to UTF-8”, was updated to now read (changed text highlighted), If the new encoding is a UTF-16 encoding, change it to UTF-8.
  • Also, in the “Changing the encoding while parsing” subsection, the following statement, which had been placed at the end of the algorithm, was removed completely: While the invocation of this algorithm is not a parse error, it is still indicative of non-conforming content.
• Significant revisions were made to the “Character encoding requirements” subsection, including the addition of a “Character encoding overrides” table, and the refinement of an accompanying note to now read, The requirement to treat certain encodings as other encodings according to the table above is a willful violation of the W3C Character Model specification.
• A new “Parse state” subsection was added.
• The algorithm for resetting the insertion mode was refined for the case of innerHTML used with td and th.
• A new “The scripting state” subsection was added, with the following text: The scripting flag is set to “enabled” if the Document with which the parser is associated was with script when the parser was created, and “disabled” otherwise.
• In the “Tokenisation” subsection, a number of changes were made — among them, the addition of an After attribute value (quoted) state, a Self-closing start tag state, and a CDATA block state. Also, statements that had referred to setting the public identifier and system identifier to “the empty string” were emended to read refer to setting them to the empty string (not missing); statements that referred to the state in which the public identifier or system identifier was “not set” were revised to instead refer to those as being the case were a public identifier or system identifier was “missing”, and the following statement was added: A system identifier whose value is the empty string is not considered missing for the purposes of the conditions above.
• In the “Tree construction” subsection, a number of changes were made — among them, the following:
  • Descriptions were added for handling foreign elements and foreign attributes.
  • More doctypes were added to the list of “quirks mode” doctypes, all doctypes that ended in //EN were revised to drop the //EN, and the accompanying text was changed to say that instead of the public identifier being “set to” a particular doctype string that it instead “starts with” that particular doctype string.
  • A new “Foster parenting” subsection was created; its contents were formed by moving statements out from algorithms in other parts of the “Tree construction” section to form this new subsection.
  • Statements related to handling of the ruby, rp, and rt elements were added.
  • The tree-construction algorithm was refined to allow the noframes element as a child of the head element, and to cause a textarea element within a select element to imply an end tag for the select element.
  • Algorithms in this section were updated to define handling of a number of elements that are newly added in HTML5, including command, event-source, article, aside, datagrid, dialog, footer, header, nav, section, param, source,
  • The following step was added in the “The ‘in body’ insertion mode” subsection:

    An end tag whose tag name is “sarcasm”

    Take a deep breath, then act as described in the “any other end tag” entry below.

• A number of instances of the phrase “if scripting is enabled” were changed to read, if the scripting flag is enabled.
• In the “The end” subsection, language related to current document readiness was added.

Section 8.3, Namespaces # T

In this section, namespace URIs were added for the following: MathML, SVG, XLink, XML, XMLNS.

Section 8.4, Serializing HTML fragments # T

In this section, some language refinements were made, and ProcessingInstruction handling was added to the HTML fragment serialization algorithm.

Section 8.5, Parsing HTML fragments # T

In this section, some minor refinements were made, and a requirement about switching the HTML parser‘s tree construction stage was removed from one of the parsing steps.

Section 8.6, Entities [now "Named character references"] # T

In this section, the following changes were made:

• The title of the section was changed to “Named character references”, and the table listing character reference names that are supported by HTML, and the code points to which they refer, was greatly expanded — mainly to include named character references of potential use in MathML documents.