HTML 5

Abstract

This specification defines the 5th major revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability.

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 most recently formally published revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

If you wish to make comments regarding this document, please send them to public-html-comments@w3.org (subscribe, archives) or whatwg@whatwg.org (subscribe, archives). All feedback is welcome.

Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

The publication of this document by the W3C as a W3C Working Draft does not imply that all of the participants in the W3C HTML working group endorse the contents of the specification. Indeed, for any section of the specification, one can usually find many members of the working group or of the W3C as a whole who object strongly to the current text, the existence of the section at all, or the idea that the working group should even spend time discussing the concept of that section.

The latest stable version of the editor's draft of this specification is always available on the W3C CVS server and in the WHATWG Subversion repository. The latest editor's working copy (which may contain unfinished text in the process of being prepared) is available on the WHATWG site. Detailed change history can be obtained from the following locations:

• Twitter messages (non-editorial changes only): http://twitter.com/WHATWG
• Interactive Web interface: http://html5.org/tools/web-apps-tracker
• Commit-Watchers mailing list: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org
• Subversion interface: http://svn.whatwg.org/
• CVS log: http://dev.w3.org/cvsweb/html5/spec/Overview.html

The W3C HTML Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track. This specification is the 6 July 2008 Editor's Draft.

This specification is also being produced by the WHATWG. The two specifications are identical from the table of contents onwards.

This specification is intended to replace (be the new version of) what was previously the HTML4, XHTML 1.0, and DOM2 HTML specifications.

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.

Stability

Different parts of this specification are at different levels of maturity.

