HTML 5 Publication Notes

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.