Re: Spec organizations and prioritization

>>> CSS 2.1 was a monolith and took years to complete.  For CSS 3, the
>>> team architected the work by describing 50 modules that could proceed
>>> to REC independently.  Isn't that the same as identifying a set of
>>> features that are being worked on simultaneously?  Doesn't that
>>> provide the lever required to move independently based on what is
>>> being implemented.
>>
>> CSS 2.0 was monolith and completed soon. CSS 3 has been going on as
>> long as CSS 2.1. If you actually look at the relative size of the
>> modules compared to CSS 2.1 I don't think we are progressing faster.
>> And quality-wise it leaves a lot to be desired too, because CSS is not
>> modular. The syntax and vocabulary are intertwined and there are
>> complex interdependencies between features. The way it is being
>> drafted now leaves a lot of open questions.

Sorry to jump late in the game. As I said earlier, my computer AND
backups suffered a major hardware failure and it took me hours to
be able to even read email again. So sorry, if I am saying things
that were already said, you contributed a lot in the last hours and
I have not recovered everything...

Saying CSS 2.1 is a monolith that took years to complete is just
a totally misleading view of the situation. Even a modularization
of CSS 2.1 would _not_ have helped. All areas of the spec were
touched, edited, modified, clarified somtimes drastically between
the beginning of our work on 2.1 and the final move to CR.
2.1 take long because the VENDORS in the CSS WG decided to make 2.1
the new common ground of web browsers, and then needed a level of
quality never reached before in layout specs. That was before the
new browser war...

If some CSS 3 modules can lead to the perception modularization
totally changes the speed a WG makes progress, that's again
misleading. Some progress faster because they're mostly independent
from others; some progress slower because they depend on other
modules; the others progress at same speed because the inherent
extreme complexity of the stuff we're dealing with can NOT be
resolved faster.

Modularization has good and bad sides, as I said recently in
an interview published by Molly. On the good side, we can focus
more and make progress things at different speeds. On the bad
side, and I would like you to think more about it, a very clear
side effect of modularization is specialization...

During the CSS 2 era, *all* the WG was involved in *all* aspects
of the spec. It's not the case any more. It's partly caused by
the complexity of our spec (some Text issues are understood by
3 ou 4 people only) but it's also because we all tend to focus
more on our strategic interests often expressed in the editorship
of one or two documents only.

And a very bad side effect of specialization is what happens when
a spec "owned" by 2 or 3 people only see these people leave the
Group.

Where Modularization helps a lot is about editorship. Getting
multiple editors is hard but when it's done, it's immensely
useful to confront different editing behaviours. It also helps
a lot getting rid of the confusion editor/decider. In the CSS
WG, editors have very, very little decision power. The ultimate
decision power does belong to the Group and only the Group; and
the co-chairs don't interfere here.

Where the CSS WG can be an example is the way it works: we value
consensus and we still value something that seems to have a rotten
smell these days : EXPERIENCE. Metrics and examples are not the
panacea, human experience accumulated over the years helps us
avoid traps, make things better.

Even if consensus can sometimes slow things down, it's immensely
useful, and a much better way of doing things than a heavy and
constraining process. With that respect, I think the process of
the HTML WG is insane because of its weight and hyper-formalism.
I often said it : W3C needs more pragmatism, not more formalism.

</Daniel>

Received on Thursday, 22 March 2012 23:11:46 UTC