[12.50] Opera is breaking the web by acting like WebKit

[12.50] Opera is breaking the web by acting like WebKit

I can't believe nobody haves a problem with Opera acting like WebKit, blaming us (the web developers) to be the bad guys and making the web worse in the long run.

Here is what currently happens:
http://www.netmagazine.com/news/opera-confirms-webkit-prefix-usage-121923

A few days later Opera answered a few questions but a lot of questions are simply ignored or claimed to be irrelevant:
http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/

Here is my example page why Opera is breaking the web:
http://maettig.com/code/css/why-opera-is-breaking-the-web.html

Here is a brief overview: Opera 12.50 will start reading CSS properties with the -webkit- prefix, for example "-webkit-border-radius". If your CSS looks like this:

border-radius: 3em;
-o-border-radius: 2em;
-webkit-border-radius: 1em;

you will see a different result in Opera 12.50 compared to all previous Opera versions. Opera 12.50 will basically ignore both the unprefixed and the -o- prefixed property and read the -webkit- property instead. This will break existing websites.

The solution is simple: Opera says this is all about "error recovery". So they need to implement this like an error recovery algorithm, reading -webkit- properties as a fallback if no unprefixed property and no -o- property was found. The -webkit- properties were never part of the CSS cascade in the Presto rendering engine and never should be. The -webkit- properties need to be lower precedence than the unprefixed and the -o- properties.

Do we need to flood the bug report wizard to make Opera understand what they do is unpredictable (because it changes the CSS cascade in an unexpected way) and simply confusing and will make our (the web developers) live more complicated?
https://bugs.opera.com/wizarddesktop/

Why won't they implement unprefixed properties? They just implemented border-radius, box-shadow, time for next properties! Prefixes are nonsense.

Yes, that's another suggestion I made. Instead of prefixing properties again that are currently not prefixed (in fact, -o-border-radius is not valid any more since Opera 10) they should drop all prefixes.

Originally posted by Thiemo:

reading -webkit- properties as a fallback if no unprefixed property and no -o- property was found.

+1000, very much better than what they are doing now.

Actually, they are simply doing the best for their users. They finally realized that you sometimes have to do bad things, that are wrong from a philosophical point of view, to make your users happy.

I'm sure Opera will remove -webkit-* support as soon as possible, but at the moment there are just too many sites that ONLY have -webkit- properties with no fallback whatsoever...

Originally posted by Hades32:

from a philosophical point of view

I'm not talking about philosophy (well, I do, but that's not the point). I'm talking about making the -webkit- properties a fallback instead of pretending they are uprefixed or similar to the -o- properties. They are not! I don't want anybody to "fix" my working CSS. If I write

border-radius: 1em;
-webkit-border-radius: 0;

I clearly want rounded corners in Opera. I don't want these corners going rectangular in Opera 12.50 and going round again in Opera 16.00 or 27.00 (who knows, they don't told us).

This example is so plain simple, I don't see why they don't understand this.

Originally posted by webcm:

Why won't they implement unprefixed properties? They just implemented border-radius, box-shadow, time for next properties! Prefixes are nonsense.

The CSS Working Group has decided collectively to unprefix a few set of properties. So these will be unprefixed for their support. It doesn't solve everything but that should help.

Just implement unprefixed properties. Microsoft uses -ms- prefix in IE 10 for Metro interface features but most CSS 3 properties don't have prefix!

If you keep properties unprefixed, developers will forget about prefixes too

Fortunately, there was no need for prefixing selectors:

img:-webkit-nth-of-type(2n+1)
-o-svg: -ms-filter(...)

Originally posted by Thiemo:

This example is so plain simple, I don't see why they don't understand this.

Opera understands what you are saying Thiemo. Still Opera can decide to choose another path. That said, what we are interested right now is to discover which sites break and how badly it breaks. So that will Opera to adjust and choose a path. Thiemo, if you identify very specific Web sites which exhibit the issue please do report them, that will be very useful.

Originally posted by Thiemo:

border-radius: 3em;
-o-border-radius: 2em;
-webkit-border-radius: 1em;

Ignoring for a moment whether Opera supports prefixes or not, it is never a good idea to have unprefixed rule before prefixed ones. You should want unprefixed rule to be the last one so that if browser supports both, it will use unprefixed. And this is not specific to any browser but this is CSS specificity that author should use to his advantage.

