

Opera confirms support for WebKit vendor prefixes - intranation
http://www.netmagazine.com/news/opera-confirms-webkit-prefix-usage-121923

======
paulirish
This is a good thing, and there is basically no way around it.

There is a varying degree of a WebKit monoculture on mobile. Without great
site compatibility, users will never successfully switch to a non-webkit
browser, but currently much of the great mobile content out there assumes
webkit prefixes and userAgent. So Opera, Mozilla, and MS basically need to
adopt some of the mobile webkit properties in order to get compatibility, in
order to get users. It's either that or advocacy wherein we try to get every
site ever to not publish with just WebKit prefixes. But in reality, this
advocacy effort has been underway already for over two years and we're still
in this bad situation.

Look at the chart linked to from [http://paulirish.com/2012/vendor-prefixes-
are-not-developer-...](http://paulirish.com/2012/vendor-prefixes-are-not-
developer-friendly/) When IE10 comes out (or it's complementary mobile
browser), less than 25% of all sites that use CSS transitions will have them
working in IE10.

Vendor prefixes are bad for us as developers and they're bad for browsers
because it leads to situations like these. We'd be in a better situation
without them.

BTW, one detail that wasn't really covered: I believe this change is localized
to Opera's mobile browsers. Their desktop story is, I think, unchanged.

(All the above is a personal opinion and not that of my employer, yadda yadda)

~~~
MatthewPhillips
Is vendor prefixing really worse than UA sniffing Paul? Your employer is one
of the worst offenders of the latter (not blaming you). Maps, for example,
falls back to a very primitive version in Firefox Mobile despite it being
perfectly capable of rendering the more advanced site.

My attitude is that if you don't want to test on anything other than Safari
Mobile and Android Browser then fine, don't test, but let the site degrade
gracefully or not on other browsers.

~~~
politician
> don't test, but let the site degrade gracefully

In practice, graceful degradation requires testing.

~~~
MatthewPhillips
I chose the wrong words, my meaning was that they should allow non-WebKit
browsers the chance to render the site and if they fail, they fail. Forwarding
the browser to another URL because you whitelist only a couple of UAs is a bad
bad idea.

------
numair
I know everyone talks about fragmentation concerns, and WebKit as the new IE6,
but does this argument really make any sense? Internet Explorer was a poorly
updated, closed source product that only worked on a single platform; WebKit
is open source, maintained by two separate companies (that are basically
locked in a cold war), and is available on all major platforms. If anything,
why isn't the notion of a single rendering engine to which we can all write a
GOOD thing? I know there's lots of idealism around standards, etc, but let's
get real here -- most people building a webpage simply want it to render
properly and universally, and would like to take advantage of cutting-edge
technologies. Agreeing on a single rendering engine seems to be the easiest
way of accomplishing this goal.

I've probably missed some killer feature of a multi-engine standards-based
ecosystem, but really -- is that the pace at which we want to move the web
forward?

~~~
MatthewPhillips
WebKit is not controlled by 2 companies and WebKit is not a single rendering
engine. WebKit is a single upstream project, the downstream browsers differ
from each other just as much as they differ from gecko or presto based
browsers.

~~~
alexchamberlain
Not sure that is fair; Google push updates to Webkit all the time, but
naturally they develop them on their fork.

~~~
MatthewPhillips
The other vendors choose when/if they merge Google's commits. The
grandparent's comment made WebKit sound like a single entity when it's
actually several competing companies with overlapping but also differing views
on things. They just happen to be working from a common code base.

~~~
alexchamberlain
Some of Google's engineers have Webkit priveleges. Webkit is a single
rendering engine - this should not be confused. It is used by several
browsers, who of course, use slightly different compilation configurations,
but I doubt that the web designer ever needs to concern themselves with that!

~~~
MatthewPhillips
No Alex, not all WebKit browsers have feature parity with each other.

~~~
alexchamberlain
Example please.

~~~
MatthewPhillips
Touch events - Android (any version) vs. iPhone (any version).

IndexedDB - Chrome Mobile has it (outdated version), Android and iPhone do
not.

Chrome will have Dart support at a later date, no other WebKit vendor is going
to implement it.

There are literally dozens, just go to caniuse.com and play around for a bit.

~~~
alexchamberlain
The first 2 are simply version issues, whilst the 3rd is nothing to do with
the rendering engine. Chrome uses V8, Safari does not.

------
mmahemoff
This is hopefully the moment where things have become so absurd (not a
criticism of Opera) that it's time for browsers and standards to tackle the
problem e.g. look at the proposed -beta flag.

