Re: vendor prefix properties diverging from official properties

On Feb 25, 2010, at 8:24 AM, Sylvain Galineau <sylvaing@microsoft.com>  
wrote:

> Given that this recommendation, as currently specified, may result  
> in different renderings or no support for this behavior at all on  
> some platforms, we will have divergences between implementations of  
> the prefixed property. I'm not sure why that's a better alternative  
> than using the prefixed version for its intended experimental purpose.

Not to throw fuel on the fire or anything, but...

But your preference is to leave it undefined in the spec about how  
colors should transition (or not) at a rounded corner, yes? So this  
means that an implementor may choose to have the colors gradating  
smoothly instead of changing abruptly, without the prefix, and still  
be in complience with the spec (just as MS, wonderfully, decided to  
make the dots in their dotted borders round instead of square). And  
they could do so in a way that is incompatible with your prefixed  
version (especially if all language about what we reccomend or suggest  
is removed), thus making your prefixed version seem less important  
than the "real" version out in the wild. 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. I think fantasai has  
done a good job already of saying what those points are (although I  
would also like to add where the point of the cone should be that the  
lines of color rotate around). Then we can influence the beauty of any  
corner transitions that are attempted without the prefix, and not have  
the weird situation of some vendors using the prefix and some not,  
where the ones that do use it have something different from their non- 
prefixed and also possibly different from what others are using as  
part of their standard CSS property.

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. So I would rather keep the language about how  
a corner should gradate colors if it is going to do so at all, while  
still allowing a vendor to opt out and have a sharp transition if,  
frex they are more concerned about memory footprint, library licences,  
and so on than they are about prettiness.

Received on Thursday, 25 February 2010 16:05:40 UTC