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

First of all, thanks Tab for all the insight on the W3C process.
It wouldn't make too much sense to go over your reply point by point,
but there are some points I find worth clarifying and/or discussing,

On Wed, Apr 7, 2010 at 8:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Another bottleneck is the way specs are organized and advanced through
>> the recommendation track. How long has passed since work on CSS
>> Selectors Level 3 began until all major browsers implemented it?
>> (hint: while MS has announced that IE9 will implement that module,
>> this has yet to happen). In contrast, how fast are things like
>> <canvas> or <section> being deployed?
>
> <canvas> was created by Apple and put in Webkit before it ever
> appeared in HTML5.  <section> still isn't, I think, actually natively
> supported by anyone (it still acts like a default unknown element in
> FF, frex, and you have to manually set display:block on it).
Apologies for taking such a bad example. Please, forget the comments
about section.
Now, let's look at some details about <canvas>:
As of 2009-10-23, both gecko and webkit have nearly complete support
for <canvas> (according to the spec's annotations), and Opera has some
partial support. But still, HTML5 itself is on Working Draft stage.

In contrast, many CSS features can't be implemented in advance because
they don't yield too well to the vendor-prefix mechanism recommended
for "experimental" implementations; which means that even if a feature
seems to be stable, as long as the same module contains features that
aren't, implementers have to wait for the draft to become stable (LC
or CR) before working on the implementations.

>> Maybe it's time to learn from HTML5's quite successful process, and
>> incorporate some ideas of it into W3C's.
>
> Most of HTML5 still isn't implemented.
Even if things aren't fully implemented yet, many are partially
implemented. This denotes that implementation work has begun, which is
a visible and unambiguous commitment to implementation. For example,
in addition to <canvas>, there are already experimental
implementations on <video>, <audio>, and many other features.
That's possible only because, despite the HTML5 is still a WD, those
features are marked as stable. It'd be insane for implementers to
begin work on such features if they weren't marked as such, since they
couldn't rely on the feature being the same tomorrow as it is today.

> The things that are
> implemented are because there is significant demand there.  If CSS
> features aren't being implemented, it's because there isn't a similar
> level of demand for them.
Demand for a feature is a good *motivation* to implement it. But
knowing that it's supposed to be stable is *needed* before
implementation work can begin without the risk of the efforts being
pointlessly wasted.



>> Proposal #1: Facilitate participation on the W3C process.
I still think that making participation easier would be a good thing,
but after your reply I'm ready to throw away that proposal (there is
no need for changes on the process itself to facilitate
participation). You have brought in some interesting points, however.

> I'm in the middle of a major project that should make test-suite
> development substantially easier, more open, and more useful.  I'll
> have an alpha version out before winter.
That sounds quite interesting, please keep me updated about that ^^ It
seems that this should help addressing one of the primary bottlenecks.

>> - Make more clear and simple the requirements for joining the W3C work.
>
> They're perhaps not very clear, but they're at least simple.  It's
> just a matter of making yourself useful enough to get invited in.
Maybe it would be a good idea to make that clear (possibly in the FAQs?)

>> - Ensure that the ability of and individual to contribute on a task is
>> determine by the individual's suitability to the task, rather than by
>> political/business factors such as employment status and the like, to
>> the maximum possible and reasonable.
>
> This is largely limited by w3c process itself.  As long as the CSSWG
> is a w3c organization, we can't substantially change it.  If you're
> part of a large enough company, the company is required to become a
> w3c member and then nominate you.  If your company is small enough and
> not expected to be interested in joining the w3c (or you're
> self-employed), it's not necessary, but then the WG has to decide that
> you're useful enough to bring in.
Forget what I said. After reading your whole reply it seems obvious
that most, if not all, of the contributions I was thinking of for
"collaborators" can be done through the public mailing lists.

>
> I'm not sure that "lingering on LC" is a fundamentally bad thing.
No, it isn't. But "lingering on any stage for too much longer than
really needed" is.

