This document records known errors in the document http://www.w3.org/TR/2011/REC-CSS2-20110607
These errata have the same status as a Working Draft.
[2011-10-12] In “6.2.1 The 'inherit' value,” change
Each property may also have a cascaded value of 'inherit', which means that, for a given element, the property takes
the same specified value as the property foras specified value the computed value of the element's parent.
[2011-10-12] In “6.1.1 Specified values,” add this clarification:
- If the cascade results in a value use it. Except that, if the value is 'inherit', the specified value is defined in “The 'inherit' value” below
[2012-04-04] In “8.3.1 Collapsing margins,” add a new item as follows:
Adjoining vertical margins collapse, except:
- Margins of the root element's box do not collapse.
- If the top and bottom margins of an element with clearance are adjoining, its margins collapse with the adjoining margins of following siblings but that resulting margin does not collapse with the bottom margin of the parent block.
- If the top margin of a box with non-zero computed 'min-height' and 'auto' computed 'height' collapses with the bottom margin of its last in-flow child, then the child's bottom margin does not collapse with the parent's bottom margin.
[2012-04-11] In “10.7 Minimum and maximum heights: 'min-height' and 'max-height',” clarify the note as follows:
These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing except as specifically required by rules for 'min-height' or 'max-height' in "Collapsing margins" (8.3.1).These steps do not affect the real computed value of 'height'. Consequently, for example, they do not affect margin collapsing, which depends on the computed value.
[2012-04-11] In “8.3.1 Collapsing margins,” clarify 7th bullet in the 2nd note:
The bottom margin of an in-flow block box with a 'height' of 'auto' and a 'min-height' of zero collapses with its last in-flow block-level child's bottom margin if the box has no bottom padding and no bottom border and the child's bottom margin does not collapse with a top margin that has clearance.The bottom margin of an in-flow block box with a 'height' of 'auto' collapses with its last in-flow block-level child's bottom margin, if:
- the box has no bottom padding, and
- the box has no bottom border, and
- the child's bottom margin neither collapses with a top margin that has clearance, nor (if the box's min-height is non-zero) with the box's top margin.
[2012-05-02] In “15.3 Font family: the 'font-family' property,” clarify that using the font name “inherit” without quotes is an error:
Font family names that happen to be the same as a keyword value ('inherit', 'serif', 'sans-serif', 'monospace', 'fantasy', and 'cursive') must be quoted to prevent confusion with the keywords with the same names. The keywords 'initial' and 'default' are reserved for future use and must also be quoted when used as font names. UAs must not consider these keywords as matching the '<family-name>' type.Unquoted font family names that happen to be the same as the keyword values 'inherit', 'default' and 'initial' or the generic font keywords ('serif', 'sans-serif', 'monospace', 'fantasy', and 'cursive') do not match the '<family-name>' type. These names must be quoted to prevent confusion with the keywords with the same names. Note that 'font-family: Times, inherit' is therefore an invalid declaration, because 'inherit' in that position can neither be a valid keyword nor a valid font family name.
[2012-05-02] Spaces and comments are not allowed between the sign and the digits of a <number>, <length> or <percentage>. In “4.3.1 Integers and real numbers,” insert “immediately” as follows:
Both integers and real numbers may immediately be preceded by a "-" or "+" to indicate the sign.
No change is required in 4.3.2 (<length>) or 4.3.3 (<percentage>), because they refer to 4.3.1.
[2012-08-01] In 10.1 “Definition of "containing block,"” change:
- […]
- For other elements, if the element's position is 'relative' or 'static', the containing block is formed by the content edge of the nearest ancestor box that is a block container
ancestor boxor which establishes a formatting context.
[2012-08-01] In 9.4 “Normal flow,” replace as follows:
Boxes in the normal flow belong to a formatting context, which in CSS 2.1 may be table, block or inline
, but not both simultaneously. In future levels of CSS, other types of formatting context will be introduced. Block-level boxes participate in a block formatting context. Inline-level boxes participate in an inline formatting context. Table formatting contexts are described in the chapter on tables.
[2012-08-01] In 9.4.2 “Inline formatting contexts,” add this sentence:
An inline formatting context is established by a block container box that contains no block-level boxes. In an inline formatting context, boxes are laid out horizontally, one after the other, beginning at the top of a containing block.
[2012-08-01] In 17.4 “Tables in the visual formatting model,” replace as follows:
The table wrapper box is a 'block' box if the table is block-level, and an 'inline-block' box if the table is inline-level. The table wrapper box establishes a block formatting context, and the table box establishes a table formatting context.
[2012-08-01] In 17.5 “Visual layout of table contents,” replace as follows:
Internal table elements generate rectangular boxes
withwhich participate in the table formatting context established by the table box. These boxes have content and borders.and cells have padding as well. Internal table elements do not have margins.
[2012-08-01] In 11.1.1 “Overflow: the 'overflow' property,” change:
Applies to: block containers and boxes that establish a formatting context
[2012-08-08] In 11.1.1 “Overflow: the 'overflow' property,” add:
On a table element ('display: table'), 'overflow' applies to the table box (i.e., not the table wrapper box) and all values other than 'hidden' are treated as 'visible'.
[2013-04-29] The letters u, r and l of the URI token may be written as escapes. In 4.1.1 “Tokenization,” change in the first table:
URI url{U}{R}{L}\({w}{string}{w}\)
|url{U}{R}{L}\({w}([!#$%&*-\[\]-~]|{nonascii}|{escape})*{w}\)
and in the second table:
baduri1 url{U}{R}{L}\({w}([!#$%&*-~]|{nonascii}|{escape})*{w}baduri2 url{U}{R}{L}\({w}{string}{w}baduri3 url{U}{R}{L}\({w}{badstring}
And add to the second table:
L l|\\0{0,4}(4c|6c)(\r\n|[ \t\r\n\f])?|\\lR r|\\0{0,4}(52|72)(\r\n|[ \t\r\n\f])?|\\rU u|\\0{0,4}(55|75)(\r\n|[ \t\r\n\f])?|\\u
[2013-04-29] The letters u, r and l of the URI token may be written as escapes (see the previous errata). In G.2 “Lexical scanner,” change:
baduri1url{U}{R}{L}\({w}([!#$%&*-\[\]-~]|{nonascii}|{escape})*{w} baduri2url{U}{R}{L}\({w}{string}{w} baduri3url{U}{R}{L}\({w}{badstring}
and
"url("{U}{R}{L}"("{w}{string}{w}")" {return URI;}"url("{U}{R}{L}"("{w}{url}{w}")" {return URI;}
[2013-04-29] Unicode control characters between U+0080 and U+009F can be used in identifiers and in URI tokens. (Previously such characters made the style sheet invalid.) In 4.1.1 “Tokenization,” change:
nonascii [^\0- \237\177]
[2013-04-29] Unicode control characters between U+0080 and U+009F can be used in identifiers and in URI tokens. (Previously such characters made the style sheet invalid.) In 4.1.3 “Characters and case,” change:
- In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters
U+00A0U+0080 and higher, plus the hyphen (-) and the underscore (_);
[2013-05-02] When a CSS file is known to be in a UTF-based character encoding, based on out-of-band information, and the file starts with a BOM, then the BOM determines which of the UTF-based encodings is used, overriding the out-of-band information. In 4.4 “CSS style sheet representation,” insert:
If rule 1 above (an HTTP "charset" parameter or similar) yields a character encoding and it is one of UTF-8, UTF-16 or UTF-32, then a BOM, if any, at the start of the file overrides that character encoding, as follows:
First bytes (hexadecimal) Resulting encoding 00 00 FE FF UTF-32, big-endian FF FE 00 00 UTF-32, little-endian FE FF UTF-16, big-endian FF FE UTF-16, little-endian EF BB BF UTF-8 If rule 1 yields a character encoding of UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE, then it is an error if the file starts with a BOM. A CSS UA must recover by ignoring the specified encoding and using the table above.
Note that the fact that a BOM at the start of a file is an error in UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE is specified by [UNICODE].