1. About the CSS 2.2 Specification
1.1. CSS 2.2 vs CSS 2
The CSS community has gained significant experience with the CSS2 specification since it became a recommendation in 1998. Errors in the CSS2 specification [CSS20] have subsequently been corrected in the first revised edition [CSS21] in 2011, but new errata were necessary.
While many of the issues will be addressed by the upcoming CSS3 specifications, the current state of affairs hinders the implementation and interoperability of CSS2. The CSS 2.2 specification attempts to address this situation by:
- Maintaining compatibility with those portions of CSS2 that are widely accepted and implemented.
- Incorporating all published CSS2 errata.
- Where implementations overwhelmingly differ from the CSS2 specification, modifying the specification to be in accordance with generally accepted practice.
- Removing CSS2 features which, by virtue of not having been implemented, have been rejected by the CSS community. CSS 2.2 aims to reflect what CSS features are reasonably widely implemented for HTML and XML languages in general (rather than only for a particular XML language, or only for HTML).
- Removing CSS2 features that will be obsoleted by CSS3, thus encouraging adoption of the proposed CSS3 features in their place.
- Adding a (very) small number of new property values, when implementation experience has shown that they are needed for implementing CSS2.
Thus, while it is not the case that a CSS2 style sheet is necessarily forwards-compatible with CSS 2.2, it is the case that a style sheet restricting itself to CSS 2.2 features is more likely to find a compliant user agent today and to preserve forwards compatibility in the future. While breaking forward compatibility is not desirable, we believe the advantages to the revisions in CSS 2.2 are worthwhile.
CSS 2.2 is derived from and is intended to replace CSS 2.1 and CSS2. Some parts of CSS2 are unchanged in CSS 2.2, some parts have been altered, and some parts removed. The removed portions may be used in a future CSS3 specification. Future specs should refer to CSS 2.2 (unless they need features from CSS2 which have been dropped in CSS 2.2, and then they should only reference CSS2 for those features, or preferably reference such feature(s) in the respective CSS3 Module that includes those feature(s)).
1.2. Reading the specification
This section is non-normative.
This specification has been written with two types of readers in mind: CSS authors and CSS implementors. We hope the specification will provide authors with the tools they need to write efficient, attractive, and accessible documents, without overexposing them to CSS’s implementation details. Implementors, however, should find all they need to build conforming user agents.
The specification begins with a general presentation of CSS and becomes more and more technical and specific towards the end. For quick access to information, a general table of contents, specific tables of contents at the beginning of each section, and an index provide easy navigation, in both the electronic and printed versions.
The specification has been written with two modes of presentation in mind: electronic and printed. Although the two presentations will no doubt be similar, readers will find some differences. For example, links will not work in the printed version (obviously), and page numbers will not appear in the electronic version. In case of a discrepancy, the electronic version is considered the authoritative version of the document.
1.3. How the specification is organized
This section is non-normative.
The specification is organized into the following sections:
- Section 2: An introduction to CSS 2
- The introduction includes a brief tutorial on CSS 2 and a discussion of design principles behind CSS 2.
- Sections 3 - 18: CSS 2 reference manual.
- The bulk of the reference manual consists of the CSS 2 language reference. This reference defines what may go into a CSS 2 style sheet (syntax, properties, property values) and how user agents must interpret these style sheets in order to claim conformance.
- Appendixes:
- Appendixes contain information about a sample style sheet for HTML 4, changes from CSS 2.1, the grammar of CSS 2, a list of normative and informative references, and two indexes: one for properties and one general index.
1.4. Conventions
1.4.1. Document language elements and attributes
- CSS property and pseudo-class names are delimited by single quotes.
- CSS values are delimited by single quotes.
- Document language attribute names are in lowercase letters and delimited by double quotes.
1.4.2. CSS property definitions
Each CSS property definition begins with a summary of key information that resembles the following:
| Name: | property-name |
|---|---|
| Value: | legal values & syntax |
| Initial: | initial value |
| Applies to: | elements this property applies to |
| Inherited: | whether the property is inherited |
| Percentages: | how percentage values are interpreted |
| Computed value: | how to compute the computed value |
| Canonical order: | per grammar |
| Media: | which media groups the property applies to |
1.4.2.1. Value
This part specifies the set of valid values for the property whose name is property-name. A property value can have one or more components. Component value types are designated in several ways:
- keyword values (e.g., auto, disc, etc.)
- basic data types, which appear between "<" and ">" (e.g., <length>, <percentage>, etc.). In the electronic version of the document, each instance of a basic data type links to its definition.
- types that have the same range of values as a property bearing the same name (e.g., <border-width> <background-attachment>, etc.). In this case, the type name is the property name (complete with quotes) between "<" and ">" (e.g., <border-width>). Such a type does not include the value inherit. In the electronic version of the document, each instance of this type of non-terminal links to the corresponding property definition.
- non-terminals that do not share the same name as a property. In this case, the non-terminal name appears between "<" and ">", as in <border-width>. Notice the distinction between <border-width> and <border-width>; the latter is defined in terms of the former. The definition of a non-terminal is located near its first appearance in the specification. In the electronic version of the document, each instance of this type of value links to the corresponding value definition.
Other words in these definitions are keywords that must appear literally, without quotes (e.g., red). The slash (/) and the comma (,) must also appear literally.
Component values may be arranged into property values as follows:
- Several juxtaposed words mean that all of them must occur, in the given order.
- A bar (|) separates two or more alternatives: exactly one of them must occur.
- A double bar (||) separates two or more options: one or more of them must occur, in any order.
- A double ampersand (&&) separates two or more components, all of which must occur, in any order.
- Brackets ([ ]) are for grouping.
Juxtaposition is stronger than the double ampersand, the double ampersand is stronger than the double bar, and the double bar is stronger than the bar. Thus, the following lines are equivalent:
a b | c || d && e f [ a b ] | [ c || [ d && [ e f ]]]
Every type, keyword, or bracketed group may be followed by one of the following modifiers:
- An asterisk (*) indicates that the preceding type, word, or group occurs zero or more times.
- A plus (+) indicates that the preceding type, word, or group occurs one or more times.
- A question mark (?) indicates that the preceding type, word, or group is optional.
- A pair of numbers in curly braces ({A,B}) indicates that the preceding type, word, or group occurs at least A and at most B times.
The following examples illustrate different value types:
Value: N | NW | NE
Value: [ <length> | thick | thin ]{1,4}
Value: [<family-name> , ]* <family-name>
Value: <uri>? <color> [ / <color> ]?
Value: <uri> || <color>
Value: inset? && [ <length>{2,4} && <color>? ]
Component values are specified in terms of tokens, as described in Appendix G.2. As the grammar allows spaces
between tokens in the components of the expr production,
spaces may appear between tokens in property values.
Note: In many cases, spaces will in fact be
required between tokens in order to distinguish them from
each other. For example, the value 1em2em would be parsed as a
single DIMEN token with the number 1 and the identifier
em2em, which is an invalid unit. In this case, a space would be
required before the 2 to get this parsed as the two lengths 1em
and 2em.
1.4.2.2. Initial
This part specifies the property’s initial value. Please consult the section on