On CSS vendor prefixes and applying pressure where it is making most sense

If you are a web developer chances are pretty good that you have read quite o lot of tweets and blog posts on vendor prefixes lately. It all started when Daniel Glazman issued an urgent call for action. Various people have chipped in including Bruce Lawson and the Web Standards Project.

This is an expanded version from a comment I wrote on Daniel Glazman's blog.

My background

Please bear with me as I explain my background. It is important for the thoughts I have at the end.

I am an educator. I teach web development for a living and has done so for more than a decade. As a consultant for Skolverket, Sweden's national agency of education I have in fact succeeded in making standards, accessibility and best practices mandatory requirements for all teaching in the country at the secondary level (approx. senior high school in the USA/A-levels in UK).

I am participating in the Web Standards Project Education Task Force, am co-author of InterACT with Web Standards and have written material for the InterACT curriculum project. I also participated in OWEA and now the Web Education Community Group at the W3C. (Of course nothing on this blog is the official position of any such entity.)

I thoroughly believe in education!

Nevertheless I do not see how education alone can solve the problem at hand. Too much misinformation, too much marketing, too much Apple- and Google-centric journalism. Education can only alleviate the problem, never solve it.

There is a solution available that will make the problem disappear

There is in fact a solution available. One that would do more good than anything else.

Webkit must drop support of prefixed properties when there has been a standards compliant solution implemented, after a reasonable grace period. Say 6 months.

This is after all what all other browser vendors are doing right now.

This is how prefixes are supposed to work. This is the right thing! Anything else is a violation of the principle.

And yes, this will break sites, which is the exact point of this solution!!!

This is the only way to create the necessary urgency that will reach into web development sweat shops in India and China, as well as into the corporate management level in the larger companies.

There are educated web developers that simply do not have the time or the mandate to fix problems like these, because upper management do not care. They think about their own product here and now, not what's good for the web as a whole 10 or 15 years into the future.

Let's apply pressure on Apple

This is primarily not about blame, but applying pressure where it is most useful.

Let's create and uproar in the web development world strong enough to create bad will for Apple, forcing upper management to do the right thing!

Apple (and to a lesser extent Google) are sitting on the solution. Not Microsoft, not Mozilla, not Opera.

If they are getting away with acting badly it is because we are letting them, letting love for the products they make get in the way of the higher goals, letting them behave in ways that perhaps was OK when the iPhone was launched and Webkit had 0 % market share on mobile, but not changing their way according to the present situation.

Apple initially supported SOPA and PIPA – which speaks volumes about the default mind set within the company – but back peddled. So even if they have claimed that they will never remove the support for prefixes, let's create enough pressure on Apple that they will benefit from back peddling again!

Right now the pressure is applied to Mozilla, Opera and Microsoft to do the right thing, even if it will hurt their market share – and by extension their ability to fight for a free and open web in the long run. We are asking those companies to sacrifice themselves for the common good and for higher ideals.

But Apple is either loved too much for anyone to act against them – or seen as a lost cause, an unfixable problem, the IT equivalent of North Korea.

As long as the web development community is stuck in that love/hate relationship with Apple, we can never act sensibly.

Who can afford it?

Apple has just had a another record quarter and even may surpass IBM and HP in a few years.

• Still they won't hire evangelists like Opera, Google and Mozilla that teach best practices.
• Still they won't hire full time spec writers to get their proprietary extensions through the standardization process.

The takeaway from every Apple keynote I've heard the last years is "concentrate on the iPhone and iPad".

This message need to change!

The other main stakeholder in Webkit is Google. And their business is not shabby either. In fact it is Android and Chrome that has made Webkit the most popular browsing engine in the world.

But Google embraces open more than Apple. Google may very well be quite easily persuaded to stop supporting prefixed properties for mature technologies, in my opinion.

It is Apple that primarily needs to be pressured.

What's at stake?

Since Mozilla not only develops their browser openly, but has an open process for just about anything I stumbled upon their internal discussion about supporting -webkit- prefixes already a few months ago. First of it is quite clear that nobody within that organizations likes the idea of supporting -webkit- prefixes. Even those that support the idea do so with the utmost distress.

