W3C home > Mailing lists > Public > www-style@w3.org > July 2005

RE: Is There a Problem? (was: The Progress of CSS)

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 5 Jul 2005 11:58:44 +0100
Message-ID: <07FF6C60-FBCB-4ED3-B736-20BD69D500C6@S009>
To: "'Ian Hickson'" <ian@hixie.ch>
Cc: "'CSS specification-development list'" <www-style@w3.org>

Ian,

> > So for me, the real question is whether large, monolithic standards 
> > are the way to meet the needs of a web that changes by the day.
> 
> The CSS working group agrees, and indeed many years ago 
> decided to split CSS into multiple modules to aleviate this problem.

But the modules need to be able to move through the process independently of
each other. Also, a crucial part of my argument is that these smaller specs
wouldn't necessarily be maintained by the CSS WG; many small specs
maintained by the same people as before doesn't buy you anything in the
nimble stakes.


> 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.


> Also, at the end of the day, I'm not convinced that it helps 
> at all to have multiple small specs instead of one large 
> spec. You still have the same amount of spec, and thus the 
> same number of issues to deal with.

Yes, but at least they can move faster. 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.


> In fact, having multiple 
> smaller specs is IMHO worse since it confuses implementors, 
> authors and spec writers (as we have found with CSS3).

That's one of those statements it's difficult to agree or disagree with. I
would say that the specs are extremely difficult to get a handle on since
there is little rhyme or reason to the property naming. For example,
properties in the same 'space' don't share a common prefix.

But the thing I think is really missing is that we don't have a way of
'automatically' generating properties in a way that would save a lot of
work. For example, the SSML specification [1] could easily have produced a
parallel document that brought the CSS speech properties right up-to-date.
The CSS WG would of course have provided guidance as to how those properties
should be specified, even to the point of saying what naming convention
could be used (perhaps they must all have names that begin with 'ssml-', or
whatever). But I see no need for the CSS WG to 'own' the resulting documents
themselves.

(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.)

None of which is to criticise the commitment of you and the team, Ian. It's
simply to say that the process may have worked in the past, but it is far
too slow and cumbersome for today. Which means that if there is any
criticism to be levelled, it's to say that at the moment the CSS WG seems
adamant to ignore the problem and plough on with 'business as usual'.

Regards,

Mark

[1] http://www.w3.org/TR/speech-synthesis/

Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/
Received on Tuesday, 5 July 2005 10:59:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:39 GMT