W3C

HTML 5 Publication Notes

W3C Editor’s Draft 25 July 2008

Latest Editor’s Draft:
http://dev.w3.org/html5/pubnotes/Overview.html
Latest Published Version:
http://www.w3.org/TR/html5-pubnotes/
Previous Version:
http://www.w3.org/TR/2008/NOTE-html5-pubnotes-20080610/
Editor:
Michael(tm) Smith, W3C <mike@w3.org>

skip to Table of Contents

Abstract

This document provides summaries and details about changes made between successive W3C drafts of the HTML 5 specification [HTML5]. It documents substantive changes only, and omits editorial changes. It’s intended to be readable as a “standalone” document — so that readers can use it to get an overview of the changes without necessarily needing to read the specification itself.

Editorial note

This document was generated on 2008-07-25T23:24:14+09:00.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the 25 July 2008 Editor’s Draft of HTML 5 Publication Notes. Please send comments about this document to public-html-comments@w3.org (archived).

This document was produced by the W3C HTML Working Group. You can find the source for the current version of this document in the group’s source repository.

Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

Current summary list of selected changes # T

This section provides a high-level list of selected changes in the current Editor’s Draft of the HTML 5 specification that were made after the June 2008 working draft. For more detailed descriptions of the changes, see the sections in this document that follow this one.

Current detailed list of changes # T

This section provides a per-section record of changes in the current Editor’s Draft of the HTML 5 specification that were made after the June 2008 working draft.

Section 1, Introduction # T

The “Introduction” section of the specification provides both non-normative (informative) background and context information on the specification, as well as normative information.

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 [NEW], Common infrastructure # T

This section was added during reorganization; it is a new logical division containing subsections moved from other existing sections.

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, Semantics and structure of HTML documents # T

The structure of this section has changed significantly. Many of its previous subsections were moved out to form the new “The elements of HTML” section, and a number of subsections that had been in the “The Document Object Model” section were moved into this one.