But except for some Gnu/Linux distros Gecko is not the default rendering engine anywhere. Opera is in a similar position. For the majority of users their is but one incentive to switch: A better user experience.

That is the bottom line.

Not ideology, but my experience as a user today, is what makes people switch.

However, since Mozilla and Opera to a high degree are value driven organizations it is easy to think that it is "their job" to keep the web open. But if right decisions comes at the cost of minuscule market shares they won't have much power to wield anyway.

And please remember that Opera and Mozilla did go down the path of ideology concerning video codecs. Would that have been possible today when their market share is falling?

It's time for Apple to pay back

Apple has never been a true champion of the open web or indeed anything open. Despite the fact that open technologies saved Apple from ruin. That, and two important gifts from Microsoft: Cash in return for stock that gave no voting power and a commitment not to stop developing Office for Mac OS.

Back in the 90's Apple struggled to develop a modern and technologically sound operating system. Copland failed. Taligent failed. And so did a bunch of other efforts.

The number one option was to buy BeOS and that deal almost came through. (Imagine the world if it had! Steve Jobs return would probably not have happened...)

However, what Apple could not develop in house they found in open source:

• The Mach kernel.
• BSD
• KHTML from which Webkit is forked.

But also this might not have been. KHTML developers came very close to throwing in the towel and switching to Gecko.

Once again, what if they had? What if they had not persisted thanks to ideology, not business considerations?

Projects driven by ideology provided Apple with the core technologies from which they have built Mac OS X, iOS and the Safari browser.

And Apple also benefited from Firefox. It was Firefox that wrestled the web away from Microsoft. It was Firefox embracing standards that provided the opportunity to develop a browser like Safari. Remove Firefox from the equation and there would never have been a superior browsing experience on the iPhone. Those experiences were made possible from developers embracing standards thus eliminating the Microsoft monoculture.

So why should Apple help the world? Because the world first helped Apple!

Once again, we should apply pressure where pressure is due.

Unconditional love or unconditional hate bestowed upon Apple will both just make the company worse. And as for the latter (hate), did you notice that Apple actually pack peddled concerning SOPA and PIPA? Given enough pressure the company actually can abandon bad ideas.

If the web development community keeps praising Apple as if the company does nothing wrong – or at least nothing wrong that can't be excused – or if we treat Apple like a lost cause, a closed brainwashed sect incapable of change, then by all means, put all pressure on Mozilla, Opera and Microsoft.

But please acknowledge that in so doing we are forfeiting our best chance to keep the web open. Remember, this is not so much an issue of who is to blame, as it is an issue of how it could be fixed.

Still using Firefox because privacy matters

I am still using Firefox as my number one browser, occasionally switching to Opera, and occasionally trying out Chrome (on my Laptop). Why am I so stubborn, some Chrome fans will ask? And why am I not using the default Android browser on my slate? And why did I not end up buying an iPad?

It all boils down to two points: The browser ecosystem and the browser ethos.

The web is more important than apps

Sometimes I hear people say it's all about the apps. I disagree. The web is the only one truly open and life changing platform. I did not chose Android over iOS because of usability or design concerns. I'd say it is still slightly – but only very slightly – behind. My new phone is a Nokia N9. Neither Android or iOS, but Meego! And yes, it has a few hundred apps, including a Dropbox client and a Google Reader.

(By the way, the user interface on the N9 is just fantastic, it beats both the iPhone and Android!)

However, both the Android Tablet and the Meego Phone lets me run Firefox. And that is nowadays a sine qua none for me when choosing a device.

Every major browser has an ecosystem nowadays

Of course all browsers can surf the web and in that regard the web is their ecosystem. But in addition to that they come with additional features.

• Internet Explorer's ecosystem is that of corporate intranets, Windows and the occasional web site that still requires ActiveX. I know of few people who enters this ecosystem by choice, except gamers, but it is easy to get support. And all your games are playable on the hardware that is far cheaper than anything from Apple. And Windows does really have the best graphics drivers and infrastructure for sound.
• Chrome's ecosystem is of course Google products: G-mail, G-cal, G-reader, G-docs and G+. You're at least considering getting an Android phone and think that Chrome OS has a lot more potential than it has shown so far. You are obviously not so concerned with the privacy of your data.
• Safari's ecosystem is of course the Apple products. If you are into Apple, you're using a Mac, and every program in sight that starts with an i. You had an iPod and now have an iPhone and you will get an iPad, not because you need it, but because its made by Apple. In short, you enjoy the shiny prison of being locked in to Apple. Censorship and authoritarian control of the platform be damned – the bars are golden!
• Opera thrives on the mobile and on devices. They have managed to make web surfers out of millions of people who never could afford a modern smart phone. In some ways though, they struggle since the entire web universe basically is their ecosystem – except for sites made by incompetent developers that shut Opera out for no good reason. There are things like Opera Link and Opera Unite, but they have not got the buzz they so rightfully deserve. The fact that Opera pioneered many things now common to all browsers, like tabs, and have always been a true champion of standards, even before Mozilla appeared, makes them worthy of tons of respect.

So, what makes Firefox ecosystem so special? It boils down to one thing. Firefox is everything!

• It is not the oldest champion of web standards among browser vendors, as that honor goes to Opera, but they are a good runner up, and it was Firefox that de facto wrestled the web away from Internet Explorer, providing room for all other browsers to exist as well. Firefox paved the way for both Safari and Chrome!
• It is not the true speed king, as that title goes to Chrome or perhaps Opera, that are faster on most – but not all – benchmarks as far as I can tell. But it is fast enough. And it championed the cause of being lean – once upon a time! Even today it consumes far less system resources than most other browsers.
• It is, however, the true champion of add-ons. And it has the best add-ons for my needs.
• Firefox has the best sync. First of all it is client side encrypted, meaning no data mining opportunities for Google or anyone else. But what makes it stand out is the syncing of tabs. It's a time saver and a life improvement factor! I sue it all the time, moving between computers, my phone and my tablet.

The right focus for the future

The economy of the future in IT is data driven. In a world of ubiquitous computing stewardship of our data in the cloud is the main prize for all big players to fight about. Through pads, tabs and boards data will be accessible in lots of places. But whoever is in control of the cloud is the winner of the future.

But will cloud stored data be accessible to all? Or only a select few that use the right brand?

And will it be inaccessible to anybody except those that I chose to share my data with? Or will the host continually mine my data and in the worst case scenario share it without my consent?

In this regard, Apple's guiding principles fail totally. The company shows close to zero interest in interoperability and since the margins go down when selling cheap devices this becomes a global problem. By building digital walls around the data in the richest countries, we are once again failing all non-western countries.

By the way, the Arab spring was not brought to the world by Apple, but by Nokia…

Google might not have failed yet. Interoperability is high on their agenda and so far their data mining seem to be mostly anonymized. But when one single entity sits on too much data and control the complete surrounding ecosystem, we are providing someone with enormous temptations. Sooner or later that temptation will become too strong!

Therefore we need truly anonymized cloud technologies. We need user owned and controlled data. We need stuff like browser id to replace the usage of id-solutions provided by Google, Facebook, Twitter, Microsoft or Apple.

In short, we need what Mozilla and Opera are championing. And for me personally that means that if you see me using a browser for anything but testing, that will still be Firefox for the foreseeable future, unless I change to Opera!

PPK is wrong, vendor prefixes are a necessary evil.

Yet another considered harmful essay has hit the web. This time it is PPK, a well known JavaScript guru and very influential author that has written it. And I get to disagree with another one of my heroes. (Just recently I have disagreed with Rasmus Leerdorf on the naming of the next major PHP version...)

Basically PPK is like many others fed up with writing the same rule 2, 3 or even 4 times. You know the drill:

-moz-border-radius: npx;
-webkit-border-radius: npx;
border-radius: npx;

Add in a few (-ms-)filter as well and it's a nightmare. And the CSS-validator is not configured to ignore these, even though they are not errors per se. It is sure easy to echo PPK's sentiment. But I believe he is wrong, and fortunately I am not the only one.

Proposals do change