Some of the more major known issues are marked like this. There are many other issues that have been raised as well; the issues given in this document are not the only known issues! There are also some spec-wide issues that have not yet been addressed: case-sensitivity is a very poorly handled topic right now, and the firing of events needs to be unified (right now some bubble, some don't, they all use different text to fire events, etc). It would also be nice to unify the rules on downloading content when attributes change (e.g. src attributes) - should they initiate downloads when the element immediately, is inserted in the document, when active scripts end, etc. This matters e.g. if an attribute is set twice in a row (does it hit the network twice).

Table of contents

• 1. Introduction
  • 1.1 Background
  • 1.2 Scope
  • 1.3 Relationships to other specifications
    • 1.3.1 Relationship to HTML 4.01 and DOM2 HTML
    • 1.3.2 Relationship to XHTML 1.x
    • 1.3.3 Relationship to XHTML2
    • 1.3.4 Relationship to Web Forms 2.0 and XForms
    • 1.3.5 Relationship to XUL, Flash, Silverlight, and other proprietary UI languages
  • 1.4 HTML vs XHTML
  • 1.5 Structure of this specification
    • 1.5.1 How to read this specification
• 2. Common infrastructure
  • 2.1 Conformance requirements
    • 2.1.1 Dependencies
    • 2.1.2 Features defined in other specifications
    • 2.1.3 Common conformance requirements for APIs exposed to JavaScript
  • 2.2 Terminology
  • 2.3 URLs
    • 2.3.1 Terminology
    • 2.3.2 Parsing URLs
    • 2.3.3 Resolving URLs
    • 2.3.4 Dynamic changes to base URLs
    • 2.3.5 Interfaces for URL manipulation
  • 2.4 Common microsyntaxes
    • 2.4.1 Common parser idioms
    • 2.4.2 Boolean attributes
    • 2.4.3 Numbers
      • 2.4.3.1. Unsigned integers
      • 2.4.3.2. Signed integers
      • 2.4.3.3. Real numbers
      • 2.4.3.4. Ratios
      • 2.4.3.5. Percentages and dimensions
      • 2.4.3.6. Lists of integers
    • 2.4.4 Dates and times
      • 2.4.4.1. Specific moments in time
      • 2.4.4.2. Vaguer moments in time
    • 2.4.5 Time offsets
    • 2.4.6 Tokens
    • 2.4.7 Keywords and enumerated attributes
    • 2.4.8 References
  • 2.5 Common DOM interfaces
    • 2.5.1 Reflecting content attributes in DOM attributes
    • 2.5.2 Collections
      • 2.5.2.1. HTMLCollection
      • 2.5.2.2. HTMLFormControlsCollection
      • 2.5.2.3. HTMLOptionsCollection
    • 2.5.3 DOMTokenList
    • 2.5.4 DOMStringMap
    • 2.5.5 DOM feature strings
  • 2.6 Fetching resources
  • 2.7 Determining the type of a resource
    • 2.7.1 Content-Type metadata
    • 2.7.2 Content-Type sniffing: Web pages
    • 2.7.3 Content-Type sniffing: text or binary
    • 2.7.4 Content-Type sniffing: unknown type
    • 2.7.5 Content-Type sniffing: image
    • 2.7.6 Content-Type sniffing: feed or HTML
• 3. Semantics and structure of HTML documents
  • 3.1 Introduction
  • 3.2 Documents
    • 3.2.1 Documents in the DOM
    • 3.2.2 Security
    • 3.2.3 Resource metadata management
    • 3.2.4 DOM tree accessors
  • 3.3 Elements
    • 3.3.1 Semantics
    • 3.3.2 Elements in the DOM
    • 3.3.3 Global attributes
      • 3.3.3.1. The id attribute
      • 3.3.3.2. The title attribute
      • 3.3.3.3. The lang (HTML only) and xml:lang (XML only) attributes
      • 3.3.3.4. The xml:base attribute (XML only)
      • 3.3.3.5. The dir attribute
      • 3.3.3.6. The class attribute
      • 3.3.3.7. The style attribute
      • 3.3.3.8. Embedding custom non-visible data
  • 3.4 Content models
    • 3.4.1 Kinds of content
      • 3.4.1.1. Metadata content
      • 3.4.1.2. Flow content
      • 3.4.1.3. Sectioning content
      • 3.4.1.4. Heading content
      • 3.4.1.5. Phrasing content
      • 3.4.1.6. Embedded content
      • 3.4.1.7. Interactive content
    • 3.4.2 Transparent content models
  • 3.5 Paragraphs
  • 3.6 APIs in HTML documents
  • 3.7 Dynamic markup insertion
    • 3.7.1 Controlling the input stream
    • 3.7.2 Dynamic markup insertion in HTML
    • 3.7.3 Dynamic markup insertion in XML
• 4. The elements of HTML
  • 4.1 The root element
    • 4.1.1 The html element
  • 4.2 Document metadata
    • 4.2.1 The head element
    • 4.2.2 The title element
    • 4.2.3 The base element
    • 4.2.4 The link element
    • 4.2.5 The meta element
      • 4.2.5.1. Standard metadata names
      • 4.2.5.2. Other metadata names
      • 4.2.5.3. Pragma directives
      • 4.2.5.4. Specifying the document's character encoding
    • 4.2.6 The style element
    • 4.2.7 Styling
  • 4.3 Sections
    • 4.3.1 The body element
    • 4.3.2 The section element
    • 4.3.3 The nav element
    • 4.3.4 The article element
    • 4.3.5 The aside element
    • 4.3.6 The h1, h2, h3, h4, h5, and h6 elements
    • 4.3.7 The header element
    • 4.3.8 The footer element
    • 4.3.9 The address element
    • 4.3.10 Headings and sections
      • 4.3.10.1. Creating an outline
      • 4.3.10.2. Distinguishing site-wide headings from page headings
  • 4.4 Grouping content
    • 4.4.1 The p element
    • 4.4.2 The hr element
    • 4.4.3 The br element
    • 4.4.4 The pre element
    • 4.4.5 The dialog element
    • 4.4.6 The blockquote element
    • 4.4.7 The ol element
    • 4.4.8 The ul element
    • 4.4.9 The li element
    • 4.4.10 The dl element
    • 4.4.11 The dt element
    • 4.4.12 The dd element
  • 4.5 Text-level semantics
    • 4.5.1 The a element
    • 4.5.2 The q element
    • 4.5.3 The cite element
    • 4.5.4 The em element
    • 4.5.5 The strong element
    • 4.5.6 The small element
    • 4.5.7 The mark element
    • 4.5.8 The dfn element
    • 4.5.9 The abbr element
    • 4.5.10 The time element
    • 4.5.11 The progress element
    • 4.5.12 The meter element
    • 4.5.13 The code element
    • 4.5.14 The var element
    • 4.5.15 The samp element
    • 4.5.16 The kbd element
    • 4.5.17 The sub and sup elements
    • 4.5.18 The span element
    • 4.5.19 The i element
    • 4.5.20 The b element
    • 4.5.21 The bdo element
    • 4.5.22 The ruby element
    • 4.5.23 The rt element
    • 4.5.24 The rp element
    • 4.5.25 Usage summary
    • 4.5.26 Footnotes
  • 4.6 Edits
    • 4.6.1 The ins element
    • 4.6.2 The del element
    • 4.6.3 Attributes common to ins and del elements
    • 4.6.4 Edits and paragraphs
    • 4.6.5 Edits and lists
  • 4.7 Embedded content
    • 4.7.1 The figure element
    • 4.7.2 The img element
    • 4.7.3 The iframe element
    • 4.7.4 The embed element
    • 4.7.5 The object element
    • 4.7.6 The param element
    • 4.7.7 The video element
      • 4.7.7.1. Video and audio codecs for video elements
    • 4.7.8 The audio element
      • 4.7.8.1. Audio codecs for audio elements
    • 4.7.9 The source element
    • 4.7.10 Media elements
      • 4.7.10.1. Error codes
      • 4.7.10.2. Location of the media resource
      • 4.7.10.3. Network states
      • 4.7.10.4. Loading the media resource
      • 4.7.10.5. Offsets into the media resource
      • 4.7.10.6. The ready states
      • 4.7.10.7. Playing the media resource
      • 4.7.10.8. Seeking
      • 4.7.10.9. Cue ranges
      • 4.7.10.10. User interface
      • 4.7.10.11. Time ranges
      • 4.7.10.12. Byte ranges
      • 4.7.10.13. Event summary
      • 4.7.10.14. Security and privacy considerations
    • 4.7.11 The canvas element
      • 4.7.11.1. The 2D context
        • 4.7.11.1.1. The canvas state
        • 4.7.11.1.2. Transformations
        • 4.7.11.1.3. Compositing
        • 4.7.11.1.4. Colors and styles
        • 4.7.11.1.5. Line styles
        • 4.7.11.1.6. Shadows
        • 4.7.11.1.7. Simple shapes (rectangles)
        • 4.7.11.1.8. Complex shapes (paths)
        • 4.7.11.1.9. Text
        • 4.7.11.1.10. Images
        • 4.7.11.1.11. Pixel manipulation
        • 4.7.11.1.12. Drawing model
      • 4.7.11.2. Color spaces and color correction
      • 4.7.11.3. Security with canvas elements
    • 4.7.12 The map element
    • 4.7.13 The area element
    • 4.7.14 Image maps
    • 4.7.15 MathML
    • 4.7.16 SVG
    • 4.7.17 Dimension attributes
  • 4.8 Tabular data
    • 4.8.1 Introduction
    • 4.8.2 The table element
    • 4.8.3 The caption element
    • 4.8.4 The colgroup element
    • 4.8.5 The col element
    • 4.8.6 The tbody element
    • 4.8.7 The thead element
    • 4.8.8 The tfoot element
    • 4.8.9 The tr element
    • 4.8.10 The td element
    • 4.8.11 The th element
    • 4.8.12 Attributes common to td and th elements
    • 4.8.13 Processing model
      • 4.8.13.1. Forming a table
      • 4.8.13.2. Forming relationships between data cells and header cells
  • 4.9 Forms
    • 4.9.1 The form element
    • 4.9.2 The fieldset element
    • 4.9.3 The input element
    • 4.9.4 The button element
    • 4.9.5 The label element
    • 4.9.6 The select element
    • 4.9.7 The datalist element
    • 4.9.8 The optgroup element
    • 4.9.9 The option element
    • 4.9.10 The textarea element
    • 4.9.11 The output element
    • 4.9.12 Processing model
      • 4.9.12.1. Form submission
  • 4.10 Scripting
    • 4.10.1 The script element
      • 4.10.1.1. Scripting languages
    • 4.10.2 The noscript element
    • 4.10.3 The event-source element
  • 4.11 Interactive elements
    • 4.11.1 The details element
    • 4.11.2 The datagrid element
      • 4.11.2.1. The datagrid data model
      • 4.11.2.2. How rows are identified
      • 4.11.2.3. The data provider interface
      • 4.11.2.4. The default data provider
        • 4.11.2.4.1. Common default data provider method definitions for cells
      • 4.11.2.5. Populating the datagrid element
      • 4.11.2.6. Updating the datagrid
      • 4.11.2.7. Requirements for interactive user agents
      • 4.11.2.8. The selection
      • 4.11.2.9. Columns and captions
    • 4.11.3 The command element
    • 4.11.4 The menu element
      • 4.11.4.1. Introduction
      • 4.11.4.2. Building menus and tool bars
      • 4.11.4.3. Context menus
      • 4.11.4.4. Toolbars
    • 4.11.5 Commands
      • 4.11.5.1. Using the a element to define a command
      • 4.11.5.2. Using the button element to define a command
      • 4.11.5.3. Using the input element to define a command
      • 4.11.5.4. Using the option element to define a command
      • 4.11.5.5. Using the command element to define a command
  • 4.12 Data Templates
    • 4.12.1 Introduction
    • 4.12.2 The datatemplate element
    • 4.12.3 The rule element
    • 4.12.4 The nest element
    • 4.12.5 Global attributes for data templates
    • 4.12.6 Processing model
      • 4.12.6.1. The originalContent DOM attribute
      • 4.12.6.2. The template attribute
      • 4.12.6.3. The ref attribute
      • 4.12.6.4. The NodeDataTemplate interface
      • 4.12.6.5. Mutations
      • 4.12.6.6. Updating the generated content
  • 4.13 Miscellaneous elements
    • 4.13.1 The legend element
    • 4.13.2 The div element
• 5. Web browsers
  • 5.1 Browsing contexts
    • 5.1.1 Nested browsing contexts
    • 5.1.2 Auxiliary browsing contexts
    • 5.1.3 Secondary browsing contexts
    • 5.1.4 Security
    • 5.1.5 Threads
    • 5.1.6 Browsing context names
  • 5.2 The default view
    • 5.2.1 Security
    • 5.2.2 Constructors
    • 5.2.3 APIs for creating and navigating browsing contexts by name
    • 5.2.4 Accessing other browsing contexts
  • 5.3 Origin
    • 5.3.1 Relaxing the same-origin restriction
  • 5.4 Scripting
    • 5.4.1 Script execution contexts
    • 5.4.2 Security exceptions
    • 5.4.3 The javascript: protocol
    • 5.4.4 Events
      • 5.4.4.1. Event handler attributes
      • 5.4.4.2. Event firing
      • 5.4.4.3. Events and the Window object
      • 5.4.4.4. Runtime script errors
  • 5.5 User prompts
    • 5.5.1 Simple dialogs
    • 5.5.2 Printing
    • 5.5.3 Dialogs implemented using separate documents
    • 5.5.4 Notifications
  • 5.6 Browser state
    • 5.6.1 Custom protocol and content handlers
      • 5.6.1.1. Security and privacy
      • 5.6.1.2. Sample user interface
  • 5.7 Offline Web applications
    • 5.7.1 Introduction
    • 5.7.2 Application caches
    • 5.7.3 The cache manifest syntax
      • 5.7.3.1. Writing cache manifests
      • 5.7.3.2. Parsing cache manifests
    • 5.7.4 Updating an application cache
    • 5.7.5 Processing model
      • 5.7.5.1. Changes to the networking model
    • 5.7.6 Application cache API
    • 5.7.7 Browser state
  • 5.8 Session history and navigation
    • 5.8.1 The session history of browsing contexts
    • 5.8.2 The History interface
    • 5.8.3 Activating state object entries
    • 5.8.4 The Location interface
      • 5.8.4.1. Security
    • 5.8.5 Implementation notes for session history
  • 5.9 Browsing the Web
    • 5.9.1 Navigating across documents
    • 5.9.2 Page load processing model for HTML files
    • 5.9.3 Page load processing model for XML files
    • 5.9.4 Page load processing model for text files
    • 5.9.5 Page load processing model for images
    • 5.9.6 Page load processing model for content that uses plugins
    • 5.9.7 Page load processing model for inline content that doesn't have a DOM
    • 5.9.8 Navigating to a fragment identifier
    • 5.9.9 History traversal
  • 5.10 Structured client-side storage
    • 5.10.1 Storing name/value pairs
      • 5.10.1.1. Introduction
      • 5.10.1.2. The Storage interface
      • 5.10.1.3. The sessionStorage attribute
      • 5.10.1.4. The localStorage attribute
      • 5.10.1.5. The storage event
        • 5.10.1.5.1. Event definition
      • 5.10.1.6. Threads
    • 5.10.2 Database storage
      • 5.10.2.1. Introduction
      • 5.10.2.2. Databases
      • 5.10.2.3. Executing SQL statements
      • 5.10.2.4. Database query results
      • 5.10.2.5. Errors
      • 5.10.2.6. Processing model
    • 5.10.3 Disk space
    • 5.10.4 Privacy
      • 5.10.4.1. User tracking
      • 5.10.4.2. Cookie resurrection
    • 5.10.5 Security
      • 5.10.5.1. DNS spoofing attacks
      • 5.10.5.2. Cross-directory attacks
      • 5.10.5.3. Implementation risks
      • 5.10.5.4. SQL and user agents
      • 5.10.5.5. SQL injection
  • 5.11 Links
    • 5.11.1 Hyperlink elements
    • 5.11.2 Following hyperlinks
      • 5.11.2.1. Hyperlink auditing
    • 5.11.3 Link types
      • 5.11.3.1. Link type "alternate"
      • 5.11.3.2. Link type "archives"
      • 5.11.3.3. Link type "author"
      • 5.11.3.4. Link type "bookmark"
      • 5.11.3.5. Link type "external"
      • 5.11.3.6. Link type "feed"
      • 5.11.3.7. Link type "help"
      • 5.11.3.8. Link type "icon"
      • 5.11.3.9. Link type "license"
      • 5.11.3.10. Link type "nofollow"
      • 5.11.3.11. Link type "noreferrer"
      • 5.11.3.12. Link type "pingback"
      • 5.11.3.13. Link type "prefetch"
      • 5.11.3.14. Link type "search"
      • 5.11.3.15. Link type "stylesheet"
      • 5.11.3.16. Link type "sidebar"
      • 5.11.3.17. Link type "tag"
      • 5.11.3.18. Hierarchical link types
        • 5.11.3.18.1. Link type "index"
        • 5.11.3.18.2. Link type "up"
      • 5.11.3.19. Sequential link types
        • 5.11.3.19.1. Link type "first"
        • 5.11.3.19.2. Link type "last"
        • 5.11.3.19.3. Link type "next"
        • 5.11.3.19.4. Link type "prev"
      • 5.11.3.20. Other link types
• 6. User Interaction
  • 6.1 Introduction
  • 6.2 The irrelevant attribute
  • 6.3 Activation
  • 6.4 Scrolling elements into view
  • 6.5 Focus
    • 6.5.1 Focus management
    • 6.5.2 Sequential focus navigation
  • 6.6 The text selection APIs
    • 6.6.1 APIs for the browsing context selection
    • 6.6.2 APIs for the text field selections
  • 6.7 The contenteditable attribute
    • 6.7.1 User editing actions
    • 6.7.2 Making entire documents editable
  • 6.8 Drag and drop
    • 6.8.1 Introduction
    • 6.8.2 The DragEvent and DataTransfer interfaces
    • 6.8.3 Events fired during a drag-and-drop action
    • 6.8.4 Drag-and-drop processing model
      • 6.8.4.1. When the drag-and-drop operation starts or ends in another document
      • 6.8.4.2. When the drag-and-drop operation starts or ends in another application
    • 6.8.5 The draggable attribute
    • 6.8.6 Copy and paste
      • 6.8.6.1. Copy to clipboard
      • 6.8.6.2. Cut to clipboard
      • 6.8.6.3. Paste from clipboard
      • 6.8.6.4. Paste from selection
    • 6.8.7 Security risks in the drag-and-drop model
  • 6.9 Undo history
    • 6.9.1 The UndoManager interface
    • 6.9.2 Undo: moving back in the undo transaction history
    • 6.9.3 Redo: moving forward in the undo transaction history
    • 6.9.4 The UndoManagerEvent interface and the undo and redo events
    • 6.9.5 Implementation notes
  • 6.10 Command APIs
• 7. Communication
  • 7.1 Event definitions
  • 7.2 Server-sent DOM events
    • 7.2.1 The RemoteEventTarget interface
    • 7.2.2 Connecting to an event stream
    • 7.2.3 Parsing an event stream
    • 7.2.4 Interpreting an event stream
    • 7.2.5 Notes
  • 7.3 Web sockets
    • 7.3.1 Introduction
    • 7.3.2 The WebSocket interface
    • 7.3.3 WebSocket Events
    • 7.3.4 The Web Socket protocol
      • 7.3.4.1. Client-side requirements
        • 7.3.4.1.1. Handshake
        • 7.3.4.1.2. Data framing
      • 7.3.4.2. Server-side requirements
        • 7.3.4.2.1. Minimal handshake
        • 7.3.4.2.2. Handshake details
        • 7.3.4.2.3. Data framing
      • 7.3.4.3. Closing the connection
  • 7.4 Cross-document messaging
    • 7.4.1 Processing model
• 8. Repetition templates
• 9. The HTML syntax
  • 9.1 Writing HTML documents
    • 9.1.1 The DOCTYPE
    • 9.1.2 Elements
      • 9.1.2.1. Start tags
      • 9.1.2.2. End tags
      • 9.1.2.3. Attributes
      • 9.1.2.4. Optional tags
      • 9.1.2.5. Restrictions on content models
      • 9.1.2.6. Restrictions on the contents of CDATA and RCDATA elements
    • 9.1.3 Text
      • 9.1.3.1. Newlines
    • 9.1.4 Character references
    • 9.1.5 CDATA blocks
    • 9.1.6 Comments
  • 9.2 Parsing HTML documents
    • 9.2.1 Overview of the parsing model
    • 9.2.2 The input stream
      • 9.2.2.1. Determining the character encoding
      • 9.2.2.2. Character encoding requirements
      • 9.2.2.3. Preprocessing the input stream
      • 9.2.2.4. Changing the encoding while parsing
    • 9.2.3 Parse state
      • 9.2.3.1. The insertion mode
      • 9.2.3.2. The stack of open elements
      • 9.2.3.3. The list of active formatting elements
      • 9.2.3.4. The element pointers
      • 9.2.3.5. The scripting state
    • 9.2.4 Tokenisation
      • 9.2.4.1. Tokenising character references
    • 9.2.5 Tree construction
      • 9.2.5.1. Creating and inserting elements
      • 9.2.5.2. Closing elements that have implied end tags
      • 9.2.5.3. Foster parenting
      • 9.2.5.4. The "initial" insertion mode
      • 9.2.5.5. The "before html" insertion mode
      • 9.2.5.6. The "before head" insertion mode
      • 9.2.5.7. The "in head" insertion mode
      • 9.2.5.8. The "in head noscript" insertion mode
      • 9.2.5.9. The "after head" insertion mode
      • 9.2.5.10. The "in body" insertion mode
      • 9.2.5.11. The "in table" insertion mode
      • 9.2.5.12. The "in caption" insertion mode
      • 9.2.5.13. The "in column group" insertion mode
      • 9.2.5.14. The "in table body" insertion mode
      • 9.2.5.15. The "in row" insertion mode
      • 9.2.5.16. The "in cell" insertion mode
      • 9.2.5.17. The "in select" insertion mode
      • 9.2.5.18. The "in select in table" insertion mode
      • 9.2.5.19. The "in foreign content" insertion mode
      • 9.2.5.20. The "after body" insertion mode
      • 9.2.5.21. The "in frameset" insertion mode
      • 9.2.5.22. The "after frameset" insertion mode
      • 9.2.5.23. The "after after body" insertion mode
      • 9.2.5.24. The "after after frameset" insertion mode
    • 9.2.6 The end
  • 9.3 Namespaces
  • 9.4 Serializing HTML fragments
  • 9.5 Parsing HTML fragments
  • 9.6 Named character references
• 10. Rendering and user-agent behavior
  • 10.1 Rendering and the DOM
  • 10.2 Rendering and menus/toolbars
    • 10.2.1 The 'icon' property
  • 10.3 Obsolete elements, attributes, and APIs
    • 10.3.1 The body element
    • 10.3.2 The applet element
• 11. Things that you can't do with this specification because they are better handled using other technologies that are further described herein
  • 11.1 Localization
  • 11.2 Declarative 2D vector graphics and animation
  • 11.3 Declarative 3D scenes
  • 11.4 Timers
• Index
• References
• Acknowledgements

1. Introduction

1.1 Background

This section is non-normative.

The World Wide Web's markup language has always been HTML. HTML was primarily designed as a language for semantically describing scientific documents, although its general design and adaptations over the years has enabled it to be used to describe a number of other types of documents.

The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.

1.2 Scope

This section is non-normative.

This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.

The scope of this specification does not include providing mechanisms for media-specific customization of presentation (although default rendering rules for Web browsers are included at the end of this specification, and several mechanisms for hooking into CSS are provided as part of the language).

The scope of this specification does not include documenting every HTML or DOM feature supported by Web browsers. Browsers support many features that are considered to be very bad for accessibility or that are otherwise inappropriate. For example, the blink element is clearly presentational and authors wishing to cause text to blink should instead use CSS.

The scope of this specification is not to describe an entire operating system. In particular, hardware configuration software, image manipulation tools, and applications that users would be expected to use with high-end workstations on a daily basis are out of scope. In terms of applications, this specification is targeted specifically at applications that would be expected to be used by users on an occasional basis, or regularly but from disparate locations, with low CPU requirements. For instance online purchasing systems, searching systems, games (especially multiplayer online games), public telephone books or address books, communications software (e-mail clients, instant messaging clients, discussion software), document editing software, etc.

For sophisticated cross-platform applications, there already exist several proprietary solutions (such as Mozilla's XUL, Adobe's Flash, or Microsoft's Silverlight). These solutions are evolving faster than any standards process could follow, and the requirements are evolving even faster. These systems are also significantly more complicated to specify, and are orders of magnitude more difficult to achieve interoperability with, than the solutions described in this document. Platform-specific solutions for such sophisticated applications (for example the MacOS X Core APIs) are even further ahead.

1.3 Relationships to other specifications

1.3.1 Relationship to HTML 4.01 and DOM2 HTML

This section is non-normative.

This specification represents a new version of HTML4, along with a new version of the associated DOM2 HTML API. Migration from HTML4 to the format and APIs described in this specification should in most cases be straightforward, as care has been taken to ensure that backwards-compatibility is retained. [HTML4] [DOM2HTML]

1.3.2 Relationship to XHTML 1.x

This section is non-normative.

This specification is intended to replace XHTML 1.0 as the normative definition of the XML serialization 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.

1.3.3 Relationship to XHTML2

This section is non-normative.

XHTML2 [XHTML2] defines a new HTML vocabulary with better features for hyperlinks, multimedia content, annotating document edits, rich metadata, declarative interactive forms, and describing the semantics of human literary works such as poems and scientific papers.

However, it lacks elements to express the semantics of many of the non-document types of content often seen on the Web. For instance, forum sites, auction sites, search engines, online shops, and the like, do not fit the document metaphor well, and are not covered by XHTML2.

This specification aims to extend HTML so that it is also suitable in these contexts.

XHTML2 and this specification use different namespaces and therefore can both be implemented in the same XML processor.

1.3.4 Relationship to Web Forms 2.0 and XForms

This section is non-normative.

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 orthognoal 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]

1.3.5 Relationship to XUL, Flash, Silverlight, and other proprietary UI languages

This section is non-normative.

This specification is independent of the various proprietary UI languages that various vendors provide. As an open, vendor-neutral language, HTML provides for a solution to the same problems without the risk of vendor lock-in.

1.4 HTML vs XHTML

This section is non-normative.

This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language.

The in-memory representation is known as "DOM5 HTML", or "the DOM" for short.

There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.

The first such concrete syntax is "HTML5". This is the format recommended for most authors. It is compatible with all legacy Web browsers. If a document is transmitted with the MIME type text/html, then it will be processed as an "HTML5" document by Web browsers.

The second concrete syntax uses XML, and is known as "XHTML5". When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an "XHTML5" document. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent an XML document from being rendered fully, whereas they would be ignored in the "HTML5" syntax.

The "DOM5 HTML", "HTML5", and "XHTML5" representations cannot all represent the same content. For example, namespaces cannot be represented using "HTML5", but they are supported in "DOM5 HTML" and "XHTML5". Similarly, documents that use the noscript feature can be represented using "HTML5", but cannot be represented with "XHTML5" and "DOM5 HTML". Comments that contain the string "-->" can be represented in "DOM5 HTML" but not in "HTML5" and "XHTML5". And so forth.

1.5 Structure of this specification

This section is non-normative.

This specification is divided into the following major sections:

Common Infrastructure

The conformance classes, algorithms, definitions, and the common underpinnings of the rest of the specification.

The DOM

Documents are built from elements. These elements form a tree using the DOM. This section defines the features of this DOM, as well as introducing the features common to all elements, and the concepts used in defining elements.

Elements

Each element has a predefined meaning, which is explained in this section. User agent requirements for how to handle each element are also given, along with rules for authors on how to use the element.

Web Browsers

HTML documents do not exist in a vacuum — this section defines many of the features that affect environments that deal with multiple pages, links between pages, and running scripts.

User Interaction

HTML documents can provide a number of mechanisms for users to interact with and modify content, which are described in this section.

The Communication APIs

Applications written in HTML often require mechanisms to communicate with remote servers, as well as communicating with other applications from different domains running on the same client.

Repetition Templates

A mechanism to support repeating sections in forms.

The Language Syntax

All of these features would be for naught if they couldn't be represented in a serialized form and sent to other people, and so this section defines the syntax of HTML, along with rules for how to parse HTML.

There are also a couple of appendices, defining rendering rules for Web browsers and listing areas that are out of scope for this specification.

1.5.1 How to read this specification

This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references.

2. Common infrastructure

2.1 Conformance requirements

All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

This specification describes the conformance criteria for user agents (relevant to implementors) and documents (relevant to authors and authoring tool implementors).

There is no implied relationship between document conformance requirements and implementation conformance requirements. User agents are not free to handle non-conformant documents as they please; the processing model described in this specification applies to implementations regardless of the conformity of the input documents.

User agents fall into several (overlapping) categories with different conformance requirements.

Web browsers and other interactive user agents

Web browsers that support XHTML must process elements and attributes from the HTML namespace found in XML documents as described in this specification, so that users can interact with them, unless the semantics of those elements have been overridden by other specifications.

A conforming XHTML processor would, upon finding an XHTML script element in an XML document, execute the script contained in that element. However, if the element is found within an XSLT transformation sheet (assuming the UA also supports XSLT), then the processor would instead treat the script element as an opaque element that forms part of the transform.

Web browsers that support HTML must process documents labeled as text/html as described in this specification, so that users can interact with them.

Non-interactive presentation user agents

User agents that process HTML and XHTML documents purely to render non-interactive versions of them must comply to the same conformance criteria as Web browsers, except that they are exempt from requirements regarding user interaction.

Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs). It is expected that most static non-interactive presentation user agents will also opt to lack scripting support.

