- From: Orion Adrian <orion.adrian@gmail.com>
- Date: Tue, 5 Jul 2005 10:08:35 -0400
- To: www-style@w3.org
> > > However, we still have to maintain our existing specs. If people raise > > > issues on CSS2 (as they have been doing) then we're not going to > > > ignore them, as that would just mean CSS2 was useless as a > > > specification. > > > > I understand, and that is a problem. But it shouldn't hold up the > > future. > > Well, it doesn't hold it up by design. It's a resource problem. > > Maintaining existing specifications is a higher priority than making up > new stuff. This is as it should be -- indeed maintaining existing specs is > the most critical work any working group can do, since the issues raised > on those specs are raised because the work is being implemented and used; > by ignoring comments, one would be ensuring that interoperability of the > existing specs will be poor. Has anyone thought of maybe finding a better process. One that doesn't eat up so much of your time. I was in a business which spent thousands of man hours to complete each project. No one thought there was a better way. No one thought it could be automated in any way, because it was just too human-centric. Well the system was automated and what took thousands of hours now takes less than one. Never assume you've maximized your time. There is always a better way. > Unfortunately, if a working group has X units of worktime per week, and > dealing with maintaining existing specs takes X units of worktime per > week, there is no time left for new work. > > In the case of the CSSWG, maintaining CSS 2.1 takes all our resources. > (There are times where we get more issues raised per week than we can > actually resolve per week!) We often have no time left for CSS3. Despite > this, some members of the WG are spending some of their own time working > on CSS3 drafts anyway, beyond their official "20%" CSSWG time commitment. Actually I'm of the mind that the specs have to move forward even at the cost of the current ones. But then again I don't think you've maximized your time. > > To pick an example, it surely can't be right that the XForms spec is > > still waiting for a formal document that contains the xf:repeat > > pseudo-elements and the various Model Item Property pseudo-classes. They > > are not very complicated, and could easily have been produced on their > > own. > > What is holding up that draft going past CR and on to REC is simple: there > is no test suite. I'm sure the CSSWG would be quite happy to have someone > (e.g., you) come in and take section 4 of the CSS3 UI module and create an > independent CSS3 module out of it, and push that through CR -- but it > would get stuck at the same place it is stuck now, because there is no > test suite. > > Section 4 of CSS3 UI needs roughly 150 tests, and then two implementations > which pass all those tests, before it can get past CR. > > Nobody in the CSSWG has the time to write those tests at the moment. > Personally my time is spent dealing with the CSS2.1 test suite (464 tests > in our unpublished copy at the moment, 928 if you count the XHTML and HTML > versions separately) and the Selectors test suite (303 tests, 786 if you > count the XHTML, HTML, and XML variants separately). > > You are of course welcome to contribute tests to the test suite. It would > directly help in bringing the draft to REC. Is that pretty much it? Any other positions open? How about editor? ;P > > (Those writing other standards can add XPointer schemes, XPath > > functions, schema data types, XML namespaces, and so on, without > > consulting some other Working Group. Yet I can't add a simple styling > > property in anything less than three years.) > > I don't see how this is the case. The SVG group seems to be quite happily > adding CSS properties left right and centre (somewhat to the concern of > the CSS working group, actually! Not all the additions seemed to make > sense. I believe the CSS and SVG groups have now reached a compromise on > which properties make sense in CSS and which don't). > > There is nothing stopping a working group from working with the CSS > working group on adding features to CSS. What about non-working groups? I'm free to develop my own XML grammar, but I'm not free to develop my own styling properties. Orion Adrian
Received on Tuesday, 5 July 2005 14:08:38 UTC