html5 css3 toàn tập

For example, here is aform with a script that sets the value of the form's outputp366 element to say "Hello World": var a = document.links[0]; // obtain the first link in the documenta.h

HTML5 (including next generation additions still

in development)

Draft Standard — 7 April 2010

You can take part in this work Join the working group's discussion list

Web designers! We have a FAQ, a forum, and a help mailing list for you!

Twitter messages (non-editorial changes only): http://twitter.com/WHATWG

Commit-Watchers mailing list: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org

Interactive Web interface: http://html5.org/tools/web-apps-tracker

Subversion interface: http://svn.whatwg.org/

Issues:

To send feedback: whatwg@whatwg.org

To view and vote on feedback: http://www.whatwg.org/issues/

Editor:

Ian Hickson, Google, ian@hixie.ch

© Copyright 2004-2010 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA.

You are granted a license to use, reproduce and create derivative works of this document.

Abstract

This specification evolves HTML and its related APIs to ease the authoring of Web-based applications The most recentadditions include a devicep401 element to enable video conferencing, as well as all the features added as part of theearlier HTML5 effort

Status of this documentThis is a work in progress! This document is changing on a daily if not hourly basis in response to comments and as

a general part of its development process Comments are very welcome, please send them to whatwg@whatwg.org.Thank you

Outstanding feedback is tracked; all e-mails sent to the list above receive a reply The level of outstanding feedback ischarted to allow progress to be evaluated

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 call for implementations shouldjoin the WHATWG mailing list and take part in the discussions

This specification is intended to replace (be the new version of) what was previously the HTML5, HTML4, XHTML1, andDOM2 HTML specifications

Table of contents

1 Introduction 16

1.1 Is this HTML5? 16

1.2 Background 16

1.3 Audience 16

1.4 Scope 17

1.5 History 17

1.6 Design notes 18

1.6.1 Serializability of script execution 18

1.6.2 Compliance with other specifications 18

1.7 HTML vs XHTML 19

1.8 Structure of this specification 19

1.8.1 How to read this specification 20

1.8.2 Typographic conventions 20

1.9 A quick introduction to HTML 20

1.10 Conformance requirements for authors 22

1.10.1 Presentational markup 23

1.10.2 Syntax errors 23

1.10.3 Restrictions on content models and on attribute values 25

1.11 Recommended reading 27

2 Common infrastructure 28

2.1 Terminology 28

2.1.1 Resources 28

2.1.2 XML 28

2.1.3 DOM trees 29

2.1.4 Scripting 29

2.1.5 Plugins 29

2.1.6 Character encodings 30

2.2 Conformance requirements 30

2.2.1 Dependencies 33

2.2.2 Extensibility 34

2.3 Case-sensitivity and string comparison 35

2.4 Common microsyntaxes 36

2.4.1 Common parser idioms 36

2.4.2 Boolean attributes 37

2.4.3 Keywords and enumerated attributes 37

2.4.4 Numbers 37

2.4.4.1 Non-negative integers 37

2.4.4.2 Signed integers 38

2.4.4.3 Real numbers 38

2.4.4.4 Percentages and lengths 40

2.4.4.5 Lists of integers 41

2.4.4.6 Lists of dimensions 42

2.4.5 Dates and times 43

2.4.5.1 Months 43

2.4.5.2 Dates 44

2.4.5.3 Times 45

2.4.5.4 Local dates and times 46

2.4.5.5 Global dates and times 46

2.4.5.6 Weeks 48

2.4.5.7 Vaguer moments in time 49

2.4.6 Colors 50

2.4.7 Space-separated tokens 52

2.4.8 Comma-separated tokens 53

2.4.9 References 54

2.4.10 Media queries 54

2.5 URLs 54

2.5.1 Terminology 54

2.5.2 Dynamic changes to base URLs 56

2.5.3 Interfaces for URL manipulation 56

2.6 Fetching resources 58

2.6.1 Protocol concepts 60

2.6.2 Encrypted HTTP and related security concerns 60

2.6.3 Determining the type of a resource 61

2.7 Common DOM interfaces 61

2.7.1 Reflecting content attributes in IDL attributes 61

2.7.2 Collections 63

2.7.2.1 HTMLCollection 63

2.7.2.2 HTMLAllCollection 64

2.7.2.3 HTMLFormControlsCollection 65

2.7.2.4 HTMLOptionsCollection 66

2.7.2.5 HTMLPropertiesCollection 68

2.7.3 DOMTokenList 69

2.7.4 DOMSettableTokenList 71

2.7.5 Safe passing of structured data 71

2.7.6 DOMStringMap 72

2.7.7 DOM feature strings 73

2.7.8 Exceptions 74

2.7.9 Garbage collection 74

2.8 Namespaces 74

3 Semantics, structure, and APIs of HTML documents 75

3.1 Documents 75

3.1.1 Documents in the DOM 75

3.1.2 Security 77

3.1.3 Resource metadata management 77

3.1.4 DOM tree accessors 80

3.1.5 Creating documents 83

3.2 Elements 84

3.2.1 Semantics 84

3.2.2 Elements in the DOM 85

3.2.3 Global attributes 87

3.2.3.1 The id attribute 89

3.2.3.2 The title attribute 89

3.2.3.3 The lang and xml:lang attributes 89

3.2.3.4 The xml:base attribute (XML only) 90

3.2.3.5 The dir attribute 90

3.2.3.6 The class attribute 91

3.2.3.7 The style attribute 91

3.2.3.8 Embedding custom non-visible data 92

3.2.4 Element definitions 94

3.2.5 Content models 94

3.2.5.1 Kinds of content 95

3.2.5.1.1 Metadata content 95

3.2.5.1.2 Flow content 96

3.2.5.1.3 Sectioning content 96

3.2.5.1.4 Heading content 96

3.2.5.1.5 Phrasing content 96

3.2.5.1.6 Embedded content 97

3.2.5.1.7 Interactive content 97

3.2.5.2 Transparent content models 98

3.2.5.3 Paragraphs 98

3.2.6 Annotations for assistive technology products (ARIA) 100

3.3 APIs in HTML documents 103

3.4 Interactions with XPath and XSLT 104

3.5 Dynamic markup insertion 105

3.5.1 Opening the input stream 105

3.5.2 Closing the input stream 106

3.5.3 document.write() 107

3.5.4 document.writeln() 108

3.5.5 innerHTML 108

3.5.6 outerHTML 109

3.5.7 insertAdjacentHTML() 109

4 The elements of HTML 112

4.1 The root element 112

4.1.1 The html element 112

4.2 Document metadata 112

4.2.1 The head element 112

4.2.2 The title element 113

4.2.3 The base element 114

4.2.4 The link element 115

4.2.5 The meta element 119

4.2.5.1 Standard metadata names 120

4.2.5.2 Other metadata names 121

4.2.5.3 Pragma directives 122

4.2.5.4 Other pragma directives 125

4.2.5.5 Specifying the document's character encoding 125

4.2.6 The style element 126

4.2.7 Styling 128

4.3 Scripting 129

4.3.1 The script element 129

4.3.1.1 Scripting languages 134

4.3.1.2 Restrictions for contents of script elements 135

4.3.1.3 Inline documentation for external scripts 136

4.3.2 The noscript element 136

4.4 Sections 138

4.4.1 The body element 138

4.4.2 The section element 140

4.4.3 The nav element 142

4.4.4 The article element 144

4.4.5 The aside element 145

4.4.6 The h1, h2, h3, h4, h5, and h6 elements 147

4.4.7 The hgroup element 148

4.4.8 The header element 148

4.4.9 The footer element 150

4.4.10 The address element 151

4.4.11 Headings and sections 152

4.4.11.1 Creating an outline 153

4.5 Grouping content 157

4.5.1 The p element 157

4.5.2 The hr element 158

4.5.3 The pre element 158

4.5.4 The blockquote element 159

4.5.5 The ol element 161

4.5.6 The ul element 162

4.5.7 The li element 163

4.5.8 The dl element 164

4.5.9 The dt element 166

4.5.10 The dd element 166

4.5.11 The figure element 167

4.5.12 The figcaption element 168

4.5.13 The div element 168

4.6 Text-level semantics 169

4.6.1 The a element 169

4.6.2 The em element 171

4.6.3 The strong element 172

4.6.4 The small element 173

4.6.5 The cite element 174

4.6.6 The q element 175

4.6.7 The dfn element 176

4.6.8 The abbr element 177

4.6.9 The time element 178

4.6.10 The code element 181

4.6.11 The var element 182

4.6.12 The samp element 182

4.6.13 The kbd element 183

4.6.14 The sub and sup elements 184

4.6.15 The i element 184

4.6.16 The b element 185

4.6.17 The mark element 186

4.6.18 The ruby element 188

4.6.19 The rt element 189

4.6.20 The rp element 189

4.6.21 The bdo element 190

4.6.22 The span element 191

4.6.23 The br element 191

4.6.24 The wbr element 192

4.6.25 Usage summary 192

4.7 Edits 193

4.7.1 The ins element 193

4.7.2 The del element 194

4.7.3 Attributes common to ins and del elements 195

4.7.4 Edits and paragraphs 195

4.7.5 Edits and lists 196

4.8 Embedded content 196

4.8.1 The img element 196

4.8.1.1 Requirements for providing text to act as an alternative for images 202 4.8.1.1.1 A link or button containing nothing but the image 202

4.8.1.1.2 A phrase or paragraph with an alternative graphical representation: charts, diagrams, graphs, maps, illustrations 202

4.8.1.1.3 A short phrase or label with an alternative graphical representation: icons, logos 203

4.8.1.1.4 Text that has been rendered to a graphic for typographical effect 204

4.8.1.1.5 A graphical representation of some of the surrounding text 205

4.8.1.1.6 A purely decorative image that doesn't add any information 206

4.8.1.1.7 A group of images that form a single larger picture with no links 206

4.8.1.1.8 A group of images that form a single larger picture with links 206

4.8.1.1.9 A key part of the content 207

4.8.1.1.10 An image not intended for the user 209

4.8.1.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 209

4.8.1.1.12 General guidelines 210

4.8.1.1.13 Guidance for markup generators 210

4.8.1.1.14 Guidance for conformance checkers 210

4.8.2 The iframe element 211

4.8.3 The embed element 217

4.8.4 The object element 220

4.8.5 The param element 224

4.8.6 The video element 225

4.8.7 The audio element 228

4.8.8 The source element 229

4.8.9 Media elements 231

4.8.9.1 Error codes 232

4.8.9.2 Location of the media resource 232

4.8.9.3 MIME types 233

4.8.9.4 Network states 234

4.8.9.5 Loading the media resource 234

4.8.9.6 Offsets into the media resource 241

4.8.9.7 The ready states 242

4.8.9.8 Playing the media resource 244

4.8.9.9 Seeking 247

4.8.9.10 User interface 248

4.8.9.11 Time ranges 249

4.8.9.12 Event summary 249

4.8.9.13 Security and privacy considerations 251

4.8.10 The canvas element 251

