CSS FAQ and contribution guidelines

The W3C process for CSS

How does the working group work?

[Left for the working group itself to fill-in, or to remove it if deemed unneeded]

Is the mailing list English-only?

Unfortunately, yes. It would be nearly impossible to have a multi-lingual list, or a separate list for each language, without making things a lot slower and more complicated.

You don't need, however, to be a native speaker nor to have great English skills: if you are able to read and follow this FAQ, you most probably have enough English to participate on the development of CSS.

If your English is not very good, however, these tips might help your postings be better understood:

On the other hand, if you are good with English, remember that not everybody is. It's fine to request for clarifications (and sometimes definitely needed) or to make corrections; but keep in mind that non-native speakers will be devoting an extra effort just to put a message together in English. For example, don't assume a sarcastic intent if someone writes "style-shits" instead of "style-sheets" (unless the context is actually sarcastic, of course).

Also keep in mind that there will be people from all over the world reading your messages: if you decorate your post with too elaborate language, obscure or long-forgotten vocabulary, or region-specific terms, chances are high that your message will be unreadable for many people.

If you encounter a post with so poor English that it may be too hard to understand, but which contributes otherwise valuable content (an interesting proposal or use case, for example), it may be quite helpful to propose a reworked wording to the original poster: as soon as s/he confirms that your wording matches the original intent, other people on the list can rely on the reworked version.

How can non-members contribute to CSS?

There are many misconceptions about public participation in the CSS process. Too many people seem to believe that they are only allowed to humbly suggest features and let the powers-that-be take all the decissions and do all the work. That is, however, rather far from reality. Here is a summary of valuable ways in which anyone can contribute:

How do I send my feedback?

Public feedback and contributions to CSS work are done through the (archived) mailing list www-style@w3.org. You can find full instructions about the W3C mailing lists at http://www.w3.org/Mail/Request. To subscribe, send a mail with "subscribe" as the subject to www-style-request@w3.org.

When sending feedback to the list, indicate the module your feedback applies to within square brackets at the start of the subject. Some examples could be: "[css3-selectors] Proposal for a parent selector", "[css3-color] #rrggbbaa notation", or "[css3-values][css3-color] Circular dependency between the Values and Units and the Colors modules". The last example also shows how to tag feedback that applies to two or more modules.

When replying to a message you received through the mailing list, you will normally want to use the "Reply to all" function of your e-mail program or service, so the reply is sent to both the original sender and to the mailing list. If you use the typical "Reply" function, you will be replying only to the individual sender.

It is quite advisable to search within the list archives before posting a new idea. It's quite possible that your idea is not so new and it has been discussed before.

What is the best way to request new features?

Here are some guidelines that will help you in posting feature requests that can be easily understood and hence better developed by the working group. These are just guidelines: if you aren't sure about how to follow them, just try your best. The worst things that can happen are that your request can't be understood, or that your idea is not as good as you initially thought of. On the first case, someone may come over, rescue the idea, and rewrite it on a more understandable form (of course, you can be that someone, but it might be somebody else as well); on the second case, if there is some raw value to the idea, discussion on it will probably shave its issues and polish it into something better. Be ready to defend your idea with logical arguments if someone, for whatever reason, dislikes it; but also be open to the fact that it can most probably be improved upon: just like with a child, protect it but let it grow.