This section provides a definition of HTML documents and HTML elements in terms of the DOM; it defines:

  • the Document object and HTMLDocument interface (associated DOM attributes and DOM tree accessors)
  • the HTMLElement interface
  • global HTML content attributes and event-handler content attributes
  • types/classes of content and content models
  • mechanisms for dynamically inserting markup into HTML documents (the document.write() family of methods and innerHTML family of DOM attributes.

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.3.3, Global attributes # T

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

  • A statement that had read, “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” was revised to read, In HTML documents, elements 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”.
  • In the “Embedding custom non-visible data” subsection, a statement defining custom data attributes was revised to read (added text highlighted): A custom data attribute is an attribute whose name starts with the string “data-”, has at least one character after the hyphen, is XML-compatible, and has no namespace.

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 [NEW], The elements of HTML # T

During reorganization, this newly titled section was formed from subsections that had previously been in the “Semantics and structure of HTML documents” section. It defines the meanings and content models for each element in the HTML language, and includes both “authoring conformance” or “document conformance” requirements (to enable authors to produce conformant HTML documents) with “implementation conformance” or “user-agent conformance” requirements (to enable implementors to produce conformant HTML user agents).

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.2.3, The base element # T

In this section, the following note was added.

If there are multiple base elements with target attributes, all but the first are ignored.

Section 4.3, Sections # T

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

Section 4.3.10, Headings and sections # T

In this section, the following changes were made:

  • A part of the “When entering a heading content element” algorithm related to the candidate section was revised.
  • A correction was made to the “Creating an outline” algorithm.

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.4.9, The li element # T

In this section, the following changes were made:

  • The following statement was added:

    If the li element is the child of a menu element and itself has a child that defines a command, then the li element must match the :enabled and :disabled pseudo-classes in the same way as the first such child element does.

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.7.2, The img element # T

In this section, the following changes were made:

  • In statements related to behavior when the src attribute is set, the text was revised to refer to fetching of the associated resource (rather than “downloading”).

Section 4.7.4, The embed element # T

In this section, the following changes were made:

  • In a part of the algorithm that defines the type of content being embedded, the following statements were added:

    Otherwise, if the <path> component of the URL of the specified resource matches a pattern that a plugin supports, then the content’s type is the type that that plugin can handle.

    For example, a plugin might say that it can handle resources with <path> components that end with the four character string “.swf”.

  • Extensive revisions were made in this section in order to specify how user agents must handle the case of an embed element without a src attribute.
  • In statements related to behavior when the src attribute is set, the text was revised to refer to fetching of the associated resource (rather than “downloading”).
  • A statement regarding attributes on the embed element was revised to now read (added text highlighted): Any (namespace-less) attribute may be specified on the embed element so long as its name is XML-compatible.

Section 4.7.5, The object element # T

In this section, the following changes were made:

  • In a part of the algorithm for that user agents must run to determine what object element represents, the following statement was added: Otherwise, if the resource type is “application/octet-stream” but there is no type attribute on the object element, then change the resource type to be unknown, so that the sniffing rules in the next step are invoked.
  • A statement specifying user-agent behavior when the data attribute is present had read “Begin a load for the resource”; that statement was changed to read, Fetch the resource specified by the data attribute.

Section 4.7.7, The video element # T

In this section, the following changes were made:

  • The following statements were added:

    In addition to the above, the user agent may provide messages to the user (such as “buffering”, “no video loaded”, “error”, or more detailed information) by overlaying text or icons on the video or other areas of the element’s playback area, or in another appropriate manner.

    User agents that cannot render the video may instead make the element represent a link to an external video playback utility or to the video data itself.

  • Significant revisions were made to the text defining the adjusted aspect ratio of a video.
  • Revisions were made to the text defining the pixelratio attribute.
  • Text was added to define the intrinsic height and intrinsic width of a video, as well as to reference the pixel ratio override.
  • The following statements were added:

    The video element supports dimension attributes.

    Video content should be rendered inside the element’s playback area such that the video content is shown centered in the playback area at the largest possible size that fits completely within it, with the video content’s adjusted aspect ratio being preserved. Thus, if the aspect ratio of the playback area does not match the adjusted aspect ratio of the video, the video will be shown letterboxed. Areas of the element’s playback area that do not contain the video represent nothing.

  • A definition of the term poster frame (the resource given by the poster attribute) was added, and instances of the phrase “resource given by the poster attribute” throughout were changed to poster frame.
  • The following statement was added:

    Notwithstanding the above, the poster frame should be preferred over nothing, but the poster frame should not be shown again after a frame of video has been shown.

  • The following notes were added:

    The image given by the poster attribute, the poster frame, is intended to be a representative frame of the video (typically one of the first non-blank frames) that gives the user an idea of what the video is like.

    The poster frame is not affected by the pixel ratio conversions.

  • In regard to the URL for the poster attribute, the following statement was added: If the specified resource is to be used, it must be fetched when the element is created or when the poster attribute is set.

Section 4.7.9, The source element # T

In this section, the following changes were made:

  • The following statement was added: If the computed values are undefined for a particular case (e.g. because the canvas element is not in a document), then the relative keywords must be interpreted relative to the normal-weight 10px sans-serif default.
  • The following note concerning the default value of the pixelratio attribute was added:

    The only way this default is used is in deciding what number the pixelRatio DOM attribute will return if the content attribute is omitted or cannot be parsed. If the content attribute is omitted or cannot be parsed, then the user agent doesn’t adjust the intrinsic width of the video at all; the intrinsic dimensions and the intrinsic pixel ratio of the video are honoured.

  • In the definition of the type attribute, an instance of the term “downloading” was replaced with fetching.

Section 4.7.10, Media elements # T

In this section, the following changes were made:

  • The interface definition for the HTMLMediaElement interface was updated to add an id argument to the addCueRange() method and to reference the CueRangeCallback interface, which takes an id value as its sole argument.
  • In the “Cue ranges” subsection, the following changes were made:
    • The following definition for the id argument to the addCueRange() method was added:

      A string can be assigned to each cue range for identification by script. The string need not be unique and can contain any value.

    • The algorithm for specifying how user agents must behave when the current playback position of a media element changes was revised to reference the id parameter passed to the addCueRange() method, as well as the CueRangeCallback interface.
  • In the “Loading the media resource” subsection, the following changes were made:
    • a statement regarding the buffered attribute was updated to read (changed text highlighted), The buffered attribute must return a static normalized TimeRanges object that represents the ranges of the media resource, if any, that the user agent has buffered, at the time the attribute is evaluated, a statement regarding the bufferedBytes attribute was updated to read, The bufferedBytes attribute must return a static normalized ByteRanges object that represents the ranges of the media resource, if any, that the user agent has buffered, at the time the attribute is evaluated, and the following statement was added: User agents may discard previously buffered data.
    • The following note was added: Thus, a time or byte position included within a range of the objects return by the buffered or bufferedBytes attributes at one time can end up being not included in the range(s) of objects returned by the same attributes at a later time.
    • A step in the algorithm that user agents must run when the load() method is invoked on a media element was revised to now read (added text highlighted): The user agent must then set the begun flag to true and synchronously fire a progress event called loadstart at the media element.
    • A step in the algorithm that user agents must run when the load() method is invoked on a media element was revised to now read (added text highlighted): Any already-running instance of this algorithm for this element must be aborted. If those method calls have not yet returned, they must finish the step they are on, and then immediately return. This is not blocking; this algorithm must not wait for the earlier instances to abort before continuing.
  • In the “Location of the media resource” subsection, the following changes were made:
    • Text was added to define the pixel ratio override of a media resource.
    • A step in the algorithm for picking a media resource for a media element was revised to now read (added text highlighted: If candidate is not null and it has a pixelratio attribute, and the result of applying the rules for parsing floating point number values to the value of that attribute is not an error, then let the chosen resource’s pixel ratio override be that result. result; otherwise, reset it back to none.
  • In the “Offsets into the media resource” subsection, the introduction to an algorithm was updated to now read (added text highlighted): When any of the start, loopStart, loopEnd, end, playCount, and currentLoop DOM attributes change value (either through content attribute mutations reflecting into the DOM attribute, if applicable, or through direct mutations of the DOM attribute), the user agent must apply the following steps.
  • In the “Playing the media resource” subsection, the following note was added:

    This specification doesn’t define how the user agent achieves the appropriate playback rate — depending on the protocol and media available, it is plausible that the user agent could negotiate with the server to have the server provide the media data at the appropriate rate, so that (except for the period between when the rate is changed and when the server updates the stream’s playback rate) the client doesn’t actually have to drop or interpolate any frames.

  • In the “User interface” subsection, text was changed to state that the initial value of the volume attribute must be 1.0 (the text had previously stated that the initial value must be 0.5).

Section 4.7.11, The canvas element # T

The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly. In this section, the following changes were made:

  • Text specifying the valid arguments on the toDataURL() method was revised to state that if the first argument to that method is image/jpeg, a number between 0.0 and 1.0 (specifying a desired quality level) may be given as a second argument.

Section 4.7.11.1, The 2D context # T

This section provides an extensive immediate-mode graphics API for use with the canvas element. In this section, the following changes were made:

  • A part of this section that defines the rounding behavior of the createImageData() method was refined to be like that of the getID() and putID() methods.
  • The CanvasPixelArray interface was added to the interface definition for the CanvasRenderingContext2D interface, and statements were added to define the relationship of the data attribute on ImageData objects to the CanvasPixelArray object.
  • The following text was added:

    Whenever the CSS value currentColor is used as a color in this API, the “computed value of the ‘color’ property” for the purposes of determining the computed value of the currentColor keyword is the computed value of the ‘color’ property on the element in question at the time that the color is specified (e.g. when the appropriate attribute is set, or when the method is called; not when the color is rendered or otherwise used). 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 “Text” subsection, text was revised to specify that the values of the ‘font-size’ and ‘font-weight’ components must be interpreted relative to the computed value of the corresponding canvas element at the time that the attribute is set.
  • Text defining the miter length was revised for clarity.
  • Part of the text defining the butt value for the lineCap attribute was revised to now read (added text highlighted): The butt value means that the end of each line has a flat edge perpendicular to the direction of the line (and that no additional line cap is added).
  • Text specifying “gradient interpolation” was revised to specify both an interpolation and extrapolation.
  • The “Shadows” subsection was updated to state that support for shadows is a requirement (in previous drafts, it had stated that such support was optional).
  • In the “Complex shapes (paths)” subsection, the following changes were made:
    • Text specifying behavior of the arc() method was revised (to bring it closer to actual implementation behavior), and the following statement related to the arc() method was added: If the absolute magnitude of the difference between the startAngle and endAngle angles is equal to or greater than 2π, then the arc is the whole circumference of this circle.
    • Text specifying behavior of the arcTo() method was revised to address the case where the value of the radius argument to that method is zero.
  • In the “Pixel manipulation” subsection, the following changes were made:
    • Text was revised to make it clear that there are two putImageData() methods with different amounts of arguments.
    • Revisions were made to an example illustrating the generation of an ImageData object.
    • A reference to “the IEEE 754r roundTiesToEven rounding mode” was changed to the IEEE 754r convertToIntegerTiesToEven rounding mode
    • Statements which had specified that an INDEX_SIZE_ERR must be raised when the value of any of the arguments to the createImageData(), getImageData(), and putImageData(), methods were changed to instead specify that a NOT_SUPPORTED_ERR must be raised.
  • In the “Colors and styles” subsection, statements which had specified that an INDEX_SIZE_ERR must be raised when the value of any of the arguments to the createRadialGradient() or createLinearGradient() methods were changed to instead specify that a NOT_SUPPORTED_ERR must be raised.
  • In the “Security with canvas elements” subsection, revisions were made to text specifying the conditions under which the value of the origin-clean flag on a particular canvas element is set to false, and the following note was added: Even resetting the canvas state by changing its width or height attributes doesn’t reset the origin-clean flag.

Section 4.7.13, The area element # T

In this section, the following changes were made:

  • A paragraph that provides authoring-conformance criteria for the area element was updated to now read (added text highlighted):

    If the area element has an href attribute, then the area element represents a hyperlink. In this case, the alt attribute attribute must be present, present. It specifies the text. However, text of the hyperlink. Its value must be text that, when presented with the texts specified for the other hyperlinks of the image map, and with the alternative text of the image, but without the image itself, provides the user with the same kind of choice as the hyperlink would when used without its text but with its shape applied to the image. The alt attribute may be left blank if there is another area element in the same image map that points to the same resource and has a non-blank alt attribute.

Section 4.7.17, Dimension attributes # T

Refinements were made the text specifying handling related to the width and height attributes.

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.10.1, The script element # T

In this section, the following changes were made:

  • Instances of the phrase “script that will execute as soon as the parser resumes” were changed to pending external script.
  • A section of an algorithm that concerns the case when the loading of a script was successful, the following statement was added: The script document context of the script must be the Document object that owns the script element.

Section 4.10.3, The eventsource element # T

In this section, the following changes were made:

  • The element was renamed to eventsource (it had been “event-source” in previous drafts).
  • For consistency with the conformance requirements specified in the “URLs” section, extensive revisions were made to text that concerns handling of the value of the eventsource element’s src attribute.
  • The add declared event source and remove declared event source algorithms were added.

Section 4.11, Interactive elements # T

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

Section 4.11.4 [NEW], The bb element # T

This newly added section defines the bb element, which represents a user-agent command that the user can invoke and for which in some cases a user agent may display a browser button (a user-agent-defined icon or user-agent-defined text).

Section 4.11.6, Commands # T

This section concerns the command abstraction behind menu items, buttons, and links. In this section, the following changes were made:

  • A new “Using the bb element to define a command” subsection was added.

Section 5, Web browsers # T

This section, which applies most directly to Web browsers, defines features affecting environments that deal with multiple pages, links between pages, and running scripts.

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 6, User Interaction [formerly “Editing”] # T

This section describes various features that concern user interaction with content, including features that allow authors to enable users to interactively edit documents and parts of documents. During reorganization, several subsections were moved from other sections into this one, including the “The irrelevant attribute”, “Activation”, “Scrolling elements into view”, and “Focus” subsections.

Section 7, Communication # T

Applications written in HTML often require mechanisms to communicate with remote servers, as well mechanisms for applications from different domains running on the same client to communicate with each other. This section defines APIs for enabling those classes of communication; specifically, APIs for cross-document messaging, for server-sent events, for “Web Sockets” (for enabling Web applications to maintain bidirectional communications with their originating server), and for “channel messaging”.

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.4.1, Introduction # T

This newly titled subsection was formed from examples and their accompanying explanatory text from what had been the “Processing model” subsection in previous drafts.

Section 7.4.2, Security # T

This newly titled subsection was formed from a number of warnings that had been in the “Processing model” subsection in previous drafts.

Section 7.4.3, Posting text # T

This newly titled subsection was formed from what the what had been the core content “Processing model” subsection in previous drafts — that is, text specifying user-agent behavior for the postMessage(message, targetOrigin) form (“two argument” form) of the postMessage() method.

Section 7.4.4, Posting message ports # T

This newly added subsection specifies user-agent behavior for the postMessage(message, messagePort, targetOrigin) form (“three argument” form) of the postMessage() method.

Section 7.4.5, Posting structured data # T

This newly added section is currently a placeholder, with an editorial note about its intended purpose.

Section 7.5 [NEW], Channel messaging # T

This newly added section defines the MessageChannel and MessagePort interfaces.

Section 8, The HTML syntax # T

This section describes syntax rules for the text/html serialization of the HTML language, as well as rules for parsing and serializing it.

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 10, Things that you can't do with this specification… # T

This mostly non-normative section describes certain features that the specification, by design, does not address — because “a client-side markup language is not the right level for them, or because the features exist in other languages that can be integrated into” HTML. In this section, the following changes were made:

  • In the “Timers” subsection, the following statement was added: Objects that implement the Window interface must also implement the WindowTimers interface.

Acknowledgements # T

The following names were added to the list of names in the Acknowledgements:

Daniel Steinberg, David Smith, Eric Law, Felix Sasaki, Philip Jägenstedt, Ryan King

2008-06-10: Summary list of selected changes # T

This section provides a high-level list of selected changes in the 10 June 2008 working draft of the HTML 5 specification that were made after the 22 January 2008 First Public Working Draft. For more detailed descriptions of the changes, see the sections in this document that follow this one. (Note: The source for this summary is maintained in the HTML 5 differences from HTML 4 document [HTML4DIFFS]; the summary was copied from that document into this one.)

2008-06-10: Detailed list of changes # T

This section provides a per-section record of changes in the 10 June 2008 working draft of the HTML 5 specification that were made after the 22 January 2008 First Public Working Draft.

Section 1, Introduction # T

The “Introduction” section of the specification provides both non-normative (informative) background and context information on the specification, as well as normative information.

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, The Document Object Model # T

Conformance criteria of HTML implementations are defined in the specification in terms of operations on the Document Object Model (DOM). This section of the specification defines the language represented in the DOM, and forms a basis for the other parts of the specification.

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, Semantics and structure of HTML elements # T

This section defines the meanings and content models for each element in the HTML language, and includes both “authoring conformance” or “document conformance” requirements (to enable authors to produce conformant HTML documents) with “implementation conformance” or “user-agent conformance” requirements (to enable implementors to produce conformant HTML user agents).

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.7.3, The base element # T

In this section, the phrase “valid browsing context name” was emended to become valid browsing context name or keyword.

Section 3.7.5, The meta element # T

In this section, the following changes were made:

  • A statement was added that The charset attribute specifies the character encoding used by the document. This is called a character encoding declaration.
  • The text of the “Specifying the document’s character encoding” subsection was refined, with the following statements added:

    If the document contains a meta element with a charset attribute or a meta element in the Encoding declaration state, then the character encoding used must be an ASCII-compatible character encoding.

    An ASCII-compatible character encoding is one that is a superset of US-ASCII (specifically, ANSI_X3.4-1968) for bytes in the range 0x09 - 0x0D, 0x20, 0x21, 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A, and 0x61 - 0x7A.

  • The value dns was removed from the list of pre-defined values for the name attribute.
  • The value description was added to the list of pre-defined values for the name attribute, and defined as:

    The value must be a free-form string that describes the page. The value must be appropriate for use in a directory of pages, e.g. in a search engine.

  • The value application-name was added to the list of pre-defined values for the name attribute, and defined as:

    The value must be a short free-form string that giving the name of the Web application that the page represents. If the page is not a Web application, the application-name metadata name must not be used. User agents may use the application name in UI in preference to the page’s title, since the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.

  • The Content-Type keyword and corresponding Encoding declaration state added to a table that lists conformant keyword values for the http-equiv attribute and their corresponding states; also, a definition for the Encoding declaration state was added, and refinements were made in the “Specifying the document’s character encoding” subsection.
  • A part of the “Refresh state” algorithm was revised to refer to the document’s source browsing context.

Section 3.7.6, The style element # T

In this section, a refinement was made to the definition of the media attribute.

Section 3.8, Sections # T

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

Section 3.8.1, The body element # T

In this section, an interface definition was added for the DOM interface for the body element.

Section 3.8.3, The nav element # T

In this section, an example was added, along with the following statement:

Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a list of links to various key parts of a site, but the footer element is more appropriate in such cases.

Section 3.8.5 [now 3.9.6], The blockquote element # T

The section on the blockquote element was moved to become a subsection of the “Grouping content” elements section.

Section 3.8.6 [now 3.8.5], The aside element # T

In this section, two examples were added.

Section 3.8.8 [now 3.8.7], The header element # T

In this section, some wording refinements were made.

Section 3.8.10 [now 3.8.9], The address element # T

In this section, a statement was added that if an address element applies to the body element, then it instead applies to the document as a whole, and in several places, the phrase “sectioning element” was changed to sectioning content element.

Section 3.8.11 [now 3.8.10], Headings and sections # T

Several parts of this section were extensively re-written. Among some of the specific changes:

  • The term sectioning roots has been introduced and defined.
  • In the “Creating an outline” subsection, the following changes were made:
    • A numbered set of steps was added to define the outline algorithm.
    • Text was added to define a section as container that corresponds to some nodes in the original DOM tree which can have one heading associated with it and can contain any number of further nested sections.
    • An example and other details were added.
  • In the final subsection, the term “headers” was replaced by “headings”, including in the title, which now reads “Distinguishing site-wide headings from page headings”, and some refinements were made to the wording of the subsection.

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.9.4 [was 3.10.1], The pre element # T

This subsection was created when the previous section for the pre element was moved down in the sectioning hierarchy to become a subsection the “Grouping content” section. Also, the following note was added:

In the HTML serialisation, a leading newline character immediately following the pre element start tag is stripped.

Section 3.9.6 [was 3.8.5], The blockquote element # T

This subsection was created when the previous section for the blockquote element was moved out of the “Sections” section and into the “Grouping content” section. Also, some small refinements were made to the wording of the section.

Section 3.9.7 [was 3.11.1], The ol element # T

In this section, the following changes were made:

  • The reversed content attribute was added to the list of conformant attributes for the element, and the reversed DOM attribute was added to the interface definition for the HTMLOListElement interface.
  • Conformance criteria for the reversed content attribute and reversed DOM attribute were added.
  • A statement defining the meaning of the element, which had read, “The ol element represents an ordered list of items (which are represented by li elements)“, was revised to read, The ol element represents a list of items, where the items have been intentionally ordered, such that changing the order would change the meaning of the document.
  • The following statements were added: The reversed attribute is a boolean attribute. If present, it indicates that the list is a descending list (..., 3, 2, 1). If the attribute is omitted, the list is an ascending list (1, 2, 3, ...).
  • Conformance statements relevant to the reversed content attribute and reversed DOM attribute were updated or added where needed throughout the text.
  • Two examples were added.

Section 3.9.8 [was 3.11.2], The ul element # T

In this section, the definition of the meaning of the ul element, which had read, “The ul element represents an unordered list of items” was changed to read, The ul element represents a list of items, where the order of the items is not important — that is, where changing the order would not materially change the meaning of the document, and two examples were added.

Section 3.9.9 [was 3.11.3], The li element # T

In this section, two examples were added.

Section 3.9.10 [was 3.11.4], The dl element # T

In this section, the following changes were made:

  • a sentence in the definition of the meaning of the dl element was slightly modified to remove the criterion that it introduces an “unordered association list”, such that the sentences now reads, The dl element introduces an association list consisting of zero or more name-value groups (a description list).
  • Significant refinements and additions were made to the language in the section.
  • The set of examples was expanded.

Section 3.9.11 [was 3.11.5], The dt element # T

In this section, the following statement was added:

If the dt element is the child of a dialog element, and it further contains a time element, then that time element represents a timestamp for when the associated discourse (dd element) was said, and is not part of the name of the talker.

Also, two examples were added.

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.10.1, The a element # T

In this section, the interface definition for the HTMLAnchorElement interface was updated for consistency with the Web IDL specification [WebIDL].

Section 3.10.2, The q element # T

In this section, some wording changes were made, four examples were added, and the following statement was added:

Quotation punctuation (such as quotation marks), if any, must be placed inside the q element.

Section 3.10.3, The cite element # T

In this section, more examples were added, and the text defining the meaning of the cite element, which had read simply, “The cite element represents a citation: the source, or reference, for a quote or statement made in the document”, was expanded to read:

The cite element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, etc). This can be a work that is being quoted or referenced in detail (i.e. a citation), or it can just be a work that is mentioned in passing.

A person’s name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people’s names. (In some cases, the b element might be appropriate for names; e.g. in a gossip article where the names of famous people are keywords rendered with a different style to draw attention to them. In other cases, if an element is really needed, the span element can be used.)

A ship is similarly not a work, and the element must not be used to mark up ship names (the i element can be used for that purpose).

Section 3.10.7, The mark element [was: the m element] # T

The m element was renamed mark; in this section, the set of examples was significantly enlarged, and the text defining the meaning of the element, which had read simply, “The m element represents a run of text marked or highlighted”, was expanded to read:

The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. When used in a quotation or other block of text referred to from the prose, it indicates a highlight that was not originally present but which has been added to bring the reader’s attention to a part of the text that might not have been considered important by the original author when the block was originally written, but which is now under previously unexpected scrutiny. When used in the main prose of a document, it indicates a part of the document that has been highlighted due to its likely relevance to the user’s current activity.

Section 3.10.8, The dfn element # T

The text defining the dfn elements has changed significantly. The changes include:

  • The most significant change is that text describing a mechanism by which the dfn element could be used to enable automatic cross-references has been removed completely, and replaced by a statement that An a element that links to a dfn element represents an instance of the term defined by the dfn element.
  • Text that had previously read, “The paragraph, description list group, or section that contains the dfn element contains the definition for the term given by the contents of the dfn element” now reads (change highlighted): The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element.
  • The following conformance requirement was removed completely: “There must only be one dfn element per document for each term defined (i.e. there must not be any duplicate terms).”
  • An additional example was added to illustrate use of the a element in conjunction with the dfn element (to make an explicit cross-reference to a defining instance of a particular term).

Section 3.10.9, The abbr element # T

Refinements and changes were made to the text in this section; the changes include:

  • The text defining the meaning of the abbr element was refined to now read (changes highlighted): The abbr element represents an abbreviation or acronym, optionally with its expansion. The title attribute may be used to provide an expansion of the abbreviation. The attribute, if specified, must only contain an expansion of the abbreviation, and nothing else.
  • The following statement was removed completely: “The title attribute may be omitted if there is a dfn element in the document whose defining term is the abbreviation (the textContent of the abbr element).”
  • The following authoring-conformance requirement was added: If an abbreviation is pluralised, the expansion’s grammatical number (plural vs singular) must match the grammatical number of the contents of the element.
  • The set of examples was expanded and includes the addition of an example prefaced by the following text: This paragraph marks up an abbreviation without giving an expansion, possibly as a hook to apply styles for abbreviations (e.g. smallcaps).

Section 3.10.11, The progress element # T

In this section, a conformance statement was updated to read: If the progress bar is an indeterminate progress bar, then the position DOM attribute must return -1. (The statement had previously indicated that is should return 1.) Also, the following note was added: The progress element is the wrong element to use for something that is just a gauge, as opposed to task progress. For instance, indicating disk space usage using progress would be inappropriate. Instead, the meter element is available for such use cases.

Section 3.10.12, The meter element # T

In this section, the following changes were made:

  • In the interface definition for the HTMLMeterElement interface, the data type for all attributes was changed from long to float.
  • A statement providing authoring requirements was changed to now read (change highlighted): The recommended way of giving the value is to include it as contents of the element, either as two numbers (the higher number represents the maximum, the other number the current value, and the minimum is assumed to be zero), or as a percentage or similar (using one of the characters such as “%”), or as a fraction.
  • A statement regarding the conformant values for the attributes on the meter was added; it states that “their values must satisfy the following inequalities”:
    • min ≤ value ≤ max
    • min ≤ low ≤ high ≤ max
    • min ≤ optimum ≤ max

Section 3.10.13, The code element # T

In this section, the following statement was removed completely: “the title attribute has special semantics on this element when used with the dfn element”, and another example was added.

Section 3.10.14, The var element # T

In this section, the following statement was removed completely: “the title attribute has special semantics on this element when used with the dfn element”.

Section 3.10.15, The samp element # T

In this section, the following statement was removed completely: “the title attribute has special semantics on this element when used with the dfn element”.

Section 3.10.17, The sub and sup elements # T

In this section, the following note was added: Authors are encouraged to use MathML for marking up mathematics, but authors may opt to use sub and sup if detailed mathematical markup is not desired.

Section 3.10.18, The span element # T

In this section, the following statement was removed completely: “the title attribute has special semantics on this element when used with the dfn element”; also removed was a statement that the span element can be useful “when used in conjunction with the dfn element”.

Section 3.10.19, The i element # T

In this section, the following changes were made:

  • A statement was removed completely: “the title attribute has special semantics on this element when used with the dfn element”.
  • A refinement was made to one of the examples.
  • The following note was added:

    Authors are encouraged to use the class attribute on the i element to identify why the element is being used, so that if the style of a particular use (e.g. dream sequences as opposed to taxonomic terms) is to be changed at a later date, the author doesn’t have to go through the entire document (or series of related documents) annotating each use.

Section 3.10.22 [new], The ruby element # T

This section is newly added. It concerns the ruby element, which allows more spans of content to be marked up with ruby annotations (sometimes used, for example, with East Asian characters to provide “readings” or pronunciations for the characters).

Section 3.10.23 [new], The rt element # T

This section is newly added. It concerns the rt element, which is used to mark up the “text component” of a ruby annotation.

Section 3.10.24 [new], The rp element # T

This section is newly added. It concerns the rp element, which can be used to provide parentheses around a ruby “text component” of a ruby annotation, to be shown by user agents that don’t support ruby annotations.

Section 3.10.25 [new], Usage summary # T

This section is newly added. It is a placeholder with an editorial note that reads, “We need to summarise the various elements, in particular to distinguish b/i/em/strong/var/q/mark/cite.”

Section 3.10.26 [new], Footnotes # T

This section is newly added. The introduction to the section states, ”HTML does not have a dedicated mechanism for marking up footnotes. Here are the recommended alternatives”, and the section includes descriptions and examples of use of the title attribute, a element, and the aside element in marking up footnote content.

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.11.4 [new], Edits and paragraphs # T

This subsection was created by moving a large note out of the introduction to its parent section, “Edits”. The content of this subsection provides information and examples illustrating the difficulties of attempting to mark up edits that cross implied paragraphs).