4.8.10.1 The 2D context 254

4.8.10.1.1 The canvas state 256

4.8.10.1.2 Transformations 257

4.8.10.1.3 Compositing 257

4.8.10.1.4 Colors and styles 259

4.8.10.1.5 Line styles 261

4.8.10.1.6 Shadows 263

4.8.10.1.7 Simple shapes (rectangles) 264

4.8.10.1.8 Complex shapes (paths) 264

4.8.10.1.9 Focus management 267

4.8.10.1.10 Text 269

4.8.10.1.11 Images 272

4.8.10.1.12 Pixel manipulation 274

4.8.10.1.13 Drawing model 277

4.8.10.1.14 Examples 278

4.8.10.2 Color spaces and color correction 278

4.8.10.3 Security with canvas elements 279

4.8.11 The map element 279

4.8.12 The area element 280

4.8.13 Image maps 282

4.8.13.1 Authoring 282

4.8.13.2 Processing model 283

4.8.14 MathML 285

4.8.15 SVG 285

4.8.16 Dimension attributes 286

4.9 Tabular data 286

4.9.1 The table element 286

4.9.2 The caption element 292

4.9.3 The colgroup element 293

4.9.4 The col element 294

4.9.5 The tbody element 294

4.9.6 The thead element 295

4.9.7 The tfoot element 296

4.9.8 The tr element 296

4.9.9 The td element 298

4.9.10 The th element 298

4.9.11 Attributes common to td and th elements 300

4.9.12 Processing model 301

4.9.12.1 Forming a table 301

4.9.12.2 Forming relationships between data cells and header cells 305

4.9.13 Examples 306

4.10 Forms 309

4.10.1 Introduction 309

4.10.1.1 Writing a form's user interface 309

4.10.1.2 Implementing the server-side processing for a form 311

4.10.1.3 Configuring a form to communicate with a server 311

4.10.1.4 Client-side form validation 312

4.10.2 Categories 313

4.10.3 The form element 314

4.10.4 The fieldset element 317

4.10.5 The legend element 318

4.10.6 The label element 319

4.10.7 The input element 320

4.10.7.1 States of the type attribute 324

4.10.7.1.1 Hidden state 324

4.10.7.1.2 Text state and Search state 325

4.10.7.1.3 Telephone state 325

4.10.7.1.4 URL state 326

4.10.7.1.5 E-mail state 327

4.10.7.1.6 Password state 327

4.10.7.1.7 Date and Time state 328

4.10.7.1.8 Date state 329

4.10.7.1.9 Month state 330

4.10.7.1.10 Week state 330

4.10.7.1.11 Time state 331

4.10.7.1.12 Local Date and Time state 332

4.10.7.1.13 Number state 333

4.10.7.1.14 Range state 334

4.10.7.1.15 Color state 336

4.10.7.1.16 Checkbox state 336

4.10.7.1.17 Radio Button state 337

4.10.7.1.18 File Upload state 338

4.10.7.1.19 Submit Button state 339

4.10.7.1.20 Image Button state 339

4.10.7.1.21 Reset Button state 341

4.10.7.1.22 Button state 341

4.10.7.2 Common input element attributes 342

4.10.7.2.1 The autocomplete attribute 342

4.10.7.2.2 The list attribute 342

4.10.7.2.3 The readonly attribute 344

4.10.7.2.4 The size attribute 344

4.10.7.2.5 The required attribute 344

4.10.7.2.6 The multiple attribute 345

4.10.7.2.7 The maxlength attribute 346

4.10.7.2.8 The pattern attribute 346

4.10.7.2.9 The min and max attributes 346

4.10.7.2.10 The step attribute 347

4.10.7.2.11 The placeholder attribute 348

4.10.7.3 Common input element APIs 348

4.10.7.4 Common event behaviors 350

4.10.8 The button element 351

4.10.9 The select element 353

4.10.10 The datalist element 356

4.10.11 The optgroup element 357

4.10.12 The option element 358

4.10.13 The textarea element 360

4.10.14 The keygen element 363

4.10.15 The output element 366

4.10.16 The progress element 367

4.10.17 The meter element 369

4.10.18 Association of controls and forms 373

4.10.19 Attributes common to form controls 374

4.10.19.1 Naming form controls 374

4.10.19.2 Enabling and disabling form controls 374

4.10.19.3 A form control's value 374

4.10.19.4 Autofocusing a form control 374

4.10.19.5 Limiting user input length 375

4.10.19.6 Form submission 375

4.10.20 Constraints 376

4.10.20.1 Definitions 376

4.10.20.2 Constraint validation 377

4.10.20.3 The constraint validation API 378

4.10.20.4 Security 380

4.10.21 Form submission 380

4.10.21.1 Introduction 380

4.10.21.2 Implicit submission 381

4.10.21.3 Form submission algorithm 381

4.10.21.4 URL-encoded form data 385

4.10.21.5 Multipart form data 386

4.10.21.6 Plain text form data 386

4.10.22 Resetting a form 387

4.10.23 Event dispatch 387

4.11 Interactive elements 387

4.11.1 The details element 387

4.11.2 The summary element 390

4.11.3 The command element 391

4.11.4 The menu element 393

4.11.4.1 Introduction 393

4.11.4.2 Building menus and toolbars 394

4.11.4.3 Context menus 395

4.11.4.4 Toolbars 396

4.11.5 Commands 396

4.11.5.1 Using the a element to define a command 398

4.11.5.2 Using the button element to define a command 398

4.11.5.3 Using the input element to define a command 398

4.11.5.4 Using the option element to define a command 399

4.11.5.5 Using the command element to define a command 399

4.11.5.6 Using the accesskey attribute on a label element to define a command 400

4.11.5.7 Using the accesskey attribute on a legend element to define a command 400

4.11.5.8 Using the accesskey attribute to define a command on other elements 401

4.11.6 The device element 401

4.11.6.1 Stream API 402

4.11.6.2 Peer-to-peer connections 402

4.12 Links 404

4.12.1 Hyperlink elements 404

4.12.2 Following hyperlinks 405

4.12.2.1 Hyperlink auditing 405

4.12.3 Link types 406

4.12.3.1 Link type "alternate" 407

4.12.3.2 Link type "archives" 408

4.12.3.3 Link type "author" 408

4.12.3.4 Link type "bookmark" 409

4.12.3.5 Link type "external" 409

4.12.3.6 Link type "help" 409

4.12.3.7 Link type "icon" 409

4.12.3.8 Link type "license" 410

4.12.3.9 Link type "nofollow" 411

4.12.3.10 Link type "noreferrer" 411

4.12.3.11 Link type "pingback" 411

4.12.3.12 Link type "prefetch" 412

4.12.3.13 Link type "search" 412

4.12.3.14 Link type "stylesheet" 412

4.12.3.15 Link type "sidebar" 412

4.12.3.16 Link type "tag" 412

4.12.3.17 Hierarchical link types 412

4.12.3.17.1 Link type "index" 413

4.12.3.17.2 Link type "up" 413

4.12.3.18 Sequential link types 413

4.12.3.18.1 Link type "first" 414

4.12.3.18.2 Link type "last" 414

4.12.3.18.3 Link type "next" 414

4.12.3.18.4 Link type "prev" 414

4.12.3.19 Other link types 414

4.13 Common idioms without dedicated elements 415

4.13.1 Tag clouds 415

4.13.2 Conversations 416

4.13.3 Footnotes 417

4.14 Matching HTML elements using selectors 418

4.14.1 Case-sensitivity 418

4.14.2 Pseudo-classes 419

5 Microdata 422

5.1 Introduction 422

5.1.1 Overview 422

5.1.2 The basic syntax 422

5.1.3 Typed items 424

5.1.4 Global identifiers for items 424

5.1.5 Selecting names when defining vocabularies 425

5.1.6 Using the microdata DOM API 425

5.2 Encoding microdata 427

5.2.1 The microdata model 427

5.2.2 Items 427

5.2.3 Names: the itemprop attribute 428

5.2.4 Values 429

5.2.5 Associating names with items 429

5.3 Microdata DOM API 431

5.4 Microdata vocabularies 432

5.4.1 vCard 432

5.4.1.1 Conversion to vCard 441

5.4.1.2 Examples 445

5.4.2 vEvent 446

5.4.2.1 Conversion to iCalendar 450

5.4.2.2 Examples 452

5.4.3 Licensing works 453

5.4.3.1 Conversion to RDF 454

5.4.3.2 Examples 454

5.5 Converting HTML to other formats 454

5.5.1 JSON 454

5.5.2 RDF 455

5.5.2.1 Examples 458

5.5.3 Atom 459

6 Loading Web pages 463

6.1 Browsing contexts 463

6.1.1 Nested browsing contexts 463

6.1.1.1 Navigating nested browsing contexts in the DOM 464

6.1.2 Auxiliary browsing contexts 465

6.1.2.1 Navigating auxiliary browsing contexts in the DOM 465

6.1.3 Secondary browsing contexts 465

6.1.4 Security 465

6.1.5 Groupings of browsing contexts 465

6.1.6 Browsing context names 466

6.2 The Window object 467

6.2.1 Security 469

6.2.2 APIs for creating and navigating browsing contexts by name 470

6.2.3 Accessing other browsing contexts 471

6.2.4 Named access on the Window object 471

6.2.5 Garbage collection and browsing contexts 472

6.2.6 Browser interface elements 472

6.2.7 The WindowProxy object 473

6.3 Origin 474

6.3.1 Relaxing the same-origin restriction 476

6.4 Session history and navigation 478

6.4.1 The session history of browsing contexts 478

6.4.2 The History interface 478

6.4.3 The Location interface 482

6.4.3.1 Security 483

6.4.4 Implementation notes for session history 484

6.5 Browsing the Web 484

6.5.1 Navigating across documents 484

6.5.2 Page load processing model for HTML files 488

6.5.3 Page load processing model for XML files 488

6.5.4 Page load processing model for text files 489

6.5.5 Page load processing model for images 489

6.5.6 Page load processing model for content that uses plugins 489

6.5.7 Page load processing model for inline content that doesn't have a DOM 490

6.5.8 Navigating to a fragment identifier 490

6.5.9 History traversal 491

6.5.9.1 Event definitions 492

6.5.10 Unloading documents 494

6.5.10.1 Event definition 495

6.5.11 Aborting a document load 495

6.6 Offline Web applications 495

6.6.1 Introduction 495

6.6.1.1 Event summary 496

6.6.2 Application caches 497

6.6.3 The cache manifest syntax 498

6.6.3.1 A sample manifest 498

6.6.3.2 Writing cache manifests 499

6.6.3.3 Parsing cache manifests 501

6.6.4 Downloading or updating an application cache 503

6.6.5 The application cache selection algorithm 509

6.6.6 Changes to the networking model 510

6.6.7 Expiring application caches 510

6.6.8 Application cache API 510

6.6.9 Browser state 513

7 Web application APIs 514

7.1 Scripting 514

7.1.1 Introduction 514

