You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1366 lines
79 KiB
1366 lines
79 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html lang="en-US-x-Hixie" ><head><title>1 Introduction — HTML5 </title><style type="text/css">
|
|
pre { margin-left: 2em; white-space: pre-wrap; }
|
|
h2 { margin: 3em 0 1em 0; }
|
|
h3 { margin: 2.5em 0 1em 0; }
|
|
h4 { margin: 2.5em 0 0.75em 0; }
|
|
h5, h6 { margin: 2.5em 0 1em; }
|
|
h1 + h2, h1 + h2 + h2 { margin: 0.75em 0 0.75em; }
|
|
h2 + h3, h3 + h4, h4 + h5, h5 + h6 { margin-top: 0.5em; }
|
|
p { margin: 1em 0; }
|
|
hr:not(.top) { display: block; background: none; border: none; padding: 0; margin: 2em 0; height: auto; }
|
|
dl, dd { margin-top: 0; margin-bottom: 0; }
|
|
dt { margin-top: 0.75em; margin-bottom: 0.25em; clear: left; }
|
|
dt + dt { margin-top: 0; }
|
|
dd dt { margin-top: 0.25em; margin-bottom: 0; }
|
|
dd p { margin-top: 0; }
|
|
dd dl + p { margin-top: 1em; }
|
|
dd table + p { margin-top: 1em; }
|
|
p + * > li, dd li { margin: 1em 0; }
|
|
dt, dfn { font-weight: bold; font-style: normal; }
|
|
dt dfn { font-style: italic; }
|
|
pre, code { font-size: inherit; font-family: monospace; font-variant: normal; }
|
|
pre strong { color: black; font: inherit; font-weight: bold; background: yellow; }
|
|
pre em { font-weight: bolder; font-style: normal; }
|
|
@media screen { code { color: orangered; } code :link, code :visited { color: inherit; } }
|
|
var sub { vertical-align: bottom; font-size: smaller; position: relative; top: 0.1em; }
|
|
table { border-collapse: collapse; border-style: hidden hidden none hidden; }
|
|
table thead, table tbody { border-bottom: solid; }
|
|
table tbody th:first-child { border-left: solid; }
|
|
table tbody th { text-align: left; }
|
|
table td, table th { border-left: solid; border-right: solid; border-bottom: solid thin; vertical-align: top; padding: 0.2em; }
|
|
blockquote { margin: 0 0 0 2em; border: 0; padding: 0; font-style: italic; }
|
|
|
|
.bad, .bad *:not(.XXX) { color: gray; border-color: gray; background: transparent; }
|
|
.matrix, .matrix td { border: none; text-align: right; }
|
|
.matrix { margin-left: 2em; }
|
|
.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; }
|
|
|
|
.toc dfn, h1 dfn, h2 dfn, h3 dfn, h4 dfn, h5 dfn, h6 dfn { font: inherit; }
|
|
img.extra { float: right; }
|
|
pre.idl { border: solid thin; background: #EEEEEE; color: black; padding: 0.5em 1em; }
|
|
pre.idl :link, pre.idl :visited { color: inherit; background: transparent; }
|
|
pre.css { border: solid thin; background: #FFFFEE; color: black; padding: 0.5em 1em; }
|
|
pre.css:first-line { color: #AAAA50; }
|
|
dl.domintro { color: green; margin: 2em 0 2em 2em; padding: 0.5em 1em; border: none; background: #DDFFDD; }
|
|
hr + dl.domintro, div.impl + dl.domintro { margin-top: 2.5em; margin-bottom: 1.5em; }
|
|
dl.domintro dt, dl.domintro dt * { color: black; text-decoration: none; }
|
|
dl.domintro dd { margin: 0.5em 0 1em 2em; padding: 0; }
|
|
dl.domintro dd p { margin: 0.5em 0; }
|
|
dl.switch { padding-left: 2em; }
|
|
dl.switch > dt { text-indent: -1.5em; }
|
|
dl.switch > dt:before { content: '\21AA'; padding: 0 0.5em 0 0; display: inline-block; width: 1em; text-align: right; line-height: 0.5em; }
|
|
dl.triple { padding: 0 0 0 1em; }
|
|
dl.triple dt, dl.triple dd { margin: 0; display: inline }
|
|
dl.triple dt:after { content: ':'; }
|
|
dl.triple dd:after { content: '\A'; white-space: pre; }
|
|
.diff-old { text-decoration: line-through; color: silver; background: transparent; }
|
|
.diff-chg, .diff-new { text-decoration: underline; color: green; background: transparent; }
|
|
a .diff-new { border-bottom: 1px blue solid; }
|
|
|
|
h2 { page-break-before: always; }
|
|
h1, h2, h3, h4, h5, h6 { page-break-after: avoid; }
|
|
h1 + h2, hr + h2.no-toc { page-break-before: auto; }
|
|
|
|
p > span:not([title=""]):not([class="XXX"]):not([class="impl"]):not([class="note"]),
|
|
li > span:not([title=""]):not([class="XXX"]):not([class="impl"]):not([class="note"]), { border-bottom: solid #9999CC; }
|
|
|
|
div.head { margin: 0 0 1em; padding: 1em 0 0 0; }
|
|
div.head p { margin: 0; }
|
|
div.head h1 { margin: 0; }
|
|
div.head .logo { float: right; margin: 0 1em; }
|
|
div.head .logo img { border: none } /* remove border from top image */
|
|
div.head dl { margin: 1em 0; }
|
|
div.head p.copyright, div.head p.alt { font-size: x-small; font-style: oblique; margin: 0; }
|
|
|
|
body > .toc > li { margin-top: 1em; margin-bottom: 1em; }
|
|
body > .toc.brief > li { margin-top: 0.35em; margin-bottom: 0.35em; }
|
|
body > .toc > li > * { margin-bottom: 0.5em; }
|
|
body > .toc > li > * > li > * { margin-bottom: 0.25em; }
|
|
.toc, .toc li { list-style: none; }
|
|
|
|
.brief { margin-top: 1em; margin-bottom: 1em; line-height: 1.1; }
|
|
.brief li { margin: 0; padding: 0; }
|
|
.brief li p { margin: 0; padding: 0; }
|
|
|
|
.category-list { margin-top: -0.75em; margin-bottom: 1em; line-height: 1.5; }
|
|
.category-list::before { content: '\21D2\A0'; font-size: 1.2em; font-weight: 900; }
|
|
.category-list li { display: inline; }
|
|
.category-list li:not(:last-child)::after { content: ', '; }
|
|
.category-list li > span, .category-list li > a { text-transform: lowercase; }
|
|
.category-list li * { text-transform: none; } /* don't affect <code> nested in <a> */
|
|
|
|
.XXX { color: #E50000; background: white; border: solid red; padding: 0.5em; margin: 1em 0; }
|
|
.XXX > :first-child { margin-top: 0; }
|
|
p .XXX { line-height: 3em; }
|
|
.annotation { border: solid thin black; background: #0C479D; color: white; position: relative; margin: 8px 0 20px 0; }
|
|
.annotation:before { position: absolute; left: 0; top: 0; width: 100%; height: 100%; margin: 6px -6px -6px 6px; background: #333333; z-index: -1; content: ''; }
|
|
.annotation :link, .annotation :visited { color: inherit; }
|
|
.annotation :link:hover, .annotation :visited:hover { background: transparent; }
|
|
.annotation span { border: none ! important; }
|
|
.note { color: green; background: transparent; font-family: sans-serif; }
|
|
.warning { color: red; background: transparent; }
|
|
.note, .warning { font-weight: bolder; font-style: italic; }
|
|
p.note, div.note { padding: 0.5em 2em; }
|
|
span.note { padding: 0 2em; }
|
|
.note p:first-child, .warning p:first-child { margin-top: 0; }
|
|
.note p:last-child, .warning p:last-child { margin-bottom: 0; }
|
|
.warning:before { font-style: normal; }
|
|
p.note:before { content: 'Note: '; }
|
|
p.warning:before { content: '\26A0 Warning! '; }
|
|
|
|
.bookkeeping:before { display: block; content: 'Bookkeeping details'; font-weight: bolder; font-style: italic; }
|
|
.bookkeeping { font-size: 0.8em; margin: 2em 0; }
|
|
.bookkeeping p { margin: 0.5em 2em; display: list-item; list-style: square; }
|
|
.bookkeeping dt { margin: 0.5em 2em 0; }
|
|
.bookkeeping dd { margin: 0 3em 0.5em; }
|
|
|
|
h4 { position: relative; z-index: 3; }
|
|
h4 + .element, h4 + div + .element { margin-top: -2.5em; padding-top: 2em; }
|
|
.element {
|
|
background: #EEEEFF;
|
|
color: black;
|
|
margin: 0 0 1em 0.15em;
|
|
padding: 0 1em 0.25em 0.75em;
|
|
border-left: solid #9999FF 0.25em;
|
|
position: relative;
|
|
z-index: 1;
|
|
}
|
|
.element:before {
|
|
position: absolute;
|
|
z-index: 2;
|
|
top: 0;
|
|
left: -1.15em;
|
|
height: 2em;
|
|
width: 0.9em;
|
|
background: #EEEEFF;
|
|
content: ' ';
|
|
border-style: none none solid solid;
|
|
border-color: #9999FF;
|
|
border-width: 0.25em;
|
|
}
|
|
|
|
.example { display: block; color: #222222; background: #FCFCFC; border-left: double; margin-left: 2em; padding-left: 1em; }
|
|
td > .example:only-child { margin: 0 0 0 0.1em; }
|
|
|
|
ul.domTree, ul.domTree ul { padding: 0 0 0 1em; margin: 0; }
|
|
ul.domTree li { padding: 0; margin: 0; list-style: none; position: relative; }
|
|
ul.domTree li li { list-style: none; }
|
|
ul.domTree li:first-child::before { position: absolute; top: 0; height: 0.6em; left: -0.75em; width: 0.5em; border-style: none none solid solid; content: ''; border-width: 0.1em; }
|
|
ul.domTree li:not(:last-child)::after { position: absolute; top: 0; bottom: -0.6em; left: -0.75em; width: 0.5em; border-style: none none solid solid; content: ''; border-width: 0.1em; }
|
|
ul.domTree span { font-style: italic; font-family: serif; }
|
|
ul.domTree .t1 code { color: purple; font-weight: bold; }
|
|
ul.domTree .t2 { font-style: normal; font-family: monospace; }
|
|
ul.domTree .t2 .name { color: black; font-weight: bold; }
|
|
ul.domTree .t2 .value { color: blue; font-weight: normal; }
|
|
ul.domTree .t3 code, .domTree .t4 code, .domTree .t5 code { color: gray; }
|
|
ul.domTree .t7 code, .domTree .t8 code { color: green; }
|
|
ul.domTree .t10 code { color: teal; }
|
|
|
|
body.dfnEnabled dfn { cursor: pointer; }
|
|
.dfnPanel {
|
|
display: inline;
|
|
position: absolute;
|
|
z-index: 10;
|
|
height: auto;
|
|
width: auto;
|
|
padding: 0.5em 0.75em;
|
|
font: small sans-serif, Droid Sans Fallback;
|
|
background: #DDDDDD;
|
|
color: black;
|
|
border: outset 0.2em;
|
|
}
|
|
.dfnPanel * { margin: 0; padding: 0; font: inherit; text-indent: 0; }
|
|
.dfnPanel :link, .dfnPanel :visited { color: black; }
|
|
.dfnPanel p { font-weight: bolder; }
|
|
.dfnPanel * + p { margin-top: 0.25em; }
|
|
.dfnPanel li { list-style-position: inside; }
|
|
|
|
#configUI { position: absolute; z-index: 20; top: 10em; right: 1em; width: 11em; font-size: small; }
|
|
#configUI p { margin: 0.5em 0; padding: 0.3em; background: #EEEEEE; color: black; border: inset thin; }
|
|
#configUI p label { display: block; }
|
|
#configUI #updateUI, #configUI .loginUI { text-align: center; }
|
|
#configUI input[type=button] { display: block; margin: auto; }
|
|
|
|
fieldset { margin: 1em; padding: 0.5em 1em; }
|
|
fieldset > legend + * { margin-top: 0; }
|
|
fieldset > :last-child { margin-bottom: 0; }
|
|
fieldset p { margin: 0.5em 0; }
|
|
|
|
.stability {
|
|
position: fixed;
|
|
bottom: 0;
|
|
left: 0; right: 0;
|
|
margin: 0 auto 0 auto !important;
|
|
z-index: 1000;
|
|
width: 50%;
|
|
background: maroon; color: yellow;
|
|
-webkit-border-radius: 1em 1em 0 0;
|
|
-moz-border-radius: 1em 1em 0 0;
|
|
border-radius: 1em 1em 0 0;
|
|
-moz-box-shadow: 0 0 1em #500;
|
|
-webkit-box-shadow: 0 0 1em #500;
|
|
box-shadow: 0 0 1em red;
|
|
padding: 0.5em 1em;
|
|
text-align: center;
|
|
}
|
|
.stability strong {
|
|
display: block;
|
|
}
|
|
.stability input {
|
|
appearance: none; margin: 0; border: 0; padding: 0.25em 0.5em; background: transparent; color: black;
|
|
position: absolute; top: -0.5em; right: 0; font: 1.25em sans-serif; text-align: center;
|
|
}
|
|
.stability input:hover {
|
|
color: white;
|
|
text-shadow: 0 0 2px black;
|
|
}
|
|
.stability input:active {
|
|
padding: 0.3em 0.45em 0.2em 0.55em;
|
|
}
|
|
.stability :link, .stability :visited,
|
|
.stability :link:hover, .stability :visited:hover {
|
|
background: transparent;
|
|
color: white;
|
|
}
|
|
|
|
</style><link href="data:text/css,.impl%20%7B%20display:%20none;%20%7D%0Ahtml%20%7B%20border:%20solid%20yellow;%20%7D%20.domintro:before%20%7B%20display:%20none;%20%7D" id="author" rel="alternate stylesheet" title="Author documentation only"><link href="data:text/css,.impl%20%7B%20background:%20%23FFEEEE;%20%7D%20.domintro:before%20%7B%20background:%20%23FFEEEE;%20%7D" id="highlight" rel="alternate stylesheet" title="Highlight implementation
|
|
requirements"><link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css"><style type="text/css">
|
|
|
|
.applies thead th > * { display: block; }
|
|
.applies thead code { display: block; }
|
|
.applies tbody th { whitespace: nowrap; }
|
|
.applies td { text-align: center; }
|
|
.applies .yes { background: yellow; }
|
|
|
|
.matrix, .matrix td { border: hidden; text-align: right; }
|
|
.matrix { margin-left: 2em; }
|
|
|
|
.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; }
|
|
|
|
.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('http://www.whatwg.org/specs/web-apps/current-work/fonts/Essays1743.ttf');
|
|
}
|
|
@font-face {
|
|
font-family: 'Essays1743';
|
|
font-weight: bold;
|
|
src: url('http://www.whatwg.org/specs/web-apps/current-work/fonts/Essays1743-Bold.ttf');
|
|
}
|
|
@font-face {
|
|
font-family: 'Essays1743';
|
|
font-style: italic;
|
|
src: url('http://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('http://www.whatwg.org/specs/web-apps/current-work/fonts/Essays1743-BoldItalic.ttf');
|
|
}
|
|
|
|
</style><style type="text/css">
|
|
.domintro:before { display: table; margin: -1em -0.5em -0.5em auto; width: auto; content: 'This box is non-normative. Implementation requirements are given below this box.'; color: black; font-style: italic; border: solid 2px; background: white; padding: 0 0.25em; }
|
|
</style><script type="text/javascript">
|
|
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;
|
|
}
|
|
</script>
|
|
<script src="link-fixup.js" type="text/javascript"></script>
|
|
<link href="style.css" rel="stylesheet"><link href="spec.html#contents" title="Table of contents" rel="index">
|
|
<link href="infrastructure.html" title="2 Common infrastructure" rel="next">
|
|
</head><body><div class="head" id="head">
|
|
<div id="multipage-common">
|
|
<p class="stability" id="wip"><strong>This is a work in
|
|
progress!</strong> For the latest updates from the HTML WG, possibly
|
|
including important bug fixes, please look at the <a href="http://dev.w3.org/html5/spec/Overview.html">editor's draft</a> instead.
|
|
There may also be a more
|
|
<a href="http://www.w3.org/TR/html5">up-to-date Working Draft</a>
|
|
with changes based on resolution of Last Call issues.
|
|
<input onclick="closeWarning(this.parentNode)" type="button" value="╳⃝"></p>
|
|
<script type="text/javascript">
|
|
function closeWarning(element) {
|
|
element.parentNode.removeChild(element);
|
|
var date = new Date();
|
|
date.setDate(date.getDate()+4);
|
|
document.cookie = 'hide-obsolescence-warning=1; expires=' + date.toGMTString();
|
|
}
|
|
if (getCookie('hide-obsolescence-warning') == '1')
|
|
setTimeout(function () { document.getElementById('wip').parentNode.removeChild(document.getElementById('wip')); }, 2000);
|
|
</script></div>
|
|
|
|
<p><a href="http://www.w3.org/"><img alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home" width="72"></a></p>
|
|
|
|
<h1>HTML5</h1>
|
|
</div><div>
|
|
<a href="spec.html#contents">Table of contents</a> –
|
|
<a href="infrastructure.html" class="next">2 Common infrastructure</a>
|
|
<ol class="toc"><li><a href="introduction.html#introduction"><span class="secno">1 </span>Introduction</a>
|
|
<ol><li><a href="introduction.html#background"><span class="secno">1.1 </span>Background</a></li><li><a href="introduction.html#audience"><span class="secno">1.2 </span>Audience</a></li><li><a href="introduction.html#scope"><span class="secno">1.3 </span>Scope</a></li><li><a href="introduction.html#history-1"><span class="secno">1.4 </span>History</a></li><li><a href="introduction.html#design-notes"><span class="secno">1.5 </span>Design notes</a>
|
|
<ol><li><a href="introduction.html#serializability-of-script-execution"><span class="secno">1.5.1 </span>Serializability of script execution</a></li><li><a href="introduction.html#compliance-with-other-specifications"><span class="secno">1.5.2 </span>Compliance with other specifications</a></li></ol></li><li><a href="introduction.html#html-vs-xhtml"><span class="secno">1.6 </span>HTML vs XHTML</a></li><li><a href="introduction.html#structure-of-this-specification"><span class="secno">1.7 </span>Structure of this specification</a>
|
|
<ol><li><a href="introduction.html#how-to-read-this-specification"><span class="secno">1.7.1 </span>How to read this specification</a></li><li><a href="introduction.html#typographic-conventions"><span class="secno">1.7.2 </span>Typographic conventions</a></li></ol></li><li><a href="introduction.html#a-quick-introduction-to-html"><span class="secno">1.8 </span>A quick introduction to HTML</a></li><li><a href="introduction.html#conformance-requirements-for-authors"><span class="secno">1.9 </span>Conformance requirements for authors</a>
|
|
<ol><li><a href="introduction.html#presentational-markup"><span class="secno">1.9.1 </span>Presentational markup</a></li><li><a href="introduction.html#syntax-errors"><span class="secno">1.9.2 </span>Syntax errors</a></li><li><a href="introduction.html#restrictions-on-content-models-and-on-attribute-values"><span class="secno">1.9.3 </span>Restrictions on content models and on attribute values</a></li></ol></li><li><a href="introduction.html#recommended-reading"><span class="secno">1.10 </span>Recommended reading</a></li></ol></li></ol></div>
|
|
|
|
<h2 id="introduction"><span class="secno">1 </span>Introduction</h2><h3 id="background"><span class="secno">1.1 </span>Background</h3><p><i>This section is non-normative.</i></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 specification
|
|
attempts to rectify this, while at the same time updating the HTML
|
|
specifications to address issues raised in the past few years.</p><h3 id="audience"><span class="secno">1.2 </span>Audience</h3><p><i>This section is non-normative.</i></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 Core and DOM
|
|
Events 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 id="scope"><span class="secno">1.3 </span>Scope</h3><p><i>This section is non-normative.</i></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. For instance online purchasing
|
|
systems, searching systems, games (especially multiplayer online
|
|
games), public telephone books or address books, communications
|
|
software (e-mail clients, instant messaging clients, discussion
|
|
software), document editing software, etc.</p><h3 id="history-1"><span class="secno">1.4 </span>History</h3><p><i>This section is non-normative.</i></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 HTML
|
|
3.2, which was completed in 1997. HTML4 followed, reaching
|
|
completion in 1998.</p><p>At this time, the W3C membership decided to stop evolving HTML
|
|
and instead begin work on an XML-based equivalent, called
|
|
XHTML. This effort started with a reformulation of HTML4 in XML,
|
|
known as XHTML 1.0, which added no new features except the new
|
|
serialization, and which was completed in 2000. After XHTML 1.0, the
|
|
W3C's 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>Since then, both groups have been working together.</p><p>The <a href="http://www.whatwg.org/specs/web-apps/current-work/">HTML
|
|
specification</a> published by the WHATWG is not identical to
|
|
this specification. At the time of this publication, the main
|
|
differences were that the WHATWG version included features not
|
|
included in this W3C version: some features have been omitted, but
|
|
may be considered for future revisions of HTML beyond HTML5; and
|
|
other features were omitted because at the W3C they are published as
|
|
separate specifications.</p><p>A separate document has been published by the W3C HTML working
|
|
group to document the differences between this specification and the
|
|
language described in the HTML4 specification. <a href="references.html#refsHTMLDIFF">[HTMLDIFF]</a></p><h3 id="design-notes"><span class="secno">1.5 </span>Design notes</h3><p><i>This section is non-normative.</i></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 id="serializability-of-script-execution"><span class="secno">1.5.1 </span>Serializability of script execution</h4><p><i>This section is non-normative.</i></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 <span title="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 <a href="browsers.html#browsing-context" title="browsing context">browsing contexts</a>.</p><p class="note">The <code title="dom-navigator-yieldForStorageUpdates"><a href="timers.html#dom-navigator-yieldforstorageupdates">navigator.yieldForStorageUpdates()</a></code>
|
|
method, in this model, is equivalent to allowing other scripts to
|
|
run while the calling script is blocked.</p><h4 id="compliance-with-other-specifications"><span class="secno">1.5.2 </span>Compliance with other specifications</h4><p><i>This section is non-normative.</i></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 id="willful-violation">willful
|
|
violation</dfn>", and the reason for the violation has been
|
|
noted.</p><h3 id="html-vs-xhtml"><span class="secno">1.6 </span>HTML vs XHTML</h3><p><i>This section is non-normative.</i></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. This specification defines version 5 of DOM HTML, known
|
|
as "DOM5 HTML".</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 an <a href="infrastructure.html#html-mime-type">HTML MIME
|
|
type</a>, such as <code><a href="iana.html#text-html">text/html</a></code>, then it will be
|
|
processed as an HTML document by Web browsers.
|
|
|
|
|
|
This specification defines version 5 of the HTML syntax, known as
|
|
"HTML5".
|
|
|
|
</p><p>The second concrete syntax is the XHTML syntax, which is an
|
|
application of XML. When a document is transmitted with an <a href="infrastructure.html#xml-mime-type">XML
|
|
MIME type</a>, such as <code><a href="iana.html#application-xhtml-xml">application/xhtml+xml</a></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 of the XHTML syntax, known as
|
|
"XHTML5".
|
|
|
|
</p><p>The DOM, the HTML syntax, and XML 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 XML.
|
|
Similarly, documents that use the <code><a href="scripting-1.html#the-noscript-element">noscript</a></code> feature can
|
|
be represented using the HTML syntax, but cannot be represented with
|
|
the DOM or in XML. Comments that contain the string "<code title="">--></code>" can only be represented in the DOM, not in
|
|
the HTML and XML syntaxes.</p><h3 id="structure-of-this-specification"><span class="secno">1.7 </span>Structure of this specification</h3><p><i>This section is non-normative.</i></p><p>This specification is divided into the following major
|
|
sections:</p><dl><dt><a href="infrastructure.html#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.html#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.html#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="impl">, along with user agent requirements for how to handle
|
|
each element,</span> are also given.</dd>
|
|
|
|
|
|
<dt><a href="browsers.html#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.</dd>
|
|
|
|
<dt><a href="webappapis.html#webappapis">Web application APIs</a></dt>
|
|
|
|
<dd>This section introduces basic features for scripting of
|
|
applications in HTML.</dd>
|
|
|
|
<dt><a href="editing.html#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.</dd>
|
|
|
|
|
|
|
|
|
|
|
|
<dt><a href="syntax.html#syntax">The HTML syntax</a></dt>
|
|
<dt><a href="the-xhtml-syntax.html#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, along with rules for
|
|
how to parse content using those syntaxes.</dd>
|
|
|
|
|
|
</dl><p>There are also some appendices, defining <a href="rendering.html#rendering">rendering rules</a> for Web browsers and listing
|
|
<a href="obsolete.html#obsolete">obsolete features</a> and <a href="iana.html#iana">IANA
|
|
considerations</a>.</p><h4 id="how-to-read-this-specification"><span class="secno">1.7.1 </span>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><h4 id="typographic-conventions"><span class="secno">1.7.2 </span>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 title="">Example</dfn> {
|
|
// this is an IDL definition
|
|
};</pre><dl class="domintro"><dt><var title="">variable</var> = <var title="">object</var> . <code title="">method</code>( [ <var title="">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 id="x-this" title="x-this">this</dfn>. Uses of that term are marked up like
|
|
<a href="#x-this" title="x-this">this</a> or like <i title="x-this"><a href="#x-this">this</a></i>.</p><p>The defining instance of an element, attribute, or API is marked
|
|
up like <dfn id="x-that" title="x-that"><code>this</code></dfn>. References to
|
|
that element, attribute, or API are marked up like <code title="x-that"><a href="#x-that">this</a></code>.</p><p>Other code fragments are marked up <code title="">like
|
|
this</code>.</p><p>Variables are marked up like <var title="">this</var>.</p><p class="impl">This is an implementation requirement.</p><h3 id="a-quick-introduction-to-html"><span class="secno">1.8 </span>A quick introduction to HTML</h3><p><i>This section is non-normative.</i></p><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 <a href="syntax.html#syntax-start-tag" title="syntax-start-tag">start tag</a>, such as "<code title=""><body></code>", and an <a href="syntax.html#syntax-end-tag" title="syntax-end-tag">end
|
|
tag</a>, such as "<code title=""></body></code>". (Certain
|
|
start tags and end tags can in certain cases be <a href="syntax.html#syntax-tag-omission" title="syntax-tag-omission">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"><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><p>Elements can have attributes, which control how the elements
|
|
work. In the example below, there is a <a href="links.html#hyperlink">hyperlink</a>,
|
|
formed using the <code><a href="text-level-semantics.html#the-a-element">a</a></code> element and its <code title="attr-hyperlink-href"><a href="links.html#attr-hyperlink-href">href</a></code> attribute:</p><pre><a href="demo.html">simple</a></pre><p><a href="syntax.html#syntax-attributes" title="syntax-attributes">Attributes</a> are placed
|
|
inside the start tag, and consist of a <a href="syntax.html#syntax-attribute-name" title="syntax-attribute-name">name</a> and a <a href="syntax.html#syntax-attribute-value" title="syntax-attribute-value">value</a>, separated by an "<code title="">=</code>" character. The attribute value can remain <a href="syntax.html#unquoted">unquoted</a> if it doesn't contain spaces or any of
|
|
<code title="">"</code> <code title="">'</code> <code title="">`</code> <code title="">=</code> <code title=""><</code>
|
|
or <code title="">></code>. Otherwise, it has to be quoted using
|
|
either single or double quotes. The value, along with the "<code title="">=</code>" character, can be omitted altogether if the value
|
|
is the empty string.</p><pre><!-- empty attributes -->
|
|
<input name=address disabled>
|
|
<input name=address disabled="">
|
|
|
|
<!-- attributes with a value -->
|
|
<input name=address maxlength=200>
|
|
<input name=address maxlength='200'>
|
|
<input name=address maxlength="200"></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 DOCTYPE
|
|
node, elements, text nodes, and comment nodes.</p><p>The <a href="#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 title="">html</code></li><li class="t1"><code><a href="semantics.html#the-html-element">html</a></code><ul><li class="t1"><code><a href="semantics.html#the-head-element">head</a></code><ul><li class="t3"><code>#text</code>: <span title="">⏎␣␣</span></li><li class="t1"><code><a href="semantics.html#the-title-element">title</a></code><ul><li class="t3"><code>#text</code>: <span title="">Sample page</span></li></ul></li><li class="t3"><code>#text</code>: <span title="">⏎␣</span></li></ul></li><li class="t3"><code>#text</code>: <span title="">⏎␣</span></li><li class="t1"><code><a href="sections.html#the-body-element">body</a></code><ul><li class="t3"><code>#text</code>: <span title="">⏎␣␣</span></li><li class="t1"><code><a href="sections.html#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code><ul><li class="t3"><code>#text</code>: <span title="">Sample page</span></li></ul></li><li class="t3"><code>#text</code>: <span title="">⏎␣␣</span></li><li class="t1"><code><a href="grouping-content.html#the-p-element">p</a></code><ul><li class="t3"><code>#text</code>: <span title="">This is a </span></li><li class="t1"><code><a href="text-level-semantics.html#the-a-element">a</a></code> <span class="t2" title=""><code class="attribute name">href</code>="<code class="attribute value">demo.html</code>"</span><ul><li class="t3"><code>#text</code>: <span title="">simple</span></li></ul></li><li class="t3"><code>#text</code>: <span title=""> sample.</span></li></ul></li><li class="t3"><code>#text</code>: <span title="">⏎␣␣</span></li><li class="t8"><code>#comment</code>: <span title=""> this is a comment </span></li><li class="t3"><code>#text</code>: <span title="">⏎␣⏎</span></li></ul></li></ul></li></ul><p>The <a href="infrastructure.html#root-element">root element</a> of this tree is the
|
|
<code><a href="semantics.html#the-html-element">html</a></code> element, which is the element always found at the
|
|
root of HTML documents. It contains two elements, <code><a href="semantics.html#the-head-element">head</a></code>
|
|
and <code><a href="sections.html#the-body-element">body</a></code>, as well as a text node between them.</p><p>There are many more text nodes in the DOM tree than one would
|
|
initially expect, because the source contains a number of spaces
|
|
(represented here by "␣") and line breaks ("⏎") that
|
|
all end up as text nodes in the DOM. However, for historical reasons
|
|
not all of the spaces and line breaks in the original markup appear
|
|
in the DOM. In particular, all the whitespace before
|
|
<code><a href="semantics.html#the-head-element">head</a></code> start tag ends up being dropped silently, and all
|
|
the whitespace after the <code><a href="sections.html#the-body-element">body</a></code> end tag ends up placed at
|
|
the end of the <code><a href="sections.html#the-body-element">body</a></code>.</p><p>The <code><a href="semantics.html#the-head-element">head</a></code> element contains a <code><a href="semantics.html#the-title-element">title</a></code>
|
|
element, which itself contains a text node with the text "Sample
|
|
page". Similarly, the <code><a href="sections.html#the-body-element">body</a></code> element contains an
|
|
<code><a href="sections.html#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code> element, a <code><a href="grouping-content.html#the-p-element">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 href="scripting-1.html#the-script-element">script</a></code> element or using
|
|
<a href="webappapis.html#event-handler-content-attributes">event handler content attributes</a>. For example, here is
|
|
a form with a script that sets the value of the form's
|
|
<code><a href="the-button-element.html#the-output-element">output</a></code> element to say "Hello World":</p><pre><<a href="forms.html#the-form-element">form</a> <a href="forms.html#attr-form-name" title="attr-form-name">name</a>="main">
|
|
Result: <<a href="the-button-element.html#the-output-element">output</a> <a href="association-of-controls-and-forms.html#attr-fe-name" title="attr-fe-name">name</a>="result"></output>
|
|
<<a href="scripting-1.html#the-script-element">script</a>>
|
|
<a href="dom.html#htmldocument" title="HTMLDocument">document</a>.<a href="dom.html#dom-document-forms" title="dom-document-forms">forms</a>.main.<a href="forms.html#dom-form-elements" title="dom-form-elements">elements</a>.result.<a href="the-button-element.html#dom-output-value" title="dom-output-value">value</a> = 'Hello World';
|
|
</script>
|
|
</form></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 href="text-level-semantics.html#the-a-element">a</a></code> element in the tree above)
|
|
can have its "<code title="attr-hyperlink-href"><a href="links.html#attr-hyperlink-href">href</a></code>"
|
|
attribute changed in several ways:</p><pre>var a = <a href="dom.html#htmldocument" title="HTMLDocument">document</a>.<a href="dom.html#dom-document-links" title="dom-document-links">links</a>[0]; // obtain the first link in the document
|
|
a.<a href="text-level-semantics.html#dom-a-href" title="dom-a-href">href</a> = 'sample.html'; // change the destination URL of the link
|
|
a.<a href="urls.html#dom-uda-protocol" title="dom-uda-protocol">protocol</a> = 'https'; // change just the scheme part of the URL
|
|
a.setAttribute('href', 'http://example.com/'); // change the content attribute directly</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><!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<title>Sample styled page</title>
|
|
<style>
|
|
body { background: navy; color: yellow; }
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<h1>Sample styled page</h1>
|
|
<p>This page is just a demo.</p>
|
|
</body>
|
|
</html></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><h3 id="conformance-requirements-for-authors"><span class="secno">1.9 </span>Conformance requirements for authors</h3><p><i>This section is non-normative.</i></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 conforming
|
|
document and one with errors.</p><h4 id="presentational-markup"><span class="secno">1.9.1 </span>Presentational markup</h4><p><i>This section is non-normative.</i></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>The use of presentational elements leads to poorer accessibility</dt>
|
|
|
|
<dd>
|
|
|
|
<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>Higher cost of maintenance</dt>
|
|
|
|
<dd>
|
|
|
|
<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>Higher document sizes</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Presentational markup tends to be much more redundant, and thus
|
|
results in larger document sizes.</p>
|
|
|
|
</dd>
|
|
|
|
</dl><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 title="attr-style"><a href="elements.html#the-style-attribute">style</a></code> attribute and the
|
|
<code><a href="semantics.html#the-style-element">style</a></code> element. Use of the <code title="attr-style"><a href="elements.html#the-style-attribute">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 href="semantics.html#the-style-element">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 href="text-level-semantics.html#the-b-element">b</a></code>, <code><a href="text-level-semantics.html#the-i-element">i</a></code>, <code><a href="grouping-content.html#the-hr-element">hr</a></code>,
|
|
<code><a href="text-level-semantics.html#the-s-element">s</a></code>, <code><a href="text-level-semantics.html#the-small-element">small</a></code>, and <code><a href="text-level-semantics.html#the-u-element">u</a></code>.</p><h4 id="syntax-errors"><span class="secno">1.9.2 </span>Syntax errors</h4><p><i>This section is non-normative.</i></p><p>The syntax of HTML is constrained to avoid a wide variety of
|
|
problems.</p><dl><dt>Unintuitive error-handling behavior</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Certain invalid syntax constructs, when parsed, result in DOM
|
|
trees that are highly unintuitive.</p>
|
|
|
|
<div class="example">
|
|
|
|
<p>For example, the following markup fragment results in a DOM
|
|
with an <code><a href="grouping-content.html#the-hr-element">hr</a></code> element that is an <em>earlier</em>
|
|
sibling of the corresponding <code><a href="tabular-data.html#the-table-element">table</a></code> element:</p>
|
|
|
|
<pre class="bad"><table><hr>...</pre>
|
|
|
|
</div>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors with optional error recovery</dt>
|
|
|
|
<dd>
|
|
|
|
<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 href="parsing.html#parse-error">parse error</a>.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors where the error-handling behavior is not compatible with streaming user agents</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Some error-handling behavior, such as the behavior for the
|
|
<code title=""><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>Errors that can result in infoset coercion</dt>
|
|
|
|
<dd>
|
|
|
|
<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>Errors that result in disproportionally poor performance</dt>
|
|
|
|
<dd>
|
|
|
|
<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">
|
|
|
|
<p>For example, the following markup results in poor performance,
|
|
since all the unclosed <code><a href="text-level-semantics.html#the-i-element">i</a></code> elements have to be
|
|
reconstructed in each paragraph, resulting in progressively more
|
|
elements in each paragraph:</p>
|
|
|
|
<pre class="bad"><p><i>He dreamt.
|
|
<p><i>He dreamt that he ate breakfast.
|
|
<p><i>Then lunch.
|
|
<p><i>And finally dinner.</pre>
|
|
|
|
<p>The resulting DOM for this fragment would be:</p>
|
|
|
|
<ul class="domTree"><li class="t1"><code><a href="grouping-content.html#the-p-element">p</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t3"><code>#text</code>: <span title="">He dreamt.</span></li></ul></li></ul></li><li class="t1"><code><a href="grouping-content.html#the-p-element">p</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t3"><code>#text</code>: <span title="">He dreamt that he ate breakfast.</span></li></ul></li></ul></li></ul></li><li class="t1"><code><a href="grouping-content.html#the-p-element">p</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t3"><code>#text</code>: <span title="">Then lunch.</span></li></ul></li></ul></li></ul></li></ul></li><li class="t1"><code><a href="grouping-content.html#the-p-element">p</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t1"><code><a href="text-level-semantics.html#the-i-element">i</a></code><ul><li class="t3"><code>#text</code>: <span title="">And finally dinner.</span></li></ul></li></ul></li></ul></li></ul></li></ul></li></ul></div>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors involving fragile syntax constructs</dt>
|
|
|
|
<dd>
|
|
|
|
<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">
|
|
|
|
<p>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>
|
|
|
|
<p>In this fragment, the attribute's value is "<code title="">?bill&ted</code>":</p>
|
|
|
|
<pre class="bad"><a href="?bill&ted">Bill and Ted</a></pre>
|
|
|
|
<p>In the following fragment, however, the attribute's value is
|
|
actually "<code title="">?art©</code>", <em>not</em> the
|
|
intended "<code title="">?art&copy</code>", because even
|
|
without the final semicolon, "<code title="">&copy</code>" is
|
|
handled the same as "<code title="">&copy;</code>" and thus
|
|
gets interpreted as "<code title="">©</code>":</p>
|
|
|
|
<pre class="bad"><a href="?art&copy">Art and Copy</a></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><a href="?bill&ted">Bill and Ted</a> <!-- &ted is ok, since it's not a named character reference --></pre>
|
|
<pre><a href="?art&amp;copy">Art and Copy</a> <!-- the & has to be escaped, since &copy <em>is</em> a named character reference --></pre>
|
|
|
|
</div>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors involving known interoperability problems in legacy user agents</dt>
|
|
|
|
<dd>
|
|
|
|
<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>
|
|
|
|
<div class="example">
|
|
|
|
<p>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>
|
|
|
|
</div>
|
|
|
|
<div class="example">
|
|
|
|
<p>Another example of this is the DOCTYPE, which is required to
|
|
trigger <a href="dom.html#no-quirks-mode">no-quirks mode</a>, because the behavior of
|
|
legacy user agents in <a href="dom.html#quirks-mode">quirks mode</a> is often largely
|
|
undocumented.</p>
|
|
|
|
</div>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that risk exposing authors to security attacks</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Certain restrictions exist purely to avoid known security
|
|
problems.</p>
|
|
|
|
<div class="example">
|
|
|
|
<p>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.</p>
|
|
|
|
</div>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Cases where the author's intent is unclear</dt>
|
|
|
|
<dd>
|
|
|
|
<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">
|
|
|
|
<p>For example, it is unclear whether the author intended the
|
|
following to be an <code><a href="sections.html#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code> heading or an <code><a href="sections.html#the-h1-h2-h3-h4-h5-and-h6-elements">h2</a></code>
|
|
heading:</p>
|
|
|
|
<pre class="bad"><h1>Contact details</h2></pre>
|
|
|
|
</div>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Cases that are likely to be typos</dt>
|
|
|
|
<dd>
|
|
|
|
<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>
|
|
|
|
<div class="example">
|
|
|
|
<p>For example, if the author typed <code><capton></code>
|
|
instead of <code><caption></code>, this would be flagged as an
|
|
error and the author could correct the typo immediately.</p>
|
|
|
|
</div>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that could interfere with new syntax in the future</dt>
|
|
|
|
<dd>
|
|
|
|
<p>In order to allow the language syntax to be extended in the
|
|
future, certain otherwise harmless features are disallowed.</p>
|
|
|
|
<div class="example">
|
|
|
|
<p>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>
|
|
|
|
</div>
|
|
|
|
</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 id="restrictions-on-content-models-and-on-attribute-values"><span class="secno">1.9.3 </span>Restrictions on content models and on attribute values</h4><p><i>This section is non-normative.</i></p><p>Beyond the syntax of the language, this specification also places
|
|
restrictions on how elements and attributes can be specified. These
|
|
restrictions are present for similar reasons:</p><dl><dt>Errors involving content with dubious semantics</dt>
|
|
|
|
<dd>
|
|
|
|
<p>To avoid misuse of elements with defined meanings, content
|
|
models are defined that restrict how elements can be nested when
|
|
such nestings would be of dubious value.</p>
|
|
|
|
<p class="example">For example, this specification disallows
|
|
nesting a <code><a href="sections.html#the-section-element">section</a></code> element inside a <code><a href="text-level-semantics.html#the-kbd-element">kbd</a></code>
|
|
element, since it is highly unlikely for an author to indicate
|
|
that an entire section should be keyed in.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that involve a conflict in expressed semantics</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Similarly, to draw the author's attention to mistakes in the
|
|
use of elements, clear contradictions in the semantics expressed
|
|
are also considered conformance errors.</p>
|
|
|
|
<div class="example">
|
|
|
|
<p>In the fragments below, for example, the semantics are
|
|
nonsensical: a separator cannot simultaneously be a cell, nor can
|
|
a radio button be a progress bar.</p>
|
|
|
|
<pre class="bad"><hr role="cell"></pre>
|
|
<pre class="bad"><input type=radio role=progressbar></pre>
|
|
|
|
</div>
|
|
|
|
<p class="example">Another example is the restrictions on the
|
|
content models of the <code><a href="grouping-content.html#the-ul-element">ul</a></code> element, which only allows
|
|
<code><a href="grouping-content.html#the-li-element">li</a></code> element children. Lists by definition consist just
|
|
of zero or more list items, so if a <code><a href="grouping-content.html#the-ul-element">ul</a></code> element
|
|
contains something other than an <code><a href="grouping-content.html#the-li-element">li</a></code> element, it's not
|
|
clear what was meant.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Cases where the default styles are likely to lead to confusion</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Certain elements have default styles or behaviors that make
|
|
certain combinations likely to lead to confusion. Where these have
|
|
equivalent alternatives without this problem, the confusing
|
|
combinations are disallowed.</p>
|
|
|
|
<p class="example">For example, <code><a href="grouping-content.html#the-div-element">div</a></code> elements are
|
|
rendered as block boxes, and <code><a href="text-level-semantics.html#the-span-element">span</a></code> elements as inline
|
|
boxes. Putting a block box in an inline box is unnecessarily
|
|
confusing; since either nesting just <code><a href="grouping-content.html#the-div-element">div</a></code> elements, or
|
|
nesting just <code><a href="text-level-semantics.html#the-span-element">span</a></code> elements, or nesting
|
|
<code><a href="text-level-semantics.html#the-span-element">span</a></code> elements inside <code><a href="grouping-content.html#the-div-element">div</a></code> elements all
|
|
serve the same purpose as nesting a <code><a href="grouping-content.html#the-div-element">div</a></code> element in a
|
|
<code><a href="text-level-semantics.html#the-span-element">span</a></code> element, but only the latter involves a block
|
|
box in an inline box, the latter combination is disallowed.</p>
|
|
|
|
<p class="example">Another example would be the way
|
|
<a href="content-models.html#interactive-content">interactive content</a> cannot be nested. For example, a
|
|
<code><a href="the-button-element.html#the-button-element">button</a></code> element cannot contain a <code><a href="the-button-element.html#the-textarea-element">textarea</a></code>
|
|
element. This is because the default behavior of such nesting
|
|
interactive elements would be highly confusing to users. Instead
|
|
of nesting these elements, they can be placed side by side.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that indicate a likely misunderstanding of the specification</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Sometimes, something is disallowed because allowing it would
|
|
likely cause author confusion.</p>
|
|
|
|
<p class="example">For example, setting the <code title="attr-fe-disabled"><a href="association-of-controls-and-forms.html#attr-fe-disabled">disabled</a></code> attribute to the value
|
|
"<code title="">false</code>" is disallowed, because despite the
|
|
appearance of meaning that the element is enabled, it in fact
|
|
means that the element is <em>disabled</em> (what matters for
|
|
implementations is the presence of the attribute, not its
|
|
value).</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors involving limits that have been imposed merely to simplify the language</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Some conformance errors simplify the language that authors need
|
|
to learn.</p>
|
|
|
|
<p class="example">For example, the <code><a href="the-map-element.html#the-area-element">area</a></code> element's
|
|
<code title="attr-area-shape"><a href="the-map-element.html#attr-area-shape">shape</a></code> attribute, despite
|
|
accepting both <code title="attr-area-shape-keyword-circ"><a href="the-map-element.html#attr-area-shape-keyword-circ">circ</a></code> and <code title="attr-area-shape-keyword-circle"><a href="the-map-element.html#attr-area-shape-keyword-circle">circle</a></code> values in
|
|
practice as synonyms, disallows the use of the <code title="attr-area-shape-keyword-circ"><a href="the-map-element.html#attr-area-shape-keyword-circ">circ</a></code> value, so as to
|
|
simplify tutorials and other learning aids. There would be no
|
|
benefit to allowing both, but it would cause extra confusion when
|
|
teaching the language.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that involve peculiarities of the parser</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Certain elements are parsed in somewhat eccentric ways
|
|
(typically for historical reasons), and their content model
|
|
restrictions are intended to avoid exposing the author to these
|
|
issues.</p>
|
|
|
|
<div class="example">
|
|
|
|
<p>For example, a <code><a href="forms.html#the-form-element">form</a></code> element isn't allowed inside
|
|
<a href="content-models.html#phrasing-content">phrasing content</a>, because when parsed as HTML, a
|
|
<code><a href="forms.html#the-form-element">form</a></code> element's start tag will imply a <code><a href="grouping-content.html#the-p-element">p</a></code>
|
|
element's end tag. Thus, the following markup results in two
|
|
<a href="content-models.html#paragraph" title="paragraph">paragraphs</a>, not one:</p>
|
|
|
|
<pre><p>Welcome. <form><label>Name:</label> <input></form></pre>
|
|
|
|
<p>It is parsed exactly like the following:</p>
|
|
|
|
<pre><p>Welcome. </p><form><label>Name:</label> <input></form></pre>
|
|
|
|
</div>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that would likely result in scripts failing in hard-to-debug ways</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Some errors are intended to help prevent script problems that
|
|
would be hard to debug.</p>
|
|
|
|
<p class="example">This is why, for instance, it is non-conforming
|
|
to have two <code title="attr-id"><a href="elements.html#the-id-attribute">id</a></code> attributes with the
|
|
same value. Duplicate IDs lead to the wrong element being
|
|
selected, with sometimes disastrous effects whose cause is hard to
|
|
determine.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that waste authoring time</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Some constructs are disallowed because historically they have
|
|
been the cause of a lot of wasted authoring time, and by
|
|
encouraging authors to avoid making them, authors can save time in
|
|
future efforts.</p>
|
|
|
|
<p class="example">For example, a <code><a href="scripting-1.html#the-script-element">script</a></code> element's
|
|
<code title="attr-script-src"><a href="scripting-1.html#attr-script-src">src</a></code> attribute causes the
|
|
element's contents to be ignored. However, this isn't obvious,
|
|
especially if the element's contents appear to be executable
|
|
script — which can lead to authors spending a lot of time
|
|
trying to debug the inline script without realizing that it is not
|
|
executing. To reduce this problem, this specification makes it
|
|
non-conforming to have executable script in a <code><a href="scripting-1.html#the-script-element">script</a></code>
|
|
element when the <code title="attr-script-src"><a href="scripting-1.html#attr-script-src">src</a></code>
|
|
attribute is present. This means that authors who are validating
|
|
their documents are less likely to waste time with this kind of
|
|
mistake.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that involve areas that affect authors migrating to and from XHTML</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Some authors like to write files that can be interpreted as
|
|
both XML and HTML with similar results. Though this practice is
|
|
discouraged in general due to the myriad of subtle complications
|
|
involved (especially when involving scripting, styling, or any
|
|
kind of automated serialization), this specification has a few
|
|
restrictions intended to at least somewhat mitigate the
|
|
difficulties. This makes it easier for authors to use this as a
|
|
transitionary step when migrating between HTML and XHTML.</p>
|
|
|
|
<p class="example">For example, there are somewhat complicated
|
|
rules surrounding the <code title="attr-lang"><a href="elements.html#attr-lang">lang</a></code> and
|
|
<code title="attr-xml-lang"><a href="elements.html#attr-xml-lang">xml:lang</a></code> attributes intended
|
|
to keep the two synchronized.</p>
|
|
|
|
<p class="example">Another example would be the restrictions on
|
|
the values of <code title="">xmlns</code> attributes in the HTML
|
|
serialization, which are intended to ensure that elements in
|
|
conforming documents end up in the same namespaces whether
|
|
processed as HTML or XML.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that involve areas reserved for future expansion</dt>
|
|
|
|
<dd>
|
|
|
|
<p>As with the restrictions on the syntax intended to allow for
|
|
new syntax in future revisions of the language, some restrictions
|
|
on the content models of elements and values of attributes are
|
|
intended to allow for future expansion of the HTML vocabulary.</p>
|
|
|
|
<p class="example">For example, limiting the values of the <code title="attr-hyperlink-target"><a href="links.html#attr-hyperlink-target">target</a></code> attribute that start
|
|
with an U+005F LOW LINE character (_) to only specific predefined
|
|
values allows new predefined values to be introduced at a future
|
|
time without conflicting with author-defined values.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Errors that indicate a mis-use of other specifications</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Certain restrictions are intended to support the restrictions
|
|
made by other specifications.</p>
|
|
|
|
<p class="example">For example, requiring that attributes that
|
|
take media queries use only <em>valid</em> media queries
|
|
reinforces the importance of following the conformance rules of
|
|
that specification.</p>
|
|
|
|
</dd>
|
|
|
|
</dl><h3 id="recommended-reading"><span class="secno">1.10 </span>Recommended reading</h3><p><i>This section is non-normative.</i></p><p>The following documents might be of interest to readers of this
|
|
specification.</p><dl><dt><cite>Character Model for the World Wide Web 1.0: Fundamentals</cite> <a href="references.html#refsCHARMOD">[CHARMOD]</a></dt>
|
|
|
|
<dd><blockquote><p>This Architectural Specification provides
|
|
authors of specifications, software developers, and content
|
|
developers with a common reference for interoperable text
|
|
manipulation on the World Wide Web, building on the Universal
|
|
Character Set, defined jointly by the Unicode Standard and ISO/IEC
|
|
10646. Topics addressed include use of the terms 'character',
|
|
'encoding' and 'string', a reference processing model, choice and
|
|
identification of character encodings, character escaping, and
|
|
string indexing.</p></blockquote></dd>
|
|
|
|
<dt><cite>Unicode Security Considerations</cite> <a href="references.html#refsUTR36">[UTR36]</a></dt>
|
|
|
|
<dd><blockquote><p>Because Unicode contains such a large number of
|
|
characters and incorporates the varied writing systems of the
|
|
world, incorrect usage can expose programs or systems to possible
|
|
security attacks. This is especially important as more and more
|
|
products are internationalized. This document describes some of the
|
|
security considerations that programmers, system analysts,
|
|
standards developers, and users should take into account, and
|
|
provides specific recommendations to reduce the risk of
|
|
problems.</p></blockquote></dd>
|
|
|
|
<dt><cite>Web Content Accessibility Guidelines (WCAG) 2.0</cite> <a href="references.html#refsWCAG">[WCAG]</a></dt>
|
|
|
|
<dd><blockquote><p>Web Content Accessibility Guidelines (WCAG) 2.0
|
|
covers a wide range of recommendations for making Web content more
|
|
accessible. Following these guidelines will make content accessible
|
|
to a wider range of people with disabilities, including blindness
|
|
and low vision, deafness and hearing loss, learning disabilities,
|
|
cognitive limitations, limited movement, speech disabilities,
|
|
photosensitivity and combinations of these. Following these
|
|
guidelines will also often make your Web content more usable to
|
|
users in general.</p></blockquote></dd>
|
|
|
|
<dt class="impl"><cite>Authoring Tool Accessibility Guidelines (ATAG) 2.0</cite> <a href="references.html#refsATAG">[ATAG]</a></dt>
|
|
|
|
<dd class="impl"><blockquote><p>This specification provides
|
|
guidelines for designing Web content authoring tools that are more
|
|
accessible for people with disabilities. An authoring tool that
|
|
conforms to these guidelines will promote accessibility by
|
|
providing an accessible user interface to authors with disabilities
|
|
as well as by enabling, supporting, and promoting the production of
|
|
accessible Web content by all authors.</p></blockquote></dd>
|
|
|
|
<dt class="impl"><cite>User Agent Accessibility Guidelines (UAAG) 2.0</cite> <a href="references.html#refsUAAG">[UAAG]</a></dt>
|
|
|
|
<dd class="impl"><blockquote><p>This document provides guidelines
|
|
for designing user agents that lower barriers to Web accessibility
|
|
for people with disabilities. User agents include browsers and
|
|
other types of software that retrieve and render Web content. A
|
|
user agent that conforms to these guidelines will promote
|
|
accessibility through its own user interface and through other
|
|
internal facilities, including its ability to communicate with
|
|
other technologies (especially assistive
|
|
technologies). Furthermore, all users, not just users with
|
|
disabilities, should find conforming user agents to be more
|
|
usable.</p></blockquote></dd>
|
|
|
|
<dt><cite>Polyglot Markup: HTML-Compatible XHTML Documents</cite> <a href="references.html#refsPOLYGLOT">[POLYGLOT]</a></dt>
|
|
|
|
<dd><blockquote><p>A document that uses polyglot markup is a document
|
|
that is a stream of bytes that parses into identical document trees
|
|
(with the exception of the xmlns attribute on the root element)
|
|
when processed as HTML and when processed as XML. Polyglot markup
|
|
that meets a well defined set of constraints is interpreted as
|
|
compatible, regardless of whether they are processed as HTML or as
|
|
XHTML, per the HTML5 specification. Polyglot markup uses a specific
|
|
DOCTYPE, namespace declarations, and a specific case —
|
|
normally lower case but occasionally camel case — for element
|
|
and attribute names. Polyglot markup uses lower case for certain
|
|
attribute values. Further constraints include those on empty
|
|
elements, named entity references, and the use of scripts and
|
|
style.</p></blockquote></dd>
|
|
|
|
<dt><cite>HTML to Platform Accessibility APIs Implementation Guide</cite> <a href="references.html#refsHPAAIG">[HPAAIG]</a></dt>
|
|
|
|
<dd><blockquote><p>This is draft documentation mapping HTML
|
|
elements and attributes to accessibility API Roles, States and
|
|
Properties on a variety of platforms. It provides recommendations
|
|
on deriving the accessible names and descriptions for HTML
|
|
elements. It also provides accessible feature implementation
|
|
examples.</p></blockquote></dd>
|
|
|
|
</dl></body></html>
|