Please email error reports to css2-editors@w3.org.
Shorthand properties take a list of subproperty values or the value 'inherit'. One cannot mix 'inherit' with other subproperty values as it would not be possible to specify the subproperty to which 'inherit' applied. The definitions of a number of shorthand properties do not enforce this rule: 'border-top', 'border-right', 'border-bottom', 'border-left', 'border', 'background', 'font', 'list-style', 'cue', and 'outline'.
The "nmchar" token should also allow the range "A-Z".
Several values described in subsections of this section incorrectly allow two "+" or "-" signs at their beginnings. Lengths, for instance, are described as follows:
The format of a length value (denoted by <length> in this specification) is an optional sign character ('+' or '-', with '+' being the default) immediately followed by a <number> (with or without a decimal point) immediately followed by a unit identifier (e.g., px, deg, etc.).
However, since <number> already allows a "+" or "-" sign, the above definition means two signs may appear. The following value types allow two signs but are meant to allow one initial sign only:
The definition of the value 'static' should say that the properties 'top', 'right', 'bottom', and 'left' do not apply.
The properties 'top', 'right', 'bottom', and 'left', incorrectly refer to offsets with respect to a box's content edge. The proper edge is the margin edge. Thus, for 'top', the description should read, "This property specifies how far a box's top margin edge is offset below the top edge of the box's containing block."
In the last sentence of the paragraph following the equation -- "If the value of 'direction' is 'ltr', this happens to 'margin-left' instead." -- substitute 'rtl' for 'ltr'.
The height calculation for block-level, non-replaced elements in normal flow, and floating, non-replaced elements is not quite correct. The height calculation should read as follows:
If 'top', 'bottom', 'margin-top', or 'margin-bottom' are 'auto', their computed value is 0. If 'height' is 'auto', the height depends on whether the element has any block-level children and whether it has padding or borders.
If it only has inline-level children, the height is the distance between the top of the topmost line box and the bottom of the bottommost line box.
If it has block-level children, the height is the distance between the top border-edge of the topmost block-level child box and the bottom border-edge of the bottommost block-level child box. However, if the element has a non-zero top padding and/or top border, then the content starts at the top margin edge of the topmost child. Similarly, if the element has a non-zero bottom padding and/or bottom border, then the content ends at the bottom margin edge of the bottommost child.
Only children in the normal flow are taken into account (i.e., floating boxes and absolutely positioned boxes are ignored, and relatively positioned boxes are considered without their offset). Note that the child box may be an anonymous box.
The example of a DIV element containing a BLOCKQUOTE containing another DIV is not rendered correctly. The first rule:
DIV { width : 100px; height: 100px;
border: thin solid red;
}
Applies to both the external and internal DIV, so, for example, the internal DIV box should be rendered with a red border. The intention of the authors was that the first style rule only apply to the external DIV. This could be accomplished by making it more specific by adding a "class" or "id" value to the markup and changing the selectors accordingly.
Under the 'font-size-adjust' property, in the formula given for <number>, the variables y, a', and c are explained. An explanation for the variable "a" is missing and should read:
a = aspect value of first-choice font
'Totum' and 'Kodic' is not a 'serif' but 'sans-serif'. 'pathang' is not a 'sans-serif' but 'serif'.
For the example with the LINK element, the list following the example incorrectly refers to the "ref" attribute. This should be the "href" attribute.
Under the definition of "Child", the phrase "if an only if" should read "if and only if".
Under the definition of "Sibling", the last sentence should read, "Element B is a following sibling if it comes after A in the document tree."
The correct RFC number for the registration of the "text/css" content type is RFC 2318, not RFC 2138.
In "XML uses an attribute called XML:LANG", the XML attribute should be in lowercase, i.e., xml:lang.
The rendering of the first example is:
THIS IS A SOMEWHAT LONG HTML PARAGRAPH THAT will be broken into several lines.
while the fictional tag sequence is given as:
<P><P:first-line> This is a somewhat long HTML
paragraph that will </P:first-line> ...
The word "will" should follow the fictional tag sequence for :first-line.
The last sentence in the penultimate paragraph should begin "All user and author rules..." instead of "All rules user and author rules...".
The individual border-X-color property definitions may also take the value 'transparent'.
In the example after the diagram, the HTML fragment "<P>This is the content of P.</>" should end instead with the end tag "</P>".
In the (third paragraph) sentence "In the example, the color of the anonymous initial boxes is inherited from the P, but the background is transparent", substitute the word "inline" for "initial".
In the second paragraph, "a new a new" should only read "a new".
In the definition of <counter>, the sentence "The latter function also has two forms: 'counter(name, string)' or 'counter(name, string, style)'" should read "two forms: 'counters(name, string)' or 'counters(name, string, style)'"
The first sentence has one too many "the"s in "please consult the the Gamma Tutorial...".
In the following sentence from the definition of the 'voice-family' property:
If quoting is omitted, any whitespace characters before and after the font name are ignored and any sequence of whitespace characters inside the font name is converted to a single space.
all occurrences of the word "font" should be replaced by "voice family".
The value of the 'line-height' property set for the BODY element should be "1.12em".
The OBJECT and APPLET elements should have 'display: inline'.
Near the end of the section, the text 'Note the whitespace on either side of the "*"' may be misleading. The note is not meant to imply that whitespace is required on both sides of the "*" (since the grammar does not require it in this case) but that one may use whitespace in this case.
The 'inherit' value causes the properties value to be inherited. This applies even to properties for which values do not otherwise inherit.
The statement "When an inline box is split, margins, borders, and padding have no visual effect where the split occurs." may be generalized. Margins, borders, and padding have no visual effect where one or more splits occur.
The following attempts to clarify the meaning of the 'left', 'right', 'top' and 'bottom' properties for relative positioning.
For relatively positioned elements, 'left' and 'right' move the box(es) horizontally, without changing their size. 'Left' moves the boxes to the right, and 'right' moves them to the left. Since boxes are not split or stretched as a result of 'left' or 'right', the computed values are always: left = -right.
If both 'left' and 'right' are 'auto' (their initial values), the computed values are '0' (i.e., the boxes stay in their original position).
If 'left' is 'auto', its computed 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 computed value is minus the value of 'left'.
If neither 'left' nor 'right' is 'auto', the position is over-constrained, and one of them has to be ignored. If the 'direction' property is 'ltr', the value of 'left' wins and 'right' becomes -'left'. If 'direction' is 'rtl', 'right' wins and 'left' is ignored.
Example. The following two style sheets are equivalent:
DIV.a8 { position: relative; left: -1em; right: auto }
and
DIV.a8 { position: relative; left: auto; right: 1em }
The 'top' and 'bottom' properties move relatively positioned elements up or down. They also must be each other's negative. If both are 'auto', their computed 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., the computed value of 'bottom' will be minus the value of 'top').
The parenthetical phrase "somewhat analogous to the 'display' property" is misleading. The 'speak' property resembles 'visibility' in some ways and 'display' in others.