7.1.2 Enabling and disabling scripting 514

7.1.3 Processing model 514

7.1.3.1 Definitions 514

7.1.3.2 Calling scripts 515

7.1.3.3 Creating scripts 515

7.1.3.4 Killing scripts 516

7.1.4 Event loops 516

7.1.4.1 Definitions 516

7.1.4.2 Processing model 517

7.1.4.3 Generic task sources 518

7.1.5 The javascript: protocol 518

7.1.6 Events 519

7.1.6.1 Event handlers 519

7.1.6.2 Event handlers on elements, Document objects, and Window objects.521 7.1.6.3 Event firing 523

7.1.6.4 Events and the Window object 523

7.1.6.5 Runtime script errors 524

7.2 Timers 524

7.3 User prompts 526

7.3.1 Simple dialogs 526

7.3.2 Printing 527

7.3.3 Dialogs implemented using separate documents 528

7.4 System state and capabilities 529

7.4.1 Client identification 530

7.4.2 Custom scheme and content handlers 531

7.4.2.1 Security and privacy 532

7.4.2.2 Sample user interface 533

7.4.3 Manually releasing the storage mutex 534

8 User interaction 536

8.1 The hidden attribute 536

8.2 Activation 536

8.3 Scrolling elements into view 537

8.4 Focus 537

8.4.1 Sequential focus navigation 537

8.4.2 Focus management 538

8.4.3 Document-level focus APIs 539

8.4.4 Element-level focus APIs 540

8.5 The accesskey attribute 541

8.6 The text selection APIs 542

8.6.1 APIs for the browsing context selection 543

8.6.2 APIs for the text field selections 545

8.7 The contenteditable attribute 546

8.7.1 User editing actions 547

8.7.2 Making entire documents editable 549

8.8 Spelling and grammar checking 549

8.9 Drag and drop 551

8.9.1 Introduction 551

8.9.2 The DragEvent and DataTransfer interfaces 553

8.9.3 Events fired during a drag-and-drop action 555

8.9.4 Drag-and-drop processing model 556

8.9.4.1 When the drag-and-drop operation starts or ends in another document 560

8.9.4.2 When the drag-and-drop operation starts or ends in another application 560

8.9.5 The draggable attribute 560

8.9.6 Security risks in the drag-and-drop model 561

8.10 Undo history 561

8.10.1 Definitions 561

8.10.2 The UndoManager interface 561

8.10.3 Undo: moving back in the undo transaction history 563

8.10.4 Redo: moving forward in the undo transaction history 563

8.10.5 The UndoManagerEvent interface and the undo and redo events 564

8.10.6 Implementation notes 564

8.11 Editing APIs 564

9 Communication 570

9.1 Event definitions 570

9.2 Cross-document messaging 571

9.2.1 Introduction 571

9.2.2 Security 571

9.2.2.1 Authors 571

9.2.2.2 User agents 571

9.2.3 Posting messages 572

9.2.4 Posting messages with message ports 572

9.3 Channel messaging 573

9.3.1 Introduction 573

9.3.2 Message channels 574

9.3.3 Message ports 574

9.3.3.1 Ports and garbage collection 576

10 The HTML syntax 577

10.1 Writing HTML documents 577

10.1.1 The DOCTYPE 577

10.1.2 Elements 578

10.1.2.1 Start tags 579

10.1.2.2 End tags 580

10.1.2.3 Attributes 580

10.1.2.4 Optional tags 581

10.1.2.5 Restrictions on content models 582

10.1.2.6 Restrictions on the contents of raw text and RCDATA elements 583

10.1.3 Text 583

10.1.3.1 Newlines 583

10.1.4 Character references 583

10.1.5 CDATA sections 584

10.1.6 Comments 584

10.2 Parsing HTML documents 584

10.2.1 Overview of the parsing model 585

10.2.2 The input stream 586

10.2.2.1 Determining the character encoding 587

10.2.2.2 Character encodings 591

10.2.2.3 Preprocessing the input stream 592

10.2.2.4 Changing the encoding while parsing 592

10.2.3 Parse state 593

10.2.3.1 The insertion mode 593

10.2.3.2 The stack of open elements 594

10.2.3.3 The list of active formatting elements 595

10.2.3.4 The element pointers 596

10.2.3.5 Other parsing state flags 597

10.2.4 Tokenization 597

10.2.4.1 Data state 597

10.2.4.2 Character reference in data state 598

10.2.4.3 RCDATA state 598

10.2.4.4 Character reference in RCDATA state 598

10.2.4.5 RAWTEXT state 598

10.2.4.6 Script data state 598

10.2.4.7 PLAINTEXT state 598

10.2.4.8 Tag open state 599

10.2.4.9 End tag open state 599

10.2.4.10 Tag name state 599

10.2.4.11 RCDATA less-than sign state 600

10.2.4.12 RCDATA end tag open state 600

10.2.4.13 RCDATA end tag name state 600

10.2.4.14 RAWTEXT less-than sign state 601

10.2.4.15 RAWTEXT end tag open state 601

10.2.4.16 RAWTEXT end tag name state 601

10.2.4.17 Script data less-than sign state 602

10.2.4.18 Script data end tag open state 602

10.2.4.19 Script data end tag name state 602

10.2.4.20 Script data escape start state 603

10.2.4.21 Script data escape start dash state 603

10.2.4.22 Script data escaped state 603

10.2.4.23 Script data escaped dash state 603

10.2.4.24 Script data escaped dash dash state 604

10.2.4.25 Script data escaped less-than sign state 604

10.2.4.26 Script data escaped end tag open state 604

10.2.4.27 Script data escaped end tag name state 605

10.2.4.28 Script data double escape start state 605

10.2.4.29 Script data double escaped state 605

10.2.4.30 Script data double escaped dash state 606

10.2.4.31 Script data double escaped dash dash state 606

10.2.4.32 Script data double escaped less-than sign state 606

10.2.4.33 Script data double escape end state 606

10.2.4.34 Before attribute name state 607

10.2.4.35 Attribute name state 607

10.2.4.36 After attribute name state 608

10.2.4.37 Before attribute value state 609

10.2.4.38 Attribute value (double-quoted) state 609

10.2.4.39 Attribute value (single-quoted) state 609

10.2.4.40 Attribute value (unquoted) state 610

10.2.4.41 Character reference in attribute value state 610

10.2.4.42 After attribute value (quoted) state 610

10.2.4.43 Self-closing start tag state 611

10.2.4.44 Bogus comment state 611

10.2.4.45 Markup declaration open state 611

10.2.4.46 Comment start state 611

10.2.4.47 Comment start dash state 612

10.2.4.48 Comment state 612

10.2.4.49 Comment end dash state 612

10.2.4.50 Comment end state 612

10.2.4.51 Comment end bang state 613

10.2.4.52 Comment end space state 613

10.2.4.53 DOCTYPE state 613

10.2.4.54 Before DOCTYPE name state 614

10.2.4.55 DOCTYPE name state 614

10.2.4.56 After DOCTYPE name state 614

10.2.4.57 After DOCTYPE public keyword state 615

10.2.4.58 Before DOCTYPE public identifier state 615

10.2.4.59 DOCTYPE public identifier (double-quoted) state 616

10.2.4.60 DOCTYPE public identifier (single-quoted) state 616

10.2.4.61 After DOCTYPE public identifier state 616

10.2.4.62 Between DOCTYPE public and system identifiers state 617

10.2.4.63 After DOCTYPE system keyword state 617

10.2.4.64 Before DOCTYPE system identifier state 618

10.2.4.65 DOCTYPE system identifier (double-quoted) state 618

10.2.4.66 DOCTYPE system identifier (single-quoted) state 618

10.2.4.67 After DOCTYPE system identifier state 619

10.2.4.68 Bogus DOCTYPE state 619

10.2.4.69 CDATA section state 619

10.2.4.70 Tokenizing character references 619

10.2.5 Tree construction 621

10.2.5.1 Creating and inserting elements 622

10.2.5.2 Closing elements that have implied end tags 625

10.2.5.3 Foster parenting 625

10.2.5.4 The "initial" insertion mode 625

10.2.5.5 The "before html" insertion mode 627

10.2.5.6 The "before head" insertion mode 628

10.2.5.7 The "in head" insertion mode 628

10.2.5.8 The "in head noscript" insertion mode 630

10.2.5.9 The "after head" insertion mode 630

10.2.5.10 The "in body" insertion mode 631

10.2.5.11 The "text" insertion mode 640

10.2.5.12 The "in table" insertion mode 641

10.2.5.13 The "in table text" insertion mode 643

10.2.5.14 The "in caption" insertion mode 643

10.2.5.15 The "in column group" insertion mode 644

10.2.5.16 The "in table body" insertion mode 644

10.2.5.17 The "in row" insertion mode 645

10.2.5.18 The "in cell" insertion mode 646

10.2.5.19 The "in select" insertion mode 647

10.2.5.20 The "in select in table" insertion mode 648

10.2.5.21 The "in foreign content" insertion mode 648

10.2.5.22 The "after body" insertion mode 651

10.2.5.23 The "in frameset" insertion mode 651

10.2.5.24 The "after frameset" insertion mode 652

10.2.5.25 The "after after body" insertion mode 652

10.2.5.26 The "after after frameset" insertion mode 653

10.2.6 The end 653

10.2.7 Coercing an HTML DOM into an infoset 654

10.2.8 An introduction to error handling and strange cases in the parser 655

10.2.8.1 Misnested tags: <b><i></b></i> 655

10.2.8.2 Misnested tags: <b><p></b></p> 655

10.2.8.3 Unexpected markup in tables 657

10.2.8.4 Scripts that modify the page as it is being parsed 658

10.3 Serializing HTML fragments 659

10.4 Parsing HTML fragments 661

10.5 Named character references 662

11 The XHTML syntax 669

11.1 Writing XHTML documents 669

11.2 Parsing XHTML documents 669

11.3 Serializing XHTML fragments 670

11.4 Parsing XHTML fragments 671

12 Rendering 672

12.1 Introduction 672

12.2 The CSS user agent style sheet and presentational hints 672

12.2.1 Introduction 672

12.2.2 Display types 673

12.2.3 Margins and padding 673

12.2.4 Alignment 675

12.2.5 Fonts and colors 677

12.2.6 Punctuation and decorations 679

12.2.7 Resetting rules for inherited properties 681

12.2.8 The hr element 682

12.2.9 The fieldset element 682

12.3 Replaced elements 683

12.3.1 Embedded content 683

12.3.2 Images 683

12.3.3 Attributes for embedded content and images 684

12.3.4 Image maps 685

12.3.5 Toolbars 685

12.4 Bindings 686

12.4.1 Introduction 686

12.4.2 The button element 686

12.4.3 The details element 686

12.4.4 The input element as a text entry widget 686

12.4.5 The input element as domain-specific widgets 687

12.4.6 The input element as a range control 687

12.4.7 The input element as a color well 688

12.4.8 The input element as a check box and radio button widgets 688

