Contents
The CSS community has gained significant experience with the CSS2specification since it became a recommendation in 1998. Errors in theCSS2 specification have subsequently been corrected via thepublication of various errata, but there has not yet been anopportunity for the specification to be changed based on experiencegained.
While many of these issues will be addressed by the upcoming CSS3specifications, the current state of affairs hinders theimplementation and interoperability of CSS2. The CSS 2.1 specificationattempts to address this situation by:
Thus, while it is not the case that a CSS2 style sheet isnecessarily forwards-compatible with CSS 2.1, it is the case that astyle sheet restricting itself to CSS 2.1 features is more likely tofind a compliant user agent today and to preserve forwardscompatibility in the future. While breaking forward compatibility isnot desirable, we believe the advantages to the revisions in CSS 2.1are worthwhile.
CSS 2.1 is derived from and is intended to replace CSS2. Someparts of CSS2 are unchanged in CSS 2.1, some parts have beenaltered, and some parts removed. The removed portions may be used in afuture CSS3 specification. Future specs should refer to CSS 2.1(unless they need features from CSS2 which have been dropped inCSS 2.1, and then they should only reference CSS2 for thosefeatures, or preferably reference such feature(s) in the respectiveCSS3 Module that includes those feature(s)).
This section is non-normative.
This specification has been written with two types of readers inmind: CSS authors and CSS implementors. We hope the specification willprovide authors with the tools they need to write efficient,attractive, and accessible documents, without overexposing them toCSS's implementation details. Implementors, however, should find allthey need to buildconforming useragents.The specification begins with a general presentation of CSS andbecomes more and more technical and specific towards the end. Forquick 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 electronicand printed versions.
The specification has been written with two modes of presentationin mind: electronic and printed. Although the two presentations willno doubt be similar, readers will find some differences. For example,links will not work in the printed version (obviously), and pagenumbers will not appear in the electronic version. In case of adiscrepancy, the electronic version is considered the authoritativeversion 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 keyinformation 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 whosename is'property-name'. A propertyvalue can have one or more components. Component value types are designatedin several ways:
Other words in these definitions are keywords that must appearliterally, 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 doubleampersand is stronger than the double bar, and the double baris 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 ofthe 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 inAppendix G.2. As the grammar allows spacesbetween tokens in the components of theexpr production,spaces may appear between tokens in property values.
Note: In many cases, spaces will in fact berequired between tokens in order to distinguish them fromeach other. For example, the value '1em2em' would be parsed as asingleDIMEN token with the number '1' and the identifier'em2em', which is an invalid unit. In this case, a space would berequired before the '2' to get this parsed as the two lengths '1em'and '2em'.
This part specifies the property's initial value. Please consultthe section onthe cascade for informationabout the interaction between style sheet-specified, inherited, andinitial property values.
This part lists the elements to which the property applies. Allelements are considered to have all properties, but some propertieshave no rendering effect on some types of elements. For example, the
This part indicates whether the value of the property is inheritedfrom an ancestor element. Please consult the section onthe cascade for information about theinteraction between style sheet-specified, inherited, and initialproperty values.
This part indicates how percentages should be interpreted, if they occur inthe value of the property. If "N/A" appears here, it means that theproperty does not accept percentages in its values.
This part indicates themediagroups to which the property applies. Information about mediagroups is non-normative.
This part describes the computed value for the property. See thesection oncomputed valuesfor how this definition is used.
Some properties areshorthand properties, meaning that they allowauthors to specify the values of several properties with a singleproperty.
For instance, the'font' propertyis a shorthand property for setting
When values are omitted from a shorthand form, each"missing" property is assignedits initial value (see the section onthecascade).
Example(s):
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,
All examples that illustrate illegal usage are clearlymarked as "ILLEGAL EXAMPLE".
HTML examples lacking DOCTYPE declarations are SGML Text Entitiesconforming to the HTML 4.01 Strict DTD[HTML4]. Other HTML examplesconform to the DTDs given in the examples.
All notes are informative only.
Examples and notes aremarked withinthe source HTML for the specification and CSS user agents willrender them specially.
Most images in the electronic version of this specification areaccompanied by "long descriptions" of what they represent. A link tothe 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 theacknowledgmentssection of CSS2 for the people that contributed to CSS2.
We would like to thank the following people who, through theirinput and feedback on the www-style mailing list, have helped us withthe 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,JanEirikOlufsen,JanRolandEriksson,Joris Huizer,Joshua Prowse,Kai Lahmann,Kevin Smith,Lachlan Cannon,Lars Knoll,Lauri Raittila,Mark Gallagher,Michael Day,Peter Sheerin,Rijkvan 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 theOpen eBook Publication Structure Working Group Editors. We would also like to thankGary Schnabl,Glenn Adams andSusan Lesch who helped proofread earlier versions of this document.
In addition, we would like to extend special thanks toElika J. Etemad,Ada Chan andBoris Zbarsky who have contributed significant time to CSS 2.1, and toKimberly Blessing for help with the editing.
Many thanks also to the following people for their helpwith 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), andPaul Nelson (Microsoft Corp.).