The post continues:

While a number of web pages already make use of this feature, some [...] do not render properly in IE9 or Opera 10.50 because they lack an unprefixed declaration of the border-radius property.

As the specification nears Recommendation and browser vendors are working on their final implementations and testcases for submission to the W3C, we recommend that new content always include a border-radius declaration without vendor prefix.

I’d like to go one step further.

It’s time to abolish all vendor prefixes. They’ve become solutions for which there is no problem, and they are actively harming web standards.

Vendor prefixes force web developers to make their style sheets much more verbose than is necessary, while also running the risk of accidentally forgetting one set of vendor-prefixed declarations.

Besides, why do we need to use several declarations for obtaining one single effect? Weren’t web standards supposed to prevent that sort of thing?

Guys, let’s stop the vendor prefix nonsense. Enough’s enough.

The point

Originally, the point of vendor prefixes was to allow browser makers to start supporting experimental CSS declarations.

Let’s say a W3C working group is discussing a grid declaration (which, incidentally, wouldn’t be such a bad idea). Let’s furthermore say that some people create a draft specification, but others disagree with some of the details. As we know, this process may take ages.

Let’s furthermore say that Microsoft as an experiment decides to implement the proposed grid. At this point in time, Microsoft cannot be certain that the specification will not change. Therefore, instead of adding grid to its CSS, it adds -ms-grid.

The vendor prefix kind of says “this is the Microsoft interpretation of an ongoing proposal.” Thus, if the final definition of grid is different, Microsoft can add a new CSS property grid without breaking pages that depend on -ms-grid

Now in itself this is a reasonable line of thought. Point is, it’s outlived its usefulness. It’s just not necessary any more, neither from a practical nor from a more philosophical point of view.

Practical problems

Let’s take a look at some practical cases.

box-sizing

One place where vendor prefixes have always annoyed me terribly is the box-sizing property that allows you to switch from one box model to another. Currently IE8 and Opera support box-sizing without prefix, but Firefox supports only -moz-box-sizing and Safari, Chrome, and all mobile WebKits only -webkit-box-sizing.

In other words, this is the code to switch the box model of one div.

div.borderbox {
	box-sizing: border-box;		/* one */
	-moz-box-sizing: border-box;	/* two */
	-webkit-box-sizing: border-box;	/* three */
}

The fact that I have to use three declarations for obtaining one effect is completely preposterous. We might as well live in the Browser Wars era. Standards, anyone?

The point here is that box-sizing will not change any more. Its purpose is to switch box models, and its two values border-box and content-box are supported everywhere.

This declaration makes sense as it is, and it is supported by all browsers as it is. So it should have the same name in every browser.

Why wait for W3C to put its stamp of approval on it before removing the prefixes? We all know that’s going to take another five to ten years.

Mozilla, WebKit, you’re just being thoughtlessly conservative here. Get rid of your vendor prefixes.

Transitions

Consider the transitions Safari added. They’re all prefixed with -webkit-. Here, too, the point is that the Safari team has effectively specified all these declarations. They’re not going to change any more.

Google and Opera are implementing transitions, too. I studied the Apple and Opera documentations a bit, and they look quite alike. In fact, right now I dare state that Opera is working to copy Apple’s transitions system.

But Apple uses -webkit-transition, while Opera is using -o-transition.

Guys ...

div.coolEffect {
  -webkit-transition-property: opacity;	/* one */
  -webkit-transition-duration: 2s;
  -o-transition-property: opacity;		/* two */
  -o-transition-duration: 2s;
  -moz-transition-property: opacity;  		/* three */
  -moz-transition-duration: 2s;
  -ms-transition-property: opacity;		/* four */
  -ms-transition-duration: 2s;
}

I don’t want to use four browser-specific declarations to obtain one effect! This sort of vendor-specific nonsense is exactly what web standards were supposed to do away with. No more bloody fragmentation!