What you are asking for - that Opera would do some magic on top of CSS specificity - would actually be very confusing for authors.

Originally posted by karlcow:

please do report them

It's your job to care about other sites. I don't think I'm in charge to prove this. I don't know any site that's so stupid to rely only on the -webkit- properties (and if so, I would contact the webmaster like I did many times, e.g. with webs.com). But I know many sites that use CSS like in my examples above, unprefixed first, prefixed last.

It's so plain simple: Opera 12.50 will render an unknown number of existing sites different than all previous Opera versions did. What's the problem with downgrading the -webkit- properties to be a fallback? This will still fix every site that only have -webkit- properties. But in contrast to your current implementation it will not break other sites. It will be predictable and consistent. The -webkit- stuff will be the last link in the chain. Simple. You can even drop your -webkit- fallback whenever you want without breaking any site again.

Originally posted by d.i.z.:

it is never a good idea to have unprefixed rule before prefixed ones.

This is how CSS is written in the real world. Nobody cares and almost nobody is able to understand the difference. Validators are whining about "invalid" properties so we moved them to the end to not break the "valid" ones. Later we stopped using validators at all. Even I thought for a long time that every prefixed property must be dropped in the moment the unprefixed property is supported. This would be predictable. But browsers keep supporting them for years. This is the main cause of the problem. Opera is making this problem worse.

Originally posted by d.i.z.:

What you are asking for - that Opera would do some magic on top of CSS specificity - would actually be very confusing for authors.

No, it won't. Error recovery is not "magic". It's a simple rule. Opera is neither Safari nor Chrome. Opera was never supposed to read the -webkit- properties. It's horribly confusing if some random Opera version starts ignoring an unprefixed property (as shown in my examples above) and another random Opera version accepts the unprefixed property again.

if you identify very specific Web sites which exhibit the issue please do report them, that will be very useful.

If you don't want, no issue with that either.

Originally posted by d.i.z.:

Ignoring for a moment whether Opera supports prefixes or not, it is never a good idea to have unprefixed rule before prefixed ones.

Indeed. The whole idea of using vendor prefixes is that you always also include the unprefixed version and put it last. And, in the case where multiple vendor prefixed versions are supported, the author has to be aware of what order they want to put them in.

Originally posted by Thiemo:

Validators are whining about "invalid"

A css validator flagging the prefixed versions as invalid isn't a big deal. You know whether you need to use them or not.

border-radius: 3em;
-o-border-radius: 2em;
-webkit-border-radius: 1em;

Indeed, it might be cool if things in that situation were handled better. But, I'd avoid that situation.

i regret this decision.

I'm just afraid nobody will use the -o- prefix anymore in the future.
Developers will not type it, CSS Minifiers will strip it out, codebooks will not mention it anymore, because it's not needed.

That's a valuable loss of exposure for Opera

I always thought Opera had the best prefix, graphically it's between a smiley and a rocket, and it's short. For that reason it should be better if Apple drops -webkit- and implements -o- .

I think Apple misused it's market power on the mobile platform to push through experimental code to daily basis, on the other hand, W3C can't keep up with the speed of innovation, and what could Apple do else?

It's not Opera's problem only, I guess when IE 10 is entering the market, sites will update their code. Then they will add -ms- but not -o- .

I would prefer an extension solution, like a `top slide-in` message or a button that's warning you that the site has webkit prefixes but lacks -o- prefixes. When you push it will use the webkit-prefixes and repaint.
In that case testing in Opera will make users, owners and testers aware that developers have forgotten something: cross-browser support!

Opera: (You Gotta) Fight For Your Right (To -o-)

Originally posted by karlcow:

If you don't want, no issue with that either.

I'm sorry but I'm very confused by your posts (also your posts there). Who are you? How many websites did you developed? If you are an Opera PR guy you are not doing a good job. You never answered any question. You never told us why it's required to stick with the current hack but impossible to use another, more reliable and consistent hack (more consistent with all previous and future Opera versions, as explained above). All you do is asking for live examples. This is irrelevant for the suggestion. Maybe I'm unable to explain? Let me repeat: The suggested solution will fix the same websites without the risk of breaking any website that doesn't need to be fixed.

Originally posted by karlcow:

It doesn't solve everything

It does solve a lot of problems, like in the Webs.com example:

