css3 border-radius and vendor prefix fud

The state of most uses of css3's border-radius around the web has been bothering me for awhile now. Though now I've found something else to be annoyed at.

The earliest common use of border-radius was -moz-border-radius in Gecko based browsers. Later on the WebKit implementation came into common play. When and where things were actually implemented isn't really important, that's just the order that people started to know about them as common knowledge.

As a result there are plenty of websites around which are still using out of date css that only support Gecko and WebKit based browsers, or in some cases support nothing but Gecko based browsers. This is somewhat irritating considering nearly every browser — at least in their most recent versions — support border-radius, and by using incorrect css they omit support for browsers that actually "DO" have a border-radius implementation. Like Konqueror, Opera, and IE9.

But besides out of date css on sites that don't bother to update it (I told Wikia about it awhile ago, and they're still using bad css) I've found a new irritation on the other side of border-radius implementation. Vendor prefix fud.

There are a variety of blog posts and help pages around now spreading mislead information about what border-radius properties to use, and giving bad advice on what rules to use leading to people using the rules in the wrong order as well.

The first issue, some posts are recommending -o- stating that Opera uses it. This is fud, Opera has never used -o-border-radius, Opera's border-radius implementation from the very beginning used the standard border-radius property, -o-border-radius has never been implemented in any released version of Opera to date, and since it's using the standard unprefixed property it never will. (Opera's forums even cleared this up)

The next issue, -icab-. Unfortunately I can't confirm or deny this one myself, I have never heard of this one being valid, searching the net I cannot find any documentation stating that -icab- has ever used -icab-border-radius — besides blog posts which are spreading fud like the existence of -o-border-radius.

Not as common, but I have also seen some assertions of -ms-border-radius, this one is incorrect to. Just like Opera, Internet Explorer's first ever implementation of border-radius in IE9 used the standard border-radius property, -ms-border-radius has never been used. So just like -o-, it's worthless.

As of writing this the known implementations of border-radius and the vendor prefixes used are:

  • -moz-border-radius in Gecko based browsers
  • -khtml-border-radius in Konqueror and early WebKit implementations
  • -webkit-border-radius in WebKit implementations
  • border-radius in Opera 10.50 and IE9, Gecko and WebKit browsers have also started using the standard property

And now the bigger problem. Besides spreading bad information about vendor prefixes people are also using bad examples of what css to use like:

.rounded-corners {
  border-radius: 10px;
  -ms-border-radius: 10px;
  -moz-border-radius: 10px;
  -webkit-border-radius: 10px;
  -khtml-border-radius: 10px;
}

The problem? CSS is cascading, in other words, if it can understand them the browser prefers the last matching rule of a type. This is how background-color: #fff; background-color: rgba(255, 255, 255, .75); works. A browser supporting rgba sees these, and because the rule with rgba in it comes after the one with #fff the browser goes and applies that rule. While a browser that can't understand rgba yet sees the second rule as an error because it can't understand rgba, and hence it applies the first rule instead, giving you a fallback without the alpha transparency when rgba isn't supported.

Now, the problem here, is this is supposed to work similarly for vendor prefixes. If a browser sees two border-radius rules it can understand, with varying prefixes, it will apply the last border-radius rule it sees. In the case of vendor prefixes the early vendor prefix implementations can contain bugs and bad rendering in them to remain backwards compatible with the web, when a vendor implements the standard property they usually implement the proper behaviour using the standard property, and retain some of the bugs inside the version using the vendor prefix. Thus for example if you use border-radius: 5px; -moz-border-radius: 5px; and a Gecko based browser has implemented support for both -moz-border-radius and border-radius and retained bugs in the -moz- version while implementing the proper standard in border-radius, when it reads your see it sees the last rule -moz-border-radius and a proper implementation will go and render the buggy version of the property instead of the proper standard because you used the wrong order.

Hence because border-radius is the standard it should always be the last rule in the list of border-radius properties. Because early versions of

So finally, unless you can find a strong citation that icab actually "does" use -icab-border-radius that isn't sourced from fud, then this is the only properly done radius pattern.

.rounded-corners {
  -moz-border-radius: 10px;
  -khtml-border-radius: 10px;
  -webkit-border-radius: 10px;
  border-radius: 10px;
}

You're free to move the -moz- after the -webkit- if you please, but -khtml- must be before -webkit-, and the standard property must be the last rule.

Tags:
  • programming
  • css
  • browser
  • css3
PreviousNext