What if a web developer accidentally forgets one vendor prefix? Then the effect won’t work while it could — something we’ve learned to recognise as a grave sin. Still, it’s bound to happen in a standardless world.

Enough’s enough. Vendor prefixes have to go.

A peek into the future

The most idiotic example comes from the mobile world. Opera has implemented a touchscreen media query in the Vodafone widget manager, and called it -o-touchscreen.

When Samsung started to work on its WebKit-based widget manager, it was notified of the existence of this media query and promptly copied it. To the letter.

Thus, we now have a WebKit browser reacting to -o-touchscreen.

And this is just the beginning. It’s going to get much, much worse.

Eventually Opera will discover that plenty of sites use -webkit-transition, but not -o-transition. Will Opera start to support -webkit-transition, too?

From a compatibility perspective that might make sense. From any other perspective it’s totally ridiculous, though. And there’s a simple solution to this problem: transition has become a de-facto web standard. So treat it as one.

Let’s stop the vendor prefix nonsense. Now.

Philosophical problems

So from a practical perspective vendor prefixes are turning into a tool for fragmentation. From a philosophical perspective, moreover, they solve problems that just aren’t there any more.

As far as I can see vendor prefixes were supposed to solve two problems:

1. The problem with unfinished standards I outlined earlier.
2. The problem underlying that problem: an automatic assumption that, when left to their own devices, browser vendors would all start to implement their own stuff without paying attention to what the other browsers were doing.

Both problems have meanwhile been solved, as far as I can see.

We’re currently moving toward a situation in which anything that is implemented by two browsers more-or-less automatically becomes a standard. I don’t think that this change of process has been accepted by W3C yet (it might take another generation), but it’s becoming reality as we speak.

The reason this system can work is because browser vendors now want to copy each other’s implementations! Microsoft, Mozilla, Apple, Google, and Opera are all eyeing each other’s browsers and want to resemble each other in standards support, while competing in execution excellence, interface smoothness, and standards extension.

Contrary to the Browser Wars era when vendor prefixes were defined, right now browser vendors are genuinely interested in interoperability. There is no danger any of them will go off on a wild tangent and, I don’t know, redefine box-sizing: border-box to mean “anything inside the border.” That sort of thing just doesn’t make sense any more today.

The Safari team invented cool, new transition stuff. They made it CSS-based, documented it, and submitted it to W3C. That’s all good.

Then they added the -webkit- prefix. That’s bad.

Now Opera comes along, and wants to support transitions, too. Is Opera going to invent its own system? Is Opera suddenly going to give transition a completely different meaning that is totally incompatible with Safari’s?

Of course not! The Opera guys aren’t crazy. They know their bread is buttered on the compatibility side of things. The same goes for all other browser vendors.

But they do add their own vendor prefix. That’s ridiculous. And pointless.

transition and all the rest have become de-facto standards. Any browser implementing the transition system will make sure that it is compatible with Safari. So who needs vendor prefixes?

Dear browser vendors, take a little more pride in your willingness to work with your competitors towards web standards, even when you invent new functionality. You do not need vendor prefixes any more. You’ve grown beyond them.

The time has come to abolish all vendor prefixes. They’ve become fossils of a bygone era, but with the potential to harm web standards significantly.

Sure, everybody who does iPhone apps, or who’s glancing cursorily at the mobile market without trying to gain in-depth knowledge, currently believes that the App Store concept is going to be a huge success because of the opportunity for developers to earn some money. But they’re just wrong.

I did some back-of-napkin calculations and found that, macro-economically speaking, iPhone app development costs money right now. And yes, an individual developer can strike it rich, but that’s getting rarer and rarer. I do not want to build a new app ecosystem based on arguments from developers who just want to take a gamble in the App Store roulette. Gamblers’ arguments are not real arguments.

Compared to the current crop of mobile clients and developers, lemmings marching off a cliff follow a solid, sensible strategy. Startling them out of this obsession requires nothing short of a new buzzword.