A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus" is irrelevant when the user cannot interact with the document, the UA would not need to support any of the focus-related DOM APIs.

User agents with no scripting support

Implementations that do not support scripting (or which have their scripting features disabled entirely) are exempt from supporting the events and DOM interfaces mentioned in this specification. For the parts of this specification that are defined in terms of an events model or in terms of the DOM, such user agents must still act as if events and the DOM were supported.

Scripting can form an integral part of an application. Web browsers that do not support scripting, or that have scripting disabled, might be unable to fully convey the author's intent.

Conformance checkers

Conformance checkers must verify that a document conforms to the applicable conformance criteria described in this specification. 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).

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. (This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible. [HALTINGPROBLEM])

The term "HTML5 validator" can be used to refer to a conformance checker that itself conforms to the applicable requirements of this specification.

XML DTDs cannot express all the conformance requirements of this specification. Therefore, a validating XML processor and a DTD cannot constitute a conformance checker. Also, since neither of the two authoring formats defined in this specification are applications of SGML, a validating SGML system cannot constitute a conformance checker either.

To put it another way, there are three types of conformance criteria:

1. Criteria that can be expressed in a DTD.
2. Criteria that cannot be expressed by a DTD, but can still be checked by a machine.
3. Criteria that can only be checked by a human.