Case in point is border-radius and gradients. Mozilla could not just drop -moz- from border radius, since their 6 year old implementation is not aligned with standards. Webkit can not drop the prefix from their gradients rules, since the standard probably - please note that word, probably - will look like Mozillas implementation.

I also note that he has put the non-prefixed version of a rule before the prefixed ones, which is not optimal for the very same reason. A problem I have dealt with in an earlier blog post.

Experimental versions are needed for things to move along. Without them very few people will be able to experiment and improve the proposal. This is a real need, this is a real problem.

Contrary to what PPK says, vendors do not simply copy each other. They often start that way, end then they run into questions like what about... and they will have to discuss and test and decide and make changes. Both to the implementation and the spec. Such discussions take place on the W3C mailing lists all the time.

Standards must be standards

PPK dislikes vendor prefixes because they seem to be the opposite of standards: Vendor specific rules, code forks, similar to browser sniffing in JavaScript.

But what he is proposing is effectually doing away with the entire W3C process. Yes, it is slow and burdened by politics. But if we drop vendor prefixes that will mean that as soon as a browser puts out a new technology it, by virtue of being first, has decided unilaterally what the syntax should look like and how it should work in every browser. This is not a standards process, this is in fact the opposite. First to market rules and everyone else be damned!

Experimental versions of future standards are a good thing, since they allow for real discussion and much more thorough standardization. One of the reasons standards are moving slowly is that today they are much more detailed, much more tested and therefore much more reliable.

This is not unique to web standards. Consider IEEE802.11n and the fact that we for a couple of years had draft version equipment on the market. Good or bad? It made the final implementation better, so yes it was good. And a necessary evil as well.

There must be room for errors

Webkit has not copied Mozilla's implementation of border-radius and Mozilla has not copied Webkit's gradients. Having discussed the proposals changes have been made, lessons have been learned and this has happened in real life.

If a vendor must not use prefixes it would take forever to get to a place where they would be confident enough to put out a new technology. Opera and Microsoft may skip the prefix for border radius, since thanks to Mozilla that 6 years ago put out an experimental implementation and thanks to Webkit, that 3 years ago put a out a slightly different experimental implementation, the standard has now reached Candidate Recommendation status and web authors demand the technology, because we have been able to experiment with it!

If it had not been for prefixes, only a very few people would actually have bothered to download experimental browsers and try this out. That is our only other option. The word would not have spread and demand had not been built up.

Is summary. PPK, I love your work and have tons of respect four you. But in this case you are wrong. I will not shout long live the prefixes, since I wish that every prefixed CSS rule should have short life. But I want that short life to be productive.

Do not put experimental features last in your CSS

Today's blog post will be short one. I have lately seen code like this on more than one occasion:

#foo { 
border-radius : 10px; 
-moz-border-radius : 10px; /* Mozilla */
-webkit-border-radius : 10px; /* Webkit */
}

What is the problem?

Right now only one line will have an effect. In Gecko-based browsers, like Firefox, the one starting with -moz-, in recent Webkit based browsers, like Safari and Chrome, the one starting with -webkit-, as indicated in the comments. These are the two current experimental implementations of the coming CSS 3 border radius property.

Hopefully in the near future the specification will thanks to these two implementations reach a level of maturity, where browsers may start to implement it in a non-experimental version. If so one thing is to be expected. The non-experimental implementation will most likely differ (somewhat) from the experimental one! And as a developer you will most probably want the final version to be the one that browsers actually use. And when two rules affect the same property like this (equal specificity, equally placed in the cascade), the last one will override the first one. Therefore you should put things in this order:

#foo { 
-moz-border-radius : 10px; /* Mozilla */
-webkit-border-radius : 10px; /* Webkit */
border-radius : 10px; 
}

Why is this better?

During a transition phase, lasting at least a few years, Webkit and Gecko can be expected to support both implementations. There are sites that use the experimental versions only and in order to give them a grace period, dropping support as soon as the final version is implemented is not an option. Historically Mozilla has let such grace periods last for 2-4 versions of Firefox.

So this is the bottom line. Put experimental features first, standard features last. That will ensure a better forward compatibility.