Therefore I’d like to re-brand standards-based mobile websites and applications, definitely including W3C Widgets, as “HTML5 apps.” People outside our little technical circle are already aware of the existence of HTML5, and I don’t think it needs much of an effort to elevate it to full buzzwordiness.

Technically, HTML5 apps would encompass all websites as well as all the myriads of (usually locally installed) web-standards-based application systems on mobile. The guiding principle would be to write and maintain one single core application that uses web standards, as well as a mechanism that deploys that core application across a wide range of platforms.

For clarity's sake: this year I have nothing to do with the organisation; I'll just attend the conference, relax, enjoy the show, as well as a beer or two.

Maybe I'll meet some of my readers at Fronteers 2010.

Swept away by the literally two requests from non-Dutch readers, I’ve also decided to publish my political primer, which will ideally consist of eleven long background articles, of which only the first eight are written. I will publish one article every Wednesday until I run out of material.

Here on the main QuirksBlog I may write some stuff about the JavaScript graph functions I created for the primer (parliament graphs, tables). Unfortunately, right now any JavaScript-focused article would mainly consist of a long list of features I haven’t implemented yet. Most of the graphs aren’t really keyboard-accessible, for instance, because I’m not happy with the idea of adding dozens of useless <a> elements just to make parts of the graphs keyboard-focusable.

All in all I’m hurrying to catch up with events. I hadn’t planned to publish any of this, but the government crisis has forced my hands. Please excuse the occasional wart or bug.

The Balkenende IV government (i.e. the fourth government that Balkenende (CDA) was prime minister of) was formed three years ago and consists of centre-right CDA (christian-democrats), centre-left PvdA (Labour), and orthodox-protestant left-leaning CU (Union of Christians). Yesterday evening the PvdA ministers resigned over a conflict about the continuing Dutch military presence in the Afghan province of Uruzgan.

In a week and a half local elections will be held, and the PvdA was slated to lose a lot of seats everywhere. PvdA party leader and finance minister Bos clearly hopes to stem the electoral tide by his resignation, and he might well be right.

Update: This will be the last political entry on the main QuirksBlog. I now have a separate politics section with a blog as well as an article series about Dutch political history.

This post gives an overview of announcements by mobile players that might be of interest to web developers. There’s an incredible lot of it, too, because every single major mobile player except Apple feels that MWC is the ultimate forum for major announcements.

If you know of more news, or have links to additional information, please leave a comment.

I was there because Vodafone had invited me to sit on a panel in a technical “embedded conference” about W3C Widgets and related technologies. The concept can use some fine-tuning; I’m hoping to do some of that in the future. I was there mainly to stress that the mobile browser situation is not as simple as it looks. THERE IS NO WEBKIT ON MOBILE!
While I was at it I also invented guerilla browser testing.

More specifically, today I will shout at web developers who think that delicately inserting an iPhone up their ass is the same as mobile web development.

Before we start, a little thought experiment. Suppose I proposed the following:

1. IE6 is today’s most advanced browser. (Note: this was actually true back in 2000. Please bear with me.)
2. IE6’s market share is about 80%.
3. The other browsers are way worse than IE6, and developing for them is a pain; something we’re not interested in and are a bit afraid of.
4. Therefore we will develop websites exclusively for IE6.

Would you agree with those sentiments, even if we’re back in 2000 and IE6 is really the best browser we have?

Or would you reply that our sites should work as well as they can in all browsers through the use of web standards, progressive enhancement, and all the rest of the best practices we’ve been preaching for the past ten years?

I distinctly remember a time when we web developers cared about such concepts. But those times are long gone.

That’s a fair question. It deserves a fair answer.

Apparently, the touchstart event object persists in browser memory even when the event has long ended. More importantly, it continues to be updated with information about the current touch action.

This is interesting. It’s also profoundly different from the desktop, where a similar trick with the mousedown, mousemove, and mouseup events definitely does not work.

Both iPhone and Android display this behaviour. Therefore future implementations of the touch events should, too.