CSS vendor prefixes in Opera 12.50 snapshots

By Bruce Lawsonbrucelawson. Friday, August 10, 2012 12:16:59 PM

, , ,

Vendor prefixes have been useful, but they have arguably caused as many problems as they've solved, both in CSS and DOM APIs. So, in the run up to Opera 12.50, we're removing as many -o- prefixes from stable CSS properties as we can.

Last week, Patrick mentioned the removal of prefixes from Transitions, Animations and Transforms.

In today's Opera 12.50 snapshot, we're removing prefixes from CSS Gradients. The latest CSS Gradients syntax is supported in Opera with no prefix. Using an -o- will no longer work, so if your CSS still has some -o-linear-gradient hanging around, you should start to include the unprefixed version as well.

While it's encouraging to see that Opera, Firefox and even Internet Explorer 10 are accelerating the move towards unprefixing stable CSS properties, it's not all roses. The elephant in the room is of course the WebKit family of browsers, which continue to support the -webkit- prefixed stuff even in parallel with the unprefixed variants. This means that "Web developers" who only test in (or care about) WebKit have no incentive to move to unprefixed CSS, and their sites will look broken in non-WebKit browsers.

Admittedly, the history of linear-gradient has been very tumultuous, with a series of incompatible syntaxes being implemented at one time or another. Although we'd love to just support the new unprefixed standard, our testing has shown that there are many sites that use an older syntax, but do so with only a -webkit- prefix. In order to ensure Opera users don't receive a worse experience, we've included support for this older syntax when it's -webkit- prefixed. So, in Opera 12.50, the legacy syntax is supported:

background: -webkit-linear-gradient(top, white, black);

whereas the equivalent, newest syntax is supported without any prefixes:

background: linear-gradient(to bottom, white, black);

For reasons of site compatibility and interoperability, this Opera 12.50 snapshot also introduces aliasing for -webkit-background-size, as this particular property is heavily used on Japanese mobile sites. This brings the list of our aliased CSS properties to:

  • -webkit-background-size
  • -webkit-box-shadow
  • -webkit-transform
  • -webkit-transform-origin
  • -webkit-border-radius
  • -webkit-border-top-left-radius
  • -webkit-border-top-right-radius
  • -webkit-border-bottom-left-radius
  • -webkit-border-bottom-right-radius
  • -webkit-transition
  • -webkit-transition-delay
  • -webkit-transition-duration
  • -webkit-transition-property
  • -webkit-transition-timing-function

Therefore, if (for some reason) you're sending a different value to Opera than to webkit browsers, put the -o- prefixed rule after the -webkit- prefix, so the Opera one "wins" in the cascade.

You can find more information about this in our earlier article on the Opera Mobile Emulator build with experimental WebKit prefix support.

A hot Opera 12.50 summer-time snapshotSXSW 2013 Proposals

Comments

Thiemo Friday, August 10, 2012 3:00:19 PM

Let me make this short: It's not "error recovery" if a prefixed property that is not targeted to the Presto rendering engine overrides an unprefixed property. See my longer post there: http://my.opera.com/community/forums/topic.dml?id=1482302

Tenno Seremeltenno-seremel Friday, August 10, 2012 3:41:06 PM

For reasons of site compatibility and interoperability, this Opera 12.50 snapshot also introduces aliasing for -webkit-


I feel more pain for web devs in the future alien

ΩJr.OmegaJunior Friday, August 10, 2012 4:16:06 PM

Thiemo: cascades are a bitch.

I think Opera should seek to recognise whether or not the author did in fact specify a rule for Opera's engine, and apply that if so, and only start translating -webkit-rules in case of absence of an -o- or generic rule.

Bruce Lawsonbrucelawson Friday, August 10, 2012 4:32:44 PM

Omega Junior