Section 3.11.5 [new], Edits and lists # T

This section, which is newly added, relates to use of the ins and del elements with list items. The text provides both examples and authoring-conformance requirements, and begins with the following statement: The content models of the ol and ul elements do not allow ins and del elements as children. Lists always represent all their items, including items that would otherwise have been marked as deleted.

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.12.1, The figure element # T

In this section, the following changes were made:

  • The category “sectioning root” was added to the list of categories to which the figure element belongs.
  • The content model for the element was changed to make the legend element optional as a child of figure (instead of being a required child), and the first statement in the prose description of the element was updated to read, “The figure element represents some flow content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document’s meaning.
  • The following statement was added:

    The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

  • Several examples were added.

Section 3.12.2, The img element # T

In this section, the following changes were made:

  • The title of a subsection that discusses specific use cases from the element was changed from “A key part of the content that doesn’t have an obvious textual alternative” to simply, “A key part of the content”. The text of that same subsection was changed to now read:

    In some cases, the image is a critical part of the content. This could be the case, for instance, on a page that is part of a photo gallery. The image is the whole point of the page containing it.

    When it is possible for alternative text to be provided, for example if the image is part of a series of screenshots in a magazine review, or part of a comic strip, or is a photograph in a blog entry about that photograph, text that conveys can serve as a substitute for the image must be given as the contents of the alt attribute.

    In a rare subset of these cases, there might be no alternative text available. This could be the case, for instance, on a photo upload site, if the site has received 8000 photos from a user without the user annotating any of them. In such cases, the alt attribute may be omitted, but the alt attribute should be included, with a useful value, if at all possible.

    In any case, if an image is a key part of the content, the alt attribute must not be specified with an empty value.

  • The alt text for the “Screenshot of a KDE desktop” example was expanded.
  • The prefatory text for one of the examples was updated to read: A photo on a photo-sharing site, if the site received the image with no metadata other than the caption.
  • A portion of a note that had read, “the alt attribute should only be omitted when no alternative text is available and none can be made available, e.g. on automated image gallery sites” was revised to now read (change portion highlighted), the alt attribute is only allowed to be omitted when no alternative text is available and none can be made available, e.g. on automated image gallery sites.
  • A statement that had read, “Once the download has completed, if the image is a valid image, the user agent must fire a load event on the img element” was emended to read (added text highlighted), Once the download has completed, if the image is a valid image, the user agent must fire a load event on the img element (this happens after complete starts returning true).
  • A note was added with the following text: The value of complete can change while a script is executing.
  • Some additional examples were added, prefaced by the following text:

    A single image can have different appropriate alternative text depending on the context.

    In each of the following cases, the same image is used, yet the alt text is different each time.

