These are the errata for CSS level 2 revision 1, CR version of 8 September 2009. These corrections have the status of a draft.
For convenience, we provide a version of the specification with these errata applied. Note that this is not an official Working Draft and has not been reviewed by the CSS working group. It is known to contain editing errors.
[2010-08-06] (Also in various other sections throughout the specification.) Distinguished all cases where the word value referred to a whole property value from where it referred to only part of such a value (such as a component in a comma-separated list). The former is now property value, the latter component value.
[2010-04-19] Add a clarification to the definition of replaced element:
The content of replaced elements is not considered in the CSS rendering model.
(Previously, the definition only said that the content was “outside the scope of CSS.”)
[2010-04-19] The definition of
“identifier” in 4.1.3 (2nd bullet) and in the grammar were
contradictory w.r.t. whether no-break space (U+00A0) was allowed in
identifiers or not. Change the text in 4.1.3 to allow no-break space:
“characters U+00A1 U+00A0 and
higher.”
Also, change the macro “nonascii” in the token
definition from “[^\0-\177]” to
[^\0-\237]”. (When CSS was first written, Unicode
didn't have code points U+0080 to U+009F, i.e., \200-\237 in octal.)
[2010-09-29] The tokenizer has been modified so that it can be implemented as a state machine without back-up (e.g., with Lex). This changes the meaning of an input of the form “url(…(…)…)”, i.e., input that starts like a URI token but then contains a parenthesis (which is not allowed in a URI token). Previously, such input was re-parsed to yield a FUNCTION token followed by other things; now it yields a BAD_URI token. Given that CSS has never used a FUNCTION token of the form “url(” this should not affect any existing CSS style sheets.
A non-normative section has been added to appendix G with an explanation of how to make a tokenizer without back-up.
[2010-09-29] The definition of the URI token was ambiguous: it allowed a backslash to be either parsed on its own or as part of an escape. A backslash in a URI token must always be interpreted as part of an escape.
[2010-09-29] Error handling for illegal tokens (braces, at-keywords, and SGML comment tokens) inside parenthesized expressions was not well defined. Change the production for “any” as follows
any : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
| DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
| DASHMATCH | ':' | FUNCTION S* [any|unsused]* ')'
| '(' S* [any|unused]* ')' | '[' S* [any|unused]* ']'
] S*;
unused : block | ATKEYWORD S* | ';' S* | CDO S* | CDC S*;
and add the following explanation:
The "unused" production is not used in CSS and will not be used by any future extension. It is included here only to help with error handling. (See 4.2 "Rules for handling parsing errors.")
[2010-04-19] Add “-tc-” to the list of existing vendor prefixes.
[2010-08-06] The handling of a backslash before a newline or at the end of a file is no longer undefined: it is parsed as a DELIM.
[2010-08-06] Make text and formal grammar the same:
In CSS, identifiers […]; they cannot start with a digit, two hyphens, or a hyphen followed by a digit.
[2010-05-12] Remove “2.1” from
Every CSS
2.1property has its own syntactic and semantic restrictions
[2010-07-07] Clarify that the fifth bullet only applies to at-rules. (At-keywords in other constructs are already handled in the preceding bullets.)
Invalid at-keywordsAt-rules with unknown at-keywords. User agents must ignore…
[2010-04-19] Make explicit that 'ex', when used in the 'font-size' property, refers to the parent element's 'ex' (just as 'em' refers to the parent's 'em' in that case.)
[2010-10-28] A UA must now either display absolute lengths (cm, in, pt, etc.) at their real size or make px align with device pixel boundaries near the 0.0213 degrees viewing angle, but not both. In either case, 3px must equal 4pt.
(Until now, authors could use absolute lengths for physical sizes and px for aligning to device pixels, but couldn't know the number of pt in a px, except in combination with Media Queries. Authors can no longer choose between absolute or device-related units, but can use px and pt interchangeably. This should only affect relatively low-resolution devices: above 300 dots per inch, the maximum error is about 16%.)
[2010-05-12] Commas do not have to be escaped in <uri> tokens:
Some characters appearing in an unquoted URI, such as parentheses,
commas,white space characters, single quotes (') and double quotes ("), must be escaped
[2010-04-21] Describe in English what was only expressed through the grammar:
Note. Since URIs may contain characters that would otherwise be used as delimiters in CSS, the entire URI value must be treated as a single unit by the tokenizer and normal tokenization behavior does not apply within a URI value. Therefore comments are not allowed within a URI value.
[2010-09-29] Clarify what is meant by “is not required”:
More precisely, a UA may, but is not required to, read an "external subset" of the DTD but is required to look for default attribute values in the document's "internal subset." (See [XML10] for definitions of these subsets.) Depending on the UA, a default attribute value defined in the external subset of the DTD might or might not appear in the document tree.
A UA that recognizes an XML namespace [XMLNAMESPACES] may, but is not required to, use its knowledge of that namespace to treat default attribute values as if they were present in the document. (E.g., an XHTML UA is not required to use its built-in knowledge of the XHTML DTD.)
and:
the first rule
willmight not match elements whose "notation" attribute is set by default, i.e., not set explicitly. To catch all cases, the attribute selector for the default value must be dropped:
[2010-08-06] The argument of ':lang()' is only case-insensitive for characters in ASCII.
[2010-08-06] Clarify that pseudo-elements behave like elements for the aspects not explicitly mentioned:
Pseudo-elements behave just like real elements in CSS with the exceptions described below and elsewhere.
[2010-08-24] More consistent use of “block” and “block-level.” Change:
The :first-line pseudo-element can only be attached to a
block-level element, inline-block, table-caption or a table-cellblock container element.
[2010-08-24] More consistent use of “block” and “block-level.” Change:
The :first-letter pseudo-element applies to
block, list-item, table-cell, table-caption and inline-block elementsblock container elements.
[2010-08-06] Add a note that, because it follows the document tree, inheritance is not intercepted by anonymous boxes
[2010-10-05] Give other languages than HTML (such as SVG) the possibility to define certain attributes as “presentational attributes”:
For other languages, all document language-based styling
should be handled in the user agent style sheetmust be translated to the corresponding CSS and either enter the cascade at the user agent level or, as with HTML presentational hints, be treated as author level rules with a specificity of zero placed at the start of the author style sheet.
[2010-09-08] Clarify what is ignored. Change:
@media and @import rules with unknown media types (that are nonetheless valid identifiers) are treated as if the unknown media types are not present. If an @media/@import rule contains a malformed media type (not an identifier) then the statement is invalid.
Note: Media Queries supercedes this error handling.
[2010-05-12] Simplify/clarify text:
An element that has
hadclearanceapplied to itnever collapses
and:
When an element's own margins collapse, and that element has
hadclearanceapplied to it
[2010-08-24] More consistent use of “block box” vs “block-level element.” Include table captions in the set of block-level elements. See also changes to 9.2.1 and to 9.2.1.1.
Two or more adjoining vertical margins of block-level boxes in the normal flow collapse.
and
The top margin of an in-flow
block-level elementblock box is adjoining to its first in-flow block-level child's top margin
and
The bottom margin of an in-flow
block-level elementblock box with a 'height' of 'auto'
[2010-08-24] Define the term “block-level element” more precisely. Also define auxiliary terms “block container box” and “block box”:
More consistent use of block box vs block-level element in section 9.2.1.1. See also changes to section 8.3.1 and 9.4.
[2010-05-12] The example has invalid HTML mark-up. Change it to use P and SPAN elements instead of BODY and P.
[2010-08-06] Also clarify that “block box” only refers to boxes in the same flow.
[2010-09-29] Percentage values that refer to dimensions of parent boxes ignore any intervening anonymous boxes. Add this paragraph:
Anonymous block boxes are ignored when resolving percentage values that would refer to it: the closest non-anonymous ancestor box is used instead. For example, if the child of the anonymous block box inside the DIV above needs to know the height of its containing block to resolve a percentage height, then it will use the height of the containing block formed by the DIV, not of the anonymous block box.
[2010-09-29] Clarify the wording:
When an inline box contains an in-flow block box […] When such an inline box is affected by relative positioning, the relative positioning also affects the block-level box contained in the block box.
[2010-10-13] Clarify that an inline box that is broken around a block-level box is always broken into two pieces, even if one or both are empty:
When an inline box contains an in-flow block-level box, the inline box (and its inline ancestors within the same line box) are broken around the block-level box, dividing the inline box into two pieces, even if either side is empty..
[2010-08-24] Better define the term “inline-level element/box” and define the auxiliary terms “inline box” and “atomic inline-level box.”
[2010-04-19] Make the definition of 'run-in' more precise:
A run-in box behaves as follows:
If the run-in box contains a block box, the run-in box becomes a block box.If a sibling block box (that does not float and is not absolutely positioned) follows the run-in box, the run-in box becomes the first inline box of the block box. A run-in cannot run in to a block that already starts with a run-in or that itself is a run-in.Otherwise, the run-in box becomes a block box.A run-in element (or pseudo-element) A behaves as follows:
- If A has any children that inhibit run-in behavior (see below), then A is rendered as if it had 'display: block'.
- Let B be the first of A's following siblings that is neither floating nor absolutely positioned nor has 'display: none'. If B exists and has a specified value for 'display' of 'block' or 'list-item' and is not replaced, then A is rendered as an 'inline' element at the start of B's principal box. Note: A is rendered before B's ':before' pseudo-element, if any. See 12.1.
- Otherwise, A is rendered as if it had 'display: block'.
In the above, "siblings" and "children" include both normal elements and :before/:after pseudo-elements.
An element or pseudo-element C inhibits run-in behavior if one of the following is true. (Note that the definition is recursive.)
- C is not floating and not absolutely positioned and the computed value of its 'display' is one of 'block', 'list-item', 'table' or 'run-in'.
- C has a computed value for 'display' of 'inline' and it has one or more children that inhibit run-in behavior. (Where "children" includes both normal elements and :before/:after pseudo-elements.)
It remains undefined how 'run-in' and ':first-line' interact:
It is undefined in CSS 2.1 if a run-in inherits from a ':first-line' pseudo-element.
[2010-08-06] Use the same terminology as in chapter 12:
- list-item
- This value causes an element (e.g., LI in HTML) to generate a principal block box and a
list-item inlinemarker box.
[2010-08-24] More consistent use of “inline-level.”
- inline-block
- This value causes an element to generate
a block box, which itself is flowed as a single inline box, similar to a replaced elementan inline-level block container. The inside of an inline-block is formatted as a block box, and the element itself is formatted as aninline replaced elementan atomic inline-level box.
[2010-08-24] More consistent use of “inline-level” and “block-level.”
- Normal flow. In CSS 2.1, normal flow includes block formatting of block-level boxes, inline formatting of inline-level boxes, relative positioning of block-level
orand inline-level boxes, andpositioningformatting of run-in boxes.
[2010-08-24] More consistent use of “inline-level” and “block-level.”
Boxes in the normal flow belong to a formatting context, which may be block or inline, but not both simultaneously. Block-level boxes participate in a block formatting context. Inline-level boxes participate in an inline formatting context.
In 9.4.1:
Floats, absolutely positioned elements,
inline-blocks, table-cells, table-captions, and elements with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contextsblock containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with 'overflow' other than 'visible'.In a block formatting context, boxes are laid out one after the other, vertically, beginning at the top of a containing block. The vertical distance between two sibling boxes is determined by the 'margin' properties. Vertical margins between adjacent block-level boxes in a block formatting context collapse.
In 9.4.2:
[…] When several inline-level boxes cannot fit horizontally within a single line box, they are distributed among two or more vertically-stacked line boxes.
When the total width of the inline-level boxes on a line […]is less than the width of the line box containing them, their horizontal distribution within the line box is determined by the 'text-align' property. If that property has the value 'justify', the user agent may stretch spaces and words in inline boxes (
except forbut not inline-table and inline-block boxes) as well.
[2010-07-19] If 'top', 'right', 'bottom' or 'left' is specified as 'auto', the used value rather than the computed value is set to the negative of the opposite side. For all four, change:
Computed value: for 'position:relative', see section Relative Positioning.For 'position:static', 'auto'. Otherwise: if specified as a length, the corresponding absolute length; if specified as a percentage, the specified value; otherwise, 'auto'.
And in section 9.4.3:
[…] Since boxes are not split or stretched as a result of 'left' or 'right', the
computedused values are always: left = -right.If both 'left' and 'right' are 'auto' (their initial values), the
computedused values are '0' (i.e., the boxes stay in their original position).If 'left' is 'auto', its
computedused value is minus the value of 'right' (i.e., the boxes move to the left by the value of 'right').If 'right' is specified as 'auto', its
computedused value is minus the value of 'left'.[…] Since boxes are not split or stretched as a result of 'top' or 'bottom', the
computedused values are always: top = -bottom. If both are 'auto', theircomputedused values are both '0'. If one of them is 'auto', it becomes the negative of the other. If neither is 'auto', 'bottom' is ignored (i.e., thecomputedused value of 'bottom' will be minus the value of 'top').
[2010-08-24] More consistent use of “inline-level” and “block-level.”
[…] In other words, if inline-level boxes are placed on the line before a left float is encountered that fits in the remaining line box space, the left float is placed on that line, aligned with the top of the line box, and then the inline-level boxes already on the line are moved accordingly to the right of the float (the right being the other side of the left float) and vice versa for rtl and right floats.
In 9.5.2:
Values have the following meanings when applied to non-floating block-level boxes:
[2010-10-25] Define exactly what it means for a line box to be next to a float:
[…] However, line boxes created next to the float are shortened to make room for the margin box of the float.
A line box is next to a float when there exists a vertical position that satisfies all of these four conditions: (a) at or below the top of the line box, (b) at or above the bottom of the line box, (c) below the top margin edge of the float, and (d) above the bottom margin edge of the float.
Note: this means that floats with zero height or negative height do not move line boxes.
[2010-05-12] Clarify that 'clear' only introduces clearance above an element if necessary; and that clearance may have zero height.
[2010-10-13] Added an example of calculating clearance from two collapsing margins M1 and M2 and the height H of a float.
[2010-10-13] Clarify the language:
Computing the clearance of an element on which 'clear' is set is done by first determining the hypothetical position of the element's top border edge within its parent block.
This position is determined after the top margin of the element has been collapsed with previous adjacent margins (including the top margin of the parent block).This position where the actual top border edge would have been if the element had a non-zero top border and its 'clear' property had been 'none'.If this hypothetical position of the element's top border edge is not past the relevant floats, then clearance
must beis introduced, and margins collapse according to the rules in 8.3.1.Then the amount of clearance is set to the greater of:
- The amount necessary to place the border edge of the block even with the bottom outer edge of the lowest float that is to be cleared.
The amount necessary to make the sum of the following equal to the distance to which these margins collapsed when the hypothetical position was calculated:
the margins collapsing above the clearancethe clearance itselfif the block's own margins collapse together: the block's top marginif the block's own margins do not collapse together: the margins collapsing below the clearanceThe amount necessary to place the top border edge of the block at its hypothetical position.
[2010-10-13] Correction: The hypothetical position is determined by assuming the box has a non-zero bottom border (see section 8.3.1):
This position is where the actual top border edge would have been if the element had a non-zero
topbottom border and its 'clear' property had been 'none'.
[2010-04-19] 'Fixed' backgrounds in paged media are positioned relative to the page box (and thus repeat on every page, just like 'fixed' elements). The position of fixed backgrounds in paged media was previously undefined.
[2010-07-07] Some ambiguities in the description of stacking contexts are fixed and the description is clearly marked as non-normative. (Appendix E holds the normative description.)
[2010-08-24] More consistent use of “inline-level” and “block-level.”
User agents that support bidirectional text must apply the Unicode bidirectional algorithm to every sequence of inline-level boxes uninterrupted by a forced line break or block boundary. This sequence forms the "paragraph" unit in the bidirectional algorithm. The paragraph embedding level is set according to the value of the 'direction' property of the containing block rather than by the heuristic given in steps P2 and P3 of the Unicode algorithm.
[…]
For the 'direction' property to affect reordering in inline
-levelelements, the 'unicode-bidi' property's value must be 'embed' or 'override'.[…]
- normal
- The element does not open an additional level of embedding with respect to the bidirectional algorithm. For inline
-levelelements, implicit reordering works across element boundaries.- embed
- If the element is inline
-level, this value opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the 'direction' property. Inside the element, reordering is done implicitly. This corresponds to adding a LRE (U+202A; for 'direction: ltr') or RLE (U+202B; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element.- bidi-override
- For inline
-levelelements this creates an override. Forblock-level, table-cell, table-caption, or inline-blockblock container elements this creates an override for inline-level descendants not within another block-level, table-cell, table-caption, or inline-block element. This means that inside the element, reordering is strictly in sequence according to the 'direction' property; the implicit part of the bidirectional algorithm is ignored. This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO (U+202E; for 'direction: rtl') at the start of the element or at the start of each anonymous child block box, if any, and a PDF (U+202C) at the end of the element.The final order of characters in each
block-level elementblock container is […]
[2010-10-05] Add a reference to bidi class B in Unicode TR 9 to clarify what a “forced break” is in the context of the Unicode bidi algorithm:
[…] inline-level boxes uninterrupted by a forced
line(bidi class B) break or block boundary
[2010-10-25] clarify “non-textual entities”:
In this process,
non-textual entities such as imagesreplaced elements with 'display: inline' (and replaced elements with 'display: run-in', when they generate inline-level boxes) are treated as neutral characters, [&hellip]
[2010-08-24] More consistent use of “inline-level” and “block-level.”
- […]
- For other elements, if the element's position is 'relative' or 'static', the containing block is formed by the content edge of the nearest
block-level, table cell or inline-blockblock container ancestor box.- […]
- […]
- In the case that the ancestor is
inline-levelan inline box, the containing block depends on the 'direction' property of the ancestor:
[2010-05-12] The computed value of 'width' doesn't depend on whether the property applies or not:
Computed value: the percentage or 'auto' as specified or the absolute length;
'auto' if the property does not apply
[2010-08-24] More consistent use of “inline-level” and “block-level.”
This property specifies the content width of boxes
generated by block-level and replaced elements.This property does not apply to non-replaced inline
-levelelements.
[2010-10-05] Remove unclear and redundant sentence:
The width of a replaced element's box is intrinsic and may be scaled by the user agent if the value of this property is different than 'auto'.
[2010-05-12] The computed value of 'height' doesn't depend on whether the property applies or not:
Computed value: the percentage or 'auto' (see prose under <percentage>) or the absolute length;
'auto' if the property does not apply
[2010-08-24] More consistent use of “inline-level” and “block-level.”
This property specifies the content height of boxes
generated by block-level, inline-block and replaced elements.This property does not apply to non-replaced inline
-levelelements. See the section on computing heights and margins for non-replaced inline elements for the rules used instead.
[2010-08-06] Clarify “bottom” and “preceding”:
In certain cases (see
the preceding sectionse.g., sections 10.6.4 and 10.6.6), the height of an element that establishes a block formatting context is computed as follows:[…]
In addition, if the element has any floating descendants whose bottom margin edge is below the
bottomthe element's bottom content edge, then the height is increased to include those edges. Only floats that are children of the element itself or of descendants in the normal flow are taken into account, e.g., floats inside absolutely positioned descendants or other floats are not.
[2010-10-26] The effect of 'min-height' and 'max-height' on table cells is still undefined in CSS:
In CSS 2.1, the effect of 'min-height' and 'max-height' on table cells, table rows, and row groups is undefined.
[2010-06-02] Clarifications to the calculation of the line boxes and the minimum line height ("strut"). Item 2 in the bulleted list is expanded and items 3 and 4 are merged, as follows:
- The height of each inline box in the line box is calculated (see "Calculating heights and margins" and the 'line-height' property).
- The inline boxes are aligned vertically according to their 'vertical-align' property. In case they are aligned 'top' or 'bottom', they must be aligned so as to minimize the line box height. If such boxes are tall enough, there are multiple solutions and CSS 2.1 does not define the position of the line box's baseline (i.e., the position of the strut, see below).
- The line box height is the distance between the uppermost box top and the lowermost box bottom. (This includes the strut, as explained under 'line-height' below.)
If the resulting height is smaller than the minimal height of line boxes for this block, as specified by the 'line-height' property, the height is increased to be that minimal height.
Furthermore, in 10.8.1, after the definition of “strut,” clarify that the font determines the initial baseline:
The height and depth of the font above and below the baseline are assumed to be metrics that are contained in the font. (For more details, see CSS level 3.)
[2010-08-24] More consistent use of “inline-level” and “block-level.”
As described in the section on inline formatting contexts, user agents flow inline-level boxes into a vertical stack of line boxes. The height of a line box is determined as follows:
- The height of each inline-level box in the line box is calculated (see "Calculating heights and margins" and the 'line-height' property).
- The inline-level boxes are aligned vertically according to their 'vertical-align' property.
In 10.8.1:
On a
block-level, table-cell, table-caption or inline-blockblock container element whose content is composed of inline-level elements, 'line-height' specifies the minimal height of line boxes within the element. […]On an inline
-levelelement, 'line-height' specifies the height that is used in the calculation of the line box height […]
After the definition of 'vertical-align':
The following values only have meaning with respect to a parent inline
-levelelement, or to the strut of a parentblock-level, table-cell, table-caption or inline-blockblock container element.
[2010-07-19] Clarify text:
On a block-level, table-cell, table-caption or inline-block element whose content is composed of inline-level elements, 'line-height' specifies the minimal height of line boxes within the element. The minimum height consists of a minimum height above the
block'sbaseline and a minimum depth below it, exactly as if each line box starts with a zero-width inline box with theblock'selement's font and line height properties.(what TEX calls a "strut").We call that imaginary box a "strut." (The name is inspired by TeX.).
[2010-08-20] Remove text that talks about the “content area” of an inline box and about “center vertically” and instead make it more explicit how leading is added to a glyph: leading is added above and below a hypothetical box around each glyph that represents the (normal or ideal) height of a line of text in that font, as given in the font metrics.
Add a note referring to 10.6.1 (which defines that the content area is undefined) and explaining that the exact position of backgrounds and borders relative to the line box is undefined.
Also add a note about how to find the relevant metrics in OpenType and TrueType fonts.
[2010-08-20] Clarify some imprecise terms:
When an element contains text that is rendered in more than one font, user agents may determine the 'normal' 'line-height' value according to the largest font size.
Generally, when there is only one value of 'line-height' for all inline boxes in a
paragraphblock container box (and notall imagesreplaced elements, inline-block elements, etc.), the above will ensure that baselines of successive lines are exactly 'line-height' apart. This is important when columns of text in different fonts have to be aligned, for example in a table.
[2010-10-25] Clarify which ancestors are meant:
- A descendant box is positioned absolutely, partly outside the box. Such boxes are not always clipped by the overflow property on their ancestors; specifically, they are not clipped by the overflow of any ancestor between themselves and their containing block
[2010-08-06] The phrase “containing
block” in the example doesn't refer to the technical term “containing block” but simply to the containing
box. Change “containing block” to
“containing div.”
[2010-08-24] More consistent use of “inline-level” and “block-level.”
This property specifies whether content of a
block-levelblock container element is clipped when it overflows the element's box.
[2010-10-25] Add missing inline-table:
Applies to: non-replaced block-level elements, table cells, inline-table, and inline-block elements
[2010-10-25] The computed value of 'auto' is 'auto' also when 'auto' is specified inside 'rect()':
Computed value: For rectangle values, a rectangle consisting of four computed lengths; otherwise, as specified'auto' if specified as 'auto', otherwise a rectangle with four values, each of which is 'auto' if specified as 'auto' and the computed length otherwise
And:
<top>, <right>, <bottom>, and <left> may either have a <length> value or 'auto'. Negative lengths are permitted. The value 'auto' means that a given edge of the clipping region will be the same as the edge of the element's generated border box (i.e., 'auto' means the same as '0' for <top> and <left> (in left-to-right text, <right> in right-to-left text), the same as the
computedused value of the height plus the sum of vertical padding and border widths for <bottom>, and the same as thecomputedused value of the width plus the sum of the horizontal padding and border widths for <right> (in left-to-right text, <left> in right-to-left text), such that four 'auto' values result in the clipping region being the same as the element's border box).
[2010-10-05] Improve wording: the marker box of a list item isn't “optional,” it is sometimes absent. Change:
CSS 2.1 offers basic visual formatting of lists. An element with 'display: list-item' generates a principal box for the element's content
and an optional marker boxand, depending on the values of 'list-style-type' and 'list-style-image', possibly also a marker box as a visual indication that the element is a list item.
[2010-07-14] Because of persistent incompatibilites between implementations, the constraints on the position of 'outside' markers are relaxed in the presence of floats. This will be fixed in a future specification.
[2010-08-06] The 'armenian' list-style-type refers to uppercase Armenian numbering.
[2010-08-06] Define the order of 'inside' marker boxes and ':before' pseudo-elements:
- inside
- The marker box is placed as the first inline box in the principal block box,
after which the element's content flowsbefore the element's content and before any :before pseudo-elements.
[2010-08-06] CSS 2.1 does not specify the precise location of an 'outside' marker box, including its z-order. Append:
CSS 2.1 does not specify the precise location of the marker box or its position in the painting order
[2010-11-25] Because of historical ambiguity, CSS level 2 does not yet require the marker to be visible when 'list-style-position' is 'outside' and 'overflow' is other than 'visible'. Insert in the definition of 'outside':
In CSS 2.1, a UA may hide the marker if the element's 'overflow' is other than 'visible'. (This is expected to change in the future.)
[2010-07-07] The @page rule can contain not just declarations but also other @-rules. (There aren't any such nested @-rules defined in level 2, but there are in level 3.)
An @page rule consists of the keyword "@page", followed by an optional page selector, followed by a block
of declarationscontaining declarations and at-rules.Note: CSS level 2 has no at-rules that may appear inside @page, but such at-rules are expected to be defined in level 3.
And add just above section 13.2.1:
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.
[2010-10-25] Whether the first page of a document is :left or :right depends on the major writing direction. Give an example of how:
All pages are automatically classified by user agents into either the :left or :right pseudo-class. Whether the first page of a document is :left or :right depends on the major writing direction of the root element. For example, the first page of a document with a left-to-right major writing direction would be a :right page, and the first page of a document with a right-to-left major writing direction would be a :left page. To explicitly force a document to begin printing on a left or right page, authors can insert a page break before the first generated box.
And in 13.3.1:
Whether the first page of a document is :left or :right depends on the major writing direction of the document.
[2010-08-24] More consistent use of “inline-level” and “block-level.” Change for both 'orphans' and 'widows':
Applies to: block-levelblock container elements
And change:
The 'orphans' property specifies the minimum number of lines in a block
elementcontainer that must be left at the bottom of a page. The 'widows' property specifies the minimum number of lines in a blockelementcontainer that must be left at the top of a page. Examples of how they are used to control page breaks are given below.
[2010-08-24] More consistent use of “inline-level” and “block-level.” Change:
- In the vertical margin between block-level boxes. […]
- Between line boxes inside a block container box.
- Between the content edge of a block container box and the outer edges of its child content […]
[2010-07-19] The specification was ambiguous as to whether parentheses, brackets and braces in font names must always be escaped, or only when needed to conform to the syntax for declarations. Because of that, and because of the many bugs in implementations, all font names must now either be quoted, or be escaped so as to consist of only identifiers.
[2010-08-26] Make it clearer that CSS does not try to define what fonts are serif or sans-serif:
15.3.1.1 serif
Glyphs of serif fonts, as the term is used in CSS, tend to have finishing strokes, flared or tapering ends, or have actual serifed endings (including slab serifs). [&hellip]
15.3.1.2 sans-serif
Glyphs in sans-serif fonts, as the term is used in CSS, tend to have stroke endings that are plain –
without anywith little or no flaring, cross stroke, or other ornamentation. […]
[2010-04-19] The meaning of the keywords 'bolder' and 'lighter' no longer depends on both the inherited weight and the actually used font, but only on the inherited weight.
[2010-10-13] Clarify the algorithm for mapping CSS font weight values to the actual weights of a font and make it normative:
The association of other weights within a family to the numerical weight values is intended only to preserve the ordering of darkness within that family. However, the following heuristics tell how the assignment is done in typical cases:
- If the font family already uses a numerical scale with nine values (like e.g., OpenType does), the font weights should be mapped directly.
- If there is both a face labeled Medium and one labeled Book, Regular, Roman or Normal, then the Medium is normally assigned to the '500'.
- The font labeled "Bold" will often correspond to the weight value '700'.
Once the font family's weights are mapped onto the CSS scale, missing weights are selected as follows:
If there are fewer then 9 weights in the family, the default algorithm for filling the "holes" is as follows. If '500' is unassigned, it will be assigned the same font as '400'. If any of the values '600', '700', '800' or '900' remains unassigned, they are assigned to the same face as the next darker assigned keyword, if any, or the next lighter one otherwise. If any of '300', '200' or '100' remains unassigned, it is assigned to the next lighter assigned keyword, if any, or the next darker otherwise.- If the desired weight is less than 400, weights below the desired weight are checked in descending order followed by weights above the desired weight in ascending order until a match is found.
- If the desired weight is greater than 500, weights above desired weight are checked in ascending order followed by weights below the desired weight in descending order until a match is found.
- If the desired weight is 400, 500 is checked first and then the rule for desired weights less than 400 is used.
- If the desired weight is 500, 400 is checked first and then the rule for desired weights less than 400 is used.
[2010-08-06] Changed “Percentages:
refer to parent element's font size” to
“Percentages: refer to inherited font size” so
that it uses the same terminology as Section 4.3.3.
[2010-08-24] More consistent use of “inline-level” and “block-level.” Change:
Applies to: block-level elements, table cells and inline blocksblock containers[…]
This property specifies the indentation of the first line of text in a block container.
[2010-10-25] Clarify that the “first line” of the “first box,” etc., is the same as the “first formatted line” of chapter 5:
'Text-indent' only affects a line if it is the first formatted line of an element. For example, the first line of an anonymous block box is only affected if it is the first child of its parent element.
[2010-07-19] The value 'pre-line' of 'white-space' does not inhibit justification. (Only lines that end with an explicit newline aren't justified, as is the case for any value of 'white-space'.) But, 'pre-wrap' does inhibit justification. Replace
If the computed value of text-align is 'justify' while the computed value of white-space is 'pre' or 'pre-line', the actual value of text-align is set to the initial value.
with
If an element has a computed value for 'white-space' of 'pre' or 'pre-wrap', then neither the glyphs of that element's text content nor its white space may be altered for the purpose of justification.
[2010-08-24] More consistent use of “inline-level” and “block-level.” Change:
Applies to: block-level elements, table cells and inline blocksblock containersThis property describes how inline-level content of a block container is aligned.
And:
[…] In the case of 'left', 'right' and 'center', this property specifies how the inline-level boxes within each line box align with respect to the line box's left and right sides; alignment is not with respect to the viewport. In the case of 'justify', this property specifies that the inline-level boxes are to be made flush with both sides of the block container if possible, by expanding or contracting the contents of inline boxes, else aligned as for the initial value.
[2010-08-24] Clarify that 'text-decoration' does not propagate to inline-table and inline-block elements. Change:
This property describes decorations that are added to the text of an element using the element's color. When specified on
an inline element, it affects all the boxes generated by that element; for all other elements, the decorations are propagated to an anonymous inline box that wraps all the in-flow inline children of the element, and to any block-level in-flow descendants. It is not, however, further propagated to floating and absolutely positioned descendants, nor to the contents of 'inline-table' and 'inline-block' descendants.or propagated to an inline element, it affects all the boxes generated by that element, and is further propagated to any in-flow block-level boxes that split the inline (see section 9.2.1.1). For block containers that establish an inline formatting context, the decorations are propagated to an anonymous inline element that wraps all the in-flow inline-level children of the block container. For all other elements it is propagated to any in-flow children. Note that text decorations are not propagated to floating and absolutely positioned descendants, nor to the contents of atomic inline-level descendants such as inline blocks and inline tables.
and:
If an element contains no text, user agents must refrain from rendering these text decorations on the element. For example, images will not be underlined.User agents must not render these text decorations on content that is not text. For example, images and inline blocks must not be underlined.
[2010-10-05] CSS 2.1 does not specify if a text decoration that is specified on a transparent element ('visibility: hidden') is itself transparent, or only transparent where the text is transparent. Add this note:
Note. If an element E has both 'visibility: hidden' and 'text-decoration: underline', the underline is invisible (although any decoration of E's parent is visible.) However, CSS 2.1 does not specify if the underline is visible or invisible in E's children:
<span style="visibility: hidden; text-decoration: underline"> <span style="visibility: visible"> underlined or not? </span> </span>This is expected to be specified in level 3 of CSS.
[2010-04-19] Word spacing does not affect fixed-width spaces. Change:
Word spacing affects each space (U+0020)
,and non-breaking space (U+00A0)and ideographic space (U+3000), left in the text after the white space processing rules have been applied. The effect of the property on other word-separator characters is undefined. However general punctuation, characters with zero advance width (such as the zero with space U+200B) and fixed-width spaces (such as U+3000 and U+2000 through U+200A) are not affected.
[2010-10-25] If the document language specifies how newlines are represented, those newlines must be passed to the CSS UA as line feed (LF) characters. If the document language does not define how newlines are expressed (e.g., if text is inserted with the 'content' property), the CSS UA must treat CR, and CRLF as if they were LF:
Newlines in the source can be represented by a carriage return (U+000D), a linefeed (U+000A) or both (U+000D U+000A) or by some other mechanism that identifies the beginning and end of document segments, such as the SGML RECORD-START and RECORD-END tokens. The CSS 'white-space' processing model assumes all newlines have been normalized to line feeds. UAs that recognize other newline representations must apply the white space processing rules as if this normalization has taken place. If no newline rules are specified for the document language, each carriage return (U+000D) and CRLF sequence (U+000D U+000A) in the document text is treated as single line feed character. This default normalization rule also applies to generated content.
[…]
- Each tab (U+0009),
carriage return (U+000D),or space (U+0020) character surrounding a linefeed (U+000A) character is removed if 'white-space' is set to 'normal', 'nowrap', or 'pre-line'.
[2010-08-06] The sentence that absolutely positioned elements do not create line breaking opportunities is normative, not informative.
[2010-08-06] The first paragraph is moved to 9.2.2.1. Also, as is clear from the latter section, the “should” is a “must”:
Any text that is directly contained inside a block container element (not inside an inline element)
shouldmust be treated as an anonymous inline element.
[2010-08-24] More consistent use of “inline-level” and “block-level.” Change:
Then, the
entire block is renderedblock container's inlines are laid out.
[2010-08-04] Clarify that the term “row group” includes header groups and footer groups as well:
Thus, the table model consists of tables, captions, rows, row groups (including header groups and footer groups), columns, column groups, and cells.
[2010-08-24] XML and HTML5, unlike SGML, do not automatically remove insignificant white space. Change the rules for generating anonymous table elements to suppress most white space between elements, rather than consider it the content of an anonymous table cell.
[2010-08-24] The static position of absolutely positioned elements between table cells or rows was not very useful. Define that the static position of such an element is found not just as if the element had 'position: static', but also had 'display: inline' and zero width and height.
[2010-04-19] The caption of the image still describes the image as it was in the previous version. Change:
Diagram of a table with a caption above it
; the top margin of the caption is collapsed with the top margin of the table.
[2010-10-13] Clarify which of the two boxes generated by a table element is the principal box:
In both cases, the table
boxgeneratesan anonymous boxa principal block 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 block-level boxes that retain their own content, padding, margin, and border areas, and are rendered as normalblocksblock boxes inside theanonymoustable 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
anonymoustable wrapper box is a 'block' box if the table is block-level, and an 'inline-block' box if the table is inline-level. Theanonymoustable wrapper box establishes a block formatting context. The table box (not theanonymoustable wrapper box) is used when doing baseline vertical alignment for an 'inline-table'. The width of theanonymoustable 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 theanonymoustable wrapper box's containing block, not theanonymoustable wrapper box itself.The computed values of properties 'position', 'float', 'margin-*', 'top', 'right', 'bottom', and 'left' on the table box are used on the
anonymoustable wrapper box instead of the table box. The table box uses the initial values for those properties.
[2010-10-25] The width of the table caption contributes to the width of the table if 'table-layout' is 'auto':
This gives a maximum and minimum width for each column.
The caption width minimum (CAPMIN) is determined by calculating for each caption the minimum caption outer width as the MCW of a hypothetical table cell that contains the caption formatted as "display: block". The greatest of the minimum caption outer widths is CAPMIN.
Column and caption widths influence the final table width as follows:
- If the 'table' or 'inline-table' element's 'width' property has a computed value (W) other than 'auto', the
property's value as used for layoutused width is the greater of W, CAPMIN, and the minimum width required by all the columns plus cell spacing or borders (MIN). IfWthe used widthis greater than MIN, the extra width should be distributed over the columns.- If the 'table' or 'inline-table' element has 'width: auto', the
table width used for layoutused width is the greater of the table's containing block width, CAPMIN, and MIN. However, if either CAPMIN or the maximum width required by the columns plus cell spacing or borders (MAX) is less than that of the containing block, useMAXmax(MAX, CAPMIN).
[2010-07-15] Clarify that the height of a table row can be influenced by 'vertical-align' and 'height', but the content box of the table cell is not affected.
[…] it is the maximum of the row's specified 'height', the specified 'height' of each cell in the row, and the minimum height (MIN) required by the cells
and
In CSS 2.1, the height of a cell box is the
maximum of the table cell's 'height' property and the minimum height required by the content (MIN).minimum height required by the content. The table cell's 'height' property can influence the height of the row, but it does not increase the height of the cell box.A value of 'auto' for 'height' implies that the value MIN will be used for layout.
[2010-08-24] More consistent use of “inline-level.” Change:
The horizontal alignment of
a cell's inline contentinline-level content within a cell box
[2010-08-06] BCP 47 replaces RFC 3066.
[2010-10-05] HTML defines that HTML's block elements represent a Unicode embedding even if they are displayed inline by means of a style sheet. The default style sheet for HTML didn't yet express that. Add:
html, address,
blockquote,
body, dd, div,
dl, dt, fieldset, form,
frame, frameset,
h1, h2, h3, h4,
h5, h6, noframes,
ol, p, ul, center,
dir, hr, menu, pre { display: block; unicode-bidi: embed }
[2010-07-07] Clarification:
The
stacking order forpainting order for the descendants of an element generating a stacking context (see the 'z-index' property) is: […]
[2010-10-25] The appendix is not normative.
Bert Bos