Contents
The CSS community has gained significant experience with the CSS2 specification since it became a recommendation in 1998. Errors in the CSS2 specification have subsequently been corrected via the publication of various errata, but there has not yet been an opportunity for the specification to be changed based on experience gained.
While many of these issues will be addressed by the upcoming CSS3 specifications, the current state of affairs hinders the implementation and interoperability of CSS2. The CSS 2.1 specification attempts to address this situation by:
Thus, while it is not the case that a CSS2 style sheet is necessarily forwards-compatible with CSS 2.1, it is the case that a style sheet restricting itself to CSS 2.1 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.1 are worthwhile.
CSS 2.1 is derived from and is intended to replace CSS2. Some parts of CSS2 are unchanged in CSS 2.1, 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.1 (unless they need features from CSS2 which have been dropped in CSS 2.1, 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)).
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.
This section is non-normative.
The specification is organized into the following sections:
Each CSS property definition begins with a summary of key information that resembles the following:
| 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 |
| Media: | which media groups the property applies to |
| Computed value: | how to compute the computed 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:
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:
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:
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'.
This part specifies the property's initial value. Please consult the section on the cascade for information about the interaction between style sheet-specified, inherited, and initial property values.
This part lists the elements to which the property applies. All elements are considered to have all properties, but some properties have no rendering effect on some types of elements. For example, the 'clear' property only affects block-level elements.
This part indicates whether the value of the property is inherited from an ancestor element. Please consult the section on the cascade for information about the interaction between style sheet-specified, inherited, and initial property values.
This part indicates how percentages should be interpreted, if they occur in the value of the property. If "N/A" appears here, it means that the property does not accept percentages in its values.
This part indicates the media groups to which the property applies. Information about media groups is non-normative.
This part describes the computed value for the property. See the section on computed values for how this definition is used.
Some properties are shorthand properties, meaning that they allow authors to specify the values of several properties with a single property.
For instance, the 'font' property is a shorthand property for setting 'font-style', 'font-variant', 'font-weight', 'font-size', 'line-height', and 'font-family' all at once.
When values are omitted from a shorthand form, each "missing" property is assigned its initial value (see the section on the cascade).
The multiple style rules of this example:
h1 {
font-weight: bold;
font-size: 12pt;
line-height: 14pt;
font-family: Helvetica;
font-variant: normal;
font-style: normal;
}
may be rewritten with a single shorthand property:
h1 { font: bold 12pt/14pt Helvetica }
In this example, 'font-variant', and 'font-style' take their initial values.
All examples that illustrate illegal usage are clearly marked as "ILLEGAL EXAMPLE".
HTML examples lacking DOCTYPE declarations are SGML Text Entities conforming to the HTML 4.01 Strict DTD [HTML4]. Other HTML examples conform to the DTDs given in the examples.
All notes are informative only.
Examples and notes are marked within the source HTML for the specification and CSS user agents will render them specially.
Most images in the electronic version of this specification are accompanied by "long descriptions" of what they represent. A link to the long description is denoted by a "[D]" after the image.
Images and long descriptions are informative only.
This section is non-normative.
CSS 2.1 is based on CSS2. See the acknowledgments section of CSS2 for the people that contributed to CSS2.
We would like to thank the following people who, through their input and feedback on the www-style mailing list, have helped us with the creation of this specification: Andrew Clover, Bernd Mielke, C. Bottelier, Christian Roth, Christoph Päper, Claus Färber, Coises, Craig Saila, Darren Ferguson, Dylan Schiemann, Etan Wexler, George Lund, James Craig, Jan Eirik Olufsen, Jan Roland Eriksson, Joris Huizer, Joshua Prowse, Kai Lahmann, Kevin Smith, Lachlan Cannon, Lars Knoll, Lauri Raittila, Mark Gallagher, Michael Day, Peter Sheerin, Rijk van Geijtenbeek, Robin Berjon, Scott Montgomery, Shelby Moore, Stuart Ballard, Tom Gilder, Vadim Plessky, Peter Moulder, Anton Prowse, Gérard Talbot, Ingo Chao, Bruno Fassino, Justin Rogers, Boris Zbarsky, Garrett Smith, Zack Weinberg, Bjoern Hoehrmann, and the Open eBook Publication Structure Working Group Editors. We would also like to thank Gary Schnabl, Glenn Adams and Susan Lesch who helped proofread earlier versions of this document.
In addition, we would like to extend special thanks to Elika J. Etemad, Ada Chan and Boris Zbarsky who have contributed significant time to CSS 2.1, and to Kimberly Blessing for help with the editing.
Many thanks also to the following people for their help with the test suite: Robert Stam, Aharon Lanin, Alan Gresley, Alan Harder, Alexander Dawson, Arron Eicholz, Bernd Mielke, Bert Bos, Boris Zbarsky, Bruno Fassino, Daniel Schattenkirchner, David Hammond, David Hyatt, Eira Monstad, Elika J. Etemad, Gérard Talbot, Gabriele Romanato, Germain Garand, Hilbrand Edskes, Ian Hickson, James Hopkins, Justin Boss, L. David Baron, Lachlan Hunt, Magne Andersson, Marc Pacheco, Mark McKenzie-Bell, Matt Bradley, Melinda Grant, Michael Turnwall, Ray Kiddy, Richard Ishida, Robert O'Callahan, Simon Montagu, Tom Clancy, Vasil Dinkov, … and all the contributors to the CSS1 test suite.
Working Group members active during the development of this specification: César Acebal (Universidad de Oviedo), Tab Atkins Jr. (Google, Inc.), L. David Baron (Mozilla Foundation), Bert Bos (W3C/ERCIM), Tantek Çelik (W3C Invited Experts), Cathy Chan (Nokia), Giorgi Chavchanidze (Opera Software), John Daggett (Mozilla Foundation), Beth Dakin (Apple, Inc.), Arron Eicholz (Microsoft Corp.), Elika J. Etemad (W3C Invited Experts), Simon Fraser (Apple, Inc.), Sylvain Galineau (Microsoft Corp.), Daniel Glazman (Disruptive Innovations), Molly Holzschlag (Opera Software), David Hyatt (Apple, Inc.), Richard Ishida (W3C/ERCIM), John Jansen (Microsoft Corp.), Brad Kemper (W3C Invited Experts), Håkon Wium Lie (Opera Software), Chris Lilley (W3C/ERCIM), Peter Linss (HP), Markus Mielke (Microsoft Corp.), Alex Mogilevsky (Microsoft Corp.), David Singer (Apple Inc.), Anne van Kesteren (Opera Software), Steve Zilles (Adobe Systems Inc.), Ian Hickson (Google, Inc.), Melinda Grant (HP), Øyvind Stenhaug (Opera Software), and Paul Nelson (Microsoft Corp.).