Abstract

This specification defines the bulk of the HTML5 vocabulary, which is further extended by other specifications.

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), or submit them using our public bug database. All feedback is welcome.

The working groups maintains a list of all bug reports that the editor has not yet tried to address and a list of issues for which the chairs have not yet declared a decision. The editor also maintains a list of all e-mails that he has not yet tried to address. These bugs, issues, and e-mails apply to all HTML specifications, not just this one.

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) contains the latest draft text of this specification (amongst others). For more details, please see the WHATWG FAQ.

There are various ways to follow the change history for the HTML specifications:

E-mail notifications of changes
HTML-Diffs mailing list (diff-marked HTML versions for each change): http://lists.w3.org/Archives/Public/public-html-diffs/latest
Commit-Watchers mailing list (complete source diffs): http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org
Real-time notifications of changes:
Generated diff-marked HTML versions for each change: http://twitter.com/HTML5
All (non-editorial) changes to the spec source: http://twitter.com/WHATWG
Browsable version-control record of all changes:
CVSWeb interface with side-by-side diffs: http://dev.w3.org/cvsweb/html5/
Annotated summary with unified diffs: http://html5.org/tools/web-apps-tracker
Raw Subversion interface: svn checkout http://svn.whatwg.org/webapps/

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 9 January 2010 Editor's Draft.

This specification is part of a larger specification being produced by the WHATWG. This specification is a module that forms part of the HTML5 series of specifications published at the W3C. It is published separate from other modules of HTML5 in a manner consistent with the principles of maturity, market success, and reusability in other languages described in the Working Group Decision published on January 7th 2010. The HTML5 series of specifications is intended to replace (be a new version of) what was previously the HTML4, XHTML1, 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.

The WHATWG version of this specification is available under a license that permits reuse of the specification text.

Table of Contents

  1. 1 Conformance requirements
  2. 2 Semantics, structure, and APIs of HTML documents
    1. 2.1 Documents
      1. 2.1.1 Documents in the DOM
      2. 2.1.2 Security
      3. 2.1.3 Resource metadata management
      4. 2.1.4 DOM tree accessors
      5. 2.1.5 Creating documents
    2. 2.2 Elements
      1. 2.2.1 Semantics
      2. 2.2.2 Elements in the DOM
      3. 2.2.3 Global attributes
        1. 2.2.3.1 The id attribute
        2. 2.2.3.2 The title attribute
        3. 2.2.3.3 The lang and xml:lang attributes
        4. 2.2.3.4 The xml:base attribute (XML only)
        5. 2.2.3.5 The dir attribute
        6. 2.2.3.6 The class attribute
        7. 2.2.3.7 The style attribute
        8. 2.2.3.8 Embedding custom non-visible data
      4. 2.2.4 Element definitions
      5. 2.2.5 Content models
        1. 2.2.5.1 Kinds of content
          1. 2.2.5.1.1 Metadata content
          2. 2.2.5.1.2 Flow content
          3. 2.2.5.1.3 Sectioning content
          4. 2.2.5.1.4 Heading content
          5. 2.2.5.1.5 Phrasing content
          6. 2.2.5.1.6 Embedded content
          7. 2.2.5.1.7 Interactive content
        2. 2.2.5.2 Transparent content models
        3. 2.2.5.3 Paragraphs
      6. 2.2.6 Annotations for assistive technology products (ARIA)
    3. 2.3 APIs in HTML documents
    4. 2.4 Interactions with XPath and XSLT
    5. 2.5 Dynamic markup insertion
      1. 2.5.1 Opening the input stream
      2. 2.5.2 Closing the input stream
      3. 2.5.3 document.write()
      4. 2.5.4 document.writeln()
      5. 2.5.5 innerHTML
      6. 2.5.6 outerHTML
      7. 2.5.7 insertAdjacentHTML()
  3. 3 The elements of HTML
    1. 3.1 The root element
      1. 3.1.1 The html element
    2. 3.2 Document metadata
      1. 3.2.1 The head element
      2. 3.2.2 The title element
      3. 3.2.3 The base element
      4. 3.2.4 The link element
      5. 3.2.5 The meta element
        1. 3.2.5.1 Standard metadata names
        2. 3.2.5.2 Other metadata names
        3. 3.2.5.3 Pragma directives
        4. 3.2.5.4 Other pragma directives
        5. 3.2.5.5 Specifying the document's character encoding
      6. 3.2.6 The style element
      7. 3.2.7 Styling
    3. 3.3 Scripting
      1. 3.3.1 The script element
        1. 3.3.1.1 Scripting languages
        2. 3.3.1.2 Restrictions for contents of script elements
        3. 3.3.1.3 Inline documentation for external scripts
      2. 3.3.2 The noscript element
    4. 3.4 Sections
      1. 3.4.1 The body element
      2. 3.4.2 The section element
      3. 3.4.3 The nav element
      4. 3.4.4 The article element
      5. 3.4.5 The aside element
      6. 3.4.6 The h1, h2, h3, h4, h5, and h6 elements
      7. 3.4.7 The hgroup element
      8. 3.4.8 The header element
      9. 3.4.9 The footer element
      10. 3.4.10 The address element
      11. 3.4.11 Headings and sections
        1. 3.4.11.1 Creating an outline
    5. 3.5 Grouping content
      1. 3.5.1 The p element
      2. 3.5.2 The hr element
      3. 3.5.3 The br element
      4. 3.5.4 The pre element
      5. 3.5.5 The blockquote element
      6. 3.5.6 The ol element
      7. 3.5.7 The ul element
      8. 3.5.8 The li element
      9. 3.5.9 The dl element
      10. 3.5.10 The dt element
      11. 3.5.11 The dd element
      12. 3.5.12 The div element
    6. 3.6 Text-level semantics
      1. 3.6.1 The a element
      2. 3.6.2 The em element
      3. 3.6.3 The strong element
      4. 3.6.4 The small element
      5. 3.6.5 The cite element
      6. 3.6.6 The q element
      7. 3.6.7 The dfn element
      8. 3.6.8 The abbr element
      9. 3.6.9 The time element
      10. 3.6.10 The code element
      11. 3.6.11 The var element
      12. 3.6.12 The samp element
      13. 3.6.13 The kbd element
      14. 3.6.14 The sub and sup elements
      15. 3.6.15 The i element
      16. 3.6.16 The b element
      17. 3.6.17 The mark element
      18. 3.6.18 The ruby element
      19. 3.6.19 The rt element
      20. 3.6.20 The rp element
      21. 3.6.21 The bdo element
      22. 3.6.22 The span element
      23. 3.6.23 Usage summary
    7. 3.7 Edits
      1. 3.7.1 The ins element
      2. 3.7.2 The del element
      3. 3.7.3 Attributes common to ins and del elements
      4. 3.7.4 Edits and paragraphs
      5. 3.7.5 Edits and lists
    8. 3.8 Embedded content
      1. 3.8.1 The figure element
      2. 3.8.2 The img element
        1. 3.8.2.1 Requirements for providing text to act as an alternative for images
          1. 3.8.2.1.1 A link or button containing nothing but the image
          2. 3.8.2.1.2 A phrase or paragraph with an alternative graphical representation: charts, diagrams, graphs, maps, illustrations
          3. 3.8.2.1.3 A short phrase or label with an alternative graphical representation: icons, logos
          4. 3.8.2.1.4 Text that has been rendered to a graphic for typographical effect
          5. 3.8.2.1.5 A graphical representation of some of the surrounding text
          6. 3.8.2.1.6 A purely decorative image that doesn't add any information
          7. 3.8.2.1.7 A group of images that form a single larger picture with no links
          8. 3.8.2.1.8 A group of images that form a single larger picture with links
          9. 3.8.2.1.9 A key part of the content
          10. 3.8.2.1.10 An image not intended for the user
          11. 3.8.2.1.11 An image in an e-mail or private document intended for a specific person who is known to be able to view images
          12. 3.8.2.1.12 General guidelines
          13. 3.8.2.1.13 Guidance for markup generators
          14. 3.8.2.1.14 Guidance for conformance checkers
      3. 3.8.3 The iframe element
      4. 3.8.4 The embed element
      5. 3.8.5 The object element
      6. 3.8.6 The param element
      7. 3.8.7 The video element
      8. 3.8.8 The audio element
      9. 3.8.9 The source element
      10. 3.8.10 Media elements
        1. 3.8.10.1 Error codes
        2. 3.8.10.2 Location of the media resource
        3. 3.8.10.3 MIME types
        4. 3.8.10.4 Network states
        5. 3.8.10.5 Loading the media resource
        6. 3.8.10.6 Offsets into the media resource
        7. 3.8.10.7 The ready states
        8. 3.8.10.8 Playing the media resource
        9. 3.8.10.9 Seeking
        10. 3.8.10.10 User interface
        11. 3.8.10.11 Time ranges
        12. 3.8.10.12 Event summary
        13. 3.8.10.13 Security and privacy considerations
      11. 3.8.11 The canvas element
        1. 3.8.11.1 Color spaces and color correction
        2. 3.8.11.2 Security with canvas elements
      12. 3.8.12 The map element
      13. 3.8.13 The area element
      14. 3.8.14 Image maps
        1. 3.8.14.1 Authoring
        2. 3.8.14.2 Processing model
      15. 3.8.15 MathML
      16. 3.8.16 SVG
      17. 3.8.17 Dimension attributes
    9. 3.9 Tabular data
      1. 3.9.1 The table element
      2. 3.9.2 The caption element
      3. 3.9.3 The colgroup element
      4. 3.9.4 The col element
      5. 3.9.5 The tbody element
      6. 3.9.6 The thead element
      7. 3.9.7 The tfoot element
      8. 3.9.8 The tr element
      9. 3.9.9 The td element
      10. 3.9.10 The th element
      11. 3.9.11 Attributes common to td and th elements
      12. 3.9.12 Processing model
        1. 3.9.12.1 Forming a table
        2. 3.9.12.2 Forming relationships between data cells and header cells
      13. 3.9.13 Examples
    10. 3.10 Forms
      1. 3.10.1 The form element
      2. 3.10.2 The fieldset element
      3. 3.10.3 The legend element
      4. 3.10.4 The label element
      5. 3.10.5 The input element
        1. 3.10.5.1 States of the type attribute
          1. 3.10.5.1.1 Hidden state
          2. 3.10.5.1.2 Text state and Search state
          3. 3.10.5.1.3 Telephone state
          4. 3.10.5.1.4 URL state
          5. 3.10.5.1.5 E-mail state
          6. 3.10.5.1.6 Password state
          7. 3.10.5.1.7 Date and Time state
          8. 3.10.5.1.8 Date state
          9. 3.10.5.1.9 Month state
          10. 3.10.5.1.10 Week state
          11. 3.10.5.1.11 Time state
          12. 3.10.5.1.12 Local Date and Time state
          13. 3.10.5.1.13 Number state
          14. 3.10.5.1.14 Range state
          15. 3.10.5.1.15 Color state
          16. 3.10.5.1.16 Checkbox state
          17. 3.10.5.1.17 Radio Button state
          18. 3.10.5.1.18 File Upload state
          19. 3.10.5.1.19 Submit Button state
          20. 3.10.5.1.20 Image Button state
          21. 3.10.5.1.21 Reset Button state
          22. 3.10.5.1.22 Button state
        2. 3.10.5.2 Common input element attributes
          1. 3.10.5.2.1 The autocomplete attribute
          2. 3.10.5.2.2 The list attribute
          3. 3.10.5.2.3 The readonly attribute
          4. 3.10.5.2.4 The size attribute
          5. 3.10.5.2.5 The required attribute
          6. 3.10.5.2.6 The multiple attribute
          7. 3.10.5.2.7 The maxlength attribute
          8. 3.10.5.2.8 The pattern attribute
          9. 3.10.5.2.9 The min and max attributes
          10. 3.10.5.2.10 The step attribute
          11. 3.10.5.2.11 The placeholder attribute
        3. 3.10.5.3 Common input element APIs
        4. 3.10.5.4 Common event behaviors
      6. 3.10.6 The button element
      7. 3.10.7 The select element
      8. 3.10.8 The datalist element
      9. 3.10.9 The optgroup element
      10. 3.10.10 The option element
      11. 3.10.11 The textarea element
      12. 3.10.12 The keygen element
      13. 3.10.13 The output element
      14. 3.10.14 The progress element
      15. 3.10.15 The meter element
      16. 3.10.16 Association of controls and forms
      17. 3.10.17 Attributes common to form controls
        1. 3.10.17.1 Naming form controls
        2. 3.10.17.2 Enabling and disabling form controls
        3. 3.10.17.3 A form control's value
        4. 3.10.17.4 Autofocusing a form control
        5. 3.10.17.5 Limiting user input length
        6. 3.10.17.6 Form submission
      18. 3.10.18 Constraints
        1. 3.10.18.1 Definitions
        2. 3.10.18.2 Constraint validation
        3. 3.10.18.3 The constraint validation API
        4. 3.10.18.4 Security
      19. 3.10.19 Form submission
        1. 3.10.19.1 Introduction
        2. 3.10.19.2 Implicit submission
        3. 3.10.19.3 Form submission algorithm
        4. 3.10.19.4 URL-encoded form data
        5. 3.10.19.5 Multipart form data
        6. 3.10.19.6 Plain text form data
      20. 3.10.20 Resetting a form
      21. 3.10.21 Event dispatch
    11. 3.11 Interactive elements
      1. 3.11.1 The details element
      2. 3.11.2 The command element
      3. 3.11.3 The menu element
        1. 3.11.3.1 Introduction
        2. 3.11.3.2 Building menus and toolbars
        3. 3.11.3.3 Context menus
        4. 3.11.3.4 Toolbars
      4. 3.11.4 Commands
        1. 3.11.4.1 Using the a element to define a command
        2. 3.11.4.2 Using the button element to define a command
        3. 3.11.4.3 Using the input element to define a command
        4. 3.11.4.4 Using the option element to define a command
        5. 3.11.4.5 Using the command element to define a command
        6. 3.11.4.6 Using the accesskey attribute on a label element to define a command
        7. 3.11.4.7 Using the accesskey attribute on a legend element to define a command
        8. 3.11.4.8 Using the accesskey attribute to define a command on other elements
    12. 3.12 Common idioms without dedicated elements
      1. 3.12.1 Tag clouds
      2. 3.12.2 Conversations
      3. 3.12.3 Footnotes
    13. 3.13 Matching HTML elements using selectors
    14. 3.14 Converting HTML to other formats
      1. 3.14.1 Atom
  4. 4 The HTML syntax
    1. 4.1 Writing HTML documents
      1. 4.1.1 The DOCTYPE
      2. 4.1.2 Elements
        1. 4.1.2.1 Start tags
        2. 4.1.2.2 End tags
        3. 4.1.2.3 Attributes
        4. 4.1.2.4 Optional tags
        5. 4.1.2.5 Restrictions on content models
        6. 4.1.2.6 Restrictions on the contents of raw text and RCDATA elements
      3. 4.1.3 Text
        1. 4.1.3.1 Newlines
      4. 4.1.4 Character references
      5. 4.1.5 CDATA sections
      6. 4.1.6 Comments
    2. 4.2 Parsing HTML documents
      1. 4.2.1 Overview of the parsing model
      2. 4.2.2 The input stream
        1. 4.2.2.1 Determining the character encoding
        2. 4.2.2.2 Character encodings
        3. 4.2.2.3 Preprocessing the input stream
        4. 4.2.2.4 Changing the encoding while parsing
      3. 4.2.3 Parse state
        1. 4.2.3.1 The insertion mode
        2. 4.2.3.2 The stack of open elements
        3. 4.2.3.3 The list of active formatting elements
        4. 4.2.3.4 The element pointers
        5. 4.2.3.5 Other parsing state flags
      4. 4.2.4 Tokenization
        1. 4.2.4.1 Data state
        2. 4.2.4.2 Character reference in data state
        3. 4.2.4.3 RCDATA state
        4. 4.2.4.4 Character reference in RCDATA state
        5. 4.2.4.5 RAWTEXT state
        6. 4.2.4.6 Script data state
        7. 4.2.4.7 PLAINTEXT state
        8. 4.2.4.8 Tag open state
        9. 4.2.4.9 Close tag open state
        10. 4.2.4.10 Tag name state
        11. 4.2.4.11 RCDATA less-than sign state
        12. 4.2.4.12 RCDATA end tag open state
        13. 4.2.4.13 RCDATA end tag name state
        14. 4.2.4.14 RAWTEXT less-than sign state
        15. 4.2.4.15 RAWTEXT end tag open state
        16. 4.2.4.16 RAWTEXT end tag name state
        17. 4.2.4.17 Script data less-than sign state
        18. 4.2.4.18 Script data end tag open state
        19. 4.2.4.19 Script data end tag name state
        20. 4.2.4.20 Script data escape start state
        21. 4.2.4.21 Script data escape start dash state
        22. 4.2.4.22 Script data escaped state
        23. 4.2.4.23 Script data escaped dash state
        24. 4.2.4.24 Script data escaped dash dash state
        25. 4.2.4.25 Script data escaped less-than sign state
        26. 4.2.4.26 Script data escaped end tag open state
        27. 4.2.4.27 Script data escaped end tag name state
        28. 4.2.4.28 Script data double escape start state
        29. 4.2.4.29 Script data double escaped state
        30. 4.2.4.30 Script data double escaped dash state
        31. 4.2.4.31 Script data double escaped dash dash state
        32. 4.2.4.32 Script data double escaped less-than sign state
        33. 4.2.4.33 Script data double escape end state
        34. 4.2.4.34 Before attribute name state
        35. 4.2.4.35 Attribute name state
        36. 4.2.4.36 After attribute name state
        37. 4.2.4.37 Before attribute value state
        38. 4.2.4.38 Attribute value (double-quoted) state
        39. 4.2.4.39 Attribute value (single-quoted) state
        40. 4.2.4.40 Attribute value (unquoted) state
        41. 4.2.4.41 Character reference in attribute value state
        42. 4.2.4.42 After attribute value (quoted) state
        43. 4.2.4.43 Self-closing start tag state
        44. 4.2.4.44 Bogus comment state
        45. 4.2.4.45 Markup declaration open state
        46. 4.2.4.46 Comment start state
        47. 4.2.4.47 Comment start dash state
        48. 4.2.4.48 Comment state
        49. 4.2.4.49 Comment end dash state
        50. 4.2.4.50 Comment end state
        51. 4.2.4.51 Comment end bang state
        52. 4.2.4.52 Comment end space state
        53. 4.2.4.53 DOCTYPE state
        54. 4.2.4.54 Before DOCTYPE name state
        55. 4.2.4.55 DOCTYPE name state
        56. 4.2.4.56 After DOCTYPE name state
        57. 4.2.4.57 After DOCTYPE public keyword state
        58. 4.2.4.58 Before DOCTYPE public identifier state
        59. 4.2.4.59 DOCTYPE public identifier (double-quoted) state
        60. 4.2.4.60 DOCTYPE public identifier (single-quoted) state
        61. 4.2.4.61 After DOCTYPE public identifier state
        62. 4.2.4.62 Between DOCTYPE public and system identifiers state
        63. 4.2.4.63 After DOCTYPE system keyword state
        64. 4.2.4.64 Before DOCTYPE system identifier state
        65. 4.2.4.65 DOCTYPE system identifier (double-quoted) state
        66. 4.2.4.66 DOCTYPE system identifier (single-quoted) state
        67. 4.2.4.67 After DOCTYPE system identifier state
        68. 4.2.4.68 Bogus DOCTYPE state
        69. 4.2.4.69 CDATA section state
        70. 4.2.4.70 Tokenizing character references
      5. 4.2.5 Tree construction
        1. 4.2.5.1 Creating and inserting elements
        2. 4.2.5.2 Closing elements that have implied end tags
        3. 4.2.5.3 Foster parenting
        4. 4.2.5.4 The "initial" insertion mode
        5. 4.2.5.5 The "before html" insertion mode
        6. 4.2.5.6 The "before head" insertion mode
        7. 4.2.5.7 The "in head" insertion mode
        8. 4.2.5.8 The "in head noscript" insertion mode
        9. 4.2.5.9 The "after head" insertion mode
        10. 4.2.5.10 The "in body" insertion mode
        11. 4.2.5.11 The "text" insertion mode
        12. 4.2.5.12 The "in table" insertion mode
        13. 4.2.5.13 The "in table text" insertion mode
        14. 4.2.5.14 The "in caption" insertion mode
        15. 4.2.5.15 The "in column group" insertion mode
        16. 4.2.5.16 The "in table body" insertion mode
        17. 4.2.5.17 The "in row" insertion mode
        18. 4.2.5.18 The "in cell" insertion mode
        19. 4.2.5.19 The "in select" insertion mode
        20. 4.2.5.20 The "in select in table" insertion mode
        21. 4.2.5.21 The "in foreign content" insertion mode
        22. 4.2.5.22 The "after body" insertion mode
        23. 4.2.5.23 The "in frameset" insertion mode
        24. 4.2.5.24 The "after frameset" insertion mode
        25. 4.2.5.25 The "after after body" insertion mode
        26. 4.2.5.26 The "after after frameset" insertion mode
      6. 4.2.6 The end
      7. 4.2.7 Coercing an HTML DOM into an infoset
      8. 4.2.8 An introduction to error handling and strange cases in the parser
        1. 4.2.8.1 Misnested tags: <b><i></b></i>
        2. 4.2.8.2 Misnested tags: <b><p></b></p>
        3. 4.2.8.3 Unexpected markup in tables
        4. 4.2.8.4 Scripts that modify the page as it is being parsed
    3. 4.3 Namespaces
    4. 4.4 Serializing HTML fragments
    5. 4.5 Parsing HTML fragments
    6. 4.6 Named character references
  5. 5 The XHTML syntax
    1. 5.1 Writing XHTML documents
    2. 5.2 Parsing XHTML documents
    3. 5.3 Serializing XHTML fragments
    4. 5.4 Parsing XHTML fragments
  6. 6 Rendering
    1. 6.1 Introduction
    2. 6.2 The CSS user agent style sheet and presentational hints
      1. 6.2.1 Introduction
      2. 6.2.2 Display types
      3. 6.2.3 Margins and padding
      4. 6.2.4 Alignment
      5. 6.2.5 Fonts and colors
      6. 6.2.6 Punctuation and decorations
      7. 6.2.7 Resetting rules for inherited properties
      8. 6.2.8 The hr element
      9. 6.2.9 The fieldset element
    3. 6.3 Replaced elements
      1. 6.3.1 Embedded content
      2. 6.3.2 Images
      3. 6.3.3 Attributes for embedded content and images
      4. 6.3.4 Image maps
      5. 6.3.5 Toolbars
    4. 6.4 Bindings
      1. 6.4.1 Introduction
      2. 6.4.2 The button element
      3. 6.4.3 The details element
      4. 6.4.4 The input element as a text entry widget
      5. 6.4.5 The input element as domain-specific widgets
      6. 6.4.6 The input element as a range control
      7. 6.4.7 The input element as a color well
      8. 6.4.8 The input element as a check box and radio button widgets
      9. 6.4.9 The input element as a file upload control
      10. 6.4.10 The input element as a button
      11. 6.4.11 The marquee element
      12. 6.4.12 The meter element
      13. 6.4.13 The progress element
      14. 6.4.14 The select element
      15. 6.4.15 The textarea element
      16. 6.4.16 The keygen element
      17. 6.4.17 The time element
    5. 6.5 Frames and framesets
    6. 6.6 Interactive media
      1. 6.6.1 Links, forms, and navigation
      2. 6.6.2 The title attribute
      3. 6.6.3 Editing hosts
    7. 6.7 Print media
    8. 6.8 Interaction with CSS
      1. 6.8.1 Selectors
  7. 7 Obsolete features
    1. 7.1 Obsolete but conforming features
      1. 7.1.1 Warnings for obsolete but conforming features
    2. 7.2 Non-conforming features
    3. 7.3 Requirements for implementations
      1. 7.3.1 The applet element
      2. 7.3.2 The marquee element
      3. 7.3.3 Frames
      4. 7.3.4 Other elements, attributes and APIs
  8. 8 IANA considerations
    1. 8.1 text/html
    2. 8.2 application/xhtml+xml
    3. 8.3 text/cache-manifest
    4. 8.4 text/ping
    5. 8.5 Ping-From
    6. 8.6 Ping-To
  9. Index
    1. Elements
    2. Attributes
    3. Interfaces
    4. Events
  10. References
  11. Acknowledgements

