-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathintroduction.html
More file actions
1216 lines (1180 loc) · 106 KB
/
Copy pathintroduction.html
File metadata and controls
1216 lines (1180 loc) · 106 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
<!DOCTYPE html>
<html lang="en"><head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<title>HTML 5.1: Introduction</title>
<meta content="width=device-width, initial-scale=1" name="viewport">
<meta content="WD" name="w3c-status">
<link href="../default.css" rel="stylesheet" type="text/css">
<link href="../csslogo.ico" rel="shortcut icon" type="image/x-icon">
<link href="styles/styles-html.css" rel="stylesheet" type="text/css">
<link href="https://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css">
<meta content="Bikeshed 1.0.0" name="generator">
<style>.highlight .hll { background-color: #ffffcc }
.highlight { background: #ffffff; }
.highlight .c { color: #708090 } /* Comment */
.highlight .k { color: #990055 } /* Keyword */
.highlight .l { color: #000000 } /* Literal */
.highlight .n { color: #0077aa } /* Name */
.highlight .o { color: #999999 } /* Operator */
.highlight .p { color: #999999 } /* Punctuation */
.highlight .cm { color: #708090 } /* Comment.Multiline */
.highlight .cp { color: #708090 } /* Comment.Preproc */
.highlight .c1 { color: #708090 } /* Comment.Single */
.highlight .cs { color: #708090 } /* Comment.Special */
.highlight .kc { color: #990055 } /* Keyword.Constant */
.highlight .kd { color: #990055 } /* Keyword.Declaration */
.highlight .kn { color: #990055 } /* Keyword.Namespace */
.highlight .kp { color: #990055 } /* Keyword.Pseudo */
.highlight .kr { color: #990055 } /* Keyword.Reserved */
.highlight .kt { color: #990055 } /* Keyword.Type */
.highlight .ld { color: #000000 } /* Literal.Date */
.highlight .m { color: #000000 } /* Literal.Number */
.highlight .s { color: #a67f59 } /* Literal.String */
.highlight .na { color: #0077aa } /* Name.Attribute */
.highlight .nc { color: #0077aa } /* Name.Class */
.highlight .no { color: #0077aa } /* Name.Constant */
.highlight .nd { color: #0077aa } /* Name.Decorator */
.highlight .ni { color: #0077aa } /* Name.Entity */
.highlight .ne { color: #0077aa } /* Name.Exception */
.highlight .nf { color: #0077aa } /* Name.Function */
.highlight .nl { color: #0077aa } /* Name.Label */
.highlight .nn { color: #0077aa } /* Name.Namespace */
.highlight .py { color: #0077aa } /* Name.Property */
.highlight .nt { color: #669900 } /* Name.Tag */
.highlight .nv { color: #0077aa } /* Name.Variable */
.highlight .ow { color: #999999 } /* Operator.Word */
.highlight .mb { color: #000000 } /* Literal.Number.Bin */
.highlight .mf { color: #000000 } /* Literal.Number.Float */
.highlight .mh { color: #000000 } /* Literal.Number.Hex */
.highlight .mi { color: #000000 } /* Literal.Number.Integer */
.highlight .mo { color: #000000 } /* Literal.Number.Oct */
.highlight .sb { color: #a67f59 } /* Literal.String.Backtick */
.highlight .sc { color: #a67f59 } /* Literal.String.Char */
.highlight .sd { color: #a67f59 } /* Literal.String.Doc */
.highlight .s2 { color: #a67f59 } /* Literal.String.Double */
.highlight .se { color: #a67f59 } /* Literal.String.Escape */
.highlight .sh { color: #a67f59 } /* Literal.String.Heredoc */
.highlight .si { color: #a67f59 } /* Literal.String.Interpol */
.highlight .sx { color: #a67f59 } /* Literal.String.Other */
.highlight .sr { color: #a67f59 } /* Literal.String.Regex */
.highlight .s1 { color: #a67f59 } /* Literal.String.Single */
.highlight .ss { color: #a67f59 } /* Literal.String.Symbol */
.highlight .vc { color: #0077aa } /* Name.Variable.Class */
.highlight .vg { color: #0077aa } /* Name.Variable.Global */
.highlight .vi { color: #0077aa } /* Name.Variable.Instance */
.highlight .il { color: #000000 } /* Literal.Number.Integer.Long */
.highlight { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
</style>
</head>
<body class="h-entry">
<div class="head">
<header>
<p data-fill-with="logo"><a href="http://www.w3.org/"><img alt="W3C" height="48" src="https://www.w3.org/Icons/w3c_home" width="72"></a></p>
<h1 class="p-name no-ref allcaps" id="title">HTML 5.1</h1>
<h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">W3C Working Draft, <time class="dt-updated" datetime="2016-01-20">20 January 2016</time></span></h2>
</header>
</div>
<nav class="prev_next"> — <a href="index.html#contents">Table of contents</a> →<a href="infrastructure.html#infrastructure"><span class="secno">2</span> <span class="content">Common infrastructure</span></a></nav><nav data-fill-with="table-of-contents" id="toc">
<h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
<ol class="toc" role="directory">
<li>
<a href="introduction.html#introduction"><span class="secno">1</span> <span class="content">Introduction</span></a>
<ol class="toc">
<li><a href="introduction.html#background"><span class="secno">1.1</span> <span class="content">Background</span></a>
</li><li><a href="introduction.html#audience"><span class="secno">1.2</span> <span class="content">Audience</span></a>
</li><li><a href="introduction.html#scope"><span class="secno">1.3</span> <span class="content">Scope</span></a>
</li><li><a href="introduction.html#introduction-history"><span class="secno">1.4</span> <span class="content">History</span></a>
</li><li>
<a href="introduction.html#design-notes"><span class="secno">1.5</span> <span class="content">Design notes</span></a>
<ol class="toc">
<li><a href="introduction.html#serializability-of-script-execution"><span class="secno">1.5.1</span> <span class="content">Serializability of script execution</span></a>
</li><li><a href="introduction.html#compliance-with-other-specifications"><span class="secno">1.5.2</span> <span class="content">Compliance with other specifications</span></a>
</li><li><a href="introduction.html#design-notes-extensibility"><span class="secno">1.5.3</span> <span class="content">Extensibility</span></a>
</li></ol>
</li><li><a href="introduction.html#html-vs-xhtml"><span class="secno">1.6</span> <span class="content">HTML vs XHTML</span></a>
</li><li>
<a href="introduction.html#structure-of-this-specification"><span class="secno">1.7</span> <span class="content">Structure of this specification</span></a>
<ol class="toc">
<li><a href="introduction.html#how-to-read-this-specification"><span class="secno">1.7.1</span> <span class="content">How to read this specification</span></a>
</li><li><a href="introduction.html#typographic-conventions"><span class="secno">1.7.2</span> <span class="content">Typographic conventions</span></a>
</li></ol>
</li><li><a href="introduction.html#fingerprint"><span class="secno">1.8</span> <span class="content">Privacy concerns</span></a>
</li><li>
<a href="introduction.html#a-quick-introduction-to-html"><span class="secno">1.9</span> <span class="content">A quick introduction to HTML</span></a>
<ol class="toc">
<li><a href="introduction.html#writing-secure-applications-with-html"><span class="secno">1.9.1</span> <span class="content">Writing secure applications with HTML</span></a>
</li><li><a href="introduction.html#common-pitfalls-to-avoid-when-using-the-scripting-apis"><span class="secno">1.9.2</span> <span class="content"> Common pitfalls to avoid when using the scripting APIs </span></a>
</li><li><a href="introduction.html#how-to-catch-mistakes-when-writing-html-validators-and-conformance-checkers"><span class="secno">1.9.3</span> <span class="content"> How to catch mistakes when writing HTML: validators and conformance checkers </span></a>
</li></ol>
</li><li>
<a href="introduction.html#conformance-requirements-for-authors"><span class="secno">1.10</span> <span class="content">Conformance requirements for authors</span></a>
<ol class="toc">
<li><a href="introduction.html#presentational-markup"><span class="secno">1.10.1</span> <span class="content">Presentational markup</span></a>
</li><li><a href="introduction.html#syntax-errors"><span class="secno">1.10.2</span> <span class="content">Syntax errors</span></a>
</li><li><a href="introduction.html#restrictions-on-content-models-and-on-attribute-values"><span class="secno">1.10.3</span> <span class="content"> Restrictions on content models and on attribute values </span></a>
</li></ol>
</li><li><a href="introduction.html#suggested-reading"><span class="secno">1.11</span> <span class="content">Suggested reading</span></a>
</li></ol>
</li></ol>
</nav>
<main>
<section>
<h2 class="heading settled" data-level="1" id="introduction"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="introduction.html#introduction"></a></h2>
<h3 class="heading settled" data-level="1.1" id="background"><span class="secno">1.1. </span><span class="content">Background</span><a class="self-link" href="introduction.html#background"></a></h3>
<p><em>This section is non-normative.</em></p>
<p>The World Wide Web’s markup language has always been HTML. HTML was primarily designed as a
language for semantically describing scientific documents, although its general design and
adaptations over the years have enabled it to be used to describe a number of other types of
documents.</p>
<p>The main area that has not been adequately addressed by HTML is a vague subject referred to as Web
Applications. This standard attempts to rectify this, while at the same time updating the HTML
language to address issues raised in the past few years.</p>
<h3 class="heading settled" data-level="1.2" id="audience"><span class="secno">1.2. </span><span class="content">Audience</span><a class="self-link" href="introduction.html#audience"></a></h3>
<p><em>This section is non-normative.</em></p>
<p>This specification is intended for authors of documents and scripts that use the features defined
in this specification<span class="impl">, 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 class="heading settled" data-level="1.3" id="scope"><span class="secno">1.3. </span><span class="content">Scope</span><a class="self-link" href="introduction.html#scope"></a></h3>
<p><em>This section is non-normative.</em></p>
<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 class="heading settled" data-level="1.4" id="introduction-history"><span class="secno">1.4. </span><span class="content">History</span><a class="self-link" href="introduction.html#introduction-history"></a></h3>
<p><em>This section is non-normative.</em></p>
<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
HTML3.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. 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 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 under the same editor: Ian Hickson. In
2011, the groups came to the conclusion that they had different goals: the W3C wanted to draw a
line in the sand for features for a HTML5 Recommendation, while the WHATWG wanted to continue
working on a Living Standard for HTML, continuously maintaining the specification and adding new
features. In mid 2012, a new editing team was introduced at the W3C to take care of creating a
HTML5 Recommendation and prepare a Working Draft for the next HTML version.</p>
<p>Since then, the W3C HTML WG has been cherry picking patches from the WHATWG that resolved bugs
registered on the W3C HTML specification or more accurately represented implemented reality in
user agents. At time of publication of this document, patches from the <a data-link-type="dfn" href="http://www.whatwg.org/specs/web-apps/current-work/#">WHATWG HTML specification</a> have been merged until revision <a data-link-type="dfn" href="http://html5.org/r/8424/#">8424</a> inclusive. The W3C HTML editors have also added
patches that resulted from discussions and decisions made by the W3C HTML WG as well a bug fixes
from bugs not shared by the WHATWG.</p>
<p>A separate document is published to document the differences between the HTML specified in this
document and the language described in the HTML4 specification. <a data-link-type="biblio" href="references.html#biblio-html5-diff">[HTML5-DIFF]</a></p>
<h3 class="heading settled" data-level="1.5" id="design-notes"><span class="secno">1.5. </span><span class="content">Design notes</span><a class="self-link" href="introduction.html#design-notes"></a></h3>
<p><em>This section is non-normative.</em></p>
<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 class="heading settled" data-level="1.5.1" id="serializability-of-script-execution"><span class="secno">1.5.1. </span><span class="content">Serializability of script execution</span><a class="self-link" href="introduction.html#serializability-of-script-execution"></a></h4>
<p><em>This section is non-normative.</em></p>
<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 <code class="idl"><a data-link-type="idl" href="http://www.w3.org/TR/workers/#worker">workers</a></code>, the intent is that the behavior of implementations
can be thought of as completely serializing the execution of all scripts in all <a data-link-type="dfn" href="browsers.html#browsing-context">browsing contexts</a>.</p>
<h4 class="heading settled" data-level="1.5.2" id="compliance-with-other-specifications"><span class="secno">1.5.2. </span><span class="content">Compliance with other specifications</span><a class="self-link" href="introduction.html#compliance-with-other-specifications"></a></h4>
<p><em>This section is non-normative.</em></p>
<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 data-dfn-type="dfn" data-noexport="" id="willful-violation">willful violation<a class="self-link" href="introduction.html#willful-violation"></a></dfn>", and the reason for the violation has been
noted.</p>
<h4 class="heading settled" data-level="1.5.3" id="design-notes-extensibility"><span class="secno">1.5.3. </span><span class="content">Extensibility</span><a class="self-link" href="introduction.html#design-notes-extensibility"></a></h4>
<p><em>This section is non-normative.</em></p>
<p>HTML has a wide array of extensibility mechanisms that can be used for adding semantics in a safe
manner:</p>
<ul>
<li data-md="">
<p>Authors can use the <code><a data-link-type="element-attr" href="dom.html#element-attrdef-global-class">class</a></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 data-md="">
<p>Authors can include data for inline client-side scripts or server-side site-wide scripts to
process using the <code><a data-link-type="element-attr" href="dom.html#element-attrdef-global-data">data-*=""</a></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 data-md="">
<p>Authors can use the <code><meta name="" content=""></code> mechanism to
include page-wide metadata by registering <a data-link-type="dfn" href="semantics.html#register-the-names">extensions to the predefined set of metadata names</a>.</p>
</li><li data-md="">
<p>Authors can use the <code><a data-link-type="element-attr" href="semantics.html#element-attrdef-link-rel">rel=""</a></code> mechanism to annotate links with specific meanings by
registering <a data-link-type="dfn" href="semantics.html#link-types-extensions-to-the-predefined-set-of-link-type">extensions to the predefined set of link types</a>. This is also used by
microformats. Additionally, absolute URLs that do not contain any non-ASCII characters, nor
characters in the range U+0041 (LATIN CAPITAL LETTER A) through U+005A (LATIN CAPITAL LETTER Z)
(inclusive), may be used as link types.</p>
</li><li data-md="">
<p>Authors can embed raw data using the <code><script type=""></code> mechanism with a custom
type, for further handling by inline or server-side scripts.</p>
</li><li data-md="">
<p>Authors can create <a data-link-type="dfn" href="infrastructure.html#plugin">plugins</a> and invoke them using the <code><a data-link-type="element" href="semantics.html#elementdef-embed">embed</a></code> element. This is how
Flash works.</p>
</li><li data-md="">
<p>Authors can extend APIs using the JavaScript prototyping mechanism. This is widely used by
script libraries, for instance.</p>
</li></ul>
<h3 class="heading settled" data-level="1.6" id="html-vs-xhtml"><span class="secno">1.6. </span><span class="content">HTML vs XHTML</span><a class="self-link" href="introduction.html#html-vs-xhtml"></a></h3>
<p><em>This section is non-normative.</em></p>
<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 <a href="iana.html#text-html"><code>text/html</code></a> <a data-link-type="dfn" href="infrastructure.html#mime-type">MIME type</a>, then it will be processed as an HTML document by Web
browsers. This specification defines version 5.1 of the HTML syntax, known as "HTML5.1".</p>
<p>The second concrete syntax is the XHTML syntax, which is an application of XML. When a document
is transmitted with an <a data-link-type="dfn" href="infrastructure.html#xml-mime-type">XML MIME type</a>, 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 version 5.1 of the XHTML syntax,
known as "XHTML5.1".</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><a data-link-type="element" href="semantics.html#elementdef-noscript">noscript</a></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>--></code>" can only be represented in the
DOM, not in the HTML and XHTML syntaxes.</p>
<h3 class="heading settled" data-level="1.7" id="structure-of-this-specification"><span class="secno">1.7. </span><span class="content">Structure of this specification</span><a class="self-link" href="introduction.html#structure-of-this-specification"></a></h3>
<p><em>This section is non-normative.</em></p>
<p>This specification is divided into the following major sections:</p>
<div>
<dl>
<dt data-md="">
<p><a href="introduction.html#introduction">§1 Introduction</a></p>
</dt><dd data-md="">
<p>Non-normative materials providing a context for the HTML standard.</p>
</dd><dt data-md="">
<p><a href="infrastructure.html#infrastructure">§2 Common infrastructure</a></p>
</dt><dd data-md="">
<p>The conformance classes, algorithms, definitions, and the common underpinnings of the rest of
the specification.</p>
</dd><dt data-md="">
<p><a href="dom.html#dom">§3 Semantics, structure, and APIs of HTML documents</a></p>
</dt><dd data-md="">
<p>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.</p>
</dd><dt data-md="">
<p><a href="semantics.html#semantics">§4 The elements of HTML</a></p>
</dt><dd data-md="">
<p>Each element has a predefined meaning, which is explained in this section. Rules for authors
on how to use the element<span class="impl">, 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.</p>
</dd><dt data-md="">
<p><a href="editing.html#editing">§5 User interaction</a></p>
</dt><dd data-md="">
<p>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.</p>
</dd><dt data-md="">
<p><a href="browsers.html#browsers">§6 Loading Web pages</a></p>
</dt><dd data-md="">
<p>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.</p>
</dd><dt data-md="">
<p><a href="webappapis.html#webappapis">§7 Web application APIs</a></p>
</dt><dd data-md="">
<p>This section introduces basic features for scripting of applications in HTML.</p>
</dd><dt data-md="">
<p><a href="syntax.html#syntax">§8 The HTML syntax</a></p>
</dt><dt data-md="">
<p><a href="xhtml.html#xhtml">§9 The XHTML syntax</a></p>
</dt><dd data-md="">
<p>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="impl">, along with rules for how to parse content using those
syntaxes</span>.</p>
</dd><dt data-md="">
<p><a href="rendering.html#rendering">§10 Rendering</a></p>
</dt><dd data-md="">
<p>This section defines the default rendering rules for Web browsers.</p>
</dd></dl>
<p>There are also some appendices, listing <a href="obsolete.html#obsolete">§11 Obsolete features</a> and <a href="iana.html#iana">§12 IANA considerations</a>, and several indices.</p>
</div>
<h4 class="heading settled" data-level="1.7.1" id="how-to-read-this-specification"><span class="secno">1.7.1. </span><span class="content">How to read this specification</span><a class="self-link" href="introduction.html#how-to-read-this-specification"></a></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" id="example-7e5c439b"><a class="self-link" href="introduction.html#example-7e5c439b"></a> For example, "the <code>foo</code> attribute’s value must be a <a data-link-type="dfn" href="infrastructure.html#valid-integer">valid integer</a>" is a
requirement on producers, as it lays out the allowed values; in contrast, the requirement "the <code>foo</code> attribute’s value must be parsed using the <a data-link-type="dfn" href="infrastructure.html#integers-parses">rules for parsing integers</a>"
is a requirement on consumers, as it describes how to process the content. </div>
<p><strong>Requirements on producers have no bearing whatsoever on consumers.</strong></p>
<div class="example" id="example-287546e8"><a class="self-link" href="introduction.html#example-287546e8"></a> Continuing the above example, a requirement stating that a particular attribute’s value is
constrained to being a <a data-link-type="dfn" href="infrastructure.html#valid-integer">valid integer</a> 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. </div>
<h4 class="heading settled" data-level="1.7.2" id="typographic-conventions"><span class="secno">1.7.2. </span><span class="content">Typographic conventions</span><a class="self-link" href="introduction.html#typographic-conventions"></a></h4>
<div>
This is a definition, requirement, or explanation.
<p class="note" role="note">This is a note.</p>
<p class="example" id="example-263fb1aa"><a class="self-link" href="introduction.html#example-263fb1aa"></a>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-ignore" data-highlight="webidl" data-no-idl="">interface <b>Example</b> {
// this is an IDL definition
};
</pre>
<dl class="domintro">
<dt><var>variable</var> = <var>object</var> . <code>method</code>( [ <var>optionalArgument</var> ] )
</dt><dd>This is a note to authors describing the usage of an interface.
</dd></dl>
<pre class="css highlight"><span class="c">/* this is a CSS fragment */</span></pre>
<p>The defining instance of a term is marked up like <dfn data-dfn-for="conventions" data-dfn-type="dfn" data-noexport="" id="conventions-this">this<a class="self-link" href="introduction.html#conventions-this"></a></dfn>. Uses of that term are marked
up like <a data-link-type="dfn" href="introduction.html#conventions-this">this</a> or like <a data-link-type="dfn" href="introduction.html#conventions-this"><i>this</i></a>.</p>
<p>The defining instance of an element, attribute, or API is marked up like <dfn data-dfn-for="conventions" data-dfn-type="element" data-noexport="" id="elementdef-conventions-this"><code>this</code><a class="self-link" href="introduction.html#elementdef-conventions-this"></a></dfn>. References to that element, attribute, or API are marked up like <code><a data-link-type="element" href="introduction.html#elementdef-conventions-this">this</a></code>.</p>
<p>Other code fragments are marked up <code>like this</code>.</p>
<p>Variables are marked up like <var>this</var>.</p>
<p>In an algorithm, steps in <a data-link-type="dfn" href="webappapis.html#synchronous-section">synchronous sections</a> 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><dt>This is another condition
</dt><dd>This is the requirement that applies to the conditions above.
</dd><dt>This is a third condition
</dt><dd>This is the requirement that applies to the third condition.
</dd></dl>
</div>
<h3 class="heading settled" data-level="1.8" id="fingerprint"><span class="secno">1.8. </span><span class="content">Privacy concerns</span><a class="self-link" href="introduction.html#fingerprint"></a></h3>
<p><em>This section is non-normative.</em></p>
<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
anonymize requests so that requests from a single user at one node on the Internet appear to come
from many disparate parts of the network.</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 minimize 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-dfn-type="dfn" data-lt="for privacy" data-noexport="" id="fingerprinting-vector">used to fingerprint the user<a class="self-link" href="introduction.html#fingerprinting-vector"></a></dfn> are marked as this paragraph is. <a class="fingerprint" href="introduction.html#fingerprinting-vector"><img alt="(This is a fingerprinting vector.)" height="21" src="images/fingerprint.png" width="15"></a></p>
<p>Other features in the platform can be used for the same purpose, though, including, though not
limited to:</p>
<ul>
<li data-md="">
<p>The exact list of which features a user agents supports.</p>
</li><li data-md="">
<p>The maximum allowed stack depth for recursion in script.</p>
</li><li data-md="">
<p>Features that describe the user’s environment, like Media Queries and the <code class="idl"><a data-link-type="idl" href="http://www.w3.org/TR/cssom-view/#screen">Screen</a></code> object. <a data-link-type="biblio" href="references.html#biblio-mediaq">[MEDIAQ]</a> <a data-link-type="biblio" href="references.html#biblio-cssom-view">[CSSOM-VIEW]</a></p>
</li><li data-md="">
<p>The user’s time zone.</p>
</li></ul>
<h3 class="heading settled" data-level="1.9" id="a-quick-introduction-to-html"><span class="secno">1.9. </span><span class="content">A quick introduction to HTML</span><a class="self-link" href="introduction.html#a-quick-introduction-to-html"></a></h3>
<p><em>This section is non-normative.</em></p>
<p>A basic HTML document looks like this:</p>
<pre class="highlight" id="intro-early-example"><span class="cp"><!DOCTYPE html></span>
<span class="nt"><html></span>
<span class="nt"><head></span>
<span class="nt"><title></span>Sample page<span class="nt"></title></span>
<span class="nt"></head></span>
<span class="nt"><body></span>
<span class="nt"><h1></span>Sample page<span class="nt"></h1></span>
<span class="nt"><p></span>This is a <span class="nt"><a</span> <span class="na">href=</span><span class="s">"demo.html"</span><span class="nt">></span>simple<span class="nt"></a></span> sample.<span class="nt"></p></span>
<span class="c"><!-- this is a comment --></span>
<span class="nt"></body></span>
<span class="nt"></html></span></pre>
<p>HTML documents consist of a tree of elements and text. Each element is denoted in the source by
a <a data-link-type="dfn" href="syntax.html#start-tag">start tag</a>, such as "<code><a data-link-type="element" href="semantics.html#elementdef-body"><body></a></code>", and an <a data-link-type="dfn" href="syntax.html#end-tag">end tag</a>, such as
"<code><a data-link-type="element" href="semantics.html#elementdef-body"></body></a></code>". (Certain start tags and end tags can in certain cases be <a data-link-type="dfn" href="syntax.html#optional-start-and-end-tags">omitted</a> 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 highlight"><span class="nt"><p></span>This is <span class="nt"><em></span>very <span class="nt"><strong></span>wrong<span class="nt"></em></span>!<span class="nt"></strong></p></span></pre>
<pre class="highlight"><span class="nt"><p></span>This <span class="nt"><em></span>is <span class="nt"><strong></span>correct<span class="nt"></strong></span>.<span class="nt"></em></p></span></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>
<p>Elements can have attributes, which control how the elements work. In the example below, there
is a <a data-link-type="dfn" href="semantics.html#hyperlink">hyperlink</a>, formed using the <code><a data-link-type="element" href="#a">a</a></code> element and its <code><a data-link-type="element-attr" href="semantics.html#element-attrdef-links-href">href</a></code> attribute:</p>
<pre class="highlight"><span class="nt"><a</span> <span class="na">href=</span><span class="s">"demo.html"</span><span class="nt">></span>simple<span class="nt"></a></span></pre>
<p><a data-link-type="dfn" href="syntax.html#attribute">Attributes</a> are placed inside the start tag, and consist of a <a data-link-type="dfn" href="syntax.html#name">name</a> and a <a data-link-type="dfn" href="syntax.html#attribute-value">value</a>, separated by an "<code>=</code>" character. The attribute value can remain <a data-link-type="dfn" href="syntax.html#unquoted">unquoted</a> if it doesn’t contain <a data-link-type="dfn" href="infrastructure.html#space-characters">space characters</a> or any of <code>"</code> <code>'</code> <code>`</code> <code>=</code> <code><</code> or <code>></code>. Otherwise,
it has to be quoted using either single or double quotes. The value, along with the
"<code>=</code>" character, can be omitted altogether if the value is the empty string.</p>
<pre class="highlight"><span class="c"><!-- empty attributes --></span>
<span class="nt"><input</span> <span class="na">name=</span><span class="s">address</span> <span class="na">disabled</span><span class="nt">></span>
<span class="nt"><input</span> <span class="na">name=</span><span class="s">address</span> <span class="na">disabled=</span><span class="s">""</span><span class="nt">></span>
<span class="c"><!-- attributes with a value --></span>
<span class="nt"><input</span> <span class="na">name=</span><span class="s">address</span> <span class="na">maxlength=</span><span class="s">200</span><span class="nt">></span>
<span class="nt"><input</span> <span class="na">name=</span><span class="s">address</span> <span class="na">maxlength=</span><span class="s">'200'</span><span class="nt">></span>
<span class="nt"><input</span> <span class="na">name=</span><span class="s">address</span> <span class="na">maxlength=</span><span class="s">"200"</span><span class="nt">></span></pre>
<p>HTML user agents (e.g. Web browsers) then <i>parse</i> this markup, turning it into a DOM
(Document Object Model) tree. A DOM tree is an in-memory representation of a document.</p>
<p>DOM trees contain several kinds of nodes, in particular a <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#documenttype">DocumentType</a></code> node, <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#element">Element</a></code> nodes, <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#text">Text</a></code> nodes, <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#comment">Comment</a></code> nodes, and in some
cases <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#processinginstruction">ProcessingInstruction</a></code> nodes.</p>
<p>The <a href="introduction.html#intro-early-example">markup snippet at the top of this section</a> would be turned into the following DOM tree:</p>
<ul class="domTree">
<li class="t10">DOCTYPE: <code>html</code>
</li><li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-html">html</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-head">head</a></code>
<ul>
<li class="t3"><code>#text</code>: <span>⏎␣␣</span>
</li><li class="t1">
<a data-link-type="element" href="#title"><code>title</code></a>
<ul>
<li class="t3"><code>#text</code>: <span>Sample page</span>
</li></ul>
</li><li class="t3"><code>#text</code>: <span>⏎␣</span>
</li></ul>
</li><li class="t3"><code>#text</code>: <span>⏎␣</span>
</li><li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-body">body</a></code>
<ul>
<li class="t3"><code>#text</code>: <span>⏎␣␣</span>
</li><li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-h1">h1</a></code>
<ul>
<li class="t3"><code>#text</code>: <span>Sample page</span>
</li></ul>
</li><li class="t3"><code>#text</code>: <span>⏎␣␣</span>
</li><li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-p">p</a></code>
<ul>
<li class="t3"><code>#text</code>: <span>This is a</span>
</li><li class="t1">
<code><a data-link-type="element" href="#a">a</a></code> <span class="t2"><code><a data-link-type="element-attr" href="semantics.html#element-attrdef-links-href">href</a></code>="<code>demo.html</code>"</span>
<ul>
<li class="t3"><code>#text</code>: <span>simple</span>
</li></ul>
</li><li class="t3"><code>#text</code>: <span> sample.</span>
</li></ul>
</li><li class="t3"><code>#text</code>: <span>⏎␣␣</span>
</li><li class="t8"><code>#comment</code>: <span> this is a comment </span>
</li><li class="t3"><code>#text</code>: <span>⏎␣⏎</span>
</li></ul>
</li></ul>
</li></ul>
<p>The <a data-link-type="dfn" href="infrastructure.html#root-element">root element</a> of this tree is the <code><a data-link-type="element" href="semantics.html#elementdef-html">html</a></code> element, which is the element always found at
the root of HTML documents. It contains two elements, <code><a data-link-type="element" href="semantics.html#elementdef-head">head</a></code> and <code><a data-link-type="element" href="semantics.html#elementdef-body">body</a></code>, as well as a <code class="idl"><a class="idl-code" data-link-type="interface" href="https://dom.spec.whatwg.org/#text">Text</a></code> node between them.</p>
<p>There are many more <code class="idl"><a class="idl-code" data-link-type="interface" href="https://dom.spec.whatwg.org/#text">Text</a></code> nodes in the DOM tree than one would initially expect,
because the source contains a number of spaces (represented here by "␣") and line breaks
("⏎") that all end up as <code class="idl"><a class="idl-code" data-link-type="interface" href="https://dom.spec.whatwg.org/#text">Text</a></code> nodes in the DOM. However, for historical
reasons not all of the spaces and line breaks in the original markup appear in the DOM. In
particular, all the whitespace before <code><a data-link-type="element" href="semantics.html#elementdef-head">head</a></code> start tag ends up being dropped silently, and all
the whitespace after the <code><a data-link-type="element" href="semantics.html#elementdef-body">body</a></code> end tag ends up placed at the end of the <code><a data-link-type="element" href="semantics.html#elementdef-body">body</a></code>.</p>
<p>The <code><a data-link-type="element" href="semantics.html#elementdef-head">head</a></code> element contains a <a data-link-type="element" href="#title"><code>title</code></a> element, which itself contains a <code class="idl"><a class="idl-code" data-link-type="interface" href="https://dom.spec.whatwg.org/#text">Text</a></code> node
with the text "Sample page". Similarly, the <code><a data-link-type="element" href="semantics.html#elementdef-body">body</a></code> element contains an <code><a data-link-type="element" href="semantics.html#elementdef-h1">h1</a></code> element, a <code><a data-link-type="element" href="semantics.html#elementdef-p">p</a></code> element, and a comment.</p>
<hr>
<p>This DOM tree can be manipulated from scripts in the page. Scripts (typically in JavaScript)
are small programs that can be embedded using the <code><a data-link-type="element" href="semantics.html#elementdef-script">script</a></code> element or using <a data-link-type="dfn" href="webappapis.html#event-handler-content-event-handler-content-attribute">event handler content attributes</a>. For example, here is a form with a script that sets the
value of the form’s <code><a data-link-type="element" href="semantics.html#elementdef-output">output</a></code> element to say "Hello World"</p>
<pre class="highlight"><span class="nt"><form</span> <span class="na">name=</span><span class="s">"main"</span><span class="nt">></span>
Result: <span class="nt"><output</span> <span class="na">name=</span><span class="s">"result"</span><span class="nt">></output></span>
<span class="nt"><script></span>
<span class="nb">document</span><span class="p">.</span><span class="nx">forms</span><span class="p">.</span><span class="nx">main</span><span class="p">.</span><span class="nx">elements</span><span class="p">.</span><span class="nx">result</span><span class="p">.</span><span class="nx">value</span> <span class="o">=</span> <span class="s1">'Hello World'</span><span class="p">;</span>
<span class="nt"></script></span>
<span class="nt"></form></span></pre>
<p>Each element in the DOM tree is represented by an object, and these objects have APIs so that
they can be manipulated. For instance, a link (e.g. the <code><a data-link-type="element" href="#a">a</a></code> element in the tree above) can have
its "<code><a data-link-type="element-attr" href="semantics.html#element-attrdef-links-href">href</a></code>" attribute changed in several ways:</p>
<pre class="highlight"><span class="kd">var</span> <span class="nx">a</span> <span class="o">=</span> <span class="nb">document</span><span class="p">.</span><span class="nx">links</span><span class="p">[</span><span class="mi">0</span><span class="p">];</span> <span class="c1">// obtain the first link in the document</span>
<span class="nx">a</span><span class="p">.</span><span class="nx">href</span> <span class="o">=</span> <span class="s1">'sample.html'</span><span class="p">;</span> <span class="c1">// change the destination URL of the link</span>
<span class="nx">a</span><span class="p">.</span><span class="nx">protocol</span> <span class="o">=</span> <span class="s1">'https'</span><span class="p">;</span> <span class="c1">// change just the scheme part of the URL</span>
<span class="nx">a</span><span class="p">.</span><span class="nx">setAttribute</span><span class="p">(</span><span class="s1">'href'</span><span class="p">,</span> <span class="s1">'http://example.com/'</span><span class="p">);</span> <span class="c1">// change the content attribute directly</span></pre>
<p>Since DOM trees are used as the way to represent HTML documents when they are processed and
presented by implementations (especially interactive implementations like Web browsers), this
specification is mostly phrased in terms of DOM trees, instead of the markup described above.</p>
<hr>
<p>HTML documents represent a media-independent description of interactive content. HTML documents
might be rendered to a screen, or through a speech synthesizer, or on a braille display. To
influence exactly how such rendering takes place, authors can use a styling language such as CSS.</p>
<p>In the following example, the page has been made yellow-on-blue using CSS.</p>
<pre class="highlight"><span class="cp"><!DOCTYPE html></span>
<span class="nt"><html></span>
<span class="nt"><head></span>
<span class="nt"><title></span>Sample styled page<span class="nt"></title></span>
<span class="nt"><style></span>
<span class="nt">body</span> <span class="p">{</span> <span class="k">background</span><span class="o">:</span> <span class="nb">navy</span><span class="p">;</span> <span class="k">color</span><span class="o">:</span> <span class="nb">yellow</span><span class="p">;</span> <span class="p">}</span>
<span class="nt"></style></span>
<span class="nt"></head></span>
<span class="nt"><body></span>
<span class="nt"><h1></span>Sample styled page<span class="nt"></h1></span>
<span class="nt"><p></span>This page is just a demo.<span class="nt"></p></span>
<span class="nt"></body></span>
<span class="nt"></html></span></pre>
<p>For more details on how to use HTML, authors are encouraged to consult tutorials and guides. Some
of the examples included in this specification might also be of use, but the novice author is
cautioned that this specification, by necessity, defines the language with a level of detail that
might be difficult to understand at first.</p>
<h4 class="heading settled" data-level="1.9.1" id="writing-secure-applications-with-html"><span class="secno">1.9.1. </span><span class="content">Writing secure applications with HTML</span><a class="self-link" href="introduction.html#writing-secure-applications-with-html"></a></h4>
<p><em>This section is non-normative.</em></p>
<p>When HTML is used to create interactive sites, care needs to be taken to avoid introducing
vulnerabilities through which attackers can compromise the integrity of the site itself or of
the site’s users.</p>
<p>A comprehensive study of this matter is beyond the scope of this document, and authors are
strongly encouraged to study the matter in more detail. However, this section attempts to provide
a quick introduction to some common pitfalls in HTML application development.</p>
<p>The security model of the Web is based on the concept of "origins", and correspondingly many of
the potential attacks on the Web involve cross-origin actions. <a data-link-type="biblio" href="references.html#biblio-origin">[ORIGIN]</a></p>
<dl>
<dt data-md="">
<p>Not validating user input</p>
</dt><dt data-md="">
<p>Cross-site scripting (XSS)</p>
</dt><dt data-md="">
<p>SQL injection</p>
</dt><dd data-md="">
<p>When accepting untrusted input, e.g. user-generated content such as text comments, values
in URL parameters, messages from third-party sites, etc, it is imperative that the data
be validated before use, and properly escaped when displayed. Failing to do this can
allow a hostile user to perform a variety of attacks, ranging from the potentially
benign, such as providing bogus user information like a negative age, to the serious,
such as running scripts every time a user looks at a page that includes the information,
potentially propagating the attack in the process, to the catastrophic, such as deleting
all data in the server.</p>
<p>When writing filters to validate user input, it is imperative that filters always be
safelist-based, allowing known-safe constructs and disallowing all other input.
Blocklist-based filters that disallow known-bad inputs and allow everything else are not
secure, as not everything that is bad is yet known (for example, because it might be invented
in the future).</p>
<div class="example" id="example-fd8071c5">
<a class="self-link" href="introduction.html#example-fd8071c5"></a> For example, suppose a page looked at its URL’s query string to determine what to display,
and the site then redirected the user to that page to display a message, as in:
<pre class="highlight"><span class="nt"><ul></span>
<span class="nt"><li><a</span> <span class="na">href=</span><span class="s">"message.cgi?say=Hello"</span><span class="nt">></span>Say Hello<span class="nt"></a></span>
<span class="nt"><li><a</span> <span class="na">href=</span><span class="s">"message.cgi?say=Welcome"</span><span class="nt">></span>Say Welcome<span class="nt"></a></span>
<span class="nt"><li><a</span> <span class="na">href=</span><span class="s">"message.cgi?say=Kittens"</span><span class="nt">></span>Say Kittens<span class="nt"></a></span>
<span class="nt"></ul></span></pre>
<p>If the message was just displayed to the user without escaping, a hostile attacker could
then craft a URL that contained a script element:</p>
<pre>http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E</pre>
<p>If the attacker then convinced a victim user to visit this page, a script of the
attacker’s choosing would run on the page. Such a script could do any number of hostile
actions, limited only by what the site offers: if the site is an e-commerce shop, for
instance, such a script could cause the user to unknowingly make arbitrarily many
unwanted purchases.</p>
<p>This is called a cross-site scripting attack.</p>
</div>
<p>There are many constructs that can be used to try to trick a site into executing code. Here
are some that authors are encouraged to consider when writing safelist filters:</p>
<ul>
<li data-md="">
<p>When allowing harmless-seeming elements like <code><a data-link-type="element" href="semantics.html#elementdef-img">img</a></code>, it is important to safelist any
provided attributes as well. If one allowed all attributes then an attacker could, for
instance, use the <a class="idl-code" data-link-type="attribute" href="webappapis.html#dom-globaleventhandlers-onload"><code>onload</code></a> attribute to run arbitrary script.</p>
</li><li data-md="">
<p>When allowing URLs to be provided (e.g. for links), the scheme of each URL also needs to be
explicitly safelisted, as there are many schemes that can be abused. The most prominent
example is "<code>javascript:</code>", but user agents can implement (and indeed, have
historically implemented) others.</p>
</li><li data-md="">
<p>Allowing a <code><a data-link-type="element" href="semantics.html#elementdef-base">base</a></code> element to be inserted means any <code><a data-link-type="element" href="semantics.html#elementdef-script">script</a></code> elements in the page with
relative links can be hijacked, and similarly that any form submissions can get redirected
to a hostile site.</p>
</li></ul>
<dl>
<dt data-md="">
<p>Cross-site request forgery (CSRF)</p>
</dt><dd data-md="">
<p>If a site allows a user to make form submissions with user-specific side-effects, for example
posting messages on a forum under the user’s name, making purchases, or applying for a
passport, it is important to verify that the request was made by the user intentionally,
rather than by another site tricking the user into making the request unknowingly.</p>
<p>This problem exists because HTML forms can be submitted to other origins.</p>
<p>Sites can prevent such attacks by populating forms with user-specific hidden tokens, or by
checking <code>Origin</code> headers on all requests.</p>
</dd><dt data-md="">
<p>Clickjacking</p>
</dt><dd data-md="">
<p>A page that provides users with an interface to perform actions that the user might not
wish to perform needs to be designed so as to avoid the possibility that users can be
tricked into activating the interface.</p>
<p>One way that a user could be so tricked is if a hostile site places the victim site in a
small <code><a data-link-type="element" href="semantics.html#elementdef-iframe">iframe</a></code> and then convinces the user to click, for instance by having the user play
a reaction game. Once the user is playing the game, the hostile site can quickly position
the <code><a data-link-type="element" href="semantics.html#elementdef-iframe">iframe</a></code> under the mouse cursor just as the user is about to click, thus tricking the
user into clicking the victim site’s interface.</p>
<p>To avoid this, sites that do not expect to be used in frames are encouraged to only enable
their interface if they detect that they are not in a frame (e.g. by comparing the <code class="idl"><a data-link-type="idl" href="browsers.html#dom-window-window">window</a></code> object to the value of the <code class="idl"><a data-link-type="idl" href="browsers.html#dom-window-top">top</a></code> attribute).</p>
</dd></dl>
</dd></dl>
<h4 class="heading settled" data-level="1.9.2" id="common-pitfalls-to-avoid-when-using-the-scripting-apis"><span class="secno">1.9.2. </span><span class="content"> Common pitfalls to avoid when using the scripting APIs </span><a class="self-link" href="introduction.html#common-pitfalls-to-avoid-when-using-the-scripting-apis"></a></h4>
<p><em>This section is non-normative.</em></p>
<p>Scripts in HTML have "run-to-completion" semantics, meaning that the browser will generally run
the script uninterrupted before doing anything else, such as firing further events or continuing
to parse the document.</p>
<p>On the other hand, parsing of HTML files happens <a data-link-type="dfn" href="infrastructure.html#in-parallel">in parallel</a> and incrementally, meaning
that the parser can pause at any point to let scripts run. This is generally a good thing, but it
does mean that authors need to be careful to avoid hooking event handlers after the events could
have possibly fired.</p>
<p>There are two techniques for doing this reliably: use <a data-link-type="dfn" href="webappapis.html#event-handler-content-event-handler-content-attribute">event handler content attributes</a>, or
create the element and add the event handlers in the same script. The latter is safe because, as
mentioned earlier, scripts are run to completion before further events can fire.</p>
<div class="example" id="example-c289d2c4">
<a class="self-link" href="introduction.html#example-c289d2c4"></a> One way this could manifest itself is with <code><a data-link-type="element" href="semantics.html#elementdef-img">img</a></code> elements and the <code>load</code> event.
The event could fire as soon as the element has been parsed, especially if the image has already
been cached (which is common).
<p>Here, the author uses the <a class="idl-code" data-link-type="attribute" href="webappapis.html#dom-globaleventhandlers-onload"><code>onload</code></a> handler on an <code><a data-link-type="element" href="semantics.html#elementdef-img">img</a></code> element to catch the <code>load</code> event:</p>
<pre class="highlight"><span class="nt"><img</span> <span class="na">src=</span><span class="s">"games.png"</span> <span class="na">alt=</span><span class="s">"Games"</span> <span class="na">onload=</span><span class="s">"gamesLogoHasLoaded(event)"</span><span class="nt">></span></pre>
<p>If the element is being added by script, then so long as the event handlers are added in the
same script, the event will still not be missed:</p>
<pre class="highlight"><span class="nt"><script></span>
<span class="kd">var</span> <span class="nx">img</span> <span class="o">=</span> <span class="k">new</span> <span class="nx">Image</span><span class="p">();</span>
<span class="nx">img</span><span class="p">.</span><span class="nx">src</span> <span class="o">=</span> <span class="s1">'games.png'</span><span class="p">;</span>
<span class="nx">img</span><span class="p">.</span><span class="nx">alt</span> <span class="o">=</span> <span class="s1">'Games'</span><span class="p">;</span>
<span class="nx">img</span><span class="p">.</span><span class="nx">onload</span> <span class="o">=</span> <span class="nx">gamesLogoHasLoaded</span><span class="p">;</span>
<span class="c1">// img.addEventListener('load', gamesLogoHasLoaded, false); // would work also</span>
<span class="nt"></script></span></pre>
<p>However, if the author first created the <code><a data-link-type="element" href="semantics.html#elementdef-img">img</a></code> element and then in a separate
script added the event listeners, there’s a chance that the <code>load</code> event would be
fired in between, leading it to be missed:</p>
<pre class="bad highlight"><span class="c"><!-- Do not use this style, it has a race condition! --></span>
<span class="nt"><img</span> <span class="na">id=</span><span class="s">"games"</span> <span class="na">src=</span><span class="s">"games.png"</span> <span class="na">alt=</span><span class="s">"Games"</span><span class="nt">></span>
<span class="c"><!-- the 'load' event might fire here while the parser is taking a</span>
<span class="c"> break, in which case you will not see it! --></span>
<span class="nt"><script></span>
<span class="kd">var</span> <span class="nx">img</span> <span class="o">=</span> <span class="nb">document</span><span class="p">.</span><span class="nx">getElementById</span><span class="p">(</span><span class="s1">'games'</span><span class="p">);</span>
<span class="nx">img</span><span class="p">.</span><span class="nx">onload</span> <span class="o">=</span> <span class="nx">gamesLogoHasLoaded</span><span class="p">;</span> <span class="c1">// might never fire!</span>
<span class="nt"></script></span></pre>
</div>
<h4 class="heading settled" data-level="1.9.3" id="how-to-catch-mistakes-when-writing-html-validators-and-conformance-checkers"><span class="secno">1.9.3. </span><span class="content"> How to catch mistakes when writing HTML: validators and conformance checkers </span><a class="self-link" href="introduction.html#how-to-catch-mistakes-when-writing-html-validators-and-conformance-checkers"></a></h4>
<p><em>This section is non-normative.</em></p>
<p>Authors are encouraged to make use of conformance checkers (also known as <i>validators</i>) to
catch common mistakes. The W3C provides a number of online validation services, including the <a data-link-type="dfn" external="" href="http://validator.w3.org/nu/#">Nu Markup Validation Service</a>.</p>
<h3 class="heading settled" data-level="1.10" id="conformance-requirements-for-authors"><span class="secno">1.10. </span><span class="content">Conformance requirements for authors</span><a class="self-link" href="introduction.html#conformance-requirements-for-authors"></a></h3>
<p><em>This section is non-normative.</em></p>
<p>Unlike previous versions of the HTML specification, this specification defines in some detail the
required processing for invalid documents as well as valid documents.</p>
<p>However, even though the processing of invalid content is in most cases well-defined, conformance
requirements for documents are still important: in practice, interoperability (the situation in
which all implementations process particular 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 <a data-link-type="dfn" href="infrastructure.html#conforming-document">conforming document</a> and one with errors.</p>
<h4 class="heading settled" data-level="1.10.1" id="presentational-markup"><span class="secno">1.10.1. </span><span class="content">Presentational markup</span><a class="self-link" href="introduction.html#presentational-markup"></a></h4>
<p><em>This section is non-normative.</em></p>
<p>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:</p>
<dl>
<dt data-md="">
<p>The use of presentational elements leads to poorer accessibility</p>
</dt><dd data-md="">
<p>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 using semantically-appropriate markup. Furthermore, even
using such techniques doesn’t help make pages accessible for non-AT non-graphical users, such
as users of text-mode browsers.</p>
<p>Using media-independent markup, on the other hand, provides an easy way for documents to be
authored in such a way that they work for more users (e.g. text browsers).</p>
</dd><dt data-md="">
<p>Higher cost of maintenance</p>
</dt><dd data-md="">
<p>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 <code><font color=""></code> throughout requires changes across the entire site,
whereas a similar change to a site based on CSS can be done by changing a single file.</p>
</dd><dt data-md="">
<p>Larger document sizes</p>
</dt><dd data-md="">
<p>Presentational markup tends to be much more redundant, and thus results in larger document
sizes.</p>
<p>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) to help authors move away from presentational markup;
later, XHTML 1.1 went further and obsoleted those features altogether.</p>
<p>The only remaining presentational markup features in HTML are the <code><a data-link-type="element-attr" href="dom.html#element-attrdef-global-style">style</a></code> attribute
and the <code><a data-link-type="element" href="semantics.html#elementdef-style">style</a></code> element. Use of the <code><a data-link-type="element-attr" href="dom.html#element-attrdef-global-style">style</a></code> attribute 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 in unusual
cases where a separate style sheet would be inconvenient. Similarly, the <code><a data-link-type="element" href="semantics.html#elementdef-style">style</a></code> element can
be useful in syndication or for page-specific styles, but in general an external style sheet
is likely to be more convenient when the styles apply to multiple pages.</p>
<p>It is also worth noting that some elements that were previously presentational have been
redefined in this specification to be media-independent: <code><a data-link-type="element" href="semantics.html#elementdef-b">b</a></code>, <code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>, <code><a data-link-type="element" href="semantics.html#elementdef-hr">hr</a></code>, <code><a data-link-type="element" href="semantics.html#elementdef-s">s</a></code>, <code><a data-link-type="element" href="semantics.html#elementdef-small">small</a></code>, and <code><a data-link-type="element" href="semantics.html#elementdef-u">u</a></code>.</p>
</dd></dl>
<h4 class="heading settled" data-level="1.10.2" id="syntax-errors"><span class="secno">1.10.2. </span><span class="content">Syntax errors</span><a class="self-link" href="introduction.html#syntax-errors"></a></h4>
<p><em>This section is non-normative.</em></p>
<p>The syntax of HTML is constrained to avoid a wide variety of problems.</p>
<dl>
<dt data-md="">
<p>Unintuitive error-handling behavior</p>
</dt><dd data-md="">
<p>Certain invalid syntax constructs, when parsed, result in DOM trees that are highly
unintuitive.</p>
<div class="example" id="example-0dccb7e3">
<a class="self-link" href="introduction.html#example-0dccb7e3"></a> For example, the following markup fragment results in a DOM with an <code><a data-link-type="element" href="semantics.html#elementdef-hr">hr</a></code> element that is
an <em>earlier</em> sibling of the corresponding <code><a data-link-type="element" href="semantics.html#elementdef-table">table</a></code> element:
<pre class="bad highlight"><span class="nt"><table><hr></span>...</pre>
</div>
</dd><dt data-md="">
<p>Errors with optional error recovery</p>
</dt><dd data-md="">
<p>To allow user agents to be used in controlled environments without having to implement the more
bizarre and convoluted error handling rules, user agents are permitted to fail whenever
encountering a <a data-link-type="dfn" href="syntax.html#parser-parse-error">parse error</a>.</p>
</dd><dt data-md="">
<p>Errors where the error-handling behavior is not compatible with streaming user agents</p>
</dt><dd data-md="">
<p>Some error-handling behavior, such as the behavior for the <code><table><hr>...</code> example mentioned above, are incompatible with streaming user agents (user agents that process
HTML files in one pass, without storing state). To avoid interoperability problems with such
user agents, any syntax resulting in such behavior is considered invalid.</p>
</dd><dt data-md="">
<p>Errors that can result in infoset coercion</p>
</dt><dd data-md="">
<p>When a user agent based on XML is connected to an HTML parser, it is possible that certain
invariants that XML enforces, 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 syntax constructs that require such handling are
considered invalid.</p>
</dd><dt data-md="">
<p>Errors that result in disproportionally poor performance</p>
</dt><dd data-md="">
<p>Certain syntax constructs can result in disproportionally poor performance. To discourage the
use of such constructs, they are typically made non-conforming.</p>
<div class="example" id="example-ccb699bd">
<a class="self-link" href="introduction.html#example-ccb699bd"></a> For example, the following markup results in poor performance, since all the unclosed <code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code> elements have to be reconstructed in each paragraph, resulting in progressively more
elements in each paragraph:
<pre class="bad highlight"><span class="nt"><p><i></span>He dreamt.
<span class="nt"><p><i></span>He dreamt that he ate breakfast.
<span class="nt"><p><i></span>Then lunch.
<span class="nt"><p><i></span>And finally dinner.</pre>
<p>The resulting DOM for this fragment would be:</p>
<ul class="domTree">
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-p">p</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t3"><code>#text</code>: <span>He dreamt.</span>
</li></ul>
</li></ul>
</li><li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-p">p</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t3"><code>#text</code>: <span>He dreamt that he ate breakfast.</span>
</li></ul>
</li></ul>
</li></ul>
</li><li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-p">p</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t3"><code>#text</code>: <span>Then lunch.</span>
</li></ul>
</li></ul>
</li></ul>
</li></ul>
</li><li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-p">p</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t1">
<code><a data-link-type="element" href="semantics.html#elementdef-i">i</a></code>
<ul>
<li class="t3"><code>#text</code>: <span>And finally dinner.</span>
</li></ul>
</li></ul>
</li></ul>
</li></ul>
</li></ul>
</li></ul>
</div>
</dd><dt data-md="">
<p>Errors involving fragile syntax constructs</p>
</dt><dd data-md="">
<p>There are syntax constructs that, for historical reasons, are relatively fragile. To help
reduce the number of users who accidentally run into such problems, they are made
non-conforming.</p>
<div class="example" id="example-4c330288">
<a class="self-link" href="introduction.html#example-4c330288"></a> For example, the parsing of certain named character references in attributes happens even
with the closing 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 <em>does</em> form a named character reference, they will be interpreted as that
character instead.
<p>In this fragment, the attribute’s value is "<code>?bill&ted</code>":</p>
<pre class="bad highlight"><span class="nt"><a</span> <span class="na">href=</span><span class="s">"?bill&ted"</span><span class="nt">></span>Bill and Ted<span class="nt"></a></span></pre>
<p>In the following fragment, however, the attribute’s value is actually
"<code>?art©</code>", <em>not</em> the intended "<code>?art&copy</code>",
because even without the final semicolon, "<code>&copy</code>" is handled the same
as "<code>&copy;</code>" and thus gets interpreted as "<code>©</code>":</p>
<pre class="bad highlight"><span class="nt"><a</span> <span class="na">href=</span><span class="s">"?art&copy"</span><span class="nt">></span>Art and Copy<span class="nt"></a></span></pre>
<p>To avoid this problem, all named character references are required to end with a
semicolon, and uses of named character references without a semicolon are flagged as
errors.</p>
<p>Thus, the correct way to express the above cases is as follows:</p>
<pre class="highlight"><span class="nt"><a</span> <span class="na">href=</span><span class="s">"?bill&ted"</span><span class="nt">></span>Bill and Ted<span class="nt"></a></span> <span class="c"><!-- &ted is ok, since it’s not a named character reference --></span></pre>
<pre class="highlight"><span class="nt"><a</span> <span class="na">href=</span><span class="s">"?art&amp;copy"</span><span class="nt">></span>Art and Copy<span class="nt"></a></span> <span class="c"><!-- the & has to be escaped, since &copy is a named character reference --></span></pre>
</div>
</dd><dt data-md="">
<p>Errors involving known interoperability problems in legacy user agents</p>
</dt><dd data-md="">
<p>Certain syntax constructs are known to cause especially subtle or serious problems in legacy
user agents, and are therefore marked as non-conforming to help authors avoid them.</p>
<p class="example" id="example-75966b06"><a class="self-link" href="introduction.html#example-75966b06"></a> For example, this is why the U+0060 GRAVE ACCENT character (`) is not allowed in unquoted
attributes. In certain legacy user agents, it is sometimes treated as a quote character. </p>
<p class="example" id="example-767451ed"><a class="self-link" href="introduction.html#example-767451ed"></a> Another example of this is the DOCTYPE, which is required to trigger <a data-link-type="dfn" href="infrastructure.html#no-quirks-mode">no-quirks mode</a>,
because the behavior of legacy user agents in <a data-link-type="dfn" href="infrastructure.html#quirks-mode">quirks mode</a> is often largely
undocumented. </p>
</dd><dt data-md="">
<p>Errors that risk exposing authors to security attacks</p>
</dt><dd data-md="">
<p>Certain restrictions exist purely to avoid known security problems.</p>
<p class="example" id="example-7147ccfb"><a class="self-link" href="introduction.html#example-7147ccfb"></a> For example, the restriction on using UTF-7 exists purely to avoid authors falling prey to a
known cross-site-scripting attack using UTF-7. <a data-link-type="biblio" href="references.html#biblio-rfc2152">[RFC2152]</a> </p>
</dd><dt data-md="">
<p>Cases where the author’s intent is unclear</p>
</dt><dd data-md="">
<p>Markup where the author’s intent is very unclear is often made non-conforming. Correcting these
errors early makes later maintenance easier.</p>
<div class="example" id="example-1ef96626">
<a class="self-link" href="introduction.html#example-1ef96626"></a> For example, it is unclear whether the author intended the following to be an <code><a data-link-type="element" href="semantics.html#elementdef-h1">h1</a></code> heading
or an <code><a data-link-type="element" href="semantics.html#elementdef-h2">h2</a></code> heading:
<pre class="bad highlight"><span class="nt"><h2></span>Contact details<span class="nt"></h2></span></pre>
</div>
</dd><dt data-md="">
<p>Cases that are likely to be typos</p>
</dt><dd data-md="">
<p>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, attribute names, and so forth, that do not match the names
defined in this specification.</p>
<p class="example" id="example-3eebe0bd"><a class="self-link" href="introduction.html#example-3eebe0bd"></a> For example, if the author typed <code><capton></code> instead of <code><a data-link-type="element" href="semantics.html#elementdef-caption"><caption></a></code>, this would be flagged as an error and the author could correct
the typo immediately. </p>
</dd><dt data-md="">
<p>Errors that could interfere with new syntax in the future</p>
</dt><dd data-md="">
<p>In order to allow the language syntax to be extended in the future, certain otherwise
harmless features are disallowed.</p>
<p class="example" id="example-3d55048a"><a class="self-link" href="introduction.html#example-3d55048a"></a> For example, "attributes" in end tags are ignored currently, but they are invalid, in case a
future change to the language makes use of that syntax feature without conflicting with
already-deployed (and valid!) content. </p>
</dd></dl>
<p>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 of the flexibility of the HTML syntax. To aid such
authors, conformance checkers can provide modes of operation wherein such conventions are
enforced.</p>
<h4 class="heading settled" data-level="1.10.3" id="restrictions-on-content-models-and-on-attribute-values"><span class="secno">1.10.3. </span><span class="content"> Restrictions on content models and on attribute values </span><a class="self-link" href="introduction.html#restrictions-on-content-models-and-on-attribute-values"></a></h4>
<p><em>This section is non-normative.</em></p>
<p>Beyond the syntax of the language, this specification also places restrictions on how elements