This repository was archived by the owner on May 5, 2023. It is now read-only.
forked from html5lib/html5lib-python
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathhtml.html
More file actions
5000 lines (3461 loc) · 229 KB
/
Copy pathhtml.html
File metadata and controls
5000 lines (3461 loc) · 229 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!-- EDITOR NOTES -*- mode: Text; fill-column: 100 -*-
!
! Adding a new element involves editing the following sections:
! - section for the element itself
! - descriptions of the element's categories
! - images/content-venn.svg
! - syntax, if it's void or otherwise special
! - parser, if it's not phrasing-level
! - rendering
! - obsolete section
! - element, attribute, content model, and interface indexes
! - adding it to the section with ARIA mappings
!
!-->
<!--
! http://lists.w3.org/Archives/Public/www-archive/2014Apr/0034.html
!-->
<!--START complete--><!--START dev-html-->
<!DOCTYPE html>
<!--SET FINGERPRINT=<span title="fingerprinting vector" class="fingerprint"><img src="images/fingerprint.png" alt="(This is a fingerprinting vector.)" width=46 height=64></span>-->
<html lang="en-GB-x-hixie" class="big">
<head>
<title>HTML Standard</title>
<script>
var loadTimer = new Date();
var current_revision = "r" + "$Revision: 1 $".substr(11);
current_revision = current_revision.substr(0, current_revision.length - 2);
var last_known_revision = current_revision;
function F( /* varargs... */) {
var fragment = document.createDocumentFragment();
for (var index = 0; index < arguments.length; index += 1) {
if (arguments[index] instanceof Array) {
fragment.appendChild(F.apply(this, arguments[index]));
} else if (typeof arguments[index] == 'string') {
fragment.appendChild(document.createTextNode(arguments[index]));
} else {
fragment.appendChild(arguments[index]);
}
}
return fragment;
}
function E(name, /* optional */ attributes /*, varargs... */) {
var element = document.createElement(name);
var index = 1;
if ((arguments.length > 1) && (typeof attributes != 'string') &&
(!(attributes instanceof Node)) && (!(attributes instanceof Array))) {
for (var attName in attributes) {
if (typeof attributes[attName] == 'boolean') {
if (attributes[attName])
element.setAttribute(attName, '');
} else if (typeof attributes[attName] == 'function') {
element[attName] = attributes[attName];
} else {
element.setAttribute(attName, attributes[attName]);
}
}
index = 2;
}
for (; index < arguments.length; index += 1) {
if (arguments[index] instanceof Array) {
element.appendChild(F.apply(this, arguments[index]));
} else if (typeof arguments[index] == 'string') {
element.appendChild(document.createTextNode(arguments[index]));
} else {
element.appendChild(arguments[index]);
}
}
return element;
}
function getCookie(name) {
var params = location.search.substr(1).split("&");
for (var index = 0; index < params.length; index++) {
if (params[index] == name)
return "1";
var data = params[index].split("=");
if (data[0] == name)
return unescape(data[1]);
}
var cookies = document.cookie.split("; ");
for (var index = 0; index < cookies.length; index++) {
var data = cookies[index].split("=");
if (data[0] == name)
return unescape(data[1]);
}
return null;
}
var currentAlert;
var currentAlertTimeout;
function showAlert(s, href) {
if (!currentAlert) {
currentAlert = document.createElement('div');
currentAlert.id = 'alert';
var x = document.createElement('button');
x.textContent = '\u2573';
x.onclick = closeAlert2;
currentAlert.appendChild(x);
currentAlert.appendChild(document.createElement('span'));
currentAlert.onmousemove = function () {
clearTimeout(currentAlertTimeout);
currentAlert.className = '';
currentAlertTimeout = setTimeout(closeAlert, 10000);
}
document.body.appendChild(currentAlert);
} else {
clearTimeout(currentAlertTimeout);
currentAlert.className = '';
}
currentAlert.lastChild.textContent = '';
currentAlert.lastChild.appendChild(F(s));
if (href) {
var link = document.createElement('a');
link.href = href;
link.textContent = href;
currentAlert.lastChild.appendChild(F(' ', link));
}
currentAlertTimeout = setTimeout(closeAlert, 10000);
}
function closeAlert() {
clearTimeout(currentAlertTimeout);
if (currentAlert) {
currentAlert.className = 'closed';
currentAlertTimeout = setTimeout(closeAlert2, 3000);
}
}
function closeAlert2() {
clearTimeout(currentAlertTimeout);
if (currentAlert) {
currentAlert.parentNode.removeChild(currentAlert);
currentAlert = null;
}
}
window.addEventListener('keydown', function (event) {
if (event.keyCode == 27) {
if (currentAlert)
closeAlert2();
} else {
closeAlert();
}
}, false);
window.addEventListener('scroll', function (event) {
closeAlert();
}, false);
function load(script) {
var e = document.createElement('script');
e.setAttribute('src', '//www.whatwg.org/specs/web-apps/current-work/' + script);
document.body.appendChild(e);
}
var startedInit = 0;
function init() {
startedInit = 1;
if (location.search == '?slow-browser')
return;
load('reviewer.js');
if (document.documentElement.className == "big" || document.documentElement.className == "big split index")
load('toc.js');
load('updater.js');
load('dfn.js');
load('status.js');
if (getCookie('profile') == '1')
document.getElementsByTagName('h2')[0].textContent += '; load: ' + (new Date() - loadTimer) + 'ms';
}
if (document.documentElement.className == "")
setTimeout(function () {
if (!startedInit)
showAlert("Too slow? Try reading the multipage copy of the spec instead:", "http://whatwg.org/html");
}, 6000);
window.addEventListener('keypress', function (event) {
if ((event.which == 114) && (event.metaKey)) {
if (!confirm('Are you sure you want to reload this page?'))
event.preventDefault();
}
}, false);
</script>
<link rel="stylesheet" href="//www.whatwg.org/style/specification">
<link rel="icon" href="//www.whatwg.org/images/icon">
<style>
.proposal { border: blue solid; padding: 1em; }
.bad, .bad *:not(.XXX) { color: gray; border-color: gray; background: transparent; }
#updatesStatus { display: none; z-index: 10; }
#updatesStatus.relevant { display: block; position: fixed; right: 1em; top: 1em; padding: 0.5em; font: bold small sans-serif; min-width: 25em; width: 30%; max-width: 40em; height: auto; border: ridge 4px gray; background: #EEEEEE; color: black; }
div.head .logo { width: 11em; margin-bottom: 20em; }
#configUI { position: absolute; z-index: 20; top: auto; right: 0; width: 11em; padding: 0 0.5em 0 0.5em; font-size: small; background: gray; background: rgba(32,32,32,0.9); color: white; border-radius: 1em 0 0 1em; -moz-border-radius: 1em 0 0 1em; }
#configUI p { margin: 0.75em 0; padding: 0.3em; }
#configUI p label { display: block; }
#configUI #updateUI, #configUI .loginUI { text-align: center; }
#configUI input[type=button] { display: block; margin: auto; }
#configUI :link, #configUI :visited { color: white; }
#configUI :link:hover, #configUI :visited:hover { background: transparent; }
#alert { position: fixed; top: 20%; left: 20%; right: 20%; font-size: 2em; padding: 0.5em; z-index: 40; background: gray; background: rgba(32,32,32,0.9); color: white; border-radius: 1em; -moz-border-radius: 1em; -webkit-transition: opacity 1s linear; }
#alert.closed { opacity: 0; }
#alert button { position: absolute; top: -1em; right: 2em; border-radius: 1em 1em 0 0; border: none; line-height: 0.9; color: white; background: rgb(64,64,64); font-size: 0.6em; font-weight: 900; cursor: pointer; }
#alert :link, #alert :visited { color: white; }
#alert :link:hover, #alert :visited:hover { background: transparent; }
@media print { #configUI { display: none; } }
.rfc2119 { font-variant: small-caps; text-shadow: 0 0 0.5em yellow; position: static; }
.rfc2119::after { position: absolute; left: 0; width: 25px; text-align: center; color: yellow; text-shadow: 0.075em 0.075em 0.2em black; }
.rfc2119.m\ust::after { content: '\2605'; }
.rfc2119.s\hould::after { content: '\2606'; }
[hidden] { display: none; }
.fingerprint { float: right; }
.applies thead th > * { display: block; }
.applies thead code { display: block; }
.applies td { text-align: center; }
.applies .yes { background: yellow; }
.matrix, .matrix td { border: hidden; text-align: right; }
.matrix { margin-left: 2em; }
.vertical-summary-table tr > th[rowspan="2"]:first-child + th,
.vertical-summary-table tr > td[rowspan="2"]:first-child + td { border-bottom: hidden; }
.dice-example { border-collapse: collapse; border-style: hidden solid solid hidden; border-width: thin; margin-left: 3em; }
.dice-example caption { width: 30em; font-size: smaller; font-style: italic; padding: 0.75em 0; text-align: left; }
.dice-example td, .dice-example th { border: solid thin; width: 1.35em; height: 1.05em; text-align: center; padding: 0; }
td.eg { border-width: thin; text-align: center; }
#table-example-1 { border: solid thin; border-collapse: collapse; margin-left: 3em; }
#table-example-1 * { font-family: "Essays1743", serif; line-height: 1.01em; }
#table-example-1 caption { padding-bottom: 0.5em; }
#table-example-1 thead, #table-example-1 tbody { border: none; }
#table-example-1 th, #table-example-1 td { border: solid thin; }
#table-example-1 th { font-weight: normal; }
#table-example-1 td { border-style: none solid; vertical-align: top; }
#table-example-1 th { padding: 0.5em; vertical-align: middle; text-align: center; }
#table-example-1 tbody tr:first-child td { padding-top: 0.5em; }
#table-example-1 tbody tr:last-child td { padding-bottom: 1.5em; }
#table-example-1 tbody td:first-child { padding-left: 2.5em; padding-right: 0; width: 9em; }
#table-example-1 tbody td:first-child::after { content: leader(". "); }
#table-example-1 tbody td { padding-left: 2em; padding-right: 2em; }
#table-example-1 tbody td:first-child + td { width: 10em; }
#table-example-1 tbody td:first-child + td ~ td { width: 2.5em; }
#table-example-1 tbody td:first-child + td + td + td ~ td { width: 1.25em; }
.apple-table-examples { border: none; border-collapse: separate; border-spacing: 1.5em 0em; width: 40em; margin-left: 3em; }
.apple-table-examples * { font-family: "Times", serif; }
.apple-table-examples td, .apple-table-examples th { border: none; white-space: nowrap; padding-top: 0; padding-bottom: 0; }
.apple-table-examples tbody th:first-child { border-left: none; width: 100%; }
.apple-table-examples thead th:first-child ~ th { font-size: smaller; font-weight: bolder; border-bottom: solid 2px; text-align: center; }
.apple-table-examples tbody th::after, .apple-table-examples tfoot th::after { content: leader(". ") }
.apple-table-examples tbody th, .apple-table-examples tfoot th { font: inherit; text-align: left; }
.apple-table-examples td { text-align: right; vertical-align: top; }
.apple-table-examples.e1 tbody tr:last-child td { border-bottom: solid 1px; }
.apple-table-examples.e1 tbody + tbody tr:last-child td { border-bottom: double 3px; }
.apple-table-examples.e2 th[scope=row] { padding-left: 1em; }
.apple-table-examples sup { line-height: 0; }
.three-column-nowrap tr > td:first-child,
.three-column-nowrap tr > td:first-child + td,
.three-column-nowrap tr > td:first-child + td + td { white-space: nowrap; }
.details-example img { vertical-align: top; }
#base64-table {
white-space: nowrap;
font-size: 0.6em;
column-width: 6em;
column-count: 5;
column-gap: 1em;
-moz-column-width: 6em;
-moz-column-count: 5;
-moz-column-gap: 1em;
-webkit-column-width: 6em;
-webkit-column-count: 5;
-webkit-column-gap: 1em;
}
#base64-table thead { display: none; }
#base64-table * { border: none; }
#base64-table tbody td:first-child:after { content: ':'; }
#base64-table tbody td:last-child { text-align: right; }
#named-character-references-table {
white-space: nowrap;
font-size: 0.6em;
column-width: 30em;
column-gap: 1em;
-moz-column-width: 30em;
-moz-column-gap: 1em;
-webkit-column-width: 30em;
-webkit-column-gap: 1em;
}
#named-character-references-table > table > tbody > tr > td:first-child + td,
#named-character-references-table > table > tbody > tr > td:last-child { text-align: center; }
#named-character-references-table > table > tbody > tr > td:last-child:hover > span { position: absolute; top: auto; left: auto; margin-left: 0.5em; line-height: 1.2; font-size: 5em; border: outset; padding: 0.25em 0.5em; background: white; width: 1.25em; height: auto; text-align: center; }
#named-character-references-table > table > tbody > tr#entity-CounterClockwiseContourIntegral > td:first-child { font-size: 0.5em; }
.glyph.control { color: red; }
@font-face {
font-family: 'Essays1743';
src: url('//www.whatwg.org/specs/web-apps/current-work/fonts/Essays1743.ttf');
}
@font-face {
font-family: 'Essays1743';
font-weight: bold;
src: url('//www.whatwg.org/specs/web-apps/current-work/fonts/Essays1743-Bold.ttf');
}
@font-face {
font-family: 'Essays1743';
font-style: italic;
src: url('//www.whatwg.org/specs/web-apps/current-work/fonts/Essays1743-Italic.ttf');
}
@font-face {
font-family: 'Essays1743';
font-style: italic;
font-weight: bold;
src: url('//www.whatwg.org/specs/web-apps/current-work/fonts/Essays1743-BoldItalic.ttf');
}
</style>
<link rel="stylesheet" href="status.css">
</head>
<body onload="init()">
<header class="head with-buttons" id="head">
<p><a href="//www.whatwg.org/" class="logo"><img width="101" height="101" alt="WHATWG" src="/images/logo"></a></p>
<hgroup>
<h1 class="allcaps">HTML</h1>
<h2 class="no-num no-toc">Living Standard — Last Updated <span class="pubdate">[DATE: 01 Jan 1901]</span></h2>
</hgroup>
<div>
<div>
<a href="//whatwg.org/html"><span><strong>Multipage Version</strong> <code>whatwg.org/html</code></span></a>
<a href="//whatwg.org/c"><span><strong>One-Page Version</strong> <code>whatwg.org/c</code></span></a>
<a href="//whatwg.org/pdf"><span><strong>PDF Version</strong> <code>whatwg.org/pdf</code></span></a>
<a href="http://developers.whatwg.org/"><span><strong>Developer Version</strong> <code>developers.whatwg.org</code></span></a>
</div>
<div>
<a class="misc" href="//whatwg.org/faq"><span><strong>FAQ</strong> <code>whatwg.org/faq</code></span></a>
<a class="misc" href="http://validator.whatwg.org/"><span><strong>Validators</strong> <code>validator.whatwg.org</code></span></a>
</div>
<div>
<a class="comms" href="//www.whatwg.org/mailing-list"><span><strong>Join our Mailing List</strong> <code>whatwg@whatwg.org</code></span></a>
<a class="comms" href="http://wiki.whatwg.org/wiki/IRC"><span><strong>Join us on IRC</strong> <code>#whatwg on Freenode</code></span></a>
<a class="comms" href="http://forums.whatwg.org/"><span><strong>Join our Forums</strong> <code>forums.whatwg.org</code></span></a>
</div>
<div>
<!--<a class="changes" href="http://svn.whatwg.org/webapps"><span><strong>SVN Repository</strong> <code>svn.whatwg.org/webapps</code></span></a>-->
<a class="changes" href="http://html5.org/tools/web-apps-tracker"><span><strong>Change Log</strong> <code>html5.org's tracker</code></span></a>
<a class="changes" href="http://twitter.com/WHATWG"><span><strong>Twitter Updates</strong> <code>@WHATWG</code></span></a>
</div>
<div>
<a class="feedback" href="https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML&product=WHATWG"><span><strong>View Open Bugs</strong> <code>filed in Bugzilla</code></span></a>
<a class="feedback" href="//www.whatwg.org/newbug"><span><strong>File a Bug</strong> <code>whatwg.org/newbug</code></span></a>
<a class="feedback" href="http://ian.hixie.ch/+"><span><strong>E-mail the Editor</strong> <code>ian@hixie.ch</code></span></a>
</div>
</div>
</header>
<hr>
<div id="configUI"></div>
<h2 class="no-num no-toc" id="contents">Table of contents</h2>
<!--toc-->
<hr>
<!--
<pre class="idl">
interface Screen { }; // CSSOM
interface URL { }; // URL API
interface Blob { }; // File API
interface File : Blob { }; // File API
interface FileList { }; // File API
interface WebGLRenderingContext { }; // WebGL
interface XMLDocument { }; // DOM
interface HTMLCollection { }; // DOM
interface DOMTokenList { }; // DOM
interface DOMSettableTokenList { attribute any value; }; // DOM
interface SVGMatrix { }; // SVG
// fake interfaces that map to JS object types:
interface ArrayBuffer { };
interface Int8Array { };
interface Uint8Array { };
interface Uint8ClampedArray { };
interface Int16Array { };
interface Uint16Array { };
interface Int32Array { };
interface Uint32Array { };
interface Float32Array { };
interface Float64Array { };
interface Uint8ClampedArray { };
</pre>
-->
<h2 id="introduction">Introduction</h2>
<div class="nodev">
<h3 id="abstract">Where does this specification fit?</h3>
<p>This specification defines a big part of the Web platform, in lots of detail. Its place in the
Web platform specification stack relative to other specifications can be best summed up as
follows:</p>
<p><img src="images/abstract.png" width="398" height="359" alt="It consists of everything else, above such core technologies as HTTP, URI/IRIs, DOM, XML, Unicode, and ECMAScript; below presentation-layer technologies like CSS and the NPAPI; and to the side of technologies like Geolocation, SVG, MathML, and XHR."></p>
</div>
<h3 id="is-this-html5?">Is this HTML5?</h3>
<!-- NON-NORMATIVE SECTION -->
<p>In short: Yes.</p>
<p>In more length: The term "HTML5" is widely used as a buzzword to refer to modern Web
technologies, many of which (though by no means all) are developed at the WHATWG. This document is
one such; others are available from <a href="http://www.whatwg.org/specs/">the WHATWG
specification index</a>.</p>
<p class="note">Although we have asked them to stop doing so, the W3C also republishes some parts
of this specification as separate documents. There are numerous differences between this
specification and the W3C forks; some minor, some major. Unfortunately these are not currently
accurately documented anywhere, so there is no way to know which are intentional and which are
not.</p>
<h3>Background</h3>
<!-- NON-NORMATIVE SECTION -->
<p>HTML is the World Wide Web's core markup language. Originally, HTML was primarily designed as a
language for semantically describing scientific documents. Its general design, however, has
enabled it to be adapted, over the subsequent years, to describe a number of other types of
documents and even applications.</p>
<h3>Audience</h3>
<!-- NON-NORMATIVE SECTION -->
<p>This specification is intended for authors of documents and scripts that use the features
defined in this specification<span class="nodev">, 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</span>.</p>
<p>This document is probably not suited to readers who do not already have at least a passing
familiarity with Web technologies, as in places it sacrifices clarity for precision, and brevity
for completeness. More approachable tutorials and authoring guides can provide a gentler
introduction to the topic.</p>
<p>In particular, familiarity with the basics of DOM is necessary for a complete understanding of
some of the more technical parts of this specification. An understanding of Web IDL, HTTP, XML,
Unicode, character encodings, JavaScript, and CSS will also be helpful in places but is not
essential.</p>
<h3>Scope</h3>
<!-- NON-NORMATIVE SECTION -->
<p>This specification is limited to providing a semantic-level markup language and associated
semantic-level scripting APIs for authoring accessible pages on the Web ranging from static
documents to dynamic applications.</p>
<p>The scope of this specification does not include providing mechanisms for media-specific
customization of presentation (although default rendering rules for Web browsers are included at
the end of this specification, and several mechanisms for hooking into CSS are provided as part of
the language).</p>
<p>The scope of this specification is not to describe an entire operating system. In particular,
hardware configuration software, image manipulation tools, and applications that users would be
expected to use with high-end workstations on a daily basis are out of scope. In terms of
applications, this specification is targeted specifically at applications that would be expected
to be used by users on an occasional basis, or regularly but from disparate locations, with low
CPU requirements. Examples of such applications include online purchasing systems, searching
systems, games (especially multiplayer online games), public telephone books or address books,
communications software (e-mail clients, instant messaging clients, discussion software), document
editing software, etc.</p>
<h3>History</h3>
<!-- NON-NORMATIVE SECTION -->
<p>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.</p>
<p>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 quickly followed later that same year.</p>
<p>The following year, the W3C membership decided to stop evolving HTML and instead begin work on
an XML-based equivalent, called XHTML. <!-- http://www.w3.org/MarkUp/future/#summary --> This
effort started with a reformulation of HTML4 in XML, known as XHTML 1.0, which added no new
features except the new serialisation, and which was completed in 2000. After XHTML 1.0, the W3C's
focus turned to making it easier for other working groups to extend XHTML, under the banner of
XHTML Modularization. In parallel with this, the W3C also worked on a new language that was not
compatible with the earlier HTML and XHTML languages, calling it XHTML2.</p>
<p>Around the time that HTML's evolution was stopped in 1998, parts of the API for HTML developed
by browser vendors were specified and published under the name DOM Level 1 (in 1998) and DOM Level
2 Core and DOM Level 2 HTML (starting in 2000 and culminating in 2003). These efforts then petered
out, with some DOM Level 3 specifications published in 2004 but the working group being closed
before all the Level 3 drafts were completed.</p>
<p>In 2003, the publication of XForms, a technology which was positioned as the next generation of
Web forms, sparked a renewed interest in evolving HTML itself, rather than finding replacements
for it. This interest was borne from the realization that XML's deployment as a Web technology was
limited to entirely new technologies (like RSS and later Atom), rather than as a replacement for
existing deployed technologies (like HTML).</p>
<p>A proof of concept to show that it was possible to extend HTML4's forms to provide many of the
features that XForms 1.0 introduced, without requiring browsers to implement rendering engines
that were incompatible with existing HTML Web pages, was the first result of this renewed
interest. At this early stage, while the draft was already publicly available, and input was
already being solicited from all sources, the specification was only under Opera Software's
copyright.</p>
<p>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 covering just forms-related features, were presented to the
W3C jointly by Mozilla and Opera. The proposal was rejected on the grounds that the proposal
conflicted with the previously chosen direction for the Web's evolution; the W3C staff and
membership voted to continue developing XML-based replacements instead.</p>
<p>Shortly thereafter, Apple, Mozilla, and Opera jointly announced their intent to continue
working on the effort under the umbrella of a new venue called the WHATWG. A public mailing list
was created, and the draft was moved to the WHATWG site. The copyright was subsequently amended to
be jointly owned by all three vendors, and to allow reuse of the specification.</p>
<p>The WHATWG was based on several core principles, in particular that technologies need to be
backwards compatible, that specifications and implementations need to match even if this means
changing the specification rather than the implementations, and that specifications need to be
detailed enough that implementations can achieve complete interoperability without
reverse-engineering each other.</p>
<p>The latter requirement in particular required that the scope of the HTML5 specification include
what had previously been specified in three separate documents: HTML4, XHTML1, and DOM2 HTML. It
also meant including significantly more detail than had previously been considered the norm.</p>
<p>In 2006, the W3C indicated an interest to participate in the development of HTML5 after all,
and in 2007 formed a working 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 less restrictive license on the WHATWG
site.</p>
<p>For a number of years, both groups then worked together. In 2011, however, the groups came to
the conclusion that they had different goals: the W3C wanted to publish a "finished" version of
"HTML5", while the WHATWG wanted to continue working on a Living Standard for HTML, continuously
maintaining the specification rather than freezing it in a state with known problems, and adding
new features as needed to evolve the platform.</p>
<p>Since then, the WHATWG has been working on this specification (amongst others), and the W3C has
been copying fixes made by the WHATWG into their fork of the document, as well as making other
changes, some intentional and some not, with no documentation listing or explaining the
differences.</p>
<h3>Design notes</h3>
<!-- NON-NORMATIVE SECTION -->
<p>It must be admitted that many aspects of HTML appear at first glance to be nonsensical and
inconsistent.</p>
<p>HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been
developed over a period of several decades by a wide array of people with different priorities
who, in many cases, did not know of each other's existence.</p>
<p>Features have thus arisen from many sources, and have not always been designed in especially
consistent ways. Furthermore, because of the unique characteristics of the Web, implementation
bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally
written in ways that rely on them before they can be fixed.</p>
<p>Despite all this, efforts have been made to adhere to certain design goals. These are described
in the next few subsections.</p>
<h4>Serializability of script execution</h4>
<!-- NON-NORMATIVE SECTION -->
<p>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 <span data-x="Worker">workers</span>, the intent is that the behavior of implementations can
be thought of as completely serializing the execution of all scripts in all <span data-x="browsing
context">browsing contexts</span>.</p>
<p class="note">The <code
data-x="dom-navigator-yieldForStorageUpdates">navigator.yieldForStorageUpdates()</code> method, in
this model, is equivalent to allowing other scripts to run while the calling script is
blocked.</p>
<h4>Compliance with other specifications</h4>
<!-- NON-NORMATIVE SECTION -->
<p>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 "<dfn>willful violation</dfn>", and the reason for the violation has
been noted.</p>
<h4>Extensibility</h4>
<!-- NON-NORMATIVE SECTION -->
<p>HTML has a wide array of extensibility mechanisms that can be used for adding semantics in a
safe manner:</p>
<ul>
<li><p>Authors can use the <code data-x="attr-class">class</code> attribute to extend elements,
effectively creating their own elements, while using the most applicable existing "real" HTML
element, so that browsers and other tools that don't know of the extension can still support it
somewhat well. This is the tack used by microformats, for example.</p></li>
<li><p>Authors can include data for inline client-side scripts or server-side site-wide scripts
to process using the <code data-x="attr-data-*">data-*=""</code> attributes. These are guaranteed
to never be touched by browsers, and allow scripts to include data on HTML elements that scripts
can then look for and process.</p></li>
<li><p>Authors can use the <code data-x="meta"><meta name="" content=""></code> mechanism to
include page-wide metadata by registering <span data-x="concept-meta-extensions">extensions to
the predefined set of metadata names</span>.</p></li>
<li><p>Authors can use the <code data-x="attr-hyperlink-rel">rel=""</code> mechanism to annotate
links with specific meanings by registering <span data-x="concept-rel-extensions">extensions to
the predefined set of link types</span>. This is also used by microformats.</p></li>
<li><p>Authors can embed raw data using the <code data-x="script"><script type=""></code>
mechanism with a custom type, for further handling by inline or server-side scripts.</p></li>
<li><p>Authors can create <span data-x="plugin">plugins</span> and invoke them using the
<code>embed</code> element. This is how Flash works.</p></li>
<li><p>Authors can extend APIs using the JavaScript prototyping mechanism. This is widely used by
script libraries, for instance.</p></li>
<li><p>Authors can use the microdata feature (the <code
data-x="attr-itemscope">itemscope=""</code> and <code data-x="attr-itemprop">itemprop=""</code>
attributes) to embed nested name-value pairs of data to be shared with other applications and
sites.</p></li>
</ul>
<h3>HTML vs XHTML</h3>
<!-- NON-NORMATIVE SECTION -->
<p>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.</p>
<p>The in-memory representation is known as "DOM HTML", or "the DOM" for short.</p>
<p>There are various concrete syntaxes that can be used to transmit resources that use this
abstract language, two of which are defined in this specification.</p>
<p>The first such concrete syntax is the HTML syntax. This is the format suggested for most
authors. It is compatible with most legacy Web browsers. If a document is transmitted with the
<code>text/html</code> <span>MIME type</span>, then it will be processed as an HTML document by
Web browsers. This specification defines the latest HTML syntax, known simply as "HTML".</p>
<p>The second concrete syntax is the XHTML syntax, which is an application of XML. When a document
is transmitted with an <span>XML MIME type</span>, such as <code>application/xhtml+xml</code>,
then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors
are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors
will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in
the HTML syntax. This specification defines the latest XHTML syntax, known simply as "XHTML".</p>
<p>The DOM, the HTML syntax, and the XHTML syntax cannot all represent the same content. For
example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM
and in the XHTML syntax. Similarly, documents that use the <code>noscript</code> feature can be
represented using the HTML syntax, but cannot be represented with the DOM or in the XHTML syntax.
Comments that contain the string "<code data-x="">--></code>" can only be represented in the
DOM, not in the HTML and XHTML syntaxes.</p>
<h3>Structure of this specification</h3>
<!-- NON-NORMATIVE SECTION -->
<p>This specification is divided into the following major sections:</p>
<dl>
<dt><a href="#introduction">Introduction</a></dt>
<dd>Non-normative materials providing a context for the HTML standard.</dd>
<dt><a href="#infrastructure">Common infrastructure</a></dt>
<dd>The conformance classes, algorithms, definitions, and the common underpinnings of the rest of
the specification.</dd>
<dt><a href="#dom">Semantics, structure, and APIs of HTML documents</a></dt>
<dd>Documents are built from elements. These elements form a tree using the DOM. This section
defines the features of this DOM, as well as introducing the features common to all elements, and
the concepts used in defining elements.</dd>
<dt><a href="#semantics">The elements of HTML</a></dt>
<dd>Each element has a predefined meaning, which is explained in this section. Rules for authors
on how to use the element<span class="nodev">, along with user agent requirements for how to
handle each element,</span> are also given. This includes large signature features of HTML such
as video playback and subtitles, form controls and form submission, and a 2D graphics API known
as the HTML canvas.</dd>
<dt><a href="#microdata">Microdata</a></dt>
<dd>This specification introduces a mechanism for adding machine-readable annotations to
documents, so that tools can extract trees of name-value pairs from the document. This section
describes this mechanism<span class="nodev"> and some algorithms that can be used to convert HTML
documents into other formats</span>. This section also defines some sample Microdata vocabularies
for contact information, calendar events, and licensing works.</dd>
<dt><a href="#editing">User interaction</a></dt>
<dd>HTML documents can provide a number of mechanisms for users to interact with and modify
content, which are described in this section, such as how focus works, and drag-and-drop.</dd>
<dt><a href="#browsers">Loading Web pages</a></dt>
<dd>HTML documents do not exist in a vacuum — this section defines many of the features
that affect environments that deal with multiple pages, such as Web browsers and offline
caching of Web applications.</dd>
<dt><a href="#webappapis">Web application APIs</a></dt>
<dd>This section introduces basic features for scripting of applications in HTML.</dd>
<dt><a href="#workers">Web workers</a></dt>
<dd>This section defines an API for background threads in JavaScript.</dd>
<dt><a href="#comms">The communication APIs</a></dt>
<dd>This section describes some mechanisms that applications written in HTML can use to
communicate with other applications from different domains running on the same client. It also
introduces a server-push event stream mechanism known as Server Sent Events or
<code>EventSource</code>, and a two-way full-duplex socket protocol for scripts known as Web
Sockets.
</dd>
<dt><a href="#webstorage">Web storage</a></dt>
<dd>This section defines a client-side storage mechanism based on name-value pairs.</dd>
<dt><a href="#syntax">The HTML syntax</a></dt>
<dt><a href="#xhtml">The XHTML syntax</a></dt>
<dd>All of these features would be for naught if they couldn't be represented in a serialized
form and sent to other people, and so these sections define the syntaxes of HTML and XHTML<span
class="nodev">, along with rules for how to parse content using those syntaxes</span>.</dd>
<dt><a href="#rendering">Rendering</a></dt>
<dd>This section defines the default rendering rules for Web browsers.</dd>
</dl>
<p>There are also some appendices, listing <a href="#obsolete">obsolete features</a> and <a
href="#iana">IANA considerations</a>, and several indices.</p>
<h4>How to read this specification</h4>
<p>This specification should be read like all other specifications. First, it should be read
cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be
read by picking random sections from the contents list and following all the cross-references.</p>
<p>As described in the conformance requirements section below, this specification describes
conformance criteria for a variety of conformance classes. In particular, there are conformance
requirements that apply to <em>producers</em>, for example authors and the documents they create,
and there are conformance requirements that apply to <em>consumers</em>, for example Web browsers.
They can be distinguished by what they are requiring: a requirement on a producer states what is
allowed, while a requirement on a consumer states how software is to act.</p>
<div class="example">
<p>For example, "the <code data-x="">foo</code> attribute's value must be a <span>valid
integer</span>" is a requirement on producers, as it lays out the allowed values; in contrast,
the requirement "the <code data-x="">foo</code> attribute's value must be parsed using the
<span>rules for parsing integers</span>" is a requirement on consumers, as it describes how to
process the content.</p>
</div>
<p><strong>Requirements on producers have no bearing whatsoever on consumers.</strong></p>
<div class="example">
<p>Continuing the above example, a requirement stating that a particular attribute's value is
constrained to being a <span>valid integer</span> emphatically does <em>not</em> imply anything
about the requirements on consumers. It might be that the consumers are in fact required to treat
the attribute as an opaque string, completely unaffected by whether the value conforms to the
requirements or not. It might be (as in the previous example) that the consumers are required to
parse the value using specific rules that define how invalid (non-numeric in this case) values
are to be processed.</p>
</div>
<h4>Typographic conventions</h4>
<p>This is a definition, requirement, or explanation.</p>
<p class="note">This is a note.</p>
<p class="example">This is an example.</p>
<p class="XXX">This is an open issue.</p>
<p class="warning">This is a warning.</p>
<pre class="idl extract">interface <dfn data-x="">Example</dfn> {
// this is an IDL definition
};</pre>
<dl class="domintro">
<dt><var data-x="">variable</var> = <var data-x="">object</var> . <code data-x="">method</code>( [ <var data-x="">optionalArgument</var> ] )</dt>
<dd>
<p>This is a note to authors describing the usage of an interface.</p>
</dd>
</dl>
<pre class="css">/* this is a CSS fragment */</pre>
<p>The defining instance of a term is marked up like <dfn data-x="x-this">this</dfn>. Uses of that
term are marked up like <span data-x="x-this">this</span> or like <i data-x="x-this">this</i>.</p>
<p>The defining instance of an element, attribute, or API is marked up like <dfn
data-x="x-that"><code>this</code></dfn>. References to that element, attribute, or API are marked
up like <code data-x="x-that">this</code>.</p>
<p>Other code fragments are marked up <code data-x="">like this</code>.</p>
<p>Variables are marked up like <var data-x="">this</var>.</p>
<p>In an algorithm, steps in <span data-x="synchronous section">synchronous sections</span> are
marked with ⌛.</p>
<p>In some cases, requirements are given in the form of lists with conditions and corresponding
requirements. In such cases, the requirements that apply to a condition are always the first set
of requirements that follow the condition, even in the case of there being multiple sets of
conditions for those requirements. Such cases are presented as follows:</p>
<dl class="switch">
<dt>This is a condition
<dt>This is another condition
<dd>This is the requirement that applies to the conditions above.
<dt>This is a third condition
<dd>This is the requirement that applies to the third condition.
</dl>
<h3 id="fingerprint">Privacy concerns</h3>
<!-- NON-NORMATIVE SECTION -->
<p>Some features of HTML trade user convenience for a measure of user privacy.</p>
<p>In general, due to the Internet's architecture, a user can be distinguished from another by the
user's IP address. IP addresses do not perfectly match to a user; as a user moves from device to
device, or from network to network, their IP address will change; similarly, NAT routing, proxy
servers, and shared computers enable packets that appear to all come from a single IP address to
actually map to multiple users. Technologies such as onion routing can be used to further
anonymise requests so that requests from a single user at one node on the Internet appear to come
from many disparate parts of the network.</p>
<p>However, the IP address used for a user's requests is not the only mechanism by which a user's
requests could be related to each other. Cookies, for example, are designed specifically to enable
this, and are the basis of most of the Web's session features that enable you to log into a site
with which you have an account.</p>
<p>There are other mechanisms that are more subtle. Certain characteristics of a user's system can
be used to distinguish groups of users from each other; by collecting enough such information, an
individual user's browser's "digital fingerprint" can be computed, which can be as good, if not
better, as an IP address in ascertaining which requests are from the same user.</p>
<p>Grouping requests in this manner, especially across multiple sites, can be used for both benign
(and even arguably positive) purposes, as well as for malevolent purposes. An example of a
reasonably benign purpose would be determining whether a particular person seems to prefer sites
with dog illustrations as opposed to sites with cat illustrations (based on how often they visit
the sites in question) and then automatically using the preferred illustrations on subsequent
visits to participating sites. Malevolent purposes, however, could include governments combining
information such as the person's home address (determined from the addresses they use when getting
driving directions on one site) with their apparent political affiliations (determined by
examining the forum sites that they participate in) to determine whether the person should be
prevented from voting in an election.</p>
<p>Since the malevolent purposes can be remarkably evil, user agent implementors are encouraged to
consider how to provide their users with tools to minimise leaking information that could be used
to fingerprint a user.</p>
<p>Unfortunately, as the first paragraph in this section implies, sometimes there is great benefit
to be derived from exposing the very information that can also be used for fingerprinting
purposes, so it's not as easy as simply blocking all possible leaks. For instance, the ability to
log into a site to post under a specific identity requires that the user's requests be
identifiable as all being from the same user, more or less by definition. More subtly, though,
information such as how wide text is, which is necessary for many effects that involve drawing
text onto a canvas (e.g. any effect that involves drawing a border around the text) also leaks
information that can be used to group a user's requests. (In this case, by potentially exposing,
via a brute force search, which fonts a user has installed, information which can vary
considerably from user to user.)</p>
<p>Features in this specification which can be <dfn data-x="fingerprinting vector">used to
fingerprint the user</dfn> are marked as this paragraph is.
<!--INSERT FINGERPRINT-->
</p>
<p>Other features in the platform can be used for the same purpose, though, including, though not
limited to:</p>
<ul>
<li>The exact list of which features a user agents supports.</li>
<li>The maximum allowed stack depth for recursion in script.</li>
<li>Features that describe the user's environment, like Media Queries and the <code>Screen</code>
object. <a href="#refsMQ">[MQ]</a> <a href="#refsCSSOMVIEW">[CSSOMVIEW]</a></li>
<li>The user's time zone.</li>
</ul>
<h3>A quick introduction to HTML</h3>
<!-- NON-NORMATIVE SECTION -->
<p>A basic HTML document looks like this:</p>
<pre id="intro-early-example"><!DOCTYPE html>
<html>
<head>
<title>Sample page</title>
</head>
<body>
<h1>Sample page</h1>
<p>This is a <a href="demo.html">simple</a> sample.</p>
<!-- this is a comment -->
</body>
</html></pre>
<p>HTML documents consist of a tree of elements and text. Each element is denoted in the source by
a <span data-x="syntax-start-tag">start tag</span>, such as "<code data-x=""><body></code>", and
an <span data-x="syntax-end-tag">end tag</span>, such as "<code data-x=""></body></code>".
(Certain start tags and end tags can in certain cases be <span
data-x="syntax-tag-omission">omitted</span> and are implied by other tags.)</p>
<p>Tags have to be nested such that elements are all completely within each other, without
overlapping:</p>
<pre class="bad"><p>This is <em>very <strong>wrong</em>!</strong></p></pre>
<pre><p>This <em>is <strong>correct</strong>.</em></p></pre>
<p>This specification defines a set of elements that can be used in HTML, along with rules about
the ways in which the elements can be nested.</p>