Section 3.12.3, The iframe element # T

Very substantial changes were made in this section to introduce the following:

  • An iframe name, a valid browsing context name associated with the iframe.
  • An iframe sandbox, which enables a set of extra restrictions on any content hosted by the iframe.
  • An iframe seamless flag, which indicates that the iframe element’s browsing context is to be rendered in a manner that makes it appear to be part of the containing document (seamlessly included in the parent document).

A number of specific changes were made to introduce the above — among them, the following:

  • The name, sandbox, seamless, width, and height content attributes were added to the list of conformant attributes for the element, and the name, sandbox, seamless, width, and height DOM attributes were added to the interface definition for the HTMLIFrameElement interface.
  • Conformance criteria for the name, sandbox, seamless, width, and height content attributes and name, sandbox, seamless, width, and height DOM attribute were added.
  • Extensive text related to the name, sandbox, and seamless attributes was added.

Section 3.12.4, The embed element # T

In this section, the following changes were made:

  • Conformance criteria were added in relation to behavior when the sandboxed plugins browsing context flag is set.
  • In a number of places in the section, the word “handler” was replaced by the word plugin.
  • Two statements related to plugins were revised and moved out of this section and into the “Terminology” section.

Section 3.12.5, The object element # T

In this section, the following changes were made:

  • The name content attribute was added to the list of conformant attributes for the element, and the name DOM attribute was added to the interface definition for the HTMLObjectElement interface.
  • Conformance criteria for the name content attribute and name DOM attribute were added.
  • In a number of places in the section, the word “handler” was replaced by the word plugin.
  • The phrase “third-party software package” was replaced with the term plugin.
  • Some specific statements were added in relation to the case when plugins aren’t being sandboxed and the case when the sandboxed plugins browsing context flag is set.
  • The following statement was added:

    Whenever the name attribute is set, if the object element has a nested browsing context, its name must be changed to the new value. If the attribute is removed, if the object element has a browsing context, the browsing context name must be set to the empty string.

  • Significant revisions and additions were made to the algorithm for checking what the object element represents, including a step for checking for the presence of the classid attribute and acting on its value, and changes to the requirements for the case where the data attribute is present.
  • The following note was added:

    The object element can, in certain cases as described above, instantiate third-party handlers. This specification does not define a mechanism for interacting with third-party handlers, as it is expected to be user-agent-specific. Some UAs might opt to support a plugin mechanism such as the Netscape Plugin API; others may use remote content convertors or have built-in support for certain types.

  • Two examples were added.