Use-cases: which problem does the feature solve?
Any new feature should be aimed to solve a specific problem or set of problems. A good description of the problems being addressed goes a long way to have them actually addressed by the standard. For this, you should focus on what is needed; not on how CSS might fulfill those needs. If you are used with these terms, a list of use-cases and their requirements is the ideal approach.
No-overlap rationale: is there no solution yet for the problem you are trying to solve?
On some cases, there may be existing features that complement, overlap, or somehow relate to your proposal. Try to identify them, and explain why they don't solve your problem; and/or why a new feature is better than extending an existing one.
What is your proposed solution?
Describe your solution, trying to cover all the relevant details. For example, for a new property, describe what values are accepted and what effect does each value have, the default value, whether it's inherited, etc. Of course, if you can provide "spec-ready" text (text than can be incorporated into the draft without major changes) you are more than welcome to do so, as that may easily quick up the review and (if accepted) incorporation into the draft processes; but if you can't you don't need to worry about it: just try to ensure that the details are there, so the members or other contributors can produce spec text from them.
How does your proposal solve the problem?
This is often overlooked, yet it's an important aspect of the proposal: if it doesn't solve the problem it was indended to solve, it's probably worthless. You should provide a rationale or a set of logical arguments to show that your proposal does solve the problem. If you described the problem in terms of use-cases and requirements, the ideal approach here is to show how your proposal addresses each use case and meets each relevant requirement.
(Optional) Test suites:
Test suite development is one of the bottlenecks in the CSS process so, if you are able to provide a complete test suite for your proposal, it may really speed things up. A test suite is a set of documents (such as stylesheets and reference renderings) that can be used to check whether an implementation is compliant with the spec. It may be advisable to wait for feedback on the proposal before starting development of a test-suite, since changes to the feature may render the tests useless.

What is the Recommendation Track?

The W3C Recommendation Track refers to the sequence of stages of maturity each specification goes through from the first draft until it becomes a World Wide Web Standard (also known as a W3C recommendation). It's fully and formally defined at http://www.w3.org/2003/06/Process-20030618/tr.html. For convenience, here is a summary of the different stages:

Working Draft (WD)
This is the stage where the bulk of new development takes place. The goal of publishing a WD is to gather feedback from the wider community. This includes you.
Last Call Working Draft (LC)
By publishing a LC, the working group makes a public statement that the draft is considered to be feature-complete and is intended to advance towards the next stages. At this point, features are frozen (ie: no new features will be added). The main goal of publishing a LC is to find issues (clashes between features, ambiguities on the text, editorial errors, etc) so they can be fixed before going on through the process.
Candidate Recommendation (CR)
Also known as Call for Implementation, the CR is published to signal potential implementors that the specification is ready for implementation. At this stage, feedback is primarily expected in the form of implementation experience. Other kinds of feedback will normally be deferred for the next iteration of the document (next level of the module in the case of CSS). A full test suite is required during this stage in order to check implementations' conformance.
Proposed Recommendation (PR)
Once two independent, complete, fully interoperable implementations have been released, the specification can advance to the PR stage. Advanciement to this stage is a statement from the working group that the specification is technically sound and implementable, thus sending it to the W3C's Advisory Committee for final endorsement.
Recommendation (Rec)
After the Committee aproves a PR, it becomes a Recommendation. A W3C Recommendation is a web standard.

Community participation takes place mostly during the WD an LC stages. During CR stage the focus is on implementation feedback, and upon reaching PR all that's left is bureaucracy. If you have a proposal for a module that's on LC or later stage, don't let that bring down your idea: it can be used for the next level of the module.


What is CSS?

CSS, or Cascading Style Sheets, is a styling language originally developed to allow separating content and structure from visual presentation on web documents. Over the years, however, it has grown over that original scope to become a general purpose styling mechanism usable for any kind of document structured as a tree; with a primary focus on the HTML and XML language families.

CSS provides a declarative syntax through which different fragments of the document conforming to a pattern (the selector) can be given a series of styling rules. Currently available features include, to name a few, precise control over font faces and font style; box margins, borders, and paddings; element positioning; table layout, etc.

What are CSS levels?

CSS levels is a numbering scheme ressembling (in appearance) version numbering. CSS levels are not versions, however. Each level is built on top of the lower ones, adding and improving upon it.

Level 1 was the first specification of CSS developed by the W3C, back in 1996, to solve the basic presentational needs of the web as the issues of presentational markup were becoming prominent. Level 2 was a wide expansion of the style-sheet concept, adding presentation features like positioning, shadows, and bidirectional text; but also features such as media types or aural style sheets. Due to several issues, a Revision of that level is being developed.

CSS Level 3 is the level where most current development efforts are commited, and it expands the language with a vast range of features and capabilities.

