CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. This module describes, in general terms, the basic structure and syntax of CSS stylesheets. It defines, in detail, the syntax and parsing of CSS - how to turn a stream of bytes into a meaningful stylesheet.
The following features are at risk: …
This section is not normative.
Provide background, motivation, etc.
This module defines the syntax and parsing of CSS stylesheets. It supersedes the lexical scanner and grammar defined in CSS 2.1.
This section is not normative.
A CSS document is a series of rules, which apply CSS properties to elements in the source document, and at-rules, which define special processing rules or values for the CSS document.
A rule starts with a selector (defined by the Selectors specification), then has a {}-wrapped block containing a sequence of declarations. The selector specifies which elements the declarations will apply to. Each declaration has a property name, followed by a colon and the property value, and finished with a semicolon.
A typical rule might look something like this:
p > a {
color: blue;
text-decoration: underline;
}
In the above rule, "p > a" is the selector,
which, if the source document is HTML,
selects any <a> elements that are children of a <p> element.
"color: blue;" is a declaration specifying that,
for the elements that match the selector,
their 'color' property should have the value ''blue''.
Similiarly, their 'text-decoration' property should have the value ''underline''.
At-rules are all different, but they have a basic structure in common. They start with an "@" character followed by their name. Some at-rules are simple statements, with their name followed by more CSS values to specify their behavior, and finally ended by a semicolon. Others are blocks; they can have CSS values following their name, but they end with a {}-wrapped block, similar to a rule. Even the contents of these blocks are specific to the given at-rule: sometimes they contain a sequence of declarations, like a rule; other times, they may contain additional blocks, or at-rules, or other structures altogether.
Here are several examples of at-rules that illustrate the varied syntax they may contain.
@import "my-styles.css";
The ''@import'' at-rule is a simple statement. After its name, it takes a single string or ''url()'' function to indicate the stylesheet that it should import.
@page :left {
margin-left: 4cm;
margin-right: 3cm;
}
The ''@page'' at-rule consists of an optional page selector (the ":left" pseudoclass), followed by a block of properties that apply to the page when printed. In this way, it's very similar to a normal rule, except that its properties don't apply to any "element", but rather the page itself.
@media print {
body { font-size: 10pt }
}
The ''@media'' at-rule begins with a media type and a list of optional media queries. Its block contains entire rules, which are only applied when the ''@media''s conditions are fulfilled.
Property names and at-rule names are always identifiers, which have to start with a letter or a hyphen followed by a letter, and then can contain letters, numbers, hyphens, or underscores. You can include any character at all, even ones that CSS uses in its syntax, by escaping it with a backslash (\) or by using a hexadecimal escape.
The syntax of selectors is defined in the Selectors spec. Similarly, the syntax of the wide variety of CSS values is defined in the Values & Units spec. The special syntaxes of individual at-rules can be found in the specs that define them.
User agents must use the parsing rules described in this section to generate the CSSOM trees from text/css resources. Together, these rules define what is referred to as the CSS parser.
This specification defines the parsing rules for CSS 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 condition exists in the document. Conformance checkers are not required to recover from parse errors.
The input to the CSS parsing process consists of a stream of Unicode code points, which is passed through a tokenization stage followed by a tree construction stage. The output is a CSSStyleSheet object.
Implementations that do not support scripting do not have to actually create a CSSOM CSSStyleSheet object, but the CSSOM tree in such cases is still used as the model for the rest of the specification.
The stream of Unicode code points that comprises 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.
The encoding sniffing algorithm defined below is used to determine the character encoding.
Given an encoding, the bytes in the input byte stream must be converted to Unicode code points for the tokenizer's input stream, 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 code points must be converted to U+FFFD REPLACEMENT CHARACTERs. Specifically, if the encoding is UTF-8, the bytes must be decoded with the error handling defined in this specification.
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 byte stream) are errors that conformance checkers are expected to report.
General algorithm:
The input stream consists of the characters pushed into it as the input byte stream is decoded.
One leading U+FEFF BYTE ORDER MARK character must be ignored if any are present in the input stream.
The requirement to strip a U+FEFF BYTE ORDER MARK character regardless of whether that character was used to determine the byte order is a willful violation of Unicode, motivated by a desire to increase the resilience of user agents in the face of naïve transcoders.
U+000D CARRIAGE RETURN (CR) characters and U+000A LINE FEED (LF) characters are treated specially. All CR characters must be converted to LF characters, and any LF characters that immediately follow a CR character must be ignored. Thus, newlines in CSS stylesheets 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 or explicitly ignored by the requirements in this section. 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 "EOF" character in the tables below is a conceptual character representing the end of the input stream.
...
Implementations must act as if they used the following state machine to tokenize CSS. 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 stays in 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 output of the tokenization step is a series of zero or more of the following tokens: identifier, function, at-keyword, hash, string, bad-string, url, bad-url, delim, number, percentage, dimension, unicode-range, whitespace, cdo, cdc, colon, semicolon, [, ], (, ), {, }.
Identifier, function, at-keyword, hash, string, and url tokens have a value composed of zero or more characters. Delim tokens have a value composed of a single character. Number, percentage, and dimension tokens have a representation composed of 1 or more character, a numeric value, and a type flag set to either "integer" or "number". The type flag defaults to "integer" if not otherwise set. Dimension tokens additionally have a unit composed of one or more characters. Unicode-range tokens have a range of characters.
The tokenizer state machine consists of the states defined in the following subsections.
The tokenizer can be run with any of several flags that alter its behavior.
Currently, this flag is only set when parsing SVG presentational attributes.
transform attribute.
When this is set, whitespace is allowed between the name of a transform function and its opening parenthesis.
This section defines several terms used during the tokenization phase.
Consume the next input character.
Otherwise, emit a delim token with its value set to U+002B PLUS SIGN (+). Remain in this state.
Otherwise, if the next input character is a digit, or the next 2 input characters are U+002E FULL STOP (.) followed by a digit, switch to the number state. Reconsume the current input character.
Otherwise, if the next input character is a name-start character, switch to the identifier state. Reconsume the current input character.
Otherwise, emit a delim token with its value set to U+002D HYPHEN-MINUS (-). Remain in this state.
Otherwise, emit a delim token with its value set to U+002E FULL STOP (.). Remain in this state.
Otherwise, emit a delim token with its value set to U+002F SOLIDUS (/). Remain in this state.
Otherwise, emit a delim token with its value set to U+003C LESS-THAN SIGN (<). Remain in this state.
Otherwise, switch to the identifier state. Reconsume the current input character.
Otherwise, if the next 3 input characters are U+0052 LATIN CAPITAL LETTER R (R) or U+0072 LATIN SMALL LETTER R (r) followed by U+004C LATIN CAPITAL LETTER L (L) or U+006C LATIN SMALL LETTER L (l) followed by U+0028 LEFT PARENTHESIS ((), consume them. Switch to the url state.
Otherwise, switch to the identifier state. Reconsume the current input character.
If a string token has not yet been created since entering this state, create a string token with its value initially set to the empty string.
Consume the next input character.
Otherwise, if the next input character is a newline, consume it. Remain in this state.
Otherwise, consume an escaped character. Append the returned character to the string token's value. Remain in this state.
If a string token has not yet been created since entering this state, create a string token with its value initially set to the empty string.
Consume the next input character.
Otherwise, if the next input character is a newline, consume it. Remain in this state.
Otherwise, consume an escaped character. Append the returned character to the string token's value. Remain in this state.
Consume the next input character.
Otherwise, consume an escaped character. Create a hash token with its value set to the returned character. Switch to the hash-rest state.
Consume the next input character.
Otherwise, consume an escaped character. Append the returned character to the hash token's value. Remain in this state.
Consume the next input character.
Otherwise, do nothing and remain in this state.
Consume the next input character.
Otherwise, emit a delim token with its value set to U+0040 COMMERCIAL AT (@). Switch to the data state. Reconsume the current input character.
Otherwise, consume an escaped character. Create an at-keyword token with its value set to the returned character. Switch to the at-keyword-rest state.
Consume the next input character.
Otherwise, consume an escaped character. Append the returned character to the at-keyword token's value. Remain in this state.
Consume the next input character.
Otherwise, switch to the data state. Reconsume the current input character.
Otherwise, consume an escaped character. Create an identifier token with its value set to the returned character. Switch to the identifier-rest state.
Consume the next input character.
Otherwise, consume an escaped character. Append the returned character to the identifier token's value. Remain in this state.
Otherwise, emit the identifier token. Switch to the data state. Reconsume the current input character.
Consume the next input character.
Create a number token with its representation initially set to the empty string.
Consume the next input character.
Otherwise, if the next 2 input characters are U+002E FULL STOP followed by a digit, consume them. Append U+002D HYPHEN-MINUS (-) to the number token's representation. Append U+002E FULL STOP (.) to the number token's representation. Append the digit to the number token's representation. Switch to the number fraction state.
Otherwise, switch to the data state. Reconsume the current input character.
Otherwise, if the next 2 input characters are U+002E FULL STOP followed by a digit, consume them. Append U+002D PLUS SIGN (+) to the number token's representation. Append U+002E FULL STOP (.) to the number token's representation. Append the digit to the number token's representation. Switch to the number fraction state.
Otherwise, switch to the data state. Reconsume the current input character.
Otherwise, switch to the data state. Reconsume the current input character.
Consume the next input character.
Otherwise, set the number token's value to the number produced by interpreting the number token's representation as a base-10 number and emit it. Switch to the data state. Reconsume the current input character.
Otherwise, if the next input character is a digit, or the next 2 input characters are U+002B PLUS SIGN (+) or U+002D HYPHEN-MINUS (-) followed by a digit, consume them and append them to the number token's representation. switch to the sci-notation state.
Otherwise, create a dimension token with its representation set to the number token's representation, its value set to the number produced by interpreting the number token's representation as a base-10 number, and a unit initially set to the current input character. Switch to the dimension state.
Otherwise, if the next 2 input characters are U+005C REVERSE SOLIDUS (\) followed by a newline, or U+005C REVERSE SOLIDUS (\) followed by EOF, set the number token's value to the number produced by interpreting the number token's representation as a base-10 number and emit it. Switch to the data state. Reconsume the current input character.
Otherwise, if the next input character is U+005C REVERSE SOLIDUS (\), consume it, then consume an escaped character. Create a dimension token with its representation set to the number token's representation, its value set to the number produced by interpreting the number token's representation as a base-10 number, and a unit initially set to U+002D HYPHEN-MINUS followed by the returned character. Switch to the dimension state.
Otherwise, set the number token's value to the number produced by interpreting the number token's representation as a base-10 number and emit it. Switch to the data state. Reconsume the current input character.
Otherwise, consume an escaped character. Create a dimension token with its representation set to the number token's representation, its value set to the number produced by interpreting the number token's representation as a base-10 number, and a unit initially set to the returned character. Switch to the dimension state.
Set the number token's type flag to "number".
Consume the next input character.
Otherwise, if the next input character is a digit, or the next 2 input characters are U+002B PLUS SIGN (+) or U+002D HYPHEN-MINUS (-) followed by a digit, consume them and append them to the number token's representation. switch to the sci-notation state.
Otherwise, create a dimension token with its representation set to the number token's representation, its value set to the number produced by interpreting the number token's representation as a base-10 number, and a unit initially set to the current input character. Switch to the dimension state.
Otherwise, if the next 2 input characters are U+005C REVERSE SOLIDUS (\) followed by a newline, or U+005C REVERSE SOLIDUS (\) followed by EOF, set the number token's value to the number produced by interpreting the number token's representation as a base-10 number and emit it. Switch to the data state. Reconsume the current input character.
Otherwise, if the next input character is U+005C REVERSE SOLIDUS (\), consume it, then consume an escaped character. Create a dimension token with its representation set to the number token's representation, its value set to the number produced by interpreting the number token's representation as a base-10 number, and a unit initially set to U+002D HYPHEN-MINUS followed by the returned character. Switch to the dimension state.
Otherwise, set the number token's value to the number produced by interpreting the number token's representation as a base-10 number and emit it. Switch to the data state. Reconsume the current input character.
Otherwise, consume an escaped character. Create a dimension token with its representation set to the number token's representation, its value set to the number produced by interpreting the number token's representation as a base-10 number, and a unit initially set to the returned character. Switch to the dimension state.
Consume the next input character.
Otherwise, consume an escaped character. Append the returned character to the dimension token's unit.
Consume the next input character.
Let power be the result of interpreting the portion of the number token's representation following the U+0045 LATIN CAPITAL LETTER E (E) or U+0065 LATIN SMALL LETTER E (e) as a base-10 number.
Set the number token's value to base * 10power.
If the number token's value is not an integer,
set the number token's type flag to "number".
Emit the number token.
Switch to the date state.
Reconsume the current input character.
Consume the next input character.
If a url token has not yet been created since entering this state, create a url token with its value initially set to the empty string.
Consume the next input character.
Otherwise, if the next input character is a newline, consume it and remain in this state.
Otherwise, consume an escaped character. Append the returned character to the url token's value. Remain in this state.
If a url token has not yet been created since entering this state, create a url token with its value initially set to the empty string.
Consume the next input character.
Otherwise, if the next input character is a newline, consume it and remain in this state.
Otherwise, consume an escaped character. Append the returned character to the url token's value. Remain in this state.
Consume the next input character.
If a url token has not yet been created since entering this state, create a url token with its value initially set to the empty string.
Consume the next input character.
Otherwise, consume an escaped character. Append the returned character to the url token's value. Remain in this state.
Consume the next input character.
Otherwise, consume an escaped character. Remain in this state.
Create a new unicode-range token with an empty range.
Consume as many hex digits as possible, but no more than 6. If less than 6 hex digits were consumed, consume as many U+003F QUESTION MARK (?) characters as possible, but no more than enough to make the total of hex digits and U+003F QUESTION MARK (?) characters equal to 6.
If any U+003F QUESTION MARK (?) characters were consumed, first interpret the consumed characters as a hexadecimal number, with the U+003F QUESTION MARK (?) characters replaced by U+0030 DIGIT ZERO (0) characters. This is the start of the range. Then interpret the consumed characters as a hexadecimal number again, with the U+003F QUESTION MARK (?) character replaced by U+0046 LATIN CAPITAL LETTER F (F) characters. This is the end of the range. Set the unicode-range token's range, then emit it. Switch to the data state.
Otherwise, interpret the digits as a hexadecimal number. This is the start of the range.
Consume the next input character.
Otherwise, set the unicode-range token's range and emit it. Switch to the data state. Reconsume the current input character.
This section describes how to consume an escaped character. It assumes that the U+005C REVERSE SOLIDUS (\) has already been consumed and that the next input character has already been verified to not be a newline or EOF. It will return a character.
Consume the next input character.
This section describes how to set a unicode-range token's range so that the range it describes is within the supported range of unicode characters.
It assumes that the start of the range has been defined, the end of the range might be defined, and both are non-negative integers.
If the start of the range is greater than the maximum allowed codepoint, the unicode-range token's range is empty.
If the end of the range is defined, and it is less than the start of the range, the unicode-range token's range is empty.
If the end of the range is not defined, the unicode-range token's range is the single character whose codepoint is the start of the range.
Otherwise, if the end of the range is greater than the maximum allowed codepoint, change it to the maximum allowed codepoint. The unicode-range token's range is all characters between the character whose codepoint is the start of the range and the character whose codepoint is the end of the range.
This section is non-normative.
Here are the changes that I know that I've made to the tokenizer of 2.1. If there are changes not present here, please let me know as they may be unintentional.
Note that the point of this spec is to match reality; changes from CSS2.1's tokenizer are nearly always because the tokenizer specified something that doesn't match actual browser behavior, or left something unspecified. If some detail doesn't match browsers, please let me know as it's almost certainly unintentional.
The input to the tree construction stage is a sequence of tokens from the tokenization stage. The output is a tree of items with a stylesheet at the root and all other nodes being at-rules, style rules, or declarations.
The construction of this stylesheet does not take into account unrecognized items, like unknown properties or at-rules. It simply produces a tree of rules according to the fundamental syntax of CSS. Unrecognized or misplaced rules are handled in the CSSOM Construction stage.
The items that can appear in the tree are a mixture of basic tokens and new objects:
This means that the following tokens emitted by the tokenizer stage will not appear in the stylesheet object: function, bad-string, bad-url, [, (, {. I need to make sure this is true.
TODO:
style attribute
(there, the top element is a style rule,
and we start by entering the declaration mode).
Consume the next input token.
Consume the next input token.
Otherwise, if the current rule is declaration-filled, switch to the declaration mode.
Otherwise, this is a parse error. Discard the current rule. Switch to the next-block error mode. Reconsume the current input token.
Consume the next input token.
Consume the next input token.
Consume the next input token.
Consume the next input token.
Consume the next input token.
This currently always parses !important at the end of a declaration as meaning that the declaration has its important flag set. It's not entirely clear yet that that's the behavior we want.
Otherwise, append the token to the value of the current declaration.
Consume the next input token.
Consume the next input token.
Consume the next input token.
This section describes how to consume a primitive.
If the current input token is a {, [, or ( token, consume a simple block and return it.
Otherwise, if the current input token is a function token, consume a function and return it.
Otherwise, return the current input token.
This section describes how to consume a simple block.
The ending token is the mirror variant of the current input token. (E.g. if it was called with [, the ending token is ].)
Create a simple block with its associated token set to the current input token. This is the current block.
Repeatedly consume the next input token and process it as follows:
This section describes how to consume a function.
Create a function with a name equal to the value of the current input token. Create an argument, called the current argument, which is initially empty.
Repeatedly consume the next input token and process it as follows:
This section describes how to switch to the current rule's content mode. It is invoked whenever a declaration or rule has been successfully completed, or when an error has finished recovery.
If the current rule is a style rule or a declaration-filled at-rule, switch to the declaration mode.
If the current rule is a rule-filled at-rule, switch to the rule mode.
If the current rule is a stylesheet, switch to the top-level mode.
This section describes how to pop the current rule. It is invoked whenever a rule is "finished" parsing and can be made part of its parent rule.
First, validate the current rule according to the appropriate grammar rules. If the rule does not match its required grammar, discard it.
Otherwise, pop the current rule from the stack of open rules and append it to the value of the new current rule.
This section describes how to finish parsing. It is invoked whenever an EOF token is encountered.
If there is a current declaration, and it is grammatically valid, append it to the value of the current rule.
While there's more than one rule on the stack of open rules, pop the current rule.
Finally, return the current rule as the result of parsing.
This section is non-normative.
Here are the changes that I know that I've made to the Core Grammar of 2.1. If there are changes not present here, please let me know as they may be unintentional.
Note that the point of this spec is to match reality; changes from CSS2.1's Core Grammar are nearly always because the Core Grammar specified something that doesn't match actual browser behavior, or left something unspecified. If some detail doesn't match browsers, please let me know as it's almost certainly unintentional.
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [[!RFC2119]]
Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example",
like this:
This is an example of an informative example.
Informative notes begin with the word “Note” and are set apart from the
normative text with class="note", like this:
Note, this is an informative note.
Conformance to CSS TEMPLATE Module is defined for three conformance classes:
A style sheet is conformant to CSS TEMPLATE Module if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.
A renderer is conformant to CSS TEMPLATE Module if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by CSS TEMPLATE Module by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)
An authoring tool is conformant to CSS TEMPLATE Module if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.
So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.
To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax for proprietary and experimental extensions to CSS.
Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.
Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.
To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.
Further information on submitting testcases and implementation reports can be found from on the CSS Working Group's website at http://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.
[Change or remove the following CR exit criteria if the spec is not a module, but, e.g., a Note or a profile. This text was decided on 2008-06-04.]
For this specification to be advanced to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product. For the purposes of this criterion, we define the following terms:
The specification will remain Candidate Recommendation for at least six months.
[acknowledgments]