background: -webkit-linear-gradient(...);
background: linear-gradient(...);

Webs.com refused to support -o-linear-gradient. Dropping the -o- prefix will fix this problem.

Originally posted by Thiemo:

I can't believe nobody haves a problem with Opera acting like WebKit, blaming us (the web developers) to be the bad guys and making the web worse in the long

But you ARE to blame. You are a group of wholly incompetent fools who started using those prefixes as if they were stable, and you incompetent fools have now broken the web.

Shame on you for destroying the web, and shame on you for blaming Opera for your own incompetence.

Hi Thiemo,

Originally posted by Thiemo:

Who are you?

Did you follow my nickname? I'm not a PR person. I'm part of the Developer Relations Team. See http://my.opera.com/karlcow/about/

Originally posted by Thiemo:

How many websites did you developed?

More than I can remember. If you really want my pedigree. I have started in 1992. I have also been webmaster, web designer, part of W3C staff for 8 years and a technical director of a Web agency, etc. But all of that do not really matter. That's not the point of the discussion.

Originally posted by Thiemo:

You never answered any question.

I gave you answers. Not the ones you want to hear. That's different. The consistent answer that I gave you is that we are exploring different solutions and in the process of assessing their effects. The current implementations of the CSS hack are in experimental and beta builds of the browser. You gave feedback and gave a good example when it is breaking. What we want is to assess it on the Web on existing Web sites. Something of the order of the 1 million Alexa Web sites for example.

I have spent the last few days working on a script to survey on how the CSS rules are used. Does it break significantly or not?

Originally posted by Thiemo:

Maybe I'm unable to explain?

You are perfectly able to explain and we heard and understood what you are saying. What I keep repeating is thanks for the feedback, it is taken into consideration in the options and we will see what we do when/if we release a production version of the browser with (without) the prefix hack.

At the same time, there is work going on at the CSS WG to identify more properties where the prefixes can be dropped across the browser vendors.

Originally posted by Chirpie:

You are a group of wholly incompetent fools who started using those prefixes as if they were stable [...] Shame on you for destroying the web

You completely missed my point. When Opera officially supports the -webkit- prefixes, a lot more "incompetent fools" will use "those prefixes as if they were stable". Opera helps them "destroying the web".

I don't use prefixes if not really necessary. All my CSS is written very carefully. I don't want Opera to "fix" it. It's not broken.

To make this clear: I fight for Opera every day. I contact every webmaster and tell him his site is broken in a standards-compilant web browser. What Opera now does is like telling me I wasted my time. Even worse, to support some "incompetent fools" they are risking collateral damage in working sites. For no reason because this can be easily avoided.

Originally posted by karlcow:

I gave you answers. Not the ones you want to hear.

Maybe. Or not the ones I asked for. One of my questions I repeated over and over again is basically the same you are asking: Please show some websites that are actually broken because of a missing box-shadow, border-radius or transition. I want to see why you are risking so much.

Originally posted by JanGen:

I would prefer an extension solution, like a `top slide-in` message or a button that's warning you that the site has webkit prefixes but lacks -o- prefixes. When you push it will use the webkit-prefixes and repaint.
In that case testing in Opera will make users, owners and testers aware that developers have forgotten something: cross-browser support!

This. At least users would be aware of this behaviour, so we should be more prone to report the webmasters.

Originally posted by Thiemo:

Originally posted by Chirpie:

You are a group of wholly incompetent fools who started using those prefixes as if they were stable [...] Shame on you for destroying the web

You completely missed my point. When Opera officially supports the -webkit- prefixes, a lot more "incompetent fools" will use "those prefixes as if they were stable". Opera helps them "destroying the web".

If Opera had made a difference here these incompetent fools wouldn't be using the prefixes in the first place. Devs who know about Opera are most likely competent enough to not screw up.

Face it, despite being the top mobile browser, these incompetent moron devs are mostly ignoring it, and Opera being less compatible isn't going to make it more popular.

What Opera now does is like telling me I wasted my time.

No it isn't. However, it's clear that the battle has been lost. The cesspool of incompetence has flooded the web, and once again Opera has no choice but to be compatible with the cesspool (like IE6). You know that "doesn't work with sites" is one of the most frequent complaint about Opera, right? And you know about the myth (lie) that the Opera people are a bunch of morons in an ivory tower who only adhere to standards and don't care about real world compatibility?

