
Vendor Prefixes and Market Reality - cpeterso
http://www.otsukare.info/2015/07/02/vendor-prefixes-market
======
TazeTSchnitzel
This is why I applaud browser vendors who are ceasing to use prefixes, and
instead hiding experimental features behind flags.

------
matthewbauer
There are some good reasons for vendor prefixing. For instance, the 'user-
select' property is implemented differently between in each prefix, so CSS
styling should explicitly state which implementation it wants.

These properties need to be standardized. But, we're going to start running
into trouble if we start pushing to get rid of prefixes for unstandardized
properties.

[https://developer.mozilla.org/en-US/docs/Web/CSS/user-
select](https://developer.mozilla.org/en-US/docs/Web/CSS/user-select)

~~~
frivoal
There were some good reasons behind the intent for vendor prefixing, but it
was a flawed solution to a real problem. As vendor prefixed made it to
production builds, we ended up not with experimental properties that we could
still change willy nily, but with strangely named properties that we have to
support forever (since content depend on them working correctly), and without
even the benefit of being able to evolve the design of the unprefixed version
anyway we like, since "best practices" mean that css authors very often writen
the unprefixed property in their stylesheet along with the prefixed one for
future proofing.

What browsers are mostly doing (and the CSSWG is in the process of
formalizing) is that experimental features should be included in
nightly/preview/developer builds, but not in production builds (or be off by
default, to be turned on via user settings). That way we can still experiment,
but we don't use experiments in production, and avoid creating a legacy compat
problem on things that were not meant to be permanent.