1 Conformance requirements

Status: Last call for comments

This specification is an HTML specification. All the conformance requirements, conformance classes, definitions, dependencies, terminology, and typographical conventions described in the HTML5 Core specification apply to this specification. [HTML5CORE]

For an introduction to the HTML5 series of specifications, please see the HTML5 Introduction specification. [HTML5INTRO]

2 Semantics, structure, and APIs of HTML documents

Status: Last call for comments

2.1 Documents

Status: Last call for comments

Every XML and HTML document in an HTML UA is represented by a Document object. [DOMCORE]

The document's address is an absolute URL that is set when the Document is created. The document's current address is an absolute URL that can change during the lifetime of the Document, for example when the user navigates to a fragment identifier on the page. The document's current address must be set to the document's address when the Document is created.

Interactive user agents typically expose the document's current address in their user interface.

When a Document is created by a script using the createDocument() or createHTMLDocument() APIs, the document's address is the same as the document's address of the active document of the script's browsing context.

Document objects are assumed to be XML documents unless they are flagged as being HTML documents when they are created. Whether a document is an HTML document or an XML document affects the behavior of certain APIs and the case-sensitivity of some selectors.

2.1.1 Documents in the DOM

Status: Last call for comments

All Document objects (in user agents implementing this specification) must also implement the HTMLDocument interface, available using binding-specific methods. (This is the case whether or not the document in question is an HTML document or indeed whether it contains any HTML elements at all.) Document objects must also implement the document-level interface of any other namespaces that the UA supports.

For example, if an HTML implementation also supports SVG, then the Document object implements both HTMLDocument and SVGDocument.

Because the HTMLDocument interface is now obtained using binding-specific casting methods instead of simply being the primary interface of the document object, it is no longer defined as inheriting from Document.

[OverrideBuiltins]
interface HTMLDocument {
  // resource metadata management
  [PutForwards=href] readonly attribute Location location;
  readonly attribute DOMString URL;
           attribute DOMString domain;
  readonly attribute DOMString referrer;
           attribute DOMString cookie;
  readonly attribute DOMString lastModified;
  readonly attribute DOMString compatMode;
           attribute DOMString charset;
  readonly attribute DOMString characterSet;
  readonly attribute DOMString defaultCharset;
  readonly attribute DOMString readyState;

  // DOM tree accessors
  getter any (in DOMString name);
           attribute DOMString title;
           attribute DOMString dir;
           attribute HTMLElement body;
  readonly attribute HTMLHeadElement head;
  readonly attribute HTMLCollection images;
  readonly attribute HTMLCollection embeds;
  readonly attribute HTMLCollection plugins;
  readonly attribute HTMLCollection links;
  readonly attribute HTMLCollection forms;
  readonly attribute HTMLCollection scripts;
  NodeList getElementsByName(in DOMString elementName);
  NodeList getElementsByClassName(in DOMString classNames);

  // dynamic markup insertion
           attribute DOMString innerHTML;
  HTMLDocument open(in optional DOMString type, in optional DOMString replace);
  WindowProxy open(in DOMString url, in DOMString name, in DOMString features, in optional boolean replace);
  void close();
  void write(in DOMString... text);
  void writeln(in DOMString... text);

  // user interaction
  Selection getSelection();
  readonly attribute Element activeElement;
  boolean hasFocus();
           attribute DOMString designMode;
  boolean execCommand(in DOMString commandId);
  boolean execCommand(in DOMString commandId, in boolean showUI);
  boolean execCommand(in DOMString commandId, in boolean showUI, in DOMString value);
  boolean queryCommandEnabled(in DOMString commandId);
  boolean queryCommandIndeterm(in DOMString commandId);
  boolean queryCommandState(in DOMString commandId);
  boolean queryCommandSupported(in DOMString commandId);
  DOMString queryCommandValue(in DOMString commandId);
  readonly attribute HTMLCollection commands;

  // event handler IDL attributes
           attribute Function onabort;
           attribute Function onblur;
           attribute Function oncanplay;
           attribute Function oncanplaythrough;
           attribute Function onchange;
           attribute Function onclick;
           attribute Function oncontextmenu;
           attribute Function ondblclick;
           attribute Function ondrag;
           attribute Function ondragend;
           attribute Function ondragenter;
           attribute Function ondragleave;
           attribute Function ondragover;
           attribute Function ondragstart;
           attribute Function ondrop;
           attribute Function ondurationchange;
           attribute Function onemptied;
           attribute Function onended;
           attribute Function onerror;
           attribute Function onfocus;
           attribute Function onformchange;
           attribute Function onforminput;
           attribute Function oninput;
           attribute Function oninvalid;
           attribute Function onkeydown;
           attribute Function onkeypress;
           attribute Function onkeyup;
           attribute Function onload;
           attribute Function onloadeddata;
           attribute Function onloadedmetadata;
           attribute Function onloadstart;
           attribute Function onmousedown;
           attribute Function onmousemove;
           attribute Function onmouseout;
           attribute Function onmouseover;
           attribute Function onmouseup;
           attribute Function onmousewheel;
           attribute Function onpause;
           attribute Function onplay;
           attribute Function onplaying;
           attribute Function onprogress;
           attribute Function onratechange;
           attribute Function onreadystatechange;
           attribute Function onscroll;
           attribute Function onseeked;
           attribute Function onseeking;
           attribute Function onselect;
           attribute Function onshow;
           attribute Function onstalled;
           attribute Function onsubmit;
           attribute Function onsuspend;
           attribute Function ontimeupdate;
           attribute Function onvolumechange;
           attribute Function onwaiting;
};
Document implements HTMLDocument;

Since the HTMLDocument interface holds methods and attributes related to a number of disparate features, the members of this interface are described in various different sections.

2.1.2 Security

Status: Last call for comments

User agents must raise a SECURITY_ERR exception whenever any of the members of an HTMLDocument object are accessed by scripts whose effective script origin is not the same as the Document's effective script origin.

2.1.3 Resource metadata management

Status: Last call for comments

document . URL

Returns the document's address.

document . referrer

Returns the address of the Document from which the user navigated to this one, unless it was blocked or there was no such document, in which case it returns the empty string.

The noreferrer link type can be used to block the referrer.

The URL attribute must return the document's address.

The referrer attribute must return either the current address of the active document of the source browsing context at the time the navigation was started (that is, the page which navigated the browsing context to the current document), with any <fragment> component removed; or the empty string if there is no such originating page, or if the UA has been configured not to report referrers in this case, or if the navigation was initiated for a hyperlink with a noreferrer keyword.

In the case of HTTP, the referrer IDL attribute will match the Referer (sic) header that was sent when fetching the current page.

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).

document . cookie [ = value ]

Returns the HTTP cookies that apply to the Document. If there are no cookies or cookies can't be applied to this resource, the empty string will be returned.

Can be set, to add a new cookie to the element's set of HTTP cookies.

If the Document has no browsing context an INVALID_STATE_ERR exception will be thrown. If the contents are sandboxed into a unique origin, a SECURITY_ERR exception will be thrown.

The cookie attribute represents the cookies of the resource.

On getting, if the document is not associated with a browsing context then the user agent must raise an INVALID_STATE_ERR exception. Otherwise, if the sandboxed origin browsing context flag was set on the browsing context of the Document when the Document was created, the user agent must raise a SECURITY_ERR exception. Otherwise, if the document's address does not use a server-based naming authority, it must return the empty string. Otherwise, it must first obtain the storage mutex and then return the cookie-string for the document's address for a "non-HTTP" API. [COOKIES]

On setting, if the document is not associated with a browsing context then the user agent must raise an INVALID_STATE_ERR exception. Otherwise, if the sandboxed origin browsing context flag was set on the browsing context of the Document when the Document was created, the user agent must raise a SECURITY_ERR exception. Otherwise, if the document's address does not use a server-based naming authority, it must do nothing. Otherwise, the user agent must obtain the storage mutex and then act as it would when receiving a set-cookie-string for the document's address via a "non-HTTP" API, consisting of the new value. [COOKIES]

Since the cookie attribute is accessible across frames, the path restrictions on cookies are only a tool to help manage which cookies are sent to which parts of the site, and are not in any way a security feature.

document . lastModified

Returns the date of the last modification to the document, as reported by the server, in the form "MM/DD/YYYY hh:mm:ss".

If the last modification date is not known, the current time is returned instead.

The lastModified attribute, on getting, must return the date and time of the Document's source file's last modification, in the user's local time zone, in the following format:

  1. The month component of the date.
  2. A U+002F SOLIDUS character (/).
  3. The day component of the date.
  4. A U+002F SOLIDUS character (/).
  5. The year component of the date.
  6. A U+0020 SPACE character.
  7. The hours component of the time.
  8. A U+003A COLON character (:).
  9. The minutes component of the time.
  10. A U+003A COLON character (:).
  11. The seconds component of the time.

All the numeric components above, other than the year, must be given as two digits in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) representing the number in base ten, zero-padded if necessary. The year must be given as the shortest possible string of four or more digits in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) representing the number in base ten, zero-padded if necessary.

The Document's source file's last modification date and time must be derived from relevant features of the networking protocols used, e.g. from the value of the HTTP Last-Modified header of the document, or from metadata in the file system for local files. If the last modification date and time are not known, the attribute must return the current date and time in the above format.

document . compatMode

In a conforming document, returns the string "CSS1Compat". (In quirks mode documents, returns the string "BackCompat", but a conforming document can never trigger quirks mode.)

A Document is always set to one of three modes: no quirks mode, the default; quirks mode, used typically for legacy documents; and limited quirks mode, also known as "almost standards" mode. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.

The compatMode IDL attribute must return the literal string "CSS1Compat" unless the document has been set to quirks mode by the HTML parser, in which case it must instead return the literal string "BackCompat".

document . charset [ = value ]

Returns the document's character encoding.

Can be set, to dynamically change the document's character encoding.

New values that are not IANA-registered aliases supported by the user agent are ignored.

document . characterSet

Returns the document's character encoding.

document . defaultCharset

Returns what might be the user agent's default character encoding.

Documents have an associated character encoding. When a Document object is created, the document's character encoding must be initialized to UTF-16. Various algorithms during page loading affect this value, as does the charset setter. [IANACHARSET]

The charset IDL attribute must, on getting, return the preferred MIME name of the document's character encoding. On setting, if the new value is an IANA-registered alias for a character encoding supported by the user agent, the document's character encoding must be set to that character encoding. (Otherwise, nothing happens.)

The characterSet IDL attribute must, on getting, return the preferred MIME name of the document's character encoding.

The defaultCharset IDL attribute must, on getting, return the preferred MIME name of a character encoding, possibly the user's default encoding, or an encoding associated with the user's current geographical location, or any arbitrary encoding name.

document . readyState

Returns "loading" while the Document is loading, and "complete" once it has loaded.

The readystatechange event fires on the Document object when this value changes.

Each document has a current document readiness. When a Document object is created, it must have its current document readiness set to the string "loading" if the document is associated with an HTML parser or an XML parser, or to the string "complete" otherwise. Various algorithms during page loading affect this value. When the value is set, the user agent must fire a simple event named readystatechange at the Document object.

A Document is said to have an active parser if it is associated with an HTML parser or an XML parser that has not yet been stopped or aborted.

The readyState IDL attribute must, on getting, return the current document readiness.

2.1.4 DOM tree accessors

Status: Last call for comments

The html element of a document is the document's root element, if there is one and it's an html element, or null otherwise.

document . head

Returns the head element.

The head element of a document is the first head element that is a child of the html element, if there is one, or null otherwise.

The head attribute, on getting, must return the head element of the document (a head element or null).

document . title [ = value ]

Returns the document's title, as given by the title element.

Can be set, to update the document's title. If there is no head element, the new value is ignored.

In SVG documents, the SVGDocument interface's title attribute takes precedence.

The title element of a document is the first title element in the document (in tree order), if there is one, or null otherwise.

The title attribute must, on getting, run the following algorithm:

  1. If the root element is an svg element in the "http://www.w3.org/2000/svg" namespace, and the user agent supports SVG, then return the value that would have been returned by the IDL attribute of the same name on the SVGDocument interface. [SVG]

  2. Otherwise, let value be a concatenation of the data of all the child text nodes of the title element, in tree order, or the empty string if the title element is null.

  3. Replace any sequence of one or more consecutive space characters in value with a single U+0020 SPACE character.

  4. Remove any leading or trailing space characters in value.

  5. Return value.

On setting, the following algorithm must be run. Mutation events must be fired as appropriate.

  1. If the root element is an svg element in the "http://www.w3.org/2000/svg" namespace, and the user agent supports SVG, then the setter must defer to the setter for the IDL attribute of the same name on the SVGDocument interface (if it is readonly, then this will raise an exception). Stop the algorithm here. [SVG]

  2. If the title element is null and the head element is null, then the attribute must do nothing. Stop the algorithm here.
  3. If the title element is null, then a new title element must be created and appended to the head element. Let element be that element. Otherwise, let element be the title element.
  4. The children of element (if any) must all be removed.
  5. A single Text node whose data is the new value being assigned must be appended to element.

The title attribute on the HTMLDocument interface should shadow the attribute of the same name on the SVGDocument interface when the user agent supports both HTML and SVG. [SVG]

document . body [ = value ]

Returns the body element.

Can be set, to replace the body element.

If the new value is not a body or frameset element, this will throw a HIERARCHY_REQUEST_ERR exception.

The body element of a document is the first child of the html element that is either a body element or a frameset element. If there is no such element, it is null. If the body element is null, then when the specification requires that events be fired at "the body element", they must instead be fired at the Document object.

The body attribute, on getting, must return the body element of the document (either a body element, a frameset element, or null). On setting, the following algorithm must be run:

  1. If the new value is not a body or frameset element, then raise a HIERARCHY_REQUEST_ERR exception and abort these steps.
  2. Otherwise, if the new value is the same as the body element, do nothing. Abort these steps.
  3. Otherwise, if the body element is not null, then replace that element with the new value in the DOM, as if the root element's replaceChild() method had been called with the new value and the incumbent body element as its two arguments respectively, then abort these steps.
  4. Otherwise, the body element is null. Append the new value to the root element.
document . images

Returns an HTMLCollection of the img elements in the Document.

document . embeds
document . plugins

Return an HTMLCollection of the embed elements in the Document.

document . links

Returns an HTMLCollection of the a and area elements in the Document that have href attributes.

document . forms

Return an HTMLCollection of the form elements in the Document.

document . scripts

Return an HTMLCollection of the script elements in the Document.

The images attribute must return an HTMLCollection rooted at the Document node, whose filter matches only img elements.

The embeds attribute must return an HTMLCollection rooted at the Document node, whose filter matches only embed elements.

The plugins attribute must return the same object as that returned by the embeds attribute.

The links attribute must return an HTMLCollection rooted at the Document node, whose filter matches only a elements with href attributes and area elements with href attributes.

The forms attribute must return an HTMLCollection rooted at the Document node, whose filter matches only form elements.

The scripts attribute must return an HTMLCollection rooted at the Document node, whose filter matches only script elements.

collection = document . getElementsByName(name)

Returns a NodeList of elements in the Document that have a name attribute with the value name.

collection = document . getElementsByClassName(classes)
collection = element . getElementsByClassName(classes)

Returns a NodeList of the elements in the object on which the method was invoked (a Document or an Element) that have all the classes given by classes.

The classes argument is interpreted as a space-separated list of classes.

The getElementsByName(name) method takes a string name, and must return a live NodeList containing all the HTML elements in that document that have a name attribute whose value is equal to the name argument (in a case-sensitive manner), in tree order.

The getElementsByClassName(classNames) method takes a string that contains a set of space-separated tokens representing classes. When called, the method must return a live NodeList object containing all the elements in the document, in tree order, that have all the classes specified in that argument, having obtained the classes by splitting a string on spaces. (Duplicates are ignored.) If there are no tokens specified in the argument, then the method must return an empty NodeList. 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.

The getElementsByClassName(classNames) method on the HTMLElement interface must return a live NodeList with the nodes that the HTMLDocument getElementsByClassName() method would return when passed the same argument(s), excluding any elements that are not descendants of the HTMLElement object on which the method was invoked.

HTML, SVG, and MathML elements define which classes they are in by having an attribute with no namespace with the name class containing a space-separated list of classes to which the element belongs. Other specifications may also allow elements in their namespaces to be labeled as being in specific classes.

Given the following XHTML fragment:

<div id="example">
 <p id="p1" class="aaa bbb"/>
 <p id="p2" class="aaa ccc"/>
 <p id="p3" class="bbb ccc"/>
</div>

A call to document.getElementById('example').getElementsByClassName('aaa') would return a NodeList with the two paragraphs p1 and p2 in it.

A call to getElementsByClassName('ccc bbb') would only return one node, however, namely p3. A call to document.getElementById('example').getElementsByClassName('bbb  ccc ') would return the same thing.

A call to getElementsByClassName('aaa,bbb') would return no nodes; none of the elements above are in the "aaa,bbb" class.

The HTMLDocument interface supports named properties. The names of the supported named properties at any moment consist of the values of the name content attributes of all the applet, embed, form, iframe, img, and fallback-free object elements in the Document that have name content attributes, and the values of the id content attributes of all the applet and fallback-free object elements in the Document that have id content attributes, and the values of the id content attributes of all the img elements in the Document that have both name content attributes and id content attributes.

When the HTMLDocument object is indexed for property retrieval using a name name, then the user agent must return the value obtained using the following steps:

  1. Let elements be the list of named elements with the name name in the Document.

    There will be at least one such element, by definition.

  2. If elements has only one element, and that element is an iframe element, then return the WindowProxy object of the nested browsing context represented by that iframe element, and abort these steps.

  3. Otherwise, if elements has only one element, return that element and abort these steps.

  4. Otherwise return an HTMLCollection rooted at the Document node, whose filter matches only named elements with the name name.

Named elements with the name name, for the purposes of the above algorithm, are those that are either:

An object element is said to be fallback-free if it has no object or embed descendants.

The dir attribute on the HTMLDocument interface is defined along with the dir content attribute.

2.1.5 Creating documents

Status: Last call for comments

XML documents can be created from script using the createDocument() method on the DOMImplementation interface.

HTML documents can be created using the createHTMLDocument() method:

[Supplemental, NoInterfaceObject]
interface DOMHTMLImplementation {
  Document createHTMLDocument(in DOMString title);
};
DOMImplementation implements DOMHTMLImplementation;

The createHTMLDocument(title) method, when invoked, must run the following steps:

  1. Let doc be a newly created Document object.

  2. Mark doc as being an HTML document.

  3. Create a DocumentType node with the name attribute set to the string "html", and the other attributes specific to DocumentType objects set to the empty string, null, and empty lists, as appropriate. Append the newly created node to doc.

  4. Create an html element, and append it to doc.

  5. Create a head element, and append it to the html element created in the previous step.

  6. Create a title element, and append it to the head element created in the previous step.

  7. Create a Text node, and set its data attribute to the string given by the method's argument (which could be the empty string). Append it to the title element created in the previous step.

  8. Create a body element, and append it to the html element created in the earlier step.

  9. Return doc.

2.2 Elements

Status: Last call for comments

2.2.1 Semantics

Status: Last call for comments. ISSUE-41 (Decentralized-extensibility) blocks progress to Last Call

Elements, attributes, and attribute values in HTML are defined (by this specification) to have certain meanings (semantics). For example, the ol element represents an ordered list, and the lang attribute represents the language of the content.

Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose. Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications.

For example, the following document is non-conforming, despite being syntactically correct:

<!DOCTYPE HTML>
<html lang="en-GB">
 <head> <title> Demonstration </title> </head>
 <body>
  <table>
   <tr> <td> My favourite animal is the cat. </td> </tr>
   <tr>
    <td>
     —<a href="http://example.org/~ernest/"><cite>Ernest</cite></a>,
     in an essay from 1992
    </td>
   </tr>
  </table>
 </body>
</html>

...because the data placed in the cells is clearly not tabular data (and the cite element mis-used). A corrected version of this document might be:

<!DOCTYPE HTML>
<html lang="en-GB">
 <head> <title> Demonstration </title> </head>
 <body>
  <blockquote>
   <p> My favourite animal is the cat. </p>
  </blockquote>
  <p>
   —<a href="http://example.org/~ernest/">Ernest</a>,
   in an essay from 1992
  </p>
 </body>
</html>

This next document fragment, intended to represent the heading of a corporate site, is similarly non-conforming because the second line is not intended to be a heading of a subsection, but merely a subheading or subtitle (a subordinate heading for the same section).

<body>
 <h1>ABC Company</h1>
 <h2>Leading the way in widget design since 1432</h2>
 ...

The hgroup element is intended for these kinds of situations:

<body>
 <hgroup>
  <h1>ABC Company</h1>
  <h2>Leading the way in widget design since 1432</h2>
 </hgroup>
 ...

In the next example, there is a non-conforming attribute value ("carpet") and a non-conforming attribute ("texture"), which is not permitted by this specification:

<label>Carpet: <input type="carpet" name="c" texture="deep pile"></label>

Here would be an alternative and correct way to mark this up:

<label>Carpet: <input type="text" class="carpet" name="c" data-texture="deep pile"></label>

Through scripting and using other mechanisms, the values of attributes, text, and indeed the entire structure of the document may change dynamically while a user agent is processing it. The semantics of a document at an instant in time are those represented by the state of the document at that instant in time, and the semantics of a document can therefore change over time. User agents must update their presentation of the document as this occurs.

