Re: [css3-color] #rrggbbaa annotation, do we need to change the process?

Tab Atkins Jr. wrote:
> Guys, there's no need to argue.  We know that #rgba will be easy to
> spec and implement, as it's a trivial parsing change.  We also know
> that some authors (me included) have grown to greatly prefer the hex
> notation, and find it the most intuitive.
> 
> The only thing we don't know is if it's worth pulling Colors 3 out of
> Last Call to add a new feature, and letting it run through LC again
> afterwards.  I would personally rather let it bake as-is so we can put
> it to rest, and slab #rgba into Colors 4.  That won't delay its
> implementation any; it's mostly a political/process thing.

OK. The #rrggbbaa and #rgba syntax was discussed on this mailing list in
July 2005 and the current status seems to be that including this feature
would delay CSS3 too much.

How about this: let's put #rgba syntax to CSS4 for now. However, if
there's any other reason to take Colors 3 out of Last Call, add the
#rgba to CSS3 in addition to other changes in that case. I think that we
can agree that the implementation of this feature would be simple and
that the only reason not to include this feature is political.


I'm very disappointed that the W3C process is such slow.

As I see it, the only way to fix this issue for real is to change to W3C
process. Clearly the current process is working only at glacial page. It
seems the problem is the "when it's done" thinking in the current process.

Here's a suggestion for alternative process for a CSS module:

1) Decide a release cycle (see Ubuntu for example, one release every 6
months)
2) Decide freeze time before release date (e.g. 3 months)

During every release cycle new features can be specified and changed
(features can be added, removed and modified without restrictions)
during the time before the freeze. During the freeze, only
changes/tweaks required to specify details for interoperability /
practical implementation are allowed. Browser vendors are encouraged to
implement features immediately after the start of the freeze so that
possible corner cases can be defined and implemented during the freeze.
Perhaps even define that all changes to specification during the freeze
must be come from actual implementers of spec. At the end of release
cycle, all features of the spec that have at least two interoperable
implementations will be marked with "Recommended" status and all the
other features fall back to next release cycle.

This would make it less fatal to miss a release of the spec (because the
next release date would be already known and not too distant future) and
at least some progress would get Recommended every release date (hopefully).

The CSS specification has already been split in modules and each module
could have a different release cycle if needed.

-- 
Mikko