
WebKit is moving away from prefixes - om2
https://webkit.org/blog/6131/updating-our-prefixing-policy/
======
timothya
It's nice to see WebKit adopt this approach too. Chrome and Firefox have
already had a policy against new CSS properties with vendor prefixes for over
three years, so with Safari onboard too now it's becoming easier to imagine a
future where web developers won't have to worry about writing code with
prefixes anymore. The only potential reason to use them will be compatibility
with older browser versions.

~~~
aiiane
Technically, web developers should never had to have worried about writing
code with prefixes - prefixed properties were never intended to be used for
production apps. :)

~~~
sdegutis
The problem is that "production" can have varying levels of tolerance to
cutting edge features depending on who the audience is. Sometimes you know all
your people are Chrome users, or IE10 users, or developers with the latest
browsers, etc.

~~~
digi_owl
And then it stays in production way way beyond the life time of your target
audience, and we have ourself a IE6 situation all over again...

~~~
ry_ry
We do, it's the IE9 situation!

I was looking at our browser metrics the other day and it's yet to drop below
the arbitrary 5% usage figure we use to fully deprecate browser support. We
are a public facing site, and not particularly niche.

It's hovering around there, but if a user is still clinging to ie9 it's highly
likely they don't have the ability or requirement to upgrade.

When ie9 legacy support drops my biggest headache will be ie10's squiffy
flexbox support.

~~~
WorldMaker
You should only really need to worry about IE10 if you have users on Windows
Server 2012 baseline, whom should have likely already upgraded to R2 or more
recent. Lifecycle support jumps to 11 on most OSes, yay!

[https://support.microsoft.com/en-
us/lifecycle#gp/Microsoft-I...](https://support.microsoft.com/en-
us/lifecycle#gp/Microsoft-Internet-Explorer)

~~~
ry_ry
If only :(

IE10 is a non-trivial portion of our desktop traffic, not to mention Trident's
hateful mobile incarnation, which still turns up from time to time.

------
gkya
I don't understand: If there is a spec that says, hey, this prefixed stuff
will get removed sooner or later, use the non prefixed variant along with the
prefixed so that it does not hurt you, and some people use only the prefixed
variants, why would the browser vendors be bothered to not break their code,
and keep stuff that needs to be removed, around?

~~~
univerio
Because the users would complain that Apple or Google broke all these websites
with the latest update.

Backwards compatibility is tricky.

~~~
toomanythings2
Backwards compatibility doesn't apply here because, by definition, prefixed
properties are supposed to go away and the intention of them is to go away.
Only dumb developers continue to use such things once a standard property is
available so it's their own fault if they don't do that.

~~~
cpeterso
Mozilla has reluctantly begun implementing some -webkit- prefixed APIs and CSS
properties (i.e. mapping the prefixed name to the standard unprefixed name) to
improve compatibility for mobile websites that assume all mobile browsers are
some version of WebKit (including Blink).

[https://bugzilla.mozilla.org/show_bug.cgi?id=1170774](https://bugzilla.mozilla.org/show_bug.cgi?id=1170774)

~~~
kalleboo
Aaaand we're back to the good old days of "Mozilla 3.0 (compatible; IE)"

~~~
kuschku
Firefox Mobile has many cases where it even uses Chrome's UA already.

------
Illniyar
The arguments sound good, and there is obviously a lot of frustration that led
to this, but:

Will this mean that new features will take even longer to come out? What about
features that aren't standardized, or in very early stages, heck, safari has
lots of css properties that aren't even close to being implemented (such as
-webkit-overflow-scrolling ).

Taking this route, either a browser can't implement something that isn't
standardized, or when it is standardized, it'll be incompatible with a future
standard (think flexbox and it's thousand implementations).

We could end up worse, to prevent sites from breaking, the standards body will
choose a different property name for things browsers implemented before
standardization, which means we'll get the same effect as vendor-prefixes but
without readily visible names.

~~~
notatoad
You can look at chrome's behaviour for the last couple of years to get an idea
of how this might play out. Basically, the big browser vendors _are_ the new
standards bodies, and the w3c/whatwg plays catch up with what the browsers are
implementing. If three browsers all agree to implement something, it gets
implemented without waiting to hear what a standards organization says, and
then it gets documented in a standard later on.

------
rattray
This struck me as a very concise, well-written description of a change. Good
description of what happened, why, and what it means for you.

------
demarq
Does this mean we can no longer use cutting edge tech in production?

for example border radius gained wide and reliable use in production while it
was still a prefix. And that was a good thing, every other way of implementing
border radius was a hacky mess.

------
dyscrete
Would this be a bad thing in the scenario one browser didn't implement the
property properly? The webkit implementation could work fine but look awful on
IE for example, which then you would simply not include it in IE.

~~~
treve
Not really, because the features need to be explicitly enabled. Nobody will
use these in production if it requires a user to change a setting in their
browser for it to work.

------
robocat
I wish they would move towards numbered "feature prefixes" e.g.

-feature555-flex-direction: column;

so that:

1\. a browser vendor can introduce a feature and have it used even as an
experiment

2\. another browser vendor can decide to implement the same draft spec

3\. if an incompatible change is made to the spec (flexbox!) then change the
feature number

4\. they should always be documented per feature (like RFC's).

~~~
RubyPinch
I don't think browser maintainers want to support -feature1-flex-direction all
the way though to -feature555-flex-direction, in fact I don't think they want
to support their failed experiments at all, after the experiment is done

this solution is trying to reduce the reliance on experimental features, not
increase it!

~~~
robocat
Obviously not.

The idea is that RFCs get written for each feature and are numbered.

They then get put out to see if they survive in the real world.

Unpopular features can be exterminated (falling back to whatever CSS is set up
for browsers that never had that feature).

Most importantly alpha features can be implemented by many browsers, or
removed, without confusion.