Section 3.12.6, The param element # T

In this section, an instance of the term “handlers” was replaced by the term plugins.

Section 3.12.7, The video element # T

In this section, the following changes were made:

  • Revisions were made to conformance requirements related to the case where the video element is paused.
  • In a section of the text that concerns where video content is rendered inside the element’s playback area, the term “aspect ratio” was changed to adjusted aspect ratio, and a statement was added to say, The adjusted aspect ratio of a video is the ratio of its adjusted width to its intrinsic height. The adjusted width of a video is its intrinsic width multiplied by its pixel ratio.
  • The following editorial note was added: “The spec does not currently define the interaction of the “controls” attribute with the “height” and “width” attributes. This will likely be defined in the rendering section based on implementation experience. So far, browsers seem to be making the controls overlay-only, thus somewhat sidestepping the issue.”

Section 3.12.9, The source element # T

In this section, the following changes were made:

  • The pixelratio content attribute was added to the list of conformant attributes for the element, and the pixelratio DOM attribute was added to the interface definition for the HTMLSourceElement interface.
  • Conformance criteria for the pixelratio content attribute and pixelratio DOM attribute were added, including the following statement:

    The pixelratio attribute allows the author to specify the pixel ratio of anamorphic media resources that do not self-describe their pixel ratio. The attribute value, if specified, must be a valid floating point number giving the ratio of the correct rendered width of each pixel to the actual width of each pixel in the image (i.e., the multiple by which the video’s intrinsic width is to be multiplied to obtain the rendered width that gives the correct aspect ratio). The default value, if the attribute is omitted or cannot be parsed, is 1.0.

