The W3C’s CSS Working Group charter expires on 1 July 2008, so the group will be discussing its revised charter in March this year. Fantasai, an Invited Expert in the group, has put out a call for web professionals to help the working group prioritise its work:
The CSSWG plans to discuss its charter at our next face-to-face meeting in March. If groups like CSS3.info, the CSS Eleven, and the WaSP and/or individuals like Jeffrey Zeldman and Eric Meyer could organize a collectively-written list of priorities and submit it to us before then, we could take that into account when writing our charter for 2008+.
I’d like to use the comments below to collect your feedback so that fantasai can take it back to the working group. It’s possible that some (or all) will be subsequently imported into a wiki on css3.info for further public discussion, with full attribution of course.
If your comments are very long, require HTML or example screenshots, please post a link to an entry on your own website—the aim is to get a single place for the working group to look at.
The CSS working group’s charter
The charter defines and limits the scope of work the CSS working group is expected to pursue, its deliverables and a timetable. It also defines the logistics of how it operates, how often it meets, and whether it’s public or private.
There’s been a lot of debate recently about whether the current charter is adequate. The CSS Working Group read those, but in order to focus on the work of the group (rather than meta-issues like its constitution), I don’t want to re-open that discussion here; if you have something that hasn’t already been said about the constitution of the CSS working group, please comment on those discussions.
The charter contains a list of CSS3 modules and their relative priorities. Remember, this list is from the expiring charter, and indicates the intentions and priorities as of 1 July 2006. (You can see the current statuses in the current work.)
The working group seeks feedback on whether those priorities are correct. Please indicate which features are most important to you, with any explanation you can give to help the group understand the different priorities of various sectors of web professional work.
For example, I’m an accessibility wonk, and I work with public sector organisations, so my emphasis is (by priority and by talent) on the information rather than the aesthetics. So, I can live without the borders module, but I’m very interested in the advanced printing options specified in the Generated Content for Paged Media module so that the large consultation documents and reports that I publish can be more
user-friendly and I can avoid having to dual-publish information in print formats (e.g., Word documents or PDFs).
Your experience will certainly vary—so please tell the working group what you need, and why.
Do you have a new idea for CSS 3?
What do you think should be added to CSS? This is your chance to let the working group know what’s missing. Feel free to link to your own blog with mocked-up screenshots: whatever you need to get the point across.
Fantasai told me
What we really need is to understand what problem needs solving and some idea of how people would like it solved. If someone’s proposing a solution, we need to understand why they’re framing the solution that way—so if we need to flesh out details or design a different solution we can understand what capabilities are important.
… If we can understand what the author is really trying to do, then we can design a feature that makes that possible. If it’s just a list of disconnected features, we won’t be able to identify with the author’s goals and then it’s likely we’ll either misunderstand what they want or not find it compelling.
The definition of the problem is by far more important a suggested solution or syntax.
As an illustration, I propose a new pseudo-element which I called
::line-break. There may be lots of good reasons why this might be bad syntax, but I don’t care whether the syntax is adopted. I just want a solution to the problem I define—that of styling to differentiate between an author-coded line break and one that the browser has inserted (very important if you’re reading poetry or code—see my “What I want from CSS3″ blog entry).
I should point out that there is no guarantee that you’ll get what you want; both the CSSWG and the browser developers have limited resources, so can’t do everything. For example, many people would like parent selector, but this is repeatedly dismissed because it’s too processor-intensive and because it breaks incremental rendering (although whether these are legitimate objections is another discussion).
What we work on first is based also on how complicated something is, how much prior work we can leverage, and sometimes other concerns that aren’t as obvious to web designers, like interoperability, accessibility, and internationalization. We know we haven’t been doing very well prioritizing our work or getting web designer feedback, and we want to do better, but practical issues will always be a factor.
Whatever your interest in CSS, here’s a real chance to influence the development of the language. So let’s do it: tell them what you want – what you really really want.
- #1 On January 18th, 2008 2:52 am