HTML has a progress element that describes a progress bar. If its "value" attribute is dynamically updated by a script, the UA would update the rendering to show the progress changing.

2.2.2 Elements in the DOM

Status: Last call for comments

The nodes representing HTML elements in the DOM must implement, and expose to scripts, the interfaces listed for them in the relevant sections of this specification. This includes HTML elements in XML documents, even when those documents are in another context (e.g. inside an XSLT transform).

Elements in the DOM represent things; that is, they have intrinsic meaning, also known as semantics.

For example, an ol element represents an ordered list.

The basic interface, from which all the HTML elements' interfaces inherit, and which must be used by elements that have no additional requirements, is the HTMLElement interface.

interface HTMLElement : Element {
  // DOM tree accessors
  NodeList getElementsByClassName(in DOMString classNames);

  // dynamic markup insertion
           attribute DOMString innerHTML;
           attribute DOMString outerHTML;
  void insertAdjacentHTML(in DOMString position, in DOMString text);

  // metadata attributes
           attribute DOMString id;
           attribute DOMString title;
           attribute DOMString lang;
           attribute DOMString dir;
           attribute DOMString className;
  readonly attribute DOMTokenList classList;
  readonly attribute DOMStringMap dataset;

  // user interaction
           attribute boolean hidden;
  void click();
  void scrollIntoView();
  void scrollIntoView(in boolean top);
           attribute long tabIndex;
  void focus();
  void blur();
           attribute DOMString accessKey;
  readonly attribute DOMString accessKeyLabel;
           attribute boolean draggable;
           attribute DOMString contentEditable;
  readonly attribute boolean isContentEditable;
           attribute HTMLMenuElement contextMenu;
           attribute DOMString spellcheck;

  // command API
  readonly attribute DOMString commandType;
  readonly attribute DOMString label;
  readonly attribute DOMString icon;
  readonly attribute boolean disabled;
  readonly attribute boolean checked;

  // styling
  readonly attribute CSSStyleDeclaration style;

  // event handler IDL attributes
           attribute Function onabort;
           attribute Function onblur;
           attribute Function oncanplay;
           attribute Function oncanplaythrough;
           attribute Function onchange;
           attribute Function onclick;
           attribute Function oncontextmenu;
           attribute Function ondblclick;
           attribute Function ondrag;
           attribute Function ondragend;
           attribute Function ondragenter;
           attribute Function ondragleave;
           attribute Function ondragover;
           attribute Function ondragstart;
           attribute Function ondrop;
           attribute Function ondurationchange;
           attribute Function onemptied;
           attribute Function onended;
           attribute Function onerror;
           attribute Function onfocus;
           attribute Function onformchange;
           attribute Function onforminput;
           attribute Function oninput;
           attribute Function oninvalid;
           attribute Function onkeydown;
           attribute Function onkeypress;
           attribute Function onkeyup;
           attribute Function onload;
           attribute Function onloadeddata;
           attribute Function onloadedmetadata;
           attribute Function onloadstart;
           attribute Function onmousedown;
           attribute Function onmousemove;
           attribute Function onmouseout;
           attribute Function onmouseover;
           attribute Function onmouseup;
           attribute Function onmousewheel;
           attribute Function onpause;
           attribute Function onplay;
           attribute Function onplaying;
           attribute Function onprogress;
           attribute Function onratechange;
           attribute Function onreadystatechange;
           attribute Function onscroll;
           attribute Function onseeked;
           attribute Function onseeking;
           attribute Function onselect;
           attribute Function onshow;
           attribute Function onstalled;
           attribute Function onsubmit;
           attribute Function onsuspend;
           attribute Function ontimeupdate;
           attribute Function onvolumechange;
           attribute Function onwaiting;
};

interface HTMLUnknownElement : HTMLElement { };

The HTMLElement interface holds methods and attributes related to a number of disparate features, and the members of this interface are therefore described in various different sections of this specification.

The HTMLUnknownElement interface must be used for HTML elements that are not defined by this specification (or other applicable specifications).

2.2.3 Global attributes

Status: Last call for comments

The following attributes are common to and may be specified on all HTML elements (even those not defined in this specification):

The following event handler content attributes may be specified on any HTML element:

The attributes marked with an asterisk have a different meaning when specified on body elements as those elements expose event handlers of the Window object with the same names.

While these attributes apply to all elements, they are not useful on all elements. For example, only media elements will ever receive a volumechange event fired by the user agent.

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.

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". This does not apply to XML documents.

In HTML, the xmlns attribute has absolutely no effect. It is basically a talisman. It is allowed merely to make migration to and from XHTML mildly easier. When parsed by an HTML parser, the attribute ends up in no namespace, not the "http://www.w3.org/2000/xmlns/" namespace like namespace declaration attributes in XML do.

In XML, an xmlns attribute is part of the namespace declaration mechanism, and an element cannot actually have an xmlns attribute in no namespace specified.

To enable assistive technology products to expose a more fine-grained interface than is otherwise possible with HTML elements and attributes, a set of annotations for assistive technology products can be specified.

2.2.3.1 The id attribute

Status: Last call for comments

The id attribute specifies its element's unique identifier (ID). The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters.

An element's unique identifier can be used for a variety of purposes, most notably as a way to link to specific parts of a document using fragment identifiers, as a way to target an element when scripting, and as a way to style a specific element from CSS.

If the value is not the empty string, user agents must associate the element with the given value (exactly, including any space characters) for the purposes of ID matching within the element's home subtree (e.g. for selectors in CSS or for the getElementById() method in the DOM).

Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute.

This specification doesn't preclude an element having multiple IDs, if other mechanisms (e.g. DOM Core methods) can set an element's ID in a way that doesn't conflict with the id attribute.

The id IDL attribute must reflect the id content attribute.

2.2.3.2 The title attribute

Status: Last call for comments

The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; and so forth. The value is text.

If this attribute is omitted from an element, then it implies that the title attribute of the nearest ancestor HTML element with a title attribute set is also relevant to this element. Setting the attribute overrides this, explicitly stating that the advisory information of any ancestors is not relevant to this element. Setting the attribute to the empty string indicates that the element has no advisory information.

If the title attribute's value contains U+000A LINE FEED (LF) characters, the content is split into multiple lines. Each U+000A LINE FEED (LF) character represents a line break.

Caution is advised with respect to the use of newlines in title attributes.

For instance, the following snippet actually defines an abbreviation's expansion with a line break in it:

<p>My logs show that there was some interest in <abbr title="Hypertext
Transport Protocol">HTTP</abbr> today.</p>

Some elements, such as link, abbr, and input, define additional semantics for the title attribute beyond the semantics described above.

The title IDL attribute must reflect the title content attribute.

2.2.3.3 The lang and xml:lang attributes

Status: Last call for comments

The lang attribute (in no namespace) specifies the primary language for the element's contents and for any of the element's attributes that contain text. Its value must be a valid BCP 47 language code, or the empty string. [BCP47]

The lang attribute in the XML namespace is defined in XML. [XML]

If these attributes are omitted from an element, then the language of this element is the same as the language of its parent element, if any. Setting the attribute to the empty string indicates that the primary language is unknown.

The lang attribute in no namespace may be used on any HTML element.

The lang attribute in the XML namespace may be used on HTML elements in XML documents, as well as elements in other namespaces if the relevant specifications allow it (in particular, MathML and SVG allow lang attributes in the XML namespace to be specified on their elements). If both the lang attribute in no namespace and the lang attribute in the XML namespace are specified on the same element, they must have exactly the same value when compared in an ASCII case-insensitive manner.

Authors must not use the lang attribute in the XML namespace on HTML elements in HTML documents. To ease migration to and from XHTML, authors may specify an attribute in no namespace with no prefix and with the literal localname "xml:lang" on HTML elements in HTML documents, but such attributes must only be specified if a lang attribute in no namespace is also specified, and both attributes must have the same value when compared in an ASCII case-insensitive manner.

The attribute in no namespace with no prefix and with the literal localname "xml:lang" has no effect on language processing.

To determine the language of a node, user agents must look at the nearest ancestor element (including the element itself if the node is an element) that has a lang attribute in the XML namespace set or is an HTML element and has a lang in no namespace attribute set. That attribute specifies the language of the node.

If both the lang attribute in no namespace and the lang attribute in the XML namespace are set on an element, user agents must use the lang attribute in the XML namespace, and the lang attribute in no namespace must be ignored for the purposes of determining the element's language.

If no explicit language is given for any ancestors of the node, including the root element, but there is a document-wide default language set, then that is the language of the node.

If there is no document-wide default language, then language information from a higher-level protocol (such as HTTP), if any, must be used as the final fallback language. In the absence of any language information, and in cases where the higher-level protocol reports multiple languages, the language of the node is unknown (the empty string).

If the resulting value is not a recognized language code, then it must be treated as an unknown language having the given language code, distinct from all other languages. For the purposes of round-tripping or communicating with other services that expect language codes, user agents should pass unknown language codes through unmodified.

Thus, for instance, an element with lang="xyzzy" would be matched by the selector :lang('xyzzy') (e.g. in CSS), but it would not be matched by :lang('abcde'), even though both are equally invalid. Similarly, if a Web browser and screen reader working in unison communicated about the language of the element, the browser would tell the screen reader that the language was "xyzzy", even if it knew it was invalid, just in case the screen reader actually supported a language with that code after all.

User agents may use the element's language to determine proper processing or rendering (e.g. in the selection of appropriate fonts or pronunciations, or for dictionary selection).

The lang IDL attribute must reflect the lang content attribute in no namespace.

2.2.3.4 The xml:base attribute (XML only)

The xml:base attribute is defined in XML Base. [XMLBASE]

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

2.2.3.5 The dir attribute

Status: Last call for comments

The dir attribute specifies the element's text directionality. The attribute is an enumerated attribute with the keyword ltr mapping to the state ltr, and the keyword rtl mapping to the state rtl. The attribute has no defaults.

The processing of this attribute is primarily performed by the presentation layer. For example, the rendering section in this specification defines a mapping from this attribute to the CSS 'direction' and 'unicode-bidi' properties, and CSS defines rendering in terms of those properties.

The directionality of an element, which is used in particular by the canvas element's text rendering API, is either 'ltr' or 'rtl'. If the user agent supports CSS and the 'direction' property on this element has a computed value of either 'ltr' or 'rtl', then that is the directionality of the element. Otherwise, if the element is being rendered, then the directionality of the element is the directionality used by the presentation layer, potentially determined from the value of the dir attribute on the element. Otherwise, if the element's dir attribute has the state ltr, the element's directionality is 'ltr' (left-to-right); if the attribute has the state rtl, the element's directionality is 'rtl' (right-to-left); and otherwise, the element's directionality is the same as its parent element, or 'ltr' if there is no parent element.

document . dir [ = value ]

Returns the html element's dir attribute's value, if any.

Can be set, to either "ltr" or "rtl", to replace the html element's dir attribute's value.

If there is no html element, returns the empty string and ignores new values.

The dir IDL attribute on an element must reflect the dir content attribute of that element, limited to only known values.

The dir IDL attribute on HTMLDocument objects must reflect the dir content attribute of the html element, if any, limited to only known values. If there is no such element, then the attribute must return the empty string and do nothing on setting.

Authors are strongly encouraged to use the dir attribute to indicate text direction rather than using CSS, since that way their documents will continue to render correctly even in the absence of CSS (e.g. as interpreted by search engines).

2.2.3.6 The class attribute

Status: Last call for comments

Every HTML element may have a class attribute specified.

The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.

The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)

Assigning classes to an element affects class matching in selectors in CSS, the getElementsByClassName() method in the DOM, and other such features.

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

The className and classList IDL attributes must both reflect the class content attribute.

2.2.3.7 The style attribute

Status: Last call for comments

All HTML elements may have the style content attribute set. This is a CSS styling attribute as defined by the CSS Styling Attribute Syntax specification. [CSSATTR]

In user agents that support CSS, the attribute's value must be parsed when the attribute is added or has its value changed, according to the rules given for CSS styling attributes. [CSSATTR]

Documents that use style attributes on any of their elements must still be comprehensible and usable if those attributes were removed.

In particular, using the style attribute to hide and show content, or to convey meaning that is otherwise not included in the document, is non-conforming. (To hide and show content, use the hidden attribute.)

element . style

Returns a CSSStyleDeclaration object for the element's style attribute.