A conformance checker must check for the first two. A simple DTD-based validator only checks for the first class of errors and is therefore not a conforming conformance checker according to this specification.

Data mining tools

Applications and tools that process HTML and XHTML documents for reasons other than to either render the documents or check them for conformance should act in accordance to the semantics of the documents that they process.

A tool that generates document outlines but increases the nesting level for each paragraph and does not increase the nesting level for each section would not be conforming.

Authoring tools and markup generators

Authoring tools and markup generators must generate conforming documents. Conformance criteria that apply to authors also apply to authoring tools, where appropriate.

Authoring tools are exempt from the strict requirements of using elements only for their specified purpose, but only to the extent that authoring tools are not yet able to determine author intent.

For example, it is not conforming to use an address element for arbitrary contact information; that element can only be used for marking up contact information for the author of the document or section. However, since an authoring tool is likely unable to determine the difference, an authoring tool is exempt from that requirement.

In terms of conformance checking, an editor is therefore required to output documents that conform to the same extent that a conformance checker will verify.

When an authoring tool is used to edit a non-conforming document, it may preserve the conformance errors in sections of the document that were not edited during the editing session (i.e. an editing tool is allowed to round-trip erroneous content). However, an authoring tool must not claim that the output is conformant if errors have been so preserved.

Authoring tools are expected to come in two broad varieties: tools that work from structure or semantic data, and tools that work on a What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG).