Section 3.12.10, media elements # T

in this section, the following changes were made:

  • The bufferingThrottled, bufferedBytes, and totalBytes attributes were added to the interface definition for the HTMLMediaElement interface.
  • Conformance criteria for the bufferingThrottled, bufferedBytes, and totalBytes DOM attributes were added.
  • The algorithm for picking a media resource for a media element was revised to include checking for the presence and value of the pixelratio attribute.
  • In the algorithm that runs when the load() method on a media element is invoked, a step that had read, “The user agent must then set the begun flag to true and fire a progress event called begin at the media element” was revised to read (change highlighted), The user agent must then set the begun flag to true and fire a progress event called loadstart at the media element.
  • A part of the of the seeking algorithm was revised, and conformance statement that concerns determining when to fire the waiting event at a media element was revised to incorporate the case of the seeking algorithm being invoked
  • The algorithm for responding to the invocation of the play() method was revised.
  • Language that stated conformance requirements for ECMAScript implementations in relation to the VoidCallback interface was removed.
  • In the “User interface” subsection, an instance of the phrase “if scripting is disabled” was changed to read, “if the media element is without script”.
  • A small revision was made to a statement in the “Time ranges” subsection.
  • A new “Byte ranges” subsection was added. It defines the ByteRanges interface and related conformance requirements.
  • In the table of events in the “Event summary” subsection, the event that had been named begin was re-named to loadstart, and entries in the table were added for the seeking and seeked events.

Section 3.12.11, The canvas element # T

In this section, the following changes were made:

  • The following statements were added:

    Arguments other than the contextId must be ignored, and must not cause the user agent to raise an exception (as would normally occur if a method was called with the wrong number of arguments).

    If the canvas has no pixels (i.e. either its horizontal dimension or its vertical dimension is zero) then the method must return the string “data:,”. (This is the shortest data: URI; it represents the empty string in a text/plain resource.)

  • Some instances of the phrase “with scripting enabled” and “with scripting disabled” were changed to refer instead to the states with script and without script.
  • A note concerning the case of trying to use the toDataURL() method with image types other than PNG was emended to read (added text highlighted):

    When trying to use types other than image/png, authors can check if the image was really returned in the requested format by checking to see if the returned string starts with one the exact strings “data:image/png,” or “data:image/png;”. If it does, the image is PNG, and thus the requested type was not supported. (The one exception to this is if the canvas has either no height or no width, in which case the result might simply be “data:,”.)

  • A statement regarding preventing information leakage from the toDataURL() and getImageData() methods was moved to become part of a newly added “Security with canvas elements” subsection.

Section 3.12.11.1, The 2D context # T

