Favorite books
These are a few of my favorite books.
The Belgariad
Five books by David and Leigh Eddings.
The Hitchhiker’s Guide to the Galaxy
A trilogy of five books by Douglas Adams.
Link: canonical W3C HTML 5.2 W3C Recommendation, 14 December 2017 superseded 28 January 2021 This version: https://www.w3.org/TR/2017/REC-html52-20171214/ Latest published version: https://www.w3.org/TR/html52/ Latest published version of HTML: https://www.w3.org/TR/html/ Previous version: https://www.w3.org/TR/2017/REC-html52-20171214/ Editor's Draft: https://w3c.github.io/html/ Editors: Steve Faulkner (The Paciello Group) Arron Eicholz (Microsoft) Travis Leithead (Microsoft) Alex Danilo (Google) Sangwhan Moon (Invited Expert) Former Editors: Erika Doyle Navara (Microsoft) Theresa O'Connor (Apple Inc.) Robin Berjon (W3C) Test Suite: https://w3c-test.org/html/ Implementation Report: https://w3c.github.io/test-results/html52/implementation-report.html Participate: File an issue (open issues) Others: Single page version Errata for this document are recorded as Github issues. The English version of this specification is the only normative version. Non-normative translations may also be available. Copyright © 2017 W3C^® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply. ---------------------------------------------------------------------- Abstract This specification defines the 5th major version, second minor revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). In this version, new features continue to be introduced to help Web application authors, new elements continue to be introduced based on research into prevailing authoring practices, and special attention continues to be given to defining clear conformance criteria for user agents in an effort to improve interoperability. Status of this document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/. This specification is a Superseded Recommendation. A newer specification exists that is recommended for new adoption in place of this specification. This document was published by the Web Platform Working Group that would obsolete the HTML 5.1 Recommendation. All interested parties are invited to provide implementation and bug reports and other comments through the Working Group's Issue tracker. These will generally be considered in the development of HTML 5.3. The implementation report produced for this version demonstrates that in almost every case changes are matched by interoperable implementation. For purposes of the W3C Patent Policy, this Superseded Recommendation has the same status as an active Recommendation; it retains licensing commitments and remains available as a reference for old -- and possibly still deployed -- implementations, but is not recommended for future implementation. New implementations should follow the latest version of the HTML 5.2 specification. This document was produced by a group operating under the 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. This document is governed by the 1 March 2017 W3C Process Document. Table of Contents 1. 1 Introduction 1. 1.1 Background 2. 1.2 Audience 3. 1.3 Scope 4. 1.4 History 5. 1.5 Design notes 1. 1.5.1 Serializability of script execution 2. 1.5.2 Compliance with other specifications 3. 1.5.3 Extensibility 6. 1.6 HTML vs XML Syntax 7. 1.7 Structure of this specification 1. 1.7.1 How to read this specification 2. 1.7.2 Typographic conventions 8. 1.8 Privacy concerns 9. 1.9 A quick introduction to HTML 1. 1.9.1 Writing secure applications with HTML 2. 1.9.2 Common pitfalls to avoid when using the scripting APIs 3. 1.9.3 How to catch mistakes when writing HTML: validators and conformance checkers 10. 1.10 Conformance requirements for authors 1. 1.10.1 Presentational markup 2. 1.10.2 Syntax errors 3. 1.10.3 Restrictions on content models and on attribute values 11. 1.11 Suggested reading 2. 2 Common infrastructure 1. 2.1 Terminology 1. 2.1.1 Resources 2. 2.1.2 XML compatibility 3. 2.1.3 DOM trees 4. 2.1.4 Scripting 5. 2.1.5 Plugins 6. 2.1.6 Character encodings 2. 2.2 Conformance requirements 1. 2.2.1 Conformance classes 2. 2.2.2 Dependencies 3. 2.2.3 Extensibility 4. 2.2.4 Interactions with XPath and XSLT 3. 2.3 Case-sensitivity and string comparison 4. 2.4 Common microsyntaxes 1. 2.4.1 Common parser idioms 2. 2.4.2 Boolean attributes 3. 2.4.3 Keywords and enumerated attributes 4. 2.4.4 Numbers 1. 2.4.4.1 Signed integers 2. 2.4.4.2 Non-negative integers 3. 2.4.4.3 Floating-point numbers 4. 2.4.4.4 Percentages and lengths 5. 2.4.4.5 Non-zero percentages and lengths 6. 2.4.4.6 Lists of floating-point numbers 7. 2.4.4.7 Lists of dimensions 5. 2.4.5 Dates and times 1. 2.4.5.1 Months 2. 2.4.5.2 Dates 3. 2.4.5.3 Yearless dates 4. 2.4.5.4 Times 5. 2.4.5.5 Floating dates and times 6. 2.4.5.6 Time zones 7. 2.4.5.7 Global dates and times 8. 2.4.5.8 Weeks 9. 2.4.5.9 Durations 10. 2.4.5.10 Vaguer moments in time 6. 2.4.6 Colors 7. 2.4.7 Space-separated tokens 8. 2.4.8 Comma-separated tokens 9. 2.4.9 References 10. 2.4.10 Media queries 5. 2.5 URLs 1. 2.5.1 Terminology 2. 2.5.2 Parsing URLs 3. 2.5.3 Dynamic changes to base URLs 6. 2.6 Fetching resources 1. 2.6.1 Terminology 2. 2.6.2 Processing model 3. 2.6.3 Encrypted HTTP and related security concerns 4. 2.6.4 Determining the type of a resource 5. 2.6.5 Extracting character encodings from meta elements 6. 2.6.6 CORS settings attributes 7. 2.6.7 Referrer policy attributes 7. 2.7 Common DOM interfaces 1. 2.7.1 Reflecting content attributes in IDL attributes 2. 2.7.2 Collections 1. 2.7.2.1 The HTMLAllCollection interface 2. 2.7.2.2 The HTMLFormControlsCollection interface 3. 2.7.2.3 The HTMLOptionsCollection interface 3. 2.7.3 The DOMStringList interface 4. 2.7.4 Garbage collection 8. 2.8 Namespaces 9. 2.9 Safe passing of structured data 1. 2.9.1 Serializable objects 2. 2.9.2 Transferable objects 3. 2.9.3 StructuredSerializeInternal ( value, forStorage [ , memory ] ) 4. 2.9.4 StructuredSerialize ( value ) 5. 2.9.5 StructuredSerializeForStorage ( value ) 6. 2.9.6 StructuredDeserialize ( serialized, targetRealm [ , memory ] ) 7. 2.9.7 StructuredSerializeWithTransfer ( value, transferList ) 8. 2.9.8 StructuredDeserializeWithTransfer ( serializeWithTransferResult, targetRealm ) 9. 2.9.9 Performing serialization and transferring from other specifications 10. 2.9.10 Monkey patch for Blob and FileList objects 3. 3 Semantics, structure, and APIs of HTML documents 1. 3.1 Documents 1. 3.1.1 The Document object 2. 3.1.2 Resource metadata management 3. 3.1.3 DOM tree accessors 2. 3.2 Elements 1. 3.2.1 Semantics 2. 3.2.2 Elements in the DOM 3. 3.2.3 Element definitions 1. 3.2.3.1 Attributes 4. 3.2.4 Content models 1. 3.2.4.1 The "nothing" content model 2. 3.2.4.2 Kinds of content 1. 3.2.4.2.1 Metadata content 2. 3.2.4.2.2 Flow content 3. 3.2.4.2.3 Sectioning content 4. 3.2.4.2.4 Heading content 5. 3.2.4.2.5 Phrasing content 6. 3.2.4.2.6 Embedded content 7. 3.2.4.2.7 Interactive content 8. 3.2.4.2.8 Palpable content 9. 3.2.4.2.9 Script-supporting elements 3. 3.2.4.3 Transparent content models 4. 3.2.4.4 Paragraphs 5. 3.2.5 Global attributes 1. 3.2.5.1 The title attribute 2. 3.2.5.2 The lang and xml:lang attributes 3. 3.2.5.3 The translate attribute 4. 3.2.5.4 The xml:base attribute (XML only) 5. 3.2.5.5 The dir attribute 6. 3.2.5.6 The style attribute 7. 3.2.5.7 Embedding custom non-visible data with the data-* attributes 6. 3.2.6 The innerText IDL attribute 7. 3.2.7 Requirements relating to the bidirectional algorithm 1. 3.2.7.1 Authoring conformance criteria for bidirectional-algorithm formatting characters 2. 3.2.7.2 User agent conformance criteria 8. 3.2.8 WAI-ARIA and HTML Accessibility API Mappings 1. 3.2.8.1 ARIA Authoring Requirements 2. 3.2.8.2 Conformance Checker Implementation Requirements 3. 3.2.8.3 User Agent Implementation Requirements 1. 3.2.8.3.1 ARIA Role Attribute 2. 3.2.8.3.2 State and Property Attributes 4. 3.2.8.4 Allowed ARIA roles, states and properties 4. 4 The elements of HTML 1. 4.1 The document element 1. 4.1.1 The html element 2. 4.2 Document metadata 1. 4.2.1 The head element 2. 4.2.2 The title element 3. 4.2.3 The base element 4. 4.2.4 The link element 1. 4.2.4.1 Processing the media attribute 2. 4.2.4.2 Processing the type attribute 3. 4.2.4.3 Obtaining a resource from a link element 4. 4.2.4.4 Processing Link headers 5. 4.2.4.5 Providing users with a means to follow hyperlinks created using the link element 6. 4.2.4.6 The LinkStyle interface 5. 4.2.5 The meta element 1. 4.2.5.1 Standard metadata names 2. 4.2.5.2 Other metadata names 3. 4.2.5.3 Pragma directives 4. 4.2.5.4 Other pragma directives 5. 4.2.5.5 Specifying the document’s character encoding 6. 4.2.6 The style element 7. 4.2.7 Interactions of styling and scripting 3. 4.3 Sections 1. 4.3.1 The body element 2. 4.3.2 The article element 3. 4.3.3 The section element 4. 4.3.4 The nav element 5. 4.3.5 The aside element 6. 4.3.6 The h1, h2, h3, h4, h5, and h6 elements 7. 4.3.7 The header element 8. 4.3.8 The footer element 9. 4.3.9 Headings and sections 1. 4.3.9.1 Creating an outline 10. 4.3.10 Usage summary 1. 4.3.10.1 Article or section? 4. 4.4 Grouping content 1. 4.4.1 The p element 2. 4.4.2 The address element 3. 4.4.3 The hr element 4. 4.4.4 The pre element 5. 4.4.5 The blockquote element 6. 4.4.6 The ol element 7. 4.4.7 The ul element 8. 4.4.8 The li element 9. 4.4.9 The dl element 10. 4.4.10 The dt element 11. 4.4.11 The dd element 12. 4.4.12 The figure element 13. 4.4.13 The figcaption element 14. 4.4.14 The main element 15. 4.4.15 The div element 5. 4.5 Text-level semantics 1. 4.5.1 The a element 2. 4.5.2 The em element 3. 4.5.3 The strong element 4. 4.5.4 The small element 5. 4.5.5 The s element 6. 4.5.6 The cite element 7. 4.5.7 The q element 8. 4.5.8 The dfn element 9. 4.5.9 The abbr element 10. 4.5.10 The ruby element 11. 4.5.11 The rb element 12. 4.5.12 The rt element 13. 4.5.13 The rtc element 14. 4.5.14 The rp element 15. 4.5.15 The data element 16. 4.5.16 The time element 17. 4.5.17 The code element 18. 4.5.18 The var element 19. 4.5.19 The samp element 20. 4.5.20 The kbd element 21. 4.5.21 The sub and sup elements 22. 4.5.22 The i element 23. 4.5.23 The b element 24. 4.5.24 The u element 25. 4.5.25 The mark element 26. 4.5.26 The bdi element 27. 4.5.27 The bdo element 28. 4.5.28 The span element 29. 4.5.29 The br element 30. 4.5.30 The wbr element 31. 4.5.31 Usage summary 6. 4.6 Edits 1. 4.6.1 The ins element 2. 4.6.2 The del element 3. 4.6.3 Attributes common to ins and del elements 4. 4.6.4 Edits and paragraphs 5. 4.6.5 Edits and lists 6. 4.6.6 Edits and tables 7. 4.7 Embedded content 1. 4.7.1 Introduction 2. 4.7.2 Dependencies 3. 4.7.3 The picture element 4. 4.7.4 The source element 5. 4.7.5 The img element 1. 4.7.5.1 Requirements for providing text to act as an alternative for images 1. 4.7.5.1.1 Examples of scenarios where users benefit from text alternatives for images 2. 4.7.5.1.2 General guidelines 3. 4.7.5.1.3 A link or button containing nothing but an image 4. 4.7.5.1.4 Graphical Representations: Charts, diagrams, graphs, maps, illustrations 5. 4.7.5.1.5 Images of text 6. 4.7.5.1.6 Images that include text 7. 4.7.5.1.7 Images that enhance the themes or subject matter of the page content 8. 4.7.5.1.8 A graphical representation of some of the surrounding text 9. 4.7.5.1.9 A purely decorative image that doesn’t add any information 10. 4.7.5.1.10 Inline images 11. 4.7.5.1.11 A group of images that form a single larger picture with no links 12. 4.7.5.1.12 Image maps 13. 4.7.5.1.13 A group of images that form a single larger picture with links 14. 4.7.5.1.14 Images of Pictures 15. 4.7.5.1.15 Webcam images 16. 4.7.5.1.16 When a text alternative is not available at the time of publication 17. 4.7.5.1.17 An image not intended for the user 18. 4.7.5.1.18 Icon Images 19. 4.7.5.1.19 Logos, insignia, flags, or emblems 20. 4.7.5.1.20 CAPTCHA Images 21. 4.7.5.1.21 An image in a picture element 22. 4.7.5.1.22 Guidance for markup generators 23. 4.7.5.1.23 Guidance for conformance checkers 6. 4.7.6 The iframe element 7. 4.7.7 The embed element 8. 4.7.8 The object element 9. 4.7.9 The param element 10. 4.7.10 The video element 11. 4.7.11 The audio element 12. 4.7.12 The track element 13. 4.7.13 Media elements 1. 4.7.13.1 Error codes 2. 4.7.13.2 Location of the media resource 3. 4.7.13.3 MIME types 4. 4.7.13.4 Network states 5. 4.7.13.5 Loading the media resource 6. 4.7.13.6 Offsets into the media resource 7. 4.7.13.7 Ready states 8. 4.7.13.8 Playing the media resource 9. 4.7.13.9 Seeking 10. 4.7.13.10 Media resources with multiple media tracks 1. 4.7.13.10.1 AudioTrackList and VideoTrackList objects 2. 4.7.13.10.2 Selecting specific audio and video tracks declaratively 11. 4.7.13.11 Timed text tracks 1. 4.7.13.11.1 Text track model 2. 4.7.13.11.2 Sourcing in-band text tracks 3. 4.7.13.11.3 Sourcing out-of-band text tracks 4. 4.7.13.11.4 Guidelines for exposing cues in various formats as text track cues 5. 4.7.13.11.5 Text track API 6. 4.7.13.11.6 Text tracks exposing in-band metadata 7. 4.7.13.11.7 Text tracks describing chapters 8. 4.7.13.11.8 Event handlers for objects of the text track APIs 9. 4.7.13.11.9 Best practices for metadata text tracks 12. 4.7.13.12 Identifying a track kind through a URL 13. 4.7.13.13 User interface 14. 4.7.13.14 Time ranges 15. 4.7.13.15 The TrackEvent interface 16. 4.7.13.16 Event summary 17. 4.7.13.17 Security and privacy considerations 18. 4.7.13.18 Best practices for authors using media elements 19. 4.7.13.19 Best practices for implementors of media elements 14. 4.7.14 The map element 15. 4.7.15 The area element 16. 4.7.16 Image maps 1. 4.7.16.1 Authoring 2. 4.7.16.2 Processing model 17. 4.7.17 MathML 18. 4.7.18 SVG 19. 4.7.19 Dimension attributes 8. 4.8 Links 1. 4.8.1 Introduction 2. 4.8.2 Links created by a and area elements 3. 4.8.3 API for a and area elements 4. 4.8.4 Following hyperlinks 5. 4.8.5 Downloading resources 6. 4.8.6 Link types 1. 4.8.6.1 Link type "alternate" 2. 4.8.6.2 Link type "author" 3. 4.8.6.3 Link type "bookmark" 4. 4.8.6.4 Link type "help" 5. 4.8.6.5 Link type "icon" 6. 4.8.6.6 Link type "license" 7. 4.8.6.7 Link type "nofollow" 8. 4.8.6.8 Link type "noopener" 9. 4.8.6.9 Link type "noreferrer" 10. 4.8.6.10 Link type "search" 11. 4.8.6.11 Link type "stylesheet" 12. 4.8.6.12 Link type "tag" 13. 4.8.6.13 Sequential link types 1. 4.8.6.13.1 Link type "next" 2. 4.8.6.13.2 Link type "prev" 14. 4.8.6.14 Other link types 9. 4.9 Tabular data 1. 4.9.1 The table element 1. 4.9.1.1 Techniques for describing tables 2. 4.9.1.2 Techniques for table design 2. 4.9.2 The caption element 3. 4.9.3 The colgroup element 4. 4.9.4 The col element 5. 4.9.5 The tbody element 6. 4.9.6 The thead element 7. 4.9.7 The tfoot element 8. 4.9.8 The tr element 9. 4.9.9 The td element 10. 4.9.10 The th element 11. 4.9.11 Attributes common to td and th elements 12. 4.9.12 Processing model 1. 4.9.12.1 Forming a table 2. 4.9.12.2 Forming relationships between data cells and header cells 13. 4.9.13 Examples 10. 4.10 Forms 1. 4.10.1 Introduction 1. 4.10.1.1 Writing a form’s user interface 2. 4.10.1.2 Implementing the server-side processing for a form 3. 4.10.1.3 Configuring a form to communicate with a server 4. 4.10.1.4 Client-side form validation 5. 4.10.1.5 Enabling client-side automatic filling of form controls 6. 4.10.1.6 The difference between the field type, the autofill field name, and the input modality 7. 4.10.1.7 Date, time, and number formats 2. 4.10.2 Categories 3. 4.10.3 The form element 4. 4.10.4 The label element 5. 4.10.5 The input element 1. 4.10.5.1 States of the type attribute 1. 4.10.5.1.1 Hidden state (type=hidden) 2. 4.10.5.1.2 Text (type=text) state and Search state (type=search) 3. 4.10.5.1.3 Telephone state (type=tel) 4. 4.10.5.1.4 URL state (type=url) 5. 4.10.5.1.5 E-mail state (type=email) 6. 4.10.5.1.6 Password state (type=password) 7. 4.10.5.1.7 Date state (type=date) 8. 4.10.5.1.8 Month state (type=month) 9. 4.10.5.1.9 Week state (type=week) 10. 4.10.5.1.10 Time state (type=time) 11. 4.10.5.1.11 Local Date and Time state (type=datetime-local) 12. 4.10.5.1.12 Number state (type=number) 13. 4.10.5.1.13 Range state (type=range) 14. 4.10.5.1.14 Color state (type=color) 15. 4.10.5.1.15 Checkbox state (type=checkbox) 16. 4.10.5.1.16 Radio Button state (type=radio) 17. 4.10.5.1.17 File Upload state (type=file) 18. 4.10.5.1.18 Submit Button state (type=submit) 19. 4.10.5.1.19 Image Button state (type=image) 20. 4.10.5.1.20 Reset Button state (type=reset) 21. 4.10.5.1.21 Button state (type=button) 2. 4.10.5.2 Implementation notes regarding localization of form controls 3. 4.10.5.3 Common input element attributes 1. 4.10.5.3.1 The maxlength and minlength attributes 2. 4.10.5.3.2 The size attribute 3. 4.10.5.3.3 The readonly attribute 4. 4.10.5.3.4 The required attribute 5. 4.10.5.3.5 The multiple attribute 6. 4.10.5.3.6 The pattern attribute 7. 4.10.5.3.7 The min and max attributes 8. 4.10.5.3.8 The step attribute 9. 4.10.5.3.9 The list attribute 10. 4.10.5.3.10 The placeholder attribute 4. 4.10.5.4 Common input element APIs 5. 4.10.5.5 Common event behaviors 6. 4.10.6 The button element 7. 4.10.7 The select element 8. 4.10.8 The datalist element 9. 4.10.9 The optgroup element 10. 4.10.10 The option element 11. 4.10.11 The textarea element 12. 4.10.12 The output element 13. 4.10.13 The progress element 14. 4.10.14 The meter element 15. 4.10.15 The fieldset element 16. 4.10.16 The legend element 17. 4.10.17 Form control infrastructure 1. 4.10.17.1 A form control value 2. 4.10.17.2 Mutability 3. 4.10.17.3 Association of controls and forms 18. 4.10.18 Attributes common to form controls 1. 4.10.18.1 Naming form controls: the name attribute 2. 4.10.18.2 Submitting element directionality: the dirname attribute 3. 4.10.18.3 Limiting user input length: the maxlength attribute 4. 4.10.18.4 Setting minimum input length requirements: the minlength attribute 5. 4.10.18.5 Enabling and disabling form controls: the disabled attribute 6. 4.10.18.6 Form submission 1. 4.10.18.6.1 Autofocusing a form control: the autofocus attribute 7. 4.10.18.7 Autofill 1. 4.10.18.7.1 Autofilling form controls: the autocomplete attribute 2. 4.10.18.7.2 Processing model 19. 4.10.19 APIs for text field selections 20. 4.10.20 Constraints 1. 4.10.20.1 Definitions 2. 4.10.20.2 Constraint validation 3. 4.10.20.3 The constraint validation API 4. 4.10.20.4 Security 21. 4.10.21 Form submission 1. 4.10.21.1 Introduction 2. 4.10.21.2 Implicit submission 3. 4.10.21.3 Form submission algorithm 4. 4.10.21.4 Constructing the form data set 5. 4.10.21.5 Selecting a form submission encoding 6. 4.10.21.6 URL-encoded form data 7. 4.10.21.7 Multipart form data 8. 4.10.21.8 Plain text form data 22. 4.10.22 Resetting a form 11. 4.11 Interactive elements 1. 4.11.1 The details element 2. 4.11.2 The summary element 3. 4.11.3 Commands 1. 4.11.3.1 Facets 2. 4.11.3.2 Using the a element to define a command 3. 4.11.3.3 Using the button element to define a command 4. 4.11.3.4 Using the input element to define a command 5. 4.11.3.5 Using the option element to define a command 6. 4.11.3.6 Using the accesskey attribute on a label element to define a command 7. 4.11.3.7 Using the accesskey attribute on a legend element to define a command 8. 4.11.3.8 Using the accesskey attribute to define a command on other elements 4. 4.11.4 The dialog element 1. 4.11.4.1 Anchor points 12. 4.12 Scripting 1. 4.12.1 The script element 1. 4.12.1.1 Processing model 2. 4.12.1.2 Scripting languages 3. 4.12.1.3 Restrictions for contents of script elements 4. 4.12.1.4 Inline documentation for external scripts 5. 4.12.1.5 Interaction of script elements and XSLT 2. 4.12.2 The noscript element 3. 4.12.3 The template element 1. 4.12.3.1 Interaction of template elements with XSLT and XPath 4. 4.12.4 The canvas element 1. 4.12.4.1 Color spaces and color correction 2. 4.12.4.2 Serializing bitmaps to a file 3. 4.12.4.3 Security with canvas elements 13. 4.13 Common idioms without dedicated elements 1. 4.13.1 Subheadings, subtitles, alternative titles and taglines 2. 4.13.2 Bread crumb navigation 3. 4.13.3 Tag clouds 4. 4.13.4 Conversations 5. 4.13.5 Footnotes 14. 4.14 Disabled elements 15. 4.15 Matching HTML elements using selectors 1. 4.15.1 Case-sensitivity 2. 4.15.2 Pseudo-classes 5. 5 User interaction 1. 5.1 The hidden attribute 2. 5.2 Inert subtrees 3. 5.3 Activation 4. 5.4 Focus 1. 5.4.1 Introduction 2. 5.4.2 Data model 3. 5.4.3 The tabindex attribute 4. 5.4.4 Processing model 5. 5.4.5 Sequential focus navigation 6. 5.4.6 Focus management APIs 7. 5.4.7 Clipboard actions and focus 5. 5.5 Assigning keyboard shortcuts 1. 5.5.1 Introduction 2. 5.5.2 The accesskey attribute 3. 5.5.3 Processing model 6. 5.6 Editing 1. 5.6.1 Making document regions editable: The contenteditable content attribute 2. 5.6.2 Making entire documents editable: The designMode IDL attribute 3. 5.6.3 Best practices for in-page editors 4. 5.6.4 Editing APIs 5. 5.6.5 Spelling and grammar checking 7. 5.7 Drag and drop 1. 5.7.1 Introduction 2. 5.7.2 The drag data store 3. 5.7.3 The DataTransfer interface 1. 5.7.3.1 The DataTransferItemList interface 2. 5.7.3.2 The DataTransferItem interface 4. 5.7.4 The DragEvent interface 5. 5.7.5 Drag-and-drop processing model 6. 5.7.6 Events summary 7. 5.7.7 The draggable attribute 8. 5.7.8 Security risks in the drag-and-drop model 6. 6 Loading Web pages 1. 6.1 Browsing contexts 1. 6.1.1 Nested browsing contexts 1. 6.1.1.1 Navigating nested browsing contexts in the DOM 2. 6.1.2 Auxiliary browsing contexts 1. 6.1.2.1 Navigating auxiliary browsing contexts in the DOM 3. 6.1.3 Security 4. 6.1.4 Groupings of browsing contexts 5. 6.1.5 Browsing context names 6. 6.1.6 Script settings for browsing contexts 2. 6.2 Security infrastructure for Window, WindowProxy, and Location objects 1. 6.2.1 Integration with IDL 2. 6.2.2 Shared internal slot: [[CrossOriginPropertyDescriptorMap]] 3. 6.2.3 Shared abstract operations 1. 6.2.3.1 CrossOriginProperties ( O ) 2. 6.2.3.2 IsPlatformObjectSameOrigin ( O ) 3. 6.2.3.3 CrossOriginGetOwnPropertyHelper ( O, P ) 1. 6.2.3.3.1 CrossOriginPropertyDescriptor ( crossOriginProperty, originalDesc ) 2. 6.2.3.3.2 CrossOriginFunctionWrapper ( needsWrapping, functionToWrap ) 4. 6.2.3.4 CrossOriginGet ( O, P, Receiver ) 5. 6.2.3.5 CrossOriginSet ( O, P, V, Receiver ) 6. 6.2.3.6 CrossOriginOwnPropertyKeys ( O ) 3. 6.3 The Window object 1. 6.3.1 APIs for creating and navigating browsing contexts by name 2. 6.3.2 Accessing other browsing contexts 3. 6.3.3 Named access on the Window object 4. 6.3.4 Garbage collection and browsing contexts 5. 6.3.5 Closing browsing contexts 6. 6.3.6 Browser interface elements 7. 6.3.7 The WindowProxy object 1. 6.3.7.1 The WindowProxy internal methods 1. 6.3.7.1.1 [[GetPrototypeOf]] ( ) 2. 6.3.7.1.2 [[SetPrototypeOf]] ( V ) 3. 6.3.7.1.3 [[IsExtensible]] ( ) 4. 6.3.7.1.4 [[PreventExtensions]] ( ) 5. 6.3.7.1.5 [[GetOwnProperty]] ( P ) 6. 6.3.7.1.6 [[DefineOwnProperty]] ( P, Desc ) 7. 6.3.7.1.7 [[Get]] ( P, Receiver ) 8. 6.3.7.1.8 [[Set]] ( P, V, Receiver ) 9. 6.3.7.1.9 [[Delete]] ( P ) 10. 6.3.7.1.10 [[OwnPropertyKeys]] ( ) 4. 6.4 Origin 1. 6.4.1 Relaxing the same-origin restriction 5. 6.5 Sandboxing 6. 6.6 Session history and navigation 1. 6.6.1 The session history of browsing contexts 2. 6.6.2 The History interface 3. 6.6.3 Implementation notes for session history 4. 6.6.4 The Location interface 1. 6.6.4.1 The Location internal methods 1. 6.6.4.1.1 [[GetPrototypeOf]] ( ) 2. 6.6.4.1.2 [[SetPrototypeOf]] ( V ) 3. 6.6.4.1.3 [[IsExtensible]] ( ) 4. 6.6.4.1.4 [[PreventExtensions]] ( ) 5. 6.6.4.1.5 [[GetOwnProperty]] ( P ) 6. 6.6.4.1.6 [[DefineOwnProperty]] ( P, Desc ) 7. 6.6.4.1.7 [[Get]] ( P, Receiver ) 8. 6.6.4.1.8 [[Set]] ( P, V, Receiver ) 9. 6.6.4.1.9 [[Delete]] ( P ) 10. 6.6.4.1.10 [[OwnPropertyKeys]] ( ) 7. 6.7 Browsing the Web 1. 6.7.1 Navigating across documents 2. 6.7.2 Page load processing model for HTML files 3. 6.7.3 Page load processing model for XML files 4. 6.7.4 Page load processing model for text files 5. 6.7.5 Page load processing model for multipart/x-mixed-replace resources 6. 6.7.6 Page load processing model for media 7. 6.7.7 Page load processing model for content that uses plugins 8. 6.7.8 Page load processing model for inline content that doesn’t have a DOM 9. 6.7.9 Navigating to a fragment 10. 6.7.10 History traversal 1. 6.7.10.1 Persisted user state restoration 2. 6.7.10.2 The PopStateEvent interface 3. 6.7.10.3 The HashChangeEvent interface 4. 6.7.10.4 The PageTransitionEvent interface 11. 6.7.11 Unloading documents 1. 6.7.11.1 The BeforeUnloadEvent interface 12. 6.7.12 Aborting a document load 13. 6.7.13 Browser state 7. 7 Web application APIs 1. 7.1 Scripting 1. 7.1.1 Introduction 2. 7.1.2 Enabling and disabling scripting 3. 7.1.3 Processing model 1. 7.1.3.1 Definitions 2. 7.1.3.2 Fetching scripts 3. 7.1.3.3 Creating scripts 4. 7.1.3.4 Calling scripts 5. 7.1.3.5 Realms, settings objects, and global objects 1. 7.1.3.5.1 Entry 2. 7.1.3.5.2 Incumbent 3. 7.1.3.5.3 Current 4. 7.1.3.5.4 Relevant 6. 7.1.3.6 Killing scripts 7. 7.1.3.7 Integration with the JavaScript job queue 1. 7.1.3.7.1 EnqueueJob(queueName, job, arguments) 8. 7.1.3.8 Integration with the JavaScript module system 1. 7.1.3.8.1 HostResolveImportedModule(referencingModule, specifier) 9. 7.1.3.9 Runtime script errors 1. 7.1.3.9.1 Runtime script errors in documents 2. 7.1.3.9.2 The ErrorEvent interface 10. 7.1.3.10 Unhandled promise rejections 1. 7.1.3.10.1 The HostPromiseRejectionTracker implementation 2. 7.1.3.10.2 The PromiseRejectionEvent interface 11. 7.1.3.11 HostEnsureCanCompileStrings(callerRealm, calleeRealm) 4. 7.1.4 Event loops 1. 7.1.4.1 Definitions 2. 7.1.4.2 Processing model 3. 7.1.4.3 Generic task sources 5. 7.1.5 Events 1. 7.1.5.1 Event handlers 2. 7.1.5.2 Event handlers on elements, Document objects, and Window objects 1. 7.1.5.2.1 IDL definitions 3. 7.1.5.3 Event firing 4. 7.1.5.4 Events and the Window object 2. 7.2 The WindowOrWorkerGlobalScope mixin 3. 7.3 Base64 utility methods 4. 7.4 Dynamic markup insertion 1. 7.4.1 Opening the input stream 2. 7.4.2 Closing the input stream 3. 7.4.3 document.write() 4. 7.4.4 document.writeln() 5. 7.5 Timers 6. 7.6 User prompts 1. 7.6.1 Simple dialogs 2. 7.6.2 Printing 7. 7.7 System state and capabilities 1. 7.7.1 The Navigator object 1. 7.7.1.1 Client identification 2. 7.7.1.2 Language preferences 3. 7.7.1.3 Custom scheme and content handlers: the registerProtocolHandler() and registerContentHandler() methods 1. 7.7.1.3.1 Security and privacy 2. 7.7.1.3.2 Sample user interface 4. 7.7.1.4 Cookies 8. 7.8 Images 9. 7.9 Animation Frames 8. 8 The HTML syntax 1. 8.1 Writing HTML documents 1. 8.1.1 The DOCTYPE 2. 8.1.2 Elements 1. 8.1.2.1 Start tags 2. 8.1.2.2 End tags 3. 8.1.2.3 Attributes 4. 8.1.2.4 Optional tags 5. 8.1.2.5 Restrictions on content models 6. 8.1.2.6 Restrictions on the contents of raw text and escapable raw text elements 3. 8.1.3 Text 1. 8.1.3.1 Newlines 4. 8.1.4 Character references 5. 8.1.5 CDATA sections 6. 8.1.6 Comments 2. 8.2 Parsing HTML documents 1. 8.2.1 Overview of the parsing model 2. 8.2.2 The input byte stream 1. 8.2.2.1 Parsing with a known character encoding 2. 8.2.2.2 Determining the character encoding 3. 8.2.2.3 Character encodings 4. 8.2.2.4 Changing the encoding while parsing 5. 8.2.2.5 Preprocessing the input stream 3. 8.2.3 Parse state 1. 8.2.3.1 The insertion mode 2. 8.2.3.2 The stack of open elements 3. 8.2.3.3 The list of active formatting elements 4. 8.2.3.4 The element pointers 5. 8.2.3.5 Other parsing state flags 4. 8.2.4 Tokenization 1. 8.2.4.1 Data state 2. 8.2.4.2 RCDATA state 3. 8.2.4.3 RAWTEXT state 4. 8.2.4.4 Script data state 5. 8.2.4.5 PLAINTEXT state 6. 8.2.4.6 Tag open state 7. 8.2.4.7 End tag open state 8. 8.2.4.8 Tag name state 9. 8.2.4.9 RCDATA less-than sign state 10. 8.2.4.10 RCDATA end tag open state 11. 8.2.4.11 RCDATA end tag name state 12. 8.2.4.12 RAWTEXT less-than sign state 13. 8.2.4.13 RAWTEXT end tag open state 14. 8.2.4.14 RAWTEXT end tag name state 15. 8.2.4.15 Script data less-than sign state 16. 8.2.4.16 Script data end tag open state 17. 8.2.4.17 Script data end tag name state 18. 8.2.4.18 Script data escape start state 19. 8.2.4.19 Script data escape start dash state 20. 8.2.4.20 Script data escaped state 21. 8.2.4.21 Script data escaped dash state 22. 8.2.4.22 Script data escaped dash dash state 23. 8.2.4.23 Script data escaped less-than sign state 24. 8.2.4.24 Script data escaped end tag open state 25. 8.2.4.25 Script data escaped end tag name state 26. 8.2.4.26 Script data double escape start state 27. 8.2.4.27 Script data double escaped state 28. 8.2.4.28 Script data double escaped dash state 29. 8.2.4.29 Script data double escaped dash dash state 30. 8.2.4.30 Script data double escaped less-than sign state 31. 8.2.4.31 Script data double escape end state 32. 8.2.4.32 Before attribute name state 33. 8.2.4.33 Attribute name state 34. 8.2.4.34 After attribute name state 35. 8.2.4.35 Before attribute value state 36. 8.2.4.36 Attribute value (double-quoted) state 37. 8.2.4.37 Attribute value (single-quoted) state 38. 8.2.4.38 Attribute value (unquoted) state 39. 8.2.4.39 After attribute value (quoted) state 40. 8.2.4.40 Self-closing start tag state 41. 8.2.4.41 Bogus comment state 42. 8.2.4.42 Markup declaration open state 43. 8.2.4.43 Comment start state 44. 8.2.4.44 Comment start dash state 45. 8.2.4.45 Comment state 46. 8.2.4.46 Comment less-than sign state 47. 8.2.4.47 Comment less-than sign bang state 48. 8.2.4.48 Comment less-than sign bang dash state 49. 8.2.4.49 Comment less-than sign bang dash dash state 50. 8.2.4.50 Comment end dash state 51. 8.2.4.51 Comment end state 52. 8.2.4.52 Comment end bang state 53. 8.2.4.53 DOCTYPE state 54. 8.2.4.54 Before DOCTYPE name state 55. 8.2.4.55 DOCTYPE name state 56. 8.2.4.56 After DOCTYPE name state 57. 8.2.4.57 After DOCTYPE public keyword state 58. 8.2.4.58 Before DOCTYPE public identifier state 59. 8.2.4.59 DOCTYPE public identifier (double-quoted) state 60. 8.2.4.60 DOCTYPE public identifier (single-quoted) state 61. 8.2.4.61 After DOCTYPE public identifier state 62. 8.2.4.62 Between DOCTYPE public and system identifiers state 63. 8.2.4.63 After DOCTYPE system keyword state 64. 8.2.4.64 Before DOCTYPE system identifier state 65. 8.2.4.65 DOCTYPE system identifier (double-quoted) state 66. 8.2.4.66 DOCTYPE system identifier (single-quoted) state 67. 8.2.4.67 After DOCTYPE system identifier state 68. 8.2.4.68 Bogus DOCTYPE state 69. 8.2.4.69 CDATA section state 70. 8.2.4.70 CDATA section bracket state 71. 8.2.4.71 CDATA section end state 72. 8.2.4.72 Character reference state 73. 8.2.4.73 Numeric character reference state 74. 8.2.4.74 Hexadecimal character reference start state 75. 8.2.4.75 Decimal character reference start state 76. 8.2.4.76 Hexadecimal character reference state 77. 8.2.4.77 Decimal character reference state 78. 8.2.4.78 Numeric character reference end state 79. 8.2.4.79 Character reference end state 5. 8.2.5 Tree construction 1. 8.2.5.1 Creating and inserting nodes 2. 8.2.5.2 Parsing elements that contain only text 3. 8.2.5.3 Closing elements that have implied end tags 4. 8.2.5.4 The rules for parsing tokens in HTML content 1. 8.2.5.4.1 The "initial" insertion mode 2. 8.2.5.4.2 The "before html" insertion mode 3. 8.2.5.4.3 The "before head" insertion mode 4. 8.2.5.4.4 The "in head" insertion mode 5. 8.2.5.4.5 The "in head noscript" insertion mode 6. 8.2.5.4.6 The "after head" insertion mode 7. 8.2.5.4.7 The "in body" insertion mode 8. 8.2.5.4.8 The "text" insertion mode 9. 8.2.5.4.9 The "in table" insertion mode 10. 8.2.5.4.10 The "in table text" insertion mode 11. 8.2.5.4.11 The "in caption" insertion mode 12. 8.2.5.4.12 The "in column group" insertion mode 13. 8.2.5.4.13 The "in table body" insertion mode 14. 8.2.5.4.14 The "in row" insertion mode 15. 8.2.5.4.15 The "in cell" insertion mode 16. 8.2.5.4.16 The "in select" insertion mode 17. 8.2.5.4.17 The "in select in table" insertion mode 18. 8.2.5.4.18 The "in template" insertion mode 19. 8.2.5.4.19 The "after body" insertion mode 20. 8.2.5.4.20 The "in frameset" insertion mode 21. 8.2.5.4.21 The "after frameset" insertion mode 22. 8.2.5.4.22 The "after after body" insertion mode 23. 8.2.5.4.23 The "after after frameset" insertion mode 5. 8.2.5.5 The rules for parsing tokens in foreign content 6. 8.2.6 The end 7. 8.2.7 Coercing an HTML DOM into an infoset 8. 8.2.8 An introduction to error handling and strange cases in the parser 1. 8.2.8.1 Misnested tags: 2. 8.2.8.2 Misnested tags:
3. 8.2.8.3 Unexpected markup in tables 4. 8.2.8.4 Scripts that modify the page as it is being parsed 5. 8.2.8.5 The execution of scripts that are moving across multiple documents 6. 8.2.8.6 Unclosed formatting elements 3. 8.3 Serializing HTML fragments 4. 8.4 Parsing HTML fragments 5. 8.5 Named character references 9. 9 The XML syntax 1. 9.1 Writing documents in the XML syntax 2. 9.2 Parsing XML documents 3. 9.3 Serializing XML fragments 4. 9.4 Parsing XML fragments 10. 10 Rendering 1. 10.1 Introduction 2. 10.2 The CSS user agent style sheet and presentational hints 3. 10.3 Non-replaced elements 1. 10.3.1 Hidden elements 2. 10.3.2 The page 3. 10.3.3 Flow content 4. 10.3.4 Phrasing content 5. 10.3.5 Bidirectional text 6. 10.3.6 Quotes 7. 10.3.7 Sections and headings 8. 10.3.8 Lists 9. 10.3.9 Tables 10. 10.3.10 Margin collapsing quirks 11. 10.3.11 Form controls 12. 10.3.12 The hr element 13. 10.3.13 The fieldset and legend elements 4. 10.4 Replaced elements 1. 10.4.1 Embedded content 2. 10.4.2 Images 3. 10.4.3 Attributes for embedded content and images 4. 10.4.4 Image maps 5. 10.5 Widgets 1. 10.5.1 Introduction 2. 10.5.2 The button element 3. 10.5.3 The details and summary elements 4. 10.5.4 The input element as a text entry widget. 5. 10.5.5 The input element as domain-specific widgets 6. 10.5.6 The input element as a range control 7. 10.5.7 The input element as a color well 8. 10.5.8 The input element as a checkbox and radio button widgets 9. 10.5.9 The input element as a file upload control 10. 10.5.10 The input element as a button 11. 10.5.11 The marquee element 12. 10.5.12 The meter element 13. 10.5.13 The progress element 14. 10.5.14 The select element 15. 10.5.15 The textarea element 6. 10.6 Frames and framesets 7. 10.7 Interactive media 1. 10.7.1 Links, forms, and navigation 2. 10.7.2 The title attribute 3. 10.7.3 Editing hosts 4. 10.7.4 Text rendered in native user interfaces 8. 10.8 Print media 9. 10.9 Unstyled XML documents 11. 11 Obsolete features 1. 11.1 Obsolete but conforming features 1. 11.1.1 Warnings for obsolete but conforming features 2. 11.2 Non-conforming features 3. 11.3 Requirements for implementations 1. 11.3.1 The applet element 2. 11.3.2 The marquee element 3. 11.3.3 Frames 4. 11.3.4 Other elements, attributes and APIs 1. 11.3.4.1 Plugins 12. 12 IANA considerations 1. 12.1 text/html 2. 12.2 multipart/x-mixed-replace 3. 12.3 application/xhtml+xml 4. 12.4 web+ scheme prefix 13. Index 1. Terms defined by this specification 2. Terms defined by reference 3. Elements 4. Element content categories 5. Attributes 6. Element Interfaces 7. Events 14. Property Index 15. IDL Index 16. References 1. Normative References 2. Informative References 17. Changes 1. New features 2. Features removed 3. Fixing bugs and matching reality better 4. New concepts 5. Editorial clarifications 18. Acknowledgements 1. People who have contributed to this version of HTML 2. People who have contributed to previous revisions of HTML 5.x 1. Introduction 1.1. Background This section is non-normative. HTML is the World Wide Web’s core markup language. Originally, HTML was primarily designed as a language for semantically describing scientific documents. Its general design, however, has enabled it to be adapted, over the subsequent years, to describe a number of other types of documents and even applications. 1.2. Audience This section is non-normative. This specification is intended for authors of documents and scripts that use the features defined in this specification, implementors of tools that operate on pages that use the features defined in this specification, and individuals wishing to establish the correctness of documents or implementations with respect to the requirements of this specification. This document is probably not suited to readers who do not already have at least a passing familiarity with Web technologies, as in places it sacrifices clarity for precision, and brevity for completeness. More approachable tutorials and authoring guides can provide a gentler introduction to the topic. In particular, familiarity with the basics of DOM is necessary for a complete understanding of some of the more technical parts of this specification. An understanding of Web IDL, HTTP, XML, Unicode, character encodings, JavaScript, and CSS will also be helpful in places but is not essential. 1.3. Scope This section is non-normative. This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications. The scope of this specification does not include providing mechanisms for media-specific customization of presentation (although default rendering rules for Web browsers are included at the end of this specification, and several mechanisms for hooking into CSS are provided as part of the language). The scope of this specification is not to describe an entire operating system. In particular, hardware configuration software, image manipulation tools, and applications that users would be expected to use with high-end workstations on a daily basis are out of scope. In terms of applications, this specification is targeted specifically at applications that would be expected to be used by users on an occasional basis, or regularly but from disparate locations, with low CPU requirements. Examples of such applications include online purchasing systems, searching systems, games (especially multiplayer online games), public telephone books or address books, communications software (e-mail clients, instant messaging clients, discussion software), document editing software, etc. 1.4. History This section is non-normative. For its first five years (1990-1995), HTML went through a number of revisions and experienced a number of extensions, primarily hosted first at CERN, and then at the IETF. With the creation of the W3C, HTML’s development changed venue again. A first abortive attempt at extending HTML in 1995 known as HTML 3.0 then made way to a more pragmatic approach known as HTML 3.2, which was completed in 1997. HTML 4.01 quickly followed later that same year. The following year, the W3C membership decided to stop evolving HTML and instead begin work on an XML-based equivalent, called XHTML. This effort started with a reformulation of HTML 4.01 in XML, known as XHTML 1.0, which added no new features except the new serialization, and which was completed in 2000. After XHTML 1.0, the W3C’s focus turned to making it easier for other working groups to extend XHTML, under the banner of XHTML Modularization. In parallel with this, the W3C also worked on a new language that was not compatible with the earlier HTML and XHTML languages, calling it XHTML 2.0. Around the time that HTML’s evolution was stopped in 1998, parts of the API for HTML developed by browser vendors were specified and published under the name DOM Level 1 (in 1998) and DOM Level 2 Core and DOM Level 2 HTML (starting in 2000 and culminating in 2003). These efforts then petered out, with some DOM Level 3 specifications published in 2004 but the working group being closed before all the Level 3 drafts were completed. In 2003, the publication of XForms, a technology which was positioned as the next generation of Web forms, sparked a renewed interest in evolving HTML itself, rather than finding replacements for it. This interest was borne from the realization that XML’s deployment as a Web technology was limited to entirely new technologies (like RSS and later Atom), rather than as a replacement for existing deployed technologies (like HTML). A proof of concept to show that it was possible to extend HTML 4.01’s forms to provide many of the features that XForms 1.0 introduced, without requiring browsers to implement rendering engines that were incompatible with existing HTML Web pages, was the first result of this renewed interest. At this early stage, while the draft was already publicly available, and input was already being solicited from all sources, the specification was only under Opera Software’s copyright. The idea that HTML’s evolution should be reopened was tested at a W3C workshop in 2004, where some of the principles that underlie the HTML work (described below), as well as the aforementioned early draft proposal covering just forms-related features, were presented to the W3C jointly by Mozilla and Opera. The proposal was rejected on the grounds that the proposal conflicted with the previously chosen direction for the Web’s evolution; the W3C staff and membership voted to continue developing XML-based replacements instead. Shortly thereafter, Apple, Mozilla, and Opera jointly announced their intent to continue working on the effort under the umbrella of a new venue called the WHATWG. A public mailing list was created, and the draft was moved to the WHATWG site. The copyright was subsequently amended to be jointly owned by all three vendors, and to allow reuse of the specification. The WHATWG was based on several core principles, in particular that technologies need to be backwards compatible, that specifications and implementations need to match even if this means changing the specification rather than the implementations, and that specifications need to be detailed enough that implementations can achieve complete interoperability without reverse-engineering each other. The latter requirement in particular required that the scope of the HTML specification include what had previously been specified in three separate documents: HTML 4.01, XHTML 1.1, and DOM Level 2 HTML. It also meant including significantly more detail than had previously been considered the norm. In 2006, the W3C indicated an interest to participate in the development of HTML 5.0 after all, and in 2007 formed a working group chartered to work with the WHATWG on the development of the HTML specification. Apple, Mozilla, and Opera allowed the W3C to publish the specification under the W3C copyright, while keeping a version with the less restrictive license on the WHATWG site. For a number of years, both groups then worked together under the same editor: Ian Hickson. In 2011, the groups came to the conclusion that they had different goals: the W3C wanted to draw a line in the sand for features for a HTML 5.0 Recommendation, while the WHATWG wanted to continue working on a Living Standard for HTML, continuously maintaining the specification and adding new features. In mid 2012, a new editing team was introduced at the W3C to take care of creating a HTML 5.0 Recommendation and prepare a Working Draft for the next HTML version. Since then, the W3C Web Platform WG has been cherry picking patches from the WHATWG that resolved bugs registered on the W3C HTML specification or more accurately represented implemented reality in user agents. At time of publication of this document, patches from the WHATWG HTML specification have been merged until January 12, 2016. The W3C HTML editors have also added patches that resulted from discussions and decisions made by the W3C Web Platform WG as well a bug fixes from bugs not shared by the WHATWG. A separate document is published to document the differences between the HTML specified in this document and the language described in the HTML 4.01 specification. [HTML5-DIFF] 1.5. Design notes This section is non-normative. It must be admitted that many aspects of HTML appear at first glance to be nonsensical and inconsistent. HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been developed over a period of several decades by a wide array of people with different priorities who, in many cases, did not know of each other’s existence. Features have thus arisen from many sources, and have not always been designed in especially consistent ways. Furthermore, because of the unique characteristics of the Web, implementation bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally written in ways that rely on them before they can be fixed. Despite all this, efforts have been made to adhere to certain design goals. These are described in the next few subsections. 1.5.1. Serializability of script execution This section is non-normative. To avoid exposing Web authors to the complexities of multithreading, the HTML and DOM APIs are designed such that no script can ever detect the simultaneous execution of other scripts. Even with workers, the intent is that the behavior of implementations can be thought of as completely serializing the execution of all scripts in all browsing contexts. 1.5.2. Compliance with other specifications This section is non-normative. This specification interacts with and relies on a wide variety of other specifications. In certain circumstances, unfortunately, conflicting needs have led to this specification violating the requirements of these other specifications. Whenever this has occurred, the transgressions have each been noted as a "willful violation", and the reason for the violation has been noted. 1.5.3. Extensibility This section is non-normative. HTML has a wide array of extensibility mechanisms that can be used for adding semantics in a safe manner: * Authors can use the class attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don’t know of the extension can still support it somewhat well. This is the tack used by microformats, for example. * Authors can include data for inline client-side scripts or server-side site-wide scripts to process using the data-*="" attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process. * Authors can use the meta name="" content="" mechanism to include page-wide metadata by registering extensions to the predefined set of metadata names. * Authors can use the rel="" mechanism to annotate links with specific meanings by registering extensions to the predefined set of link types. This is also used by microformats. * Authors can embed raw data using the script type="" mechanism with a custom type, for further handling by inline or server-side scripts. * Authors can extend APIs using the JavaScript prototyping mechanism. This is widely used by script libraries, for instance. 1.6. HTML vs XML Syntax This section is non-normative. This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language. The in-memory representation is known as "DOM HTML", or "the DOM" for short. There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification. The first such concrete syntax is the HTML syntax. This is the format suggested for most authors. It is compatible with most legacy Web browsers. If a document is transmitted with the text/html MIME type, then it will be processed as an HTML document by Web browsers. This specification defines the latest version of the HTML syntax, known simply as "HTML". The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines the latest version of the XHTML syntax, known simply as "XHTML". The DOM, the HTML syntax, and the XHTML syntax cannot all represent the same content. For example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM and in the XHTML syntax. Similarly, documents that use the noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in the XHTML syntax. Comments that contain the string "-->" can only be represented in the DOM, not in the HTML and XHTML syntaxes. 1.7. Structure of this specification This section is non-normative. This specification is divided into the following major sections: §1 Introduction Non-normative materials providing a context for the HTML specification. §2 Common infrastructure The conformance classes, algorithms, definitions, and the common underpinnings of the rest of the specification. §3 Semantics, structure, and APIs of HTML documents Documents are built from elements. These elements form a tree using the DOM. This section defines the features of this DOM, as well as introducing the features common to all elements, and the concepts used in defining elements. §4 The elements of HTML Each element has a predefined meaning, which is explained in this section. Rules for authors on how to use the element, along with user agent requirements for how to handle each element, are also given. This includes large signature features of HTML such as video playback and subtitles, form controls and form submission, and a 2D graphics API known as the HTML canvas. §5 User interaction HTML documents can provide a number of mechanisms for users to interact with and modify content, which are described in this section, such as how focus works, and drag-and-drop. §6 Loading Web pages HTML documents do not exist in a vacuum — this section defines many of the features that affect environments that deal with multiple pages, such as Web browsers and offline caching of Web applications. §7 Web application APIs This section introduces basic features for scripting of applications in HTML. §8 The HTML syntax §9 The XML syntax All of these features would be for naught if they couldn’t be represented in a serialized form and sent to other people, and so these sections define the syntaxes of HTML and XHTML, along with rules for how to parse content using those syntaxes. §10 Rendering This section defines the default rendering rules for Web browsers. There are also some appendices, listing §11 Obsolete features and §12 IANA considerations, and several indices. 1.7.1. How to read this specification This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references. As described in the conformance requirements section below, this specification describes conformance criteria for a variety of conformance classes. In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example Web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act. For example, "the foo attribute’s value must be a valid integer" is a requirement on producers, as it lays out the allowed values; in contrast, the requirement "the foo attribute’s value must be parsed using the rules for parsing integers" is a requirement on consumers, as it describes how to process the content. Requirements on producers have no bearing whatsoever on consumers. Continuing the above example, a requirement stating that a particular attribute’s value is constrained to being a valid integer emphatically does not imply anything about the requirements on consumers. It might be that the consumers are in fact required to treat the attribute as an opaque string, completely unaffected by whether the value conforms to the requirements or not. It might be (as in the previous example) that the consumers are required to parse the value using specific rules that define how invalid (non-numeric in this case) values are to be processed. 1.7.2. Typographic conventions This is a definition, requirement, or explanation. This is a note. This is an example. This is an open issue. This is a warning. interface Example { // this is an IDL definition }; variable = object . method( [ optionalArgument ] ) This is a note to authors describing the usage of an interface. /* this is a CSS fragment */ The defining instance of a term is marked up like this. Uses of that term are marked up like this or like this. The defining instance of an element, attribute, or API is marked up like this. References to that element, attribute, or API are marked up like this. Other code fragments are marked up like this. Byte sequences with bytes in the range 0x00 to 0x7F, inclusive, are marked up like this. Variables are marked up like this. In an algorithm, steps in synchronous sections are marked with ⌛. In some cases, requirements are given in the form of lists with conditions and corresponding requirements. In such cases, the requirements that apply to a condition are always the first set of requirements that follow the condition, even in the case of there being multiple sets of conditions for those requirements. Such cases are presented as follows: This is a condition This is another condition This is the requirement that applies to the conditions above. This is a third condition This is the requirement that applies to the third condition. 1.8. Privacy concerns This section is non-normative. Some features of HTML trade user convenience for a measure of user privacy. In general, due to the Internet’s architecture, a user can be distinguished from another by the user’s IP address. IP addresses do not perfectly match to a user; as a user moves from device to device, or from network to network, their IP address will change; similarly, NAT routing, proxy servers, and shared computers enable packets that appear to all come from a single IP address to actually map to multiple users. Technologies such as onion routing can be used to further anonymize requests so that requests from a single user at one node on the Internet appear to come from many disparate parts of the network. However, the IP address used for a user’s requests is not the only mechanism by which a user’s requests could be related to each other. Cookies, for example, are designed specifically to enable this, and are the basis of most of the Web’s session features that enable you to log into a site with which you have an account. There are other mechanisms that are more subtle. Certain characteristics of a user’s system can be used to distinguish groups of users from each other; by collecting enough such information, an individual user’s browser’s "digital fingerprint" can be computed, which can be as good, if not better, as an IP address in ascertaining which requests are from the same user. Grouping requests in this manner, especially across multiple sites, can be used for both benign (and even arguably positive) purposes, as well as for malevolent purposes. An example of a reasonably benign purpose would be determining whether a particular person seems to prefer sites with dog illustrations as opposed to sites with cat illustrations (based on how often they visit the sites in question) and then automatically using the preferred illustrations on subsequent visits to participating sites. Malevolent purposes, however, could include governments combining information such as the person’s home address (determined from the addresses they use when getting driving directions on one site) with their apparent political affiliations (determined by examining the forum sites that they participate in) to determine whether the person should be prevented from voting in an election. Since the malevolent purposes can be remarkably evil, user agent implementors are encouraged to consider how to provide their users with tools to minimize leaking information that could be used to fingerprint a user. Unfortunately, as the first paragraph in this section implies, sometimes there is great benefit to be derived from exposing the very information that can also be used for fingerprinting purposes, so it’s not as easy as simply blocking all possible leaks. For instance, the ability to log into a site to post under a specific identity requires that the user’s requests be identifiable as all being from the same user. More subtly, though, information such as how wide text is, which is necessary for many effects that involve drawing text onto a canvas (e.g., any effect that involves drawing a border around the text) also leaks information that can be used to group a user’s requests. (In this case, by potentially exposing, via a brute force search, which fonts a user has installed, information which can vary considerably from user to user.) Features in this specification which can be used to fingerprint the user are marked as this paragraph is. (This is a fingerprinting vector.) Other features in the platform can be used for the same purpose, though, including, though not limited to: * The exact list of which features a user agents supports. * The maximum allowed stack depth for recursion in script. * Features that describe the user’s environment, like Media Queries and the Screen object. [MEDIAQ] [CSSOM-VIEW] * The user’s time zone. 1.9. A quick introduction to HTML This section is non-normative. A basic HTML document looks like this:This is a simple sample.
HTML documents consist of a tree of elements and text. Each element is denoted in the source by a start tag, such as "body", and an end tag, such as "/body". (Certain start tags and end tags can in certain cases be omitted and are implied by other tags.) Tags have to be nested such that elements are all completely within each other, without overlapping:This is very wrong!
This is correct.
This specification defines a set of elements that can be used in HTML, along with rules about the ways in which the elements can be nested. Elements can have attributes, which control how the elements work. In the example below, there is a hyperlink, formed using the a element and its href attribute: simple Attributes are placed inside the start tag, and consist of a name and a value, separated by an "=" character. The attribute value can remain unquoted if it doesn’t contain space characters or any of " ' ` = < or >. Otherwise, it has to be quoted using either single or double quotes. The value, along with the "=" character, can be omitted altogether if the value is the empty string. HTML user agents (e.g., Web browsers) then parse this markup, turning it into a DOM (Document Object Model) tree. A DOM tree is an in-memory representation of a document. DOM trees contain several kinds of nodes, in particular a DocumentType node, Element nodes, Text nodes, Comment nodes, and in some cases ProcessingInstruction nodes. The markup snippet at the top of this section would be turned into the following DOM tree: * DOCTYPE: html * html * head * #text: ⏎␣␣ * title * #text: Sample page * #text: ⏎␣ * #text: ⏎␣ * body * #text: ⏎␣␣ * h1 * #text: Sample page * #text: ⏎␣␣ * p * #text: This is a * a href="demo.html" * #text: simple * #text: sample. * #text: ⏎␣␣ * #comment: this is a comment * #text: ⏎␣⏎ The document element of this tree is the html element, which is the element always found in that position in HTML documents. It contains two elements, head and body, as well as a Text node between them. There are many more Text nodes in the DOM tree than one would initially expect, because the source contains a number of spaces (represented here by "␣") and line breaks ("⏎") that all end up as Text nodes in the DOM. However, for historical reasons not all of the spaces and line breaks in the original markup appear in the DOM. In particular, all the white space before head start tag ends up being dropped silently, and all the white space after the body end tag ends up placed at the end of the body. The head element contains a title element, which itself contains a Text node with the text "Sample page". Similarly, the body element contains an h1 element, a p element, and a comment. ---------------------------------------------------------------------- This DOM tree can be manipulated from scripts in the page. Scripts (typically in JavaScript) are small programs that can be embedded using the script element or using event handler content attributes. For example, here is a form with a script that sets the value of the form’s output element to say "Hello World" Each element in the DOM tree is represented by an object, and these objects have APIs so that they can be manipulated. For instance, a link (e.g., the a element in the tree above) can have its "href" attribute changed in several ways: var a = document.links[0]; // obtain the first link in the document a.href = 'sample.html'; // change the destination URL of the link a.protocol = 'https'; // change just the scheme part of the URL a.setAttribute('href', 'http://example.com/'); // change the content attribute directly Since DOM trees are used as the way to represent HTML documents when they are processed and presented by implementations (especially interactive implementations like Web browsers), this specification is mostly phrased in terms of DOM trees, instead of the markup described above. ---------------------------------------------------------------------- HTML documents represent a media-independent description of interactive content. HTML documents might be rendered to a screen, or through a speech synthesizer, or on a braille display. To influence exactly how such rendering takes place, authors can use a styling language such as CSS. In the following example, the page has been made yellow-on-blue using CSS.This page is just a demo.
For more details on how to use HTML, authors are encouraged to consult tutorials and guides. Some of the examples included in this specification might also be of use, but the novice author is cautioned that this specification, by necessity, defines the language with a level of detail that might be difficult to understand at first. 1.9.1. Writing secure applications with HTML This section is non-normative. When HTML is used to create interactive sites, care needs to be taken to avoid introducing vulnerabilities through which attackers can compromise the integrity of the site itself or of the site’s users. A comprehensive study of this matter is beyond the scope of this document, and authors are strongly encouraged to study the matter in more detail. However, this section attempts to provide a quick introduction to some common pitfalls in HTML application development. The security model of the Web is based on the concept of "origins", and correspondingly many of the potential attacks on the Web involve cross-origin actions. [ORIGIN] Not validating user input Cross-site scripting (XSS) SQL injection When accepting untrusted input, e.g., user-generated content such as text comments, values in URL parameters, messages from third-party sites, etc, it is imperative that the data be validated before use, and properly escaped when displayed. Failing to do this can allow a hostile user to perform a variety of attacks, ranging from the potentially benign, such as providing bogus user information like a negative age, to the serious, such as running scripts every time a user looks at a page that includes the information, potentially propagating the attack in the process, to the catastrophic, such as deleting all data in the server. When writing filters to validate user input, it is imperative that filters always be safelist-based, allowing known-safe constructs and disallowing all other input. Blocklist-based filters that disallow known-bad inputs and allow everything else are not secure, as not everything that is bad is yet known (for example, because it might be invented in the future). For example, suppose a page looked at its URL’s query string to determine what to display, and the site then redirected the user to that page to display a message, as in: If the message was just displayed to the user without escaping, a hostile attacker could then craft a URL that contained a script element: http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E If the attacker then convinced a victim user to visit this page, a script of the attacker’s choosing would run on the page. Such a script could do any number of hostile actions, limited only by what the site offers: if the site is an e-commerce shop, for instance, such a script could cause the user to unknowingly make arbitrarily many unwanted purchases. This is called a cross-site scripting attack. There are many constructs that can be used to try to trick a site into executing code. Here are some that authors are encouraged to consider when writing safelist filters: * When allowing harmless-seeming elements like img, it is important to safelist any provided attributes as well. If one allowed all attributes then an attacker could, for instance, use the onload attribute to run arbitrary script. * When allowing URLs to be provided (e.g., for links), the scheme of each URL also needs to be explicitly safelisted, as there are many schemes that can be abused. The most prominent example is "javascript:", but user agents can implement (and indeed, have historically implemented) others. * Allowing a base element to be inserted means any script elements in the page with relative links can be hijacked, and similarly that any form submissions can get redirected to a hostile site. Cross-site request forgery (CSRF) If a site allows a user to make form submissions with user-specific side-effects, for example posting messages on a forum under the user’s name, making purchases, or applying for a passport, it is important to verify that the request was made by the user intentionally, rather than by another site tricking the user into making the request unknowingly. This problem exists because HTML forms can be submitted to other origins. Sites can prevent such attacks by populating forms with user-specific hidden tokens, or by checking Origin headers on all requests. Clickjacking A page that provides users with an interface to perform actions that the user might not wish to perform needs to be designed so as to avoid the possibility that users can be tricked into activating the interface. One way that a user could be so tricked is if a hostile site places the victim site in a small iframe and then convinces the user to click, for instance by having the user play a reaction game. Once the user is playing the game, the hostile site can quickly position the iframe under the mouse cursor just as the user is about to click, thus tricking the user into clicking the victim site’s interface. To avoid this, sites that do not expect to be used in frames are encouraged to only enable their interface if they detect that they are not in a frame (e.g., by comparing the window object to the value of the top attribute). 1.9.2. Common pitfalls to avoid when using the scripting APIs This section is non-normative. Scripts in HTML have "run-to-completion" semantics, meaning that the browser will generally run the script uninterrupted before doing anything else, such as firing further events or continuing to parse the document. On the other hand, parsing of HTML files happens incrementally, meaning that the parser can pause at any point to let scripts run. This is generally a good thing, but it does mean that authors need to be careful to avoid hooking event handlers after the events could have possibly fired. There are two techniques for doing this reliably: use event handler content attributes, or create the element and add the event handlers in the same script. The latter is safe because, as mentioned earlier, scripts are run to completion before further events can fire. One way this could manifest itself is with img elements and the load event. The event could fire as soon as the element has been parsed, especially if the image has already been cached (which is common). Here, the author uses the onload handler on an img element to catch the load event: