Re: Vendor Prefix solutions

I completely agree that hiding beta features will slow down the
testing that's done with them. I am not convinced, however, that it's
such a bad thing given the problems misuse causes. What's worse, a
longer time to geta final spec out or a web full of franken-sites and
yet more developer confusion and vendor hacking to solve it?

I'm not convinced that there are technical reasons for vendors to not
silo features into beta/dev builds, beyond a general dislike of doing
it for internal reasons. I can't see how it's hard to toggle sections
of code on and off given a version number. Therefor the decision of
whether it is or isn't correct to do so is not likely to be a
technical reason but a process and politics reason. Internal reasons,
basically. Which, yes, are important and practical. But everyone has
to do a bit of give-and-take here if we're to fix this mess.

There are no ideal solutions because the world isn't ideal. There's
loads of ways this problem could have been avoided: developers coding
to standards properly, the W3C moving faster, better communication
between everyone at all levels. Realistically, there's not going to be
much improvement in those areas. A little, but not enough. We all know
it.

To my mind, we've tried the compromise that let's developers be lazy.
It's breaking the standards process and more importantly harming the
entire community. So, can we not try the other end of the compromise
spectrum?

This is about quality control of the environment we are in and the
site's we can create. Web developers as a whole do not provide
sufficient quality control. No amount of standards process will fix
the fundamental fact that the majority of developers do not code as we
would like them to. They need to be _unable_ to make such mistakes,
whilst allowing more knowledgable developers the same freedom to
experiment vendor-prefixes offer now.



On 10 February 2012 18:17, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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 18:42:10 UTC