12.4.9 The input element as a file upload control 688

12.4.10 The input element as a button 688

12.4.11 The marquee element 688

12.4.12 The meter element 690

12.4.13 The progress element 690

12.4.14 The select element 690

12.4.15 The textarea element 691

12.4.16 The keygen element 692

12.4.17 The time element 692

12.5 Frames and framesets 692

12.6 Interactive media 694

12.6.1 Links, forms, and navigation 694

12.6.2 The title attribute 694

12.6.3 Editing hosts 694

12.7 Print media 695

13 Obsolete features 696

13.1 Obsolete but conforming features 696

13.1.1 Warnings for obsolete but conforming features 696

13.2 Non-conforming features 696

13.3 Requirements for implementations 701

13.3.1 The applet element 701

13.3.2 The marquee element 702

13.3.3 Frames 704

13.3.4 Other elements, attributes and APIs 706

14 IANA considerations 715

14.1 text/html 715

14.2 text/html-sandboxed 716

14.3 application/xhtml+xml 717

14.4 text/cache-manifest 718

14.5 text/ping 719

14.6 application/microdata+json 720

14.7 Ping-From 720

14.8 Ping-To 721

Index 722

Elements 722

Element content categories 727

Attributes 728

Interfaces 735

Events 736

References 738

Acknowledgements 744

The W3C has also been working on HTML in conjunction with the WHATWG; at the W3C, this document has been splitinto several parts, and the occasional informative paragraph or example has been removed for technical reasons Forall intents and purposes, however, the W3C HTML specifications and this specification are equivalent (and they are infact all generated from the same source document).

Features that are considered part of the next generation of HTML beyond HTML5 currently consist of only:

• The devicep401element

• The pingp404attribute and related hyperlink auditingp405features

Features that are part of HTML5 (and this specification) but that are either currently, or have been in the past,published as separate specifications:

• Canvas 2D Graphics Contextp254

• Microdatap422

• Microdata vocabulariesp432

• Cross-document messagingp571(also known as Communications)

• Channel messagingp573(also known as Communications)

• Formsp309(previously known as Web Forms 2)Features that are not currently in this document that were in the past considered part of HTML5, or that were neverpart of HTML5 but have been referred to as part of HTML5 in the media, include:

This section is non-normative.

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

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

1.3 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 tutorialsand authoring guides can provide a gentler introduction to the topic

In particular, familiarity with the basics of DOM Core and DOM Events is necessary for a complete understanding ofsome of the more technical parts of this specification An understanding of Web IDL, HTTP, XML, Unicode, characterencodings, JavaScript, and CSS will also be helpful in places but is not essential

1.4 Scope

This section is non-normative.

This specification is limited to providing a semantic-level markup language and associated semantic-level scriptingAPIs 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, andseveral 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 configurationsoftware, 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 thatwould be expected to be used by users on an occasional basis, or regularly but from disparate locations, with low CPUrequirements For instance online purchasing systems, searching systems, games (especially multiplayer online

games), public telephone books or address books, communications software (e-mail clients, instant messaging clients,discussion software), document editing software, etc

1.5 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 HTML4 followed, reaching completion in 1998

At this time, 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 HTML4 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 focusturned to making it easier for other working groups to extend XHTML, under the banner of XHTML Modularization Inparallel with this, the W3C also worked on a new language that was not compatible with the earlier HTML and XHTMLlanguages, calling it XHTML2

Around the time that HTML's evolution was stopped in 1998, parts of the API for HTML developed by browser vendorswere 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 specificationspublished 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 arenewed interest in evolving HTML itself, rather than finding replacements for it This interest was borne from therealization that XML's deployment as a Web technology was limited to entirely new technologies (like RSS and laterAtom), rather than as a replacement for existing deployed technologies (like HTML)

A proof of concept to show that it was possible to extend HTML4's forms to provide many of the features that XForms1.0 introduced, without requiring browsers to implement rendering engines that were incompatible with existing HTMLWeb 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'scopyright

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 HTML5 work (described below), as well as the aforementioned early draft proposal coveringjust forms-related features, were presented to the W3C jointly by Mozilla and Opera The proposal was rejected on thegrounds that the proposal conflicted with the previously chosen direction for the Web's evolution; the W3C staff andmembership 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 theumbrella of a new venue called the WHATWG A public mailing list was created, and the draft was moved to theWHATWG 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 theimplementations, and that specifications need to be detailed enough that implementations can achieve completeinteroperability without reverse-engineering each other

The latter requirement in particular required that the scope of the HTML5 specification include what had previouslybeen specified in three separate documents: HTML4, XHTML1, and DOM2 HTML It also meant including significantlymore detail than had previously been considered the norm

In 2006, the W3C indicated an interest to participate in the development of HTML5 after all, and in 2007 formed aworking group chartered to work with the WHATWG on the development of the HTML5 specification Apple, Mozilla,and Opera allowed the W3C to publish the specification under the W3C copyright, while keeping a version with the lessrestrictive license on the WHATWG site

Since then, both groups have been working together

A separate document has been published by the W3C HTML working group to document the differences between thisspecification and the language described in the HTML4 specification [HTMLDIFF]p739

1.6 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 ofseveral decades by a wide array of people with different priorities who, in many cases, did not know of each other'sexistence

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, andnow 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 fewsubsections

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 thebehavior of implementations can be thought of as completely serializing the execution of all scripts in all browsingcontextsp463

Note: The navigator.yieldForStorageUpdates() p535

method, in this model, is equivalent to allowing other scripts to run while the calling script is blocked.

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.6.1 Serializability of script execution

1.6.2 Compliance with other specifications

1.7 HTML vs XHTML

This section is non-normative.

This specification defines an abstract language for describing documents and applications, and some APIs for

interacting with in-memory representations of resources that use this language

The in-memory representation is known as "DOM HTML", or "the DOM" for short This specification defines version 5 ofDOM HTML, known as "DOM5 HTML"

There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two ofwhich 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 withmost legacy Web browsers If a document is transmitted with an HTML MIME typep28, such as text/htmlp715, then it will

be processed as an HTML document by Web browsers This specification defines the latest 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 typep29, such as application/xhtml+xmlp717, 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 beignored in the HTML syntax This specification defines the latest XHTML syntax, known simply as "XHTML"

The DOM, the HTML syntax, and XML cannot all represent the same content For example, namespaces cannot berepresented using the HTML syntax, but they are supported in the DOM and in XML Similarly, documents that use thenoscriptp136 feature can be represented using the HTML syntax, but cannot be represented with the DOM or in XML.Comments that contain the string " >" can be represented in the DOM but not in the HTML syntax or in XML

1.8 Structure of this specification

This section is non-normative.

This specification is divided into the following major sections:

Common infrastructure p28

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

Semantics, structure, and APIs of HTML documents p75

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

Microdata vocabularies for contact information, calendar events, and licensing works

Loading Web pages p463

HTML documents do not exist in a vacuum — this section defines many of the features that affect environmentsthat deal with multiple pages

Web application APIs p514

This section introduces basic features for scripting of applications in HTML

User interaction p536

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

The communication APIs p570

This section describes some mechanisms that applications written in HTML can use to communicate with otherapplications from different domains running on the same client

The HTML syntax The XHTML syntax p669

All of these features would be for naught if they couldn't be represented in a serialized form and sent to otherpeople, and so these sections define the syntaxes of HTML, along with rules for how to parse content using thosesyntaxes

There are also some appendices, defining rendering rulesp672for Web browsers and listing obsolete featuresp696andIANA considerationsp715

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 contentslist and following all the cross-references

This is a definition, requirement, or explanation

Note: This is a note.

This is an example

This is an open issue

⚠Warning! This is a warning.

