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

On 4/8/10 8:51 AM, Mikko Rantalainen wrote:
> I understand that the time window for feedback would be much shorter but
>   I fail to see actual problems caused by this change. It's not like I'm
> proposing no time for feedback but instead only a couple months instead
> of years (in practice).

No, your proposal cuts the time to pretty much 0.

> Implementors are already independently selecting which features they
> will even try to implement. A spec that describes some nice to have
> feature that is not implemented anywhere does not matter. I think that
> if a feature is badly conceived, either the implementors will notice
> that even before trying to implement the said feature or they will try
> to implement the feature and hit the problem during the implementation.
> In the latter case, it would probably be the case regardless of longer
> Last Call phase.

I'm having the opposite concern: a feature that implementors propose 
that's badly conceived.  Your proposal has no way for anyone else to 
review such features.

> I honestly believe that Last Call could be dropped altogether. Just keep
> the requirement that there must be at least two independent
> interoperable implementations before a feature can reach Recommended status.

That's not acceptable, since it means that any two implementors can just 
make a feature Recommended in spite of what anyone else (including other 
implementors or other constituencies) wants.

>> Given you lack of a review period, this effectively allows implemeters
>> to implement whatever they want: just propose it the day before feature
>> freeze, and then no one else can suggest changes to it.
>
> They can already do that today.

As a matter of fact, they can't.  After they propose it, there's a 
review period for public comment.  That's the whole point.

> However, such tricks cannot be used to
> achieve the Recommended status unless another independent implementor
> decides to also implement that feature.

Sure, and we have examples of that right now where poorly-conceived and 
underdefined features (text-overflow:ellipsis, display:run-in) would 
have been Recommeded per your criteria today.

> If that happens, I believe that
> the feature is good enough (and specified with enough detail) to be
> Recommended.

I see nothing in your proposal that ensures the "specified with enough 
detail" aspect other than completeness of the test suite.  I also see no 
provisions for ensuring completeness of the test suite.

> I agree that this is a problem. For example, the HTML5 wouldn't be in
> the shape it's today if Ian Hickson weren't the editor.

Yep.

> The editor makes
> all the difference and the editor must have enough time to do his work.
> Hopefully somebody pays for that work, too.

That's nice if it happens, yes.  But not all specs are giant balls of 
twine that require a single editor, and smaller editing jobs can in fact 
be done on a semi-volunteer basis (at least as far as producing a first 
draft).
>
>> 2)  Lack of implementor time to implement all the things that people
>>      care to think up all at once.
>
> This is the most important part in my mind. My point is that
> implementors are already independantly deciding which parts they will
> implement.

Sure.

> I guess I'm suggesting more power to implementors on deciding which
> parts get Recommended

No, you're suggesting more power to early-adopter implementors on 
deciding exactly how the things that are "Recommeded" work and look. 
This biases toward fast implementation in a way that's as easy as 
possible in your particular codebase without worrying overmuch about the 
long-term health of the web.  I think we have quite a bit of bias in 
that direction already, and don't need more.

> It would be great if a feature couldn't receive Recommended status
> without a test suite testing every part of the feature. However, I
> understand that such test suite requires really much work.

If the test suite is not comprehensive then a reasonable review period 
is a must, no?

> If I have to choose between a feature that has been already implemented
> interoperable and a feature that has test suite and hopefully gets an
> implementation in the future, I will rather take the former.

How do you know it's "interoperable" without a test suite?

> Unfortunately, I don't have enough time (I don't get paid for that in my
> job).

As it happens, neither do I...  Nor do a number of other people that 
have contributed to the CSS specs and test suites.

-Boris

Received on Thursday, 8 April 2010 13:42:06 UTC