> Yes, we want to push things to PR and then Rec, but in terms of
> stability, LC is effectively the end-point for new additions.  Once we
> hit LC we try to only pull it back when significant issues have been
> raised, not just to add something new.
>
> I don't see any problem with starting a new level of a module in WD if
> the previous one is in LC and only waiting for a test suite.
Does the WG share that opinion?
I remember sending in a proposal for Selectors that didn't receive
even a single reply. I later assumed it was due to selectors being
already "frozen", and didn't think too much about it. And I have seen
similar things happening sporadically.
Maybe I'm getting things wrong; but my perception is that the flow of
new proposals into future versions isn't as dynamic as it could be:
they get ignored or stapled into a wiki page, and apparently forgotten
until someone decides is time to work on them. Again, this is just my
perception, seeing things from the outside, and it could be completely
wrong.

>> On other cases, a desired feature can be well-known and even easily
>> implementable, but the editors might fail to find an appropriate
>> wording for it. It's not that unusual that a possible feature is easy
>> to imagine and even describe in the abstract; but it turns to be very
>> challenging to translate it to more formal language (a.k.a.
>> spec-quality text).
>
> Do you know of anything that is actually being held up for this
> reason?
Here, and now, I don't know of any specific case. HTML5's microdata
took quite long to be addressed, mostly because of an inability of the
semantic web community and the draft editor to properly understand
each other. I have also seen this on other contexts; and I'm now
wondering if my proposal (mentioned above) could have gone unnoticed
precisely because of this kind of communication issue.

> I think that, in general, translating something to 'formal
> language' is mostly a matter of actually figuring out what the details
> are.  Some things are indeed easy to describe in the abstract, but are
> incoherent or undesirable when you drill down to the precise details.
I'm afraid you're missing two subtle, but important, points here:
1) Discussion only happens in English, despite we are discussing about
the technologies for the *world wide* web. We should start from the
assumption that not everybody participating here will be native
English speakers (for example, my English is not native). Even when a
contributor understands the details and the intricacies of what they
are proposing, describing them in a foreign language can quite pose a
challenge.
2) There is no "sign at the door" telling contributors what kind of
details are most important to describe about a proposal. For you and
for me it may be obvious that use-cases and requirements are more
important than a tale about how someone come up with the idea they are
proposing; but it's not as obvious for everybody, especially for
newcomers.

In general, communication issues can easily hurt interesting proposals
and suggestions.

> Plus, the w3c is funded entirely through its member fees.  If it was
> easier to forgo paying the member fee, it would have less money to
> operate on.
My ideas were quite towards the opposite direction; not about allowing
employees of Members (or potential members) to participate as
individuals, but about individuals being able (more easily) to
participate without needing to be employed.
You have already pointed out that this can be perfectly achieved
through participation on the lists; so I just wanted to clarify things
(hey, that seems to be another example of a "communication issue",
even if a minor one).

>> This approach shouldn't prevent Editors and other WG members from
>> interacting directly with the wider community; but should prevent them
>> to have to deal directly with each message sent by each member, which
>> is an insane amount of work for so few people.
>
> That's what we do right now, and it doesn't seem very insane at all.
Does each of you really go through *all* messages posted on the list?
In that case, you definitely have my admiration. Yet still, it must be
a slowing down factor. Having some people go through the raw comments
to filter out irrelevant details, consolidate duplicate or overlapping
proposals, and posting the resulting summaries would give the group
more time to spend on the technical aspects of the specs (at least in
theory).
Again, you have highlighted that this kind of collaboration can be
provided as a "participant", so no need to go further into that.

> We don't rate individual features in terms of stability, but otherwise
> you exactly described current process in the CSSWG.
At the risk of repeating myself, I'll mention that marking individual
features would allow implementers to start working on each feature as
soon as it becomes stable, rather than having to wait for the whole
module to become stable. This is more prominent on the cases where
vendor-prefixing doesn't work well.


> The entire point of modularizing CSS *was* to allow things like
> Selectors 4 reaching CR while other "level 3" specs are still in WD.
That's exactly what I thought. However, it doesn't change the fact
that some people will choke at the idea. CSS teachers come to mind :P

> there are several features planned to drop into a
> Selectors 4 draft as soon as someone gets around to writing it,
Please let me know when work on that begins; I have a proposal to
"re-submit" (hopefully better described than on my first attempt) and
some ideas brewing in my brain.


Again, thanks for your elaborate reply and for the insight on the
process you provided. This has also given me some ideas on how to make
myself more useful on these lists ^^

Regards,
Eduard Pascual

Received on Wednesday, 7 April 2010 22:33:33 UTC