- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Tue, 5 Jul 2005 11:58:44 +0100
- 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 UTC