1 About the CSS2CSS 2.1 Specification

1.1 CSS 2.1 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 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:

• 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.1 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.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)).

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.21.3 How the specification is organized

This section is non-normative.

The specification is organized into the following sections:

Section 2: An introduction to CSS2CSS 2.1

The introduction includes a brief tutorial on CSS2CSS 2.1 and a discussion of design principles behind CSS2.CSS 2.1.

Sections 3 - 20: CSS218: CSS 2.1 reference manual.

The bulk of the reference manual consists of the CSS2CSS 2.1 language reference. This reference defines what may go into a CSS2CSS 2.1 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 aural properties (non-normative), a sample style sheet for HTML 4.04, changes from CSS1 , implementation and performance notesCSS2, the grammar of CSS2CSS 2.1, a list of normative and informative references, and threetwo indexes: one for properties , one for descriptors ,and one general index.

1.31.4 Conventions

1.3.11.4.1 Document language elements and attributes

• CSS property, descriptor,property and pseudo-class names are delimited by single quotes.
• CSS values are delimited by single quotes.
• Document language element names are in uppercase letters. Document languageattribute names are in lowercase letters and delimited by double quotes.

1.3.21.4.2 CSS property definitions

Each CSS property definition begins with a summary of key information that resembles the following:

1.4.2.1 Value

This part specifies the set of valid values for the property.property whose name is 'property-name'. A property value can have one or more components. Component value types may beare designated in several ways:

1. keyword values (e.g., auto, disc, etc.)
2. 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.
3. 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.
4. 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>
Initial This part specifiesValue: inset? && [ <length>{2,4} && <color>? ]

Component values are specified in terms of tokens, as described in Appendix G.2. As the property's initial value. Ifgrammar allows spaces between tokens in the components of the expr production, spaces may appear between tokens in property is inherited, this isvalues.

Note: In many cases, spaces will in fact be required between tokens in order to distinguish them from each other. For example, the value that'1em2em' would be parsed as a single DIMEN token with the number '1' and the identifier 'em2em', which is givenan invalid unit. In this case, a space would be required before the '2' to get this parsed as the root element oftwo lengths '1em' and '2em'.

1.4.2.2 Initial

This part specifies the document tree .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.

1.4.2.3 Applies to

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, 'white-space'the 'clear' property only affects block-level elements.

1.4.2.4 Inherited

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.

1.4.2.5 Percentage 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 asin its values.

1.4.2.6 Media groups

This part indicates the media groups to which the property applies. The conformance conditions state that user agents must support this property if they support rendering to the media types included in theseInformation about media groups . 1.3.3is non-normative.

1.4.2.7 Computed value

This part describes the computed value for the property. See the section on computed values for how this definition is used.

1.4.3 Shorthand properties

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).

h1 { 
  font-weight: bold; 
  font-size: 12pt;
  line-height: 14pt; 
  font-family: Helvetica; 
  font-variant: normal;
  font-style: normal;
 font-stretch: normal; font-size-adjust: none}

h1 { font: bold 12pt/14pt Helvetica }

1.3.41.4.4 Notes and examples

All examples that illustrate illegal usage are clearly marked as "ILLEGAL EXAMPLE".

AllHTML examples conformlacking DOCTYPE declarations are SGML Text Entities conforming to the HTML 4.04.01 Strict DTD (defined[HTML4]. Other HTML examples conform to the DTDs given in [HTML40] ) unless otherwise indicated by a document type declaration.the examples.

All notes are informative only.

Examples and notes are marked within the source HTML for the specification and CSS1CSS user agents will render them specially.

1.3.51.4.5 Images and long descriptions

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]" to the right ofafter the image.

Images and long descriptions are informative only.

1.41.5 Acknowledgments

This specificationsection is non-normative.

CSS 2.1 is based on CSS2. See the productacknowledgments section of CSS2 for the W3C Working Group on Cascading Style Sheets and Formatting Properties. In additionpeople that contributed to CSS2.

We would like to thank the editors of this specification,following people who, through their input and feedback on the memberswww-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 are: Brad Chase (Bitstream), Chris Wilson (Microsoft), Daniel Glazman (Electricité de France), Dave Raggett (W3C/HP), Ed Tecot (Microsoft), Jared Sorensen (Novell), Lauren Wood (SoftQuad), Laurie Anna Kaplan (Microsoft), Mike Wexler (Adobe), Murray Maloney (Grif), Powell Smith (IBM), Robert Stevahn (HP), Steve Byrne (JavaSoft), Steven Pemberton (CWI), Thom Phillabaum (Netscape), Douglas Rand (Silicon Graphics), Robert Pernett (Lotus), Dwayne Dicks (SoftQuad), and Sho Kuwamoto (Macromedia).Editors. We would also like to thank them for their continued efforts. A numberGary Schnabl, Glenn Adams and Susan Lesch who helped proofread earlier versions of invited expertsthis document.

In addition, we would like to the Working Group have contributed: George Kersher, Glenn Rippel (Bitstream), Jeff Veen (HotWired), Markku T. Hakkinen (The Productivity Works), Martin Dürst (W3C, formerly Universität Zürich), Roy Platon (RAL), Todd Fahrner (Verso), Tim Boland (NIST), Eric Meyer (Case Western Reserve University), and Vincent Quint (W3C). The section on Web Fonts was strongly shaped by Brad Chase (Bitstream) David Meltzer (Microsoft Typography)extend special thanks to Elika J. Etemad, Ada Chan and Steve Zilles (Adobe). The following peopleBoris Zbarsky who have alsocontributed in various wayssignificant time to CSS 2.1, and to Kimberly Blessing for help with the section pertainingediting.