The former is the preferred mechanism for tools that author HTML, since the structure in the source information can be used to make informed choices regarding which HTML elements and attributes are most appropriate.

However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are appropriate, and should not use elements that they do not know to be appropriate. This might in certain extreme cases mean limiting the use of flow elements to just a few elements, like div, b, i, and span and making liberal use of the style attribute.

All authoring tools, whether WYSIWYG or not, should make a best effort attempt at enabling users to create well-structured, semantically rich, media-independent content.

Some conformance requirements are phrased as requirements on elements, attributes, methods or objects. Such requirements fall into two categories: those describing content model restrictions, and those describing implementation behavior. The former category of requirements are requirements on documents and authoring tools. The second category are requirements on user agents.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML (referred to as XHTML5), and one using a custom format inspired by SGML (referred to as HTML5). Implementations may support only one of these two formats, although supporting both is encouraged.

XHTML documents (XML documents using elements from the HTML namespace) that use the new features described in this specification and that are served over the wire (e.g. by HTTP) must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html. [RFC3023]

Such XML documents may contain a DOCTYPE if desired, but this is not required to conform to this specification.

According to the XML specification, XML processors are not guaranteed to process the external DTD subset referenced in the DOCTYPE. This means, for example, that using entity references for characters in XHTML documents is unsafe (except for <, >, &, " and ').

HTML documents, if they are served over the wire (e.g. by HTTP) must be labeled with the text/html MIME type.

The language in this specification assumes that the user agent expands all entity references, and therefore does not include entity reference nodes in the DOM. If user agents do include entity reference nodes in the DOM, then user agents must handle them as if they were fully expanded when implementing this specification. For example, if a requirement talks about an element's child text nodes, then any text nodes that are children of an entity reference that is a child of that element would be used as well. Entity references to unknown entities must be treated as if they contained just an empty text node for the purposes of the algorithms defined in this specification.

2.1.1 Dependencies

This specification relies on several other underlying specifications.

XML

Implementations that support XHTML5 must support some version of XML, as well as its corresponding namespaces specification, because XHTML5 uses an XML serialization with namespaces. [XML] [XMLNAMES]

DOM

The Document Object Model (DOM) is a representation — a model — of a document and its content. The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM. [DOM3CORE]

Implementations must support some version of DOM Core and DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM Core interfaces. [DOM3CORE] [DOM3EVENTS]

ECMAScript

Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification, as this specification uses that specification's terminology. [WebIDL]

Media Queries

Implementations must support some version of the Media Queries language. [MQ]

This specification does not require support of any particular network transport protocols, style sheet language, scripting language, or any of the DOM and WebAPI specifications beyond those described above. However, the language described by this specification is biased towards CSS as the styling language, ECMAScript as the scripting language, and HTTP as the network protocol, and several features assume that those languages and protocols are in use.

This specification might have certain additional requirements on character encodings, image formats, audio formats, and video formats in the respective sections.

2.1.2 Features defined in other specifications

this section will be removed at some point

Some elements are defined in terms of their DOM textContent attribute. This is an attribute defined on the Node interface in DOM3 Core. [DOM3CORE]

Should textContent be defined differently for dir="" and <bdo>? Should we come up with an alternative to textContent that handles those and other things, like alt=""?

The interface DOMTimeStamp is defined in DOM3 Core. [DOM3CORE]

The term activation behavior is used as defined in the DOM3 Events specification. [DOM3EVENTS] At the time of writing, DOM3 Events hadn't yet been updated to define that phrase.

The rules for handling alternative style sheets are defined in the CSS object model specification. [CSSOM]

See http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?content-type=text/html;%20charset=utf-8

2.1.3 Common conformance requirements for APIs exposed to JavaScript

This section will eventually be removed in favour of WebIDL.

A lot of arrays/lists/collections in this spec assume zero-based indexes but use the term "indexth" liberally. We should define those to be zero-based and be clearer about this.

Unless otherwise specified, if a DOM attribute that is a floating point number type (float) is assigned an Infinity or Not-a-Number value, a NOT_SUPPORTED_ERR exception must be raised.

Unless otherwise specified, if a method with an argument that is a floating point number type (float) is passed an Infinity or Not-a-Number value, a NOT_SUPPORTED_ERR exception must be raised.

Unless otherwise specified, if a method is passed fewer arguments than is defined for that method in its IDL definition, a NOT_SUPPORTED_ERR exception must be raised.

Unless otherwise specified, if a method is passed more arguments than is defined for that method in its IDL definition, the excess arguments must be ignored.

2.2 Terminology

This specification refers to both HTML and XML attributes and DOM attributes, often in the same context. When it is not clear which is being referred to, they are referred to as content attributes for HTML and XML attributes, and DOM attributes for those from the DOM. Similarly, the term "properties" is used for both ECMAScript object properties and CSS properties. When these are ambiguous they are qualified as object properties and CSS properties respectively.

To ease migration from HTML to XHTML, UAs conforming to this specification will place elements in HTML in the http://www.w3.org/1999/xhtml namespace, at least for the purposes of the DOM and CSS. The term "elements in the HTML namespace", or "HTML elements" for short, when used in this specification, thus refers to both HTML and XHTML elements.

Unless otherwise stated, all elements defined or mentioned in this specification are in the http://www.w3.org/1999/xhtml namespace, and all attributes defined or mentioned in this specification have no namespace (they are in the per-element partition).

When an XML name, such as an attribute or element name, is referred to in the form prefix:localName, as in xml:id or svg:rect, it refers to a name with the local name localName and the namespace given by the prefix, as defined by the following table:

xml

http://www.w3.org/XML/1998/namespace

html

http://www.w3.org/1999/xhtml

svg

http://www.w3.org/2000/svg

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". [XML]

The term HTML documents is sometimes used in contrast with XML documents to specifically mean documents that were parsed using an HTML parser (as opposed to using an XML parser or created purely through the DOM).

Generally, when the specification states that a feature applies to HTML or XHTML, it also includes the other. When a feature specifically only applies to one of the two languages, it is called out by explicitly stating that it does not apply to the other format, as in "for HTML, ... (this does not apply to XHTML)".

This specification uses the term document to refer to any use of HTML, ranging from short static documents to long essays or reports with rich multimedia, as well as to fully-fledged interactive applications.

The term root element, when not explicitly qualified as referring to the document's root element, means the furthest ancestor element node of whatever node is being discussed, or the node itself if it has no ancestors. When the node is a part of the document, then that is indeed the document's root element; however, if the node is not currently part of the document tree, the root element will be an orphaned node.

An element is said to have been inserted into a document when its root element changes and is now the document's root element.

The term tree order means a pre-order, depth-first traversal of DOM nodes involved (through the parentNode/childNodes relationship).

When it is stated that some element or attribute is ignored, or treated as some other value, or handled as if it was something else, this refers only to the processing of the node after it is in the DOM. A user agent must not mutate the DOM in such situations.

For simplicity, terms such as shown, displayed, and visible might sometimes be used when referring to the way a document is rendered to the user. These terms are not meant to imply a visual medium; they must be considered to apply to other media in equivalent ways.

The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of the more accurate "an object implementing the interface Foo".

A DOM attribute is said to be getting when its value is being retrieved (e.g. by author script), and is said to be setting when a new value is assigned to it.

If a DOM object is said to be live, then that means that any attributes returning that object must always return the same object (not a new object each time), and the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data.

The terms fire and dispatch are used interchangeably in the context of events, as in the DOM Events specifications. [DOM3EVENTS]

The term text node refers to any Text node, including CDATASection nodes; specifically, any Node with node type TEXT_NODE (3) or CDATA_SECTION_NODE (4). [DOM3CORE]

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.

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. [NPAPI]

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.

Some of the algorithms in this specification, for historical reasons, require the user agent to pause until some condition has been met. While a user agent is paused, it must ensure that no scripts execute (e.g. no event handlers, no timers, etc). User agents should remain responsive to user input while paused, however, albeit without letting the user interact with Web pages where that would involve invoking any script.

2.3 URLs

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.

2.3.1 Terminology

A URL is a string used to identify a resource. A URL is always associated with a Document, either explicitly when the URL is created or defined; or through a DOM node, in which case the associated Document is the node's Document; or through a script, in which case the associated Document is the script's script document context.

A URL is a valid URL if at least one of the following conditions holds:

• The URL is a valid URI reference [RFC3986].

• The URL is a valid IRI reference and it has no query component. [RFC3987]

• The URL is a valid IRI reference and its query component contains no unescaped non-ASCII characters. [RFC3987]

• The URL is a valid IRI reference and the character encoding of the URL's Document is UTF-8 or UTF-16. [RFC3987]

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.

2.3.2 Parsing URLs

To parse a URL url into its component parts, the user agent must use the following steps:

1. Strip leading and trailing space characters from url.

2. Parse url in the manner defined by RFC 3986, with the following exceptions:

   • Add all characters with codepoints less than or equal to U+0020 or greater than or equal to U+007F to the <unreserved> production.
   • Add the characters U+0022, U+003C, U+003E, U+005B .. U+005E, U+0060, and U+007B .. U+007D to the <unreserved> production.
   • Add a single U+0025 PERCENT SIGN character as a second alternative way of matching the <pct-encoded> production, except when the <pct-encoded> is used in the <reg-name> production.
   • Add the U+0023 NUMBER SIGN character to the characters allowed in the <fragment> production.

3. If url doesn't match the <URI-reference> production, even after the above changes are made to the ABNF definitions, then parsing the URL fails with an error. [RFC3986]

   Otherwise, parsing url was successful; the components of the URL are substrings of url defined as follows:

   <scheme>

   The substring matched by the <scheme> production, if any.

   <host>

   The substring matched by the <host> production, if any.

   <port>

   The substring matched by the <port> production, if any.

   <hostport>

   If there is a <scheme> component and a <port> component and the port given by the <port> component is different than the default port defined for the protocol given by the <scheme> component, then <hostport> is the substring that starts with the substring matched by the <host> production and ends with the substring matched by the <port> production, and includes the colon in between the two. Otherwise, it is the same as the <host> component.

   <path>

   The substring matched by one of the following productions, if one of them was matched:

   • <path-abempty>
   • <path-absolute>
   • <path-noscheme>
   • <path-rootless>
   • <path-empty>

   <query>

   The substring matched by the <query> production, if any.

   <fragment>

   The substring matched by the <fragment> production, if any.

2.3.3 Resolving URLs

Relative URLs are resolved relative to a base URL. The base URL of a URL is the absolute URL obtained as follows:

If the URL to be resolved was passed to an API

The base URL is the document base URL of the script's script document context.

If the URL to be resolved is from the value of a content attribute

The base URL is the base URI of the element that the attribute is on, as defined by the XML Base specification, with the base URI of the document entity being defined as the document base URL of the Document that owns the element.

For the purposes of the XML Base specification, user agents must act as if all Document objects represented XML documents.

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 are not allowed in HTML documents.)

