This is the SVG WG's modification of the original proposal for inline SVG in HTML5
Note that sections with the class 'svgSection' (blue background, double blue border) contain the original portions of the proposal that were commented out in the HTML5 draft. Relevant sections are:
This section only applies to user agents, data mining tools, and conformance checkers.
The rules for parsing XML documents (and thus XHTML documents) into DOM trees are covered by the next section, entitled "The XHTML syntax".
For HTML documents, user agents must use the parsing rules described in this section to generate the DOM trees. Together, these rules define what is referred to as the HTML parser.
While the HTML form of HTML5 bears a close resemblance to SGML and XML, it is a separate language with its own parsing rules.
Some earlier versions of HTML (in particular from HTML2 to HTML4) were based on SGML and used SGML parsing rules. However, few (if any) web browsers ever implemented true SGML parsing for HTML documents; the only user agents to strictly handle HTML as an SGML application have historically been validators. The resulting confusion — with validators claiming documents to have one representation while widely deployed Web browsers interoperably implemented a different representation — has wasted decades of productivity. This version of HTML thus returns to a non-SGML basis.
Authors interested in using SGML tools in their authoring pipeline are encouraged to use XML tools and the XML serialization of HTML5.
This specification defines the parsing rules for HTML documents, whether they are syntactically correct or not. Certain points in the parsing algorithm are said to be parse errors. The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below.
Conformance checkers must report at least one parse error condition to the user if one or more parse error conditions exist in the document and must not report parse error conditions if none exist in the document. Conformance checkers may report more than one parse error condition if more than one parse error conditions exist in the document. Conformance checkers are not required to recover from parse errors.
Parse errors are only errors with the syntax of HTML. In addition to checking for parse errors, conformance checkers will also verify that the document obeys all the other conformance requirements described in this specification.
The input to the HTML parsing process consists of a stream of
Unicode characters, which is passed through a
tokenization stage (lexical analysis) followed by a
tree construction stage (semantic analysis). The output
is a Document object.
Implementations that do not
support scripting do not have to actually create a DOM
Document object, but the DOM tree in such cases is
still used as the model for the rest of the specification.
In the common case, the data handled by the tokenization stage
comes from the network, but it can also come from script, e.g. using the document.write() API.
There is only one set of state for the tokeniser stage and the tree construction stage, but the tree construction stage is reentrant, meaning that while the tree construction stage is handling one token, the tokeniser might be resumed, causing further tokens to be emitted and processed before the first token's processing is complete.
In the following example, the tree construction stage will be called upon to handle a "p" start tag token while handling the "script" start tag token:
...
<script>
document.write('<p>');
</script>
...
To handle these cases, parsers have a script nesting level, which must be initially set to zero, and a parser pause flag, which must be initially set to false.
The stream of Unicode characters that consists the input to the tokenization stage will be initially seen by the user agent as a stream of bytes (typically coming over the network or from the local file system). The bytes encode the actual characters according to a particular character encoding, which the user agent must use to decode the bytes into characters.
For XML documents, the algorithm user agents must use to determine the character encoding is given by the XML specification. This section does not apply to XML documents. [XML]
In some cases, it might be impractical to unambiguously determine the encoding before parsing the document. Because of this, this specification provides for a two-pass mechanism with an optional pre-scan. Implementations are allowed, as described below, to apply a simplified parsing algorithm to whatever bytes they have available before beginning to parse the document. Then, the real parser is started, using a tentative encoding derived from this pre-parse and other out-of-band metadata. If, while the document is being loaded, the user agent discovers an encoding declaration that conflicts with this information, then the parser can get reinvoked to perform a parse of the document with the real encoding.
User agents must use the following algorithm (the encoding sniffing algorithm) to determine the character encoding to use when decoding a document in the first pass. This algorithm takes as input any out-of-band metadata available to the user agent (e.g. the Content-Type metadata of the document) and all the bytes available so far, and returns an encoding and a confidence. The confidence is either tentative, certain, or irrelevant. The encoding used, and whether the confidence in that encoding is tentative or confident, is used during the parsing to determine whether to change the encoding. If no encoding is necessary, e.g. because the parser is operating on a stream of Unicode characters and doesn't have to use an encoding at all, then the confidence is irrelevant.
If the transport layer specifies an encoding, and it is supported, return that encoding with the confidence certain, and abort these steps.
The user agent may wait for more bytes of the resource to be available, either in this step or at any later step in this algorithm. For instance, a user agent might wait 500ms or 512 bytes, whichever came first. In general preparsing the source to find the encoding improves performance, as it reduces the need to throw away the data structures used when parsing upon finding the encoding information. However, if the user agent delays too long to obtain data to determine the encoding, then the cost of the delay could outweigh any performance improvements from the preparse.
For each of the rows in the following table, starting with the first one and going down, if there are as many or more bytes available than the number of bytes in the first column, and the first bytes of the file match the bytes given in the first column, then return the encoding given in the cell in the second column of that row, with the confidence certain, and abort these steps:
| Bytes in Hexadecimal | Encoding |
|---|---|
| FE FF | UTF-16BE |
| FF FE | UTF-16LE |
| EF BB BF | UTF-8 |
This step looks for Unicode Byte Order Marks (BOMs).
Otherwise, the user agent will have to search for explicit character encoding information in the file itself. This should proceed as follows:
Let position be a pointer to a byte in the input stream, initially pointing at the first byte. If at any point during these substeps the user agent either runs out of bytes or decides that scanning further bytes would not be efficient, then skip to the next step of the overall character encoding detection algorithm. User agents may decide that scanning any bytes is not efficient, in which case these substeps are entirely skipped.
Now, repeat the following "two" steps until the algorithm aborts (either because user agent aborts, as described above, or because a character encoding is found):
If position points to:
Advance the position pointer so that it points at the first 0x3E byte which is preceded by two 0x2D bytes (i.e. at the end of an ASCII '-->' sequence) and comes after the 0x3C byte that was found. (The two 0x2D bytes can be the same as the those in the '<!--' sequence.)
Advance the position pointer so that it points at the next 0x09, 0x0A, 0x0C, 0x0D, 0x20, or 0x2F byte (the one in sequence of characters matched above).
Get an attribute and its value. If no attribute was sniffed, then skip this inner set of steps, and jump to the second step in the overall "two step" algorithm.
If the attribute's name is neither "charset" nor "content",
then return to step 2 in these inner steps.
If the attribute's name is "charset", let charset be
the attribute's value, interpreted as a character
encoding.
Otherwise, the attribute's name is "content": apply the algorithm for
extracting an encoding from a Content-Type, giving the
attribute's value as the string to parse. If an encoding is
returned, let charset be that
encoding. Otherwise, return to step 2 in these inner
steps.
If charset is a UTF-16 encoding, change it to UTF-8.
If charset is a supported character encoding, then return the given encoding, with confidence tentative, and abort all these steps.
Otherwise, return to step 2 in these inner steps.
Advance the position pointer so that it points at the next 0x09 (ASCII TAB), 0x0A (ASCII LF), 0x0C (ASCII FF), 0x0D (ASCII CR), 0x20 (ASCII space), or 0x3E (ASCII '>') byte.
Repeatedly get an attribute until no further attributes can be found, then jump to the second step in the overall "two step" algorithm.
Advance the position pointer so that it points at the first 0x3E byte (ASCII '>') that comes after the 0x3C byte that was found.
Do nothing with that byte.
When the above "two step" algorithm says to get an attribute, it means doing this:
If the byte at position is one of 0x09 (ASCII TAB), 0x0A (ASCII LF), 0x0C (ASCII FF), 0x0D (ASCII CR), 0x20 (ASCII space), or 0x2F (ASCII '/') then advance position to the next byte and redo this substep.
If the byte at position is 0x3E (ASCII '>'), then abort the "get an attribute" algorithm. There isn't one.
Otherwise, the byte at position is the start of the attribute name. Let attribute name and attribute value be the empty string.
Attribute name: Process the byte at position as follows:
Advance position to the next byte and return to the previous step.
Spaces. If the byte at position is one of 0x09 (ASCII TAB), 0x0A (ASCII LF), 0x0C (ASCII FF), 0x0D (ASCII CR), or 0x20 (ASCII space) then advance position to the next byte, then, repeat this step.
If the byte at position is not 0x3D (ASCII '='), abort the "get an attribute" algorithm. The attribute's name is the value of attribute name, its value is the empty string.
Advance position past the 0x3D (ASCII '=') byte.
Value. If the byte at position is one of 0x09 (ASCII TAB), 0x0A (ASCII LF), 0x0C (ASCII FF), 0x0D (ASCII CR), or 0x20 (ASCII space) then advance position to the next byte, then, repeat this step.
Process the byte at position as follows:
Process the byte at position as follows:
Advance position to the next byte and return to the previous step.
For the sake of interoperability, user agents should not use a pre-scan algorithm that returns different results than the one described above. (But, if you do, please at least let us know, so that we can improve this algorithm and benefit everyone...)
If the user agent has information on the likely encoding for this page, e.g. based on the encoding of the page when it was last visited, then return that encoding, with the confidence tentative, and abort these steps.
The user agent may attempt to autodetect the character encoding from applying frequency analysis or other algorithms to the data stream. If autodetection succeeds in determining a character encoding, then return that encoding, with the confidence tentative, and abort these steps. [UNIVCHARDET]
Otherwise, return an implementation-defined or
user-specified default character encoding, with the confidence
tentative. In non-legacy environments, the more
comprehensive UTF-8 encoding is
recommended. Due to its use in legacy content, windows-1252 is recommended as a default in
predominantly Western demographics instead. Since these encodings
can in many cases be distinguished by inspection, a user agent may
heuristically decide which to use as a default.
The document's character encoding must immediately be set to the value returned from this algorithm, at the same time as the user agent uses the returned value to select the decoder to use for the input stream.
Given an encoding, the bytes in the input stream must be converted to Unicode characters for the tokeniser, as described by the rules for that encoding, except that the leading U+FEFF BYTE ORDER MARK character, if any, must not be stripped by the encoding layer (it is stripped by the rule below).
Bytes or sequences of bytes in the original byte stream that could not be converted to Unicode characters must be converted to U+FFFD REPLACEMENT CHARACTER code points.
Bytes or sequences of bytes in the original byte stream that did not conform to the encoding specification (e.g. invalid UTF-8 byte sequences in a UTF-8 input stream) are errors that conformance checkers are expected to report.
Any byte or sequences of bytes in the original byte stream that is misinterpreted for compatibility is a parse error.
One leading U+FEFF BYTE ORDER MARK character must be ignored if any are present.
All U+0000 NULL characters in the input must be replaced by U+FFFD REPLACEMENT CHARACTERs. Any occurrences of such characters is a parse error.
Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E to U+001F, U+007F to U+009F, U+D800 to U+DFFF, U+FDD0 to U+FDEF, and characters U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse errors. (These are all control characters or permanently undefined Unicode characters.)
U+000D CARRIAGE RETURN (CR) characters and U+000A LINE FEED (LF) characters are treated specially. Any CR characters that are followed by LF characters must be removed, and any CR characters not followed by LF characters must be converted to LF characters. Thus, newlines in HTML DOMs are represented by LF characters, and there are never any CR characters in the input to the tokenization stage.
The next input character is the first character in the input stream that has not yet been consumed. Initially, the next input character is the first character in the input. The current input character is the last character to have been consumed.
The insertion point is the position (just before a
character or just before the end of the input stream) where content
inserted using document.write() is actually
inserted. The insertion point is relative to the position of the
character immediately after it, it is not an absolute offset into
the input stream. Initially, the insertion point is
uninitialized.
The "EOF" character in the tables below is a conceptual character
representing the end of the input stream. If the parser
is a script-created parser, then the end of the
input stream is reached when an explicit "EOF"
character (inserted by the document.close() method) is
consumed. Otherwise, the "EOF" character is not a real character in
the stream, but rather the lack of any further characters.
When the parser requires the user agent to change the encoding, it must run the following steps. This might happen if the encoding sniffing algorithm described above failed to find an encoding, or if it found an encoding that was not the actual encoding of the file.
The insertion mode is a flag that controls the primary operation of the tree construction stage.
Initially the insertion mode is "initial". It can change to "before html", "before head", "in head", "in head noscript", "after head", "in body", "in CDATA/RCDATA", "in table", "in caption", "in column group", "in table body", "in row", "in cell", "in select", "in select in table", "in foreign content", "after body", "in frameset", "after frameset", "after after body", and "after after frameset" during the course of the parsing, as described in the tree construction stage. The insertion mode affects how tokens are processed and whether CDATA sections are supported.
Seven of these modes, namely "in head", "in body", "in CDATA/RCDATA", "in table", "in table body", "in row", "in cell", and "in select", are special, in that the other modes defer to them at various times. When the algorithm below says that the user agent is to do something "using the rules for the m insertion mode", where m is one of these modes, the user agent must use the rules described under the m insertion mode's section, but must leave the insertion mode unchanged unless the rules in m themselves switch the insertion mode to a new value.
When the insertion mode is switched to "in CDATA/RCDATA", the original insertion mode is also set. This is the insertion mode to which the tree construction stage will return when the corresponding end tag is parsed.
When the insertion mode is switched to "in foreign content", the secondary insertion mode is also set. This secondary mode is used within the rules for the "in foreign content" mode to handle HTML (i.e. not foreign) content.
When the steps below require the UA to reset the insertion mode appropriately, it means the UA must follow these steps:
select element,
then switch the insertion mode to "in select" and abort these
steps. (fragment case)td or
th element and last is false, then
switch the insertion mode to "in cell" and abort these steps.tr element, then
switch the insertion mode to "in row" and abort these steps.tbody,
thead, or tfoot element, then switch the
insertion mode to "in table body" and abort these steps.caption element,
then switch the insertion mode to "in caption" and abort
these steps.colgroup element,
then switch the insertion mode to "in column group" and
abort these steps. (fragment case)table element,
then switch the insertion mode to "in table" and abort these
steps.head element,
then switch the insertion mode to "in body" ("in body"! not "in head"!) and abort
these steps. (fragment case)body element,
then switch the insertion mode to "in body" and abort these
steps.frameset element,
then switch the insertion mode to "in frameset" and abort
these steps. (fragment case)html element,
then: if the head element
pointer is null, switch the insertion mode to
"before head",
otherwise, switch the insertion mode to "after head". In either
case, abort these steps. (fragment case)Initially the stack of open elements is empty. The stack grows downwards; the topmost node on the stack is the first one added to the stack, and the bottommost node of the stack is the most recently added node in the stack (notwithstanding when the stack is manipulated in a random access fashion as part of the handling for misnested tags).
The "before
html" insertion mode creates the
html root element node, which is then added to the
stack.
In the fragment case, the stack of open
elements is initialized to contain an html
element that is created as part of that algorithm. (The fragment
case skips the "before html" insertion mode.)
The html node, however it is created, is the topmost
node of the stack. It never gets popped off the stack.
The current node is the bottommost node in this stack.
The current table is the last table
element in the stack of open elements, if there is
one. If there is no table element in the stack of
open elements (fragment case), then the
current table is the first element in the stack
of open elements (the html element).
Elements in the stack fall into the following categories:
The following HTML elements have varying levels of special
parsing rules: address, area,
article, aside, base,
basefont, bgsound,
blockquote, body, br,
center, col, colgroup,
command, datagrid, dd,
details, dialog, dir,
div, dl, dt,
embed, fieldset, figure,
footer, form, frame,
frameset, h1, h2,
h3, h4, h5, h6,
head, header, hr,
iframe, img, input,
isindex, li, link,
listing, menu, meta,
nav, noembed, noframes,
noscript, ol, p,
param, plaintext, pre,
script, section, select,
spacer, style, tbody,
textarea, tfoot, thead,
title, tr, ul, and
wbr.
The following HTML elements introduce new scopes for various parts of the
parsing: applet, button,
caption, html, marquee,
object, table, td,
th.
The following HTML elements are those that end up in the
list of active formatting elements: a,
b, big, code,
em, font, i,
nobr, s, small,
strike, strong, tt, and
u.
All other elements found while parsing an HTML document.
The stack of open elements is said to have an element in scope when the following algorithm terminates in a match state:
Initialize node to be the current node (the bottommost node of the stack).
If node is the target node, terminate in a match state.
Otherwise, if node is one of the following elements, terminate in a failure state:
Otherwise, set node to the previous
entry in the stack of open elements and return to step
2. (This will never fail, since the loop will always terminate in
the previous step if the top of the stack — an
html element — is reached.)
The stack of open elements is said to have an element in table scope when the following algorithm terminates in a match state:
Initialize node to be the current node (the bottommost node of the stack).
If node is the target node, terminate in a match state.
Otherwise, if node is one of the following elements, terminate in a failure state:
Otherwise, set node to the previous
entry in the stack of open elements and return to step
2. (This will never fail, since the loop will always terminate in
the previous step if the top of the stack — an
html element — is reached.)
Nothing happens if at any time any of the elements in the
stack of open elements are moved to a new location in,
or removed from, the Document tree. In particular, the
stack is not changed in this situation. This can cause, amongst
other strange effects, content to be appended to nodes that are no
longer in the DOM.
In some cases (namely, when closing misnested formatting elements), the stack is manipulated in a random-access fashion.
Initially the list of active formatting elements is empty. It is used to handle mis-nested formatting element tags.
The list contains elements in the formatting
category, and scope markers. The scope markers are inserted when
entering applet elements, buttons, object
elements, marquees, table cells, and table captions, and are used to
prevent formatting from "leaking" into applet elements,
buttons, object elements, marquees, and tables.
When the steps below require the UA to reconstruct the active formatting elements, the UA must perform the following steps:
This has the effect of reopening all the formatting elements that were opened in the current body, cell, or caption (whichever is youngest) that haven't been explicitly closed.
The way this specification is written, the list of active formatting elements always consists of elements in chronological order with the least recently added element first and the most recently added element last (except for while steps 8 to 11 of the above algorithm are being executed, of course).
When the steps below require the UA to clear the list of active formatting elements up to the last marker, the UA must perform the following steps:
Initially the head element
pointer and the form element
pointer are both null.
Once a head element has been parsed (whether
implicitly or explicitly) the head
element pointer gets set to point to this node.
The form element pointer
points to the last form element that was opened and
whose end tag has not yet been seen. It is used to make form
controls associate with forms in the face of dramatically bad
markup, for historical reasons.
The scripting flag is set to "enabled" if scripting was enabled for the
Document with which the parser is associated when the
parser was created, and "disabled" otherwise.
The frameset-ok flag is set to "ok" when the parser is created. It is set to "not ok" after certain tokens are seen.
Implementations must act as if they used the following state machine to tokenise HTML. The state machine must start in the data state. Most states consume a single character, which may have various side-effects, and either switches the state machine to a new state to reconsume the same character, or switches it to a new state (to consume the next character), or repeats the same state (to consume the next character). Some states have more complicated behavior and can consume several characters before switching to another state.
The exact behavior of certain states depends on a content model flag that is set after certain tokens are emitted. The flag has several states: PCDATA, RCDATA, CDATA, and PLAINTEXT. Initially it must be in the PCDATA state. In the RCDATA and CDATA states, a further escape flag is used to control the behavior of the tokeniser. It is either true or false, and initially must be set to the false state. The insertion mode and the stack of open elements also affects tokenization.
The output of the tokenization step is a series of zero or more of the following tokens: DOCTYPE, start tag, end tag, comment, character, end-of-file. DOCTYPE tokens have a name, a public identifier, a system identifier, and a force-quirks flag. When a DOCTYPE token is created, its name, public identifier, and system identifier must be marked as missing (which is a distinct state from the empty string), and the force-quirks flag must be set to off (its other state is on). Start and end tag tokens have a tag name, a self-closing flag, and a list of attributes, each of which has a name and a value. When a start or end tag token is created, its self-closing flag must be unset (its other state is that it be set), and its attributes list must be empty. Comment and character tokens have data.
When a token is emitted, it must immediately be handled by the
tree construction stage. The tree construction stage
can affect the state of the content model flag, and can
insert additional characters into the stream. (For example, the
script element can result in scripts executing and
using the dynamic markup insertion APIs to insert
characters into the stream being tokenised.)
When a start tag token is emitted with its self-closing flag set, if the flag is not acknowledged when it is processed by the tree construction stage, that is a parse error.
When an end tag token is emitted, the content model flag must be switched to the PCDATA state.
When an end tag token is emitted with attributes, that is a parse error.
When an end tag token is emitted with its self-closing flag set, that is a parse error.
Before each step of the tokeniser, the user agent must first check the parser pause flag. If it is true, then the tokeniser must abort the processing of any nested invocations of the tokeniser, yielding control back to the caller. If it is false, then the user agent may then check to see if either one of the scripts in the list of scripts that will execute as soon as possible or the first script in the list of scripts that will execute asynchronously, has completed loading. If one has, then it must be executed and removed from its list.
The tokeniser state machine consists of the states defined in the following subsections.
Consume the next input character:
If the content model flag is set to either the RCDATA state or the CDATA state, and the escape flag is false, and there are at least three characters before this one in the input stream, and the last four characters in the input stream, including this one, are U+003C LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+002D HYPHEN-MINUS, and U+002D HYPHEN-MINUS ("<!--"), then set the escape flag to true.
In any case, emit the input character as a character token. Stay in the data state.
If the content model flag is set to either the RCDATA state or the CDATA state, and the escape flag is true, and the last three characters in the input stream including this one are U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN ("-->"), set the escape flag to false.
In any case, emit the input character as a character token. Stay in the data state.
(This cannot happen if the content model flag is set to the CDATA state.)
Attempt to consume a character reference, with no additional allowed character.
If nothing is returned, emit a U+0026 AMPERSAND character token.
Otherwise, emit the character token that was returned.
Finally, switch to the data state.
The behavior of this state depends on the content model flag.
Consume the next input character. If it is a U+002F SOLIDUS (/) character, switch to the close tag open state. Otherwise, emit a U+003C LESS-THAN SIGN character token and reconsume the current input character in the data state.
Consume the next input character:
If the content model flag is set to the RCDATA or CDATA states but no start tag token has ever been emitted by this instance of the tokeniser (fragment case), or, if the content model flag is set to the RCDATA or CDATA states and the next few characters do not match the tag name of the last start tag token emitted (compared in an ASCII case-insensitive manner), or if they do but they are not immediately followed by one of the following characters:
...then emit a U+003C LESS-THAN SIGN character token, a U+002F SOLIDUS character token, and switch to the data state to process the next input character.
Otherwise, if the content model flag is set to the PCDATA state, or if the next few characters do match that tag name, consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
When the user agent leaves the attribute name state (and before emitting the tag token, if appropriate), the complete attribute's name must be compared to the other attributes on the same token; if there is already an attribute on the token with the exact same name, then this is a parse error and the new attribute must be dropped, along with the value that gets associated with it (if any).
Consume the next input character:
Consume the next input character:
Contrast this prose with the original proposal.
Consume the next input character:
Consume the next input character:
Consume the next input character:
Attempt to consume a character reference.
If nothing is returned, append a U+0026 AMPERSAND character to the current attribute's value.
Otherwise, append the returned character token to the current attribute's value.
Finally, switch back to the attribute value state that you were in when were switched into this state.
Consume the next input character:
Consume the next input character:
(This can only happen if the content model flag is set to the PCDATA state.)
Consume every character up to and including the first U+003E GREATER-THAN SIGN character (>) or the end of the file (EOF), whichever comes first. Emit a comment token whose data is the concatenation of all the characters starting from and including the character that caused the state machine to switch into the bogus comment state, up to and including the character immediately before the last consumed character (i.e. up to the character just before the U+003E or EOF character). (If the comment was started by the end of the file (EOF), the token is empty.)
Switch to the data state.
If the end of the file was reached, reconsume the EOF character.
(This can only happen if the content model flag is set to the PCDATA state.)
If the next two characters are both U+002D HYPHEN-MINUS (-) characters, consume those two characters, create a comment token whose data is the empty string, and switch to the comment start state.
Otherwise, if the next seven characters are an ASCII case-insensitive match for the word "DOCTYPE", then consume those characters and switch to the DOCTYPE state.
Otherwise, if the insertion mode is "in foreign content" and the current node is not an element in the HTML namespace and the next seven characters are an ASCII case-sensitive match for the string "[CDATA[" (the five uppercase letters "CDATA" with a U+005B LEFT SQUARE BRACKET character before and after), then consume those characters and switch to the CDATA section state (which is unrelated to the content model flag's CDATA state).
Otherwise, this is a parse error. Switch to the bogus comment state. The next character that is consumed, if any, is the first character that will be in the comment.
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
If the six characters starting from the current input character are an ASCII case-insensitive match for the word "PUBLIC", then consume those characters and switch to the before DOCTYPE public identifier state.
Otherwise, if the six characters starting from the current input character are an ASCII case-insensitive match for the word "SYSTEM", then consume those characters and switch to the before DOCTYPE system identifier state.
Otherwise, this is the parse error. Set the DOCTYPE token's force-quirks flag to on. Switch to the bogus DOCTYPE state.
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
Consume the next input character:
(This can only happen if the content model flag is set to the PCDATA state, and is unrelated to the content model flag's CDATA state.)
Consume every character up to the next occurrence of the three
character sequence U+005D RIGHT SQUARE BRACKET U+005D RIGHT SQUARE
BRACKET U+003E GREATER-THAN SIGN (]]>), or the
end of the file (EOF), whichever comes first. Emit a series of
character tokens consisting of all the characters consumed except
the matching three character sequence at the end (if one was found
before the end of the file).
Switch to the data state.
If the end of the file was reached, reconsume the EOF character.
This section defines how to consume a character reference. This definition is used when parsing character references in text and in attributes.
The behavior depends on the identity of the next character (the one immediately after the U+0026 AMPERSAND character):
Consume the U+0023 NUMBER SIGN.
The behavior further depends on the character after the U+0023 NUMBER SIGN:
Consume the X.
Follow the steps below, but using the range of characters U+0030 DIGIT ZERO through to U+0039 DIGIT NINE, U+0061 LATIN SMALL LETTER A through to U+0066 LATIN SMALL LETTER F, and U+0041 LATIN CAPITAL LETTER A, through to U+0046 LATIN CAPITAL LETTER F (in other words, 0-9, A-F, a-f).
When it comes to interpreting the number, interpret it as a hexadecimal number.
Follow the steps below, but using the range of characters U+0030 DIGIT ZERO through to U+0039 DIGIT NINE (i.e. just 0-9).
When it comes to interpreting the number, interpret it as a decimal number.
Consume as many characters as match the range of characters given above.
If no characters match the range, then don't consume any characters (and unconsume the U+0023 NUMBER SIGN character and, if appropriate, the X character). This is a parse error; nothing is returned.
Otherwise, if the next character is a U+003B SEMICOLON, consume that too. If it isn't, there is a parse error.
If one or more characters match the range, then take them all and interpret the string of characters as a number (either hexadecimal or decimal as appropriate).
If that number is one of the numbers in the first column of the following table, then this is a parse error. Find the row with that number in the first column, and return a character token for the Unicode character given in the second column of that row.
| Number | Unicode character | |
|---|---|---|
| 0x0D | U+000A | LINE FEED (LF) |
| 0x80 | U+20AC | EURO SIGN ('€') |
| 0x81 | U+FFFD | REPLACEMENT CHARACTER |
| 0x82 | U+201A | SINGLE LOW-9 QUOTATION MARK ('‚') |
| 0x83 | U+0192 | LATIN SMALL LETTER F WITH HOOK ('ƒ') |
| 0x84 | U+201E | DOUBLE LOW-9 QUOTATION MARK ('„') |
| 0x85 | U+2026 | HORIZONTAL ELLIPSIS ('…') |
| 0x86 | U+2020 | DAGGER ('†') |
| 0x87 | U+2021 | DOUBLE DAGGER ('‡') |
| 0x88 | U+02C6 | MODIFIER LETTER CIRCUMFLEX ACCENT ('ˆ') |
| 0x89 | U+2030 | PER MILLE SIGN ('‰') |
| 0x8A | U+0160 | LATIN CAPITAL LETTER S WITH CARON ('Š') |
| 0x8B | U+2039 | SINGLE LEFT-POINTING ANGLE QUOTATION MARK ('‹') |
| 0x8C | U+0152 | LATIN CAPITAL LIGATURE OE ('Œ') |
| 0x8D | U+FFFD | REPLACEMENT CHARACTER |
| 0x8E | U+017D | LATIN CAPITAL LETTER Z WITH CARON ('Ž') |
| 0x8F | U+FFFD | REPLACEMENT CHARACTER |
| 0x90 | U+FFFD | REPLACEMENT CHARACTER |
| 0x91 | U+2018 | LEFT SINGLE QUOTATION MARK ('‘') |
| 0x92 | U+2019 | RIGHT SINGLE QUOTATION MARK ('’') |
| 0x93 | U+201C | LEFT DOUBLE QUOTATION MARK ('“') |
| 0x94 | U+201D | RIGHT DOUBLE QUOTATION MARK ('”') |
| 0x95 | U+2022 | BULLET ('•') |
| 0x96 | U+2013 | EN DASH ('–') |
| 0x97 | U+2014 | EM DASH ('—') |
| 0x98 | U+02DC | SMALL TILDE ('˜') |
| 0x99 | U+2122 | TRADE MARK SIGN ('™') |
| 0x9A | U+0161 | LATIN SMALL LETTER S WITH CARON ('š') |
| 0x9B | U+203A | SINGLE RIGHT-POINTING ANGLE QUOTATION MARK ('›') |
| 0x9C | U+0153 | LATIN SMALL LIGATURE OE ('œ') |
| 0x9D | U+FFFD | REPLACEMENT CHARACTER |
| 0x9E | U+017E | LATIN SMALL LETTER Z WITH CARON ('ž') |
| 0x9F | U+0178 | LATIN CAPITAL LETTER Y WITH DIAERESIS ('Ÿ') |
Otherwise, if the number is in the range 0x0000 to 0x0008, 0x000E to 0x001F, 0x007F to 0x009F, 0xD800 to 0xDFFF, 0xFDD0 to 0xFDEF, or is one of 0x000B, 0xFFFE, 0xFFFF, 0x1FFFE, 0x1FFFF, 0x2FFFE, 0x2FFFF, 0x3FFFE, 0x3FFFF, 0x4FFFE, 0x4FFFF, 0x5FFFE, 0x5FFFF, 0x6FFFE, 0x6FFFF, 0x7FFFE, 0x7FFFF, 0x8FFFE, 0x8FFFF, 0x9FFFE, 0x9FFFF, 0xAFFFE, 0xAFFFF, 0xBFFFE, 0xBFFFF, 0xCFFFE, 0xCFFFF, 0xDFFFE, 0xDFFFF, 0xEFFFE, 0xEFFFF, 0xFFFFE, 0xFFFFF, 0x10FFFE, or 0x10FFFF, or is higher than 0x10FFFF, then this is a parse error; return a character token for the U+FFFD REPLACEMENT CHARACTER character instead.
Otherwise, return a character token for the Unicode character whose code point is that number.
Consume the maximum number of characters possible, with the consumed characters matching one of the identifiers in the first column of the named character references table (in a case-sensitive manner).
If no match can be made, then this is a parse error. No characters are consumed, and nothing is returned.
If the last character matched is not a U+003B SEMICOLON (;), there is a parse error.
If the character reference is being consumed as part of an
attribute, and the last character matched is not a U+003B
SEMICOLON (;), and the next character is in
the range U+0030 DIGIT ZERO to U+0039 DIGIT NINE, U+0041 LATIN
CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, or U+0061 LATIN
SMALL LETTER A to U+007A LATIN SMALL LETTER Z, then, for
historical reasons, all the characters that were matched after the
U+0026 AMPERSAND (&) must be unconsumed, and nothing is
returned.
Otherwise, return a character token for the character corresponding to the character reference name (as given by the second column of the named character references table).
If the markup contains I'm ¬it; I tell
you, the character reference is parsed as "not", as in,
I'm ¬it; I tell you. But if the markup
was I'm ∉ I tell you, the
character reference would be parsed as "notin;", resulting in
I'm ∉ I tell you.
The input to the tree construction stage is a sequence of tokens
from the tokenization stage. The tree construction
stage is associated with a DOM Document object when a
parser is created. The "output" of this stage consists of
dynamically modifying or extending that document's DOM tree.
This specification does not define when an interactive user agent
has to render the Document so that it is available to
the user, or when it has to begin accepting user input.
As each token is emitted from the tokeniser, the user agent must process the token according to the rules given in the section corresponding to the current insertion mode.
When the steps below require the UA to insert a
character into a node, if that node has a child immediately
before where the character is to be inserted, and that child is a
Text node, and that Text node was the last
node that the parser inserted into the document, then the character
must be appended to that Text node; otherwise, a new
Text node whose data is just that character must be
inserted in the appropriate place.
DOM mutation events must not fire
for changes caused by the UA parsing the document. (Conceptually,
the parser is not mutating the DOM, it is constructing it.) This
includes the parsing of any content inserted using document.write() and document.writeln() calls. [DOM3EVENTS]
Not all of the tag names mentioned below are conformant tag names in this specification; many are included to handle legacy content. They still form part of the algorithm that implementations are required to implement to claim conformance.
The algorithm described below places no limit on the depth of the DOM tree generated, or on the length of tag names, attribute names, attribute values, text nodes, etc. While implementors are encouraged to avoid arbitrary limits, it is recognized that practical concerns will likely force user agents to impose nesting depths.
When the steps below require the UA to create an element for a token in a
particular namespace, the UA must create a node implementing the
interface appropriate for the element type corresponding to the tag
name of the token in the given namespace (as given in the
specification that defines that element, e.g. for an a
element in the HTML namespace, this specification
defines it to be the HTMLAnchorElement interface), with
the tag name being the name of that element, with the node being in
the given namespace, and with the attributes on the node being those
given in the given token.
The interface appropriate for an element in the HTML
namespace that is not defined in this specification is
HTMLElement. The interface appropriate for an element
in another namespace that is not defined by that namespace's
specification is Element.
When a resettable element is created in this manner, its reset algorithm must be invoked once the attributes are set. (This initializes the element's value and checkedness based on the element's attributes.)
When the steps below require the UA to insert an HTML element for a token, the UA must first create an element for the token in the HTML namespace, and then append this node to the current node, and push it onto the stack of open elements so that it is the new current node.
The steps below may also require that the UA insert an HTML element in a particular place, in which case the UA must follow the same steps except that it must insert or append the new node in the location specified instead of appending it to the current node. (This happens in particular during the parsing of tables with invalid content.)
If an element created by the insert an HTML element
algorithm is a form-associated element, and the
form element pointer is not null,
and the newly created element doesn't have a form attribute, the user agent must
associate the newly
created element with the form element pointed to by the
form element pointer before
inserting it wherever it is to be inserted.
When the steps below require the UA to insert a foreign
element for a token, the UA must first create an element
for the token in the given namespace, and then append this
node to the current node, and push it onto the
stack of open elements so that it is the new
current node. If the newly created element has an xmlns attribute in the XMLNS namespace
whose value is not exactly the same as the element's namespace, that
is a parse error. Similarly, if the newly created
element has an xmlns:xlink attribute in the
XMLNS namespace whose value is not the XLink
Namespace, that is a parse error.
When the steps below require the user agent to adjust MathML
attributes for a token, then, if the token has an attribute
named definitionurl, change its name to definitionURL (note the case difference).
When the steps below require the user agent to adjust SVG attributes for a token, then, for each attribute on the token whose attribute name matches in a case-insensitive manner an attribute name specified in SVG 1.1 [SVG11] or SVG Tiny 1.2 [SVGT12], change the attribute's name to to the case-sensitive equivalent. If an attribute on the token has an attribute name that matches in a case-insensitive manner an attribute name specified in any later SVG specification recognized by the user agent, change the attribute's name to to the case-sensitive equivalent.
(This fixes the case of SVG attributes that are not all lowercase.)
Contrast this prose with the original proposal.
When the steps below require the user agent to adjust
foreign attributes for a token, then, if any of the attributes
on the token match the strings given in the first column of the
following table, let the attribute be a namespaced attribute, with
the prefix being the string given in the corresponding cell in the
second column, the local name being the string given in the
corresponding cell in the third column, and the namespace being the
namespace given in the corresponding cell in the fourth
column. (This fixes the use of namespaced attributes, in particular
xml:lang.)
| Attribute name | Prefix | Local name | Namespace |
|---|---|---|---|
xlink:actuate | xlink | actuate | XLink namespace |
xlink:arcrole | xlink | arcrole | XLink namespace |
xlink:href | xlink | href | XLink namespace |
xlink:role | xlink | role | XLink namespace |
xlink:show | xlink | show | XLink namespace |
xlink:title | xlink | title | XLink namespace |
xlink:type | xlink | type | XLink namespace |
xml:base | xml | base | XML namespace |
xml:lang | xml | lang | XML namespace |
xml:space | xml | space | XML namespace |
xmlns | (none) | xmlns | XMLNS namespace |
xmlns:xlink | xmlns | xlink | XMLNS namespace |
The generic CDATA element parsing algorithm and the generic RCDATA element parsing algorithm consist of the following steps. These algorithms are always invoked in response to a start tag token.
Insert an HTML element for the token.
If the algorithm that was invoked is the generic CDATA element parsing algorithm, switch the tokeniser's content model flag to the CDATA state; otherwise the algorithm invoked was the generic RCDATA element parsing algorithm, switch the tokeniser's content model flag to the RCDATA state.
Let the original insertion mode be the current insertion mode.
Then, switch the insertion mode to "in CDATA/RCDATA".
When the steps below require the UA to generate implied end
tags, then, while the current node is a
dd element, a dt element, an
li element, an option element, an
optgroup element, a p element, an
rp element, or an rt element, the UA must
pop the current node off the stack of open
elements.
If a step requires the UA to generate implied end tags but lists an element to exclude from the process, then the UA must perform the above steps as if that element was not in the above list.
Foster parenting happens when content is misnested in tables.
When a node node is to be foster parented, the node node must be inserted into the foster parent element, and the current table must be marked as tainted. (Once the current table has been tainted, whitespace characters are inserted into the foster parent element instead of the current node.)
The foster parent element is the parent element of the
last table element in the stack of open
elements, if there is a table element and it has
such a parent element. If there is no table element in
the stack of open elements (fragment
case), then the foster parent element is the first
element in the stack of open elements (the
html element). Otherwise, if there is a
table element in the stack of open
elements, but the last table element in the
stack of open elements has no parent, or its parent
node is not an element, then the foster parent element is
the element before the last table element in the
stack of open elements.
If the foster parent element is the parent element of the
last table element in the stack of open
elements, then node must be inserted
immediately before the last table element in
the stack of open elements in the foster parent
element; otherwise, node must be
appended to the foster parent element.
When the insertion mode is "initial", tokens must be handled as follows:
Ignore the token.
Append a Comment node to the Document
object with the data attribute set to the
data given in the comment token.
If the DOCTYPE token's name is not a
case-sensitive match for the string "html", or if the token's public identifier is not
missing, or if the token's system identifier is neither missing
nor a case-sensitive match for the string
"about:legacy-compat", then there is a parse
error (this is the DOCTYPE parse
error). Conformance checkers may, instead of reporting this
error, switch to a conformance checking mode for another language
(e.g. based on the DOCTYPE token a conformance checker could
recognize that the document is an HTML4-era document, and defer to
an HTML4 conformance checker.)
Append a DocumentType node to the
Document node, with the name
attribute set to the name given in the DOCTYPE token, or the empty
string if the name was missing; the publicId
attribute set to the public identifier given in the DOCTYPE token,
or the empty string if the public identifier was missing; the
systemId attribute set to the system
identifier given in the DOCTYPE token, or the empty string if the
system identifier was missing; and the other attributes specific
to DocumentType objects set to null and empty lists
as appropriate. Associate the DocumentType node with
the Document object so that it is returned as the
value of the doctype attribute of the
Document object.
Then, if the DOCTYPE token matches one of the conditions in the following list, then set the document to quirks mode:
Otherwise, if the DOCTYPE token matches one of the conditions in the following list, then set the document to limited quirks mode:
-//W3C//DTD XHTML 1.0 Frameset//" -//W3C//DTD XHTML 1.0 Transitional//" -//W3C//DTD HTML 4.01 Frameset//" -//W3C//DTD HTML 4.01 Transitional//" The name, system identifier, and public identifier strings must be compared to the values given in the lists above in an ASCII case-insensitive manner. A system identifier whose value is the empty string is not considered missing for the purposes of the conditions above.
Then, switch the insertion mode to "before html".
Set the document to quirks mode.
Switch the insertion mode to "before html", then reprocess the current token.
When the insertion mode is "before html", tokens must be handled as follows:
Parse error. Ignore the token.
Append a Comment node to the Document
object with the data attribute set to the
data given in the comment token.
Ignore the token.
Create an element for the token in the HTML
namespace. Append it to the Document
object. Put this element in the stack of open
elements.
If the Document is being
loaded as part of navigation of a
browsing context, then: if the newly created element
has a manifest attribute,
then resolve the value of that
attribute to an absolute URL, relative to the newly
created element, and if that is successful, run the application cache selection
algorithm with the resulting absolute URL;
otherwise, if there is no such attribute or resolving it fails,
run the application cache
selection algorithm with no manifest. The algorithm must be
passed the Document object.
Switch the insertion mode to "before head".
Create an html element. Append it to the
Document object. Put this element in the stack
of open elements.
If the Document is being loaded as part of navigation of a browsing
context, then: run the application cache selection
algorithm with no manifest, passing it the
Document object.
Switch the insertion mode to "before head", then reprocess the current token.
Should probably make end tags be ignored, so that "</head><!-- --><html>" puts the comment before the root node (or should we?)
The root element can end up being removed from the
Document object, e.g. by scripts; nothing in particular
happens in such cases, content continues being appended to the nodes
as described in the next section.
When the insertion mode is "before head", tokens must be handled as follows:
Ignore the token.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
Insert an HTML element for the token.
Set the head element pointer
to the newly created head element.
Switch the insertion mode to "in head".
Act as if a start tag token with the tag name "head" and no attributes had been seen, then reprocess the current token.
Parse error. Ignore the token.
Act as if a start tag token with the tag name "head" and no attributes had been seen, then reprocess the current token.
This will result in an empty head
element being generated, with the current token being
reprocessed in the "after head" insertion mode.
When the insertion mode is "in head", tokens must be handled as follows:
Insert the character into the current node.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.
Acknowledge the token's self-closing flag, if it is set.
Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.
Acknowledge the token's self-closing flag, if it is set.
If the element has a charset attribute, and its
value is a supported encoding, and the confidence is
currently tentative, then change the
encoding to the encoding given by the value of the
charset attribute.
Otherwise, if the element has a content attribute, and
applying the algorithm for extracting an encoding from a
Content-Type to its value returns a supported encoding
encoding, and the confidence is
currently tentative, then change the
encoding to the encoding encoding.
Follow the generic RCDATA element parsing algorithm.
Follow the generic CDATA element parsing algorithm.
Insert an HTML element for the token.
Switch the insertion mode to "in head noscript".
Mark the element as being "parser-inserted".
This ensures that, if the script is external,
any document.write()
calls in the script will execute in-line, instead of blowing the
document away, as would happen in most other cases. It also
prevents the script from executing until the end tag is
seen.
If the parser was originally created for the HTML
fragment parsing algorithm, then mark the
script element as "already
executed". (fragment case)
Append the new element to the current node and push it onto the stack of open elements.
Switch the tokeniser's content model flag to the CDATA state.
Let the original insertion mode be the current insertion mode.
Switch the insertion mode to "in CDATA/RCDATA".
Pop the current node (which will be the
head element) off the stack of open
elements.
Switch the insertion mode to "after head".
Act as described in the "anything else" entry below.
Parse error. Ignore the token.
Act as if an end tag token with the tag name "head" had been seen, and reprocess the current token.
In certain UAs, some elements don't trigger the "in body" mode straight away, but instead get put into the head. Do we want to copy that?
When the insertion mode is "in head noscript", tokens must be handled as follows:
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
Pop the current node (which will be a
noscript element) from the stack of open
elements; the new current node will be a
head element.
Switch the insertion mode to "in head".
Process the token using the rules for the "in head" insertion mode.
Act as described in the "anything else" entry below.
Parse error. Ignore the token.
Parse error. Act as if an end tag with the tag name "noscript" had been seen and reprocess the current token.
When the insertion mode is "after head", tokens must be handled as follows:
Insert the character into the current node.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
Insert an HTML element for the token.
Switch the insertion mode to "in body".
Insert an HTML element for the token.
Switch the insertion mode to "in frameset".
Push the node pointed to by the head element pointer onto the
stack of open elements.
Process the token using the rules for the "in head" insertion mode.
Remove the node pointed to by the head element pointer from the stack
of open elements.
Act as described in the "anything else" entry below.
Parse error. Ignore the token.
Act as if a start tag token with the tag name "body" and no attributes had been seen, and then reprocess the current token.
When the insertion mode is "in body", tokens must be handled as follows:
Reconstruct the active formatting elements, if any.
Insert the token's character into the current node.
If the token is not one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000C FORM FEED (FF), or U+0020 SPACE, then set the frameset-ok flag to "not ok".
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Parse error. For each attribute on the token, check to see if the attribute is already present on the top element of the stack of open elements. If it is not, add the attribute and its corresponding value to that element.
Process the token using the rules for the "in head" insertion mode.
If the second element on the stack of open
elements is not a body element, or, if the
stack of open elements has only one node on it,
then ignore the token. (fragment case)
Otherwise, for each attribute on the token, check to see if
the attribute is already present on the body
element (the second element) on the stack of open
elements. If it is not, add the attribute and its
corresponding value to that element.
If the second element on the stack of open
elements is not a body element, or, if the
stack of open elements has only one node on it,
then ignore the token. (fragment case)
If the frameset-ok flag is set to "not ok", ignore the token.
Otherwise, run the following steps:
Remove the second element on the stack of open elements from its parent node, if it has one.
Pop all the nodes from the bottom of the stack of
open elements, from the current node up to
the root html element.
Insert an HTML element for the token.
Switch the insertion mode to "in frameset".
If there is a node in the stack of open elements
that is not either a dd element, a dt
element, an li element, a p element, a
tbody element, a td element, a
tfoot element, a th element, a
thead element, a tr element, the
body element, or the html element, then
this is a parse error.
If the stack of open elements does not have a body element
in scope, this is a parse error; ignore the
token.
Otherwise, if there is a node in the stack of open
elements that is not either a dd element, a
dt element, an li element, an
optgroup element, an option element, a
p element, an rp element, an
rt element, a tbody element, a
td element, a tfoot element, a
th element, a thead element, a
tr element, the body element, or the
html element, then this is a parse
error.
Switch the insertion mode to "after body".
Act as if an end tag with tag name "body" had been seen, then, if that token wasn't ignored, reprocess the current token.
The fake end tag token here can only be ignored in the fragment case.
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
Insert an HTML element for the token.
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
If the current node is an element whose tag name is one of "h1", "h2", "h3", "h4", "h5", or "h6", then this is a parse error; pop the current node off the stack of open elements.
Insert an HTML element for the token.
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
Insert an HTML element for the token.
If the next token is a U+000A LINE FEED (LF) character
token, then ignore that token and move on to the next
one. (Newlines at the start of pre blocks are
ignored as an authoring convenience.)
Set the frameset-ok flag to "not ok".
If the form element
pointer is not null, then this is a parse
error; ignore the token.
Otherwise:
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
Insert an HTML element for the token, and set the
form element pointer to
point to the element created.
Run the following algorithm:
Set the frameset-ok flag to "not ok".
Initialize node to be the current node (the bottommost node of the stack).
If node is an li element,
then act as if an end tag with the tag name "li" had
been seen, then jump to the last step.
If node is not in the
formatting category, and is not in the
phrasing category, and is not an
address, div, or p
element, then jump to the last step.
Otherwise, set node to the previous entry in the stack of open elements and return to step 2.
This is the last step.
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
Finally, insert an HTML element for the token.
Run the following algorithm:
Set the frameset-ok flag to "not ok".
Initialize node to be the current node (the bottommost node of the stack).
If node is a dd or
dt element, then act as if an end tag with the same
tag name as node had been seen, then jump to
the last step.
If node is not in the
formatting category, and is not in the
phrasing category, and is not an
address, div, or p
element, then jump to the last step.
Otherwise, set node to the previous entry in the stack of open elements and return to step 2.
This is the last step.
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
Finally, insert an HTML element for the token.
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
Insert an HTML element for the token.
Switch the content model flag to the PLAINTEXT state.
Once a start tag with the tag name "plaintext" has been seen, that will be the last token ever seen other than character tokens (and the end-of-file token), because there is no way to switch the content model flag out of the PLAINTEXT state.
If the stack of open elements does not have an element in scope with the same tag name as that of the token, then this is a parse error; ignore the token.
Otherwise, run these steps:
If the current node is not an element with the same tag name as that of the token, then this is a parse error.
Pop elements from the stack of open elements until an element with the same tag name as the token has been popped from the stack.
Let node be the element that the
form element pointer is set
to.
Set the form element pointer
to null.
If node is null or the stack of open elements does not have node in scope, then this is a parse error; ignore the token.
Otherwise, run these steps:
If the current node is not node, then this is a parse error.
Remove node from the stack of open elements.
If the stack of open elements does not have an element in scope with the same tag name as that of the token, then this is a parse error; act as if a start tag with the tag name "p" had been seen, then reprocess the current token.
Otherwise, run these steps:
Generate implied end tags, except for elements with the same tag name as the token.
If the current node is not an element with the same tag name as that of the token, then this is a parse error.
Pop elements from the stack of open elements until an element with the same tag name as the token has been popped from the stack.
If the stack of open elements does not have an element in scope with the same tag name as that of the token, then this is a parse error; ignore the token.
Otherwise, run these steps:
Generate implied end tags, except for elements with the same tag name as the token.
If the current node is not an element with the same tag name as that of the token, then this is a parse error.
Pop elements from the stack of open elements until an element with the same tag name as the token has been popped from the stack.
If the stack of open elements does not have an element in scope whose tag name is one of "h1", "h2", "h3", "h4", "h5", or "h6", then this is a parse error; ignore the token.
Otherwise, run these steps:
If the current node is not an element with the same tag name as that of the token, then this is a parse error.
Pop elements from the stack of open elements until an element whose tag name is one of "h1", "h2", "h3", "h4", "h5", or "h6" has been popped from the stack.
Take a deep breath, then act as described in the "any other end tag" entry below.
If the list of active formatting elements contains an element whose tag name is "a" between the end of the list and the last marker on the list (or the start of the list if there is no marker on the list), then this is a parse error; act as if an end tag with the tag name "a" had been seen, then remove that element from the list of active formatting elements and the stack of open elements if the end tag didn't already remove it (it might not have if the element is not in table scope).
In the non-conforming stream
<a href="a">a<table><a href="b">b</table>x,
the first a element would be closed upon seeing
the second one, and the "x" character would be inside a link
to "b", not to "a". This is despite the fact that the outer
a element is not in table scope (meaning that a
regular </a> end tag at the start of the table
wouldn't close the outer a element).
Reconstruct the active formatting elements, if any.
Insert an HTML element for the token. Add that element to the list of active formatting elements.
Reconstruct the active formatting elements, if any.
Insert an HTML element for the token. Add that element to the list of active formatting elements.
Reconstruct the active formatting elements, if any.
If the stack of open elements has a nobr element in scope,
then this is a parse error; act as if an end tag with
the tag name "nobr" had been seen, then once again
reconstruct the active formatting elements, if
any.
Insert an HTML element for the token. Add that element to the list of active formatting elements.
Follow these steps:
Let the formatting element be the last element in the list of active formatting elements that:
If there is no such node, or, if that node is also in the stack of open elements but the element is not in scope, then this is a parse error; ignore the token, and abort these steps.
Otherwise, if there is such a node, but that node is not in the stack of open elements, then this is a parse error; remove the element from the list, and abort these steps.
Otherwise, there is a formatting element and that element is in the stack and is in scope. If the element is not the current node, this is a parse error. In any case, proceed with the algorithm as written in the following steps.
Let the furthest block be the topmost node in the stack of open elements that is lower in the stack than the formatting element, and is not an element in the phrasing or formatting categories. There might not be one.
If there is no furthest block, then the UA must skip the subsequent steps and instead just pop all the nodes from the bottom of the stack of open elements, from the current node up to and including the formatting element, and remove the formatting element from the list of active formatting elements.
Let the common ancestor be the element immediately above the formatting element in the stack of open elements.
Let a bookmark note the position of the formatting element in the list of active formatting elements relative to the elements on either side of it in the list.
Let node and last node be the furthest block. Follow these steps:
If the common ancestor node is a
table, tbody, tfoot,
thead, or tr element, then,
foster parent whatever last
node ended up being in the previous step, first removing
it from its previous parent node if any.
Otherwise, append whatever last node ended up being in the previous step to the common ancestor node, first removing it from its previous parent node if any.
Perform a shallow clone of the formatting element.
Take all of the child nodes of the furthest block and append them to the clone created in the last step.
Append that clone to the furthest block.
Remove the formatting element from the list of active formatting elements, and insert the clone into the list of active formatting elements at the position of the aforementioned bookmark.
Remove the formatting element from the stack of open elements, and insert the clone into the stack of open elements immediately below the position of the furthest block in that stack.
Jump back to step 1 in this series of steps.
The way these steps are defined, only elements in the formatting category ever get cloned by this algorithm.
Because of the way this algorithm causes elements to change parents, it has been dubbed the "adoption agency algorithm" (in contrast with other possibly algorithms for dealing with misnested content, which included the "incest algorithm", the "secret affair algorithm", and the "Heisenberg algorithm").
If the stack of open elements has a button element in
scope, then this is a parse error;
act as if an end tag with the tag name "button" had been seen,
then reprocess the token.
Otherwise:
Reconstruct the active formatting elements, if any.
Insert an HTML element for the token.
Insert a marker at the end of the list of active formatting elements.
Set the frameset-ok flag to "not ok".
Reconstruct the active formatting elements, if any.
Insert an HTML element for the token.
Insert a marker at the end of the list of active formatting elements.
Set the frameset-ok flag to "not ok".
If the stack of open elements does not have an element in scope with the same tag name as that of the token, then this is a parse error; ignore the token.
Otherwise, run these steps:
If the current node is not an element with the same tag name as that of the token, then this is a parse error.
Pop elements from the stack of open elements until an element with the same tag name as the token has been popped from the stack.
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
Insert an HTML element for the token.
Set the frameset-ok flag to "not ok".
Switch the insertion mode to "in table".
Reconstruct the active formatting elements, if any.
Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.
Acknowledge the token's self-closing flag, if it is set.
Set the frameset-ok flag to "not ok".
Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.
Acknowledge the token's self-closing flag, if it is set.
If the stack of open elements has a p element in
scope, then act as if an end tag with the tag name
"p" had been seen.
Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.
Acknowledge the token's self-closing flag, if it is set.
Set the frameset-ok flag to "not ok".
Parse error. Change the token's tag name to "img" and reprocess it. (Don't ask.)
If the form element
pointer is not null, then ignore the token.
Otherwise:
Acknowledge the token's self-closing flag, if it is set.
Act as if a start tag token with the tag name "form" had been seen.
If the token has an attribute called "action", set the
action attribute on the
resulting form element to the value of the
"action" attribute of the token.
Act as if a start tag token with the tag name "hr" had been seen.
Act as if a start tag token with the tag name "p" had been seen.
Act as if a start tag token with the tag name "label" had been seen.
Act as if a stream of character tokens had been seen (see below for what they should say).
Act as if a start tag token with the tag name "input" had been
seen, with all the attributes from the "isindex" token except
"name", "action", and "prompt". Set the name attribute of the resulting
input element to the value "isindex".
Act as if a stream of character tokens had been seen (see below for what they should say).
Act as if an end tag token with the tag name "label" had been seen.
Act as if an end tag token with the tag name "p" had been seen.
Act as if a start tag token with the tag name "hr" had been seen.
Act as if an end tag token with the tag name "form" had been seen.
If the token has an attribute with the name "prompt", then the
first stream of characters must be the same string as given in
that attribute, and the second stream of characters must be
empty. Otherwise, the two streams of character tokens together
should, together with the input element, express the
equivalent of "This is a searchable index. Insert your search
keywords here: (input field)" in the user's preferred
language.
Insert an HTML element for the token.
If the next token is a U+000A LINE FEED (LF) character
token, then ignore that token and move on to the next
one. (Newlines at the start of textarea elements are
ignored as an authoring convenience.)
Switch the tokeniser's content model flag to the RCDATA state.
Let the original insertion mode be the current insertion mode.
Set the frameset-ok flag to "not ok".
Switch the insertion mode to "in CDATA/RCDATA".
Reconstruct the active formatting elements, if any.
Set the frameset-ok flag to "not ok".
Follow the generic CDATA element parsing algorithm.
Set the frameset-ok flag to "not ok".
Follow the generic CDATA element parsing algorithm.
Follow the generic CDATA element parsing algorithm.
Reconstruct the active formatting elements, if any.
Insert an HTML element for the token.
Set the frameset-ok flag to "not ok".
If the insertion mode is one of in table", "in caption", "in column group", "in table body", "in row", or "in cell", then switch the insertion mode to "in select in table". Otherwise, switch the insertion mode to "in select".
If the stack of open elements has an option element in
scope, then act as if an end tag with the tag name "option"
had been seen.
Reconstruct the active formatting elements, if any.
Insert an HTML element for the token.
If the stack of open elements has a ruby element in scope,
then generate implied end tags. If the current
node is not then a ruby element, this is a
parse error; pop all the nodes from the current
node up to the node immediately before the bottommost
ruby element on the stack of open
elements.
Insert an HTML element for the token.
Parse error. Act as if a start tag token with the tag name "br" had been seen. Ignore the end tag token.
Reconstruct the active formatting elements, if any.
Adjust MathML attributes for the token. (This fixes the case of MathML attributes that are not all lowercase.)
Adjust foreign attributes for the token. (This fixes the use of namespaced attributes, in particular XLink.)
Insert a foreign element for the token, in the MathML namespace.
If the token has its self-closing flag set, pop the current node off the stack of open elements and acknowledge the token's self-closing flag.
Otherwise, let the secondary insertion mode be the current insertion mode, and then switch the insertion mode to "in foreign content".
Reconstruct the active formatting elements, if any.
Adjust SVG attributes for the token. (This fixes the case of SVG attributes that are not all lowercase.)
Adjust foreign attributes for the token. (This fixes the use of namespaced attributes, in particular XLink in SVG.)
Insert a foreign element for the token, in the SVG namespace.
If the token has its self-closing flag set, pop the current node off the stack of open elements and acknowledge the token's self-closing flag.
Otherwise, let the secondary insertion mode be the current insertion mode, and then switch the insertion mode to "in foreign content".
Parse error. Ignore the token.
Reconstruct the active formatting elements, if any.
Insert an HTML element for the token.
This element will be a phrasing element.
Run the following steps:
Initialize node to be the current node (the bottommost node of the stack).
If node has the same tag name as the end tag token, then:
If the tag name of the end tag token does not match the tag name of the current node, this is a parse error.
Pop all the nodes from the current node up to node, including node, then stop these steps.
Otherwise, if node is in neither the formatting category nor the phrasing category, then this is a parse error; ignore the token, and abort these steps.
Set node to the previous entry in the stack of open elements.
Return to step 2.
When the insertion mode is "in CDATA/RCDATA", tokens must be handled as follows:
Insert the token's character into the current node.
If the current node is a script
element, mark the script element as "already
executed".
Pop the current node off the stack of open elements.
Switch the insertion mode to the original insertion mode and reprocess the current token.
Let script be the current node
(which will be a script element).
Pop the current node off the stack of open elements.
Switch the insertion mode to the original insertion mode.
Let the old insertion point have the same value as the current insertion point. Let the insertion point be just before the next input character.
Increment the parser's script nesting level by one.
Run the script. This might cause some script to execute, which might cause new characters to be inserted into the tokeniser, and might cause the tokeniser to output more tokens, resulting in a reentrant invocation of the parser.
Decrement the parser's script nesting level by one. If the parser's script nesting level is zero, then set the parser pause flag to false.
Let the insertion point have the value of the old insertion point. (In other words, restore the insertion point to the value it had before the previous paragraph. This value might be the "undefined" value.)
At this stage, if there is a pending external script, then:
document.write():Set the parser pause flag to true, and abort the processing of any nested invocations of the tokeniser, yielding control back to the caller. (Tokenization will resume when the caller returns to the "outer" tree construction stage.)
Follow these steps:
Let the script be the pending external script. There is no longer a pending external script.
Pause until the script has completed loading.
Let the insertion point be just before the next input character.
Let the insertion point be undefined again.
If there is once again a pending external script, then repeat these steps from step 1.
Pop the current node off the stack of open elements.
Switch the insertion mode to the original insertion mode.
When the insertion mode is "in table", tokens must be handled as follows:
If the current table is tainted, then act as described in the "anything else" entry below.
Otherwise, insert the character into the current node.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Clear the stack back to a table context. (See below.)
Insert a marker at the end of the list of active formatting elements.
Insert an HTML element for the token, then switch the insertion mode to "in caption".
Clear the stack back to a table context. (See below.)
Insert an HTML element for the token, then switch the insertion mode to "in column group".
Act as if a start tag token with the tag name "colgroup" had been seen, then reprocess the current token.
Clear the stack back to a table context. (See below.)
Insert an HTML element for the token, then switch the insertion mode to "in table body".
Act as if a start tag token with the tag name "tbody" had been seen, then reprocess the current token.
Parse error. Act as if an end tag token with the tag name "table" had been seen, then, if that token wasn't ignored, reprocess the current token.
The fake end tag token here can only be ignored in the fragment case.
If the stack of open elements does not have an element in table scope with the same tag name as the token, this is a parse error. Ignore the token. (fragment case)
Otherwise:
Pop elements from this stack until a table
element has been popped from the stack.
Parse error. Ignore the token.
If the current table is tainted then act as described in the "anything else" entry below.
Otherwise, process the token using the rules for the "in head" insertion mode.
If the token does not have an attribute with the name "type",
or if it does, but that attribute's value is not an ASCII
case-insensitive match for the string "hidden", or, if the current table is
tainted, then: act as described in the "anything
else" entry below.
Otherwise:
Insert an HTML element for the token.
Pop that input element off the stack of
open elements.
If the current node is not the root
html element, then this is a parse
error.
It can only be the current node in the fragment case.
Parse error. Process the token using the
rules for the "in
body" insertion mode, except that if the
current node is a table,
tbody, tfoot, thead, or
tr element, then, whenever a node would be inserted
into the current node, it must instead be foster parented.
When the steps above require the UA to clear the stack
back to a table context, it means that the UA must, while
the current node is not a table
element or an html element, pop elements from the
stack of open elements.
The current node being an
html element after this process is a fragment
case.
When the insertion mode is "in caption", tokens must be handled as follows:
If the stack of open elements does not have an element in table scope with the same tag name as the token, this is a parse error. Ignore the token. (fragment case)
Otherwise:
Now, if the current node is not a
caption element, then this is a parse
error.
Pop elements from this stack until a caption
element has been popped from the stack.
Clear the list of active formatting elements up to the last marker.
Switch the insertion mode to "in table".
Parse error. Act as if an end tag with the tag name "caption" had been seen, then, if that token wasn't ignored, reprocess the current token.
The fake end tag token here can only be ignored in the fragment case.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
When the insertion mode is "in column group", tokens must be handled as follows:
Insert the character into the current node.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.
Acknowledge the token's self-closing flag, if it is set.
If the current node is the root
html element, then this is a parse
error; ignore the token. (fragment
case)
Otherwise, pop the current node (which will be
a colgroup element) from the stack of open
elements. Switch the insertion mode to
"in table".
Parse error. Ignore the token.
If the current node is the root html
element, then stop parsing. (fragment
case)
Otherwise, act as described in the "anything else" entry below.
Act as if an end tag with the tag name "colgroup" had been seen, and then, if that token wasn't ignored, reprocess the current token.
The fake end tag token here can only be ignored in the fragment case.
When the insertion mode is "in table body", tokens must be handled as follows:
Clear the stack back to a table body context. (See below.)
Insert an HTML element for the token, then switch the insertion mode to "in row".
Parse error. Act as if a start tag with the tag name "tr" had been seen, then reprocess the current token.
If the stack of open elements does not have an element in table scope with the same tag name as the token, this is a parse error. Ignore the token.
Otherwise:
Clear the stack back to a table body context. (See below.)
Pop the current node from the stack of open elements. Switch the insertion mode to "in table".
If the stack of open elements does not have a
tbody, thead, or tfoot
element in table scope, this is a parse
error. Ignore the token. (fragment
case)
Otherwise:
Clear the stack back to a table body context. (See below.)
Act as if an end tag with the same tag name as the current node ("tbody", "tfoot", or "thead") had been seen, then reprocess the current token.
Parse error. Ignore the token.
Process the token using the rules for the "in table" insertion mode.
When the steps above require the UA to clear the stack
back to a table body context, it means that the UA must,
while the current node is not a tbody,
tfoot, thead, or html
element, pop elements from the stack of open
elements.
The current node being an
html element after this process is a fragment
case.
When the insertion mode is "in row", tokens must be handled as follows:
Clear the stack back to a table row context. (See below.)
Insert an HTML element for the token, then switch the insertion mode to "in cell".
Insert a marker at the end of the list of active formatting elements.
If the stack of open elements does not have an element in table scope with the same tag name as the token, this is a parse error. Ignore the token. (fragment case)
Otherwise:
Clear the stack back to a table row context. (See below.)
Pop the current node (which will be a
tr element) from the stack of open
elements. Switch the insertion mode to
"in table
body".
Act as if an end tag with the tag name "tr" had been seen, then, if that token wasn't ignored, reprocess the current token.
The fake end tag token here can only be ignored in the fragment case.
If the stack of open elements does not have an element in table scope with the same tag name as the token, this is a parse error. Ignore the token.
Otherwise, act as if an end tag with the tag name "tr" had been seen, then reprocess the current token.
Parse error. Ignore the token.
Process the token using the rules for the "in table" insertion mode.
When the steps above require the UA to clear the stack
back to a table row context, it means that the UA must,
while the current node is not a tr
element or an html element, pop elements from the
stack of open elements.
The current node being an
html element after this process is a fragment
case.
When the insertion mode is "in cell", tokens must be handled as follows:
If the stack of open elements does not have an element in table scope with the same tag name as that of the token, then this is a parse error and the token must be ignored.
Otherwise:
Now, if the current node is not an element with the same tag name as the token, then this is a parse error.
Pop elements from this stack until an element with the same tag name as the token has been popped from the stack.
Clear the list of active formatting elements up to the last marker.
Switch the insertion mode to "in row". (The
current node will be a tr element at
this point.)
If the stack of open elements does
not have
a td or th element in table
scope, then this is a parse error; ignore
the token. (fragment case)
Otherwise, close the cell (see below) and reprocess the current token.
Parse error. Ignore the token.
If the stack of open elements does not have an element in table scope with the same tag name as that of the token (which can only happen for "tbody", "tfoot" and "thead", or, in the fragment case), then this is a parse error and the token must be ignored.
Otherwise, close the cell (see below) and reprocess the current token.
Process the token using the rules for the "in body" insertion mode.
Where the steps above say to close the cell, they mean to run the following algorithm:
If the stack of open elements has a td
element in table scope, then act as if an end tag token
with the tag name "td" had been seen.
Otherwise, the stack of open elements will
have a
th element in table scope; act as if an end
tag token with the tag name "th" had been seen.
The stack of open elements cannot
have both a td and a th element in table scope at
the same time, nor can it have neither when the insertion
mode is "in
cell".
When the insertion mode is "in select", tokens must be handled as follows:
Insert the token's character into the current node.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
If the current node is an option
element, act as if an end tag with the tag name "option" had
been seen.
Insert an HTML element for the token.
If the current node is an option
element, act as if an end tag with the tag name "option" had
been seen.
If the current node is an
optgroup element, act as if an end tag with the
tag name "optgroup" had been seen.
Insert an HTML element for the token.
First, if the current node is an
option element, and the node immediately before
it in the stack of open elements is an
optgroup element, then act as if an end tag with
the tag name "option" had been seen.
If the current node is an
optgroup element, then pop that node from the
stack of open elements. Otherwise, this is a
parse error; ignore the token.
If the current node is an option
element, then pop that node from the stack of open
elements. Otherwise, this is a parse
error; ignore the token.
If the stack of open elements does not have an element in table scope with the same tag name as the token, this is a parse error. Ignore the token. (fragment case)
Otherwise:
Pop elements from the stack of open elements
until a select element has been popped from the
stack.
Parse error. Act as if the token had been an end tag with the tag name "select" instead.
Parse error. Act as if an end tag with the tag name "select" had been seen, and reprocess the token.
Process the token using the rules for the "in head" insertion mode.
If the current node is not the root
html element, then this is a parse
error.
It can only be the current node in the fragment case.
Parse error. Ignore the token.
When the insertion mode is "in select in table", tokens must be handled as follows:
Parse error. Act as if an end tag with the tag name "select" had been seen, and reprocess the token.
If the stack of open elements has an element in table scope with the same tag name as that of the token, then act as if an end tag with the tag name "select" had been seen, and reprocess the token. Otherwise, ignore the token.
Process the token using the rules for the "in select" insertion mode.
When the insertion mode is "in foreign content", tokens must be handled as follows:
Insert the token's character into the current node.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
mi element in the MathML namespace.mo element in the MathML namespace.mn element in the MathML namespace.ms element in the MathML namespace.mtext element in the MathML namespace.annotation-xml element in the MathML namespace.foreignObject element in the SVG namespace.desc element in the SVG namespace.title element in the SVG namespace.Process the token using the rules for the secondary insertion mode.
If, after doing so, the insertion mode is still "in foreign content", but there is no element in scope that has a namespace other than the HTML namespace, switch the insertion mode to the secondary insertion mode.
Pop elements from the stack of open elements until the current node is in the HTML namespace.
Switch the insertion mode to the secondary insertion mode, and reprocess the token.
If the current node is an element in the MathML namespace, adjust MathML attributes for the token. (This fixes the case of MathML attributes that are not all lowercase.)
If the current node is an element in the SVG namespace, and the token's tag name matches in a case-insensitive manner an element name specified in SVG 1.1 [SVG11], SVG Tiny 1.2 [SVGT12], change the tag name to the case-sensitive equivalent.
If the current node is an element in the SVG namespace, and the token's tag name matches in a case-insensitive manner an element name from any later SVG specification recognized by the user agent, change the tag name to the case-sensitive equivalent.
(This fixes the case of SVG elements that are not all lowercase.)
If the current node is an element in the SVG namespace, adjust SVG attributes for the token. (This fixes the case of SVG attributes that are not all lowercase.)
Contrast this prose with the original proposal.
Adjust foreign attributes for the token. (This fixes the use of namespaced attributes, in particular XLink in SVG.)
Insert a foreign element for the token, in the same namespace as the current node.
If the token has its self-closing flag set, pop the current node off the stack of open elements and acknowledge the token's self-closing flag.
When the insertion mode is "after body", tokens must be handled as follows:
Process the token using the rules for the "in body" insertion mode.
Append a Comment node to the first element in
the stack of open elements (the html
element), with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
If the parser was originally created as part of the HTML fragment parsing algorithm, this is a parse error; ignore the token. (fragment case)
Otherwise, switch the insertion mode to "after after body".
Parse error. Switch the insertion mode to "in body" and reprocess the token.
When the insertion mode is "in frameset", tokens must be handled as follows:
Insert the character into the current node.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
Insert an HTML element for the token.
If the current node is the root
html element, then this is a parse
error; ignore the token. (fragment
case)
Otherwise, pop the current node from the stack of open elements.
If the parser was not originally created as part
of the HTML fragment parsing algorithm
(fragment case), and the current
node is no longer a frameset element, then
switch the insertion mode to "after
frameset".
Insert an HTML element for the token. Immediately pop the current node off the stack of open elements.
Acknowledge the token's self-closing flag, if it is set.
Process the token using the rules for the "in head" insertion mode.
If the current node is not the root
html element, then this is a parse
error.
It can only be the current node in the fragment case.
Parse error. Ignore the token.
When the insertion mode is "after frameset", tokens must be handled as follows:
Insert the character into the current node.
Append a Comment node to the current
node with the data attribute set to
the data given in the comment token.
Parse error. Ignore the token.
Process the token using the rules for the "in body" insertion mode.
Switch the insertion mode to "after after frameset".
Process the token using the rules for the "in head" insertion mode.
Parse error. Ignore the token.
This doesn't handle UAs that don't support frames, or that do support frames but want to show the NOFRAMES content. Supporting the former is easy; supporting the latter is harder.
When the insertion mode is "after after body", tokens must be handled as follows:
Append a Comment node to the Document
object with the data attribute set to the
data given in the comment token.
Process the token using the rules for the "in body" insertion mode.
Parse error. Switch the insertion mode to "in body" and reprocess the token.
When the insertion mode is "after after frameset", tokens must be handled as follows:
Append a Comment node to the Document
object with the data attribute set to the
data given in the comment token.
Process the token using the rules for the "in body" insertion mode.
Process the token using the rules for the "in head" insertion mode.
Parse error. Ignore the token.
Once the user agent stops parsing the document, the user agent must follow the steps in this section.
First, the current document readiness must be set to "interactive".
Then, the rules for when a script completes loading start applying (script execution is no longer managed by the parser).
If any of the scripts in the list of scripts that will
execute as soon as possible have completed
loading, or if the list of scripts that will execute
asynchronously is not empty and the first script in that list
has completed loading, then the user agent must act as
if those scripts just completed loading, following the rules given
for that in the script element definition.
Then, if the list of scripts that will execute when the document has finished parsing is not empty, and the first item in this list has already completed loading, then the user agent must act as if that script just finished loading.
By this point, there will be no scripts that have loaded but have not yet been executed.
The user agent must then fire a simple event called
DOMContentLoaded at the
Document.
Once everything that delays the load event has completed, the user agent must run the following steps:
Document is in a browsing
context, then queue a task to fire a load
event at the Document's Window
object.Document has a pending state
object, then queue a task to fire a popstate event in no namespace on the
Document's Window object using the
PopStateEvent interface, with the state attribute set to the
current value of the pending state object. This event
must bubble but not be cancelable and has no default action.The task source for these tasks is the DOM manipulation task source.
delaying the load event for things like image loads allows for intranet port scans (even without javascript!). Should we really encode that into the spec?
When an application uses an HTML parser in
conjunction with an XML pipeline, it is possible that the
constructed DOM is not compatible with the XML tool chain in certain
subtle ways. For example, an XML toolchain might not be able to
represent attributes with the name xmlns,
since they conflict with the Namespaces in XML syntax. There is also
some data that the HTML parser generates that isn't
included in the DOM itself. This section specifies some rules for
handling these issues.
If the XML API being used doesn't support DOCTYPEs, the tool may drop DOCTYPEs altogether.
If the XML API doesn't support attributes in no namespace that
are named "xmlns", attributes whose names
start with "xmlns:", or attributes in the
XMLNS namespace, then the tool may drop such
attributes.
The tool may annotate the output with any namespace declarations required for proper operation.
If the XML API being used restricts the allowable characters in the local names of elements and attributes, then the tool may map all element and attribute local names that the API wouldn't support to a set of names that are allowed, by replacing any character that isn't supported with the uppercase letter U and the six digits of the character's Unicode codepoint when expressed in hexadecimal, using digits 0-9 and capital letters A-F as the symbols, in increasing numeric order.
For example, the element name foo<bar, which can be output by the HTML
parser, though it is neither a legal HTML element name nor a
well-formed XML element name, would be converted into fooU00003Cbar, which is a well-formed XML
element name (though it's still not legal in HTML by any means).
As another example, consider the attribute
xlink:href. Used on a MathML element, it becomes, after
being adjusted, an
attribute with a prefix "xlink" and a local
name "href". However, used on an HTML element,
it becomes an attribute with no prefix and the local name "xlink:href", which is not a valid NCName, and thus
might not be accepted by an XML API. It could thus get converted,
becoming "xlinkU00003Ahref".
The resulting names from this conversion conveniently can't clash with any attribute generated by the HTML parser, since those are all either lowercase or those listed in the adjust foreign attributes algorithm's table.
If the XML API restricts comments from having two consecutive U+002D HYPHEN-MINUS characters (--), the tool may insert a single U+0020 SPACE character between any such offending characters.
If the XML API restricts comments from ending in a U+002D HYPHEN-MINUS character (-), the tool may insert a single U+0020 SPACE character at the end of such comments.
If the XML API restricts allowed characters in character data, the tool may replace any U+000C FORM FEED (FF) character with a U+0020 SPACE character, and any other literal non-XML character with a U+FFFD REPLACEMENT CHARACTER.
If the tool has no way to convey out-of-band information, then the tool may drop the following information:
form element ancestor (use of the
form element pointer in the parser)The mutations allowed by this section apply
after the HTML parser's rules have been
applied. For example, a <a::> start tag
will be closed by a </a::> end tag, and
never by a </aU00003AU00003A> end tag, even
if the user agent is using the rules above to then generate an
actual element in the DOM with the name aU00003AU00003A for that start tag.
The HTML namespace is: http://www.w3.org/1999/xhtml
The MathML namespace is: http://www.w3.org/1998/Math/MathML
The SVG namespace is: http://www.w3.org/2000/svg
The XLink namespace is: http://www.w3.org/1999/xlink
The XML namespace is: http://www.w3.org/XML/1998/namespace
The XMLNS namespace is: http://www.w3.org/2000/xmlns/
Data mining tools and other user agents that perform operations
on text/html content without running scripts,
evaluating CSS or XPath expressions, or otherwise exposing the
resulting DOM to arbitrary content, may "support namespaces" by just
asserting that their DOM node analogues are in certain namespaces,
without actually exposing the above strings.
The following steps form the HTML fragment serialization
algorithm. The algorithm takes as input a DOM
Element or Document, referred to as the node, and either returns a string or raises an
exception.
This algorithm serializes the children of the node being serialized, not the node itself.
Let s be a string, and initialize it to the empty string.
For each child node of the node, in tree order, run the following steps:
Let current node be the child node being processed.
Append the appropriate string from the following list to s:
ElementAppend a U+003C LESS-THAN SIGN (<)
character, followed by the element's tag name. (For nodes
created by the HTML parser, Document.createElement(), or Document.renameNode(), the tag name will be
lowercase.)
For each attribute that the element has, append a U+0020
SPACE character, the attribute's name (which, for attributes
set by the HTML parser or by Element.setAttributeNode() or Element.setAttribute(), will be lowercase), a
U+003D EQUALS SIGN (=) character, a
U+0022 QUOTATION MARK (")
character, the attribute's value, escaped as described below in attribute
mode, and a second U+0022 QUOTATION MARK (") character.
While the exact order of attributes is UA-defined, and may depend on factors such as the order that the attributes were given in the original markup, the sort order must be stable, such that consecutive invocations of this algorithm serialize an element's attributes in the same order.
Append a U+003E GREATER-THAN SIGN (>)
character.
If current node is an
area, base, basefont,
bgsound, br, col,
embed, frame, hr,
img, input, link,
meta, param, spacer, or
wbr element, then continue on to the next child
node at this point.
If current node is a pre,
textarea, or listing element, append
a U+000A LINE FEED (LF) character.
Append the value of running the HTML fragment
serialization algorithm on the current
node element (thus recursing into this algorithm for
that element), followed by a U+003C LESS-THAN SIGN (<) character, a U+002F SOLIDUS (/) character, the element's tag name again,
and finally a U+003E GREATER-THAN SIGN (>) character.
Text or CDATASection
nodeIf one of the ancestors of current node
is a style, script,
xmp, iframe, noembed,
noframes, noscript, or
plaintext element, then append the value of current node's data DOM
attribute literally.
Otherwise, append the value of current
node's data DOM attribute, escaped as described
below.
CommentAppend the literal string <!-- (U+003C
LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+002D HYPHEN-MINUS,
U+002D HYPHEN-MINUS), followed by the value of current node's data DOM
attribute, followed by the literal string -->
(U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN
SIGN).
ProcessingInstructionAppend the literal string <? (U+003C
LESS-THAN SIGN, U+003F QUESTION MARK), followed by the value
of current node's target DOM attribute, followed by a single
U+0020 SPACE character, followed by the value of current node's data DOM
attribute, followed by a single U+003E GREATER-THAN SIGN
character ('>').
DocumentTypeAppend the literal string <!DOCTYPE (U+003C
LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+0044 LATIN CAPITAL
LETTER D, U+004F LATIN CAPITAL LETTER O, U+0043 LATIN CAPITAL
LETTER C, U+0054 LATIN CAPITAL LETTER T, U+0059 LATIN CAPITAL
LETTER Y, U+0050 LATIN CAPITAL LETTER P, U+0045 LATIN CAPITAL
LETTER E), followed by a space (U+0020 SPACE), followed by the
value of current node's name DOM attribute, followed by the literal
string > (U+003E GREATER-THAN SIGN).
Other node types (e.g. Attr) cannot
occur as children of elements. If, despite this, they somehow do
occur, this algorithm must raise an
INVALID_STATE_ERR exception.
The result of the algorithm is the string s.
Escaping a string (for the
purposes of the algorithm above) consists of replacing any
occurrences of the "&" character by the
string "&", any occurrences of the
U+00A0 NO-BREAK SPACE character by the string " ", and, if the algorithm was invoked in
the attribute mode, any occurrences of the """ character by the string """, or if it was not, any occurrences of
the "<" character by the string "<", any occurrences of the ">" character by the string ">".
Entity reference nodes are assumed to be expanded by the user agent, and are therefore not covered in the algorithm above.
It is possible that the output of this algorithm, if
parsed with an HTML parser, will not return the
original tree structure. For instance, if a textarea
element to which a Comment node has been
appended is serialized and the output is then reparsed, the comment
will end up being displayed in the text field. Similarly, if, as a
result of DOM manipulation, an element contains a comment that
contains the literal string "-->", then
when the result of serializing the element is parsed, the comment
will be truncated at that point and the rest of the comment will be
interpreted as markup. More examples would be making a
script element contain a text node with the text string
"</script>", or having a p element that
contains a ul element (as the ul element's
start tag would imply the end
tag for the p).
The following steps form the HTML fragment parsing
algorithm. The algorithm optionally takes as input an
Element node, referred to as the context element, which gives the context for the
parser, as well as input, a string to parse, and
returns a list of zero or more nodes.
Parts marked fragment case in algorithms in the parser section are parts that only occur if the parser was created for the purposes of this algorithm (and with a context element). The algorithms have been annotated with such markings for informational purposes only; such markings have no normative weight. If it is possible for a condition described as a fragment case to occur even when the parser wasn't created for the purposes of handling this algorithm, then that is an error in the specification.
Create a new Document node, and mark it as being
an HTML document.
Create a new HTML parser, and associate it with
the just created Document node.
If there is a context element, run these substeps:
Set the HTML parser's tokenization stage's content model flag according to the context element, as follows:
title or textarea
elementstyle, script,
xmp, iframe, noembed, or
noframes elementnoscript elementplaintext elementLet root be a new html element
with no attributes.
Append the element root to the
Document node created above.
Set up the parser's stack of open elements so that it contains just the single element root.
Reset the parser's insertion mode appropriately.
The parser will reference the context element as part of that algorithm.
Set the parser's form element pointer
to the nearest node to the context element
that is a form element (going straight up the
ancestor chain, and including the element itself, if it is a
form element), or, if there is no such
form element, to null.
Place into the input stream for the HTML parser just created the input. The encoding confidence is irrelevant.
Start the parser and let it run until it has consumed all the characters just inserted into the input stream.
If there is a context element, return the child nodes of root, in tree order.
Otherwise, return the children of the Document
object, in tree order.
This section only describes the rules for XML
resources. Rules for text/html resources are
discussed in the section above entitled "The HTML
syntax".
The syntax for using HTML with XML, whether in XHTML documents or embedded in other XML documents, is defined in the XML and Namespaces in XML specifications. [XML] [XMLNS]
This specification does not define any syntax-level requirements beyond those defined for XML proper.
XML documents may contain a DOCTYPE if desired, but
this is not required to conform to this specification. This
specification does not define a public or system identifier, nor
provide a format DTD.
According to the XML specification, XML processors
are not guaranteed to process the external DTD subset referenced in
the DOCTYPE. This means, for example, that using entity references
for characters in XHTML documents is unsafe if they are defined in
an external file (except for <, >, &, " and ').
This section describes the relationship between XML and the DOM, with a particular emphasis on how this interacts with HTML.
An XML parser, for the purposes of this specification,
is a construct that follows the rules given in the XML specification
to map a string of bytes or characters into a Document
object.
An XML parser is either associated with a
Document object when it is created, or creates one
implicitly.
This Document must then be populated with DOM nodes
that represent the tree structure of the input passed to the parser,
as defined by the XML specification, the Namespaces in XML
specification, and the DOM Core specification. DOM mutation events
must not fire for the operations that the XML parser
performs on the Document's tree, but the user agent
must act as if elements and attributes were individually appended
and set respectively so as to trigger rules in this specification
regarding what happens when an element in inserted into a document
or has its attributes set. [XML] [XMLNS] [DOMCORE]
[DOMEVENTS]
Certain algorithms in this specification spoon-feed the parser characters one string at a time. In such cases, the XML parser must act as it would have if faced with a single string consisting of the concatenation of all those characters.
When an XML parser creates a script
element, it must be marked as being "parser-inserted".
If the parser was originally created for the XML fragment
parsing algorithm, then the element must be marked as
"already executed" also. When the element's end tag is
parsed, the user agent must run the script element. If this causes
there to be a pending external script, then the user
agent must pause until that script has completed
loading, and then execute it.
Since the document.write() API is not
available for XML documents, much of the complexity in
the HTML parser is not needed in the XML
parser.
When an XML parser reaches the end of its input, it must stop parsing, following the same rules as the HTML parser.
The XML fragment serialization algorithm for a
Document or Element node either returns a
fragment of XML that represents that node or raises an
exception.
For Documents, the algorithm must return a string in
the form of a document
entity, if none of the error cases below apply.
For Elements, the algorithm must return a string in
the form of an internal general parsed
entity, if none of the error cases below apply.
In both cases, the string returned must be XML namespace-well-formed and must be an isomorphic serialization of all of that node's child nodes, in tree order. User agents may adjust prefixes and namespace declarations in the serialization (and indeed might be forced to do so in some cases to obtain namespace-well-formed XML).
For Elements, if any of the elements in the
serialization are in no namespace, the default namespace in scope
for those elements must be explicitly declared as the empty
string. (This doesn't
apply in the Document case.) [XML] [XMLNS]
If any of the following error cases are found in the DOM subtree
being serialized, then the algorithm raises an
INVALID_STATE_ERR exception instead of returning a
string:
Document node with no child element nodes.DocumentType node that has an external subset
public identifier that contains characters that are not matched by
the XML PubidChar production. [XML]DocumentType node that has an external subset
system identifier that contains both a U+0022 QUOTATION MARK ('"')
and a U+0027 APOSTROPHE ("'").Attr node, Text node,
CDATASection node, Comment node, or
ProcessingInstruction node whose data contains
characters that are not matched by the XML Char production. [XML]CDATASection node whose data contains the string
"]]>".Comment node whose data contains two adjacent
U+002D HYPHEN-MINUS (-) characters or ends with such a
character.ProcessingInstruction node whose target name is
an ASCII case-insensitive match for the string "xml".ProcessingInstruction node whose target name
contains a U+003A COLON (":").ProcessingInstruction node whose data contains
the string "?>".These are the only ways to make a DOM
unserializable. The DOM enforces all the other XML constraints; for
example, trying to set an attribute with a name that contains an
equals sign (=) will raised an INVALID_CHARACTER_ERR
exception.
The XML fragment parsing algorithm for either returns
a Document or raises a SYNTAX_ERR
exception. Given a string input and an optional
context element context, the algorithm is as
follows:
Create a new XML parser.
If there is a context element, feed the parser just created the string corresponding to the start tag of that element, declaring all the namespace prefixes that are in scope on that element in the DOM, as well as declaring the default namespace (if any) that is in scope on that element in the DOM.
A namespace prefix is in scope if the DOM Core lookupNamespaceURI() method on the element would
return a non-null value for that prefix.
The default namespace is the namespace for which the DOM Core
isDefaultNamespace() method on the element
would return true.
Feed the parser just created the string input.
If there is a context element, feed the parser just created the string corresponding to the end tag of that element.
If there is an XML well-formedness or XML namespace
well-formedness error, then raise a SYNTAX_ERR
exception and abort these steps.
If there is a context element, then return
the child nodes of the root element of the resulting
Document, in tree order.
Otherwise, return the children of the Document
object, in tree order.
User agents are not required present HTML documents in any particular way. However, this section provides a set of suggestions for rendering HTML documents that, if followed, are likely to lead to a user experience that closely resembles the experience intended by the documents' authors. So as to avoid confusion regarding the normativity of this section, RFC2119 terms have not been used. Instead, the term "expected" is used to indicate behavior that will lead to this experience.
In general, user agents are expected to support CSS, and many of the suggestions in this section are expressed in CSS terms. User agents that use other presentation mechanisms can derive their expected behavior by translating from the CSS rules given in this section.
In the absence of style-layer rules to the contrary (e.g. author style sheets), user agents are expected to render an element so that it conveys to the user the meaning that the element represents, as described by this specification.
The suggestions in this section generally assume a visual output medium with a resolution of 96dpi or greater, but HTML is intended to apply to multiple media (it is a media-independent language). User agents are encouraged to adapt the suggestions in this section to their target media.
The CSS rules given in these subsections are, unless otherwise specified, expected to be used as part of the user-agent level style sheet defaults for all documents that contain HTML elements.
Some rules are intended for the author-level zero-specificity presentational hints part of the CSS cascade; these are explicitly called out as presentational hints.
Some of the rules regarding left and right margins are given here as appropriate for elements whose 'direction' property is 'ltr', and are expected to be flipped around on elements whose 'direction' property is 'rtl'. These are marked "LTR-specific".
When the text below says that an attribute attribute on an element element maps to the pixel length property (or properties) properties, it means that if element has an attribute attribute set, and parsing that attribute's value using the rules for parsing non-negative integers doesn't generate an error, then the user agent is expected to use the parsed value as a pixel length for a presentational hint for properties.
When the text below says that an attribute attribute on an element element maps to the dimension property (or properties) properties, it means that if element has an attribute attribute set, and parsing that attribute's value using the rules for parsing dimension values doesn't generate an error, then the user agent is expected to use the parsed dimension as the value for a presentational hint for properties, with the value given as a pixel length if the dimension was an integer, and with the value given as a percentage if the dimension was a percentage.
@namespace url(http://www.w3.org/1999/xhtml);
[hidden], area, audio:not([controls]), base, basefont, command,
datalist, head, input[type=hidden], link, menu[type=context], meta,
noembed, noframes, param, script, source, style, title {
display: none;
}
address, article, aside, blockquote, body, center, dd, dialog, dir,
div, dl, dt, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hr,
html, legend, listing, menu, nav, ol, p, plaintext, pre, rp, section,
ul, xmp { display: block; }
table { display: table; }
caption { display: table-caption; }
colgroup { display: table-column-group; }
col { display: table-column; }
thead { display: table-header-group; }
tbody { display: table-row-group; }
tfoot { display: table-footer-group; }
tr { display: table-row; }
td, th { display: table-cell; }
li { display: list-item; }
ruby { display: ruby; }
rt { display: ruby-text; }
For the purposes of the CSS table model, the col
element is to be treated as if it was present as many times as its
span attribute specifies.
For the purposes of the CSS table model, the
colgroup element, if it contains no col
element, is to be treated as if it had as many such children as its
span attribute specifies.
For the purposes of the CSS table model, the colspan and rowspan attributes on
td and th elements are expected to provide the
special knowledge regarding cells spanning rows and
columns.
For the purposes of the CSS ruby model, runs of descendants of
ruby elements that are not rt or
rp elements are expected to be wrapped in anonymous
boxes whose 'display' property has the value 'ruby-base'.
User agents that do not support correct ruby rendering are
expected to render parentheses around the text of rt
elements in the absence of rp elements.
The br element is expected to render as if its
contents were a single U+000A LINE FEED (LF) character and its
'white-space' property was 'pre'.
The user agent is expected to hide noscript elements
for whom scripting is
disabled, irrespective of CSS rules.
@namespace url(http://www.w3.org/1999/xhtml);
article, aside, blockquote, dir, dl, figure, listing, menu, nav, ol,
p, plaintext, pre, section, ul, xmp {
margin-top: 1em; margin-bottom: 1em;
}
dir dir, dir dl, dir menu, dir ol, dir ul,
dl dir, dl dl, dl menu, dl ol, dl ul,
menu dir, menu dl, menu menu, menu ol, menu ul,
ol dir, ol dl, ol menu, ol ol, ol ul,
ul dir, ul dl, ul menu, ul ol, ul ul {
margin-top: 0; margin-bottom: 0;
}
h1 { margin-top: 0.67em; margin-bottom; 0.67em; }
h2 { margin-top: 0.83em; margin-bottom; 0.83em; }
h3 { margin-top: 1.00em; margin-bottom; 1.00em; }
h4 { margin-top: 1.33em; margin-bottom; 1.33em; }
h5 { margin-top: 1.67em; margin-bottom; 1.67em; }
h6 { margin-top: 2.33em; margin-bottom; 2.33em; }
dd { margin-left: 40px; } /* LTR-specific: use 'margin-right' for rtl elements */
dir, menu, ol, ul { padding-left: 40px; } /* LTR-specific: use 'padding-right' for rtl elements */
blockquote, figure { margin-left: 40px; margin-right: 40px; }
table { border-spacing: 2px; border-collapse: separate; }
td, th { padding: 1px; }
For each property in the table below, given a body
element, the first attribute that exists maps to the pixel
length property on the body element. If none of
the attributes for a property are found, or if the value of the
attribute that was found cannot be parsed successfully, then a
default value of 8px is expected to be used for that property
instead.
| Property | Source |
|---|---|
| 'margin-top' | body element's marginheight attribute
|
The body element's container frame element's marginheight attribute
| |
body element's topmargin attribute
| |
| 'margin-right' | body element's marginwidth attribute
|
The body element's container frame element's marginwidth attribute
| |
body element's rightmargin attribute
| |
| 'margin-bottom' | body element's marginheight attribute
|
The body element's container frame element's marginheight attribute
| |
body element's topmargin attribute
| |
| 'margin-left' | body element's marginwidth attribute
|
The body element's container frame element's marginwidth attribute
| |
body element's rightmargin attribute
|
If the body element's Document's
browsing context is a nested browsing
context, and the browsing context container of
that nested browsing context is a frame or
iframe element, then the the container frame
element of the body element is that
frame or iframe element. Otherwise, there
is no container frame element.
If the Document has a root element, and
the Document's browsing context is a
nested browsing context, and the browsing context
container of that nested browsing context is a
frame or iframe element, and that element
has a scrolling
attribute, then the user agent is expected to compare the value of
the attribute in an ASCII case-insensitive manner to
the values in the first column of the following table, and if one of
them matches, then the user agent is expected to treat that
attribute as a presentational
hint for the aforementioned root element's 'overflow'
property, setting it to the value given in the corresponding cell on
the same row in the second column:
| Attribute value | 'overflow' value |
|---|---|
on
| 'scroll' |
scroll
| 'scroll' |
yes
| 'scroll' |
off
| 'hidden' |
noscroll
| 'hidden' |
no
| 'hidden' |
auto
| 'auto' |
The table element's cellspacing attribute
maps to the pixel length property 'border-spacing' on the
element.
The table element's cellpadding attribute maps to the pixel length
properties 'padding-top', 'padding-right', 'padding-bottom',
and 'padding-left' of any td and th
elements that have corresponding cells in the table corresponding to the
table element.
The table element's hspace attribute maps to the dimension properties
'margin-left' and 'margin-right' on the table
element.
The table element's vspace attribute maps to the dimension properties
'margin-top' and 'margin-bottom' on the table
element.
The table element's height attribute maps to the
dimension property 'height' on the table
element.
The table element's width attribute maps to the
dimension property 'width' on the table
element.
The col element's width attribute maps to the
dimension property 'width' on the col
element.
The tr element's height attribute maps to the
dimension property 'height' on the tr
element.
The td and th elements' height attributes map to the dimension property 'height'
on the element.
The td and th elements' width attributes map to the dimension property 'width'
on the element.
In quirks mode, the following rules are also expected to apply:
@namespace url(http://www.w3.org/1999/xhtml);
form { margin-bottom: 1em; }
When a Document is in quirks mode,
margins on HTML elements that collapse with the top or
bottom of the initial containing block, or the top of bottom of
td or th elements, are expected to be
collapsed to zero.
@namespace url(http://www.w3.org/1999/xhtml);
thead, tbody, tfoot, table > tr { vertical-align: middle; }
tr, td, th { vertical-align: inherit; }
sub { vertical-align: sub; }
sup { vertical-align: super; }
th { text-align: center; }
The following rules are also expected to apply, as presentational hints:
@namespace url(http://www.w3.org/1999/xhtml);
table[align=left] { float: left; }
table[align=right] { float: right; }
table[align=center], table[align=abscenter],
table[align=abdmiddle], table[align=middle] {
margin-left: auto; margin-right: auto;
}
caption[align=bottom] { caption-side: bottom; }
p[align=left], h1[align=left], h2[align=left], h3[align=left],
h4[align=left], h5[align=left], h6[align=left] {
text-align: left;
}
p[align=right], h1[align=right], h2[align=right], h3[align=right],
h4[align=right], h5[align=right], h6[align=right] {
text-align: right;
}
p[align=center], h1[align=center], h2[align=center], h3[align=center],
h4[align=center], h5[align=center], h6[align=center] {
text-align: center;
}
p[align=justify], h1[align=justify], h2[align=justify], h3[align=justify],
h4[align=justify], h5[align=justify], h6[align=justify] {
text-align: justify;
}
col[valign=top], thead[valign=top], tbody[valign=top],
tfoot[valign=top], tr[valign=top], td[valign=top], th[valign=top] {
vertial-align: top;
}
col[valign=middle], thead[valign=middle], tbody[valign=middle],
tfoot[valign=middle], tr[valign=middle], td[valign=middle], th[valign=middle] {
vertial-align: middle;
}
col[valign=bottom], thead[valign=bottom], tbody[valign=bottom],
tfoot[valign=bottom], tr[valign=bottom], td[valign=bottom], th[valign=bottom] {
vertial-align: bottom;
}
col[valign=baseline], thead[valign=baseline], tbody[valign=baseline],
tfoot[valign=baseline], tr[valign=baseline], td[valign=baseline], th[valign=baseline] {
vertial-align: baseline;
}
The center element, the caption element
unless specified otherwise below, and the div element
when its align attribute's value
is an ASCII case-insensitive match for the string
"center", are expected to center text within
themselves, as if they had their 'text-align' property set to
'center' in a presentational
hint, and to align descendants to the center.
The div, caption, thead,
tbody, tfoot, tr,
td, and th elements, when they have an
align attribute whose value is an
ASCII case-insensitive match for the string "left", are expected to left-align text within
themselves, as if they had their 'text-align' property set to 'left'
in a presentational hint,
and to align descendants to the left.
The div, caption, thead,
tbody, tfoot, tr,
td, and th elements, when they have an
align attribute whose value is an
ASCII case-insensitive match for the string "right", are expected to right-align text within
themselves, as if they had their 'text-align' property set to
'right' in a presentational
hint, and to align descendants to the right.
The div, caption, thead,
tbody, tfoot, tr,
td, and th elements, when they have an
align attribute whose value is an
ASCII case-insensitive match for the string "justify", are expected to full-justify text within
themselves, as if they had their 'text-align' property set to
'justify' in a presentational
hint, and to align descendants to the left.
When a user agent is to align descendants of a node,
the user agent is expected to align only those descendants that have
both their 'margin-left' and 'margin-right' properties computing to
a value other than 'auto', that are over-constrained and that have
one of those two margins with a used value forced to a greater
value, and that do not themselves have an applicable align attribute.
The initial value for the 'color' property is expected to be black. The initial value for the 'background-color' property is expected to be 'transparent'. The canvas's background is expected to be white.
The article, aside, nav,
and section elements are expected to affect the styling
of h1 elements, based on the nesting depth. If x is a selector that matches elements that are either
article, aside, nav, or
section elements, then the following rules capture what
is expected:
@namespace url(http://www.w3.org/1999/xhtml);
x h1 { font-size: 1.50em; }
x x h1 { font-size: 1.17em; }
x x x h1 { font-size: 1.00em; }
x x x x h1 { font-size: 0.83em; }
x x x x x h1 { font-size: 0.67em; }
When a body, table, thead,
tbody, tfoot, tr,
td, or th element has a background attribute set to a
non-empty value, the new value is expected to be resolved relative to the element, and
if this is successful, the user agent is expected to treat the
attribute as a presentational
hint setting the element's 'background-image' property to the
resulting absolute URL.
When a body, table, thead,
tbody, tfoot, tr,
td, or th element has a bgcolor attribute set, the new value is
expected to be parsed using the rules for parsing a legacy
color value, and the user agent is expected to treat the
attribute as a presentational
hint setting the element's 'background-color' property to the
resulting color.
When a body element has a text attribute, its value is expected
to be parsed using the rules for parsing a legacy color
value, and the user agent is expected to treat the attribute
as a presentational hint
setting the element's 'color' property to the resulting color.
When a body element has a link attribute, its value is expected
to be parsed using the rules for parsing a legacy color
value, and the user agent is expected to treat the attribute
as a presentational hint
setting the 'color' property of any element in the
Document matching the ':link' pseudo-class to the
resulting color.
When a body element has a vlink attribute, its value is
expected to be parsed using the rules for parsing a legacy
color value, and the user agent is expected to treat the
attribute as a presentational
hint setting the 'color' property of any element in the
Document matching the ':visited' pseudo-class to the
resulting color.
When a body element has a alink attribute, its value is
expected to be parsed using the rules for parsing a legacy
color value, and the user agent is expected to treat the
attribute as a presentational
hint setting the 'color' property of any element in the
Document matching the ':active' pseudo-class and either
the ':link' pseudo-class or the ':visited' pseudo-class to the
resulting color.
When a table element has a bordercolor attribute, its
value is expected to be parsed using the rules for parsing a
legacy color value, and the user agent is expected to treat
the attribute as a presentational
hint setting the element's 'border-top-color',
'border-right-color', 'border-bottom-color', and
'border-right-color' properties to the resulting color.
When a font element has a color attribute, its value is
expected to be parsed using the rules for parsing a legacy
color value, and the user agent is expected to treat the
attribute as a presentational
hint setting the element's 'color' property to the resulting
color.
When a font element has a face attribute, the user agent is
expected to treat the attribute as a presentational hint setting the element's
'font-family' property to the attribute's value.
When a font element has a pointsize attribute, the user
agent is expected to parse that attribute's value using the
rules for parsing non-negative integers, and if this
doesn't generate an error, then the user agent is expected to use
the parsed value as a point length for a presentational hint for the
'font-size' property on the element.
When a font element has a size attribute, the user agent is
expected to use the following steps to treat the attribute as a
presentational hint
setting the element's 'font-size' property:
Let input be the attribute's value.
Let position be a pointer into input, initially pointing at the start of the string.
If position is past the end of input, there is no presentational hint. Abort these steps.
If the character at position is a U+002B PLUS SIGN character (+), then let mode be relative-plus, and advance position to the next character. Otherwise, if the character at position is a U+002D HYPHEN-MINUS character (-), then let mode be relative-minus, and advance position to the next character. Otherwise, let mode be absolute.
Collect a sequence of characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), and let the resulting sequence be digits.
If digits is the empty string, there is no presentational hint. Abort these steps.
Interpret digits as a base-ten integer. Let size be the resulting number.
If mode is is relative-plus, then increment value by 3. If mode is is relative-minus, then decrement value by 3.
If value is greater than 7, let it be 7.
If value is less than 1, let it be 1.
Set 'font-size' to the keyword corresponding to the value of value according to the following table:
| value | 'font-size' keyword | Notes |
|---|---|---|
| 1 | xx-small | |
| 2 | small | |
| 3 | medium | |
| 4 | large | |
| 5 | x-large | |
| 6 | xx-large | |
| 7 | xxx-large | see below |
The 'xxx-large' value is a non-CSS value used here to indicate a font size one "step" larger than 'xx-large'.
The applet, canvas, embed,
iframe, and video elements are expected to
be treated as replaced elements.
An object element that represents an
image, plugin, or nested browsing context is expected
to be treated as a replaced element. Other object
elements are expected to be treated as ordinary elements in the
rendering model.
The audio element, when it has a controls attribute, is expected
to be treated as a replaced element about one line high, as wide as
is necessary to expose the user agent's user interface features.
The video element's controls attribute is not
expected to affect the size of the rendering; controls are expected
to be overlaid with the page content without causing any layout
changes, and are expected to disappear when the user does not need
them.
Resizing video and canvas
elements does not interrupt video playback or clear the canvas.
The following CSS rules are expected to apply:
@namespace url(http://www.w3.org/1999/xhtml);
iframe { border: 2px inset; }
When an img element or an input element
when its type attribute is in
the Image Button state
represents an image, it is expected to be treated as a
replaced element.
When an img element or an input element
when its type attribute is in
the Image Button state
does not represent an image, but the
element already has instrinsic dimensions (e.g. from the
dimension attributes or CSS rules), and either the user
agent has reason to believe that the image will become
available and be rendered in due course or the
Document is in quirks mode, the element is
expected to be treated as a replaced element whose content is the
text that the element represents, if any, optionally alongside an
icon indicating that the image is being obtained. For
input elements, the text is expected to appear
button-like to indicate that the element is a button.
When an img element represents some
text and the user agent does not expect this to change, the element
is expected to be treated as an inline element whose content is the
text, optionally with an icon indicating that an image is
missing.
When an img element represents nothing
and the user agent does not expect this to change, the element is
expected to not be rendered at all.
When an img element might be a key part of the
content, but neither the image nor any kind of alternative text is
available, and the user agent does not expect this to change, the
element is expected to be treated as an inline element whose content
is an icon indicating that an image is missing.
When an input element whose type attribute is in the Image Button state does not
represent an image and the user
agent does not expect this to change, the element is expected to be
treated as a replaced element consisting of a button whose content
is the element's alternative text. The intrinsic dimensions of the
button are expected to be about one line in height and whatever
width is necessary to render the text on one line.
The icons mentioned above are expected to be relatively small so as not to disrupt most text but be easily clickable. In a visual environment, for instance, icons could be 16 pixels by 16 pixels square, or 1em by 1em if the images are scalable. In an audio environment, the icon could be a short bleep. The icons are intended to indicate to the user that they can be used to get to whatever options the UA provides for images, and, where appropriate, are expected to provide access to the context menu that would have come up if the user interacted with the actual image.
The following CSS rules are expected to apply when the
Document is in quirks mode:
@namespace url(http://www.w3.org/1999/xhtml);
img[align=left] { margin-right: 3px; }
img[align=right] { margin-left: 3px; }
The following CSS rules are expected to apply as presentational hints:
@namespace url(http://www.w3.org/1999/xhtml);
iframe[frameborder=0], iframe[frameborder=no] { border: none; }
applet[align=left], embed[align=left], iframe[align=left],
img[align=left], input[type=image][align=left], object[align=left] {
float: left;
}
applet[align=right], embed[align=right], iframe[align=right],
img[align=right], input[type=image][align=right], object[align=right] {
float: right;
}
applet[align=top], embed[align=top], iframe[align=top],
img[align=top], input[type=image][align=top], object[align=top] {
vertical-align: top;
}
applet[align=bottom], embed[align=bottom], iframe[align=bottom],
img[align=bottom], input[type=image][align=bottom], object[align=bottom],
applet[align=baseline], embed[align=baseline], iframe[align=baseline],
img[align=baseline], input[type=image][align=baseline], object[align=baseline] {
vertical-align: baseline;
}
applet[align=texttop], embed[align=texttop], iframe[align=texttop],
img[align=texttop], input[type=image][align=texttop], object[align=texttop] {
vertical-align: text-top;
}
applet[align=absmiddle], embed[align=absmiddle], iframe[align=absmiddle],
img[align=absmiddle], input[type=image][align=absmiddle], object[align=absmiddle],
applet[align=abscenter], embed[align=abscenter], iframe[align=abscenter],
img[align=abscenter], input[type=image][align=abscenter], object[align=abscenter] {
vertical-align: middle;
}
applet[align=bottom], embed[align=bottom], iframe[align=bottom],
img[align=bottom], input[type=image][align=bottom],
object[align=bottom] {
vertical-align: bottom;
}
When an applet, embed,
iframe, img, or object
element, or an input element whose type attribute is in the Image Button state, has an
align attribute whose value is
an ASCII case-insensitive match for the string "center" or the string "middle", the user agent is expected to act as if the
element's 'vertical-align' property was set to a value that aligns
the vertical middle of the element with the parent element's
baseline.
The hspace attribute of
applet, embed, iframe,
img, or object elements, and
input elements with a type attribute in the Image Button state, maps to the dimension
properties 'margin-left' and 'margin-right' on the
element.
The vspace attribute of
applet, embed, iframe,
img, or object elements, and
input elements with a type attribute in the Image Button state, maps to the dimension
properties 'margin-top' and 'margin-bottom' on the
element.
When an img element, object element, or
input element with a type attribute in the Image Button state is contained
within a hyperlink and has a border attribute whose value, when
parsed using the rules for parsing non-negative
integers, is found to be a number greater than zero, the user
agent is expected to use the parsed value for eight
presentational hints: four setting the parsed value as
a pixel length for the element's 'border-top-width',
'border-right-width', 'border-bottom-width', and 'border-left-width'
properties, and four setting the element's 'border-top-style',
'border-right-style', 'border-bottom-style', and 'border-left-style'
properties to the value 'solid'.
The width
and height attributes on
applet, embed, iframe,
img, object or video
elements, and input elements with a type attribute in the Image Button state, map to the dimension
properties 'width' and 'height' on the element
respectively.
Shapes on an image map are expected to act, for the
purpose of the CSS cascade, as elements independent of the original
area element that happen to match the same style rules
but inherit from the img or object
element.
For the purposes of the rendering, only the 'cursor' property is expected to have any effect on the shape.
Thus, for example, if an area
element has a style attribute that
sets the 'cursor' property to 'help', then when the user designates
that shape, the cursor would change to a Help cursor.
Similarly, if an area element had a
CSS rule that set its 'cursor' property to 'inherit' (or if no rule
setting the 'cursor' property matched the element at all), the
shape's cursor would be inherited from the img or
object element of the image map, not from
the parent of the area element.
When a menu element's type attribute is in the tool bar state, the element is
expected to be treated as a replaced element with a height about two
lines high and a width derived from the contents of the element.
The element is expected to have, by default, the appearance of a tool bar on the user agent's platform. It is expected to contain the menu that is built from the element.
...example with screenshot...
A number of elements have their rendering defined in terms of the 'binding' property. [BECSS]
The CSS snippets below set the 'binding' property to a
user-agent-defined value, represented below by keywords like bb. The rules then described for
these bindings are only expected to apply if the element's 'binding'
property has not been overriden (e.g. by the author) to have another
value.
Exactly how the bindings are implemented is not specified by this specification. User agents are encouraged to make their bindings set the 'appearance' CSS property appropriately to achieve platform-native appearances for widgets, and are expected to implement any relevant animations, etc, that are appropriate for the platform. [CSSUI]
The converting a character width to pixels algorithm, used by some of the bindings below, returns (size-1)×avg + max, where size is the character width to convert, avg is the average character width of the primary font for the element for which the algorithm is being run, in pixels, and max is the maximum character width of that same font, also in pixels. (The element's 'letter-spacing' property does not affect the result.)
bb element@namespace url(http://www.w3.org/1999/xhtml);
bb:empty { binding: bb; }
When the bb binding applies to a bb
element, the element is expected to render as an 'inline-block' box
rendered as a button, about one line high, containing text derived
from the element's type attribute
in a user-agent-defined (and probably locale-specific) fashion.
button element@namespace url(http://www.w3.org/1999/xhtml);
button { binding: button; }
When the button binding applies to a
button element, the element is expected to render as an
'inline-block' box rendered as a button whose contents are the
contents of the element.
datagrid elementThis section will probably include details on how to render DATAGRID (including its pseudo-elements), drag-and-drop, etc, in a visual medium, in concert with CSS. Implementation experience is desired before this section is filled in.
details element@namespace url(http://www.w3.org/1999/xhtml);
details { binding: details; }
When the details binding applies to a
details element, the element is expected to render as a
'block' box with its 'padding-left' property set to '40px'. The
element's shadow tree is expected to take a child element that
matches the selector :bound-element > legend:first-child and
place it in a first 'block' box container, and then take the
remaining child nodes and place them in a later 'block' box
container.
The first container is expected to contain at least one line box,
and that line box is expected to contain a triangle widget,
horizontally positioned within the left padding of the
details element. That widget is expected to allow the
user to request that the details be shown or hidden.
The later container is expected to have its 'overflow' property
set to 'hidden'. When the details element has an open attribute, the later container
is expected to have its 'height' set to 'auto'; when it does not,
the later container is expected to have its 'height' set to 0.
input element as a text entry widget@namespace url(http://www.w3.org/1999/xhtml);
input { binding: input-textfield; }
input[type=password] { binding: input-password; }
/* later rules override this for other values of type="" */
When the input-textfield binding applies to an
input element whose type attribute is in the Text, Search, URL, or E-mail state, the element is
expected to render as an 'inline-block' box rendered as a text
field.
When the input-password binding applies, to an
input element whose type attribute is in the Password state, the element
is expected to render as an 'inline-block' box rendered as a text
field whose contents are obscured.
If an input element whose type attribute is in one of the above
states has a size attribute,
and parsing that attribute's value using the rules for parsing
non-negative integers doesn't generate an error, then the
user agent is expected to use the attribute as a presentational hint for the
'width' property on the element, with the value obtained from
applying the converting a character width to pixels
algorithm to the value of the attribute.
If an input element whose type attribute is in one of the above
states does not have a size attribute, then the user agent
is expected to act as if it had a user-agent-level style sheet rule
setting the 'width' property on the element to the value obtained
from applying the converting a character width to
pixels algorithm to the number 20.
input element as domain-specific widgets@namespace url(http://www.w3.org/1999/xhtml);
input[type=datetime] { binding: input-datetime; }
input[type=date] { binding: input-date; }
input[type=month] { binding: input-month; }
input[type=week] { binding: input-week; }
input[type=time] { binding: input-time; }
input[type=datetime-local] { binding: input-datetime-local; }
input[type=number] { binding: input-number; }
When the input-datetime binding applies to an
input element whose type attribute is in the Date and Time state, the
element is expected to render as an 'inline-block' box depicting a
Date and Time control.
When the input-date binding applies to an
input element whose type attribute is in the Date state, the element is
expected to render as an 'inline-block' box depicting a Date
control.
When the input-month binding applies to an
input element whose type attribute is in the Month state, the element is
expected to render as an 'inline-block' box depicting a Month
control.
When the input-week binding applies to an
input element whose type attribute is in the Week state, the element is
expected to render as an 'inline-block' box depicting a Week
control.
When the input-time binding applies to an
input element whose type attribute is in the Time state, the element is
expected to render as an 'inline-block' box depicting a Time
control.
When the input-datetime-local binding applies to an
input element whose type attribute is in the Local Date and Time
state, the element is expected to render as an 'inline-block' box
depicting a Local Date and Time control.
When the input-number binding applies to an
input element whose type attribute is in the Number state, the element is
expected to render as an 'inline-block' box depicting a Number
control.
These controls are all expected to be about one line high, and about as wide as necessary to show the widest possible value.
input element as a range control@namespace url(http://www.w3.org/1999/xhtml);
input[type=range] { binding: input-range; }
When the input-range binding applies to an
input element whose type attribute is in the Range state, the element is
expected to render as an 'inline-block' box depicting a slider
control.
When the control is wider than it is tall (or square), the control is expected to be a horizontal slider, with the lowest value on the right if the 'direction' property on this element has a computed value of 'rtl', and on the left otherwise. When the control is taller than it is wide, it is expected to be a vertical slider, with the lowest value on the bottom.
Predefined suggested values (provided by the list attribute) are expected to be
shown as tick marks on the slider, which the slider can snap to.
input element as a color well@namespace url(http://www.w3.org/1999/xhtml);
input[type=color] { binding: input-color; }
When the input-color binding applies to an
input element whose type attribute is in the Color state, the element is
expected to render as an 'inline-block' box depicting a color well,
which, when activated, provides the user with a color picker (e.g. a
color wheel or color palette) from which the color can be
changed.
Predefined suggested values (provided by the list attribute) are expected to be
shown in the color picker interface, not on the color well
itself.
input element as a check box and radio button widgets@namespace url(http://www.w3.org/1999/xhtml);
input[type=checkbox] { binding: input-checkbox; }
input[type=radio] { binding: input-radio; }
When the input-checkbox binding applies to an
input element whose type attribute is in the Checkbox state, the element
is expected to render as an 'inline-block' box containing a single
check box control, with no label.
When the input-radio binding applies to an
input element whose type attribute is in the Radio Button state, the element
is expected to render as an 'inline-block' box containing a single
radio button control, with no label.
input element as a file upload control@namespace url(http://www.w3.org/1999/xhtml);
input[type=file] { binding: input-file; }
When the input-file binding applies to an
input element whose type attribute is in the File Upload state, the element
is expected to render as an 'inline-block' box containing a span of
text giving the filename(s) of the selected files, if
any, followed by a button that, when activated, provides the user
with a file picker from which the selection can be changed.
input element as a button@namespace url(http://www.w3.org/1999/xhtml);
input[type=submit], input[type=reset], input[type=button] {
binding: input-button;
}
When the input-button binding applies to an
input element whose type attribute is in the Submit Button, Reset Button, or Button state, the element is
expected to render as an 'inline-block' box rendered as a button,
about one line high, containing the contents of the element's value attribute, if any, or text
derived from the element's type
attribute in a user-agent-defined (and probably locale-specific)
fashion, if not.
marquee element...(Waiting til I've specced the DOM side of this)...
meter element@namespace url(http://www.w3.org/1999/xhtml);
meter {
binding: meter;
}
When the meter binding applies to a
meter element, the element is expected to render as an
'inline-block' box with a 'height' of '1em' and a 'width' of '5em',
a 'vertical-align' of '-0.2em', and with its contents depicting a
gauge.
When the element is wider than it is tall (or square), the depiction is expected to be of a horizontal gauge, with the minimum value on the right if the 'direction' property on this element has a computed value of 'rtl', and on the left otherwise. When the element is taller than it is wide, it is expected to depict a vertical gauge, with the minimum value on the bottom.
User agents are expected to use a presentation consistent with platform conventions for gauges, if any.
Requirements for what must be depicted in the gauge
are included in the definition of the meter
element.
progress element@namespace url(http://www.w3.org/1999/xhtml);
progress {
binding: progress;
}
When the progress binding applies to a
progress element, the element is expected to render as
an 'inline-block' box with a 'height' of '1em' and a 'width' of
'10em', a 'vertical-align' of '-0.2em', and with its contents
depicting a horizontal progress bar, with the start on the right and
the end on the left if the 'direction' property on this element has
a computed value of 'rtl', and with the start on the left and the
end on the right otherwise.
User agents are expected to use a presentation consistent with platform conventions for progress bars. In particular, user agents are expected to use different presentations for determinate and indeterminate progress bars. User agents are also expected to vary the presentation based on the dimensions of the element.
For example, on some platforms for showing indeterminate progress there is an asychronous progress indicator with square dimensions, which could be used when the element is square, and an indeterminate progress bar, which could be used when the element is wide.
Requirements for how to determine if the progress
bar is determinate or indeterminate, and what progress a determinate
progress bar is to show, are included in the definition of the
progress element.
select element@namespace url(http://www.w3.org/1999/xhtml);
select {
binding: select;
}
When the select binding applies to a
select element whose multiple attribute is present,
the element is expected to render as a multi-select list box.
When the select binding applies to a
select element whose multiple attribute is absent,
and the element's size
attribute specifies a value greater than 1, the element is
expected to render as a single-select list box.
When the element renders as a list box, it is expected to render
as an 'inline-block' box whose 'height' is the height necessary to
contain as many rows for items as specified by the element's size attribute, or four rows if the
attribute is absent, and whose 'width' is the width of the
select's labels plus the width of a
scrollbar.
When the select binding applies to a
select element whose multiple attribute is absent,
and the element's size
attribute is either absent or specifies either no value (an error),
or a value less than or equal to 1, the element is expected to
render as a one-line drop down box whose width is the width of
the select's labels.
In either case (list box or drop-down box), the element's items
are expected to be the element's list of options, with the
element's optgroup element children providing headers
for groups of options where applicable.
The width of the select's labels is the
wider of the width necessary to render the widest
optgroup, and the width necessary to render the widest
option element in the element's list of options (including
its indent, if any).
An optgroup element is expected to be rendered by
displaying the element's label attribute.
An option element is expected to be rendered by
displaying the element's label, indented under its
optgroup element if it has one.
textarea element@namespace url(http://www.w3.org/1999/xhtml);
textarea { binding: textarea; }
When the textarea binding applies to a
textarea element, the element is expected to render as
an 'inline-block' box rendered as a multiline text field.
If the element has a cols
attribute, and parsing that attribute's value using the rules
for parsing non-negative integers doesn't generate an error,
then the user agent is expected to use the attribute as a presentational hint for the
'width' property on the element, with the value obtained from
applying the converting a character width to pixels
algorithm to the value of the attribute and then adding the width of
a scroll bar.
If the element has a rows
attribute, and parsing that attribute's value using the rules
for parsing non-negative integers doesn't generate an error,
then the user agent is expected to use the attribute as a presentational hint for the
'height' property on the element, with the value being the specified
number of lines, plus the height of a scrollbar.
When an html element's second child element is a
frameset element, the user agent is expected to render
the frameset element as described below across the
surface of the view, instead of applying the usual CSS
rendering rules.
When rendering a frameset on a surface, the user
agent is expected to use the following layout algorithm:
The cols and rows variables are lists of zero or more pairs consisting of a number and a unit, the unit being one of percentage, relative, and absolute.
Use the rules for parsing a list of dimensions to
parse the value of the element's cols attribute, if there is
one. Let cols be the result, or an empty list
if there is no such attribute.
Use the rules for parsing a list of dimensions to
parse the value of the element's rows attribute, if there is
one. Let rows be the result, or an empty list
if there is no such attribute.
For any of the entries in cols or rows that have the number zero and the unit relative, change the entry's number to one.
If cols has no entries, then add a single entry consisting of the value 1 and the unit relative to cols.
If rows has no entries, then add a single entry consisting of the value 1 and the unit relative to rows.
Invoke the algorithm defined below to convert a list of
dimensions to a list of pixel values using cols as the input list, and the width of the
surface that the frameset is being rendered into, in
CSS pixels, as the input dimension. Let sized
cols be the resulting list.
Invoke the algorithm defined below to convert a list of
dimensions to a list of pixel values using rows as the input list, and the height of the
surface that the frameset is being rendered into, in
CSS pixels, as the input dimension. Let sized
rows be the resulting list.
Split the surface into a grid of w×h rectangles, where w is the number of entries in sized cols and h is the number of entries in sized rows.
Size the columns so that each column in the grid is as many CSS pixels wide as the corresponding entry in the sized cols list.
Size the rows so that each row in the grid is as many CSS pixels high as the corresponding entry in the sized rows list.
Let children be the list of
frame and frameset elements that are
children of the frameset element for which the
algorithm was invoked.
For each row of the grid of rectangles created in the previous step, from top to bottom, run these substeps:
For each rectangle in the row, from left to right, run these substeps:
If there are any elements left in children, take the first element in the list, and assign it to the rectangle.
If this is a frameset element, then recurse
the entire frameset layout algorithm for that
frameset element, with the rectangle as the
surface.
Otherwise, it is a frame element; create a
nested browsing context sized to fit the
rectangle.
If there are any elements left in children, remove the first element from children.
If the frameset element has a border,
draw an outer set of borders around the rectangles, using the
element's frame border color.
For each rectangle, if there is an element assigned to that rectangle, and that element has a border, draw an inner set of borders around that rectangle, using the element's frame border color.
For each (visible) border that does not abut a rectangle that
is assigned a frame element with a noresize attribute (including
rectangles in further nested frameset elements), the
user agent is expected to allow the user to move the border,
resizing the rectangles within, keeping the proportions of any
nested frameset grids.
A frameset or frame element has
a border if the following algorithm returns true:
If the element has a frameborder attribute
whose value is not the empty string and whose first character is
either a U+0031 DIGIT ONE (1), a U+0079 LATIN SMALL LETTER Y, or
a U+0059 LATIN CAPITAL LETTER Y, then return true.
Otherwise, if the element has a frameborder attribute,
return false.
Otherwise, if the element has a parent element that is a
frameset element, then return true if that
element has a border, and false if it does
not.
Otherwise, return true.
The frame border color of a frameset or
frame element is the color obtained from the
following algorithm:
If the element has a bordercolor attribute,
then return the color obtained from applying the rules for
parsing a legacy color value to that attribute's
value.
Otherwise, if the element has a parent element that is a
frameset element, then the frame border
color of that element.
Otherwise, return gray.
The algorithm to convert a list of dimensions to a list of pixel values consists of the following steps:
Let input list be the list of numbers and units passed to the algorithm.
Let output list be a list of numbers the same length as input list, all zero.
Entries in output list correspond to the entries in input list that have the same position.
Let input dimension be the size passed to the algorithm.
Let count percentage be the number of entries in input list whose unit is percentage.
Let total percentage be the sum of all the numbers in input list whose unit is percentage.
Let count relative be the number of entries in input list whose unit is relative.
Let total relative be the sum of all the numbers in input list whose unit is relative.
Let count absolute be the number of entries in input list whose unit is absolute.
Let total absolute be the sum of all the numbers in input list whose unit is absolute.
Let remaining space be the value of input dimension.
If total absolute is greater than remaining space, then for each entry in input list whose unit is absolute, set the corresponding value in output list to the number of the entry in input list multiplied by remaining space and divided by total absolute. Then, set remaining space to zero.
Otherwise, for each entry in input list whose unit is absolute, set the corresponding value in output list to the number of the entry in input list. Then, decrement remaining space by total absolute.
If total percentage multiplied by the input dimension and divided by 100 is greater than remaining space, then for each entry in input list whose unit is percentage, set the corresponding value in output list to the number of the entry in input list multiplied by remaining space and divided by total percentage. Then, set remaining space to zero.
Otherwise, for each entry in input list whose unit is percentage, set the corresponding value in output list to the number of the entry in input list multiplied by the input dimension and divided by 100. Then, decrement remaining space by total percentage multiplied by the input dimension and divided by 100.
For each entry in input list whose unit is relative, set the corresponding value in output list to the number of the entry in input list multiplied by remaining space and divided by total relative.
Return output list.
User agents working with integer values for frame widths (as opposed to user agents that can lay frames out with subpixel accuracy) are expected to distribute the remainder first the last entry whose unit is relative, then equally (not proportionally) to each entry whose unit is percentage, then equally (not proportionally) to each entry whose unit is absolute, and finally, failing all else, to the last entry.
User agents are expected to allow the user to control aspects of hyperlink activation and form submission, such as which browsing context is to be used for the subsequent navigation.
User agents are expected to allow users to discover the destination of hyperlinks and of forms before triggering their navigation.
User agents are expected to inform the user of whether a hyperlink includes hyperlink auditing, and to let them know at a minimum which domains will be contacted as part of such auditing.
User agents are expected to allow users to navigate
browsing contexts to the
resources indicated by the cite attributes on q,
blockquote, ins, and del
elements.
User agents are expected to surface hyperlinks created by link
elements in their user interface.
While link elements that create hyperlinks will match the ':link' or
':visited' pseudo-classes, will react to clicks if visible, and so
forth, this does not extend to any browser interface constructs that
expose those same links. Activating a link through the browser's
interface, rather than in the page itself, does not trigger click events and the like.
mark elementUser agents are expected to allow the user to cycle through all
the mark elements in a Document. User
agents are also expected to bring their existence to the user's
attention, even when they are off-screen, e.g. by highlighting
portions of the scroll bar that represent portions of the document
that contain mark elements.
title attributeGiven an element (e.g. the element designated by the mouse
cursor), if the element, or one of its ancestors, has a title attribute, and the nearest such
attribute has a value that is not the empty string, it is expected
that the user agent will expose the contents of that attribute as a
tooltip.
U+000A LINE FEED (LF) characters are expected to cause line breaks in the tooltip.
User agents are expected to allow the user to request the
opportunity to obtain a physical form (or a
representation of a physical form) of a Document. For
example, selecting the option to print a page or convert it to PDF
format.
When the user actually obtains a physical form (or a representation of a
physical form) of a Document, the user agent is
expected to create a new view with the print media, render the
result, and the discard the view.
Must define that in CSS, tag and attribute names in HTML documents, and class names in quirks mode documents, are case-insensitive, as well as saying which attribute values must be compared case-insensitively.
Authors and documents must not use the features listed in this section. They are documented to enable user agents to support legacy content in an interoperable fashion.
applet elementThe applet element is a Java-specific variant of the
embed element. In HTML5 the applet element
is obsoleted so that all extension frameworks (Java, .NET, Flash,
etc) are handled in a consistent manner.
If the sandboxed plugins browsing
context flag is set on the browsing context for
which the applet element's document is the active
document, then the element must be ignored (it represents
nothing).
Otherwise, define how the element works, if supported.
[XXX] interface HTMLDocument {
readonly attribute HTMLCollection applets;
};
The applets
attribute must return an HTMLCollection rooted at the
Document node, whose filter matches only
applet elements.
marquee element...
The following elements are obsolete and either have no meaning whatsoever or have no requirements beyond those described elsewhere in this specification:
centerThe following attributes are obsolete and either have no meaning whatsoever or have no requirements beyond those described elsewhere in this specification:
name on a elementsalink on body elementsbgcolor on body elementslink on body elementstext on body elementsvlink on body elementsThese APIs expose obsolete content attributes.
The [XXX] below is for some annotation meaning "this is just another part of the named interface, and should be treated as if it had been part of the main interface definition".
[XXX] interface HTMLBodyElement {
attribute DOMString text;
attribute DOMString bgColor;
attribute DOMString background;
attribute DOMString link;
attribute DOMString vLink;
attribute DOMString aLink;
};
The text DOM
attribute of the body element must reflect
the element's text content
attribute.
The bgColor DOM
attribute of the body element must reflect
the element's bgcolor content
attribute.
The background DOM
attribute of the body element must reflect
the element's background content
attribute.
The link DOM
attribute of the body element must reflect
the element's link content
attribute.
The aLink DOM
attribute of the body element must reflect
the element's alink content
attribute.
The vLink DOM
attribute of the body element must reflect
the element's vlink content
attribute.
[XXX] interface HTMLDocument {
attribute DOMString fgColor;
attribute DOMString bgColor;
attribute DOMString linkColor;
attribute DOMString vlinkColor;
attribute DOMString alinkColor;
};
The fgColor
attribute on the Document object must
reflect the text
attribute on the body element.
The bgColor
attribute on the Document object must
reflect the bgcolor
attribute on the body element.
The linkColor
attribute on the Document object must
reflect the link
attribute on the body element.
The vLinkColor
attribute on the Document object must
reflect the vlink
attribute on the body element.
The aLinkColor
attribute on the Document object must
reflect the alink
attribute on the body element.
To ease the transition from HTML4 Transitional documents to the language defined in this specification, conformance checkers are encouraged to categorise errors that represent usage of old obsolete features that generally have no effect (as defined below) into a separate part of their report, to allow authors to distinguish between likely mistakes and mere vestigial markup.
The following errors may be categorised as described above:
The DOCTYPE parse error, if the DOCTYPE token's
name is an ASCII
case-insensitive match for the string "HTML", and either:
-//W3C//DTD HTML 4.0//EN" and the
token's system identifier is either missing or the
case-sensitive string "http://www.w3.org/TR/REC-html40/strict.dtd", or-//W3C//DTD HTML 4.01//EN" and the
token's system identifier is either missing or the
case-sensitive string "http://www.w3.org/TR/html4/strict.dtd", or-//W3C//DTD XHTML 1.0 Strict//EN"
and the token's system identifier is either missing or the
case-sensitive string "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd",
or-//W3C//DTD XHTML 1.1//EN"
and the token's system identifier is either missing or the
case-sensitive string "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd".The presence of a profile attribute on the
head element, if its value is an unordered set
of unique space-separated tokens where the words are all
valid URLs.
The presence of a meta element with an http-equiv attribute in the
Content
Language state.
The presence of a border attribute on an
img element if its value is the string "0".
The presence of a longdesc attribute on an
img element, if its value is a valid
URL.
The presence of a language attribute on a
script element if its value is an ASCII
case-insensitive match for the string "JavaScript".
The presence of a name
attribute on an a element, if its value is not the
empty string.
The presence of a summary attribute on a
table element.