Re: Vendor Prefix solutions

Totally agree with Tab, here. Adding prefixed versions to RTM versions is 
needed *at some point*. When that should occur is questionnable, but it's 
sure that if you put a property on the web, you make its standardisation 
easier. The point is that you should do that to help webdesigners, not to 
force your implementation to win.

I hope that some global prefix can be used in the future, too.



-----Message d'origine----- 
From: Tab Atkins Jr.
Sent: Friday, February 10, 2012 7:17 PM
To: Matthew Wilcox
Cc: www-style@w3.org
Subject: Re: Vendor Prefix solutions

On Thu, Feb 9, 2012 at 1:48 PM, Matthew Wilcox <elvendil@gmail.com> wrote:
> Vendor prefixes are great. There's nothing wrong with them. The fault
> at the moment is developers that don't use them right.
>
> What can we do about it?
>
> Well, the main problem from our standpoint is that the test mechanism
> makes it easy to abuse. What about ditching any new vendor prefixes
> and going with something like
> http://felipe.wordpress.com/2012/02/02/a-proposal-to-drop-browser-vendor-prefixes/
>
> @-vendor-unlock {
>  box-shadow, transition, transform
> }
>
> That makes it harder to abuse but has it's own issues (incompatible
> syntax for experimental implementations).
>
> But, the main problem really is that vendors are shipping support for
> experimental features in production, public targeted, browsers. Can we
> not suggest vendors come to a mutual agreement to lock prefixes to
> development builds, and remove them from public shipping builds? This
> stops the uneducated developer being able to mis-use experimental
> features, whilst allowing knowledgable developers to experiment in
> safety. It also forces a progressive-enhancement mentality. And stops
> browser vendor competition 'point scoring' which is causing long-term
> harm.

Having experiments in public is useful - it gives us real feedback
that is hard to get if it's just in beta versions.  Importantly, it's
very unlikely that we can realistically ship a prefix in beta versions
of Chrome but not in public releases - our release engineers frown on
binary changes between beta and release that aren't motivated by
important bugfixing.  It's more realistic for us to only ship them on
dev builds or canary, but that drops the test population even more
drastically, making it not nearly as useful.  Finally, having
experiments in public allows for public pressure on popular things.

The failure mode is when we ignore that public pressure and drag our
feet in standardizing.

~TJ

Received on Friday, 10 February 2012 19:53:08 UTC