If the URL to be resolved was found in an offline application cache manifest

The base URL is the URL of the application cache manifest.

The document base URL of a Document is the absolute URL obtained by running these steps:

1. If there is no base element that is both a child of the head element and has an href attribute, then the document base URL is the document's address.

2. Otherwise, let url be the value of the href attribute of the first such element.

3. Resolve the url URL, using the document's address as the base URL (thus, the base href attribute isn't affect by xml:base attributes).

4. The document base URL is the result of the previous step if it was successful; otherwise it is the document's address.

To resolve a URL to an absolute URL the user agent must use the following steps. Resolving a URL can result in an error, in which case the URL is not resolvable.

1. Let url be the URL being resolved.

2. Let document be the Document associated with url.

3. Let encoding be the character encoding of document.

4. If encoding is UTF-16, then change it to UTF-8.

5. Let base be the base URL for url. (This is an absolute URL.)

6. Parse url into its component parts.

7. If parsing url resulted in a <host> component, then replace the matching subtring of url with the string that results from expanding any sequences of percent-encoded octets in that component that are valid UTF-8 sequences into Unicode characters as defined by UTF-8.

   If any percent-encoded octets in that component are not valid UTF-8 sequences, then return an error and abort these steps.

   Apply the IDNA ToASCII algorithm to the matching substring, with both the AllowUnassigned and UseSTD3ASCIIRules flags set. Replace the matching substring with the result of the ToASCII algorithm.

   If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then return an error and abort these steps. [RFC3490]