([http://www.quirksmode.org/blog/archives/2012/02/the_vendor_p...](http://www.quirksmode.org/blog/archives/2012/02/the_vendor_pref.html))

~~~
talmand
If all the browsers use the same prefix then why use one at all?

~~~
wmf
Because the behavior of the beta feature may be different from the behavior of
the final version.

~~~
talmand
I would prefer an experimental feature not be implemented until at least the
syntax has been decided on. Prefixes were implemented so that browsers could
have experimental features in place and look where we are now. Adding in a
prefix, even a single one, doesn't change the fact that if present then people
will use it. If the syntax changes during the -beta prefix phase then lots of
stuff will be broken anyway. Can the browser companies at least get their crap
together to decide on a basic syntax and then expand on it if needed? Lately
they seem to be able to do that with some of the newer properties but we still
have prefixes.

~~~
mmahemoff
Vendor prefixes have turned out to be unsuccessful, but letting browsers move
ahead before standards is the best thing that could have happened for the web.
And the web apps we see today are evidence of it.

XHTML shows what happens when you try to agree on everything upfront. You
mention agreeing on a basic syntax. The browser developers generally do
discuss ideas for new features in basic terms before they release them, and
hopefully there's some vague sense of agreement between at least two browsers
before a feature goes alpha. But agreeing on anything more than that, instead
of just hammering out a working implementation, means developers end up with
APIs that are hard to use and don't address their users' needs.

~~~
talmand
Sure, I agree. I just feel that experimental features should be in beta or
nightly builds until they are ready for production use. The fact these
features were available in current releases means developers will start using
them whether they are really ready or not.

Like I said before, they are getting better at agreeing on basic syntax at
least. I would say don't make it available until the basics have been decided
on. If they are still arguing over details that require a prefix then it isn't
ready for release.

------
Osiris
In some ways, I understand the need the vendor prefixes, but they do seem to
be causing some fragmentation. I'm getting to the point on some CSS properties
that I just use the real CSS name (like border-radius) and don't use the
vendor prefixes at all since all the major browers that support radius use the
non-prefixed name.

If you all remember back in the IE6 dominated days, Opera was built to the web
standards but in order to make it a viable browser for pages that were only
tested in IE6, they had to try to emulate IE6 behavior in Quirks mode, and I'm
sure Mozilla had to do the same thing.

Hopefully this is a short-term thing unless standards are more finalized and
browser implementations become more consistent.

------
ergo14
What an idiotic move - So now they want to make webkit the next IE of
internet?

Standards are standards - period. I see ton of wrong with this approach, or...
mabye we should just ignore the w3C CSS Working group.

Vendor prefixes are fine - as long they are used as temporary solution, and no
one expects them to be the "default" way of doing things.

~~~
cpeterso
Opera is not making WebKit the new IE; web developers who only use -webkit CSS
prefixes have done that.

~~~
ergo14
By this move they are essentially legitimizing it. The only way to oppose
stupidity is to not agree to it.

~~~
politician
Exactly, couldn't Opera instead release an advisory tool which examines
stylesheets and points out how to convert -webkit- prefixes to a) standards or
b) -o- prefixes?

------
kogir
I've been telling the IE team to do this since IE 9. In reality, the purpose
of vendor prefixes is to keep two vendors from using the same name for two
distinctly different behaviors. The current prefix model does that.

After a prefixed extension gains market adoption, it serves to indicate which
implementation is authoritative. -webkit means you better do it the way webkit
does it.

Any browser that won't make use of the author's intent, when that intent is
unambiguous and easy to determine, is just shooting itself in the foot.

------
Tomis02
Unfortunately it can't be helped, adhering strictly to the standards loses
market share. Yesterday Internet Explorer, today webkit.

------
zalew
next move: spoof user-agent to appear as chrome. hello mozilla compatible
internet explorer

------
iandevlin
I think this is a bad idea as it's supporting bad, lazy developers who can't
be bothered to learn their craft correctly.

I've written a bit more about these "WODs" at
[http://www.iandevlin.com/blog/2012/04/css/on-vendor-
prefixes...](http://www.iandevlin.com/blog/2012/04/css/on-vendor-prefixes-and-
wods)

------
amadeus
Wonderful [sarcasm].

So now when I create something that requires a browser that actually has good
hardware acceleration, it will be a dastardly turd of a performer in Opera.

~~~
ernesth
No, it will continue to be fast on opera and firefox and to be a "dastardly
turd" on chrome and safari: only some selected -webkit- properties will be
translated by opera.

------
macco
Smart move.