The style IDL attribute must return a CSSStyleDeclaration whose value represents the declarations specified in the attribute, if present. Mutating the CSSStyleDeclaration object must create a style attribute on the element (if there isn't one already) and then change its value to be a value representing the serialized form of the CSSStyleDeclaration object. [CSSOM]

In the following example, the words that refer to colors are marked up using the span element and the style attribute to make those words show up in the relevant colors in visual media.

<p>My sweat suit is <span style="color: green; background:
transparent">green</span> and my eyes are <span style="color: blue;
background: transparent">blue</span>.</p>
2.2.3.8 Embedding custom non-visible data

Status: Last call for comments

A custom data attribute is an attribute in no namespace whose name starts with the string "data-", has at least one character after the hyphen, is XML-compatible, and contains no characters in the range U+0041 to U+005A (LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z).

All attributes on HTML elements in HTML documents get ASCII-lowercased automatically, so the restriction on ASCII uppercase letters doesn't affect such documents.

Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.

These attributes are not intended for use by software that is independent of the site that uses the attributes.

For instance, a site about music could annotate list items representing tracks in an album with custom data attributes containing the length of each track. This information could then be used by the site itself to allow the user to sort the list by track length, or to filter the list for tracks of certain lengths.

<ol>
 <li data-length="2m11s">Beyond The Sea</li>
 ...
</ol>

It would be inappropriate, however, for the user to use generic software not associated with that music site to search for tracks of a certain length by looking at this data.

This is because these attributes are intended for use by the site's own scripts, and are not a generic extension mechanism for publicly-usable metadata.

Every HTML element may have any number of custom data attributes specified, with any value.

element . dataset

Returns a DOMStringMap object for the element's data-* attributes.

The dataset IDL attribute provides convenient accessors for all the data-* attributes on an element. On getting, the dataset IDL attribute must return a DOMStringMap object, associated with the following algorithms, which expose these attributes on their element:

The algorithm for getting the list of name-value pairs
  1. Let list be an empty list of name-value pairs.
  2. For each content attribute on the element whose first five characters are the string "data-", add a name-value pair to list whose name is the attribute's name with the first five character removed and whose value is the attribute's value.
  3. Return list.
The algorithm for setting names to certain values
  1. Let name be the concatenation of the string data- and the name passed to the algorithm.
  2. Let value be the value passed to the algorithm.
  3. Set the value of the attribute with the name name, to the value value, replacing any previous value if the attribute already existed. If setAttribute() would have raised an exception when setting an attribute with the name name, then this must raise the same exception.
The algorithm for deleting names
  1. Let name be the concatenation of the string data- and the name passed to the algorithm.
  2. Remove the attribute with the name name, if such an attribute exists. Do nothing otherwise.

If a Web page wanted an element to represent a space ship, e.g. as part of a game, it would have to use the class attribute along with data-* attributes:

<div class="spaceship" data-id="92432"
     data-weapons="laser 2" data-shields="50%"
     data-x="30" data-y="10" data-z="90">
 <button class="fire"
         onclick="spaceships[this.parentNode.dataset.id].fire()">
  Fire
 </button>
</div>

Authors should carefully design such extensions so that when the attributes are ignored and any associated CSS dropped, the page is still usable.

User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.

JavaScript libraries may use the custom data attributes, as they are considered to be part of the page on which they are used. Authors of libraries that are reused by many authors are encouraged to include their name in the attribute names, to reduce the risk of clashes.

For example, a library called "DoQuery" could use attribute names like data-doquery-range, and a library called "jJo" could use attributes names like data-jjo-range.

2.2.4 Element definitions

Status: Last call for comments

Each element in this specification has a definition that includes the following information:

Categories
A list of categories to which the element belongs. These are used when defining the content models for each element.
Contexts in which this element may be used
A non-normative description of where the element can be used. This information is redundant with the content models of elements that allow this one as a child, and is provided only as a convenience.
Content model
A normative description of what content must be included as children and descendants of the element.
Content attributes
A normative list of attributes that may be specified on the element.
DOM interface
A normative definition of a DOM interface that such elements must implement.

This is then followed by a description of what the element represents, along with any additional normative conformance criteria that may apply to authors and implementations. Examples are sometimes also included.

2.2.5 Content models

Status: Last call for comments

Each element defined in this specification has a content model: a description of the element's expected contents. An HTML element must have contents that match the requirements described in the element's content model.

As noted in the conformance and terminology sections, for the purposes of determining if an element matches its content model or not, CDATASection nodes in the DOM are treated as equivalent to Text nodes, and entity reference nodes are treated as if they were expanded in place.

The space characters are always allowed between elements. User agents represent these characters between elements in the source markup as text nodes in the DOM. Empty text nodes and text nodes consisting of just sequences of those characters are considered inter-element whitespace.

Inter-element whitespace, comment nodes, and processing instruction nodes must be ignored when establishing whether an element's contents match the element's content model or not, and must be ignored when following algorithms that define document and element semantics.

An element A is said to be preceded or followed by a second element B if A and B have the same parent node and there are no other element nodes or text nodes (other than inter-element whitespace) between them.

Authors must not use HTML elements anywhere except where they are explicitly allowed, as defined for each element, or as explicitly required by other specifications. For XML compound documents, these contexts could be inside elements from other namespaces, if those elements are defined as providing the relevant contexts.

The Atom specification defines the Atom content element, when its type attribute has the value xhtml, as requiring that it contains a single HTML div element. Thus, a div element is allowed in that context, even though this is not explicitly normatively stated by this specification. [ATOM]

In addition, HTML elements may be orphan nodes (i.e. without a parent node).

For example, creating a td element and storing it in a global variable in a script is conforming, even though td elements are otherwise only supposed to be used inside tr elements.

var data = {
  name: "Banana",
  cell: document.createElement('td'),
};
2.2.5.1 Kinds of content

Status: Last call for comments

Each element in HTML falls into zero or more categories that group elements with similar characteristics together. The following broad categories are used in this specification:

Some elements also fall into other categories, which are defined in other parts of this specification.

These categories are related as follows:

Sectioning content, heading content, phrasing content, and embedded content are all types of flow content. Embedded content is also a type of phrasing content.

In addition, certain elements are categorized as form-associated elements and further subcategorized to define their role in various form-related processing models.

Some elements have unique requirements and do not fit into any particular category.

2.2.5.1.1 Metadata content

Status: Last call for comments

Metadata content is content that sets up the presentation or behavior of the rest of the content, or that sets up the relationship of the document with other documents, or that conveys other "out of band" information.

Elements from other namespaces whose semantics are primarily metadata-related (e.g. RDF) are also metadata content.

Thus, in the XML serialization, one can use RDF, like this:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 <head>
  <title>Hedral's Home Page</title>
  <r:RDF>
   <Person xmlns="http://www.w3.org/2000/10/swap/pim/contact#"
           r:about="http://hedral.example.com/#">
    <fullName>Cat Hedral</fullName>
    <mailbox r:resource="mailto:hedral@damowmow.com"/>
    <personalTitle>Sir</personalTitle>
   </Person>
  </r:RDF>
 </head>
 <body>
  <h1>My home page</h1>
  <p>I like playing with string, I guess. Sister says squirrels are fun
  too so sometimes I follow her to play with them.</p>
 </body>
</html>

This isn't possible in the HTML serialization, however.

2.2.5.1.2 Flow content

Status: Last call for comments

Most elements that are used in the body of documents and applications are categorized as flow content.

As a general rule, elements whose content model allows any flow content should have either at least one descendant text node that is not inter-element whitespace, or at least one descendant element node that is embedded content. For the purposes of this requirement, del elements and their descendants must not be counted as contributing to the ancestors of the del element.

This requirement is not a hard requirement, however, as there are many cases where an element can be empty legitimately, for example when it is used as a placeholder which will later be filled in by a script, or when the element is part of a template and would on most pages be filled in but on some pages is not relevant.

2.2.5.1.3 Sectioning content

Status: Last call for comments

Sectioning content is content that defines the scope of headings and footers.

Each sectioning content element potentially has a heading and an outline. See the section on headings and sections for further details.

There are also certain elements that are sectioning roots. These are distinct from sectioning content, but they can also have an outline.

2.2.5.1.4 Heading content

Status: Last call for comments

Heading content defines the header of a section (whether explicitly marked up using sectioning content elements, or implied by the heading content itself).

2.2.5.1.5 Phrasing content

Status: Last call for comments

Phrasing content is the text of the document, as well as elements that mark up that text at the intra-paragraph level. Runs of phrasing content form paragraphs.

As a general rule, elements whose content model allows any phrasing content should have either at least one descendant text node that is not inter-element whitespace, or at least one descendant element node that is embedded content. For the purposes of this requirement, nodes that are descendants of del elements must not be counted as contributing to the ancestors of the del element.

Most elements that are categorized as phrasing content can only contain elements that are themselves categorized as phrasing content, not any flow content.

Text, in the context of content models, means text nodes. Text is sometimes used as a content model on its own, but is also phrasing content, and can be inter-element whitespace (if the text nodes are empty or contain just space characters).

2.2.5.1.6 Embedded content

Status: Last call for comments

Embedded content is content that imports another resource into the document, or content from another vocabulary that is inserted into the document.

Elements that are from namespaces other than the HTML namespace and that convey content but not metadata, are embedded content for the purposes of the content models defined in this specification. (For example, MathML, or SVG.)

Some embedded content elements can have fallback content: content that is to be used when the external resource cannot be used (e.g. because it is of an unsupported format). The element definitions state what the fallback is, if any.

2.2.5.1.7 Interactive content

Status: Last call for comments

Interactive content is content that is specifically intended for user interaction.

Certain elements in HTML have an activation behavior, which means that the user can activate them. This triggers a sequence of events dependent on the activation mechanism, and normally culminating in a click event followed by a DOMActivate event, as described below.

The user agent should allow the user to manually trigger elements that have an activation behavior, for instance using keyboard or voice input, or through mouse clicks. When the user triggers an element with a defined activation behavior in a manner other than clicking it, the default action of the interaction event must be to run synthetic click activation steps on the element.

When a user agent is to run synthetic click activation steps on an element, the user agent must run pre-click activation steps on the element, then fire a click event at the element. The default action of this click event must be to run post-click activation steps on the element. If the event is canceled, the user agent must run canceled activation steps on the element instead.

Given an element target, the nearest activatable element is the element returned by the following algorithm:

  1. If target has a defined activation behavior, then return target and abort these steps.

  2. If target has a parent element, then set target to that parent element and return to the first step.

  3. Otherwise, there is no nearest activatable element.

When a pointing device is clicked, the user agent must run these steps:

  1. Let e be the nearest activatable element of the element designated by the user, if any.

  2. If there is an element e, run pre-click activation steps on it.

  3. Dispatch the required click event.

    If there is an element e, then the default action of the click event must be to run post-click activation steps on element e.

    If there is an element e but the event is canceled, the user agent must run canceled activation steps on element e.

The above doesn't happen for arbitrary synthetic events dispatched by author script. However, the click() method can be used to make it happen programmatically.

When a user agent is to run pre-click activation steps on an element, it must run the pre-click activation steps defined for that element, if any.

When a user agent is to run post-click activation steps on an element, the user agent must fire a simple event named DOMActivate that is cancelable at that element. The default action of this event must be to run final activation steps on that element. If the event is canceled, the user agent must run canceled activation steps on the element instead.

When a user agent is to run canceled activation steps on an element, it must run the canceled activation steps defined for that element, if any.

When a user agent is to run final activation steps on an element, it must run the activation behavior defined for that element. Activation behaviors can refer to the click and DOMActivate events that were fired by the steps above leading up to this point.

2.2.5.2 Transparent content models

Status: Last call for comments

Some elements are described as transparent; they have "transparent" in the description of their content model.

When a content model includes a part that is "transparent", those parts must not contain content that would not be conformant if all transparent elements in the tree were replaced, in their parent element, by the children in the "transparent" part of their content model, retaining order.

Consider the following markup fragment:

<p>Hello <a href="world.html"><em>wonderful</em> world</a>!</p>

Its DOM looks like the following:

The content model of the a element is transparent. To see if its contents are conforming, therefore, the element is replaced by its contents:

Since that is conforming, the contents of the a are conforming in the original fragment.

When a transparent element has no parent, then the part of its content model that is "transparent" must instead be treated as accepting any flow content.

2.2.5.3 Paragraphs

Status: Last call for comments

The term paragraph as defined in this section is distinct from (though related to) the p element defined later. The paragraph concept defined here is used to describe how to interpret documents.

A paragraph is typically a run of phrasing content that forms a block of text with one or more sentences that discuss a particular topic, as in typography, but can also be used for more general thematic grouping. For instance, an address is also a paragraph, as is a part of a form, a byline, or a stanza in a poem.

In the following example, there are two paragraphs in a section. There is also a heading, which contains phrasing content that is not a paragraph. Note how the comments and inter-element whitespace do not form paragraphs.

<section>
  <h1>Example of paragraphs</h1>
  This is the <em>first</em> paragraph in this example.
  <p>This is the second.</p>
  <!-- This is not a paragraph. -->
</section>

Paragraphs in flow content are defined relative to what the document looks like without the a, ins, del, and map elements complicating matters, since those elements, with their hybrid content models, can straddle paragraph boundaries, as shown in the first two examples below.

Generally, having elements straddle paragraph boundaries is best avoided. Maintaining such markup can be difficult.

The following example takes the markup from the earlier example and puts ins and del elements around some of the markup to show that the text was changed (though in this case, the changes admittedly don't make much sense). Notice how this example has exactly the same paragraphs as the previous one, despite the ins and del elements — the ins element straddles the heading and the first paragraph, and the del element straddles the boundary between the two paragraphs.

<section>
  <ins><h1>Example of paragraphs</h1>
  This is the <em>first</em> paragraph in</ins> this example<del>.
  <p>This is the second.</p></del>
  <!-- This is not a paragraph. -->
</section>

Let view be a view of the DOM that replaces all a, ins, del, and map elements in the document with their contents. Then, in view, for each run of sibling phrasing content nodes uninterrupted by other types of content, in an element that accepts content other than phrasing content as well as phrasing content, let first be the first node of the run, and let last be the last node of the run. For each such run that consists of at least one node that is neither embedded content nor inter-element whitespace, a paragraph exists in the original DOM from immediately before first to immediately after last. (Paragraphs can thus span across a, ins, del, and map elements.)

Conformance checkers may warn authors of cases where they have paragraphs that overlap each other (this can happen with object, video, audio, and canvas elements).

A paragraph is also formed explicitly by p elements.

The p element can be used to wrap individual paragraphs when there would otherwise not be any content other than phrasing content to separate the paragraphs from each other.

In the following example, the link spans half of the first paragraph, all of the heading separating the two paragraphs, and half of the second paragraph. It straddles the paragraphs and the heading.

<aside>
 Welcome!
 <a href="about.html">
  This is home of...
  <h1>The Falcons!</h1>
  The Lockheed Martin multirole jet fighter aircraft!
 </a>
 This page discusses the F-16 Fighting Falcon's innermost secrets.
</aside>

Here is another way of marking this up, this time showing the paragraphs explicitly, and splitting the one link element into three:

<aside>
 <p>Welcome! <a href="about.html">This is home of...</a></p>
 <h1><a href="about.html">The Falcons!</a></h1>
 <p><a href="about.html">The Lockheed Martin multirole jet
 fighter aircraft!</a> This page discusses the F-16 Fighting
 Falcon's innermost secrets.</p>
</aside>

It is possible for paragraphs to overlap when using certain elements that define fallback content. For example, in the following section:

<section>
 <h1>My Cats</h1>
 You can play with my cat simulator.
 <object data="cats.sim">
  To see the cat simulator, use one of the following links:
  <ul>
   <li><a href="cats.sim">Download simulator file</a>
   <li><a href="http://sims.example.com/watch?v=LYds5xY4INU">Use online simulator</a>
  </ul>
  Alternatively, upgrade to the Mellblom Browser.
 </object>
 I'm quite proud of it.
</section>

There are five paragraphs:

  1. The paragraph that says "You can play with my cat simulator. object I'm quite proud of it.", where object is the object element.
  2. The paragraph that says "To see the cat simulator, use one of the following links:".
  3. The paragraph that says "Download simulator file".
  4. The paragraph that says "Use online simulator".
  5. The paragraph that says "Alternatively, upgrade to the Mellblom Browser.".

The first paragraph is overlapped by the other four. A user agent that supports the "cats.sim" resource will only show the first one, but a user agent that shows the fallback will confusingly show the first sentence of the first paragraph as if it was in the same paragraph as the second one, and will show the last paragraph as if it was at the start of the second sentence of the first paragraph.

To avoid this confusion, explicit p elements can be used.

2.2.6 Annotations for assistive technology products (ARIA)

Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below. These exceptions are intended to prevent authors from making assistive technology products report nonsensical states that do not represent the actual state of the document. [ARIA]

User agents are required to implement ARIA semantics on all HTML elements, as defined in the ARIA specifications. The implicit ARIA semantics defined below must be recognised by implementations. [ARIAIMPL]

The following table defines the strong native semantics and corresponding implicit ARIA semantics that apply to HTML elements. Each language feature (element or attribute) in a cell in the first column implies the ARIA semantics (role, states, and/or properties) given in the cell in the second column of the same row. Authors must not set the ARIA role and aria-* attributes in a manner that conflicts with the semantics described in the following table. When multiple rows apply to an element, the role from the last row to define a role must be applied, and the states and properties from all the rows must be combined.

Language feature Strong native semantics and implied ARIA semantics
a element that represents a hyperlink link role
address element contentinfo role
area element that represents a hyperlink link role
button element button role
datalist element listbox role, with the aria-multiselectable property set to "false"
footer element contentinfo role
h1 element that does not have an hgroup ancestor heading role, with the aria-level property set to the element's outline depth
h2 element that does not have an hgroup ancestor heading role, with the aria-level property set to the element's outline depth
h3 element that does not have an hgroup ancestor heading role, with the aria-level property set to the element's outline depth
h4 element that does not have an hgroup ancestor heading role, with the aria-level property set to the element's outline depth
h5 element that does not have an hgroup ancestor heading role, with the aria-level property set to the element's outline depth
h6 element that does not have an hgroup ancestor heading role, with the aria-level property set to the element's outline depth
hgroup element heading role, with the aria-level property set to the element's outline depth
hr element separator role
img element whose alt attribute's value is empty presentation role
input element with a type attribute in the Button state button role
input element with a type attribute in the Checkbox state checkbox role, with the aria-checked state set to "mixed" if the element's indeterminate IDL attribute is true, or "true" if the element's checkedness is true, or "false" otherwise
input element with a type attribute in the Color state No role
input element with a type attribute in the Date state No role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Date and Time state No role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Local Date and Time state No role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the E-mail state with no suggestions source element textbox role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the File Upload state button role
input element with a type attribute in the Hidden state No role
input element with a type attribute in the Image Button state button role
input element with a type attribute in the Month state No role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Number state spinbutton role, with the aria-readonly state set to "true" if the element has a readonly attribute, the aria-valuemax property set to the element's maximum, the aria-valuemin property set to the element's minimum, and, if the result of applying the rules for parsing floating point number values to the element's value is a number, with the aria-valuenow property set to that number
input element with a type attribute in the Password state textbox role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Radio Button state radio role, with the aria-checked state set to "true" if the element's checkedness is true, or "false" otherwise
input element with a type attribute in the Range state slider role, with the aria-valuemax property set to the element's maximum, the aria-valuemin property set to the element's minimum, and the aria-valuenow property set to the result of applying the rules for parsing floating point number values to the element's value, if that that results in a number, or the default value otherwise
input element with a type attribute in the Reset Button state button role
input element with a type attribute in the Search state with no suggestions source element textbox role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Submit Button state button role
input element with a type attribute in the Telephone state with no suggestions source element textbox role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Text state with no suggestions source element textbox role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Text, Search, Telephone, URL, or E-mail states with a suggestions source element combobox role, with the aria-owns property set to the same value as the list attribute, and the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Time state No role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the URL state with no suggestions source element textbox role, with the aria-readonly state set to "true" if the element has a readonly attribute
input element with a type attribute in the Week state No role, with the aria-readonly state set to "true" if the element has a readonly attribute
link element that represents a hyperlink link role
menu element with a type attribute in the context menu state No role
menu element with a type attribute in the list state menu role
menu element with a type attribute in the toolbar state toolbar role
nav element navigation role
option element that is in a list of options or that represents a suggestion in a datalist element option role, with the aria-selected state set to "true" if the element's selectedness is true, or "false" otherwise.
progress element progressbar role, with, if the progress bar is determinate, the aria-valuemax property set to the maximum value of the progress bar, the aria-valuemin property set to zero, and the aria-valuenow property set to the current value of the progress bar
select element with a multiple attribute listbox role, with the aria-multiselectable property set to "true"
select element with no multiple attribute listbox role, with the aria-multiselectable property set to "false"
td element gridcell role, with the aria-labelledby property set to the value of the headers attribute, if any
textarea element textbox role, with the aria-multiline property set to "true", and the aria-readonly state set to "true" if the element has a readonly attribute
th element that is neither a column header nor a row header gridcell role, with the aria-labelledby property set to the value of the headers attribute, if any
th element that is a column header columnheader role, with the aria-labelledby property set to the value of the headers attribute, if any
th element that is a row header rowheader role, with the aria-labelledby property set to the value of the headers attribute, if any
tr element row role
An element that defines a command, whose Type facet is "checkbox", and that is a descendant of a menu element whose type attribute in the list state menuitemcheckbox role, with the aria-checked state set to "true" if the command's Checked State facet is true, and "false" otherwise
An element that defines a command, whose Type facet is "command", and that is a descendant of a menu element whose type attribute in the list state menuitem role
An element that defines a command, whose Type facet is "radio", and that is a descendant of a menu element whose type attribute in the list state menuitemradio role, with the aria-checked state set to "true" if the command's Checked State facet is true, and "false" otherwise
Elements that are disabled The aria-disabled state set to "true"
Elements that are required The aria-required state set to "true"

Some HTML elements have native semantics that can be overridden. The following table lists these elements and their implicit ARIA semantics, along with the restrictions that apply to those elements. Each language feature (element or attribute) in a cell in the first column implies, unless otherwise overriden, the ARIA semantic (role, state, or property) given in the cell in the second column of the same row, but this semantic may be overridden under the conditions listed in the cell in the third column of that row.

Language feature Default implied ARIA semantic Restrictions
article element article role Role must be either article, document, application, or main
aside element note role Role must be either note, complementary, or search
header element No role If specified, role must be banner
li element whose parent is an ol or ul element listitem role Role must be either listitem or treeitem
ol element list role Role must be either list, tree, or directory
output element status role No restrictions
section element region role Role must be either region, document, application, contentinfo, main, search, alert, dialog, alertdialog, status, or log
table element grid role Role must be either grid or treegrid
ul element list role Role must be either list or tree, or directory
The body element document role Role must be either document or application

User agents may apply different defaults than those described in this section in order to expose the semantics of HTML elements in a manner more fine-grained than possible with the above definitions.

Conformance checkers are encouraged to phrase errors such that authors are encouraged to use more appropriate elements rather than remove accessibility annotations. For example, if an a element is marked as having the button role, a conformance checker could say "Either a button element or an input element is required when using the button role" rather than "The button role cannot be used with a elements".

2.3 APIs in HTML documents

Status: Last call for comments

For HTML documents, and for HTML elements in HTML documents, certain APIs defined in DOM Core become case-insensitive or case-changing, as sometimes defined in DOM Core, and as summarized or required below. [DOMCORE]

This does not apply to XML documents or to elements that are not in the HTML namespace despite being in HTML documents.

Element.tagName and Node.nodeName

These attributes must return element names converted to ASCII uppercase, regardless of the case with which they were created.

Document.createElement()

The canonical form of HTML markup is all-lowercase; thus, this method will lowercase the argument before creating the requisite element. Also, the element created must be in the HTML namespace.

This doesn't apply to Document.createElementNS(). Thus, it is possible, by passing this last method a tag name in the wrong case, to create an element that appears to have the same tag name as that of an element defined in this specification when its tagName attribute is examined, but that doesn't support the corresponding interfaces. The "real" element name (unaffected by case conversions) can be obtained from the localName attribute.

Element.setAttribute()
Element.setAttributeNode()

Attribute names are converted to ASCII lowercase.

Specifically: when an attribute is set on an HTML element using Element.setAttribute(), the name argument must be converted to ASCII lowercase before the element is affected; and when an Attr node is set on an HTML element using Element.setAttributeNode(), it must have its name converted to ASCII lowercase before the element is affected.

This doesn't apply to Document.setAttributeNS() and Document.setAttributeNodeNS().

Element.getAttribute()
Element.getAttributeNode()

Attribute names are converted to ASCII lowercase.

Specifically: When the Element.getAttribute() method or the Element.getAttributeNode() method is invoked on an HTML element, the name argument must be converted to ASCII lowercase before the element's attributes are examined.

This doesn't apply to Document.getAttributeNS() and Document.getAttributeNodeNS().

Document.getElementsByTagName()
Element.getElementsByTagName()

HTML elements match by lower-casing the argument before comparison, elements from other namespaces are treated as in XML (case-sensitively).

Specifically, these methods (but not their namespaced counterparts) must compare the given argument in a case-sensitive manner, but when looking at HTML elements, the argument must first be converted to ASCII lowercase.

Thus, in an HTML document with nodes in multiple namespaces, these methods will effectively be both case-sensitive and case-insensitive at the same time.

2.4 Interactions with XPath and XSLT

Status: Last call for comments

Implementations of XPath 1.0 that operate on HTML documents parsed or created in the manners described in this specification (e.g. as part of the document.evaluate() API) must act as if the following edit was applied to the XPath 1.0 specification.

First, remove this paragraph:

A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.

Then, insert in its place the following:

A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. If the QName has a prefix, then there must be a namespace declaration for this prefix in the expression context, and the corresponding namespace URI is the one that is associated with this prefix. It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.

If the QName has no prefix and the principal node type of the axis is element, then the default element namespace is used. Otherwise if the QName has no prefix, the namespace URI is null. The default element namespace is a member of the context for the XPath expression. The value of the default element namespace when executing an XPath expression through the DOM3 XPath API is determined in the following way:

  1. If the context node is from an HTML DOM, the default element namespace is "http://www.w3.org/1999/xhtml".
  2. Otherwise, the default element namespace URI is null.

This is equivalent to adding the default element namespace feature of XPath 2.0 to XPath 1.0, and using the HTML namespace as the default element namespace for HTML documents. It is motivated by the desire to have implementations be compatible with legacy HTML content while still supporting the changes that this specification introduces to HTML regarding the namespace used for HTML elements, and by the desire to use XPath 1.0 rather than XPath 2.0.

This change is a willful violation of the XPath 1.0 specification, motivated by desire to have implementations be compatible with legacy content while still supporting the changes that this specification introduces to HTML regarding which namespace is used for HTML elements. [XPATH10]

XSLT 1.0 processors outputting to a DOM when the output method is "html" (either explicitly or via the defaulting rule in XSLT 1.0) are affected as follows:

If the transformation program outputs an element in no namespace, the processor must, prior to constructing the corresponding DOM element node, change the namespace of the element to the HTML namespace, ASCII-lowercase the element's local name, and ASCII-lowercase the names of any non-namespaced attributes on the element.

This requirement is a willful violation of the XSLT 1.0 specification, required because this specification changes the namespaces and case-sensitivity rules of HTML in a manner that would otherwise be incompatible with DOM-based XSLT transformations. (Processors that serialize the output are unaffected.) [XSLT10]

2.5 Dynamic markup insertion

Status: Last call for comments

APIs for dynamically inserting markup into the document interact with the parser, and thus their behavior varies depending on whether they are used with HTML documents (and the HTML parser) or XHTML in XML documents (and the XML parser).

2.5.1 Opening the input stream

Status: Last call for comments

The open() method comes in several variants with different numbers of arguments.

document = document . open( [ type [, replace ] ] )

Causes the Document to be replaced in-place, as if it was a new Document object, but reusing the previous object, which is then returned.

If the type argument is omitted or has the value "text/html", then the resulting Document has an HTML parser associated with it, which can be given data to parse using document.write(). Otherwise, all content passed to document.write() will be parsed as plain text.

If the replace argument is present and has the value "replace", the existing entries in the session history for the Document object are removed.

The method has no effect if the Document is still being parsed.

Throws an INVALID_STATE_ERR exception if the Document is an XML document.

window = document . open( url, name, features [, replace ] )

Works like the window.open() method.

When called with two or fewer arguments, the method must act as follows:

  1. If the Document object is not flagged as an HTML document, throw an INVALID_STATE_ERR exception and abort these steps.

  2. Let type be the value of the first argument, if there is one, or "text/html" otherwise.

  3. Let replace be true if there is a second argument and it is an ASCII case-insensitive match for the value "replace", and false otherwise.

  4. If the document has an active parser that isn't a script-created parser, and the insertion point associated with that parser's input stream is not undefined (that is, it does point to somewhere in the input stream), then the method does nothing. Abort these steps and return the Document object on which the method was invoked.

    This basically causes document.open() to be ignored when it's called in an inline script found during the parsing of data sent over the network, while still letting it have an effect when called asynchronously or on a document that is itself being spoon-fed using these APIs.

  5. Release the storage mutex.

  6. Prompt to unload the Document object. If the user refused to allow the document to be unloaded, then these steps must be aborted.

  7. Unload the Document object, with the recycle parameter set to true.

  8. If the document has an active parser, then abort that parser, and throw away any pending content in the input stream.

  9. Unregister all event listeners registered on the Document node and its descendants.

  10. Remove any tasks associated with the Document in any task source.

  11. Remove all child nodes of the document, without firing any mutation events.

  12. Replace the Document's singleton objects with new instances of those objects. (This includes in particular the Window, Location, History, ApplicationCache, UndoManager, Navigator, and Selection objects, the various BarProp objects, the two Storage objects, and the various HTMLCollection objects. It also includes all the Web IDL prototypes in the JavaScript binding, including the Document object's prototype.)

  13. Change the document's character encoding to UTF-16.

  14. Change the document's address to the entry script's browsing context's active document's address.

  15. Create a new HTML parser and associate it with the document. This is a script-created parser (meaning that it can be closed by the document.open() and document.close() methods, and that the tokenizer will wait for an explicit call to document.close() before emitting an end-of-file token). The encoding confidence is irrelevant.

  16. If the type string contains a U+003B SEMICOLON character (;), remove the first such character and all characters from it up to the end of the string.

    Strip all leading and trailing space characters from type.

    If type is not now an ASCII case-insensitive match for the string "text/html", then act as if the tokenizer had emitted a start tag token with the tag name "pre", then switch the HTML parser's tokenizer to the PLAINTEXT state.

  17. If replace is false, then:

    1. Remove all the entries in the browsing context's session history after the current entry in its Document's History object
    2. Remove any earlier entries that share the same Document
    3. Add a new entry just before the last entry that is associated with the text that was parsed by the previous parser associated with the Document object, as well as the state of the document at the start of these steps. (This allows the user to step backwards in the session history to see the page before it was blown away by the document.open() call.)

  18. Finally, set the insertion point to point at just before the end of the input stream (which at this point will be empty).

  19. Return the Document on which the method was invoked.

When called with three or more arguments, the open() method on the HTMLDocument object must call the open() method on the Window object of the HTMLDocument object, with the same arguments as the original call to the open() method, and return whatever that method returned. If the HTMLDocument object has no Window object, then the method must raise an INVALID_ACCESS_ERR exception.

2.5.2 Closing the input stream

Status: Last call for comments

document . close()

Closes the input stream that was opened by the document.open() method.

Throws an INVALID_STATE_ERR exception if the Document is an XML document.

The close() method must run the following steps:

  1. If the Document object is not flagged as an HTML document, throw an INVALID_STATE_ERR exception and abort these steps.

  2. If there is no script-created parser associated with the document, then abort these steps.

  3. Insert an explicit "EOF" character at the end of the parser's input stream.

  4. If there is a pending parsing-blocking script, then abort these steps.

  5. Run the tokenizer, processing resulting tokens as they are emitted, and stopping when the tokenizer reaches the explicit "EOF" character or spins the event loop.

2.5.3 document.write()

document . write(text...)

Adds the given string(s) to the Document's input stream. If necessary, calls the open() method implicitly first.

This method throws an INVALID_ACCESS_ERR exception when invoked on XML documents.

The document.write(...) method must act as follows:

  1. If the method was invoked on an XML document, throw an INVALID_ACCESS_ERR exception and abort these steps.

  2. If the insertion point is undefined, the open() method must be called (with no arguments) on the document object. If the user refused to allow the document to be unloaded, then these steps must be aborted. Otherwise, the insertion point will point at just before the end of the (empty) input stream.

  3. The string consisting of the concatenation of all the arguments to the method must be inserted into the input stream just before the insertion point.

  4. If there is a pending parsing-blocking script, then the method must now return without further processing of the input stream.

  5. Otherwise, the tokenizer must process the characters that were inserted, one at a time, processing resulting tokens as they are emitted, and stopping when the tokenizer reaches the insertion point or when the processing of the tokenizer is aborted by the tree construction stage (this can happen if a script end tag token is emitted by the tokenizer).

    If the document.write() method was called from script executing inline (i.e. executing because the parser parsed a set of script tags), then this is a reentrant invocation of the parser.

  6. Finally, the method must return.

2.5.4 document.writeln()

document . writeln(text...)

Adds the given string(s) to the Document's input stream, followed by a newline character. If necessary, calls the open() method implicitly first.

This method throws an INVALID_ACCESS_ERR exception when invoked on XML documents.

The document.writeln(...) method, when invoked, must act as if the document.write() method had been invoked with the same argument(s), plus an extra argument consisting of a string containing a single line feed character (U+000A).

2.5.5 innerHTML

Status: Last call for comments

The innerHTML IDL attribute represents the markup of the node's contents.

document . innerHTML [ = value ]

Returns a fragment of HTML or XML that represents the Document.

Can be set, to replace the Document's contents with the result of parsing the given string.

In the case of XML documents, will throw an INVALID_STATE_ERR if the Document cannot be serialized to XML, and a SYNTAX_ERR if the given string is not well-formed.

element . innerHTML [ = value ]

Returns a fragment of HTML or XML that represents the element's contents.

Can be set, to replace the contents of the element with nodes parsed from the given string.

In the case of XML documents, will throw an INVALID_STATE_ERR if the element cannot be serialized to XML, and a SYNTAX_ERR if the given string is not well-formed.

On getting, if the node's document is an HTML document, then the attribute must return the result of running the HTML fragment serialization algorithm on the node; otherwise, the node's document is an XML document, and the attribute must return the result of running the XML fragment serialization algorithm on the node instead (this might raise an exception instead of returning a string).

On setting, the following steps must be run:

  1. If the node's document is an HTML document: Invoke the HTML fragment parsing algorithm.

    If the node's document is an XML document: Invoke the XML fragment parsing algorithm.

    In either case, the algorithm must be invoked with the string being assigned into the innerHTML attribute as the input. If the node is an Element node, then, in addition, that element must be passed as the context element.

    If this raises an exception, then abort these steps.

    Otherwise, let new children be the nodes returned.

  2. If the attribute is being set on a Document node, and that document has an active parser, then abort that parser.

  3. Remove the child nodes of the node whose innerHTML attribute is being set, firing appropriate mutation events.

  4. If the attribute is being set on a Document node, let target document be that Document node. Otherwise, the attribute is being set on an Element node; let target document be the ownerDocument of that Element.

  5. Set the ownerDocument of all the nodes in new children to the target document.

  6. Append all the new children nodes to the node whose innerHTML attribute is being set, preserving their order, and firing mutation events as if a DocumentFragment containing the new children had been inserted.

2.5.6 outerHTML

Status: Last call for comments

The outerHTML IDL attribute represents the markup of the element and its contents.

element . outerHTML [ = value ]

Returns a fragment of HTML or XML that represents the element and its contents.

Can be set, to replace the element with nodes parsed from the given string.

In the case of XML documents, will throw an INVALID_STATE_ERR if the element cannot be serialized to XML, and a SYNTAX_ERR if the given string is not well-formed.

Throws a NO_MODIFICATION_ALLOWED_ERR exception if the parent of the element is the Document node.

On getting, if the node's document is an HTML document, then the attribute must return the result of running the HTML fragment serialization algorithm on a fictional node whose only child is the node on which the attribute was invoked; otherwise, the node's document is an XML document, and the attribute must return the result of running the XML fragment serialization algorithm on that fictional node instead (this might raise an exception instead of returning a string).

On setting, the following steps must be run:

  1. Let target be the element whose outerHTML attribute is being set.

  2. If target has no parent node, then abort these steps. There would be no way to obtain a reference to the nodes created even if the remaining steps were run.

  3. If target's parent node is a Document object, throw a NO_MODIFICATION_ALLOWED_ERR exception and abort these steps.

  4. Let parent be target's parent node, unless that is a DocumentFragment node, in which case let parent be an arbitrary body element.

  5. If target's document is an HTML document: Invoke the HTML fragment parsing algorithm.

    If target's document is an XML document: Invoke the XML fragment parsing algorithm.

    In either case, the algorithm must be invoked with the string being assigned into the outerHTML attribute as the input, and parent as the context element.

    If this raises an exception, then abort these steps.

    Otherwise, let new children be the nodes returned.

  6. Set the ownerDocument of all the nodes in new children to target's document.

  7. Remove target from its parent node, firing mutation events as appropriate, and then insert in its place all the new children nodes, preserving their order, and again firing mutation events as if a DocumentFragment containing the new children had been inserted.

2.5.7 insertAdjacentHTML()

element . insertAdjacentHTML(position, text)

Parses the given string text as HTML or XML and inserts the resulting nodes into the tree in the position given by the position argument, as follows:

"beforebegin"
Before the element itself.
"afterbegin"
Just inside the element, before its first child.
"beforeend"
Just inside the element, after its last child.
"afterend"
After the element itself.

Throws a SYNTAX_ERR exception if the arguments have invalid values (e.g., in the case of XML documents, if the given string is not well-formed).

Throws a NO_MODIFICATION_ALLOWED_ERR exception if the given position isn't possible (e.g. inserting elements after the root element of a Document).

The insertAdjacentHTML(position, text) method, when invoked, must run the following algorithm:

  1. Let position and text be the method's first and second arguments, respectively.

  2. Let target be the element on which the method was invoked.

  3. Use the first matching item from this list:

    If position is an ASCII case-insensitive match for the string "beforebegin"
    If position is an ASCII case-insensitive match for the string "afterend"

    If target has no parent node, then abort these steps.

    If target's parent node is a Document object, then throw a NO_MODIFICATION_ALLOWED_ERR exception and abort these steps.

    Otherwise, let context be the parent node of target.

    If position is an ASCII case-insensitive match for the string "afterbegin"
    If position is an ASCII case-insensitive match for the string "beforeend"

    Let context be the same as target.

    Otherwise

    Throw a SYNTAX_ERR exception.

  4. If target's document is an HTML document: Invoke the HTML fragment parsing algorithm.

    If target's document is an XML document: Invoke the XML fragment parsing algorithm.

    In either case, the algorithm must be invoked with text as the input, and the element selected in by the previous step as the context element.

    If this raises an exception, then abort these steps.

    Otherwise, let new children be the nodes returned.

  5. Set the ownerDocument of all the nodes in new children to target's document.

  6. Use the first matching item from this list:

    If position is an ASCII case-insensitive match for the string "beforebegin"

    Insert all the new children nodes immediately before target.

    If position is an ASCII case-insensitive match for the string "afterbegin"

    Insert all the new children nodes before the first child of target, if there is one. If there is no such child, append them all to target.

    If position is an ASCII case-insensitive match for the string "beforeend"

    Append all the new children nodes to target.

    If position is an ASCII case-insensitive match for the string "afterend"

    Insert all the new children nodes immediately after target.

    The new children nodes must be inserted in a manner that preserves their order and fires mutation events as if a DocumentFragment containing the new children had been inserted.

3 The elements of HTML

3.1 The root element

Status: Last call for comments

3.1.1 The html element

Status: Last call for comments

Categories
None.
Contexts in which this element may be used:
As the root element of a document.
Wherever a subdocument fragment is allowed in a compound document.
Content model:
A head element followed by a body element.
Content attributes:
Global attributes
manifest
DOM interface:
interface HTMLHtmlElement : HTMLElement {};

The html element represents the root of an HTML document.

The manifest attribute gives the address of the document's application cache manifest, if there is one. If the attribute is present, the attribute's value must be a valid URL.

The manifest attribute only has an effect during the early stages of document load. Changing the attribute dynamically thus has no effect (and thus, no DOM API is provided for this attribute).

For the purposes of application cache selection, later base elements cannot affect the resolving of relative URLs in manifest attributes, as the attributes are processed before those elements are seen.

The html element in the following example declares that the document's language is English.

<!DOCTYPE html>
<html lang="en">
<head>
<title>Swapping Songs</title>
</head>
<body>
<h1>Swapping Songs</h1>
<p>Tonight I swapped some of the songs I wrote with some friends, who
gave me some of the songs they wrote. I love sharing my music.</p>
</body>
</html>

3.2 Document metadata

Status: Last call for comments

3.2.1 The head element

Status: Last call for comments

Categories
None.
Contexts in which this element may be used:
As the first element in an html element.
Content model:
One or more elements of metadata content, of which exactly one is a title element.
Content attributes:
Global attributes
DOM interface:
interface HTMLHeadElement : HTMLElement {};

The head element represents a collection of metadata for the Document.

The collection of metadata in a head element can be large or small. Here is an example of a very short one:

<!doctype html>
<html>
 <head>
  <title>A document with a short head</title>
 </head>
 <body>
 ...

Here is an example of a longer one:

<!DOCTYPE HTML>
<HTML>
 <HEAD>
  <META CHARSET="UTF-8">
  <BASE HREF="http://www.example.com/">
  <TITLE>An application with a long head</TITLE>
  <LINK REL="STYLESHEET" HREF="default.css">
  <LINK REL="STYLESHEET ALTERNATE" HREF="big.css" TITLE="Big Text">
  <SCRIPT SRC="support.js"></SCRIPT>
  <META NAME="APPLICATION-NAME" CONTENT="Long headed application">
 </HEAD>
 <BODY>
 ...

3.2.2 The title element

Status: Last call for comments

Categories
Metadata content.
Contexts in which this element may be used:
In a head element containing no other title elements.
Content model:
Text.
Content attributes:
Global attributes
DOM interface:
interface HTMLTitleElement : HTMLElement {
           attribute DOMString text;
};

The title element represents the document's title or name. Authors should use titles that identify their documents even when they are used out of context, for example in a user's history or bookmarks, or in search results. The document's title is often different from its first heading, since the first heading does not have to stand alone when taken out of context.

There must be no more than one title element per document.

title . text [ = value ]

Returns the contents of the element, ignoring child nodes that aren't text nodes.

Can be set, to replace the element's children with the given value.

The IDL attribute text must return a concatenation of the contents of all the text nodes that are direct children of the title element (ignoring any other nodes such as comments or elements), in tree order. On setting, it must act the same way as the textContent IDL attribute.

Here are some examples of appropriate titles, contrasted with the top-level headings that might be used on those same pages.

  <title>Introduction to The Mating Rituals of Bees</title>
    ...
  <h1>Introduction</h1>
  <p>This companion guide to the highly successful
  <cite>Introduction to Medieval Bee-Keeping</cite> book is...

The next page might be a part of the same site. Note how the title describes the subject matter unambiguously, while the first heading assumes the reader knows what the context is and therefore won't wonder if the dances are Salsa or Waltz:

  <title>Dances used during bee mating rituals</title>
    ...
  <h1>The Dances</h1>

The string to use as the document's title is given by the document.title IDL attribute. User agents should use the document's title when referring to the document in their user interface.

3.2.3 The base element

Status: Last call for comments

Categories
Metadata content.
Contexts in which this element may be used:
In a head element containing no other base elements.
Content model:
Empty.
Content attributes:
Global attributes
href
target
DOM interface:
interface HTMLBaseElement : HTMLElement {
           attribute DOMString href;
           attribute DOMString target;
};

The base element allows authors to specify the document base URL for the purposes of resolving relative URLs, and the name of the default browsing context for the purposes of following hyperlinks. The element does not represent any content beyond this information.

There must be no more than one base element per document.

A base element must have either an href attribute, a target attribute, or both.

The href content attribute, if specified, must contain a valid URL.

A base element, if it has an href attribute, must come before any other elements in the tree that have attributes defined as taking URLs, except the html element (its manifest attribute isn't affected by base elements).

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

The target attribute, if specified, must contain a valid browsing context name or keyword, which specifies which browsing context is to be used as the default when hyperlinks and forms in the Document cause navigation.

A base element, if it has a target attribute, must come before any elements in the tree that represent hyperlinks.

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

The href and target IDL attributes must reflect the respective content attributes of the same name.

In this example, a base element is used to set the document base URL:

<!DOCTYPE html>
<html>
    <head>
        <title>This is an example for the &lt;base&gt; element</title>
        <base href="http://www.example.com/news/index.html">
    </head>
    <body>
        <p>Visit the <a href="archives.html">archives</a>.</p>
    </body>
</html>

The link in the above example would be a link to "http://www.example.com/news/archives.html".

Status: Last call for comments

Categories
Metadata content.
Contexts in which this element may be used:
Where metadata content is expected.
In a noscript element that is a child of a head element.
Content model:
Empty.
Content attributes:
Global attributes
href
rel
media
hreflang
type
sizes
Also, the title attribute has special semantics on this element.
DOM interface:
interface HTMLLinkElement : HTMLElement {
           attribute boolean disabled;
           attribute DOMString href;
           attribute DOMString rel;
  readonly attribute DOMTokenList relList;
           attribute DOMString media;
           attribute DOMString hreflang;
           attribute DOMString type;
           attribute DOMString sizes;
};
HTMLLinkElement implements LinkStyle;

The link element allows authors to link their document to other resources.

The destination of the link(s) is given by the href attribute, which must be present and must contain a valid URL. If the href attribute is absent, then the element does not define a link.

A link element must have rel attribute.

The types of link indicated (the relationships) are given by the value of the rel attribute, which, if present, must have a value that is a set of space-separated tokens. The allowed values and their meanings are defined in a later section. If the rel attribute is absent, or if the values used are not allowed according to the definitions in this specification, then the element does not define a link.

Two categories of links can be created using the link element. Links to external resources are links to resources that are to be used to augment the current document, and hyperlink links are links to other documents. The link types section defines whether a particular link type is an external resource or a hyperlink. One element can create multiple links (of which some might be external resource links and some might be hyperlinks); exactly which and how many links are created depends on the keywords given in the rel attribute. User agents must process the links on a per-link basis, not a per-element basis.

Each link is handled separately. For instance, if there are two link elements with rel="stylesheet", they each count as a separate external resource, and each is affected by its own attributes independently.

The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type. Some of the attributes control whether or not the external resource is to be applied (as defined below). For external resources that are represented in the DOM (for example, style sheets), the DOM representation must be made available even if the resource is not applied. To obtain the resource, the user agent must resolve the URL given by the href attribute, relative to the element, and then fetch the resulting absolute URL. User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied.

The semantics of the protocol used (e.g. HTTP) must be followed when fetching external resources. (For example, redirects will be followed and 404 responses will cause the external resource to not be applied.)

Once the attempts to obtain the resource and its critical subresources are complete, the user agent must, if the loads were successful, queue a task to fire a simple event named load at the link element, or, if the resource or one of its critical subresources failed to completely load for any reason (e.g. DNS error, HTTP 404 response, a connection being prematurely closed, unsupported Content-Type), queue a task to fire a simple event named error at the link element. Non-network errors in processing the resource or its subresources (e.g. CSS parse errors, PNG decoding errors) are not failures for the purposes of this paragraph.

The task source for these tasks is the DOM manipulation task source.

The element must delay the load event of the element's document until all the attempts to obtain the resource and its critical subresources are complete. (Resources that the user agent has not yet attempted to obtain, e.g. because it is waiting for the resource to be needed, do not delay the load event.)

Which resources are considered critical or not is defined by the relevant specification. For CSS resources, only @import rules introduce critical subresources; other resources, e.g. fonts or backgrounds, are not.

Interactive user agents may provide users with a means to follow the hyperlinks created using the link element, somewhere within their user interface. The exact interface is not defined by this specification, but it could include the following information (obtained from the element's attributes, again as defined below), in some form or another (possibly simplified), for each hyperlink created with each link element in the document:

User agents could also include other information, such as the type of the resource (as given by the type attribute).

Hyperlinks created with the link element and its rel attribute apply to the whole page. This contrasts with the rel attribute of a and area elements, which indicates the type of a link whose context is given by the link's location within the document.

The media attribute says which media the resource applies to. The value must be a valid media query.

If the link is a hyperlink then the media attribute is purely advisory, and describes for which media the document in question was designed.

However, if the link is an external resource link, then the media attribute is prescriptive. The user agent must apply the external resource to a view when the media attribute's value matches the environment of that view and the other relevant conditions apply, and must not apply it otherwise.

The external resource might have further restrictions defined within that limit its applicability. For example, a CSS style sheet might have some @media blocks. This specification does not override such further restrictions or requirements.

The default, if the media attribute is omitted, is "all", meaning that by default links apply to all media.

The hreflang attribute on the link element has the same semantics as the hreflang attribute on hyperlink elements.

The type attribute gives the MIME type of the linked resource. It is purely advisory. The value must be a valid MIME type, optionally with parameters.

For external resource links, the type attribute is used as a hint to user agents so that they can avoid fetching resources they do not support. If the attribute is present, then the user agent must assume that the resource is of the given type (even if that is not a valid MIME type, e.g. the empty string). If the attribute is omitted, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type. If the UA does not support the given MIME type for the given link relationship, then the UA should not obtain the resource; if the UA does support the given MIME type for the given link relationship, then the UA should obtain the resource. If the attribute is omitted, and the external resource link type does not have a default type defined, but the user agent would obtain the resource if the type was known and supported, then the user agent should obtain the resource under the assumption that it will be supported.

User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must not use the type attribute to determine its actual type. Only the actual type (as defined in the next paragraph) is used to determine whether to apply the resource, not the aforementioned assumed type.

The stylesheet link type defines rules for processing the resource's Content-Type metadata.

Once the user agent has established the type of the resource, the user agent must apply the resource if it is of a supported type and the other relevant conditions apply, and must ignore the resource otherwise.

If a document contains style sheet links labeled as follows:

<link rel="stylesheet" href="A" type="text/plain">
<link rel="stylesheet" href="B" type="text/css">
<link rel="stylesheet" href="C">

...then a compliant UA that supported only CSS style sheets would fetch the B and C files, and skip the A file (since text/plain is not the MIME type for CSS style sheets).

For files B and C, it would then check the actual types returned by the server. For those that are sent as text/css, it would apply the styles, but for those labeled as text/plain, or any other type, it would not.

If one of the two files was returned without a Content-Type metadata, or with a syntactically incorrect type like Content-Type: "null", then the default type for stylesheet links would kick in. Since that default type is text/css, the style sheet would nonetheless be applied.

The title attribute gives the title of the link. With one exception, it is purely advisory. The value is text. The exception is for style sheet links, where the title attribute defines alternative style sheet sets.

The title attribute on link elements differs from the global title attribute of most other elements in that a link without a title does not inherit the title of the parent element: it merely has no title.

The sizes attribute is used with the icon link type. The attribute must not be specified on link elements that do not have a rel attribute that specifies the icon keyword.

Some versions of HTTP defined a Link: header, to be processed like a series of link elements. If supported, for the purposes of ordering links defined by HTTP headers must be assumed to come before any links in the document, in the order that they were given in the HTTP entity header. (URIs in these headers are to be processed and resolved according to the rules given in HTTP; the rules of this specification don't apply.) [HTTP] [WEBLINK]

The IDL attributes href, rel, media, hreflang, and type, and sizes each must reflect the respective content attributes of the same name.

The IDL attribute relList must reflect the rel content attribute.

The IDL attribute disabled only applies to style sheet links. When the link element defines a style sheet link, then the disabled attribute behaves as defined for the alternative style sheets DOM. For all other link elements it always return false and does nothing on setting.

The LinkStyle interface is also implemented by this element; the styling processing model defines how. [CSSOM]

Here, a set of link elements provide some style sheets:

<!-- a persistent style sheet -->
<link rel="stylesheet" href="default.css">

<!-- the preferred alternate style sheet -->
<link rel="stylesheet" href="green.css" title="Green styles">

<!-- some alternate style sheets -->
<link rel="alternate stylesheet" href="contrast.css" title="High contrast">
<link rel="alternate stylesheet" href="big.css" title="Big fonts">
<link rel="alternate stylesheet" href="wide.css" title="Wide screen">

The following example shows how you can specify versions of the page that use alternative formats, are aimed at other languages, and that are intended for other media:

<link rel=alternate href="/en/html" hreflang=en type=text/html title="English HTML">
<link rel=alternate href="/fr/html" hreflang=fr type=text/html title="French HTML">
<link rel=alternate href="/en/html/print" hreflang=en type=text/html media=print title="English HTML (for printing)">
<link rel=alternate href="/fr/html/print" hreflang=fr type=text/html media=print title="French HTML (for printing)">
<link rel=alternate href="/en/pdf" hreflang=en type=application/pdf title="English PDF">
<link rel=alternate href="/fr/pdf" hreflang=fr type=application/pdf title="French PDF">

3.2.5 The meta element

Status: Last call for comments

Categories
Metadata content.
Contexts in which this element may be used:
If the charset attribute is present, or if the element's http-equiv attribute is in the Encoding declaration state: in a head element.
If the http-equiv attribute is present but not in the Encoding declaration state: in a head element.
If the http-equiv attribute is present but not in the Encoding declaration state: in a noscript element that is a child of a head element.
If the name attribute is present: where metadata content is expected.
Content model:
Empty.
Content attributes:
Global attributes
name
http-equiv
content
charset
DOM interface:
interface HTMLMetaElement : HTMLElement {
           attribute DOMString name;
           attribute DOMString httpEquiv;
           attribute DOMString content;
};

The meta element represents various kinds of metadata that cannot be expressed using the title, base, link, style, and script elements.

The meta element can represent document-level metadata with the name attribute, pragma directives with the http-equiv attribute, and the file's character encoding declaration when an HTML document is serialized to string form (e.g. for transmission over the network or for disk storage) with the charset attribute.

Exactly one of the name, http-equiv, and charset attributes must be specified.

If either name or http-equiv is specified, then the content attribute must also be specified. Otherwise, it must be omitted.

The charset attribute specifies the character encoding used by the document. This is a character encoding declaration. If the attribute is present in an XML document, its value must be an ASCII case-insensitive match for the string "UTF-8" (and the document is therefore forced to use UTF-8 as its encoding).

The charset attribute on the meta element has no effect in XML documents, and is only allowed in order to facilitate migration to and from XHTML.

There must not be more than one meta element with a charset attribute per document.

The content attribute gives the value of the document metadata or pragma directive when the element is used for those purposes. The allowed values depend on the exact context, as described in subsequent sections of this specification.

If a meta element has a name attribute, it sets document metadata. Document metadata is expressed in terms of name/value pairs, the name attribute on the meta element giving the name, and the content attribute on the same element giving the value. The name specifies what aspect of metadata is being set; valid names and the meaning of their values are described in the following sections. If a meta element has no content attribute, then the value part of the metadata name/value pair is the empty string.

The name and content IDL attributes must reflect the respective content attributes of the same name. The IDL attribute httpEquiv must reflect the content attribute http-equiv.

3.2.5.1 Standard metadata names

Status: Last call for comments

This specification defines a few names for the name attribute of the meta element.

Names are case-insensitive, and must be compared in an ASCII case-insensitive manner.

application-name

The value must be a short free-form string 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. There must not be more than one meta element with its name attribute set to the value application-name per document. 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.

author

The value must be a free-form string giving the name of one of the page's authors.

description

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. There must not be more than one meta element with its name attribute set to the value description per document.

generator

The value must be a free-form string that identifies one of the software packages used to generate the document. This value must not be used on hand-authored pages.

Here is what a tool called "Frontweaver" could include in its output, in the page's head element, to identify itself as the tool used to generate the page:

<meta name=generator content="Frontweaver 8.2">
3.2.5.2 Other metadata names

Status: Last call for comments. ISSUE-27 (rel-ownership) blocks progress to Last Call

Extensions to the predefined set of metadata names may be registered in the WHATWG Wiki MetaExtensions page. [WHATWGWIKI]

Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a type. These new names must be specified with the following information:

Keyword

The actual name being defined. The name should not be confusingly similar to any other defined name (e.g. differing only in case).

Brief description

A short non-normative description of what the metadata name's meaning is, including the format the value is required to be in.

Specification
A link to a more detailed description of the metadata name's semantics and requirements. It could be another page on the Wiki, or a link to an external page.
Synonyms

A list of other names that have exactly the same processing requirements. Authors should not use the names defined to be synonyms, they are only intended to allow user agents to support legacy content. Anyone may remove synonyms that are not used in practice; only names that need to be processed as synonyms for compatibility with legacy content are to be registered in this way.

Status

One of the following:

Proposed
The name has not received wide peer review and approval. Someone has proposed it and is, or soon will be, using it.
Ratified
The name has received wide peer review and approval. It has a specification that unambiguously defines how to handle pages that use the name, including when they use it in incorrect ways.
Discontinued
The metadata name has received wide peer review and it has been found wanting. Existing pages are using this metadata name, but new pages should avoid it. The "brief description" and "specification" entries will give details of what authors should use instead, if anything.

If a metadata name is found to be redundant with existing values, it should be removed and listed as a synonym for the existing value.

If a metadata name is registered in the "proposed" state for a period of a month or more without being used or specified, then it may be removed from the registry.

If a metadata name is added with the "proposed" status and found to be redundant with existing values, it should be removed and listed as a synonym for the existing value. If a metadata name is added with the "proposed" status and found to be harmful, then it should be changed to "discontinued" status.

Anyone can change the status at any time, but should only do so in accordance with the definitions above.

Conformance checkers must use the information given on the WHATWG Wiki MetaExtensions page to establish if a value is allowed or not: values defined in this specification or marked as "proposed" or "ratified" must be accepted, whereas values marked as "discontinued" or not listed in either this specification or on the aforementioned page must be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).

When an author uses a new metadata name not defined by either this specification or the Wiki page, conformance checkers should offer to add the value to the Wiki, with the details described above, with the "proposed" status.

Metadata names whose values are to be URLs must not be proposed or accepted. Links must be represented using the link element, not the meta element.

3.2.5.3 Pragma directives

Status: Last call for comments

When the http-equiv attribute is specified on a meta element, the element is a pragma directive.

The http-equiv attribute is an enumerated attribute. The following table lists the keywords defined for this attribute. The states given in the first cell of the rows with keywords give the states to which those keywords map.

State Keywords Notes
Content Language content-language Conformance checkers will include a warning
Encoding declaration content-type
Default style default-style
Refresh refresh

When a meta element is inserted into the document, if its http-equiv attribute is present and represents one of the above states, then the user agent must run the algorithm appropriate for that state, as described in the following list:

Content language state (http-equiv="content-language")

This pragma sets the document-wide default language. Until the pragma is successfully processed, there is no document-wide default language.

Conformance checkers will include a warning if this pragma is used. Authors are encouraged to use the lang attribute instead.

  1. If another meta element with an http-equiv attribute in the Content Language state has already been successfully processed (i.e. when it was inserted the user agent processed it and reached the last step of this list of steps), then abort these steps.

  2. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  3. Let input be the value of the element's content attribute.

  4. Let position point at the first character of input.

  5. Skip whitespace.

  6. Collect a sequence of characters that are neither space characters nor a U+002C COMMA character (,).

  7. Let the document-wide default language be the string that resulted from the previous step.

For meta elements with an http-equiv attribute in the Content Language state, the content attribute must have a value consisting of a valid BCP 47 language code. [BCP47]

This pragma is not exactly equivalent to the HTTP Content-Language header, for instance it only supports one language. [HTTP]

Encoding declaration state (http-equiv="content-type")

The Encoding declaration state is just an alternative form of setting the charset attribute: it is a character encoding declaration. This state's user agent requirements are all handled by the parsing section of the specification.

For meta elements with an http-equiv attribute in the Encoding declaration state, the content attribute must have a value that is an ASCII case-insensitive match for a string that consists of: the literal string "text/html;", optionally followed by any number of space characters, followed by the literal string "charset=", followed by the character encoding name of the character encoding declaration.

If the document contains a meta element with an http-equiv attribute in the Encoding declaration state, then the document must not contain a meta element with the charset attribute present.

The Encoding declaration state may be used in HTML documents, but elements with an http-equiv attribute in that state must not be used in XML documents.

Default style state (http-equiv="default-style")

This pragma sets the name of the default alternative style sheet set.

  1. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  2. Set the preferred style sheet set to the value of the element's content attribute. [CSSOM]

Refresh state (http-equiv="refresh")

This pragma acts as timed redirect.

  1. If another meta element with an http-equiv attribute in the Refresh state has already been successfully processed (i.e. when it was inserted the user agent processed it and reached the last step of this list of steps), then abort these steps.

  2. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  3. Let input be the value of the element's content attribute.

  4. Let position point at the first character of input.

  5. Skip whitespace.

  6. Collect a sequence of characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), and parse the resulting string using the rules for parsing non-negative integers. If the sequence of characters collected is the empty string, then no number will have been parsed; abort these steps. Otherwise, let time be the parsed number.

  7. Collect a sequence of characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) and U+002E FULL STOP (.). Ignore any collected characters.

  8. Skip whitespace.

  9. Let url be the address of the current page.

  10. If the character in input pointed to by position is a U+003B SEMICOLON (";"), then advance position to the next character. Otherwise, jump to the last step.

  11. Skip whitespace.

  12. If the character in input pointed to by position is a U+0055 LATIN CAPITAL LETTER U character (U) or a U+0075 LATIN SMALL LETTER U character (u), then advance position to the next character. Otherwise, jump to the last step.

  13. If the character in input pointed to by position is a U+0052 LATIN CAPITAL LETTER R character (R) or a U+0072 LATIN SMALL LETTER R character (r), then advance position to the next character. Otherwise, jump to the last step.

  14. If the character in input pointed to by position is s U+004C LATIN CAPITAL LETTER L character (L) or a U+006C LATIN SMALL LETTER L character (l), then advance position to the next character. Otherwise, jump to the last step.

  15. Skip whitespace.

  16. If the character in input pointed to by position is a U+003D EQUALS SIGN ("="), then advance position to the next character. Otherwise, jump to the last step.

  17. Skip whitespace.

  18. If the character in input pointed to by position is either a U+0027 APOSTROPHE character (') or U+0022 QUOTATION MARK character ("), then let quote be that character, and advance position to the next character. Otherwise, let quote be the empty string.

  19. Let url be equal to the substring of input from the character at position to the end of the string.

  20. If quote is not the empty string, and there is a character in url equal to quote, then truncate url at that character, so that it and all subsequent characters are removed.

  21. Strip any trailing space characters from the end of url.

  22. Strip any U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), and U+000D CARRIAGE RETURN (CR) characters from url.

  23. Resolve the url value to an absolute URL, relative to the meta element. If this fails, abort these steps.

  24. Perform one or more of the following steps:

    • Set a timer so that in time seconds, adjusted to take into account user or user agent preferences, if the user has not canceled the redirect, the user agent navigates the document's browsing context to url, with replacement enabled, and with the document's browsing context as the source browsing context.

    • Provide the user with an interface that, when selected, navigates a browsing context to url, with the document's browsing context as the source browsing context.

    • Do nothing.

    In addition, the user agent may, as with anything, inform the user of any and all aspects of its operation, including the state of any timers, the destinations of any timed redirects, and so forth.

For meta elements with an http-equiv attribute in the Refresh state, the content attribute must have a value consisting either of:

In the former case, the integer represents a number of seconds before the page is to be reloaded; in the latter case the integer represents a number of seconds before the page is to be replaced by the page at the given URL.

A news organization's front page could include the following markup in the page's head element, to ensure that the page automatically reloads from the server every five minutes:

<meta http-equiv="Refresh" content="300">

A sequence of pages could be used as an automated slide show by making each page refresh to the next page in the sequence, using markup such as the following:

<meta http-equiv="Refresh" content="20; URL=page4.html">

There must not be more than one meta element with any particular state in the document at a time.

3.2.5.4 Other pragma directives

Status: Last call for comments

Extensions to the predefined set of pragma directives may, under certain conditions, be registered in the WHATWG Wiki PragmaExtensions page. [WHATWGWIKI]

Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry, and must have behavior identical to that described for the HTTP header. [IANAPERMHEADERS]

Pragma directives corresponding to headers describing metadata, or not requiring specific user agent processing, must not be registered; instead, use metadata names. Pragma directives corresponding to headers that affect the HTTP processing model (e.g. caching) must not be registered, as they would result in HTTP-level behavior being different for user agents that implement HTML than for user agents that do not.

Anyone is free to edit the WHATWG Wiki PragmaExtensions page at any time to add a pragma directive satisfying these conditions. Such registrations must specify the following information:

Keyword

The actual name being defined. The name must match a previously-registered HTTP name with the same requirements.

Brief description

A short non-normative description of the purpose of the pragma directive.

Specification
A link to the specification defining the corresponding HTTP header.

Conformance checkers must use the information given on the WHATWG Wiki PragmaExtensions page to establish if a value is allowed or not: values defined in this specification or listed on the aforementioned page must be accepted, whereas values not listed in either this specification or on the aforementioned page must be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).