8. If parsing url resulted in a <path> component, then replace the matching substring of url with the string that results from applying the following steps to each character other than U+0025 PERCENT SIGN (%) that doesn't match the original <path> production defined in RFC 3986:

   1. Encode the character into a sequence of octets as defined by UTF-8.
   2. Replace the character with the percent-encoded form of those octets. [RFC3986]

   For instance if url was "//example.com/a^b☺c%FFd%z/?e", then the <path> component's substring would be "/a^b☺c%FFd%z/" and the two characters that would have to be escaped would be "^" and "☺". The result after this step was applied would therefore be that url now had the value "//example.com/a%5Eb%E2%98%BAc%FFd%z/?e".

9. If parsing url resulted in a <query> component, then replace the matching substring of url with the string that results from applying the following steps to each character other than U+0025 PERCENT SIGN (%) that doesn't match the original <query> production defined in RFC 3986:

   1. If the character in question cannot be expressed in the encoding encoding, then replace it with a single 0x3F octet (an ASCII question mark) and skip the remaining substeps for this character.
   2. Encode the character into a sequence of octets as defined by the encoding encoding.
   3. Replace the character with the percent-encoded form of those octets. [RFC3986]

10. Apply the algorithm described in RFC 3986 section 5.2 Relative Resolution, using url as the potentially relative URI reference (R), and base as the base URI (Base). [RFC3986]

