The members of the CSS&FP Working Group have decided to modularize the CSS specification. This modularization will help to clarify the relationships between the different parts of the specification, and reduce the size of the complete document. It will also allow us to build specific tests on a per module basis and will help implementors in deciding which portions of CSS to support. Furthermore, the modular nature of the specification will make it possible for individual modules to be updated as needed, thus allowing for a more flexible and timely evolution of the spcification as a whole.
This document lists all the modules to be contained in the future CSS3 specification.
This is an official introduction, issued by the CSS Working Group, which details the modularization of the CSS3 specification and the CSS test suite. This document should be considered to be informative, not normative. See the Style overview pages for more information on W3C's work on style sheets, including CSS.
This is a public W3C Working Draft for review by W3C members and other interested parties. As a draft document, it may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress."
A list of current W3C Recommendations and other technical documents including Working Drafts and Notes can be found at http://www.w3.org/TR.
Please send comments to the firstname.lastname@example.org mailing list (see how to subscribe) or to the editor.
As the popularity of CSS grows, so does interest in making additions to the specification. Rather than attempting to shove dozens of updates into a single monolithic specification, it will be much easier and more efficient to be able to update individual pieces of the specification. Modules will enable CSS to be updated in a more timely and precise fashion, thus allowing for a more flexible and timely evolution of the spcification as a whole.
For resource constrained devices, it may be impractical to support all of CSS. For example, an aural browser may be concerned only with aural styles, whereas a visual browser may care nothing for aural styles. In such cases, a user agent may implement a subset of CSS. Subsets of CSS are limited to combining selected CSS modules, and once a module has been chosen, all of its features must be supported.
All modules must contain a "Conformance: Requirements and Recommendations" section. Any module whose table row is backed with green is considered part of the "CSS Core." The listed deadlines (backed in red) represent the time at which a module should be ready for Working Draft publication. There are also columns which indicate a module's participation in each of three "profiles": HTML Basic, CSS3, and SVG. A module without any indicated module participation is at risk of being dropped from CSS3 before it reaches Proposed Recommendation status. A module without a listed editor is backed in yellow, and is in serious danger of being dropped.
|Syntax / grammar / etc.||X||X||-||-||-||-||-||-||-|
|Selectors||Tantek Çelik, Daniel Glazman||X||X||5 Oct 2000||-||-||-||-||-||-|
|Values, Units||Håkon Lie, Chris Lilley||X||X||-||-||-||-||-||-||-|
|Value assignment / cascade / inheritance||Håkon Lie||X||X||-||-||-||-||-||-||-|
|Box model / vertical||Bert Bos||X||X||-||-||-||-||-||-||-|
|Color / gamma / color profiles||Tantek Çelik, Chris Lilley||X||X||22 Jun 1999||-||-||-||-||-||-|
|Line box model||Eric Meyer||X||X||-||-||-||-||-||-||-|
|Text / bidi / vertical alignment||Chris Lilley, Michel Suignard||X||X||-||-||-||-||-||-||-|
|Font properties||Chris Lilley, Michel Suignard||X||X||-||-||-||-||-||-||-|
|Generated content / markers||Håkon Lie||X||-||-||-||-||-||-||-|
|Replaced content||Eric Meyer||X||-||-||-||-||-||-||-|
|Paged media||Steve Zilles||X||28 Sep 1999||-||-||-||-||-||-|
|User interface||Tantek Çelik||X||16 Sep 1999||16 Feb 2000||-||-||-||-||-|
|Columns||Håkon Lie||X||22 Jun 1999||-||-||-||-||-||-|
|BECSS||Michel Suignard||4 Aug 1999||-||-||-||-||-||-|
|Test Suite||Eric Meyer||X||-||-||-||-||-||-||-|
This provides a general overview of the specification's goals, as well as basic notes on how CSS works, acknowledgments, and so forth.
A way to attach arbitrary properties to a hierarchically structured document or other data structure, with the characteristic that it has built-in "forward-compatibility" (a.k.a. "extensibility").
Describes the selectors of CSS3. Selectors are used to select elements in an HTML or XML document, in order to attach (style) properties to them. The draft includes the selectors of CSS1 and CSS2 and extends them with new proposals that allow, for example, elements to be selected based on whether they contain a certain word, or whether they are the only element of their kind.
Things which are applied to values.
How properties interact, and the core of how CSS operates.
The box model describes the basics of the normal text flow, including how to "float" blocks of text or images, but excluding columns, tables, and other advanced layouts; i.e., it describes how text and other objects are strung into lines, and lines into blocks (paragraphs), and how those blocks are put below each other or side by side with the help of margins and borders. It treats both horizontal text and vertical writing modes.
This describes the process of placing an element someplace other than it would normally be in the normal flow of the document.
In general, basic color descriptions and color handling in multiple environments. The color profiles section describes how two properties can be attached to embedded images to specify their "color space," which is the information a renderer needs to paint the right color for each pixel. It should do away with the annoying problem that images, especially GIF and JPEG, but sometimes also PNG, look different on a Mac than on a PC, or other platforms.
A description of how element foregrounds and backgrounds are formatted.
A description of the line box model for inline elements, and the inline content of block elements.
Description of the handling of text in user agents.
Description of the handling of fonts in user agents.
A draft that contains proposals for new style properties for typographic traditions that have so far had little attention in CSS, such as vertical Japanese and Arabic. The CSS working group is cooperating with W3C's Internationalization working group on this.
A description of how content is generated and markers are displayed.
A module explaining how replaced content is handled and what qualifies as replaced content.
Extends the properties that CSS2 already had with new ones to control such things as running headers and footers, page numbers and print-style cross-references ("see page...").
Contains features for styling some interactive, dynamic aspects of Web pages: the look of form elements in their various states, more cursors and colors to describe GUIs (graphical user interfaces) that blend well with the user's desktop environment, and a proposal for "kiosk" mode.
Authors continue to clamor for "more control" over their pages, and the fonts used in presenting them. This module will attempt to provide a way to make fonts more Web-friendly.
An attempt to make styled content evben more accessible.
An attempt to link CSS and SMIL together.
The tables module contains the properties to lay out boxes in rows and columns. It allows a designer to assign roles like "table," "cell," "row," or "caption" to boxes and provides for various alignments and border styles.
Proposes new properties to create flexible column layouts.
A format that expresses shapes (lines, circles, splines, etc.) in an XML-based language and their style (fill color, stroke width, etc.) in CSS. This should make it easy to create text and graphics in the same style simply by using a single style sheet for both. SVG uses several existing CSS properties, but also introduces new ones that may or may not be useful for styling text. It will progress to Recommendation as a separate specification, but the (new) CSS properties are coordinated with the CSS working group.
An attempt to provide style properties for mathematical expressions. This will obviously be deeply linked to the MathML specification.
A proposal to use the CSS syntax and CSS's system of cascading and inheritance to attach "behavior" (rather than style) to elements. Behavior in this context refers to any dynamic changes to the style or the document in response to user events, such as clicks and key presses. The behaviors themselves are expressed as pieces of script, in languages such as ECMAscript.
Providing implementation guidelines, concrete examples, and user insight into implementation support, a test suite is crucial to the success of any specification. Although the Test Suite is a module in itself and has a module owner, individual module owners are responsible for assisting in the creation and review of tests for their specific module.
Some appendices will be split up to go with individual modules. These are:
For example, the changes between one version of a module and another should be tracked in an appendix to that module, not a single appendix to the entire specification. Similarly, there should be a property reference for each module. There may be a single cumulative reference for the entire specification, although this is not yet known with any certainty. Each module should also include an appendix listing any dependencies on other modules or specifications.
There will also be a few specification-wide appendices. There are projected to be:
All modules should conform to the format defined in the CSS3 editing rules [member-only link]. In addition to the definitions of properties and values, each module contains a list of dependencies on other modules or specifications, and also provides a list of changes from CSS2.