interface Example {

// this is an IDL definition};

This box is non-normative Implementation requirements are given below this box.

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 thisp20or like this p20

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 thisp20.Other code fragments are marked up like this

Variables are marked up like this.

This is an implementation requirement

1.9 A quick introduction to HTML

This section is non-normative.

A basic HTML document looks like this:

HTML documents consist of a tree of elements and text Each element is denoted in the source by a start tagp579, such

as "<body>", and an end tagp580, such as "</body>" (Certain start tags and end tags can in certain cases be

omittedp581 and are implied by other tags.)

Tags have to be nested such that elements are all completely within each other, without overlapping:

<p>This is <em>very <strong>wrong</em>!</strong></p>

<p>This <em>is <strong>correct</strong>.</em></p>

This specification defines a set of elements that can be used in HTML, along with rules about the ways in which theelements can be nested

Elements can have attributes, which control how the elements work In the example below, there is a hyperlinkp404,formed using the ap169 element and its hrefp404 attribute:

<a href="demo.html">simple</a>

Attributesp580are placed inside the start tag, and consist of a namep580and a valuep580, separated by an "=" character.The attribute value can remain unquotedp580if it doesn't contain spaces or any of " ' ` = < or > Otherwise, it has to bequoted using either single or double quotes The value, along with the "=" character, can be omitted altogether if thevalue is the empty string

<! empty attributes >

<input name=address disabled>

<input name=address disabled="">

<! attributes with a value >

<input name=address maxlength=200>

<input name=address maxlength='200'>

<input name=address maxlength="200">

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 DOCTYPE node, elements, text nodes, and comment nodes.The markup snippet at the top of this sectionp20would be turned into the following DOM tree:

The root elementp29of this tree is the htmlp112element, which is the element always found at the root of HTML

documents It contains two elements, headp112and bodyp138, 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 anumber of spaces (represented here by "␣") and line breaks ("⏎") that all end up as text nodes in the DOM.

The headp112element contains a titlep113element, which itself contains a text node with the text "Sample page".Similarly, the bodyp138

element contains an h1p147

element, a pp157

element, and a comment

This DOM tree can be manipulated from scripts in the page Scripts (typically in JavaScript) are small programs thatcan be embedded using the scriptp129element or using event handler content attributesp520 For example, here is aform with a script that sets the value of the form's outputp366

element to say "Hello World":

var a = document.links[0]; // obtain the first link in the documenta.href = 'sample.html'; // change the destination URL of the linka.protocol = 'https'; // change just the scheme part of the URLa.setAttribute('href', 'http://example.com/'); // change the content attribute directlySince DOM trees are used as the way to represent HTML documents when they are processed and presented byimplementations (especially interactive implementations like Web browsers), this specification is mostly phrased interms of DOM trees, instead of the markup described above

HTML documents represent a media-independent description of interactive content HTML documents might berendered to a screen, or through a speech synthesizer, or on a braille display To influence exactly how such renderingtakes place, authors can use a styling language such as CSS

In the following example, the page has been made yellow-on-blue using CSS

<h1>Sample styled page</h1>

<p>This page is just a demo.</p>

</body>

</html>

For more details on how to use HTML, authors are encouraged to consult tutorials and guides Some of the examplesincluded in this specification might also be of use, but the novice author is cautioned that this specification, bynecessity, defines the language with a level of detail that might be difficult to understand at first

1.10 Conformance requirements for authors

This section is non-normative.

Unlike previous versions of the HTML specification, this specification defines in some detail the required processing forinvalid documents as well as valid documents

However, even though the processing of invalid content is in most cases well-defined, conformance requirements fordocuments are still important: in practice, interoperability (the situation in which all implementations processparticular content in a reliable and identical or equivalent way) is not the only goal of document conformance

requirements This section details some of the more common reasons for still distinguishing between a conformingdocument and one with errors.

This section is non-normative.

The majority of presentational features from previous versions of HTML are no longer allowed Presentational markup

in general has been found to have a number of problems:

The use of presentational elements leads to poorer accessibility

While it is possible to use presentational markup in a way that provides users of assistive technologies (ATs) with

an acceptable experience (e.g using ARIA), doing so is significantly more difficult than doing so when usingsemantically-appropriate markup Furthermore, even using such techniques doesn't help make pages accessiblefor non-AT non-graphical users, such as users of text-mode browsers

Using media-independent markup, on the other hand, provides an easy way for documents to be authored insuch a way that they work for more users (e.g text browsers)

Higher cost of maintenance

It is significantly easier to maintain a site written in such a way that the markup is style-independent For

example, changing the color of a site that uses <font color=""> throughout requires changes across the entiresite, whereas a similar change to a site based on CSS can be done by changing a single file

Higher document sizes

Presentational markup tends to be much more redundant, and thus results in larger document sizes

For those reasons, presentational markup has been removed from HTML in this version This change should not come

as a surprise; HTML4 deprecated presentational markup many years ago and provided a mode (HTML4 Transitional) tohelp authors move away from presentational markup; later, XHTML 1.1 went further and obsoleted those featuresaltogether

The only remaining presentational markup features in HTML are the stylep91

attribute and the stylep126

element Use

of the stylep91attribute is somewhat discouraged in production environments, but it can be useful for rapid

prototyping (where its rules can be directly moved into a separate style sheet later) and for providing specific styles inunusual cases where a separate style sheet would be inconvenient Similarly, the stylep126element can be useful insyndication or for page-specific styles, but in general an external style sheet is likely to be more convenient when thestyles apply to multiple pages

It is also worth noting that four elements that were previously presentational have been redefined in this specification

to be media-independent: bp185, ip184, hrp158, and smallp173

This section is non-normative.

The syntax of HTML is constrained to avoid a wide variety of problems

Unintuitive error-handling behavior

Certain invalid syntax constructs, when parsed, result in DOM trees that are highly unintuitive

For example, the following markup fragment results in a DOM with an hrp158element that is an earlier

sibling of the corresponding tablep286 element:

<table><hr>

Errors with optional error recovery

To allow user agents to be used in controlled environments without having to implement the more bizarre andconvoluted error handling rules, user agents are permitted to fail whenever encountering a parse errorp585

Errors where the error-handling behavior is not compatible with streaming user agents

Some error-handling behavior, such as the behavior for the <table><hr> example mentioned above, areincompatible with streaming user agents To avoid interoperability problems with such user agents, any syntaxresulting in such behavior is considered invalid

1.10.1 Presentational markup

1.10.2 Syntax errors

Errors that can result in infoset coercion

When a user agent based on XML is connected to an HTML parser, it is possible that certain invariants that XMLenforces, such as comments never containing two consecutive hyphens, will be violated by an HTML file.Handling this can require that the parser coerce the HTML DOM into an XML-compatible infoset Most syntaxconstructs that require such handling are considered invalid

Errors that result in disproportionally poor performance

Certain syntax constructs can result in disproportionally poor performance To discourage the use of suchconstructs, they are typically made non-conforming

For example, the following markup results in poor performance when hitting the highlighted end tag, sinceall the open elements are examined first to see if they match the close tag:

<p><em><span><span><span> <span><span><span></em>

Errors that help authors avoid fragile syntax constructs

There are syntax constructs that, for historical reasons, are relatively fragile To help reduce the number of userswho accidentally run into such problems, they are made non-conforming

For example, the parsing of certain named character references in attributes happens even with theclosing semicolon being omitted It is safe to include an ampersand followed by letters that do not form a

named character reference, but if the letters are changed to a string that does form a named character

reference, they will be interpreted as that character instead

In this fragment, the attribute's value is "?hello=1&world=2":

Thus, the correct way to express the above cases is as follows:

<a href="?hello=1&world=2">Demo</a> <! &world is ok, since it's not a namedcharacter reference >

<a href="?original=1&amp;copy=2">Compare</a> <! the & has to be escaped, since

&copy is a named character reference >

Errors that flag known interoperability problems in legacy user agents

Certain syntax constructs are known to cause especially subtle or serious problems in legacy user agents, andare therefore marked as non-conforming to help authors avoid them

For example, this is why the U+0060 GRAVE ACCENT character (`) is not allowed in unquoted attributes Incertain legacy user agents, it is sometimes treated as a quote character

Another example of this is the DOCTYPE, which is required to trigger no-quirks modep79, because thebehavior of legacy user agents in quirks modep79is often largely undocumented

Errors that protect authors from security attacks

Certain restrictions exist purely to avoid known security problems

For example, the restriction on using UTF-7 exists purely to avoid authors falling prey to a known site-scripting attack using UTF-7

cross-Cases where the author's intent is unclear

Some errors merely flag cases where the author's intent is most unclear Correcting these errors early makeslater maintenance easier

For example, it is unclear whether the author intended the following to be an h1p147heading or an h2p147

heading:

<h1>Contact details</h2>

Cases that are likely to be typos

When a user makes a simple typo, it is helpful if the error can be caught early, as this can save the author a lot

of debugging time This specification therefore usually considers it an error to use element names, attributenames, and so forth, that do not match the names defined in this specification

For example, if the author typed <capton> instead of <caption>, this would be flagged as an error and theauthor could correct the typo immediately

Errors that allow for new syntax in future

In order to allow us to extend the language syntax in the future, certain otherwise harmless features are

disallowed

For example, "attributes" in end tags are ignored currently, but they are invalid, in case a future change tothe language makes use of that syntax feature without conflicting with already-deployed (and valid!)content

Some authors find it helpful to be in the practice of always quoting all attributes and always including all optional tags,preferring the consistency derived from such custom over the minor benefits of terseness afforded by making use ofthe flexibility of the HTML syntax To aid such authors, conformance checkers can provide modes of operation whereinsuch conventions are enforced

This section is non-normative.

Beyond the syntax of the language, this specification also places restrictions on how elements and attributes can bespecified These restrictions are present for similar reasons:

Errors that flag content with dubious semantics

To avoid misuse of elements with defined meanings, content models are defined that restrict how elements can

be nested when such nestings would be of dubious value

For example, this specification disallows nesting a sectionp140

element inside a kbdp183

element, since it ishighly unlikely for an author to indicate that an entire section should be keyed in

Errors that indicate a conflict in expressed semantics

Similarly, to draw the author's attention to mistakes in the use of elements, clear contradictions in the semanticsexpressed are also considered conformance errors

In the fragments below, for example, the semantics are nonsensical: a row cannot simultaneously be acell, nor can a radio button be a progress bar

<tr role="cell">

<input type=radio role=progressbar>

Another example is the restrictions on the content models of the ulp162element, which only allows lip163

element children Lists by definition consist just of zero or more list items, so if a ulp162element containssomething other than an lip163 element, it's not clear what was meant

Errors that catch cases where the default styles are likely to lead to confusion

Certain elements have default styles or behaviors that make certain combinations likely to lead to confusion.Where these have equivalent alternatives without this problem, the confusing combinations are disallowed

For example, divp168 elements are rendered as block boxes, and spanp191elements as inline boxes Putting

a block box in an inline box is unnecessarily confusing; since either nesting just divp168 elements, or

nesting just spanp191elements, or nesting spanp191elements inside divp168elements all serve the samepurpose as nesting a divp168element in a spanp191 element, but only the latter involves a block box in aninline box, the latter combination is disallowed

Another example would be the way interactive contentp97cannot be nested For example, a buttonp351

element cannot contain a textareap360element This is because the default behavior of such nestinginteractive elements would be highly confusing to users Instead of nesting these elements, they can beplaced side by side

Errors that encourage a correct understanding of the spec

Sometimes, something is disallowed because allowing it would likely cause author confusion

1.10.3 Restrictions on content models and on attribute values

For example, setting the disabled attribute to the value "false" is disallowed, because despite the

appearance of meaning that the element is enabled, it in fact means that the element is disabled (what

matters for implementations is the presence of the attribute, not its value)

Errors that are intended merely to simplify the language

Some conformance errors simplify the language that authors need to learn

For example, the areap280element's shapep281 attribute, despite accepting both circp281 and circlep281

values in practice as synonyms, disallows the use of the circp281value, so as to simplify tutorials andother learning aids There would be no benefit to allowing both, but it would cause extra confusion whenteaching the language

Errors that avoid peculiarities of the parser

Certain elements are parsed in someone eccentric ways (typically for historical reasons), and their content modelrestrictions are intended to avoid exposing the author to these issues

For example, a formp314element isn't allowed inside phrasing contentp96, because when parsed as HTML, aformp314

element's start tag will imply a pp157

element's end tag Thus, the following markup results in twoparagraphsp98, not one:

<p>Welcome <form><label>Name:</label> <input></form>

It is parsed exactly like the following:

<p>Welcome </p><form><label>Name:</label> <input></form>

Errors that would likely result in scripts failing in hard-to-debug ways

Some errors are intended to help prevent script problems that would be hard to debug

This is why, for instance, it is non-conforming to have two idp89attributes with the same value DuplicateIDs lead to the wrong element being selected, with sometimes disastrous effects whose cause is hard todetermine

Errors that are intended to save the author time

Some constructs are disallowed because historically they have been the cause of a lot of wasted authoring time

For example, a scriptp129element's srcp130attribute causes the element's contents to be ignored

However, this isn't obvious, especially if the element's contents appear to be executable script — whichcan lead to authors spending a lot of time trying to debug the inline script without realising that it is notexecuting To reduce this problem, this specification makes it non-conforming to have executable script in

a scriptp129 element when the srcp130 attribute is present This means that authors who are validatingtheir documents are less likely to waste time with this kind of mistake

Errors that are intended to help authors migrating to and from XHTML

Some authors like to write files that can be interpreted as both XML and HTML with similar results Though thispractice is discouraged in general due to the myriad of subtle complications involved (especially when involvingscripting, styling, or any kind of automated serialization), this specification has a few restrictions intended to atleast somewhat mitigate the difficulties This makes it easier for authors to use this as a transitionary step whenmigrating between HTML and XHTML

For example, there are somewhat complicated rules surrounding the langp89and xml:langp89attributesintended to keep the two synchronized

Another example would be the restrictions on the values of xmlns attributes in the HTML serialization,which are intended to ensure that elements in conforming documents end up in the same namespaceswhether processed as HTML or XML

Errors that reserve space for future expansion

As with the restrictions on the syntax intended to allow for new syntax in future revisions of the language, somerestrictions on the content models of elements and values of attributes are intended to allow for future expansion