11. Apply any relevant conformance criteria of RFC 3986 and RFC 3987, returning an error and aborting these steps if appropriate. [RFC3986] [RFC3987]

    For instance, if an absolute URI that would be returned by the above algorithm violates the restrictions specific to its scheme, e.g. a data: URI using the "//" server-based naming authority syntax, then user agents are to treat this as an error instead.

12. Let result be the target URI (T) returned by the Relative Resolution algorithm.

13. If result uses a scheme with a server-based naming authority, replace all U+005C REVERSE SOLIDUS (\) characters in result with U+002F SOLIDUS (/) characters.

14. Return result.

A URL is an absolute URL if resolving it results in the same URL without an error.

2.3.4 Dynamic changes to base URLs

When an xml:base attribute changes, the attribute's element, and all descendant elements, are affected by a base URL change.

When a document's document base URL changes, all elements in that document are affected by a base URL change.

When an element is moved from one document to another, if the two documents have different base URLs, then that element and all its descendants are affected by a base URL change.

When an element is affected by a base URL change, it must act as described in the following list:

If the element is a hyperlink element

If the absolute URL identified by the hyperlink is being shown to the user, or if any data derived from that URL is affecting the display, then the href attribute should be reresolved and the UI updated appropriately.

For example, the CSS :link/:visited pseudo-classes might have been affected.

If the hyperlink has a ping attribute and its absolute URL(s) are being shown to the user, then the ping attribute's tokens should be reresolved and the UI updated appropriately.

If the element is a blockquote, q, ins, or del element with a cite attribut