This section provides an extensive immediate-mode graphics API for use with the canvas element. In this section, the following changes were made:

  • In the interface definition for the CanvasRenderingContext2D interface, the following DOM attributes were added:
    • font
    • textAlign
    • textBaseline
    Also, the following methods were added:
    • fillText
    • strokeText
    • measureText
    • createImageData
    In addition, the TextMetrics interface was added.
  • A number of significant refinements were made to existing text throughout various subsections.
  • A new and extensive “Text” subsection was added. It concerns rendering of text to a canvas.
  • A new “Security with canvas elements” subsection was added. It begins with the following statement:

    Information leakage can occur if scripts from one origin are exposed to images from another origin (one that isn’t the same).

    To mitigate this, canvas elements are defined to have a flag indicating whether they are origin-clean. All canvas elements must start with their origin-clean set to true.

    It then lists a specific set actions, each of which must cause the origin-clean flag to be set to false. In addition, it includes the following statements:

    Whenever the toDataURL() method of a canvas element whose origin-clean flag is set to false is called, the method must immediately raise a security exception.

    Whenever the getImageData() method of the 2D context of a canvas element whose origin-clean flag is set to false is called, the method must immediately raise a security exception.

Section 3.12.12, The map element # T

In this section, the following changes were made:

  • The content model for the element was changed to add as an element-specific attribute the name attribute, which “gives the map a name so that it can be referenced”.
  • The name DOM attribute was added to the interface definition for the HTMLMapElement interface.

Section 3.12.13, The area element # T

In this section, the following statement was added: “The DOM attribute shape must reflect the shape content attribute, limited to only known values.”

Section 3.12.14, Image maps # T

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

Section 3.12.15 [new], MathML # T

This short section is newly added. It reads in whole:

The math element from the MathML namespace falls into the embedded content category for the purposes of the content models in this specification.

User agents must handle text other than inter-element whitespace found in MathML elements whose content models do not allow raw text by pretending for the purposes of MathML content models, layout, and rendering that that text is actually wrapped in an mtext element in the MathML namespace. (Such text is not, however, conforming.)

User agents must act as if any MathML element whose contents does not match the element’s content model was replaced, for the purposes of MathML layout and rendering, by an merror element in the MathML namespace containing some appropiate error message.

To enable authors to use MathML tools that only accept MathML in its XML form, interactive HTML user agents are encouraged to provide a way to export any MathML fragment as a namespace-well-formed XML fragment.

Section 3.12.16 [new], SVG # T

This short section is newly added. It reads in whole:

The svg element from the SVG namespace falls into the embedded content category for the purposes of the content models in this specification.

To enable authors to use SVG tools that only accept SVG in its XML form, interactive HTML user agents are encouraged to provide a way to export any SVG fragment as a namespace-well-formed XML fragment.

Section 3.13 [was 3.15], Tabular data # T

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

Section 3.13.2, The table element # T

In this section, the following changes were made:

  • The createTBody() method was added to the interface definition for the HTMLTableElement interface.
  • Following a statement of the conformance requirement that a table element must have “Zero or more tbody elements, or One or more tr elements”, the following note was added: (Only expressible in the XML serialization.)
  • A statement giving conformance requirements for the caption DOM attribute was emended to read (added text highlighted), The caption DOM attribute must return, on getting, the first caption element child of the table element, if any, or null otherwise.
  • A statement giving conformance requirements for the tHead DOM attribute was emended to read (added text highlighted), The tHead DOM attribute must return, on getting, the first thead element child of the table element, if any, or null otherwise.
  • A statement giving conformance requirements for the tFoot DOM attribute was emended to read (added text highlighted), The tFoot DOM attribute must return, on getting, the first tfoot element child of the table element, if any, or null otherwise.
  • The following new statement was added: The createTBody() method must create a new tbody element, insert it immediately after the last tbody element in the table element, if any, or at the end of the table element if the table element has no tbody element children, and then must return the new tbody element.
  • The algorithm that must run when the deleteRow() method is called was revised.

Section 3.13.4, The colgroup element # T