3.2.5.5 Specifying the document's character encoding

Status: Last call for comments

A character encoding declaration is a mechanism by which the character encoding used to store or transmit a document is specified.

The following restrictions apply to character encoding declarations:

If an HTML document does not start with a BOM, and if its encoding is not explicitly given by Content-Type metadata, then the character encoding used must be an ASCII-compatible character encoding, and, in addition, if that encoding isn't US-ASCII itself, then the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state.

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

Authors are encouraged to use UTF-8. Conformance checkers may advise authors against using legacy encodings.

Authoring tools should default to using UTF-8 for newly-created documents.

Encodings in which a series of bytes in the range 0x20 to 0x7E can encode characters other than the corresponding characters in the range U+0020 to U+007E represent a potential security vulnerability: a user agent that does not support the encoding (or does not support the label used to declare the encoding, or does not use the same mechanism to detect the encoding of unlabelled content as another user agent) might end up interpreting technically benign plain text content as HTML tags and JavaScript. For example, this applies to encodings in which the bytes corresponding to "<script>" in ASCII can encode a different string. Authors should not use such encodings, which are known to include JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), encodings based on ISO-2022, and encodings based on EBCDIC. Furthermore, authors must not use the CESU-8, UTF-7, BOCU-1 and SCSU encodings, which also fall into this category, because these encodings were never intended for use for Web content. [RFC1345] [RFC1842] [RFC1468] [RFC2237] [RFC1554] [RFC1922] [RFC1557] [CESU8] [UTF7] [BOCU1] [SCSU]