Even worse, to support some "incompetent fools" they are risking collateral damage in working sites. For no reason because this can be easily avoided.

Then post examples. They're testing this in an early alpha. It isn't even in a final version yet, and 12.50 is unlikely to be released for another year or so.

Originally posted by Thiemo:

I fight for Opera every day. I contact every webmaster and tell him his site is broken in a standards-compilant web browser.

Opera's decision isn't exactly a pat on the shoulder for diligent webdevelopers, although i fail to see what's broken when experimental code is used with prefixes.

Originally posted by karlcow:

The CSS Working Group has decided collectively to unprefix a few set of properties.

@Karlcow, can you point out which ones?

As I mentioned before, i think this problem is wider than just Opera, so what is the CSS Working group's point of view?

The -webkit- prefix insanity got worse in the current 12.50 build 1546. The good news is: Opera dropped the -o- prefix from the CSS gradients (linear-gradient, radial-gradient, radial-gradient, repeating-linear-gradient and repeating-radial-gradient) as well as from the animations, transitions and transforms. Yea! I love you for making this big step forward. Burn all prefixes!

The bad news is: It's still prefixed. What do you think should happen in the following example?

background: linear-gradient(#CCC, green);
background: -webkit-linear-gradient(#CCC, red);

If you ask me, Opera must show a green background, no matter what the order of these properties is. It is not "error recovery" if a prefixed property that is not targeted to the Presto rendering engine overrides an unprefixed property. This is not for "site compatibility and interoperability". This is a step backwards.

http://my.opera.com/ODIN/blog/2012/08/10/css-vendor-prefixes-in-opera-12-50-snapshots
http://my.opera.com/desktopteam/blog/2012/08/10/more-marlin

Also in the news: For the first time we got a tiny bit of information why Opera is messing around with CSS so much: because of "Japanese mobile sites". I'm not sure if I have to thank you for this information. I feel the urge to quit my job and cry.

"For the first time we got a tiny bit of information why Opera is messing around with CSS so much"

aeh, no. it's always been said that this is for compatibility with badly developed sites.

"because of "Japanese mobile sites". I'm not sure if I have to thank you for this information. I feel the urge to quit my job and cry."

and why, exactly? a large number of sites, particularly in Japan (but hey, US and Europe are no different) exclusively use -webkit- prefixed stuff. our users access those sites, and the effects go from some things not looking as swish, to full-on unusuable sites. and despite continuous outreach effort and open-the-web attempts, those sites refuse to at least add unprefixed styles. so...solution?

Originally posted by Thiemo:

The -webkit- prefix insanity got worse in the current 12.50 build 1546. The good news is: Opera dropped the -o- prefix from the CSS gradients (linear-gradient, radial-gradient, radial-gradient, repeating-linear-gradient and repeating-radial-gradient) as well as from the animations, transitions and transforms. Yea! I love you for making this big step forward. Burn all prefixes!

The bad news is: It's still prefixed. What do you think should happen in the following example?

background: linear-gradient(#CCC, green);
background: -webkit-linear-gradient(#CCC, red);

If you ask me, Opera must show a green background, no matter what the order of these properties is. It is not "error recovery" if a prefixed property that is not targeted to the Presto rendering engine overrides an unprefixed property. This is not for "site compatibility and interoperability". This is a step backwards.

http://my.opera.com/ODIN/blog/2012/08/10/css-vendor-prefixes-in-opera-12-50-snapshots
http://my.opera.com/desktopteam/blog/2012/08/10/more-marlin

Also in the news: For the first time we got a tiny bit of information why Opera is messing around with CSS so much: because of "Japanese mobile sites". I'm not sure if I have to thank you for this information. I feel the urge to quit my job and cry.

In the example you gave the output should be red. Adding non-W3C rules to how declarations are weighted in the cascade is opening a portal to hell on earth. We've already enjoyed non-standard implementations with IE. I have no desire to go on that ride again.

I have no problem with Opera stripping out the -webkit- prefix in order to display sites correctly where functionality is for all intents and purposes identical but I would have a BIG problem if the cascade was calculated differently in Opera - which is what you are advocating.

Originally posted by Thiemo:

It is not "error recovery" if a prefixed property that is not targeted to the Presto rendering engine overrides an unprefixed property.

Fully agreed.

Originally posted by patrickhlauke:

a large number of sites, particularly in Japan (but hey, US and Europe are no different) exclusively use -webkit- prefixed stuff. so...solution?

If they exclusively use -webkit- prefixes, how does Internet Explorer (desktop and mobile) deal with them?

Originally posted by ixuzus:

Adding non-W3C rules to how declarations are weighted in the cascade is opening a portal to hell on earth.

With Opera supporting webkit prefixes, we're already in hell. Letting -o- prefixes and the standard version override them takes a little bit of the way back out.

Originally posted by patrickhlauke:

it's always been said that this is for compatibility with badly developed sites.

As far as I know Opera never told us which sites. I heard "Japanese" for the first time.

Originally posted by patrickhlauke:

so...solution?

I answered this question many times. Let me repeat: You need to ignore the -webkit- garbage if there is an unprefixed property. Use the -webkit- stuff only in cases where error recovery is required. Use it only for sites that "exclusively use -webkit- prefixed stuff". Don't mess around with my CSS (like in the examples above). My CSS is not broken.

If you need to read the -webkit- properties for error recovery then you can not make it the same precedence than the unprefixed properties. This does not make any sense. Error recovery always needs to be the last step if everything else fails. If there is an unprefixed property then no error recovery is needed. In the current builds your error recovery destroys the standard compliant way.

This is so damn stupid. Since Opera dropped the -o- prefix (which is a very good thing) you can't even use code like this to fix bad ordered properties:

border-radius: 1em;
-webkit-border-radius: 0;
-o-border-radius: 1em;

This code worked in all (!) previous Opera versions since -o-border-radius was introduced. This code will stop (!) working in Opera 12.50. And it may continue to work if Opera decides to drop the -webkit- hack some day.

This confusing crap can be so easily avoided. I don't understand why Opera refuses to act responsible.

Reported again as bug DSK-372981.

I'm curious, Why would you put the unprefixed property as anything other than the last in the cascade? Every example I've ever seen has it last, and it makes perfect sense that any definitive (i.e. unprefixed) implementation of a property should be last in the cascade to give it the highest priority.

Frankly, what is that example even trying to do: you want rounded corners… but not in Webkit; what's the use-case? Maybe if -webkit- was broken vs. a newer version of the spec, but once Webkit implements any unprefixed property surely you'd want it to support that without any work? Or maybe you really do want to avoid rounded corners in Webkit — that's you screwed when some hypothetical new version drops -webkit- support.

Maybe I'm missing something but, short of bug workarounds (which should only be temporary anyway unless with end up with another IE6-like stagnation,) why would you ever put an unprefixed property anywhere but last in the cascade (where Opera's -webkit- aliasing will have no effect anyway?) Prefixes have never circumvented the cascade, doing so would add an extra layer of complexity to CSS parsers (probably no visible hit on PCs, but smartphones? Feature phones? Smart TVs and other embedded devices?) so why should Opera start now just because it's aliasing -webkit- to unprefixed in exactly the same as Webkit does: according to the cascade?

Originally posted by Thiemo:

Reported again as bug DSK-372981.

There is no need to report the same thing lots of times, it will only be waste of people's time.

Uh? What?!
What is this topic all about?
Why do you want to show different colors in different browsers, using CSS3 prefixes?

1st, CSS prefixes should've never existed,
2nd, prefixed and non-prefixed properties should give same results,
3rd, non-prefixed should go last (as said above),
4th, you should set same values for those properties.
I think failing to set one value properly is actually a coder's fault.

It reminds me about the HTML5 parsing algorithm which fixes coders' errors like <b><i>Yo!</b></i>/i

You completely missed my point. Nobody cares how it "should" be used. It is not used like it should be in the world out there. Read my posts above. I gave answers to all of the questions you are asking.

Adding -webkit- properties to a non-WebKit rendering engine is clearly a hack. A hack must always be the last link in the chain so the chain does not break when you remove the hack some day. Simple. This can be very easily avoided.

Originally posted by BtEO:

why should Opera start now just because it's aliasing -webkit- to unprefixed in exactly the same as Webkit does: according to the cascade?

Are you kidding? The answer is so obvious: Because Opera uses Presto and not the WebKit rendering engine. The -webkit- properties were never supposed to be part of the cascade in an non-WebKit rendering engine and never should be. It's a bad hack. It's confusing. It's a slap in the face of every responsible web developer. Be responsible! I'm begging you.

This is your point:

Originally posted by Thiemo:

border-radius: 3em;
-o-border-radius: 2em;
-webkit-border-radius: 1em;

Our point is:

In CSS, last rule prevails.

It is that way,
It was that way,
It will be that way.

-o- was dropped.
It doesn't exist anymore.
-webkit-border is after border.
It prevails.

There is no bug there.

End.

Let me repeat: The -webkit- properties were never supposed to be part of the cascade in an non-WebKit rendering engine and never should be. It's a bad hack. It's confusing. It's a slap in the face of every responsible web developer. Be responsible! I'm begging you.

Originally posted by RicardoB:

-webkit-border is after border.
It prevails.

No, it does not in previous Opera versions and it will not in future versions when you drop the -webkit- hack some day.

Responsible devs uses same values for all prefixes and

Originally posted by BtEO:

Every example I've ever seen has it last, and it makes perfect sense that any definitive (i.e. unprefixed) implementation of a property should be last in the cascade to give it the highest priority.

Irresponsible is doing the inverse, as you insist.

Responsible devs may use different style sheets for different browsers, if different values are needed.
If both Opera and Chrome share the same prefixed property, you would need to detect the browser and send appropriate values.
Anyway, that is a perpetual need, as you have IE between the browser war.

I'm sorry? This doesn't solve any of the problems you create.

Eventually webkit will drop their prefix too. At that point your code may stop working or produce unpredictable results. If you are trying to send different values to different browsers then using prefixes to do it is not a good solution.

Originally posted by RicardoB:

Responsible devs

...
Well if something like that existed then we wouldn't have the problem with prefixes in the first place...

Question?

Given the following code, what would you prefer Opera to do to the corners: rounded, or straight?

div { border-radius: 1em; }
div.class { -webkit-border-radius: 0; }

Should Opera override specificity too to prefer unprefixed over wrong-prefixed? What about style attributes vs. stylesheets. Should Opera have to do an additional check any time it encounters -webkit- prefixes to make sure there's not any unprefixed rules that should take precedence.

What about border-top-left-radius vs. -webkit-border-radius? Should Opera attempt to merge those two, or wholesale discard the prefixed version? And this is just one of the properties they've aliased…

The only sane option is what Opera have done. Treat -webkit- as equal to unprefixed, and follow normal cascade rules. Sites that only use -webkit- will still work. And devs using both prefixed and unprefixed as they should will likely be fine because I've seen no-one apart from you advocate for putting unprefixed anywhere but last in the cascade.

Originally posted by Thiemo:

Are you kidding? The answer is so obvious: Because Opera uses Presto and not the WebKit rendering engine. The -webkit- properties were never supposed to be part of the cascade in a non-WebKit rendering engine and never should be. It's a bad hack. It's confusing. It's a slap in the face of every responsible web developer. Be responsible! I'm begging you.

It's an unfortunate hack to a bad problem, one notably not caused by responsible web developers who avoid (or use polyfills) experimental properties in production sites and use a full range of prefixes with unprefixed last for the more stable properties.

I'll ask again, what is the use-case for targeting Webkit for specific properties solely via prefixes — given that Opera deliberately only chose to alias properties that are stable and whose syntaxes align properly between Webkit and Presto? Why would you want your design to have rounded corners in one but not the other; I can see a possible case on mobile for emulating different OS widgets on different devices, but since they all use some version of Webkit anyway you'd still need JavaScript somewhere.

And again: what happens to your plans when Webkit drops -webkit-?

My idea was very simple: If a -webkit- property has the same specificity as an unprefixed property it looses. Thats all.

a                  {         border-radius: 1em;
                     -webkit-border-radius: 0;   } // same specificity, -webkit- loses

a                  {         border-radius: 1em; }
a                  { -webkit-border-radius: 0;   } // same specificity, -webkit- loses

a.internal         {         border-radius: 1em; }
a:link             { -webkit-border-radius: 0;   } // same specificity, -webkit- loses

a.internal         {         border-radius: 1em; }
a:link:first-child { -webkit-border-radius: 0;   } // different specificity, -webkit- wins

What I forgot: This will create the same problem I want to avoid. This page will look different in Opera 12.50 and it will look different again if the -webkit- hack is dropped some day. My idea fixes only a few cases and therefor adds more confusion.

Darn. I was wrong.