In this section, the following changes were made:

  • The following statement that concerns requirements for the span attribute on the colgroup element was removed completely: “Its default value, which must be used if parsing the attribute as a non-negative integer returns either an error or zero, is 1.”
  • A statement that concerns requirements for the span DOM attribute was revised to now read, The span DOM attribute must reflect the content attribute of the same name. The value must be limited to only positive non-zero numbers. (it had previously stated, “on setting, if the new value is 0, then an INDEX_SIZE_ERR exception must be raised”.

Section 3.13.5, The col element # T

In this section, the following changes were made:

  • The following statement that concerns requirements for the span attribute on the col element was removed completely: “Its default value, which must be used if parsing the attribute as a non-negative integer returns either an error or zero, is 1.”
  • A statement that concerns requirements for the span DOM attribute was revised to now read, The span DOM attribute must reflect the content attribute of the same name. The value must be limited to only positive non-zero numbers. (it had previously stated, “on setting, if the new value is 0, then an INDEX_SIZE_ERR exception must be raised”.

Section 3.13.6, The tbody element # T

In this section, the following changes were made:

  • The content model for the element was changed to require Zero or more tr elements. (It had previously required “One or more tr elements”.)

Section 3.13.7, The thead element # T

In this section, the following changes were made:

  • The content model for the element was changed to require Zero or more tr elements. (It had previously required “One or more tr elements”.)

Section 3.13.8, The tfoot element # T

In this section, the following changes were made:

  • The content model for the element was changed to require Zero or more tr elements. (It had previously required “One or more tr elements”.)

Section 3.13.9, The tr element # T

In this section, the following changes were made:

  • The content model for the element was changed to require Zero or more td or th elements (It had previously required “One or more tr elements”.)
  • In a statement that gives conformance requirements for the rowIndex DOM attribute, for the case where no table exists that meets particular criteria, the text was changed to state that the attribute must return -1. (It had stated that it must return 0.)
  • In a statement that gives conformance requirements for the sectionRowIndex DOM attribute, for the case where no parent element exists that meets particular criteria, the text was changed to state that the attribute must return -1. (It had stated that it must return 0.)

Section 3.13.10, The td element # T

In this section, the following changes were made:

  • The category to which the td element belongs was changed from “None” to sectioning root.
  • The interface that corresponds to the element was renamed from “HTMLTableCellElement” to HTMLTableDataCellElement.
  • The headers content attribute was added to the list of conformant attributes for the element, and the headers DOM attribute was added to the interface definition for the HTMLTableDataCellElement interface.
  • The colSpan and rowSpan DOM attributes were removed from the interface definition for the HTMLTableDataCellElement interface.
  • The text of the section was revised to remove references to the colSpan and rowSpan DOM attributes and to add references to the headers DOM attribute.

Section 3.13.11, The th element # T

In this section, the following changes were made:

  • The text of the section was revised to remove references to the colspan and rowSpan content attributes.

Section 3.13.12 [new], Attributes common to td and th elements # T

This section is newly added. It provides

  • an interface definition for the HTMLTableCellElement interface; the conformance requirements for the td and th elements now state that they implement interfaces that inherit from that interface
  • Conformance criteria for the colspan and rowSpan content attributes.
  • Conformance criteria for the colSpan, rowSpan, and cellIndex DOM attributes.

Section 3.13.13, Processing model # T

In this section, the following changes were made:

  • Changes were made in the introduction to this section to bring it in alignment with related change made in other parts of the specification.
  • A large number of substantive changes were made to the algorithms in the “Forming a table” subsection; among those changes were the addition of steps related to the tfoot and caption elements, as well as a number of other changes, including a reformulation and refinement of a part of the previous text to form an algorithm for growing downward-growing cells.

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.15.1, The script element # T

In this section, a number of significant changes were made made:

  • The charset content attribute was added to the list of conformant attributes for the element, and the charset DOM attribute was added to the interface definition for the HTMLScriptElement interface.
  • Conformance criteria for the charset content attribute and charset DOM attribute were added.
  • An part of conformance statement that read, “If scripting is disabled, or if the Document has designMode enabled” was revised to now read, “If the script element is without script“.
  • The text providing the conformance requirements for the script element and the algorithm for running scripts in script blocks within documents were revised extensively.

Section 3.15.2, The noscript element # T

In this section, the following changes were made:

  • The content model for the element was updated to change instances of the phrases “when scripting is disabled” and “when scripting is enabled” to instead use the terms “without script” and “with script”, and statements within the text of the section were revised to use those terms.
  • The following note was added: The noscript element is only effective in the HTML serialization, it has no effect in the XML serialization.
  • The following note was added: The noscript element interacts poorly with the designMode feature. Authors are encouraged to not use noscript elements on pages that will have designMode enabled.

Section 3.15.3, The event-source element # T

In this section, a statement regarding the src attribute was changed to now read (changed text highlighted), The src attribute, if specified, must give a URI (or IRI) pointing to a resource that uses the text/event-stream format. (The highlighted part had previously read, “application/x-dom-event-stream”.

Section 3.16 [was 3.18], Interactive elements # T

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

Section 3.16.2, The datagrid element # T

datagrid is a new element and feature introduced in HTML 5. It is an interactive representation of a tree, a list, or a set of tabular data. Support for the datagrid feature has not yet been implemented in any user agents.

In this section, the following changes were made:

  • The category “sectioning root” was added to the list of categories to which the datagrid element belongs.
  • Part of the content model for the element was emended to read (highlighting added), Flow content, but where the first element child node, if any, is not a table, select, or datalist element
  • The interface definition for the DataGridDataProvider interface was updated for consistency with the Web IDL specification [WebIDL].
  • In the “Requirements for interactive user agents” subsection, a statement that concerns invocation of a data provider’s setCellCheckedState() method was revised to read (change highlighted), “The state should be represented by the number 1 if the new state is checked, 0 if the new state is unchecked, and −1 if the new state is indeterminate.”
  • The interface definition for the DataGridSelection interface was updated for consistency with the Web IDL specification [WebIDL].

Section 3.16.5, Commands # T

This section concerns the command abstraction behind menu items, buttons, and links. In this section, the interface definition for the Command interface was updated for consistency with the Web IDL specification [WebIDL].

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, Web browsers # T

This section, which applies most directly to Web browsers, defines features affecting environments that deal with multiple pages, links between pages, and running scripts.

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.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, Editing # T

This section describes various features that allow authors to enable users to interactively edit documents and parts of documents.

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, Communication # T

Applications written in HTML often require mechanisms to communicate with remote servers, as well mechanisms for applications from different domains running on the same client to communicate with each other (so-called “cross-document messaging”). This section defines APIs for enabling those classes of communication; specifically, APIs for cross-document messaging, for server-sent DOM events, and for network connections — as well as providing the interface definitions for messages sent in cross-document messaging and server-sent DOM events.

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 7, Repetition templates # T

This section was an empty placeholder in the FPWD, and not additions were made to it, so it remains so. Its intended purpose is to define a mechanism to support repeating sections in forms.

Section 8, The HTML syntax # T

This section describes syntax rules for the text/html serialization of the HTML language, as well as rules for parsing and serializing it.

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.

Section 9 [now removed], WYSIWYG editors # T

The entire “WYSIWYG editors” section was removed from the specification. It had provided information that attempted to “allow a way for WYSIWYG editors, which aren’t going to use semantic markup, to still write conforming documents, while not letting it be ok for hand-coding authors to not use semantic markup”.

Section 10 [now section 9], Rendering and user-agent behavior # T

This section is intended to provide descriptions of expected user-agent rendering behavior as well as other user-agent behavior, but remains mostly just a placeholder at this point, with the plan being to complete the section later. In this section, the following changes were made:

  • The title of the section was changed from “Rendering” to “Rendering and user-agent behavior”.
  • Within this section, a new subsection was added, with the title “Obsolete elements, attributes, and APIs”. It contains descriptions of the obsoleted applet element and obsolete parts of DOM interface for the body element.

Section 11 [now section 10], Things that you can't do with this specification… # T

This mostly non-normative section describes certain features that the specification, by design, does not address — because “a client-side markup language is not the right level for them, or because the features exist in other languages that can be integrated into” HTML. In this section, the following changes were made:

  • In the “Timers” subsection, which is planned to be integrated into the Window Object specification, the following changes were made: For consistency with the Web IDL specification [WebIDL], the interface definition for the WindowTimers and TimeoutHandler interfaces were updated, and a paragraph was removed that stated conformance requirements for the handleEvent() method in the TimeoutHandler interface of the ECMAScript DOM binding.

Acknowledgements # T

The following names were added to the list of names in the Acknowledgements:

Adam Barth, Addison Phillips, Adele Peterson, Alastair Campbell, Anders Carlsson, Anthony Ricaud, Arphen Lin, Ashley Sheridan, Aurelien Levy, Ben Millard, Brian Smith, Bruce Miller, Cameron McCormack, Daniel Glazman, Danny Sullivan, Dave Camp, David Bloom, David Carlisle, Dean Edridge, Debi Orton, Evan Prodromou, Geoffrey Garen, Henry Mason, Hugh Winkler, Jacques Distler, James Justin Harrell, Jason White, Jens Fendler, Jjgod Jiang, Johan Herland, Jim Jewett, Jim Meehan, Joe Clark, Julian Reschke, Laura L. Carlson, Laura Wisewell, Lee Kowalkowski, Leif Halvard Silli, Magnus Kristiansen, Masataka Yakura, Michael Carter, Michael(tm) Smith, Neil Soiffer, Olaf Hoffmann, Oliver Hunt, Peter Karlsson, Philip TAYLOR, Ralf Stoltze, Raphael Champeimont, Rene Saarsoo, Richard Ishida, Steve Faulkner, Sunava Dutta, Terrence Wood, Tim Johansson, Wayne Pollock, Yi-An Huang

References # T

[HTML5FPWD]
HTML 5: A vocabulary and associated APIs for HTML and XHTML (First Public Working Draft), I. Hickson, D. Hyatt, editors. W3C, January 2008.
[HTML5]
HTML 5: A vocabulary and associated APIs for HTML and XHTML (current Working Draft), I. Hickson, D. Hyatt, editors. W3C, June 2008.
[HTML4DIFFS]
HTML 5 differences from HTML 4, A. van Kesteren, editor. W3C, June 2008.
[WebIDL]
Language Bindings for DOM Specifications, C. McCormack, editor. W3C, April 2008.