RE: vendor prefix properties diverging from official properties

> From: Brad Kemper [mailto:brad.kemper@gmail.com]


> [snip] I think that if you really want consistency across UAs on this 
> (as you seemed to say earlier), then we should say normatively in the 
> spec (or in a separate document) what we think the important elements 
> of a good corner gradation are, for any implementor who wants to go that route. 

No disagreement. Either we specify it in such a way that will ensure a good
level of testable interop. Or it's undefined until we are able to do so. I'm 
not interested in some waffly middle. (I don't mean to sound pejorative here;
when it comes to standards, I see more risk than upside in general recommendations 
and suggestions).

We also want and need each feature in the spec to be implemented in order to 
move it to REC. It's a W3C spec, not a statement of intent. 
The available evidence does not show a high level of priority from authors or 
implementors for this particular item. If the WG wants to remain in CR until 
this is both specified and compatibly implemented in 2+ browsers, I'm fine 
with that. 


> [More snipping] Not that I really expect those differences to be major, 
> but we did recently see that what seems obvious to designers as the right way to
> do a corner gradient is not as obvious to others, who thought for
> instance that it was OK to have the cone tip of the blend be somewhere
> in the middle of a line. 

Precisely why we should specify it beyond a mere recommendation+suggestion. I don't
mind healthy mailing list disagreements on the way this should look. I love that part
of the discussion. But I'm not so interested in getting that reaction from bits I've 
shipped. Let me be very clear here: if my corner gradient looks visibly different than 
Mozilla's, my implementation *will* be called wrong :) I'm more willing to risk that behind 
our vendor prefix. For stable CR+ properties, I'd rather wait for an agreement to emerge. 
Especially when the use-case seems pretty uncommon and of lower priority to authors than
other features that either remain or used to be in the spec.


> So I would rather keep the language...

I would rather not keep language that is hard to implement and test in an interoperable matter.
Again, this is a CR spec. I'm quite happy having the spec nail everything we know we must do. It
does a very good job for all the other features. I don't see any harm in leaving this out.

Received on Thursday, 25 February 2010 19:12:57 UTC