Appendix C. Changes

Contents

C.1 Changes since the Recommendation of 7 June 2011

This appendix is informative, not normative.

Below are the changes relative to the first revision of CSS2 (CSS 2.1). The changes between the CSS2 specification (see [CSS2]) and CSS 2.1 (see [CSS21]) can be found in the Changes section of CSS 2.1.

This chapter is not a complete list of changes. Minor editorial changes and most changes to examples are not listed here.

C.1 Changes since the Recommendation of 7 June 2011

[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 for~~ as specified value the computed value of the element's parent.

(See CSS WG minutes 2011-10-12.)
[2011-10-12] In “6.1.1 Specified values,” add this clarification:
1. 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
(See CSS WG minutes 2011-10-12.)
[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.
(See CSS WG minutes 2012-04-04.)
[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.

(See CSS WG minutes 2012-04-11.)
[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.
(See CSS WG minutes 2012-04-11.)
[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.

(See CSS WG minutes 2012-05-02.)
[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.

In “4.1.1 Tokenization,” allow "+" or "-" at the start of the {num} macro:

num [-+]?[0-9]+|[-+]?[0-9]*\.[0-9]+

(Note that this changes the definition of three tokens, NUMBER, DIMENSION and PERCENTAGE, and thus the tokenization of CSS, but it does not change the language generated by the grammar as a whole.)
No change is required in 4.3.2 (<length>) or 4.3.3 (<percentage>), because they refer to 4.3.1.
(See CSS WG minutes 2012-05-02.)
[2012-08-01] In 10.1 “Definition of "containing block,"” change:
1. […]
2. 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 box~~ or which establishes a formatting context.
(See CSS WG minutes 2012-08-01.)
[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 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.

(See CSS WG minutes 2012-08-01.)
[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.

(See CSS WG minutes 2012-08-01.)
[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.

(See CSS WG minutes 2012-08-01.)
[2012-08-01] In 17.5 “Visual layout of table contents,” replace as follows:

Internal table elements generate rectangular boxes ~~with~~ which 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.

(See CSS WG minutes 2012-08-01.)
[2012-08-01] In 11.1.1 “Overflow: the 'overflow' property,” change:

Applies to: block containers and boxes that establish a formatting context

(See CSS WG minutes 2012-08-01.)
[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])?|\\l
R r|\\0{0,4}(52|72)(\r\n|[ \t\r\n\f])?|\\r
U u|\\0{0,4}(55|75)(\r\n|[ \t\r\n\f])?|\\u

(See CSS WG minutes 2013-01-30.)

[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:

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

"url("{U}{R}{L}"("{w}{string}{w}")" {return URI;}
"url("{U}{R}{L}"("{w}{url}{w}")"    {return URI;}

(See CSS WG minutes 2013-01-30.)

[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]

(See CSS WG minutes 2013-01-30.)
[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+00A0~~ U+0080 and higher, plus the hyphen (-) and the underscore (_);
(See CSS WG minutes 2013-01-30.)

[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].

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

(See CSS WG minutes 2012-10-24.)

[2013-07-15] In 11.1.1 “Overflow: the 'overflow' property,” change the definition of 'scroll' and 'auto':

scroll
This value indicates that the content is clipped and that if the user agent uses a scrolling mechanism that is visible on the screen (such as a scroll bar or a panner), that mechanism should be displayed for a box whether or not any of its content is clipped. This avoids any problem with scrollbars appearing and disappearing in a dynamic environment. When this value is specified and the target medium is 'print', overflowing content may be printed. When used on table boxes, this value has the same meaning as 'visible'.
auto
The behavior of the 'auto' value is user agent-dependent, but should cause a scrolling mechanism to be provided for overflowing boxes. When used on table boxes, this value has the same meaning as 'visible'.

(See CSS WG minutes 2012-08-08.)
[2013-07-15] In 15.3 Font family: the 'font-family' property the grammar is missing a pair of brackets:

Value: [[ <family-name> | <generic-family> ] [, [ <family-name>| <generic-family> ] ]* ] | inherit

(See CSS WG minutes 2012-05-03.)
[2013-07-15] Spaces and comments are not allowed between the sign and the digits of a <number>, <length> or <percentage>. In “G.2 Lexical scanner,” change the {num} macro as follows:
```
num		[-+]?[0-9]+|[-+]?[0-9]*"."[0-9]+
```
In “G.1 Grammar,” remove unary_operator from the grammar:
```
unary_operator
  : '-' | '+'
  ;
```
and
```
term
  : unary_operator?
    [ NUMBER S* | PERCENTAGE S* | LENGTH S* | EMS S* | EXS S* | ANGLE S* |
      TIME S* | FREQ S* ]
  | STRING S* | IDENT S* | URI S* | hexcolor | function
  ;
```
(See CSS WG minutes 2012-05-02.)
[2013-07-18] A percentage on 'height', even if not used, can be inherited. In “10.5 Content height: the 'height' property,” change the “computed value” line as follows:

Computed value: the percentage or 'auto' ~~(see prose under <percentage>)~~ (as specified)

and in the definition of <percentage>:

<percentage>
Specifies a percentage height. The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, ~~the value computes to 'auto'~~ the used height is calculated as if 'auto' was specified.

(See CSS WG minutes 2013-05-08.)

[2013-09-09] In “4.1.1 Tokenization,” make the UNICODE-RANGE token more precise:

UNICODE-RANGE u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})? u\+[?]{1,6}| u\+[0-9a-f]{1}[?]{0,5}| u\+[0-9a-f]{2}[?]{0,4}| u\+[0-9a-f]{3}[?]{0,3}| u\+[0-9a-f]{4}[?]{0,2}| u\+[0-9a-f]{5}[?]{0,1}| u\+[0-9a-f]{6}| u\+[0-9a-f]{1,6}-[0-9a-f]{1,6}

E.g., “U+A?5” previously was a single UNICODE-RANGE token (although a semantically meaningless one), now this is two tokens: “U+A?” (meaning the 16-character range U+A0-AF) and the number “5”.

(See CSS WG minutes 2013-09-03.)

[2012-09-19] Modify “9.2 Controlling box generation” and “9.2.1 Block-level elements and block boxes” as follows:

Controlling box generation
The following sections describe the types of boxes that may be generated in CSS 2.1. A box's type affects, in part, its behavior in the visual formatting model. The 'display' property, described below, specifies a box's type.
Certain values of the ''display' property cause an element of the source document to generate a principal box that contains descendant boxes and generated content and is also the box involved in any positioning scheme. Some elements may generate additional boxes in addition to the principal box: 'list-item' elements. These additional boxes are placed with respect to the principal box.
9.2.1 Block-level elements and block boxes
Block-level elements are those elements of the source document that are formatted visually as blocks (e.g., paragraphs). The following values of the 'display' property make an element block-level: 'block', 'list-item', and 'table'.
Block-level elements – those elements of the source document that are formatted visually as blocks (e.g., paragraphs) – are elements which generate a block-level principal box. Values of the 'display' property that make an element block-level include: 'block', 'list-item', and 'table'. Block-level boxes are boxes that participate in a block formatting context.
Block-level boxes are boxes that participate in a block formatting context. Each block-level element generates a principal block-level box that contains descendant boxes and generated content and is also the box involved in any positioning scheme. Some block-level elements may generate additional boxes in addition to the principal box: 'list-item' elements. These additional boxes are placed with respect to the principal box.
~~Except for table boxes, which are described in a later chapter, and replaced elements,~~ In CSS 2, a block-level box is also a block container box unless it is a table box or the principal box of a replaced element. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. An element whose principal box is a block container box is a block container element. Values of the 'display' property which make a non-replaced element generate a block container include 'block', 'list-item' and 'inline-block'. Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells are block containers but are not block-level ~~boxes~~. Block-level boxes that are also block containers are called block boxes.
The three terms "block-level box," "block container box," and "block box" are sometimes abbreviated as "block" where unambiguous.
[2012-09-19] Modify “9.2.4 The 'display' property” as follows:

block
This value causes an element to generate a principal block box.
inline-block
This value causes an element to generate an a principal inline-level block container. (The inside of an inline-block is formatted as a block box, and the element itself is formatted as an atomic inline-level box.)
[2012-09-19] Modify “17.4 Tables in the visual formatting model” as follows:

In both cases, the table generates a principal block container box called the table wrapper box that contains the table box itself and any caption boxes (in document order). The table box is a block-level box that contains the table's internal table boxes. The caption boxes are principal block-level boxes that retain their own content, padding, margin, and border areas, and are rendered as normal block boxes inside the table wrapper box. Whether the caption boxes are placed before or after the table box is decided by the 'caption-side' property, as described below.
The table wrapper box is ~~a 'block' box if the table is block-level~~ block-level for 'display: table', and ~~an 'inline-block' box if the table is inline-level~~ inline-level for 'display: inline-table'. The table wrapper box establishes a block formatting context, and the table box establishes a table formatting context. The table box (not the table wrapper box) is used when doing baseline vertical alignment for an 'inline-table'. The width of the table wrapper box is the border-edge width of the table box inside it, as described by section 17.5.2. Percentages on 'width' and 'height' on the table are relative to the table wrapper box's containing block, not the table wrapper box itself.
[2012-09-19] For compatibility with SVG, modify the definition of macro num in “4.1.1 Tokenization” as follows:

~~num~~ ~~[-+]?[0-9]+|[-+]?[0-9]*\.[0-9]+~~
num [+-]?([0-9]+|[0-9]*\.[0-9]+)(e[+-]?[0-9]+)?
[2014-07-16] The background of the canvas cannot be taken from an element that is suppressed with 'display: none'. On the other hand, if the element is merely invisible ('visibility: hidden'), its background can still be used for the canvas. In other words, if the root element has 'display: none', the background of the canvas is undefined. In the case of (X)HTML documents, if the root element has 'background: transparent' and the <body> element has 'display: none', the background of the canvas is likewise undefined. Change the text in “14.2 The background” as follows:

[…] Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element.
However, if no boxes are generated for the element whose background would be used for the background of the canvas, then the canvas background is transparent. (in CSS 2, that is the case when the element or an ancestor has 'display: none'.)
Note that, if the element has 'visibility: hidden' but not 'display: none', boxes are generated for it and its background is used for the canvas.
[2015-07-01] An element with 'position: fixed' always establishes a new stacking context. (This is different from 'position: absolute', where 'z-index' determines if the element establishes a stacking context or not.)
Change the definition of 'auto' in “9.9.1 Specifying the stack level: the 'z-index' property” as follows:

auto
The stack level of the generated box in the current stacking context is 0. ~~The box does not establish a new stacking context unless it is the root element.~~ If the box has 'position: fixed' or if it is the root, it also establishes a new stacking context.
[2015-09-05] Malformed declarations are handled differently when the start of the malformed declaration conforms to the syntax of an at-rule. In that case, parsing resumes not at the next semicolon or at the closing curly brace of the enclosing block, but immediately after that at-rule. This is expressed by adding the at-rule to the core syntax for rulesets, as shown below.
In “4.1.1 Tokenization”, change the production for ruleset as follows:
```
ruleset     : selector? '{' S* declaration? [ ';' S* declaration? ]* '}' S*;
ruleset     : selector? '{' S* declaration-list '}' S*;
declaration-list: declaration [ ';' S* declaration-list ]?
              | at-rule declaration-list
              | /* empty */;
```
In “4.1.7 Rule sets, declaration blocks, and selectors”, change the second paragraph as follows:

A declaration block starts with a left curly brace ({) and ends with the matching right curly brace (}). In between there must be a list of zero or more ~~semicolon-separated (;) declarations~~ declarations and at-rules. Declarations must end with a semicolon (;) unless they are last in the list.
Note: CSS level 2 has no at-rules that may appear inside rule sets, but such at-rules may be defined in future levels.

In “4.2 Rules for handling parsing errors”, change the rule for malformed declarations as follows:
- Malformed declarations. User agents must handle unexpected tokens encountered while parsing a declaration by reading until the end of the declaration, while observing the rules for matching pairs of (), [], {}, "", and '', and correctly handling escapes. For example, a malformed declaration may be missing a property name, colon (:), or property value.
  When the UA expects the start of a declaration or at-rule (i.e., an IDENT token or an ATKEYWORD token) but finds an unexpected token instead, that token is considered to be the first token of a malformed declaration. I.e., the rule for malformed declarations, rather than malformed statements is used to determine which tokens to ignore in that case.
  The following are all equivalent:
```
p { color:green }
p { @foo { bar: baz } color:green }  /* unknown at-rule */
p { color:green; color }  /* malformed declaration missing ':', value */
p { color:red;   color; color:green }  /* same with expected recovery */
p { color:green; color: } /* malformed declaration missing value */
p { color:red;   color:; color:green } /* same with expected recovery */
p { color:green; color{;color:maroon} } /* unexpected tokens { } */
	 p { color:red;   color{;color:maroon}; color:green } /* same with recovery */
```
And, finally, in “13.2 Page boxes: the @page rule&rdquo, remove the following text, which is now redundant:

The rules for handling malformed declarations, malformed statements, and invalid at-rules inside @page are as defined in section 4.2, with the following addition: when the UA expects the start of a declaration or at-rule (i.e., an IDENT token or an ATKEYWORD token) but finds an unexpected token instead, that token is considered to be the first token of a malformed declaration. I.e., the rule for malformed declarations, rather than malformed statements is used to determine which tokens to ignore in that case.

baduri1	`url{U}{R}{L}\({w}([!#$%&-~]\|{nonascii}\|{escape}){w}`
baduri2	`url{U}{R}{L}\({w}{string}{w}`
baduri3	`url{U}{R}{L}\({w}{badstring}`

L	`l\|\\0{0,4}(4c\|6c)(\r\n\|[ \t\r\n\f])?\|\\l`
R	`r\|\\0{0,4}(52\|72)(\r\n\|[ \t\r\n\f])?\|\\r`
U	`u\|\\0{0,4}(55\|75)(\r\n\|[ \t\r\n\f])?\|\\u`

~~num~~	~~`[-+]?[0-9]+\|[-+]?[0-9]*\.[0-9]+`~~
num	`[+-]?([0-9]+\|[0-9]*\.[0-9]+)(e[+-]?[0-9]+)?`