When will we be able to start using new features?

Thanks to modularization, each group of related features can advance at a different pace through the Recommendation Track, so features from each module can be used as soon as that module becomes stable and widely supported, regardless of other modules being on a less mature stage. For example, at the moment of writing this, most major browsers already support Selectors Level 3; while modules like Text Layout and Line Grid don't even have a public Working Draft yet.

Once a module reaches PR or Rec stage, you know that it's implemented by at least two independent browsers; which also means that competitors will work hard to catch up as soon as possible. This leaves a gap, however: old browsers tend to last a while before being completely replaced by newer versions; which means that it may take a while before support for a feature becomes commonplace.

In general, if your design supports fall back graciously enough (ie: if it still renders "ok" even in the total absence of the feature) you may start using a feature as soon as the module defining it enters CR stage: you won't get it applied on many browsers at the beginning, but support for it will grow and extend over time.

There are several sites on the Web dedicated to keep track of different browsers' support for CSS and other technologies. If you plan to use cutting-edge features, it may be a good idea to get familiar with these sites and keep checking them sporadically.

[Note for the WG: looks like http://www.quirksmode.org/compatibility.html is a great resource; but since it's external to the W3C and the WG there can be no guarantees of its accuracy and/or about it receiving timely updates. Would it be a good idea to list it here?]

When will CSS be finished?

Short answer: never.

Long answer: First of all, each module advances at a different pace, so a module can be "finished" while another is at an early stage. In addition, when the Level 3 for a module is finished, work on Level 4 can begin; after that is also finished Level 5 comes next, and so on. So CSS will keep maturing and evolving indefinitely.

If your question is "When will CSS 3 be finished?", then a rough estimate is within a few years or decades. It may sound crazy, but if we look back at CSS 2, it has taken for over a decade since it was written until it has been implemented by all major browsers.

CSS Modularization

What is CSS modularization?

CSS Modularization is the process of breaking CSS Level 3 into several separate specifications. This has the direct advantadge that each module advances through the Recommendation Track at its own pace, without having to wait for features in other modules to become more mature.

From that, an indirect advantadge arises: UAs can implement the some modules without waiting for the less mature ones. For example, at the moment of writting this there are many modules at a very early stage of development; but most major desktop browsers already implement Selectors Level 3 (for the one that doesn't implement it yet, Internet Explorer, it has already been announced that it will implement these features on the next version).

How many modules does CSS3 have?

On http://www.w3.org/Style/CSS/current-work you can see a list of the specifications the CSS Working Group is working on. A rough count yields 43 modules, plus some other documents that are not modules themselves.

Don't be daunted by the large ammount of documents: one of the advantadges of modularization is that you can focus only on those that interest you. For example, content authors, generally, won't need to know all the details defined on CSS Syntax Module Level 3, but the module needs to define the syntax down to the last detail so UAs parse CSS sheets the same way. In the aspect of contribution, if you have feedback specific to one module, it doesn't matter whether you are familiar or not with the others.

Which is the right module to propose feature X?

On many cases, the module for a new proposal is an obvious choice. There are some cases, however, that things may be less straightforward, and a bit of thought is required.

If you take the time to search through the archives before posting, it should be easy to get a glimpse of what kind of stuff goes to each module, and to figure out which module will be the best home for your proposal.

If your proposal seems to match for two or more modules, take a moment to review it: is it a single feature, or a set of related features? If there are multiple features, does it make sense to use them separately? In that case, consider spliting the idea into mulitple proposals, with a single feature (or a set of unseparable features) each; and most probably each proposal will fit within a single module.

On the other hand, if your proposal doesn't seem to fit into any module, ask yourself: does it fit within CSS at all? Keep in mind that CSS is about styling (formatting, layout, presentation, etc). If you still think CSS is the right place, then go ahead and drop it on the mailing list: the community will most probably manage to figure out the right place for it.

In summary: put a bit of thought on which module you send your proposal for; but don't let some confussion about the module boundaries prevent your idea from being heard.