of the HTML vocabulary

For example, limiting the values of the targetp404attribute that start with an U+005F LOW LINE character(_) to only specific predefined values allows new predefined values to be introduced at a future timewithout conflicting with author-defined values

Errors that indicate a mis-use of other specifications

Certain restrictions are intended to support the restrictions made by other specifications

For example, requiring that attributes that take media queries use only valid media queries reinforces the

importance of following the conformance rules of that specification

1.11 Recommended reading

This section is non-normative.

The following documents might be of interest to readers of this specification

Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD]p738

This Architectural Specification provides authors of specifications, software developers, and content

developers with a common reference for interoperable text manipulation on the World Wide Web, building on the Universal Character Set, defined jointly by the Unicode Standard and ISO/IEC 10646 Topics addressed include use of the terms 'character', 'encoding' and 'string', a reference processing model, choice and

identification of character encodings, character escaping, and string indexing.

Unicode Security Considerations [UTR36]p742

Because Unicode contains such a large number of characters and incorporates the varied writing systems of the world, incorrect usage can expose programs or systems to possible security attacks This is especially important as more and more products are internationalized This document describes some of the security considerations that programmers, system analysts, standards developers, and users should take into

account, and provides specific recommendations to reduce the risk of problems.

Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG]p742

Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these Following these guidelines will also often make your Web content more usable to users in general.

Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG]p738

This specification provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as by enabling, supporting, and promoting the production of accessible Web content by all authors.

User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG]p742

This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities User agents include browsers and other types of software that retrieve and render Web content A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies) Furthermore, all users, not just users with disabilities, should find

conforming user agents to be more usable.

2 Common infrastructure

2.1 Terminology

This specification refers to both HTML and XML attributes and IDL attributes, often in the same context When it is not

clear which is being referred to, they are referred to as content attributes for HTML and XML attributes, and IDL attributes for those defined on IDL interfaces Similarly, the term "properties" is used for both JavaScript object properties and CSS properties When these are ambiguous they are qualified as object properties and CSS properties respectively.

Generally, when the specification states that a feature applies to the HTML syntaxp577or the XHTML syntaxp669, it alsoincludes the other When a feature specifically only applies to one of the two languages, it is called out by explicitlystating that it does not apply to the other format, as in "for HTML, (this does not apply to XHTML)"

This specification uses the term document to refer to any use of HTML, ranging from short static documents to long

essays or reports with rich multimedia, as well as to fully-fledged interactive applications

For simplicity, terms such as shown, displayed, and visible might sometimes be used when referring to the way a

document is rendered to the user These terms are not meant to imply a visual medium; they must be considered toapply to other media in equivalent ways

When an algorithm B says to return to another algorithm A, it implies that A called B Upon returning to A, theimplementation must continue from where it left off in calling B

The specification uses the term supported when referring to whether a user agent has an implementation capable of

decoding the semantics of an external resource A format or type is said to be supported if the implementation can

process an external resource of that format or type without critical aspects of the resource being ignored Whether a

specific resource is supported can depend on what features of the resource's format are in use.

For example, a PNG image would be considered to be in a supported format if its pixel data could be decodedand rendered, even if, unbeknownst to the implementation, the image also contained animation data

A MPEG4 video file would not be considered to be in a supported format if the compression format used was notsupported, even if the implementation could determine the dimensions of the movie from the file's metadata

The term MIME type is used to refer to what is sometimes called an Internet media type in protocol literature The

term media type in this specification is used to refer to the type of media intended for presentation, as used by the

CSS specifications [RFC2046]p741[MQ]p740

A string is a valid MIME type if it matches the media-type rule defined in section 3.7 "Media Types" of RFC 2616 In

particular, a valid MIME typep28may include MIME type parameters [HTTP]p739

A string is a valid MIME type with no parameters if it matches the media-type rule defined in section 3.7 "Media

Types" of RFC 2616, but does not contain any U+003B SEMICOLON characters (;) In other words, if it consists only of atype and subtype, with no MIME Type parameters [HTTP]p739

The term HTML MIME type is used to refer to the MIME typesp28text/htmlp715and text/html-sandboxedp716

A resource's critical subresources are those that the resource needs to have available to be correctly processed.

Which resources are considered critical or not is defined by the specification that defines the resource's format ForCSS resources, only @import rules introduce critical subresourcesp28; other resources, e.g fonts or backgrounds, arenot

To ease migration from HTML to XHTML, UAs conforming to this specification will place elements in HTML in the

http://www.w3.org/1999/xhtml namespace, at least for the purposes of the DOM and CSS The term "HTML elements", when used in this specification, refers to any element in that namespace, and thus refers to both HTML

Attribute names are said to be XML-compatible if they match the Name production defined in XML, they contain no

U+003A COLON characters (:), and their first three characters are not an ASCII case-insensitivep35

match for the string

"xml" [XML]p743

The term XML MIME type is used to refer to the MIME typesp28text/xml, application/xml, and any MIME typep28whose subtype ends with the four characters "+xml" [RFC3023]p741

The term root element, when not explicitly qualified as referring to the document's root element, means the furthest

ancestor element node of whatever node is being discussed, or the node itself if it has no ancestors When the node is

a part of the document, then the node's root elementp29is indeed the document's root element; however, if the node

is not currently part of the document tree, the root element will be an orphaned node

When an element's root elementp29is the root element of a Documentp33, it is said to be in a Document An element is said to have been inserted into a document when its root elementp29changes and is now the document's rootelementp29 Analogously, an element is said to have been removed from a document when its root elementp29changes from being the document's root elementp29to being another element

A node's home subtree is the subtree rooted at that node's root elementp29 When a node is in a Documentp29, itshome subtreep29is that Documentp33's tree

The Documentp33of a Nodep33(such as an element) is the Documentp33that the Nodep33's ownerDocument IDL attributereturns When a Nodep33is in a Documentp29then that Documentp33is always the Nodep33's Documentp33, and the

Nodep33's ownerDocument IDL attribute thus always returns that Documentp33

The term tree order means a pre-order, depth-first traversal of DOM nodes involved (through the

parentNodep33/childNodesp33relationship)

When it is stated that some element or attribute is ignored, or treated as some other value, or handled as if it was

something else, this refers only to the processing of the node after it is in the DOM A user agent must not mutate theDOM in such situations

The term text node refers to any Textp33node, including CDATASectionp33nodes; specifically, any Nodep33with nodetype TEXT_NODE (3) or CDATA_SECTION_NODE (4) [DOMCORE]p739

A content attribute is said to change value only if its new value is different than its previous value; setting an attribute

to a value it already has does not change it

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

"an object implementing the interface Foo"

An IDL attribute is said to be getting when its value is being retrieved (e.g by author script), and is said to be setting

when a new value is assigned to it

If a DOM object is said to be live, then the attributes and methods on that object must operate on the actual

underlying data, not a snapshot of the data

The terms fire and dispatch are used interchangeably in the context of events, as in the DOM Events specifications The term trusted event is used as defined by the DOM Events specification [DOMEVENTS]p739

The term plugin is used to mean any content handler that supports displaying content as part of the user agent's

rendering of a Documentp33object, but that neither acts as a child browsing contextp463of the Documentp33nor

introduces any Nodep33objects to the Documentp33's DOM

Typically such content handlers are provided by third parties, though a user agent can designate content handlers to

be plugins

One example of a plugin would be a PDF viewer that is instantiated in a browsing contextp463 when the usernavigates to a PDF file This would count as a plugin regardless of whether the party that implemented the PDFviewer component was the same as that which implemented the user agent itself However, a PDF viewer

2.1.3 DOM trees

2.1.4 Scripting

2.1.5 Plugins

application that launches separate from the user agent (as opposed to using the same interface) is not a plugin

by this definition

Note: This specification does not define a mechanism for interacting with plugins, as it is expected to be user-agent- and platform-specific Some UAs might opt to support a plugin mechanism such as the Netscape Plugin API; others might use remote content converters or have built-in support for certain types [NPAPI] p740

⚠Warning! Browsers should take extreme care when interacting with external content intended for

plugins p29 When third-party software is run with the same privileges as the user agent itself, vulnerabilities in the third-party software become as dangerous as those in the user agent.

The preferred MIME name of a character encoding is the name or alias labeled as "preferred MIME name" in the

IANA Character Sets registry, if there is one, or the encoding's name, if none of the aliases are so labeled.

[IANACHARSET]p739

An ASCII-compatible character encoding is a single-byte or variable-length encoding in which the bytes 0x09,

0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A, and 0x61 - 0x7A, ignoring bytes that are thesecond and later bytes of multibyte sequences, all correspond to single-byte sequences that map to the same Unicodecharacters as those bytes in ANSI_X3.4-1968 (US-ASCII) [RFC1345]p740

Note: This includes such encodings as Shift_JIS, HZ-GB-2312, and variants of ISO-2022, even though it is possible in these encodings for bytes like 0x70 to be part of longer sequences that are unrelated to their interpretation as ASCII It excludes such encodings as UTF-7, UTF-16, GSM03.38, and EBCDIC variants.

The term Unicode character is used to mean a Unicode scalar value (i.e any Unicode code point that is not a

surrogate code point) [UNICODE]p742

2.2 Conformance requirements

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

non-The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and

"OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119 For readability,these words do not appear in all uppercase letters in this specification [RFC2119]p741

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

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

Conforming documents are those that comply with all the conformance criteria for documents For readability, some

of these conformance requirements are phrased as conformance requirements on authors; such requirements areimplicitly requirements on documents: by definition, all documents are assumed to have had an author (In somecases, that author may itself be a user agent — such user agents are subject to additional rules, as explained below.)

For example, if a requirement states that "authors must not use the foobar element", it would imply thatdocuments are not allowed to contain elements named foobar

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

Web browsers and other interactive user agents

Web browsers that support the XHTML syntaxp669must process elements and attributes from the HTMLnamespacep74

found in XML documents as described in this specification, so that users can interact with them,unless the semantics of those elements have been overridden by other specifications

A conforming XHTML processor would, upon finding an XHTML scriptp129

element in an XML document,execute the script contained in that element However, if the element is found within a transformation

2.1.6 Character encodings

expressed in XSLT (assuming the user agent also supports XSLT), then the processor would instead treatthe scriptp129

element as an opaque element that forms part of the transform

Web browsers that support the HTML syntaxp577 must process documents labeled with an HTML MIME typep28asdescribed in this specification, so that users can interact with them

User agents that support scripting must also be conforming implementations of the IDL fragments in this

specification, as described in the Web IDL specification [WEBIDL]p742

Note: Unless explicitly stated, specifications that override the semantics of HTML elements

do not override the requirements on DOM objects representing those elements For example, the script p129 element in the example above would still implement the HTMLScriptElement p130

interface.

Non-interactive presentation user agents

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

Note: Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs) It is expected that most static non-interactive

presentation user agents will also opt to lack scripting support p31

A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be

