[Left for the working group itself to fill-in, or to remove it if deemed unneeded]
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.
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:
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.
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). These stages are:
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.
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.
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.
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?]
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 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).
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.
This is generally an intuitive decission, especially if you are not very familiar with the modules and their boundaries. You should't need to think too much about this. Also, if you make a mistake on this, it's very likely that someone will correct it, so there is no big deal. There are, however, some things to consider.
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.