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.
1369 lines
78 KiB
1369 lines
78 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>2 Common infrastructure — 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="introduction.html" title="1 Introduction" rel="prev">
|
|
<link href="spec.html#contents" title="Table of contents" rel="index">
|
|
<link href="common-microsyntaxes.html" title="2.5 Common microsyntaxes" 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="introduction.html" class="prev">1 Introduction</a> –
|
|
<a href="spec.html#contents">Table of contents</a> –
|
|
<a href="common-microsyntaxes.html" class="next">2.5 Common microsyntaxes</a>
|
|
<ol class="toc"><li><a href="infrastructure.html#infrastructure"><span class="secno">2 </span>Common infrastructure</a>
|
|
<ol><li><a href="infrastructure.html#terminology"><span class="secno">2.1 </span>Terminology</a>
|
|
<ol><li><a href="infrastructure.html#resources"><span class="secno">2.1.1 </span>Resources</a></li><li><a href="infrastructure.html#xml"><span class="secno">2.1.2 </span>XML</a></li><li><a href="infrastructure.html#dom-trees"><span class="secno">2.1.3 </span>DOM trees</a></li><li><a href="infrastructure.html#scripting-0"><span class="secno">2.1.4 </span>Scripting</a></li><li><a href="infrastructure.html#plugins"><span class="secno">2.1.5 </span>Plugins</a></li><li><a href="infrastructure.html#character-encodings"><span class="secno">2.1.6 </span>Character encodings</a></li></ol></li><li><a href="infrastructure.html#conformance-requirements"><span class="secno">2.2 </span>Conformance requirements</a>
|
|
<ol><li><a href="infrastructure.html#conformance-classes"><span class="secno">2.2.1 </span>Conformance classes</a></li><li><a href="infrastructure.html#dependencies"><span class="secno">2.2.2 </span>Dependencies</a></li><li><a href="infrastructure.html#extensibility"><span class="secno">2.2.3 </span>Extensibility</a></li></ol></li><li><a href="infrastructure.html#case-sensitivity-and-string-comparison"><span class="secno">2.3 </span>Case-sensitivity and string comparison</a></li><li><a href="infrastructure.html#utf-8"><span class="secno">2.4 </span>UTF-8</a></li></ol></li></ol></div>
|
|
|
|
<h2 id="infrastructure"><span class="secno">2 </span>Common infrastructure</h2><h3 id="terminology"><span class="secno">2.1 </span>Terminology</h3><p>This specification refers to both HTML and XML attributes and IDL
|
|
attributes, often in the same context. When it is not clear which is
|
|
being referred to, they are referred to as <dfn title="">content
|
|
attributes</dfn> for HTML and XML attributes, and <dfn title="">IDL
|
|
attributes</dfn> for those defined on IDL interfaces. Similarly, the
|
|
term "properties" is used for both JavaScript object properties and
|
|
CSS properties. When these are ambiguous they are qualified as <dfn title="">object properties</dfn> and <dfn title="">CSS
|
|
properties</dfn> respectively.</p><p>Generally, when the specification states that a feature applies
|
|
to <a href="syntax.html#syntax">the HTML syntax</a> or <a href="the-xhtml-syntax.html#the-xhtml-syntax">the XHTML syntax</a>, it
|
|
also includes the other. When a feature specifically only applies to
|
|
one of the two languages, it is called out by explicitly stating
|
|
that it does not apply to the other format, as in "for HTML,
|
|
... (this does not apply to XHTML)".</p><p>This specification uses the term <dfn title="">document</dfn> to
|
|
refer to any use of HTML, ranging from short static documents to
|
|
long essays or reports with rich multimedia, as well as to
|
|
fully-fledged interactive applications.</p><p>For simplicity, terms such as <dfn title="">shown</dfn>, <dfn title="">displayed</dfn>, and <dfn title="">visible</dfn> might
|
|
sometimes be used when referring to the way a document is rendered
|
|
to the user. These terms are not meant to imply a visual medium;
|
|
they must be considered to apply to other media in equivalent
|
|
ways.</p><div class="impl">
|
|
|
|
<p>When an algorithm B says to return to another algorithm A, it
|
|
implies that A called B. Upon returning to A, the implementation
|
|
must continue from where it left off in calling B.</p>
|
|
|
|
</div><p>The term "transparent black" refers to the color with red, green,
|
|
blue, and alpha channels all set to zero.</p><h4 id="resources"><span class="secno">2.1.1 </span>Resources</h4><p>The specification uses the term <dfn title="">supported</dfn>
|
|
when referring to whether a user agent has an implementation capable
|
|
of decoding the semantics of an external resource. A format or type
|
|
is said to be <i>supported</i> if the implementation can process an
|
|
external resource of that format or type without critical aspects of
|
|
the resource being ignored. Whether a specific resource is
|
|
<i>supported</i> can depend on what features of the resource's
|
|
format are in use.</p><p class="example">For example, a PNG image would be considered to
|
|
be in a supported format if its pixel data could be decoded and
|
|
rendered, even if, unbeknownst to the implementation, the image also
|
|
contained animation data.</p><p class="example">A MPEG4 video file would not be considered to be
|
|
in a supported format if the compression format used was not
|
|
supported, even if the implementation could determine the dimensions
|
|
of the movie from the file's metadata.</p><p>What some specifications, in particular the HTTP and URI
|
|
specifications, refer to as a <i>representation</i> is referred to
|
|
in this specification as a <dfn title="">resource</dfn>. <a href="references.html#refsHTTP">[HTTP]</a> <a href="references.html#refsRFC3986">[RFC3986]</a></p><p>The term <dfn id="mime-type">MIME type</dfn> is used to refer to what is
|
|
sometimes called an <i>Internet media type</i> in protocol
|
|
literature. The term <i>media type</i> in this specification is used
|
|
to refer to the type of media intended for presentation, as used by
|
|
the CSS specifications. <a href="references.html#refsRFC2046">[RFC2046]</a> <a href="references.html#refsMQ">[MQ]</a></p><p>A string is a <dfn id="valid-mime-type">valid MIME type</dfn> if it matches the <code title="">media-type</code> rule defined in section 3.7 "Media Types"
|
|
of RFC 2616. In particular, a <a href="#valid-mime-type">valid MIME type</a> may
|
|
include MIME type parameters. <a href="references.html#refsHTTP">[HTTP]</a></p><p>A string is a <dfn id="valid-mime-type-with-no-parameters">valid MIME type with no parameters</dfn> if it
|
|
matches the <code title="">media-type</code> rule defined in section
|
|
3.7 "Media Types" of RFC 2616, but does not contain any U+003B
|
|
SEMICOLON characters (;). In other words, if it consists only of a
|
|
type and subtype, with no MIME Type parameters. <a href="references.html#refsHTTP">[HTTP]</a></p><p>The term <dfn id="html-mime-type">HTML MIME type</dfn> is used to refer to the <a href="#mime-type" title="MIME type">MIME types</a> <code><a href="iana.html#text-html">text/html</a></code> and
|
|
<code><a href="iana.html#text-html-sandboxed">text/html-sandboxed</a></code>.</p><p>A resource's <dfn id="critical-subresources">critical subresources</dfn> are those that the
|
|
resource needs to have available to be correctly processed. Which
|
|
resources are considered critical or not is defined by the
|
|
specification that defines the resource's format. For CSS resources,
|
|
only <code title="">@import</code> rules introduce <a href="#critical-subresources">critical
|
|
subresources</a>; other resources, e.g. fonts or backgrounds, are
|
|
not.</p><p>The term <dfn id="data-protocol" title="data protocol"><code title="">data:</code>
|
|
URL</dfn> refers to <a href="urls.html#url" title="URL">URLs</a> that use the <code title="">data:</code> scheme. <a href="references.html#refsRFC2397">[RFC2397]</a></p><h4 id="xml"><span class="secno">2.1.2 </span>XML</h4><p id="html-namespace">To ease migration from HTML to XHTML, UAs
|
|
conforming to this specification will place elements in HTML in the
|
|
<code>http://www.w3.org/1999/xhtml</code> namespace, at least for
|
|
the purposes of the DOM and CSS. The term "<dfn id="html-elements">HTML
|
|
elements</dfn>", when used in this specification, refers to any
|
|
element in that namespace, and thus refers to both HTML and XHTML
|
|
elements.</p><p>Except where otherwise stated, all elements defined or mentioned
|
|
in this specification are in the
|
|
<code>http://www.w3.org/1999/xhtml</code> namespace, and all
|
|
attributes defined or mentioned in this specification have no
|
|
namespace.</p><p>Attribute names are said to be <dfn id="xml-compatible">XML-compatible</dfn> if they
|
|
match the <a href="http://www.w3.org/TR/REC-xml/#NT-Name"><code title="">Name</code></a> production defined in XML, they contain no
|
|
U+003A COLON characters (:), and their first three characters are
|
|
not an <a href="#ascii-case-insensitive">ASCII case-insensitive</a> match for the string
|
|
"<code title="">xml</code>". <a href="references.html#refsXML">[XML]</a></p><p>The term <dfn id="xml-mime-type">XML MIME type</dfn> is used to refer to the <a href="#mime-type" title="MIME type">MIME types</a> <code title="">text/xml</code>,
|
|
<code title="">application/xml</code>, and any <a href="#mime-type">MIME
|
|
type</a> whose subtype ends with the four characters "<code title="">+xml</code>". <a href="references.html#refsRFC3023">[RFC3023]</a></p><h4 id="dom-trees"><span class="secno">2.1.3 </span>DOM trees</h4><p>The <dfn id="root-element-of-a-document-object">root element of a <code>Document</code> object</dfn> is
|
|
that <code><a href="#document">Document</a></code>'s first element child, if any. If it does
|
|
not have one then the <code><a href="#document">Document</a></code> has no root element.</p><p>The term <dfn id="root-element">root element</dfn>, when not referring to a
|
|
<code><a href="#document">Document</a></code> object's root element, means the furthest
|
|
ancestor element node of whatever node is being discussed, or the
|
|
node itself if it has no ancestors. When the node is a part of the
|
|
document, then the node's <a href="#root-element">root element</a> is indeed the
|
|
document's root element; however, if the node is not currently part
|
|
of the document tree, the root element will be an orphaned node.</p><p>When an element's <a href="#root-element">root element</a> is the <a href="#root-element-of-a-document-object">root
|
|
element of a <code>Document</code> object</a>, it is said to be
|
|
<dfn id="in-a-document">in a <code>Document</code></dfn>. An element is said to have
|
|
been <dfn id="insert-an-element-into-a-document" title="insert an element into a document">inserted into a
|
|
document</dfn> when its <a href="#root-element">root element</a> changes and is now
|
|
the document's <a href="#root-element">root element</a>. Analogously, an element is
|
|
said to have been <dfn id="remove-an-element-from-a-document" title="remove an element from a
|
|
document">removed from a document</dfn> when its <a href="#root-element">root
|
|
element</a> changes from being the document's <a href="#root-element">root
|
|
element</a> to being another element.</p><p>A node's <dfn id="home-subtree">home subtree</dfn> is the subtree rooted at that
|
|
node's <a href="#root-element">root element</a>. When a node is <a href="#in-a-document">in a
|
|
<code>Document</code></a>, its <a href="#home-subtree">home subtree</a> is that
|
|
<code><a href="#document">Document</a></code>'s tree.</p><p>The <code><a href="#document">Document</a></code> of a <code><a href="#node">Node</a></code> (such as an
|
|
element) is the <code><a href="#document">Document</a></code> that the <code><a href="#node">Node</a></code>'s
|
|
<code title="dom-Node-ownerDocument"><a href="#dom-node-ownerdocument">ownerDocument</a></code> IDL
|
|
attribute returns. When a <code><a href="#node">Node</a></code> is <a href="#in-a-document">in a
|
|
<code>Document</code></a> then that <code><a href="#document">Document</a></code> is
|
|
always the <code><a href="#node">Node</a></code>'s <code><a href="#document">Document</a></code>, and the
|
|
<code><a href="#node">Node</a></code>'s <code title="dom-Node-ownerDocument"><a href="#dom-node-ownerdocument">ownerDocument</a></code> IDL attribute
|
|
thus always returns that <code><a href="#document">Document</a></code>.</p><p>The term <dfn id="tree-order">tree order</dfn> means a pre-order, depth-first
|
|
traversal of DOM nodes involved (through the <code title="dom-Node-parentNode"><a href="#dom-node-parentnode">parentNode</a></code>/<code title="dom-Node-childNodes"><a href="#dom-node-childnodes">childNodes</a></code> relationship).</p><p>When it is stated that some element or attribute is <dfn id="ignore" title="ignore">ignored</dfn>, or treated as some other value, or
|
|
handled as if it was something else, this refers only to the
|
|
processing of the node after it is in the DOM. <span class="impl">A
|
|
user agent must not mutate the DOM in such situations.</span></p><p>The term <dfn id="text-node">text node</dfn> refers to any <code><a href="#text">Text</a></code>
|
|
node, including <code><a href="#cdatasection">CDATASection</a></code> nodes; specifically, any
|
|
<code><a href="#node">Node</a></code> with node type <code title="">TEXT_NODE</code> (3)
|
|
or <code title="">CDATA_SECTION_NODE</code> (4). <a href="references.html#refsDOMCORE">[DOMCORE]</a></p><p>A content attribute is said to <dfn title="">change</dfn> value
|
|
only if its new value is different than its previous value; setting
|
|
an attribute to a value it already has does not change it.</p><p>The term <dfn title="">empty</dfn>, when used of an attribute
|
|
value, text node, or string, means that the length of the text is
|
|
zero (i.e. not even containing spaces or control characters).</p><p>Nodes can be <dfn id="concept-clone" title="concept-clone">cloned</dfn>, as
|
|
described in the DOM Core specification. For example, the <code title="dom-cloneNode">cloneNode()</code> and <code title="dom-importNode">importNode()</code> methods of the
|
|
<code><a href="#node">Node</a></code> interface both clone nodes, as do a number of
|
|
algorithms in this specification. Certain <a href="#html-elements">HTML elements</a>
|
|
(in particular, <code><a href="the-input-element.html#the-input-element">input</a></code> and <code><a href="scripting-1.html#the-script-element">script</a></code>) apply
|
|
additional requirements on how they are cloned. <a href="references.html#refsDOMCORE">[DOMCORE]</a></p><h4 id="scripting-0"><span class="secno">2.1.4 </span>Scripting</h4><p>The construction "a <code>Foo</code> object", where
|
|
<code>Foo</code> is actually an interface, is sometimes used instead
|
|
of the more accurate "an object implementing the interface
|
|
<code>Foo</code>".</p><p>An IDL attribute is said to be <dfn title="">getting</dfn> when
|
|
its value is being retrieved (e.g. by author script), and is said to
|
|
be <dfn title="">setting</dfn> when a new value is assigned to
|
|
it.</p><p>If a DOM object is said to be <dfn id="live">live</dfn>, then the
|
|
attributes and methods on that object <span class="impl">must</span>
|
|
operate on the actual underlying data, not a snapshot of the
|
|
data.</p><p>The terms <dfn title="">fire</dfn> and <dfn title="">dispatch</dfn> are used interchangeably in the context of
|
|
events, as in the DOM Events specifications. The term <dfn id="concept-events-trusted" title="concept-events-trusted">trusted event</dfn> is used as
|
|
defined by the DOM Events specification. <a href="references.html#refsDOMEVENTS">[DOMEVENTS]</a></p><h4 id="plugins"><span class="secno">2.1.5 </span>Plugins</h4><p>The term <dfn id="plugin">plugin</dfn> refers to a user-agent defined set of
|
|
content handlers used by the user agent that can take part in the
|
|
user agent's rendering of a <code><a href="#document">Document</a></code> object, but that
|
|
neither act as <a href="browsers.html#child-browsing-context" title="child browsing context">child browsing
|
|
contexts</a> of the <code><a href="#document">Document</a></code> nor introduce any
|
|
<code><a href="#node">Node</a></code> objects to the <code><a href="#document">Document</a></code>'s DOM.</p><p>Typically such content handlers are provided by third parties,
|
|
though a user agent can also designate built-in content handlers as
|
|
plugins.</p><div class="impl">
|
|
|
|
<p>A user agent must not consider the types <code>text/plain</code>
|
|
and <code>application/octet-stream</code> as having a registered
|
|
<a href="#plugin">plugin</a>.</p>
|
|
</div><p class="example">One example of a plugin would be a PDF viewer
|
|
that is instantiated in a <a href="browsers.html#browsing-context">browsing context</a> when the
|
|
user navigates to a PDF file. This would count as a plugin
|
|
regardless of whether the party that implemented the PDF viewer
|
|
component was the same as that which implemented the user agent
|
|
itself. However, a PDF viewer application that launches separate
|
|
from the user agent (as opposed to using the same interface) is not
|
|
a plugin by this definition.</p><p class="note">This specification does not define a mechanism for
|
|
interacting with plugins, as it is expected to be user-agent- and
|
|
platform-specific. Some UAs might opt to support a plugin mechanism
|
|
such as the Netscape Plugin API; others might use remote content
|
|
converters or have built-in support for certain types. Indeed, this
|
|
specification doesn't require user agents to support plugins at all.
|
|
<a href="references.html#refsNPAPI">[NPAPI]</a></p><div class="impl">
|
|
|
|
<p class="warning">Browsers should take extreme care when
|
|
interacting with external content intended for <a href="#plugin" title="plugin">plugins</a>. When third-party software is run with
|
|
the same privileges as the user agent itself, vulnerabilities in the
|
|
third-party software become as dangerous as those in the user
|
|
agent.</p>
|
|
|
|
</div><h4 id="character-encodings"><span class="secno">2.1.6 </span>Character encodings</h4><p>The <dfn id="preferred-mime-name">preferred MIME name</dfn> of a character encoding is the
|
|
name or alias labeled as "preferred MIME name" in the IANA
|
|
<cite>Character Sets</cite> registry, if there is one, or the
|
|
encoding's name, if none of the aliases are so labeled. <a href="references.html#refsIANACHARSET">[IANACHARSET]</a></p><p>An <dfn id="ascii-compatible-character-encoding">ASCII-compatible character encoding</dfn> is a
|
|
single-byte or variable-length encoding in which the bytes 0x09,
|
|
0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A,
|
|
and 0x61 - 0x7A, ignoring bytes that
|
|
are the second and later bytes of multibyte sequences, all
|
|
correspond to single-byte sequences that map to the same Unicode
|
|
characters as those bytes in ANSI_X3.4-1968 (US-ASCII). <a href="references.html#refsRFC1345">[RFC1345]</a></p><p class="note">This includes such encodings as Shift_JIS,
|
|
HZ-GB-2312, and variants of ISO-2022, even though it is possible in
|
|
these encodings for bytes like 0x70 to be part of longer sequences
|
|
that are unrelated to their interpretation as ASCII. It excludes
|
|
such encodings as UTF-7, UTF-16, GSM03.38, and EBCDIC variants.</p><p>The term <dfn title="">Unicode character</dfn> is used to mean a
|
|
<i title="">Unicode scalar value</i> (i.e. any Unicode code point
|
|
that is not a surrogate code point). <a href="references.html#refsUNICODE">[UNICODE]</a></p><h3 id="conformance-requirements"><span class="secno">2.2 </span>Conformance requirements</h3><p>All diagrams, examples, and notes in this specification are
|
|
non-normative, as are all sections explicitly marked non-normative.
|
|
Everything else in this specification is normative.</p><p>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
|
|
"OPTIONAL" in the normative parts of this document are to be
|
|
interpreted as described in RFC2119. For readability, these words do
|
|
not appear in all uppercase letters in this specification. <a href="references.html#refsRFC2119">[RFC2119]</a></p><div class="impl">
|
|
|
|
<p>Requirements phrased in the imperative as part of algorithms
|
|
(such as "strip any leading space characters" or "return false and
|
|
abort these steps") are to be interpreted with the meaning of the
|
|
key word ("must", "should", "may", etc) used in introducing the
|
|
algorithm.</p>
|
|
|
|
<p>Conformance requirements phrased as algorithms or specific steps
|
|
may be implemented in any manner, so long as the end result is
|
|
equivalent. (In particular, the algorithms defined in this
|
|
specification are intended to be easy to follow, and not intended to
|
|
be performant.)</p>
|
|
|
|
</div><div class="impl">
|
|
|
|
<h4 id="conformance-classes"><span class="secno">2.2.1 </span>Conformance classes</h4>
|
|
|
|
<p>This specification describes the conformance criteria for <span class="impl">user agents (relevant to implementors) and</span>
|
|
documents<span class="impl"> (relevant to authors and authoring tool
|
|
implementors)</span>.</p>
|
|
|
|
<p><dfn id="conforming-html5-documents">Conforming
|
|
HTML5
|
|
documents</dfn> are those that comply with all
|
|
the conformance criteria for documents. For readability, some of
|
|
these conformance requirements are phrased as conformance
|
|
requirements on authors; such requirements are implicitly
|
|
requirements on documents: by definition, all documents are assumed
|
|
to have had an author. (In some cases, that author may itself be a
|
|
user agent — such user agents are subject to additional rules,
|
|
as explained below.)</p>
|
|
|
|
<p class="example">For example, if a requirement states that
|
|
"authors must not use the <code title="">foobar</code> element", it
|
|
would imply that documents are not allowed to contain elements named
|
|
<code title="">foobar</code>.</p>
|
|
|
|
<p class="note">the conformance requirements for documents include
|
|
syntax (the <table> element is conforming as a child of
|
|
<body>, but not as a child ot <title>), and semantics (the
|
|
<table> elements denotes a multi-dimensional data table, not a
|
|
piece of furniture).</p>
|
|
|
|
<p class="note impl">There is no implied relationship between
|
|
document conformance requirements and implementation conformance
|
|
requirements. User agents are not free to handle non-conformant
|
|
documents as they please; the processing model described in this
|
|
specification applies to implementations regardless of the
|
|
conformity of the input documents.</p>
|
|
|
|
<p>User agents fall into several (overlapping) categories with
|
|
different conformance requirements.</p>
|
|
|
|
<dl><dt id="interactive">Web browsers and other interactive user agents</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Web browsers that support <a href="the-xhtml-syntax.html#the-xhtml-syntax">the XHTML syntax</a> must
|
|
process elements and attributes from the <a href="namespaces.html#html-namespace-0">HTML
|
|
namespace</a> found in XML documents as described in this
|
|
specification, so that users can interact with them, unless the
|
|
semantics of those elements have been overridden by other
|
|
specifications.</p>
|
|
|
|
<p class="example">A conforming XHTML processor would, upon
|
|
finding an XHTML <code><a href="scripting-1.html#the-script-element">script</a></code> element in an XML document,
|
|
execute the script contained in that element. However, if the
|
|
element is found within a transformation expressed in XSLT
|
|
(assuming the user agent also supports XSLT), then the processor
|
|
would instead treat the <code><a href="scripting-1.html#the-script-element">script</a></code> element as an opaque
|
|
element that forms part of the transform.</p>
|
|
|
|
<p>Web browsers that support <a href="syntax.html#syntax">the HTML syntax</a> must
|
|
process documents labeled with an <a href="#html-mime-type">HTML MIME type</a> as
|
|
described in this specification, so that users can interact with
|
|
them.</p>
|
|
|
|
<p>User agents that support scripting must also be conforming
|
|
implementations of the IDL fragments in this specification, as
|
|
described in the Web IDL specification. <a href="references.html#refsWEBIDL">[WEBIDL]</a></p>
|
|
|
|
<p class="note">Unless explicitly stated, specifications that
|
|
override the semantics of HTML elements do not override the
|
|
requirements on DOM objects representing those elements. For
|
|
example, the <code><a href="scripting-1.html#the-script-element">script</a></code> element in the example above
|
|
would still implement the <code><a href="scripting-1.html#htmlscriptelement">HTMLScriptElement</a></code>
|
|
interface.</p>
|
|
|
|
</dd>
|
|
|
|
<dt id="non-interactive">Non-interactive presentation user agents</dt>
|
|
|
|
<dd>
|
|
|
|
<p>User agents that process HTML and XHTML documents purely to
|
|
render non-interactive versions of them must comply to the same
|
|
conformance criteria as Web browsers, except that they are exempt
|
|
from requirements regarding user interaction.</p>
|
|
|
|
<p class="note">Typical examples of non-interactive presentation
|
|
user agents are printers (static UAs) and overhead displays
|
|
(dynamic UAs). It is expected that most static non-interactive
|
|
presentation user agents will also opt to <a href="#non-scripted">lack scripting support</a>.</p>
|
|
|
|
<p class="example">A non-interactive but dynamic presentation UA
|
|
would still execute scripts, allowing forms to be dynamically
|
|
submitted, and so forth. However, since the concept of "focus" is
|
|
irrelevant when the user cannot interact with the document, the UA
|
|
would not need to support any of the focus-related DOM APIs.</p>
|
|
|
|
</dd>
|
|
|
|
<dt id="renderingUA">Visual user agents that support the suggested default rendering</dt>
|
|
|
|
<dd>
|
|
|
|
<p>User agents, whether interactive or not, may be designated
|
|
(possibly as a user option) as supporting the suggested default
|
|
rendering defined by this specification.</p>
|
|
|
|
<p>User agents that are designated as supporting the suggested
|
|
default rendering must implement the rules in <a href="rendering.html#rendering">the rendering section</a> that that section
|
|
defines as the behavior that user agents are <em>expected</em> to
|
|
implement.</p>
|
|
|
|
</dd>
|
|
|
|
<dt id="non-scripted">User agents with no scripting support</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Implementations that do not support scripting (or which have
|
|
their scripting features disabled entirely) are exempt from
|
|
supporting the events and DOM interfaces mentioned in this
|
|
specification. For the parts of this specification that are
|
|
defined in terms of an events model or in terms of the DOM, such
|
|
user agents must still act as if events and the DOM were
|
|
supported.</p>
|
|
|
|
<p class="note">Scripting can form an integral part of an
|
|
application. Web browsers that do not support scripting, or that
|
|
have scripting disabled, might be unable to fully convey the
|
|
author's intent.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt>Conformance checkers</dt>
|
|
|
|
<dd id="conformance-checkers">
|
|
|
|
<p>Conformance checkers must verify that a document conforms to
|
|
the applicable conformance criteria described in this
|
|
specification. Automated conformance checkers are exempt from
|
|
detecting errors that require interpretation of the author's
|
|
intent (for example, while a document is non-conforming if the
|
|
content of a <code><a href="grouping-content.html#the-blockquote-element">blockquote</a></code> element is not a quote,
|
|
conformance checkers running without the input of human judgement
|
|
do not have to check that <code><a href="grouping-content.html#the-blockquote-element">blockquote</a></code> elements only
|
|
contain quoted material).</p>
|
|
|
|
<p>Conformance checkers must check that the input document
|
|
conforms when parsed without a <a href="browsers.html#browsing-context">browsing context</a>
|
|
(meaning that no scripts are run, and that the parser's
|
|
<a href="parsing.html#scripting-flag">scripting flag</a> is disabled), and should also check
|
|
that the input document conforms when parsed with a <a href="browsers.html#browsing-context">browsing
|
|
context</a> in which scripts execute, and that the scripts
|
|
never cause non-conforming states to occur other than transiently
|
|
during script execution itself. (This is only a "SHOULD" and not a
|
|
"MUST" requirement because it has been proven to be impossible. <a href="references.html#refsCOMPUTABLE">[COMPUTABLE]</a>)</p>
|
|
|
|
|
|
<p>The term "HTML5 validator" can be used to refer to a
|
|
conformance checker that itself conforms to the applicable
|
|
requirements of this specification.</p>
|
|
|
|
<div class="note">
|
|
|
|
<p>XML DTDs cannot express all the conformance requirements of
|
|
this specification. Therefore, a validating XML processor and a
|
|
DTD cannot constitute a conformance checker. Also, since neither
|
|
of the two authoring formats defined in this specification are
|
|
applications of SGML, a validating SGML system cannot constitute
|
|
a conformance checker either.</p>
|
|
|
|
<p>To put it another way, there are three types of conformance
|
|
criteria:</p>
|
|
|
|
<ol><li>Criteria that can be expressed in a DTD.</li>
|
|
|
|
<li>Criteria that cannot be expressed by a DTD, but can still be
|
|
checked by a machine.</li>
|
|
|
|
<li>Criteria that can only be checked by a human.</li>
|
|
|
|
</ol><p>A conformance checker must check for the first two. A simple
|
|
DTD-based validator only checks for the first class of errors and
|
|
is therefore not a conforming conformance checker according to
|
|
this specification.</p>
|
|
|
|
</div>
|
|
</dd>
|
|
|
|
|
|
<dt>Data mining tools</dt>
|
|
|
|
<dd id="data-mining">
|
|
|
|
<p>Applications and tools that process HTML and XHTML documents
|
|
for reasons other than to either render the documents or check
|
|
them for conformance should act in accordance with the semantics
|
|
of the documents that they process.</p>
|
|
|
|
<p class="example">A tool that generates <a href="sections.html#outline" title="outline">document outlines</a> but increases the nesting
|
|
level for each paragraph and does not increase the nesting level
|
|
for each section would not be conforming.</p>
|
|
|
|
</dd>
|
|
|
|
|
|
<dt id="editors">Authoring tools and markup generators</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Authoring tools and markup generators must generate
|
|
<a href="#conforming-html5-documents">conforming
|
|
HTML5
|
|
documents</a>. Conformance criteria that apply to authors also
|
|
apply to authoring tools, where appropriate.</p>
|
|
|
|
<p>Authoring tools are exempt from the strict requirements of
|
|
using elements only for their specified purpose, but only to the
|
|
extent that authoring tools are not yet able to determine author
|
|
intent. However, authoring tools must not automatically misuse
|
|
elements or encourage their users to do so.</p>
|
|
|
|
<p class="example">For example, it is not conforming to use an
|
|
<code><a href="sections.html#the-address-element">address</a></code> element for arbitrary contact information;
|
|
that element can only be used for marking up contact information
|
|
for the author of the document or section. However, since an
|
|
authoring tool is likely unable to determine the difference, an
|
|
authoring tool is exempt from that requirement. This does not
|
|
mean, though, that authoring tools can use <code><a href="sections.html#the-address-element">address</a></code>
|
|
elements for any block of italics text (for instance); it just
|
|
means that the authoring tool doesn't have to verify that when the
|
|
user uses a tool for inserting contact information for a section,
|
|
that the user really is doing that and not inserting something
|
|
else instead.</p>
|
|
|
|
<p class="note">In terms of conformance checking, an editor has to
|
|
output documents that conform to the same extent that a
|
|
conformance checker will verify.</p>
|
|
|
|
<p>When an authoring tool is used to edit a non-conforming
|
|
document, it may preserve the conformance errors in sections of
|
|
the document that were not edited during the editing session
|
|
(i.e. an editing tool is allowed to round-trip erroneous
|
|
content). However, an authoring tool must not claim that the
|
|
output is conformant if errors have been so preserved.</p>
|
|
|
|
<p>Authoring tools are expected to come in two broad varieties:
|
|
tools that work from structure or semantic data, and tools that
|
|
work on a What-You-See-Is-What-You-Get media-specific editing
|
|
basis (WYSIWYG).</p>
|
|
|
|
<p>The former is the preferred mechanism for tools that author
|
|
HTML, since the structure in the source information can be used to
|
|
make informed choices regarding which HTML elements and attributes
|
|
are most appropriate.</p>
|
|
|
|
<p>However, WYSIWYG tools are legitimate. WYSIWYG tools should use
|
|
elements they know are appropriate, and should not use elements
|
|
that they do not know to be appropriate. This might in certain
|
|
extreme cases mean limiting the use of flow elements to just a few
|
|
elements, like <code><a href="grouping-content.html#the-div-element">div</a></code>, <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>,
|
|
and <code><a href="text-level-semantics.html#the-span-element">span</a></code> and making liberal use of the <code title="attr-style"><a href="elements.html#the-style-attribute">style</a></code> attribute.</p>
|
|
|
|
<p>All authoring tools, whether WYSIWYG or not, should make a best
|
|
effort attempt at enabling users to create well-structured,
|
|
semantically rich, media-independent content.</p>
|
|
|
|
</dd>
|
|
|
|
</dl><p id="hardwareLimitations">User agents may impose
|
|
implementation-specific limits on otherwise unconstrained inputs,
|
|
e.g. to prevent denial of service attacks, to guard against running
|
|
out of memory, or to work around platform-specific limitations.</p>
|
|
|
|
<p>For compatibility with existing content and prior specifications,
|
|
this specification describes two authoring formats: one based on XML
|
|
(referred to as <a href="the-xhtml-syntax.html#the-xhtml-syntax">the XHTML syntax</a>), and one using a <a href="syntax.html#writing">custom format</a> inspired by SGML (referred to as
|
|
<a href="syntax.html#syntax">the HTML syntax</a>). Implementations must support at least
|
|
one of these two formats, although supporting both is
|
|
encouraged.</p>
|
|
|
|
<p id="entity-references">The language in this specification assumes
|
|
that the user agent expands all entity references, and therefore
|
|
does not include entity reference nodes in the DOM. If user agents
|
|
do include entity reference nodes in the DOM, then user agents must
|
|
handle them as if they were fully expanded when implementing this
|
|
specification. For example, if a requirement talks about an
|
|
element's child text nodes, then any text nodes that are children of
|
|
an entity reference that is a child of that element would be used as
|
|
well. Entity references to unknown entities must be treated as if
|
|
they contained just an empty text node for the purposes of the
|
|
algorithms defined in this specification.</p>
|
|
|
|
<p>Some conformance requirements are phrased as requirements on
|
|
elements, attributes, methods or objects. Such requirements fall
|
|
into two categories: those describing content model restrictions,
|
|
and those describing implementation behavior. Those in the former
|
|
category are requirements on documents and authoring tools. Those in
|
|
the second category are requirements on user agents. Similarly, some
|
|
conformance requirements are phrased as requirements on authors;
|
|
such requirements are to be interpreted as conformance requirements
|
|
on the documents that authors produce. (In other words, this
|
|
specification does not distinguish between conformance criteria on
|
|
authors and conformance criteria on documents.)</p>
|
|
|
|
</div><div class="impl">
|
|
|
|
<h4 id="dependencies"><span class="secno">2.2.2 </span>Dependencies</h4>
|
|
|
|
<p>This specification relies on several other underlying
|
|
specifications.</p>
|
|
|
|
<dl><dt>XML</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Implementations that support <a href="the-xhtml-syntax.html#the-xhtml-syntax">the XHTML syntax</a> must
|
|
support some version of XML, as well as its corresponding
|
|
namespaces specification, because that syntax uses an XML
|
|
serialization with namespaces. <a href="references.html#refsXML">[XML]</a> <a href="references.html#refsXMLNS">[XMLNS]</a></p>
|
|
|
|
</dd>
|
|
|
|
<dt>DOM</dt>
|
|
|
|
<dd>
|
|
|
|
<p>The Document Object Model (DOM) is a representation — a
|
|
model — of a document and its content. The DOM is not just
|
|
an API; the conformance criteria of HTML implementations are
|
|
defined, in this specification, in terms of operations on the DOM.
|
|
<a href="references.html#refsDOMCORE">[DOMCORE]</a></p>
|
|
|
|
<p>Implementations must support some version of DOM Core and DOM
|
|
Events, because this specification is defined in terms of the DOM,
|
|
and some of the features are defined as extensions to the DOM Core
|
|
interfaces. <a href="references.html#refsDOMCORE">[DOMCORE]</a> <a href="references.html#refsDOMEVENTS">[DOMEVENTS]</a></p>
|
|
|
|
<p>In particular, the following features are defined in the DOM
|
|
Core specification: <a href="references.html#refsDOMCORE">[DOMCORE]</a></p>
|
|
|
|
<ul class="brief"><li><dfn id="attr"><code>Attr</code></dfn> interface</li>
|
|
<li><dfn id="cdatasection"><code>CDATASection</code></dfn> interface</li>
|
|
<li><dfn id="comment-0"><code>Comment</code></dfn> interface</li>
|
|
<li><dfn id="domimplementation"><code>DOMImplementation</code></dfn> interface</li>
|
|
<li><dfn id="document"><code>Document</code></dfn> interface</li>
|
|
<li><dfn id="documentfragment"><code>DocumentFragment</code></dfn> interface</li>
|
|
<li><dfn id="documenttype"><code>DocumentType</code></dfn> interface</li>
|
|
<li><dfn id="domexception"><code>DOMException</code></dfn> interface</li>
|
|
<li><dfn id="element"><code>Element</code></dfn> interface</li>
|
|
<li><dfn id="node"><code>Node</code></dfn> interface</li>
|
|
<li><dfn id="nodelist"><code>NodeList</code></dfn> interface</li>
|
|
<li><dfn id="processinginstruction"><code>ProcessingInstruction</code></dfn> interface</li>
|
|
<li><dfn id="text"><code>Text</code></dfn> interface</li>
|
|
|
|
<li><dfn id="dom-domimplementation-createdocument" title="dom-DOMImplementation-createDocument"><code>createDocument()</code></dfn> method</li>
|
|
<li><dfn id="dom-document-createelement" title="dom-Document-createElement"><code>createElement()</code></dfn> method</li>
|
|
<li><dfn id="dom-document-createelementns" title="dom-Document-createElementNS"><code>createElementNS()</code></dfn> method</li>
|
|
<li><dfn id="dom-document-getelementbyid" title="dom-Document-getElementById"><code>getElementById()</code></dfn> method</li>
|
|
<li><dfn id="dom-node-insertbefore" title="dom-Node-insertBefore"><code>insertBefore()</code></dfn> method</li>
|
|
|
|
<li><dfn id="dom-node-ownerdocument" title="dom-Node-ownerDocument"><code>ownerDocument</code></dfn> attribute</li>
|
|
<li><dfn id="dom-node-childnodes" title="dom-Node-childNodes"><code>childNodes</code></dfn> attribute</li>
|
|
<li><dfn id="dom-node-localname" title="dom-Node-localName"><code>localName</code></dfn> attribute</li>
|
|
<li><dfn id="dom-node-parentnode" title="dom-Node-parentNode"><code>parentNode</code></dfn> attribute</li>
|
|
<li><dfn id="dom-node-namespaceuri" title="dom-Node-namespaceURI"><code>namespaceURI</code></dfn> attribute</li>
|
|
<li><dfn id="dom-element-tagname" title="dom-Element-tagName"><code>tagName</code></dfn> attribute</li>
|
|
<li><dfn id="textcontent"><code>textContent</code></dfn> attribute</li>
|
|
|
|
</ul><p>The following features are defined in the DOM Events
|
|
specification: <a href="references.html#refsDOMEVENTS">[DOMEVENTS]</a></p>
|
|
|
|
<ul class="brief"><li><dfn id="event"><code>Event</code></dfn> interface</li>
|
|
<li><dfn id="eventtarget"><code>EventTarget</code></dfn> interface</li>
|
|
<li><dfn id="uievent"><code>UIEvent</code></dfn> interface</li>
|
|
<li><dfn id="mouseevent"><code>MouseEvent</code></dfn> interface</li>
|
|
|
|
<li><dfn id="event-click" title="event-click"><code>click</code></dfn> event</li>
|
|
|
|
<li><dfn id="dom-event-target" title="dom-Event-target"><code>target</code></dfn> attribute</li>
|
|
|
|
</ul></dd>
|
|
|
|
<dt>File API</dt>
|
|
|
|
<dd>
|
|
|
|
<p>This specification uses the following interfaces defined in the
|
|
File API specification: <a href="references.html#refsFILEAPI">[FILEAPI]</a></p>
|
|
|
|
<ul class="brief"><li><dfn id="blob">Blob</dfn></li>
|
|
<li><dfn id="file">File</dfn></li>
|
|
<li><dfn id="filelist">FileList</dfn></li>
|
|
|
|
</ul></dd>
|
|
|
|
<dt>Web IDL</dt>
|
|
|
|
<dd>
|
|
|
|
<p>The IDL fragments in this specification must be interpreted as
|
|
required for conforming IDL fragments, as described in the Web IDL
|
|
specification. <a href="references.html#refsWEBIDL">[WEBIDL]</a></p>
|
|
|
|
<p>The terms <dfn id="supported-property-indices">supported property indices</dfn> and
|
|
<dfn id="supported-property-names">supported property names</dfn> are used as defined in the
|
|
WebIDL specification.</p>
|
|
|
|
<p id="float-nan">Except where otherwise specified, if an IDL
|
|
attribute that is a floating point number type (<code title="">double</code>) is assigned an Infinity or Not-a-Number
|
|
(NaN) value, a <code><a href="common-dom-interfaces.html#not_supported_err">NOT_SUPPORTED_ERR</a></code> exception must be
|
|
raised.</p>
|
|
|
|
<p>Except where otherwise specified, if a method with an argument
|
|
that is a floating point number type (<code title="">double</code>)
|
|
is passed an Infinity or Not-a-Number (NaN) value, a
|
|
<code><a href="common-dom-interfaces.html#not_supported_err">NOT_SUPPORTED_ERR</a></code> exception must be raised.</p>
|
|
|
|
<p>Except where otherwise specified, if a method has an argument
|
|
of type <code>DOMString</code>, or if an IDL attribute is assigned
|
|
a new value of type <code>DOMString</code>, the user agent must
|
|
<span title="dfn-obtain-unicode">convert the
|
|
<code>DOMString</code> to a sequence of Unicode characters</span>
|
|
to obtain the string on which the algorithms in this specification
|
|
are to operate. <a href="references.html#refsWEBIDL">[WEBIDL]</a></p>
|
|
|
|
</dd>
|
|
|
|
<dt>JavaScript</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Some parts of the language described by this specification only
|
|
support JavaScript as the underlying scripting language. <a href="references.html#refsECMA262">[ECMA262]</a></p>
|
|
|
|
<p class="note">The term "JavaScript" is used to refer to ECMA262,
|
|
rather than the official term ECMAScript, since the term
|
|
JavaScript is more widely known. Similarly, the <a href="#mime-type">MIME
|
|
type</a> used to refer to JavaScript in this specification is
|
|
<code title="">text/javascript</code>, since that is the most
|
|
commonly used type, <a href="introduction.html#willful-violation" title="willful violation">despite it
|
|
being an officially obsoleted type</a> according to RFC
|
|
4329. <a href="references.html#refsRFC4329">[RFC4329]</a></p>
|
|
|
|
</dd>
|
|
|
|
<dt>Media Queries</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Implementations must support some version of the Media Queries
|
|
language. <a href="references.html#refsMQ">[MQ]</a></p>
|
|
|
|
</dd>
|
|
|
|
<dt>URIs, IRIs, IDNA</dt>
|
|
|
|
<dd>
|
|
|
|
<p>Implementations must support the semantics of <a href="urls.html#url" title="URL">URLs</a> defined in the URI and IRI specifications,
|
|
as well as the semantics of IDNA domain names defined in the
|
|
<cite>Internationalizing Domain Names in Applications
|
|
(IDNA)</cite> specification. <a href="references.html#refsRFC3986">[RFC3986]</a>
|
|
<a href="references.html#refsRFC3987">[RFC3987]</a> <a href="references.html#refsRFC3490">[RFC3490]</a>
|
|
|
|
</p></dd>
|
|
|
|
<dt>CSS modules</dt>
|
|
|
|
<dd>
|
|
|
|
<p>While support for CSS as a whole is not required of
|
|
implementations of this specification (though it is encouraged, at
|
|
least for Web browsers), some features are defined in terms of
|
|
specific CSS requirements.</p>
|
|
|
|
<p>In particular, some features require that a string be
|
|
<dfn id="parsed-as-a-css-color-value">parsed as a CSS <color> value</dfn>. When parsing a CSS
|
|
value, user agents are required by the CSS specifications to apply
|
|
some error handling rules. These apply to this specification also.
|
|
<a href="references.html#refsCSSCOLOR">[CSSCOLOR]</a> <a href="references.html#refsCSS">[CSS]</a></p>
|
|
|
|
<p class="example">For example, user agents are required to close
|
|
all open constructs upon finding the end of a style sheet
|
|
unexpectedly. Thus, when parsing the string "<code title="">rgb(0,0,0</code>" (with a missing close-parenthesis) for
|
|
a color value, the close parenthesis is implied by this error
|
|
handling rule, and a value is obtained (the color 'black').
|
|
However, the similar construct "<code title="">rgb(0,0,</code>"
|
|
(with both a missing parenthesis and a missing "blue" value)
|
|
cannot be parsed, as closing the open construct does not result
|
|
in a viable value.</p>
|
|
|
|
</dd>
|
|
|
|
</dl><p>This specification does not <em>require</em> support of any
|
|
particular network protocol, style sheet language, scripting
|
|
language, or any of the DOM specifications beyond those described
|
|
above. However, the language described by this specification is
|
|
biased towards CSS as the styling language, JavaScript as the
|
|
scripting language, and HTTP as the network protocol, and several
|
|
features assume that those languages and protocols are in use.</p>
|
|
|
|
<p class="note">This specification might have certain additional
|
|
requirements on character encodings, image formats, audio formats,
|
|
and video formats in the respective sections.</p>
|
|
|
|
</div><h4 id="extensibility"><span class="secno">2.2.3 </span>Extensibility</h4><p>HTML has a wide number of extensibility mechanisms that can be
|
|
used for adding semantics in a safe manner:</p><ul><li>Authors can use the <code title="attr-class"><a href="elements.html#classes">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.</li>
|
|
|
|
<li>Authors can include data for inline client-side scripts or
|
|
server-side site-wide scripts to process using the <code title="attr-data-*"><a href="elements.html#attr-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.</li>
|
|
|
|
<li>Authors can use the <code title="meta"><a href="semantics.html#the-meta-element"><meta name=""
|
|
content=""></a></code> mechanism to include page-wide metadata by
|
|
registering <a href="semantics.html#concept-meta-extensions" title="concept-meta-extensions">extensions to the
|
|
predefined set of metadata names</a>.</li>
|
|
|
|
<li>Authors can use the <code title="attr-hyperlink-rel"><a href="links.html#attr-hyperlink-rel">rel=""</a></code> mechanism to annotate
|
|
links with specific meanings by registering <a href="links.html#concept-rel-extensions" title="concept-rel-extensions">extensions to the predefined set of
|
|
link types</a>. This is also used by Microformats.</li>
|
|
|
|
<li>Authors can embed raw data using the <code title="script"><a href="scripting-1.html#the-script-element"><script type=""></a></code> mechanism with a custom
|
|
type, for further handling by inline or server-side scripts.</li>
|
|
|
|
<li>Authors can create <a href="#plugin" title="plugin">plugins</a> and
|
|
invoke them using the <code><a href="the-iframe-element.html#the-embed-element">embed</a></code> element. This is how Flash
|
|
works.</li>
|
|
|
|
<li>Authors can extend APIs using the JavaScript prototyping
|
|
mechanism. This is widely used by script libraries, for
|
|
instance.</li>
|
|
|
|
|
|
</ul><div class="impl">
|
|
|
|
<hr><p>Vendor-specific proprietary user agent extensions to this
|
|
specification are strongly discouraged. Documents must not use such
|
|
extensions, as doing so reduces interoperability and fragments the
|
|
user base, allowing only users of specific user agents to access the
|
|
content in question.</p>
|
|
|
|
<p>If such extensions are nonetheless needed, e.g. for experimental
|
|
purposes, then vendors are strongly urged to use one of the
|
|
following extension mechanisms:</p>
|
|
|
|
<p>For markup-level features that can be limited to the XML
|
|
serialization and need not be supported in the HTML serialization,
|
|
vendors should use the namespace mechanism to define custom
|
|
namespaces in which the non-standard elements and attributes are
|
|
supported.</p>
|
|
|
|
<p>For markup-level features that are intended for use with
|
|
<a href="syntax.html#syntax">the HTML syntax</a>, extensions should be limited to new
|
|
attributes of the form "<code title="">x-<var title="">vendor</var>-<var title="">feature</var></code>", where
|
|
<var title="">vendor</var> is a short string that identifies the
|
|
vendor responsible for the extension, and <var title="">feature</var> is the name of the feature. New element names
|
|
should not be created. Using attributes for such extensions
|
|
exclusively allows extensions from multiple vendors to co-exist on
|
|
the same element, which would not be possible with elements. Using
|
|
the "<code title="">x-<var title="">vendor</var>-<var title="">feature</var></code>" form allows extensions to be made
|
|
without risk of conflicting with future additions to the
|
|
specification.</p>
|
|
|
|
<div class="example">
|
|
|
|
<p>For instance, a browser named "FerretBrowser" could use "ferret"
|
|
as a vendor prefix, while a browser named "Mellblom Browser" could
|
|
use "mb". If both of these browsers invented extensions that turned
|
|
elements into scratch-and-sniff areas, an author experimenting with
|
|
these features could write:</p>
|
|
|
|
<pre><p>This smells of lemons!
|
|
<span x-ferret-smellovision x-ferret-smellcode="LEM01"
|
|
x-mb-outputsmell x-mb-smell="lemon juice"></span></p></pre>
|
|
|
|
</div>
|
|
|
|
<p>Attribute names beginning with the two characters "<code title="">x-</code>" are reserved for user agent use and are
|
|
guaranteed to never be formally added to the HTML language. For
|
|
flexibility, attributes names containing underscores (the U+005F LOW
|
|
LINE character) are also reserved for experimental purposes and are
|
|
guaranteed to never be formally added to the HTML language.</p>
|
|
|
|
<p class="note">Pages that use such attributes are by definition
|
|
non-conforming.</p>
|
|
|
|
<p>For DOM extensions, e.g. new methods and IDL attributes, the new
|
|
members should be prefixed by vendor-specific strings to prevent
|
|
clashes with future versions of this specification.</p>
|
|
|
|
<p>For events, experimental event names should be prefixed with
|
|
vendor-specific strings.</p>
|
|
|
|
<div class="example">
|
|
|
|
<p>For example, if a user agent called "Pleasold" were to
|
|
add an event to indicate when the user is going up in an elevator,
|
|
it could use the prefix "<code title="">pleasold</code>" and thus
|
|
name the event "<code title="">pleasoldgoingup</code>", possibly
|
|
with an event handler attribute named "<code title="">onpleasoldgoingup</code>".</p>
|
|
|
|
</div>
|
|
|
|
<p>All extensions must be defined so that the use of extensions
|
|
neither contradicts nor causes the non-conformance of functionality
|
|
defined in the specification.</p>
|
|
|
|
<div class="example">
|
|
|
|
<p>For example, while strongly discouraged from doing so, an
|
|
implementation "Foo Browser" could add a new IDL attribute "<code title="">fooTypeTime</code>" to a control's DOM interface that
|
|
returned the time it took the user to select the current value of a
|
|
control (say). On the other hand, defining a new control that
|
|
appears in a form's <code title="dom-form-elements"><a href="forms.html#dom-form-elements">elements</a></code>
|
|
array would be in violation of the above requirement, as it would
|
|
violate the definition of <code title="dom-form-elements"><a href="forms.html#dom-form-elements">elements</a></code> given in this
|
|
specification.</p>
|
|
|
|
</div>
|
|
|
|
<p>When adding new <a href="common-dom-interfaces.html#reflect" title="reflect">reflecting</a> IDL
|
|
attributes corresponding to content attributes of the form "<code title="">x-<var title="">vendor</var>-<var title="">feature</var></code>", the IDL attribute should be named
|
|
"<code title=""><var title="">vendor</var><var title="">Feature</var></code>" (i.e. the "<code title="">x</code>"
|
|
is dropped from the IDL attribute's name).</p>
|
|
|
|
<hr><p>When vendor-neutral extensions to this specification are needed,
|
|
either this specification can be updated accordingly, or an
|
|
extension specification can be written that overrides the
|
|
requirements in this specification. When someone applying this
|
|
specification to their activities decides that they will recognize
|
|
the requirements of such an extension specification, it becomes an
|
|
<dfn id="other-applicable-specifications" title="other applicable specifications">applicable
|
|
specification</dfn>.
|
|
|
|
</p><p>The conformance terminology for documents depends on the nature
|
|
of the changes introduced by such applicable specificactions, and on
|
|
the content and intended interpretation of the document. Applicable
|
|
specifications MAY define new document content (e.g. a foobar
|
|
element), MAY prohibit certain otherwise conforming content (e.g.
|
|
prohibit use of <table>s), or MAY change the semantics, DOM
|
|
mappings, or other processing rules for content defined in this
|
|
specification. Whether a document is or is not a <a href="#conforming-html5-documents">conforming HTML5 document</a> does not
|
|
depend on the use of applicable specifications: if the syntax and
|
|
semantics of a given <a href="#conforming-html5-documents">conforming
|
|
HTML5 document </a>document is unchanged by the use of applicable
|
|
specification(s), then that document remains a <a href="#conforming-html5-documents">conforming HTML5 document</a>. If the
|
|
semantics or processing of a given (otherwise conforming) document
|
|
is changed by use of applicable specification(s), then it is not a
|
|
<a href="#conforming-html5-documents">conforming HTML5 document</a>. For
|
|
such cases, the applicable specifications SHOULD define conformance
|
|
terminology.</p>
|
|
|
|
<p class="note">As a suggested but not required convention, such
|
|
specifications might define conformance terminology such as:
|
|
"Conforming HTML5+XXX document", where XXX is a short
|
|
name for the applicable specification. (Example: "Conforming
|
|
HTML5+AutomotiveExtensions document").</p>
|
|
|
|
<p class="note">a consequence of the rule given above is that
|
|
certain syntactically correct HTML5 documents may not be <a href="#conforming-html5-documents">conforming HTML5 documents</a> in the
|
|
presence of applicable specifications. (Example: the applicable
|
|
specification defines <table> to be a piece of furniture —
|
|
a document written to that specification and containing a <table>
|
|
element is NOT a <a href="#conforming-html5-documents">conforming HTML5
|
|
document</a>, even if the element happens to be syntactically
|
|
correct HTML5.)</p>
|
|
|
|
<hr><p>User agents must treat elements and attributes that they do not
|
|
understand as semantically neutral; leaving them in the DOM (for DOM
|
|
processors), and styling them according to CSS (for CSS processors),
|
|
but not inferring any meaning from them.</p>
|
|
|
|
<p>When support for a feature is disabled (e.g. as an emergency
|
|
measure to mitigate a security problem, or to aid in development, or
|
|
for performance reasons), user agents must act as if they had no
|
|
support for the feature whatsoever, and as if the feature was not
|
|
mentioned in this specification. For example, if a particular
|
|
feature is accessed via an attribute in a Web IDL interface, the
|
|
attribute itself would be omitted from the objects that implement
|
|
that interface — leaving the attribute on the object but
|
|
making it return null or throw an exception is insufficient.</p>
|
|
|
|
</div><h3 id="case-sensitivity-and-string-comparison"><span class="secno">2.3 </span>Case-sensitivity and string comparison</h3><p>Comparing two strings in a <dfn id="case-sensitive">case-sensitive</dfn> manner means
|
|
comparing them exactly, code point for code point.</p><p>Comparing two strings in an <dfn id="ascii-case-insensitive">ASCII case-insensitive</dfn>
|
|
manner means comparing them exactly, code point for code point, except
|
|
that the characters in the range U+0041 to U+005A (i.e. LATIN
|
|
CAPITAL LETTER A to LATIN CAPITAL LETTER Z) and the corresponding
|
|
characters in the range U+0061 to U+007A (i.e. LATIN SMALL LETTER A
|
|
to LATIN SMALL LETTER Z) are considered to also match.</p><p>Comparing two strings in a <dfn id="compatibility-caseless">compatibility caseless</dfn>
|
|
manner means using the Unicode <i>compatibility caseless match</i>
|
|
operation to compare the two strings. <a href="references.html#refsUNICODE">[UNICODE]</a></p><p>Except where otherwise stated, string comparisons must be
|
|
performed in a <a href="#case-sensitive">case-sensitive</a> manner.</p><div class="impl">
|
|
|
|
<p><dfn id="converted-to-ascii-uppercase" title="converted to ASCII uppercase">Converting a string to
|
|
ASCII uppercase</dfn> means replacing all characters in the range
|
|
U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z)
|
|
with the corresponding characters in the range U+0041 to U+005A
|
|
(i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z).</p>
|
|
|
|
<p><dfn id="converted-to-ascii-lowercase" title="converted to ASCII lowercase">Converting a string to
|
|
ASCII lowercase</dfn> means replacing all characters in the range
|
|
U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL
|
|
LETTER Z) with the corresponding characters in the range U+0061
|
|
to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z).</p>
|
|
|
|
</div><p>A string <var title="">pattern</var> is a <dfn id="prefix-match">prefix match</dfn>
|
|
for a string <var title="">s</var> when <var title="">pattern</var>
|
|
is not longer than <var title="">s</var> and truncating <var title="">s</var> to <var title="">pattern</var>'s length leaves the
|
|
two strings as matches of each other.</p><div class="impl">
|
|
|
|
<h3 id="utf-8"><span class="secno">2.4 </span>UTF-8</h3>
|
|
|
|
<p>When a user agent is required to <dfn id="decoded-as-utf-8-with-error-handling" title="decoded as UTF-8,
|
|
with error handling">decode a byte string as UTF-8, with error
|
|
handling</dfn>, it means that the byte stream must be converted to a
|
|
Unicode string by interpreting it as UTF-8, except that any errors
|
|
must be handled as described in the following list. Bytes in the
|
|
following list are represented in hexadecimal. <a href="references.html#refsRFC3629">[RFC3629]</a>
|
|
|
|
</p><dl class="switch"><dt>One byte in the range FE to FF</dt>
|
|
|
|
|
|
<dt><a href="#overlong-form" title="overlong form">Overlong forms</a> (e.g. F0 80 80 A0)</dt>
|
|
|
|
<dt>One byte in the range C0 to C1, followed by one byte in the range 80 to BF</dt>
|
|
|
|
|
|
<dt>One byte in the range F0 to F4, followed by three bytes in the range 80 to BF that represent a code point above U+10FFFF</dt>
|
|
|
|
<dt>One byte in the range F5 to F7, followed by three bytes in the range 80 to BF</dt>
|
|
|
|
<dt>One byte in the range F8 to FB, followed by four bytes in the range 80 to BF</dt>
|
|
|
|
<dt>One byte in the range FC to FD, followed by five bytes in the range 80 to BF</dt>
|
|
|
|
|
|
<dt>One byte in the range C0 to FD that is not followed by a byte in the range 80 to BF</dt>
|
|
|
|
<dt>One byte in the range E0 to FD, followed by a byte in the range 80 to BF that is not followed by a byte in the range 80 to BF</dt>
|
|
|
|
<dt>One byte in the range F0 to FD, followed by two bytes in the range 80 to BF, the last of which is not followed by a byte in the range 80 to BF</dt>
|
|
|
|
<dt>One byte in the range F8 to FD, followed by three bytes in the range 80 to BF, the last of which is not followed by a byte in the range 80 to BF</dt>
|
|
|
|
<dt>One byte in the range FC to FD, followed by four bytes in the range 80 to BF, the last of which is not followed by a byte in the range 80 to BF</dt>
|
|
|
|
|
|
<dt>Any byte sequence that represents a code point in the range U+D800 to U+DFFF</dt>
|
|
|
|
|
|
<dd>The whole matched sequence must be replaced by a single U+FFFD
|
|
REPLACEMENT CHARACTER.</dd>
|
|
|
|
|
|
<dt>One byte in the range 80 to BF not preceded by a byte in the range 80 to FD</dt>
|
|
|
|
<dt>One byte in the range 80 to BF preceded by a byte that is part of a complete UTF-8 sequence that does not include this byte</dt>
|
|
|
|
<dt>One byte in the range 80 to BF preceded by a byte that is part of a sequence that has been replaced by a U+FFFD REPLACEMENT CHARACTER, either alone or as part of a sequence</dt>
|
|
|
|
<dd>Each such byte must be replaced with a U+FFFD REPLACEMENT CHARACTER.</dd>
|
|
|
|
|
|
</dl><p>For the purposes of the above requirements, an <dfn id="overlong-form">overlong
|
|
form</dfn> in UTF-8 is a sequence that encodes a code point using
|
|
more bytes than the minimum needed to encode that code point in
|
|
UTF-8.</p>
|
|
|
|
<p class="example">For example, the byte string "41 98 BA 42 E2 98
|
|
43 E2 98 BA E2 98" would be converted to the string
|
|
"A��B�C☺�".</p>
|
|
|
|
</div></body></html>
|