Many thanks also to fonts: Alex Beamon (Apple), Ashok Saxena (Adobe), Ben Bauermeister (HP), Dave Raggett (W3C/HP), David Opstad (Apple), David Goldsmith (Apple), Ed Tecot (Microsoft), Erik van Blokland (LettError), François Yergeau (Alis), Gavin Nicol (Inso), Herbert van Zijl (Elsevier), Liam Quin, Misha Wolf (Reuters), Paul Haeberli (SGI), andthe late Phil Karlton (Netscape).following people for their help with the section on Paged Media was in large parts authored bytest suite: Robert Stevahn (HP) and Stephen Waters (Microsoft).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 Stevahn (HP), Scott Furman (Netscape),O'Callahan, Simon Montagu, Tom Clancy, Vasil Dinkov, … and Scott Isaacs (Microsoft) were keyall the contributors to CSS Positioning. Mike Wexler (Adobe) was the editor ofthe interimCSS1 test suite.

Working draft, which described many of the new features of CSS2. T.V. Raman (Adobe) made pivotal contributions towards Aural Cascading Style Sheets (ACSS) andGroup members active during the concepts of aural presentation based on his work on AsTeR (Audio System For Technical Readings). He contributed an initial draftdevelopment of the ACSS specification that shaped the current specification. Values for aural properties in the HTML 4.0 sample style sheet are of his devising; he currently uses them on a daily basis on his audio desktop in conjunction with Emacspeak and the Emacs W3 browser (authored by William Perry, who also implemented the aural extensions on the W3 side of the fence). Todd Fahrner (Verso) researched contemporary and historical browsers to develop the sample style sheet in the appendix. Thanks to Jan Kärrman, author of html2ps for helping so much in creating the PostScript version of the specification. Through electronic and physical encounters, the following people have contributed to the development of CSS2: Alan Borning, Robert Cailliau, Liz Castro, James Clark, Dan Connolly, Donna Converse, Daniel Dardailler, Al Gilman, Daniel Greene, Scott Isaacs, Geir Ivarsøy, Vincent Mallet, Kim Marriott, Brian Michalowski, Lou Montulli, Henrik Frystyk Nielsen, Jacob Nielsen, Eva von Pepel, William Perry, David Siegel, Peter Stuckey, and Jason White. The discussions on www-style@w3.org have been influential in many key issues for CSS. Especially, we would like to thank Bjorn Backlund, Todd Fahrner, Lars Marius Garshol, Sue Jordan, Ian Hickson, Susan Lesch, Andrew Marshall, MegaZone, Eric Meyer, Russell O'Connor, David Perrell, Liam Quinn, Jon Seymour, Neil St. Laurent, Taylor, Brian Wilson, and Chris Wilson for their participation. Many thanks to the Web Accessibility Initiative Protocols and Formats Technical Review Working Group (WAI PF) for helping to improve the accessibility of CSS2. Many thanks to Philippe Le Hégaret, whose CSS validator helped ensure correct examples and a sensible grammar. Special thanks to Arnaud Le Hors, whose engineering contributions madethis document work. Adam Costello improved this specification by performing a detailed review. Lastly, thanks to Tim Berners-Lee without whom none of this would have been possible. 1.5 Copyright Notice Copyright © 1997 World Wide Web Consortiumspecification: César Acebal (Universidad de Oviedo), Tab Atkins Jr. ( Massachusetts Institute of TechnologyGoogle, Inc.), Institut National de Recherche en Informatique et en AutomatiqueL. David Baron (Mozilla Foundation), Keio University ). All Rights Reserved. Documents on the W3C site are provided by the copyright holders under the following license. By obtaining, using and/or copying this document, or the W3C document from which this statement is linked, you agree that you have read, understood, and will comply with the following terms and conditions: Permission to use, copy, and distribute the contents of this document, or theBert Bos (W3C/ERCIM), Tantek Çelik (W3C document from which this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use: A link or URI to the originalInvited Experts), Cathy Chan (Nokia), Giorgi Chavchanidze (Opera Software), John Daggett (Mozilla Foundation), Beth Dakin (Apple, Inc.), Arron Eicholz (Microsoft Corp.), Elika J. Etemad (W3C document. The pre-existing copyright notice of the original author, if it doesn't exist, a notice of the form: "Copyright © World Wide Web ConsortiumInvited Experts), Simon Fraser ( Massachusetts Institute of TechnologyApple, Inc.), Institut National de Recherche en Informatique et en AutomatiqueSylvain Galineau (Microsoft Corp.), Keio University ). All Rights Reserved." If it existsDaniel Glazman (Disruptive Innovations), the STATUS of theMolly Holzschlag (Opera Software), David Hyatt (Apple, Inc.), Richard Ishida (W3C/ERCIM), John Jansen (Microsoft Corp.), Brad Kemper (W3C document. When space permits, inclusion of the full text of this NOTICE should be provided. In addition, credit shall be attributed to the copyright holders for any software, documents, or other items or products that you create pursuant to the implementation of the contents of this document, or any portion thereof. No right to create modifications or derivatives is granted pursuant to this license. THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF. The nameInvited 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 trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.Paul Nelson (Microsoft Corp.).