Authors should not use UTF-32, as the HTML5 encoding detection algorithms intentionally do not distinguish it from UTF-16. [UNICODE]

Using non-UTF-8 encodings can have unexpected results on form submission and URL encodings, which use the document's character encoding by default.

In XHTML, the XML declaration should be used for inline character encoding information, if necessary.

In HTML, to declare that the character encoding is UTF-8, the author could include the following markup near the top of the document (in the head element):

<meta charset="utf-8">

In XML, the XML declaration would be used instead, at the very top of the markup:

<?xml version="1.0" encoding="utf-8"?>

3.2.6 The style element

Status: Last call for comments

Categories
Metadata content.
If the scoped attribute is present: flow content.
Contexts in which this element may be used:
If the scoped attribute is absent: where metadata content is expected.
If the scoped attribute is absent: in a noscript element that is a child of a head element.
If the scoped attribute is present: where flow content is expected, but before any other flow content other than other style elements and inter-element whitespace.
Content model:
Depends on the value of the type attribute, but must match requirements described in prose below.
Content attributes:
Global attributes
media
type
scoped
Also, the title attribute has special semantics on this element.
DOM interface:
interface HTMLStyleElement : HTMLElement {
           attribute boolean disabled;
           attribute DOMString media;
           attribute DOMString type;
           attribute boolean scoped;
};
HTMLStyleElement implements LinkStyle;

The style element allows authors to embed style information in their documents. The style element is one of several inputs to the styling processing model. The element does not represent content for the user.

If the type attribute is given, it must contain a valid MIME type, optionally with parameters, that designates a styling language. If the attribute is absent, the type defaults to text/css. [RFC2318]

When examining types to determine if they support the language, user agents must not ignore unknown MIME parameters — types with unknown parameters must be assumed to be unsupported. The charset parameter must be treated as an unknown parameter for the purpose of comparing MIME types here.

The media attribute says which media the styles apply to. The value must be a valid media query. The user agent must apply the styles to a view when the media attribute's value matches the environment of that view and the other relevant conditions apply, and must not apply them otherwise.

The styles might be further limited in scope, e.g. in CSS with the use of @media blocks. This specification does not override such further restrictions or requirements.

The default, if the media attribute is omitted, is "all", meaning that by default styles apply to all media.

The scoped attribute is a boolean attribute. If set, it indicates that the styles are intended just for the subtree rooted at the style element's parent element, as opposed to the whole Document.

If the scoped attribute is present, then the user agent must apply the specified style information only to the style element's parent element (if any), and that element's child nodes. Otherwise, the specified styles must, if applied, be applied to the entire document.

The title attribute on style elements defines alternative style sheet sets. If the style element has no title attribute, then it has no title; the title attribute of ancestors does not apply to the style element. [CSSOM]

The title attribute on style elements, like the title attribute on link elements, differs from the global title attribute in that a style block without a title does not inherit the title of the parent element: it merely has no title.

The textContent of a style element must match the style production in the following ABNF, the character set for which is Unicode. [ABNF]

style         = no-c-start *( c-start no-c-end c-end no-c-start )
no-c-start    = <any string that doesn't contain a substring that matches c-start >
c-start       = "<!--"
no-c-end      = <any string that doesn't contain a substring that matches c-end >
c-end         = "-->"

All descendant elements must be processed, according to their semantics, before the style element itself is evaluated. For styling languages that consist of pure text, user agents must evaluate style elements by passing the concatenation of the contents of all the text nodes that are direct children of the style element (not any other nodes such as comments or elements), in tree order, to the style system. For XML-based styling languages, user agents must pass all the child nodes of the style element to the style system.

All URLs found by the styling language's processor must be resolved, relative to the element (or as defined by the styling language), when the processor is invoked.

Once the attempts to obtain the style sheet's critical subresources, if any, are complete, or, if the style sheet has no critical subresources, once the style sheet has been parsed and processed, the user agent must, if the loads were successful or there were none, queue a task to fire a simple event named load at the style element, or, if one of the style sheet's critical subresources failed to completely load for any reason (e.g. DNS error, HTTP 404 response, a connection being prematurely closed, unsupported Content-Type), queue a task to fire a simple event named error at the style element. Non-network errors in processing the style sheet or its subresources (e.g. CSS parse errors, PNG decoding errors) are not failures for the purposes of this paragraph.

The task source for these tasks is the DOM manipulation task source.

The element must delay the load event of the element's document until all the attempts to obtain the style sheet's critical subresources, if any, are complete.

Which resources are considered critical or not is defined by the relevant specification. For CSS resources, only @import rules introduce critical subresources; other resources, e.g. fonts or backgrounds, are not.

This specification does not specify a style system, but CSS is expected to be supported by most Web browsers. [CSS]

The media, type and scoped IDL attributes must reflect the respective content attributes of the same name.

The disabled IDL attribute behaves as defined for the alternative style sheets DOM.

The LinkStyle interface is also implemented by this element; the styling processing model defines how. [CSSOM]

The following document has its emphasis styled as bright red text rather than italics text, while leaving titles of works and Latin words in their default italics. It shows how using appropriate elements enables easier restyling of documents.

<!DOCTYPE html>
<html lang="en-US">
 <head>
  <title>My favorite book</title>
  <style>
   body { color: black; background: white; }
   em { font-style: normal; color: red; }
  </style>
 </head>
 <body>
  <p>My <em>favorite</em> book of all time has <em>got</em> to be
  <cite>A Cat's Life</cite>. It is a book by P. Rahmel that talks
  about the <i lang="la">Felis Catus</i> in modern human society.</p>
 </body>
</html>

3.2.7 Styling

Status: Last call for comments

The link and style elements can provide styling information for the user agent to use when rendering the document. The DOM Styling specification specifies what styling information is to be used by the user agent and how it is to be used. [CSSOM]

The style and link elements implement the LinkStyle interface. [CSSOM]

For style elements, if the user agent does not support the specified styling language, then the sheet attribute of the element's LinkStyle interface must return null. Similarly, link elements that do not represent external resource links that contribute to the styling processing model (i.e. that do not have a stylesheet keyword in their rel attribute), and link elements whose specified resource has not yet been fetched, or is not in a supported styling language, must have their LinkStyle interface's sheet attribute return null.

Otherwise, the LinkStyle interface's sheet attribute must return a StyleSheet object with the following properties: [CSSOM]

The style sheet type

The style sheet type must be the same as the style's specified type. For style elements, this is the same as the type content attribute's value, or text/css if that is omitted. For link elements, this is the Content-Type metadata of the specified resource.

The style sheet location

For link elements, the location must be the result of resolving the URL given by the element's href content attribute, relative to the element, or the empty string if that fails. For style elements, there is no location.

The style sheet media

The media must be the same as the value of the element's media content attribute, or the empty string, if the attribute is omitted.

The style sheet title

The title must be the same as the value of the element's title content attribute, if the attribute is present and has a non-empty value. If the attribute is absent or its value is the empty string, then the style sheet does not have a title (it is the empty string). The title is used for defining alternative style sheet sets.

The style sheet alternate flag

For link elements, true if the link is an alternative stylesheet. In all other cases, false.

The disabled IDL attribute on link and style elements must return false and do nothing on setting, if the sheet attribute of their LinkStyle interface is null. Otherwise, it must return the value of the StyleSheet interface's disabled attribute on getting, and forward the new value to that same attribute on setting.

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

Style sheets, whether added by a link element, a style element, an <?xml-stylesheet> PI, an HTTP Link: header, or some other mechanism, have a style sheet ready flag, which is initially unset.

When a style sheet is ready to be applied, its style sheet ready flag must be set. If the style sheet referenced no other resources (e.g. it was an internal style sheet given by a style element with no @import rules), then the style rules must be synchronously made available to script; otherwise, the style rules must only be made available to script once the event loop reaches its "update the rendering" step.

A style sheet in the context of the Document of an HTML parser or XML parser is said to be a style sheet blocking scripts if the element was created by that Document's parser, and the element is either a style element or a link element that was an external resource link that contributes to the styling processing model when the element was created by the parser, and the element's style sheet was enabled when the element was created by the parser, and the element's style sheet ready flag is not yet set, and, the last time the event loop reached step 1, the element was in that Document.

3.3 Scripting

Status: Last call for comments

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.

3.3.1 The script element

Status: Last call for comments

Categories
Metadata content.
Flow content.
Phrasing content.
Contexts in which this element may be used:
Where metadata content is expected.
Where phrasing content is expected.
Content model:
If there is no src attribute, depends on the value of the type attribute, but must match script content restrictions.
If there is a src attribute, the element must be either empty or contain only script documentation that also matches script content restrictions.
Content attributes:
Global attributes
src
async
defer
type
charset
DOM interface:
interface HTMLScriptElement : HTMLElement {
           attribute DOMString src;
           attribute boolean async;
           attribute boolean defer;
           attribute DOMString type;
           attribute DOMString charset;
           attribute DOMString text;
};

The script element allows authors to include dynamic script and data blocks in their documents. The element does not represent content for the user.

When used to include dynamic scripts, the scripts may either be embedded inline or may be imported from an external file using the src attribute. If the language is not that described by "text/javascript", then the type attribute must be present, as described below.

When used to include data blocks, the data must be embedded inline, the format of the data must be given using the type attribute, and the src attribute must not be specified.

The type attribute gives the language of the script or format of the data. If the attribute is present, its value must be a valid MIME type, optionally with parameters. The charset parameter must not be specified. (The default, which is used if the attribute is absent, is "text/javascript".)

The src attribute, if specified, gives the address of the external script resource to use. The value of the attribute must be a valid URL identifying a script resource of the type given by the type attribute, if the attribute is present, or of the type "text/javascript", if the attribute is absent. A resource is a script resource of a given type if that type identifies a scripting language and the resource conforms with the requirements of that language's specification.

The charset attribute gives the character encoding of the external script resource. The attribute must not be specified if the src attribute is not present. If the attribute is set, its value must be a valid character encoding name, must be an ASCII case-insensitive match for the preferred MIME name for that encoding, and must match the encoding given in the charset parameter of the Content-Type metadata of the external file, if any. [IANACHARSET]

The async and defer attributes are boolean attributes that indicate how the script should be executed.

There are three possible modes that can be selected using these attributes. If the async attribute is present, then the script will be executed asynchronously, as soon as it is available. If the async attribute is not present but the defer attribute is present, then the script is executed when the page has finished parsing. If neither attribute is present, then the script is fetched and executed immediately, before the user agent continues parsing the page. The exact processing details for these attributes are described below.

The defer attribute may be specified even if the async attribute is specified, to cause legacy Web browsers that only support defer (and not async) to fall back to the defer behavior instead of the synchronous blocking behavior that is the default.

If one or both of the defer and async attributes are specified, the src attribute must also be specified.

Changing the src, type, charset, async, and defer attributes dynamically has no direct effect; these attribute are only used at specific times described below (namely, when the element is inserted into the document).

A script element has several associated pieces of state.

The first is a flag indicating whether or not the script block has been "already started". Initially, script elements must have this flag unset (script blocks, when created, are not "already started"). When a script element is cloned, the "already started" flag, if set, must be propagated to the clone when it is created.

The second is a flag indicating whether the element was "parser-inserted". Initially, script elements must have this flag unset. It is set by the HTML parser and is used to handle document.write() calls.

The third is a flag indicating whether or not the script block is "ready to be parser-executed". Initially, script elements must have this flag unset (script blocks, when created, are not "ready to be parser-executed"). This flag is used only for elements that are also "parser-inserted", to let the parser know when to execute the script.

The fourth and fifth pieces of state are the script block's type and the script block's character encoding. They are determined when the script is run, based on the attributes on the element at that time.

When a script element that is neither marked as having "already started" nor marked as being "parser-inserted" experiences one of the events listed in the following list, the user agent must synchronously run the script element:

Running a script: When a script element is to be run, the user agent must act as follows:

  1. If either:

    • the script element has a type attribute and its value is the empty string, or
    • the script element has no type attribute but it has a language attribute and that attribute's value is the empty string, or
    • the script element has neither a type attribute nor a language attribute, then

    ...let the script block's type for this script element be "text/javascript".

    Otherwise, if the script element has a type attribute, let the script block's type for this script element be the value of that attribute with any leading or trailing sequences of space characters removed.

    Otherwise, the element has a non-empty language attribute; let the script block's type for this script element be the concatenation of the string "text/" followed by the value of the language attribute.

    The language attribute is never conforming, and is always ignored if there is a type attribute present.

  2. If the script element has a charset attribute, then let the script block's character encoding for this script element be the encoding given by the charset attribute.

    Otherwise, let the script block's character encoding for this script element be the same as the encoding of the document itself.

  3. If the script element has a for attribute, then the user agent must abort these steps at this point. The script is not executed.

  4. If scripting is disabled for the script element, or if the user agent does not support the scripting language given by the script block's type for this script element, then the user agent must abort these steps at this point. The script is not executed.

  5. If the element has no src attribute, and its child nodes consist only of comment nodes and empty text nodes, then the user agent must abort these steps at this point. The script is not executed.

  6. The user agent must set the element's "already started" flag.

  7. If the element has a src attribute, then the value of that attribute must be resolved relative to the element, and if that is successful, the specified resource must then be fetched, from the origin of the element's Document.

    For historical reasons, if the URL is a javascript: URL, then the user agent must not, despite the requirements in the definition of the fetching algorithm, actually execute the given script; instead the user agent must act as if it had received an empty HTTP 400 response.

    Once the resource's Content Type metadata is available, if it ever is, apply the algorithm for extracting an encoding from a Content-Type to it. If this returns an encoding, and the user agent supports that encoding, then let the script block's character encoding be that encoding.

    For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.

  8. Then, the first of the following options that describes the situation must be followed:

    If the element has a src attribute, and the element has a defer attribute, and the element has been flagged as "parser-inserted", and the element does not have an async attribute

    The element must be added to the end of the list of scripts that will execute when the document has finished parsing.

    The task that the networking task source places on the task queue once the fetching algorithm has completed must set the element's "ready to be parser-executed" flag. The parser will handle executing the script.

    If the element has a src attribute, and the element has been flagged as "parser-inserted", and the element does not have an async attribute

    The element is the pending parsing-blocking script. (There can only be one such script at a time.)

    The task that the networking task source places on the task queue once the fetching algorithm has completed must set the element's "ready to be parser-executed" flag. The parser will handle executing the script.

    If the element does not have a src attribute, but there is a style sheet blocking scripts, and the element has been flagged as "parser-inserted"

    The element is the pending parsing-blocking script. (There can only be one such script at a time.)

    Set the element's "ready to be parser-executed" flag. The parser will handle executing the script.

    If the element has a src attribute

    The element must be added to the end of the list of scripts that will execute as soon as possible.

    The task that the networking task source places on the task queue once the fetching algorithm has completed must execute the script block.

    Otherwise
    The user agent must immediately execute the script block, even if other scripts are already executing.

Fetching an external script must delay the load event of the element's document until the task that is queued by the networking task source once the resource has been fetched (defined above) has been run.

The pending parsing-blocking script is used by the parser.

Executing a script block: When the steps above require that the script block be executed, the user agent must act as follows:

If the load resulted in an error (for example a DNS error, or an HTTP 404 error)

Executing the script block must just consist of firing a simple event named error at the element.

If the load was successful

  1. Initialize the script block's source as follows:

    If the script is from an external file and the script block's type is a text-based language

    The contents of that file, interpreted as string of Unicode characters, are the script source.

    For each of the rows in the following table, starting with the first one and going down, if the file has as many or more bytes available than the number of bytes in the first column, and the first bytes of the file match the bytes given in the first column, then set the script block's character encoding to the encoding given in the cell in the second column of that row, irrespective of any previous value:

    Bytes in Hexadecimal Encoding
    FE FF UTF-16BE
    FF FE UTF-16LE
    EF BB BF UTF-8

    This step looks for Unicode Byte Order Marks (BOMs).

    The file must then be converted to Unicode using the character encoding given by the script block's character encoding.

    If the script is from an external file and the script block's type is an XML-based language

    The external file is the script source. When it is later executed, it must be interpreted in a manner consistent with the specification defining the language given by the script block's type.

    If the script is inline and the script block's type is a text-based language

    The value of the text IDL attribute at the time the "running a script" algorithm was first invoked is the script source.

    If the script is inline and the script block's type is an XML-based language

    The child nodes of the script element at the time the "running a script" algorithm was first invoked are the script source.

  2. Pause until either any applicable style sheets have been fetched and applied, or the user agent has timed out and decided to not wait for those style sheets.

  3. Create a script from the script element node, using the script block's source and the script block's type.

    This is where the script is compiled and actually executed.

  4. Fire a simple event named load at the script element.

The IDL attributes src, type, charset, async, and defer, each must reflect the respective content attributes of the same name.

script . text [ = value ]

Returns the contents of the element, ignoring child nodes that aren't text nodes.

Can be set, to replace the element's children with the given value.

The IDL attribute text must return a concatenation of the contents of all the text nodes that are direct children of the script element (ignoring any other nodes such as comments or elements), in tree order. On setting, it must act the same way as the textContent IDL attribute.

When inserted using the document.write() method, script elements execute (typically synchronously), but when inserted using innerHTML and outerHTML attributes, they do not execute at all.

In this example, two script elements are used. One embeds an external script, and the other includes some data.

<script src="game-engine.js"></script>
<script type="text/x-game-map">
........U.........e
o............A....e
.....A.....AAA....e
.A..AAA...AAAAA...e
</script>

The data in this case might be used by the script to generate the map of a video game. The data doesn't have to be used that way, though; maybe the map data is actually embedded in other parts of the page's markup, and the data block here is just used by the site's search engine to help users who are looking for particular features in their game maps.

The following sample shows how a script element can be used to define a function that is then used by other parts of the document. It also shows how a script element can be used to invoke script while the document is being parsed, in this case to initialize the form's output.

<script>
 function calculate(form) {
   var price = 52000;
   if (form.elements.brakes.checked)
     price += 1000;
   if (form.elements.radio.checked)
     price += 2500;
   if (form.elements.turbo.checked)
     price += 5000;
   if (form.elements.sticker.checked)
     price += 250;
   form.elements.result.value = price;
 }
</script>
<form name="pricecalc" onsubmit="return false">
 <fieldset>
  <legend>Work out the price of your car</legend>
  <p>Base cost: £52000.</p>
  <p>Select additional options:</p>
  <ul>
   <li><label><input type=checkbox name=brakes> Ceramic brakes (£1000)</label></li>
   <li><label><input type=checkbox name=radio> Satellite radio (£2500)</label></li>
   <li><label><input type=checkbox name=turbo> Turbo charger (£5000)</label></li>
   <li><label><input type=checkbox name=sticker> "XZ" sticker (£250)</label></li>
  </ul>
  <p>Total: £<output name=result onformchange="calculate(form)"></output></p>
 </fieldset>
 <script>
  document.forms.pricecalc.dispatchFormChange();
 </script>
</form>
3.3.1.1 Scripting languages

Status: Last call for comments

A user agent is said to support the scripting language if the script block's type is an ASCII case-insensitive match for the MIME type string of a scripting language that the user agent implements.

The following lists some MIME type strings and the languages to which they refer:

"application/ecmascript"
"application/javascript"
"application/x-ecmascript"
"application/x-javascript"
"text/ecmascript"
"text/javascript"
"text/javascript1.0"
"text/javascript1.1"
"text/javascript1.2"
"text/javascript1.3"
"text/javascript1.4"
"text/javascript1.5"
"text/jscript"
"text/livescript"
"text/x-ecmascript"
"text/x-javascript"
JavaScript. [ECMA262]
"text/javascript;e4x=1"
JavaScript with ECMAScript for XML. [ECMA357]

User agents may support other MIME types and other languages.

When examining types to determine if they support the language, user agents must not ignore unknown MIME parameters — types with unknown parameters must be assumed to be unsupported. The charset parameter must be treated as an unknown parameter for the purpose of comparing MIME types here.

3.3.1.2 Restrictions for contents of script elements

Status: Last call for comments

The textContent of a script element must match the script production in the following ABNF, the character set for which is Unicode. [ABNF]

script        = data1 *( escape [ script-start data3 ] "-->" data1 ) [ escape ]
escape        = "<!--" data2 *( script-start data3 script-end data2 )

data1         = <any string that doesn't contain a substring that matches not-data1>
not-data1     = "<!--"             

data2         = <any string that doesn't contain a substring that matches not-data2>
not-data2     = script-start / "-->"  

data3         = <any string that doesn't contain a substring that matches not-data3>
not-data3     = script-end / "-->"

script-start  = lt       s c r i p t tag-end
script-end    = lt slash s c r i p t tag-end

lt            =  %x003C ; U+003C LESS-THAN SIGN character (<)
slash         =  %x002F ; U+002F SOLIDUS character (/)

s             =  %x0053 ; U+0053 LATIN CAPITAL LETTER S
s             =/ %x0073 ; U+0073 LATIN SMALL LETTER S
c             =  %x0043 ; U+0043 LATIN CAPITAL LETTER C
c             =/ %x0063 ; U+0063 LATIN SMALL LETTER C
r             =  %x0052 ; U+0052 LATIN CAPITAL LETTER R
r             =/ %x0072 ; U+0072 LATIN SMALL LETTER R
i             =  %x0049 ; U+0049 LATIN CAPITAL LETTER I
i             =/ %x0069 ; U+0069 LATIN SMALL LETTER I
p             =  %x0050 ; U+0050 LATIN CAPITAL LETTER P
p             =/ %x0070 ; U+0070 LATIN SMALL LETTER P
t             =  %x0054 ; U+0054 LATIN CAPITAL LETTER T
t             =/ %x0074 ; U+0074 LATIN SMALL LETTER T

tag-end       =  %x0009 ; U+0009 CHARACTER TABULATION
tag-end       =/ %x000A ; U+000A LINE FEED (LF)
tag-end       =/ %x000C ; U+000C FORM FEED (FF)
tag-end       =/ %x0020 ; U+0020 SPACE
tag-end       =/ %x002F ; U+002F SOLIDUS (/)
tag-end       =/ %x003E ; U+003E GREATER-THAN SIGN (>)

When a script element contains script documentation, there are further restrictions on the contents of the element, as described in the section below.

3.3.1.3 Inline documentation for external scripts

Status: Last call for comments

If a script element's src attribute is specified, then the contents of the script element, if any, must be such that the value of the text IDL attribute, which is derived from the element's contents, matches the documentation production in the following ABNF, the character set for which is Unicode. [ABNF]

documentation = *( *( space / tab / comment ) [ line-comment ] newline )
comment       = slash star *( not-star / star not-slash ) 1*star slash
line-comment  = slash slash *not-newline

; characters
tab           = %x0009 ; U+0009 TAB
newline       = %x000A ; U+000A LINE FEED (LF)
space         = %x0020 ; U+0020 SPACE
star          = %x002A ; U+002A ASTERISK (*)
slash         = %x002F ; U+002F SOLIDUS (/)
not-newline   = %x0000-0009 / %x000B-10FFFF
                ; a Unicode character other than U+000A LINE FEED (LF)
not-star      = %x0000-0029 / %x002B-10FFFF
                ; a Unicode character other than U+002A ASTERISK (*)
not-slash     = %x0000-002E / %x0030-10FFFF
                ; a Unicode character other than U+002F SOLIDUS (/)

This corresponds to putting the contents of the element in JavaScript comments.

This requirement is in addition to the earlier restrictions on the syntax of contents of script elements.

This allows authors to include documentation, such as license information or API information, inside their documents while still referring to external script files. The syntax is constrained so that authors don't accidentally include what looks like valid script while also providing a src attribute.

<script src="cool-effects.js">
 // create new instances using:
 //    var e = new Effect();
 // start the effect using .play, stop using .stop:
 //    e.play();
 //    e.stop();
</script>

3.3.2 The noscript element

Status: Last call for comments

Categories
Metadata content.
Flow content.
Phrasing content.
Contexts in which this element may be used:
In a head element of an HTML document, if there are no ancestor noscript elements.
Where phrasing content is expected in HTML documents, if there are no ancestor noscript elements.
Content model:
When scripting is disabled, in a head element: in any order, zero or more link elements, zero or more style elements, and zero or more meta elements.
When scripting is disabled, not in a head element: transparent, but there must be no noscript element descendants.
Otherwise: text that conforms to the requirements given in the prose.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The noscript element represents nothing if scripting is enabled, and represents its children if scripting is disabled. It is used to present different markup to user agents that support scripting and those that don't support scripting, by affecting how the document is parsed.

When used in HTML documents, the allowed content model is as follows:

In a head element, if scripting is disabled for the noscript element

The noscript element must contain only link, style, and meta elements.

In a head element, if scripting is enabled for the noscript element

The noscript element must contain only text, except that invoking the HTML fragment parsing algorithm with the noscript element as the context element and the text contents as the input must result in a list of nodes that consists only of link, style, and meta elements that would be conforming if they were children of the noscript element, and no parse errors.

Outside of head elements, if scripting is disabled for the noscript element

The noscript element's content model is transparent, with the additional restriction that a noscript element must not have a noscript element as an ancestor (that is, noscript can't be nested).

Outside of head elements, if scripting is enabled for the noscript element

The noscript element must contain only text, except that the text must be such that running the following algorithm results in a conforming document with no noscript elements and no script elements, and such that no step in the algorithm causes an HTML parser to flag a parse error:

  1. Remove every script element from the document.
  2. Make a list of every noscript element in the document. For every noscript element in that list, perform the following steps:
    1. Let the parent element be the parent element of the noscript element.
    2. Take all the children of the parent element that come before the noscript element, and call these elements the before children.
    3. Take all the children of the parent element that come after the noscript element, and call these elements the after children.
    4. Let s be the concatenation of all the text node children of the noscript element.
    5. Set the innerHTML attribute of the parent element to the value of s. (This, as a side-effect, causes the noscript element to be removed from the document.)
    6. Insert the before children at the start of the parent element, preserving their original relative order.
    7. Insert the after children at the end of the parent element, preserving their original relative order.

All these contortions are required because, for historical reasons, the noscript element is handled differently by the HTML parser based on whether scripting was enabled or not when the parser was invoked.

The noscript element must not be used in XML documents.

The noscript element is only effective in the HTML syntax, it has no effect in the XHTML syntax.

The noscript element has no other requirements. In particular, children of the noscript element are not exempt from form submission, scripting, and so forth, even when scripting is enabled for the element.

In the following example, a noscript element is used to provide fallback for a script.

<form action="calcSquare.php">
 <p>
  <label for=x>Number</label>:
  <input id="x" name="x" type="number">
 </p>
 <script>
  var x = document.getElementById('x');
  var output = document.createElement('p');
  output.textContent = 'Type a number; it will be squared right then!';
  x.form.appendChild(output);
  x.form.onsubmit = function () { return false; }
  x.oninput = function () {
    var v = x.valueAsNumber;
    output.textContent = v + ' squared is ' + v * v;
  };
 </script>
 <noscript>
  <input type=submit value="Calculate Square">
 </noscript>
</form>

When script is disabled, a button appears to do the calculation on the server side. When script is enabled, the value is computed on-the-fly instead.

The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail. For this reason, it's generally better to avoid using noscript, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly, as in the next example:

<form action="calcSquare.php">
 <p>
  <label for=x>Number</label>:
  <input id="x" name="x" type="number">
 </p>
 <input id="submit" type=submit value="Calculate Square">
 <script>
  var x = document.getElementById('x');
  var output = document.createElement('p');
  output.textContent = 'Type a number; it will be squared right then!';
  x.form.appendChild(output);
  x.form.onsubmit = function () { return false; }
  x.oninput = function () {
    var v = x.valueAsNumber;
    output.textContent = v + ' squared is ' + v * v;
  };
  var submit = document.getElementById('submit');
  submit.parentNode.removeChild(submit);
 </script>
</form>

The above technique is also useful in XHTML, since noscript is not supported in the XHTML syntax.

3.4 Sections

Status: Last call for comments

3.4.1 The body element

Status: Last call for comments

Categories
Sectioning root.
Contexts in which this element may be used:
As the second element in an html element.
Content model:
Flow content.
Content attributes:
Global attributes
onafterprint
onbeforeprint
onbeforeunload
onblur
onerror
onfocus
onhashchange
onload
onmessage
onoffline
ononline
onpagehide
onpageshow
onpopstate
onredo
onresize
onstorage
onundo
onunload
DOM interface:
interface HTMLBodyElement : HTMLElement {
           attribute Function onafterprint;
           attribute Function onbeforeprint;
           attribute Function onbeforeunload;
           attribute Function onblur;
           attribute Function onerror;
           attribute Function onfocus;
           attribute Function onhashchange;
           attribute Function onload;
           attribute Function onmessage;
           attribute Function onoffline;
           attribute Function ononline;
           attribute Function onpopstate;
           attribute Function onpagehide;
           attribute Function onpageshow;
           attribute Function onredo;
           attribute Function onresize;
           attribute Function onstorage;
           attribute Function onundo;
           attribute Function onunload;
};

The body element represents the main content of the document.

In conforming documents, there is only one body element. The document.body IDL attribute provides scripts with easy access to a document's body element.

Some DOM operations (for example, parts of the drag and drop model) are defined in terms of "the body element". This refers to a particular element in the DOM, as per the definition of the term, and not any arbitrary body element.

The body element exposes as event handler content attributes a number of the event handlers of the Window object. It also mirrors their event handler IDL attributes.

The onblur, onerror, onfocus, and onload event handlers of the Window object, exposed on the body element, shadow the generic event handlers with the same names normally supported by HTML elements.

Thus, for example, a bubbling error event fired on a child of the body element of a Document would first trigger the onerror event handler content attributes of that element, then that of the root html element, and only then would it trigger the onerror event handler content attribute on the body element. This is because the event would bubble from the target, to the body, to the html, to the Document, to the Window, and the event handler on the body is watching the Window not the body. A regular event listener attached to the body using addEventListener(), however, would fire when the event bubbled through the body and not when it reaches the Window object.

This page updates an indicator to show whether or not the user is online:

<!DOCTYPE HTML>
<html>
 <head>
  <title>Online or offline?</title>
  <script>
   function update(online) {
     document.getElementById('status').textContent = 
       online ? 'Online' : 'Offline';
   }
  </script>
 </head>
 <body ononline="update(true)"
       onoffline="update(false)"
       onload="update(navigator.onLine)">
  <p>You are: <span id="status">(Unknown)</span></p>
 </body>
</html>

3.4.2 The section element

Status: Last call for comments

Categories
Flow content.
Sectioning content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Flow content.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading.

Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, contact information.

Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element.

The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.

In the following example, we see an article (part of a larger Web page) about apples, containing two short sections.

<article>
 <hgroup>
  <h1>Apples</h1>
  <h2>Tasty, delicious fruit!</h2>
 </hgroup>
 <p>The apple is the pomaceous fruit of the apple tree.</p>
 <section>
  <h1>Red Delicious</h1>
  <p>These bright red apples are the most common found in many
  supermarkets.</p>
 </section>
 <section>
  <h1>Granny Smith</h1>
  <p>These juicy, green apples make a great filling for
  apple pies.</p>
 </section>
</article>

Notice how the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.

Here is a graduation programme with two sections, one for the list of people graduating, and one for the description of the ceremony.

<!DOCTYPE Html>
<Html
 ><Head
   ><Title
     >Graduation Ceremony Summer 2022</Title
   ></Head
 ><Body
   ><H1
     >Graduation</H1
   ><Section
     ><H1
       >Ceremony</H1
     ><P
       >Opening Procession</P
     ><P
       >Speech by Validactorian</P
     ><P
       >Speech by Class President</P
     ><P
       >Presentation of Diplomas</P
     ><P
       >Closing Speech by Headmaster</P
   ></Section
   ><Section
     ><H1
       >Graduates</H1
     ><Ul
       ><Li
         >Molly Carpenter</Li
       ><Li
         >Anastasia Luccio</Li
       ><Li
         >Ebenezar McCoy</Li
       ><Li
         >Karrin Murphy</Li
       ><Li
         >Thomas Raith</Li
       ><Li
         >Susan Rodriguez</Li
     ></Ul
   ></Section
 ></Body
></Html>

3.4.3 The nav element

Status: Last call for comments

Categories
Flow content.
Sectioning content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Flow content.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element.

User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request.

In the following example, the page has several places where links are present, but only one of those places is considered a navigation section.

<body>
 <header>
  <h1>Wake up sheeple!</h1>
  <p><a href="news.html">News</a> -
     <a href="blog.html">Blog</a> -
     <a href="forums.html">Forums</a></p>
  <p>Last Modified: <time>2009-04-01</time></p>
  <nav>
   <h1>Navigation</h1>
   <ul>
    <li><a href="articles.html">Index of all articles</a></li>
    <li><a href="today.html">Things sheeple need to wake up for today</a></li>
    <li><a href="successes.html">Sheeple we have managed to wake</a></li>
   </ul>
  </nav>
 </header>
 <div>
  <article>
   <header>
    <h1>My Day at the Beach</h1>
   </header>
   <div>
    <p>Today I went to the beach and had a lot of fun.</p>
    ...more content...
   </div>
   <footer>
    <p>Posted <time pubdate datetime="2009-10-10T14:36-08:00">Thursday</time>.</p>
   </footer>
  </article>
  ...more blog posts...
 </div>
 <footer>
  <p>Copyright © 2006 The Example Company</p>
  <p><a href="about.html">About</a> -
     <a href="policy.html">Privacy Policy</a> -
     <a href="contact.html">Contact Us</a></p>
 </footer>
</body>

Notice the div element being used to wrap all the contents of the page other than the header and footer, and all the contents of the blog entry other than its header and footer.

In the following example, there are two nav elements, one for primary navigation around the site, and one for secondary navigation around the page itself.

<body>
 <h1>The Wiki Center Of Exampland</h1>
 <nav>
  <ul>
   <li><a href="/">Home</a></li>
   <li><a href="/events">Current Events</a></li>
   ...more...
  </ul>
 </nav>
 <article>
  <header>
   <h1>Demos in Exampland</h1>
   <p>Written by A. N. Other.</p>
  </header>
  <nav>
   <ul>
    <li><a href="#public">Public demonstrations</a></li>
    <li><a href="#destroy">Demolitions</a></li>
    ...more...
   </ul>
  </nav>
  <div>
   <section id="public">
    <h1>Public demonstrations</h1>
    <p>...more...</p>
   </section>
   <section id="destroy">
    <h1>Demolitions</h1>
    <p>...more...</p>
   </section>
   ...more...
  </div>
  <footer>
   <p><a href="?edit">Edit</a> | <a href="?delete">Delete</a> | <a href="?Rename">Rename</a></p>
  </footer>
 </article>
 <footer>
  <p><small>© copyright 1998 Exampland Emperor</small></p>
 </footer>
</body>

3.4.4 The article element

Status: Last call for comments

Categories
Flow content.
Sectioning content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Flow content.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a blog entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the blog entry.

Author information associated with an article element (q.v. the address element) does not apply to nested article elements.