dynamically submitted, and so forth However, since the concept of "focus" is irrelevant when the usercannot interact with the document, the UA would not need to support any of the focus-related DOM APIs

User agents with no scripting support

Implementations that do not support scripting (or which have their scripting features disabled entirely) are

exempt from supporting the events and DOM interfaces mentioned in this specification For the parts of thisspecification that are defined in terms of an events model or in terms of the DOM, such user agents must still act

as if events and the DOM were supported

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

Conformance checkers

Conformance checkers must verify that a document conforms to the applicable conformance criteria described inthis specification Automated conformance checkers are exempt from detecting errors that require interpretation

of the author's intent (for example, while a document is non-conforming if the content of a blockquotep159

element is not a quote, conformance checkers running without the input of human judgement do not have tocheck that blockquotep159elements only contain quoted material)

Conformance checkers must check that the input document conforms when parsed without a browsing

contextp463(meaning that no scripts are run, and that the parser's scripting flagp597is disabled), and should alsocheck that the input document conforms when parsed with a browsing contextp463in which scripts execute, andthat the scripts never cause non-conforming states to occur other than transiently during script execution itself.(This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible

[COMPUTABLE]p738)

The term "HTML validator" can be used to refer to a conformance checker that itself conforms to the applicablerequirements of this specification

XML DTDs cannot express all the conformance requirements of this specification Therefore,

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

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

1 Criteria that can be expressed in a DTD.

2 Criteria that cannot be expressed by a DTD, but can still be checked by a machine.

3 Criteria that can only be checked by a human.

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

Data mining tools

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

A tool that generates document outlinesp153but increases the nesting level for each paragraph and doesnot increase the nesting level for each section would not be conforming

Authoring tools and markup generators

Authoring tools and markup generators must generate conforming documentsp30 Conformance criteria thatapply to authors also apply to authoring tools, where appropriate

Authoring tools are exempt from the strict requirements of using elements only for their specified purpose, butonly to the extent that authoring tools are not yet able to determine author intent However, authoring toolsmust not automatically misuse elements or encourage their users to do so

For example, it is not conforming to use an addressp151element for arbitrary contact information; thatelement can only be used for marking up contact information for the author of the document or section.However, since an authoring tool is likely unable to determine the difference, an authoring tool is exemptfrom that requirement This does not mean, though, that authoring tools can use addressp151 elements forany block of italics text (for instance); it just means that the authoring tool doesn't have to verify thatwhen the user uses a tool for inserting contact information for a section, that the user really is doing thatand not inserting something else instead

Note: In terms of conformance checking, an editor has to output documents that conform to the same extent that a conformance checker will verify.

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

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

The former is the preferred mechanism for tools that author HTML, since the structure in the source informationcan be used to make informed choices regarding which HTML elements and attributes are most appropriate.However, WYSIWYG tools are legitimate WYSIWYG tools should use elements they know are appropriate, andshould not use elements that they do not know to be appropriate This might in certain extreme cases meanlimiting the use of flow elements to just a few elements, like divp168, bp185, ip184, and spanp191and making liberaluse of the stylep91attribute

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

well-Some conformance requirements are phrased as requirements on elements, attributes, methods or objects Suchrequirements fall into two categories: those describing content model restrictions, and those describing

implementation behavior Those in the former category are requirements on documents and authoring tools Those inthe second category are requirements on user agents Similarly, some conformance requirements are phrased asrequirements on authors; such requirements are to be interpreted as conformance requirements on the documentsthat authors produce (In other words, this specification does not distinguish between conformance criteria on authorsand conformance criteria on documents.)

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

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

Note: There is no implied relationship between document conformance requirements and implementation conformance requirements User agents are not free to handle non-conformant

documents as they please; the processing model described in this specification applies to

implementations regardless of the conformity of the input documents.

For compatibility with existing content and prior specifications, this specification describes two authoring formats: onebased on XML (referred to as the XHTML syntaxp669), and one using a custom formatp577inspired by SGML (referred to

as the HTML syntaxp577) Implementations may support only one of these two formats, although supporting both isencouraged

The language in this specification assumes that the user agent expands all entity references, and therefore does notinclude entity reference nodes in the DOM If user agents do include entity reference nodes in the DOM, then useragents must handle them as if they were fully expanded when implementing this specification For example, if a

requirement talks about an element's child text nodes, then any text nodes that are children of an entity referencethat is a child of that element would be used as well Entity references to unknown entities must be treated as if theycontained just an empty text node for the purposes of the algorithms defined in this specification

This specification relies on several other underlying specifications

XML

Implementations that support the XHTML syntaxp669must support some version of XML, as well as its

corresponding namespaces specification, because that syntax uses an XML serialization with namespaces

[XML]p743[XMLNS]p743

DOM

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

Implementations must support some version of DOM Core and DOM Events, because this specification is defined

in terms of the DOM, and some of the features are defined as extensions to the DOM Core interfaces

The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as

described in the Web IDL specification [WEBIDL]p742

2.2.1 Dependencies

Except where otherwise specified, if an IDL attribute that is a floating point number type (float) is assigned anInfinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERRp74

exception must be raised

Except where otherwise specified, if a method with an argument that is a floating point number type (float) ispassed an Infinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERRp74

exception must be raised

Media Queries

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

URIs, IRIs, IDNA

Implementations must support the semantics of URLsp54defined in the URI and IRI specifications, as well as the

semantics of IDNA domain names defined in the Internationalizing Domain Names in Applications (IDNA)

specification [RFC3986]p741[RFC3987]p741[RFC3490]p741

This specification does not require support of any particular network protocol, style sheet language, scripting

language, or any of the DOM specifications beyond those described above However, the language described by thisspecification is biased towards CSS as the styling language, JavaScript as the scripting language, and HTTP as thenetwork protocol, and several features assume that those languages and protocols are in use

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

HTML has a wide number of extensibility mechanisms that can be used for adding semantics in a safe manner:

• Authors can use the classp91attribute to extend elements, effectively creating their own elements, whileusing the most applicable existing "real" HTML element, so that browsers and other tools that don't know ofthe 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 thedata-*=""p92attributes These are guaranteed to never be touched by browsers, and allow scripts to includedata on HTML elements that scripts can then look for and process

• Authors can use the <meta name="" content="">p119mechanism to include page-wide metadata byregistering extensions to the predefined set of metadata namesp121

• Authors can create pluginsp29and invoke them using the embedp217element This is how Flash works

• Authors can extend APIs using the JavaScript prototyping mechanism This is widely used by script libraries,for instance

• Authors can use the microdata feature (the item="" and itemprop=""p428attributes) to embed nestedname-value pairs of data to be shared with other applications and sites

Vendor-specific proprietary user agent extensions to this specification are strongly discouraged Documents must notuse such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specificuser agents to access the content in question

2.2.2 Extensibility

If such extensions are nonetheless needed, e.g for experimental purposes, then vendors are strongly urged to use one

of the following extension mechanisms:

For markup-level features that can be limited to the XML serialization and need not be supported in the HTML

serialization, vendors should use the namespace mechanism to define custom namespaces in which the non-standardelements and attributes are supported

For markup-level features that are intended for use with the HTML syntaxp577, extensions should be limited to new

attributes of the form "_vendor-feature", where vendor is a short string that identifies the vendor responsible for the extension, and feature is the name of the feature New element names should not be created Using attributes for

such extensions exclusively allows extensions from multiple vendors to co-exist on the same element, which would not

be possible with elements Using the "_vendor-feature" form allows extensions to be made without risk of conflicting

with future additions to the specification

For instance, a browser named "FerretBrowser" could use "ferret" as a vendor prefix, while a browser named

"Mellblom Browser" could use "mb" If both of these browsers invented extensions that turned elements intoscratch-and-sniff areas, an author experimenting with these features could write:

<p>This smells of lemons!

<span _ferret-smellovision _fetter-smellcode="LEM01"

_mb-outputsmell _mb-smell="lemon juice"></span></p>

Attribute names starting with a U+005F LOW LINE character (_) are reserved for user agent use and are guaranteed tonever be formally added to the HTML language

Note: Pages that use such attributes are by definition non-conforming.

For DOM extensions, e.g new methods and IDL attributes, the new members should be prefixed by vendor-specificstrings to prevent clashes with future versions of this specification

All extensions must be defined so that the use of extensions neither contradicts nor causes the non-conformance offunctionality defined in the specification

For example, while strongly discouraged from doing so, an implementation "Foo Browser" could add a new IDLattribute "fooTypeTime" to a control's DOM interface that returned the time it took the user to select the currentvalue of a control (say) On the other hand, defining a new control that appears in a form's elementsp316arraywould be in violation of the above requirement, as it would violate the definition of elementsp316given in thisspecification

When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly,

or an extension specification can be written that overrides the requirements in this specification When someoneapplying this specification to their activities decides that they will recognize the requirements of such an extension

specification, it becomes an applicable specification for the purposes of conformance requirements in this

specification

User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them inthe DOM (for DOM processors), and styling them according to CSS (for CSS processors), but not inferring any meaningfrom them

When support for a feature is disabled (e.g as an emergency measure to mitigate a security problem, or to aid indevelopment, or for performance reasons), user agents must act as if they had no support for the feature whatsoever,and as if the feature was not mentioned in this specification For example, if a particular feature is accessed via anattribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface —leaving the attribute on the object but making it return null or throw an exception is insufficient

2.3 Case-sensitivity and string comparison

Comparing two strings in a case-sensitive manner means comparing them exactly, code point for code point.

Comparing two strings in an ASCII case-insensitive manner means comparing them exactly, code point for code

point, except that the characters in the range U+0041 to U+005A (i.e LATIN CAPITAL LETTER A to LATIN CAPITALLETTER Z) and the corresponding characters in the range U+0061 to U+007A (i.e LATIN SMALL LETTER A to LATINSMALL LETTER Z) are considered to also match

Comparing two strings in a compatibility caseless manner means using the Unicode compatibility caseless match

operation to compare the two strings [UNICODE]p742

Converting a string to ASCII uppercase means replacing all characters in the range U+0061 to U+007A (i.e LATIN

SMALL LETTER A to LATIN SMALL LETTER Z) with the corresponding characters in the range U+0041 to U+005A (i.e.LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z)

Converting a string to ASCII lowercase means replacing all characters in the range U+0041 to U+005A (i.e LATIN

CAPITAL LETTER A to LATIN CAPITAL LETTER Z) with the corresponding characters in the range U+0061 to U+007A (i.e.LATIN SMALL LETTER A to LATIN SMALL LETTER Z)

A string pattern is a prefix match for a string s when pattern is not longer than s and truncating s to pattern's length

leaves the two strings as matches of each other

specification, since error-handling behavior is often not defined in specifications that describe date syntaxes similar to those used in this specification, and thus implementations tend to vary greatly in how they handle errors.

The space characters, for the purposes of this specification, are U+0020 SPACE, U+0009 CHARACTER TABULATION

(tab), U+000A LINE FEED (LF), U+000C FORM FEED (FF), and U+000D CARRIAGE RETURN (CR)