I thought so too, and lobbied for -o- or generic rule to be magic, and always trump a -webkit- rule. But while, in theory, there is no cascade implied for vendor prefixes (because they're mutually exclusive) people expect the cascade, and understand how it works. So, as long as the unprefixed version is after the -webkit- version, that will take precedence.

metude Friday, August 10, 2012 5:29:57 PM

Why are you removing -o- support? What will happen to good developers, will they wasted their time?

sirnh1 Friday, August 10, 2012 5:51:27 PM

Question (just being curious), if one would have both the webkit prefixed and the
non-prefixed version, will the non prefixed always take priority over the prefixed one? Or does the one last in the css still take priority?

Joel Spadinspadija Friday, August 10, 2012 7:25:57 PM

@metude: if they were good developers, they would have added the unprefixed versions too, in which case things will still work and no time was wasted.

Jimtoyotabedzrock Friday, August 10, 2012 10:11:40 PM

I don't think box-shadow or border-radius are really needed with the webkit syntax. Most sites are fixed for those two.

@joel For gradients the syntax has been so debated the unprefixed styles will not work anywhere.

Patrick H. Laukepatrickhlauke Friday, August 10, 2012 10:41:04 PM

"Why are you removing -o- support?"

because that's the idea of vendor prefixes. they're supposed to be used to test stuff out. once the testing is successful and the CSS spec stabilises, they're supposed to be removed. Opera, Firefox and even IE do it. WebKit have publicly stated that they simply can't, because of "walled gardens" and because of all the legacy pages that are out on the web that rely on those experimental implementations. Which is fun, particularly when syntaxes change so dramatically as with the gradient ones.

"will the non prefixed always take priority over the prefixed one"

no, like all other browsers as well, it's purely a matter of the order in which the style rules are present/processed.

i.e. if your stylesheet has, as a simplest example

background: -webkit-linear-gradient(top, pink, yellow);
background: linear-gradient(to bottom, white, black);

you'll get a black/white gradient, while

background: linear-gradient(to bottom, white, black);
background: -webkit-linear-gradient(top, pink, yellow);

gets you a pink/yellow gradient.

Joel Spadinspadija Friday, August 10, 2012 11:42:57 PM

@Jim: the gradients syntax has stabilized, hence Opera's removal of the prefix. Other browsers should support unprefixed gradients soon if they don't already.

Swapnil RustagiSwapnil99pro Saturday, August 11, 2012 4:07:38 AM

Originally posted by patrickhlauke:

background: linear-gradient(to bottom, white, black);
background: -webkit-linear-gradient(top, pink, yellow);

gets you a pink/yellow gradient.

The question is WHY??? Why not the unprefixed one?

Or,

background: linear-gradient(to bottom, white, black);
background: -o-linear-gradient(to bottom, white, red);
background: -webkit-linear-gradient(top, pink, yellow);
why would it produce pink/yellow gradient. (OK, you guys unprefixed Gradients in this snapshot, but the previous one would read -o- prefix).

WHEN an unprefixed version OR an -o- prefixed version is already THERE, why not simply ignore webkit, irrelevant of their order.
Why take -webkit- into account at all, when an unprefixed version or an -o- prefixed version is already there? How does the order matter?

Michael A. Puls IIburnout426 Saturday, August 11, 2012 5:30:48 AM

Originally posted by Swapnil99pro:

background: linear-gradient(to bottom, white, black);
background: -webkit-linear-gradient(top, pink, yellow);



Think of it this way:

background: stuff
background: stuff

CSS says that the 2nd background property redefines (overrides) the first one. Doesn't matter what the value is of each as long as the value is a valid one. A supported prefixed value is a valid value.

Likewise, for prefixed property names, like:

foo:
-vendor-foo

, -vendor-foo is a redefinition of foo as long as its value is valid according to the UA.

In other words, the way browsers handle vendor prefixes is the way I'd expect them to. Opera supporting webkit prefixes makes them valid redefinitions in the cascade where they can override previous ones.

That's not to say that vendors couldn't support things a different way and force the spec to get changed. But, most authors know about the order and how they have to list the least important one first and the most important one (the unprefixed one) last. So, any problems are super easily avoided.

Swapnil RustagiSwapnil99pro Saturday, August 11, 2012 5:43:46 AM

Originally posted by burnout426:

Opera supporting webkit prefixes makes them valid redefinitions in the cascade where they can override previous ones.


OK agreed. But that is a case of what the (CSSWG?) originally defined - overriding the previous one. But is it really compulsory to follow it in "this" case? It's a special case.

ЫъГЬ Saturday, August 11, 2012 2:35:54 PM

Originally posted by metude:

Why are you removing -o- support? What will happen to good developers, will they wasted their time?


"good developers" don't use prefixes in the first place. And if you used vendor-prefixed property without prefix-less you're not "good developer" at all, actually this is the very source of the problem.

metude Saturday, August 11, 2012 5:28:10 PM

Originally posted by ЫъГЬ:

"good developers" don't use prefixes in the first place. And if you used vendor-prefixed property without prefix-less you're not "good developer" at all


I'm not developer at all for now. Just following trends and developers. smile

Originally posted by ЫъГЬ:

actually this is the very source of the problem.


Originally posted by spadija:

if they were good developers, they would have added the unprefixed versions too, in which case things will still work and no time was wasted.


Yep, I see now.

Binyamin7raivis Saturday, August 11, 2012 6:54:58 PM

Do not forget about repeating gradients too.

Michael A. Puls IIburnout426 Saturday, August 11, 2012 7:00:03 PM

Originally posted by Swapnil99pro:

But is it really compulsory to follow it in "this" case?

There's nothing explicit. So, vendors could change to something that makes more sense.

Thiemo Sunday, August 12, 2012 6:08:27 PM

Originally posted by ЫъГЬ:

And if you used vendor-prefixed property without prefix-less you're not "good developer" at all

Thats what I did for years. An unprefixed property plus a few prefixed properties if needed.

background: linear-gradient(green, black);
background: -o-linear-gradient(green, black);
background: -webkit-linear-gradient(red, black);
I don't want to discuss if this example makes sense in WebKit. The point is, it did made sense in Opera. It worked in previous versions of Opera but in Opera 12.50 this site will change. The background will change from green to red without anybody touching the site. And it will change again some day when Opera drops the -webkit- stuff. This example is not broken. It does not need to be fixed. The -webkit- stuff is not targeted to Opera and can never override a property that is targeted to Opera. You need to make the -webkit- garbage lower precedence.

Michael A. Puls IIburnout426 Sunday, August 12, 2012 9:11:08 PM

Originally posted by Thiemo:

I don't want to discuss if this example makes sense in WebKit.

I understand your point. But, that css is not a really good example. It's incorrect to put the non-prefixed version first. It doesn't matter if it used to work or not. Maintaining compatibility of sites that list the non-prefixed version first is not much of a concern. Also, serving red to webkit is not correct use of vendor prefixes in this case. The idea is to serve green in all of them. I still see your point though. But, it's a super-edge case that shouldn't be used in the first place.

Tenno Seremeltenno-seremel Sunday, August 12, 2012 9:17:59 PM

Unprefixed version of the property is recommended to be written after prefixed one, AFAIR.

Thiemo Tuesday, August 14, 2012 3:07:55 PM

Originally posted by burnout426:

It's incorrect to put the non-prefixed version first.

No. Why? This is how it's done in the real world for many reasons. Because people think the prefixed properties are supposed to be lower precedence. Because people think the web browsers read only one of these properties (like Opera does it when -o-border-radius was dropped, for example). Because validators are complaining about invalid properties and the developers moved them to the end to not break the valid ones. Because people think it does not matter. Whatever the reason is, it always worked as expected in Opera no matter how the properties were ordered.

border-radius: 1em;
-webkit-border-radius: 0;
This was never incorrect. But it will become incorrect in Opera 12.50 because of the change. And it will become incorrect again when Opera drops the -webkit- hack some day. I don't consider this a "super-edge case". I consider this a dangerous step backwards that can be very, very easily avoided. Making the -webkit- hack lower precedence will still fix all the badly developed Japanese mobile sites.

Originally posted by burnout426:

serving red to webkit is not correct use of vendor prefixes

Nobody cares. This is what developers do. They use a property that targets a specific rendering engine to target a specific rendering engine.

René-Gilles DeberdtNao Tuesday, August 14, 2012 5:27:34 PM

Is it normal that the new angles are going clockwise, while they used to go counter-clockwise? This definitely wasn't intuitive...

After taking some time testing, it seems to me that an angle can be converted between syntaxes by doing (90deg - angle). Is that the recommended way of doing it?

Also, are you aware that Firefox 16 still retains support for the prefixed version as well? Do they plan to drop it as well?

-Edit-

Actually, according to Lea Verou's PrefixFree and IE10's blog (http://blogs.msdn.com/b/ie/archive/2012/06/25/unprefixed-css3-gradients-in-ie10.aspx), it seems that the 'official' conversion method is abs(old_angle - 450) mod 360... I don't really see the difference in practice, except for abs() returning a positive number obviously... (but is 270deg really any better than -90deg?)

René-Gilles DeberdtNao Wednesday, August 15, 2012 9:18:48 AM

Okay, I did a quick test to see how an angle > 450° would behave on this... And as expected, it failed.
So, the best way to convert angles is (90 - angle), or if you insist on having only positive numbers, ((3690 - angle) % 360) should be okay, since it's unlikely anyone would provide an angle > 10 * 360°...

Odin Hørthe OmdalVelmont Wednesday, August 15, 2012 11:03:40 AM

I think you should list the -webkit-linear-background one in your last list as well. Now it seems like that is not in the code :-)

Write a comment

New comments have been disabled for this post.