Re: vendor prefixes considered harmful

On 3/3/10 4:14 AM, Daniel Glazman wrote:
> I find rather hilarious - and a shame at the same time - that HTML5
> elements and attributes are implemented as is w/o vendor prefix even
> if the document is only a WD

I would implement HTML5 elements with prefixes in some cases if HTML had 
fallback rules like CSS does.

And we (Gecko) have in fact implemented some draft DOM properties with a 
Moz prefix.  The problem there is that DOM fallback is even more of a 
pain on authors than CSS fallback...

That said, the HTML thing also causes problems; things like @autobuffer 
having to switch to a different name altogether, for example, because 
the existing name was implemented and the spec was changing drastically.

If the CSS WG wants to rename its properties any time after they are 
implemented when they make an incompatible change to the property, then 
I can see more of a case for dropping vendor prefixes.

That said, I am also OK with dropping vendor prefixes on particular 
properties that are known to be stable even if the spec they're in is 
not in CR yet.  The problem is knowing what's stable.  In the case of 
HTML5, there's a pretty simple resolution procedure for this: asking Ian 
gives a good first-order approximation.  Is there a CSS equivalent?

Perhaps parts of the spec should be annotated with per-section stability 
indicators, similar to how HTML5 operates?

 > An idea could be to let the WG
> decide when a given property can avoid vendor prefixes instead of
> enforcing the CR status for the whole spec.

Right.  I would be fine with that, per above.

-Boris

Received on Wednesday, 3 March 2010 16:54:48 UTC