When used specifically with content to be redistributed in syndication, the article element is similar in purpose to the entry element in Atom. [ATOM]

The time element's pubdate attribute can be used to provide the publication date for an article element.

This example shows a blog post using the article element:

<article>
 <header>
  <h1>The Very First Rule of Life</h1>
  <p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p>
 </header>
 <p>If there's a microphone anywhere near you, assume it's hot and
 sending whatever you're saying to the world. Seriously.</p>
 <p>...</p>
 <footer>
  <a href="?comments=1">Show comments...</a>
 </footer>
</article>

Here is that same blog post, but showing some of the comments:

<article>
 <header>
  <h1>The Very First Rule of Life</h1>
  <p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p>
 </header>
 <p>If there's a microphone anywhere near you, assume it's hot and
 sending whatever you're saying to the world. Seriously.</p>
 <p>...</p>
 <section>
  <h1>Comments</h1>
  <article>
   <header>
    <p>Posted by: George Washington</p>
    <p><time pubdate datetime="2009-10-10T19:10-08:00"></time></p>
   </header>
   <p>Yeah! Especially when talking about your lobbyist friends!</p>
  </article>
  <article>
   <header>
    <p>Posted by: George Hammond</p>
    <p><time pubdate datetime="2009-10-10T19:15-08:00"></time></p>
   </header>
   <p>Hey, you have the same first name as me.</p>
  </article>
 </section>
</article>

3.4.5 The aside element

Status: Last call for comments

Categories
Flow content.
Sectioning content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Flow content.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

It's not appropriate to use the aside element just for parentheticals, since those are part of the main flow of the document.

The following example shows how an aside is used to mark up background material on Switzerland in a much longer news story on Europe.

<aside>
 <h1>Switzerland</h1>
 <p>Switzerland, a land-locked country in the middle of geographic
 Europe, has not joined the geopolitical European Union, though it is
 a signatory to a number of European treaties.</p>
</aside>

The following example shows how an aside is used to mark up a pull quote in a longer article.

...

<p>He later joined a large company, continuing on the same work.
<q>I love my job. People ask me what I do for fun when I'm not at
work. But I'm paid to do my hobby, so I never know what to
answer. Some people wonder what they would do if they didn't have to
work... but I know what I would do, because I was unemployed for a
year, and I filled that time doing exactly what I do now.</q></p>

<aside>
 <q> People ask me what I do for fun when I'm not at work. But I'm
 paid to do my hobby, so I never know what to answer. </q>
</aside>

<p>Of course his work — or should that be hobby? —
isn't his only passion. He also enjoys other pleasures.</p>

...

The following extract shows how aside can be used for blogrolls and other side content on a blog:

<body>
 <header>
  <h1>My wonderful blog</h1>
  <p>My tagline</p>
 </header>
 <aside>
  <!-- this aside contains two sections that are tangentially related
  to the page, namely, links to other blogs, and links to blog posts
  from this blog -->
  <nav>
   <h1>My blogroll</h1>
   <ul>
    <li><a href="http://blog.example.com/">Example Blog</a>
   </ul>
  </nav>
  <nav>
   <h1>Archives</h1>
   <ol reversed>
    <li><a href="/last-post">My last post</a>
    <li><a href="/first-post">My first post</a>
   </ol>
  </nav>
 </aside>
 <aside>
  <!-- this aside is tangentially related to the page also, it
  contains twitter messages from the blog author -->
  <h1>Twitter Feed</h1>
  <blockquote cite="http://twitter.example.net/t31351234">
   <p>I'm on vacation, writing my blog.</p>
  </blockquote>
  <blockquote cite="http://twitter.example.net/t31219752">
   <p>I'm going to go on vacation soon.</p>
  </blockquote>
 </aside>
 <article>
  <!-- this is a blog post -->
  <h1>My last post</h1>
  <p>This is my last post.</p>
  <footer>
   <p><a href="/last-post" rel=bookmark>Permalink</a>
  </footer>
 </article>
 <article>
  <!-- this is also a blog post -->
  <h1>My first post</h1>
  <p>This is my first post.</p>
  <aside>
   <!-- this aside is about the blog post, since it's inside the
   <article> element; it would be wrong, for instance, to put the
   blogroll here, since the blogroll isn't really related to this post
   specifically, only to the page as a whole -->
   <h1>Posting</h1>
   <p>While I'm thinking about it, I wanted to say something about
   posting. Posting is fun!</p>
  </aside>
  <footer>
   <p><a href="/first-post" rel=bookmark>Permalink</a>
  </footer>
 </article>
 <footer>
  <nav>
   <a href="/archives">Archives</a> —
   <a href="/about">About me</a> —
   <a href="/copyright">Copyright</a>
  </nav>
 </footer>
</body>

3.4.6 The h1, h2, h3, h4, h5, and h6 elements

Categories
Flow content.
Heading content.
formatBlock candidate.
Contexts in which this element may be used:
As a child of an hgroup element.
Where flow content is expected.
Content model:
Phrasing content.
Content attributes:
Global attributes
DOM interface:
interface HTMLHeadingElement : HTMLElement {};

These elements represent headings for their sections.

The semantics and meaning of these elements are defined in the section on headings and sections.

These elements have a rank given by the number in their name. The h1 element is said to have the highest rank, the h6 element has the lowest rank, and two elements with the same name have equal rank.

These two snippets are equivalent:

<body>
<h1>Let's call it a draw(ing surface)</h1>
<h2>Diving in</h2>
<h2>Simple shapes</h2>
<h2>Canvas coordinates</h2>
<h3>Canvas coordinates diagram</h3>
<h2>Paths</h2>
</body>
<body>
 <h1>Let's call it a draw(ing surface)</h1>
 <section>
  <h1>Diving in</h1>
 </section>
 <section>
  <h1>Simple shapes</h1>
 </section>
 <section>
  <h1>Canvas coordinates</h1>
  <section>
   <h1>Canvas coordinates diagram</h1>
  </section>
 </section>
 <section>
  <h1>Paths</h1>
 </section>
</body>

3.4.7 The hgroup element

Status: Last call for comments

Categories
Flow content.
Heading content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
One or more h1, h2, h3, h4, h5, and/or h6 elements.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

For the purposes of document summaries, outlines, and the like, the text of hgroup elements is defined to be the text of the highest ranked h1–h6 element descendant of the hgroup element, if there are any such elements, and the first such element if there are multiple elements with that rank. If there are no such elements, then the text of the hgroup element is the empty string.

Other elements of heading content in the hgroup element indicate subheadings or subtitles.

The rank of an hgroup element is the rank of the highest-ranked h1–h6 element descendant of the hgroup element, if there are any such elements, or otherwise the same as for an h1 element (the highest rank).

The section on headings and sections defines how hgroup elements are assigned to individual sections.

Here are some examples of valid headings. In each case, the emphasized text represents the text that would be used as the heading in an application extracting heading data and ignoring subheadings.

<hgroup>
 <h1>The reality dysfunction</h1>
 <h2>Space is not the only void</h2>
</hgroup>
<hgroup>
 <h1>Dr. Strangelove</h1>
 <h2>Or: How I Learned to Stop Worrying and Love the Bomb</h2>
</hgroup>

The point of using hgroup in these examples is to mask the h2 element (which acts as a secondary title) from the outline algorithm.

3.4.8 The header element

Status: Last call for comments

Categories
Flow content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Flow content, but with no header or footer element descendants.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The header element represents a group of introductory or navigational aids.

A header element is intended to usually contain the section's heading (an h1–h6 element or an hgroup element), but this is not required. The header element can also be used to wrap a section's table of contents, a search form, or any relevant logos.

Here are some sample headers. This first one is for a game:

<header>
 <p>Welcome to...</p>
 <h1>Voidwars!</h1>
</header>

The following snippet shows how the element can be used to mark up a specification's header:

<header>
 <hgroup>
  <h1>Scalable Vector Graphics (SVG) 1.2</h1>
  <h2>W3C Working Draft 27 October 2004</h2>
 </hgroup>
 <dl>
  <dt>This version:</dt>
  <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20041027/">http://www.w3.org/TR/2004/WD-SVG12-20041027/</a></dd>
  <dt>Previous version:</dt>
  <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20040510/">http://www.w3.org/TR/2004/WD-SVG12-20040510/</a></dd>
  <dt>Latest version of SVG 1.2:</dt>
  <dd><a href="http://www.w3.org/TR/SVG12/">http://www.w3.org/TR/SVG12/</a></dd>
  <dt>Latest SVG Recommendation:</dt>
  <dd><a href="http://www.w3.org/TR/SVG/">http://www.w3.org/TR/SVG/</a></dd>
  <dt>Editor:</dt>
  <dd>Dean Jackson, W3C, <a href="mailto:dean@w3.org">dean@w3.org</a></dd>
  <dt>Authors:</dt>
  <dd>See <a href="#authors">Author List</a></dd>
 </dl>
 <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notic ...
</header>

The header element is not sectioning content; it doesn't introduce a new section.

In this example, the page has a page heading given by the h1 element, and two subsections whose headings are given by h2 elements. The content after the header element is still part of the last subsection started in the header element, because the header element doesn't take part in the outline algorithm.

<body>
 <header>
  <h1>Little Green Guys With Guns</h1>
  <nav>
   <ul>
    <li><a href="/games">Games</a>
    <li><a href="/forum">Forum</a>
    <li><a href="/download">Download</a>
   </ul>
  </nav>
  <h2>Important News</h2> <!-- this starts a second subsection -->
  <!-- this is part of the subsection entitled "Important News" -->
  <p>To play today's games you will need to update your client.</p>
  <h2>Games</h2> <!-- this starts a third subsection -->
 </header>
 <p>You have three active games:</p>
 <!-- this is still part of the subsection entitled "Games" -->
 ...

Status: Last call for comments

Categories
Flow content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Flow content, but with no header or footer element descendants.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

Contact information for the author or editor of a section belongs in an address element, possibly itself inside a footer.

Footers don't necessarily have to appear at the end of a section, though they usually do.

When the footer element contains entire sections, they represent appendices, indexes, long colophons, verbose license agreements, and other such content.

The footer element is not sectioning content; it doesn't introduce a new section.

When the nearest ancestor sectioning content or sectioning root element is the body element, then it applies to the whole page.

Here is a page with two footers, one at the top and one at the bottom, with the same content:

<body>
 <footer><a href="../">Back to index...</a></footer>
 <hgroup>
  <h1>Lorem ipsum</h1>
  <h2>The ipsum of all lorems</h2>
 </hgroup>
 <p>A dolor sit amet, consectetur adipisicing elit, sed do eiusmod
 tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
 veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex
 ea commodo consequat. Duis aute irure dolor in reprehenderit in
 voluptate velit esse cillum dolore eu fugiat nulla
 pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
 culpa qui officia deserunt mollit anim id est laborum.</p>
 <footer><a href="../">Back to index...</a></footer>
</body>

Here is an example which shows the footer element being used both for a site-wide footer and for a section footer.

<!DOCTYPE HTML>
<HTML><HEAD>
<TITLE>The Ramblings of a Scientist</TITLE>
<BODY>
<H1>The Ramblings of a Scientist</H1>
<ARTICLE>
 <H1>Episode 15</H1>
 <VIDEO SRC="/fm/015.ogv" CONTROLS AUTOBUFFER>
  <P><A HREF="/fm/015.ogv">Download video</A>.</P>
 </VIDEO>
 <FOOTER> <!-- footer for article -->
  <P>Published <TIME PUBDATE DATETIME="2009-10-21T18:26-07:00"></TIME></P>
 </FOOTER>
</ARTICLE>
<ARTICLE>
 <H1>My Favorite Trains</H1>
 <P>I love my trains. My favorite train of all time is a Köf.</P>
 <P>It is fun to see them pull some coal cars because they look so
 dwarfed in comparison.</P>
 <FOOTER> <!-- footer for article -->
  <P>Published <TIME PUBDATE DATETIME="2009-09-15T14:54-07:00"></TIME></P>
 </FOOTER>
</ARTICLE>
<FOOTER> <!-- site wide footer -->
 <NAV>
  <P><A HREF="/credits.html">Credits</A> —
     <A HREF="/tos.html">Terms of Service</A> —
     <A HREF="/index.html">Blog Index</A></P>
 </NAV>
 <P>Copyright © 2009 Gordon Freeman</P>
</FOOTER>
</BODY>
</HTML>

3.4.10 The address element

Status: Last call for comments

Categories
Flow content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Flow content, but with no heading content descendants, no sectioning content descendants, and no header, footer, or address element descendants.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The address element represents the contact information for its nearest article or body element ancestor. If that is the body element, then the contact information applies to the document as a whole.

For example, a page at the W3C Web site related to HTML might include the following contact information:

<ADDRESS>
 <A href="../People/Raggett/">Dave Raggett</A>,
 <A href="../People/Arnaud/">Arnaud Le Hors</A>,
 contact persons for the <A href="Activity">W3C HTML Activity</A>
</ADDRESS>

The address element must not be used to represent arbitrary addresses (e.g. postal addresses), unless those addresses are in fact the relevant contact information. (The p element is the appropriate element for marking up postal addresses in general.)

The address element must not contain information other than contact information.

For example, the following is non-conforming use of the address element:

<ADDRESS>Last Modified: 1999/12/24 23:37:50</ADDRESS>

Typically, the address element would be included along with other information in a footer element.

The contact information for a node node is a collection of address elements defined by the first applicable entry from the following list:

If node is an article element
If node is a body element

The contact information consists of all the address elements that have node as an ancestor and do not have another body or article element ancestor that is a descendant of node.

If node has an ancestor element that is an article element
If node has an ancestor element that is a body element

The contact information of node is the same as the contact information of the nearest article or body element ancestor, whichever is nearest.

If node's Document has a body element

The contact information of node is the same as the contact information the body element of the Document.

Otherwise

There is no contact information for node.

User agents may expose the contact information of a node to the user, or use it for other purposes, such as indexing sections based on the sections' contact information.

3.4.11 Headings and sections

Status: Last call for comments

The h1–h6 elements and the hgroup element are headings.

The first element of heading content in an element of sectioning content represents the heading for that section. Subsequent headings of equal or higher rank start new (implied) sections, headings of lower rank start implied subsections that are part of the previous one. In both cases, the element represents the heading of the implied section.

Sectioning content elements are always considered subsections of their nearest ancestor element of sectioning content, regardless of what implied sections other headings may have created.

Certain elements are said to be sectioning roots, including blockquote and td elements. These elements can have their own outlines, but the sections and headings inside these elements do not contribute to the outlines of their ancestors.

For the following fragment:

<body>
 <h1>Foo</h1>
 <h2>Bar</h2>
 <blockquote>
  <h3>Bla</h3>
 </blockquote>
 <p>Baz</p>
 <h2>Quux</h2>
 <section>
  <h3>Thud</h3>
 </section>
 <p>Grunt</p>
</body>

...the structure would be:

  1. Foo (heading of explicit body section, containing the "Grunt" paragraph)
    1. Bar (heading starting implied section, containing a block quote and the "Baz" paragraph)
    2. Quux (heading starting implied section)
    3. Thud (heading of explicit section section)

Notice how the section ends the earlier implicit section so that a later paragraph ("Grunt") is back at the top level.

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level.

Authors are also encouraged to explicitly wrap sections in elements of sectioning content, instead of relying on the implicit sections generated by having multiple headings in one element of sectioning content.

For example, the following is correct:

<body>
 <h4>Apples</h4>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <h6>Sweet</h6>
  <p>Red apples are sweeter than green ones.</p>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>
</body>

However, the same document would be more clearly expressed as:

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Color</h2>
  <p>Apples come in various colors.</p>
 </section>
</body>

Both of the documents above are semantically identical and would produce the same outline in compliant user agents.

3.4.11.1 Creating an outline

Status: Last call for comments

This section defines an algorithm for creating an outline for a sectioning content element or a sectioning root element. It is defined in terms of a walk over the nodes of a DOM tree, in tree order, with each node being visited when it is entered and when it is exited during the walk.

The outline for a sectioning content element or a sectioning root element consists of a list of one or more potentially nested sections. A section is a container that corresponds to some nodes in the original DOM tree. Each section can have one heading associated with it, and can contain any number of further nested sections. The algorithm for the outline also associates each node in the DOM tree with a particular section and potentially a heading. (The sections in the outline aren't section elements, though some may correspond to such elements — they are merely conceptual sections.)

The following markup fragment:

<body>
 <h1>A</h1>
 <p>B</p>
 <h2>C</h2>
 <p>D</p>
 <h2>E</h2>
 <p>F</p>
</body>

...results in the following outline being created for the body node (and thus the entire document):

  1. Section created for body node.

    Associated with heading "A".

    Also associated with paragraph "B".

    Nested sections:

    1. Section implied for first h2 element.

      Associated with heading "C".

      Also associated with paragraph "D".

      No nested sections.

    2. Section implied for second h2 element.

      Associated with heading "E".

      Also associated with paragraph "F".

      No nested sections.

The algorithm that must be followed during a walk of a DOM subtree rooted at a sectioning content element or a sectioning root element to determine that element's outline is as follows:

  1. Let current outlinee be null. (It holds the element whose outline is being created.)

  2. Let current section be null. (It holds a pointer to a section, so that elements in the DOM can all be associated with a section.)

  3. Create a stack to hold elements, which is used to handle nesting. Initialize this stack to empty.

  4. As you walk over the DOM in tree order, trigger the first relevant step below for each element as you enter and exit it.

    If the top of the stack is an element, and you are exiting that element

    The element being exited is a heading content element.

    Pop that element from the stack.

    If the top of the stack is a heading content element

    Do nothing.

    When entering a sectioning content element or a sectioning root element

    If current outlinee is not null, and the current section has no heading, create an implied heading and let that be the heading for the current section.

    If current outlinee is not null, push current outlinee onto the stack.

    Let current outlinee be the element that is being entered.

    Let current section be a newly created section for the current outlinee element.

    Let there be a new outline for the new current outlinee, initialized with just the new current section as the only section in the outline.

    When exiting a sectioning content element, if the stack is not empty

    Pop the top element from the stack, and let the current outlinee be that element.

    Let current section be the last section in the outline of the current outlinee element.

    Append the outline of the sectioning content element being exited to the current section. (This does not change which section is the last section in the outline.)

    When exiting a sectioning root element, if the stack is not empty

    Run these steps:

    1. Pop the top element from the stack, and let the current outlinee be that element.

    2. Let current section be the last section in the outline of the current outlinee element.

    3. Finding the deepest child: If current section has no child sections, stop these steps.

    4. Let current section be the last child section of the current current section.

    5. Go back to the substep labeled finding the deepest child.

    When exiting a sectioning content element or a sectioning root element

    The current outlinee is the element being exited.

    Let current section be the first section in the outline of the current outlinee element.

    Skip to the next step in the overall set of steps. (The walk is over.)

    If the current outlinee is null.

    Do nothing.

    When entering a heading content element

    If the current section has no heading, let the element being entered be the heading for the current section.

    Otherwise, if the element being entered has a rank equal to or greater than the heading of the last section of the outline of the current outlinee, then create a new section and append it to the outline of the current outlinee element, so that this new section is the new last section of that outline. Let current section be that new section. Let the element being entered be the new heading for the current section.

    Otherwise, run these substeps:

    1. Let candidate section be current section.

    2. If the element being entered has a rank lower than the rank of the heading of the candidate section, then create a new section, and append it to candidate section. (This does not change which section is the last section in the outline.) Let current section be this new section. Let the element being entered be the new heading for the current section. Abort these substeps.

    3. Let new candidate section be the section that contains candidate section in the outline of current outlinee.

    4. Let candidate section be new candidate section.

    5. Return to step 2.

    Push the element being entered onto the stack. (This causes the algorithm to skip any descendants of the element.)

    Recall that h1 has the highest rank, and h6 has the lowest rank.

    Otherwise

    Do nothing.

    In addition, whenever you exit a node, after doing the steps above, if current section is not null, associate the node with the section current section.

  5. If the current outlinee is null, then there was no sectioning content element or sectioning root element in the DOM. There is no outline. Abort these steps.

  6. Associate any nodes that were not associated with a section in the steps above with current outlinee as their section.

  7. Associate all nodes with the heading of the section with which they are associated, if any.

  8. If current outlinee is the body element, then the outline created for that element is the outline of the entire document.

The tree of sections created by the algorithm above, or a proper subset thereof, must be used when generating document outlines, for example when generating tables of contents.

When creating an interactive table of contents, entries should jump the user to the relevant sectioning content element, if the section was created for a real element in the original document, or to the relevant heading content element, if the section in the tree was generated for a heading in the above process.

Selecting the first section of the document therefore always takes the user to the top of the document, regardless of where the first heading in the body is to be found.

The outline depth of a heading content element associated with a section section is the number of sections that are ancestors of section in the outline that section finds itself in when the outlines of its Document's elements are created, plus 1. The outline depth of a heading content element not associated with a section is 1.

User agents should provide default headings for sections that do not have explicit section headings.

Consider the following snippet:

<body>
 <nav>
  <p><a href="/">Home</a></p>
 </nav>
 <p>Hello world.</p>
 <aside>
  <p>My cat is cute.</p>
 </aside>
</body>

Although it contains no headings, this snippet has three sections: a document (the body) with two subsections (a nav and an aside). A user agent could present the outline as follows:

  1. Untitled document
    1. Navigation
    2. Sidebar

These default headings ("Untitled document", "Navigation", "Sidebar") are not specified by this specification, and might vary with the user's language, the page's language, the user's preferences, the user agent implementor's preferences, etc.

The following JavaScript function shows how the tree walk could be implemented. The root argument is the root of the tree to walk, and the enter and exit arguments are callbacks that are called with the nodes as they are entered and exited. [ECMA262]

function (root, enter, exit) {
  var node = root;
  start: while (node) {
    enter(node);
    if (node.firstChild) {
      node = node.firstChild;
      continue start;
    }
    while (node) {
      exit(node);
      if (node.nextSibling) {
        node = node.nextSibling;
        continue start;
      }
      if (node == root)
        node = null;
      else
        node = node.parentNode;
    }
  }
}

3.5 Grouping content

Status: Last call for comments

3.5.1 The p element

Status: Last call for comments

Categories
Flow content.
formatBlock candidate.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Phrasing content.
Content attributes:
Global attributes
DOM interface:
interface HTMLParagraphElement : HTMLElement {};

The p element represents a paragraph.

The following examples are conforming HTML fragments:

<p>The little kitten gently seated himself on a piece of
carpet. Later in his life, this would be referred to as the time the
cat sat on the mat.</p>
<fieldset>
 <legend>Personal information</legend>
 <p>
   <label>Name: <input name="n"></label>
   <label><input name="anon" type="checkbox"> Hide from other users</label>
 </p>
 <p><label>Address: <textarea name="a"></textarea></label></p>
</fieldset>
<p>There was once an example from Femley,<br>
Whose markup was of dubious quality.<br>
The validator complained,<br>
So the author was pained,<br>
To move the error from the markup to the rhyming.</p>