Re: vendor prefixes considered harmful (was: vendor prefix properties diverging from official properties)

On Wed, Mar 3, 2010 at 3:14 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> Le 26/02/10 04:15, Sylvain Galineau a écrit :
>
>> This topic has come up before; see
>> http://lists.w3.org/Archives/Public/www-style/2009May/0105.html.
>
> 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 while we still require differenciated
> vendor prefixes for CSS until CR that are a huge burden on web authors.
> The last case is the placeholder attribute on html input fields,
> recently implemented in Gecko and already implemented long ago as is in
> Webkit.

You *can't* vendor-prefix HTML elements, because there's no way to
achieve fallback.  There've been discussion on ways to hack around
that which may work, but are rather ugly.

You can vendor-prefix attributes, as long as you define what order
they're to be resolved in, which doesn't exist currently.

That said, many new HTML5 things *should* be vendor-prefixed.  Apple
suffered some relatively significant pain when <canvas> changed
underneath them from their original experimental implementation.

> I understand that nothing in a spec is really frozen until the spec is
> released, but I don't see why there is a burden on CSS and not on other
> Web standards here. Again, HTML5 is only a WD and implementations don't
> use prefixes. I am officially requesting that a DRASTIC change of
> the way we manage CSS vendor prefixes (and in particular when we remove
> them) be discussed between browser vendors, for instance during the
> forthcoming CSS WG face-to-face meeting. 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.
>
> I would like the following to never happen again (example taken from a
> real stylesheet on the web) if the properties are already interoperable
> enough to avoid it:
>
>  -moz-border-radius: 5px;
>  -webkit-border-radius: 5px;
>  -o-border-radius: 5px;
>  -ms-border-radius: 5px;
>  border-radius: 5px;
>
> Counter-productivity at its best...

Here's the problem, though.  Say we had released the vendor prefix on
border-radius months ago.  What to do, then, when Hakon brings up that
he wants %s to be relative to the side they're specified on, not just
always the width?  With the current system we have the ability to say
pretty easily that yes, it's possible to make the change until this
particular cutoff (CR).  Without that, we'd be much more uncertain,
and would have to rely on *hoping* that not enough people are using
the property in the old way.

(That said, we still have to deal with that, when people write the
unprefixed version into their stylesheet early as well.  But it's much
lesser.)

~TJ

Received on Wednesday, 3 March 2010 15:50:16 UTC