The White_Space characters are those that have the Unicode property "White_Space" in the Unicode PropList.txt

data file [UNICODE]p742

Note: This should not be confused with the "White_Space" value (abbreviated "WS") of the

"Bidi_Class" property in the Unicode.txt data file.

The alphanumeric ASCII characters are those in the ranges U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9),

U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, U+0061 LATIN SMALL LETTER A to U+007ALATIN SMALL LETTER Z

Some of the micro-parsers described below follow the pattern of having an input variable that holds the string being parsed, and having a position variable pointing at the next character to parse in input.

For parsers based on this pattern, a step that requires the user agent to collect a sequence of characters means

that the following algorithm must be run, with characters being the set of characters that can be collected:

1 Let input and position be the same variables as those of the same name in the algorithm that invoked these

steps

2 Let result be the empty string.

3 While position doesn't point past the end of input and the character at position is one of the characters, append that character to the end of result and advance position to the next character in input.

4 Return result.

The step skip whitespace means that the user agent must collect a sequence of charactersp36that are spacecharactersp36 The step skip White_Space characters means that the user agent must collect a sequence of

charactersp36that are White_Spacep36characters In both cases, the collected characters are not used [UNICODE]p742

When a user agent is to strip line breaks from a string, the user agent must remove any U+000A LINE FEED (LF) and

U+000D CARRIAGE RETURN (CR) characters from that string

When a user agent is to strip leading and trailing whitespace from a string, the user agent must remove all space

charactersp36

that are at the start or end of the string

2.4.1 Common parser idioms

The code-point length of a string is the number of Unicode code points in that string.

A number of attributes are boolean attributes The presence of a boolean attribute on an element represents the

true value, and the absence of the attribute represents the false value

If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitivep35

match for the attribute's canonical name, with no leading or trailing whitespace

Note: The values "true" and "false" are not allowed on boolean attributes To represent a false

value, the attribute has to be omitted altogether.

Some attributes are defined as taking one of a finite set of keywords Such attributes are called enumerated

attributes The keywords are each defined to map to a particular state (several keywords might map to the same

state, in which case some of the keywords are synonyms of each other; additionally, some of the keywords can be said

to be non-conforming, and are only in the specification for historical reasons) In addition, two default states can be

given The first is the invalid value default, the second is the missing value default.

If an enumerated attribute is specified, the attribute's value must be an ASCII case-insensitivep35match for one of thegiven keywords that are not said to be non-conforming, with no leading or trailing whitespace

When the attribute is specified, if its value is an ASCII case-insensitivep35match for one of the given keywords thenthat keyword's state is the state that the attribute represents If the attribute value matches none of the given

keywords, but the attribute has an invalid value default, then the attribute represents that state Otherwise, if the attribute value matches none of the keywords but there is a missing value default state defined, then that is the state

represented by the attribute Otherwise, there is no default, and invalid values must be ignored

When the attribute is not specified, if there is a missing value default state defined, then that is the state represented

by the (missing) attribute Otherwise, the absence of the attribute means that there is no state represented

Note: The empty string can be a valid keyword.

2.4.4.1 Non-negative integers

A string is a valid non-negative integer if it consists of one or more characters in the range U+0030 DIGIT ZERO (0)

to U+0039 DIGIT NINE (9)

A valid non-negative integerp37represents the number that is represented in base ten by that string of digits

The rules for parsing non-negative integers are as given in the following algorithm When invoked, the steps must

be followed in the order given, aborting at the first step that returns a value This algorithm will return either zero, apositive integer, or an error Leading spaces are ignored Trailing spaces and any trailing garbage characters are

ignored

1 Let input be the string being parsed.

2 Let position be a pointer into input, initially pointing at the start of the string.

3 Skip whitespacep36

4 If position is past the end of input, return an error.

5 If the character indicated by position is a U+002B PLUS SIGN character (+), advance position to the next

character (The "+" is ignored, but it is not conforming.)

6 If position is past the end of input, return an error.

7 If the character indicated by position is not one of U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then

return an error

2.4.2 Boolean attributes

2.4.3 Keywords and enumerated attributes

2.4.4 Numbers

8 Collect a sequence of characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), and

interpret the resulting sequence as a base-ten integer Let value be that integer.

9 Return value.

2.4.4.2 Signed integers

A string is a valid integer if it consists of one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039

DIGIT NINE (9), optionally prefixed with a U+002D HYPHEN-MINUS character (-)

A valid integerp38without a U+002D HYPHEN-MINUS (-) prefix represents the number that is represented in base ten

by that string of digits A valid integerp38with a U+002D HYPHEN-MINUS (-) prefix represents the number represented

in base ten by the string of digits that follows the U+002D HYPHEN-MINUS, subtracted from zero

The rules for parsing integers are similar to the rules for non-negative integersp37, and are as given in the followingalgorithm When invoked, the steps must be followed in the order given, aborting at the first step that returns a value.This algorithm will return either an integer or an error Leading spaces are ignored Trailing spaces and trailing garbagecharacters are ignored

1 Let input be the string being parsed.

2 Let position be a pointer into input, initially pointing at the start of the string.

3 Let sign have the value "positive".

4 Skip whitespacep36

5 If position is past the end of input, return an error.

6 If the character indicated by position (the first character) is a U+002D HYPHEN-MINUS character (-):

1 Let sign be "negative".

2 Advance position to the next character.

3 If position is past the end of input, return an error.

Otherwise, if the character indicated by position (the first character) is a U+002B PLUS SIGN character (+):

1 Advance position to the next character (The "+" is ignored, but it is not conforming.)

2 If position is past the end of input, return an error.

7 If the character indicated by position is not one of U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then

return an error

8 Collect a sequence of charactersp36in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), and

interpret the resulting sequence as a base-ten integer Let value be that integer.

9 If sign is "positive", return value, otherwise return the result of subtracting value from zero.

2.4.4.3 Real numbers

A string is a valid floating point number if it consists of:

1 Optionally, a U+002D HYPHEN-MINUS character (-)

2 A series of one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)

3 Optionally:

1 A single U+002E FULL STOP character (.)

2 A series of one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)

4 Optionally:

1 Either a U+0065 LATIN SMALL LETTER E character (e) or a U+0045 LATIN CAPITAL LETTER Echaracter (E)

2 Optionally, a U+002D HYPHEN-MINUS character (-) or U+002B PLUS SIGN character (+)

3 A series of one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)

A valid floating point numberp38represents the number obtained by multiplying the significand by ten raised to thepower of the exponent, where the significand is the first number, interpreted as base ten (including the decimal pointand the number after the decimal point, if any, and interpreting the significand as a negative number if the wholestring starts with a U+002D HYPHEN-MINUS character (-) and the number is not zero), and where the exponent is thenumber after the E, if any (interpreted as a negative number if there is a U+002D HYPHEN-MINUS character (-)

between the E and the number and the number is not zero, or else ignoring a U+002B PLUS SIGN character (+)

between the E and the number if there is one) If there is no E, then the exponent is treated as zero

Note: The Infinity and Not-a-Number (NaN) values are not valid floating point numbers p38

The best representation of the number n as a floating point number is the string obtained from applying the

JavaScript operator ToString to n The JavaScript operator ToString is not uniquely determined When there are multiple

possible strings that could be obtained from the JavaScript operator ToString for a particular value, the user agentmust always return the same string for that value (though it may differ from the value used by other user agents)

The rules for parsing floating point number values are as given in the following algorithm This algorithm must

be aborted at the first step that returns something This algorithm will return either a number or an error Leadingspaces are ignored Trailing spaces and garbage characters are ignored

1 Let input be the string being parsed.

2 Let position be a pointer into input, initially pointing at the start of the string.

3 Let value have the value 1.

4 Let divisor have the value 1.

5 Let exponent have the value 1.

6 Skip whitespacep36

7 If position is past the end of input, return an error.

8 If the character indicated by position is a U+002D HYPHEN-MINUS character (-):

1 Change value and divisor to −1.

2 Advance position to the next character.

3 If position is past the end of input, return an error.

9 If the character indicated by position is not one of U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then

return an error

10 Collect a sequence of charactersp36in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), and

interpret the resulting sequence as a base-ten integer Multiply value by that integer.

11 If position is past the end of input, jump to the step labeled conversion.

12 If the character indicated by position is a U+002E FULL STOP (.), run these substeps:

1 Advance position to the next character.

2 If position is past the end of input, or if the character indicated by position is not one of U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then jump to the step labeled conversion.

3 Fraction loop: Multiply divisor by ten.

4 Add the value of the character indicated by position, interpreted as a base-ten digit (0 9) and divided by divisor, to value.

5 Advance position to the next character.

6 If position is past the end of input, then jump to the step labeled conversion.

7 If the character indicated by position is one of U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), jump back to the step labeled fraction loop in these substeps.

13 If the character indicated by position is a U+0065 LATIN SMALL LETTER E character (e) or a U+0045 LATIN

CAPITAL LETTER E character (E), run these substeps:

1 Advance position to the next character.

2 If position is past the end of input, then jump to the step labeled conversion.

3 If the character indicated by position is a U+002D HYPHEN-MINUS character (-):

1 Change exponent to −1.

2 Advance position to the next character.

3 If position is past the end of input, then jump to the step labeled conversion.

Otherwise, if the character indicated by position is a U+002B PLUS SIGN character (+):

1 Advance position to the next character.

2 If position is past the end of input, then jump to the step labeled conversion.

4 If the character indicated by position is not one of U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then jump to the step labeled conversion.

5 Collect a sequence of charactersp36in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE

(9), and interpret the resulting sequence as a base-ten integer Multiply exponent by that integer.

6 Multiply value by ten raised to the exponentth power.

14 Conversion: Let S be the set of finite IEEE 754 single-precision floating point values except −0, but with two

special values added: 2128and −2128

15 Let rounded-value be the number in S that is closest to value, selecting the number with an even significand

if there are two equally close values (The two special values 2128and −2128are considered to have evensignificands for this purpose.)

16 If rounded-value is 2128or −2128, return an error

1 Let input be the string being parsed.

2 Let position be a pointer into input, initially pointing at the start of the string.

3 Skip whitespacep36

4 If position is past the end of input, return an error.

5 If the character indicated by position is a U+002B PLUS SIGN character (+), advance position to the next

character

6 Collect a sequence of charactersp36that are U+0030 DIGIT ZERO (0) characters, and discard them

7 If position is past the end of input, return an error.

8 If the character indicated by position is not one of U+0031 DIGIT ONE (1) to U+0039 DIGIT NINE (9), then

return an error

9 Collect a sequence of charactersp36in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), and

interpret the resulting sequence as a base-ten integer Let value be that number.

10 If position is past the end of input, return value as a length.

11 If the character indicated by position is a U+002E FULL STOP character (.):

1 Advance position to the next character.

2 If position is past the end of input, or if the character indicated by position is not one of U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then return value as a length.

3 Let divisor have the value 1.

4 Fraction loop: Multiply divisor by ten.