Archive for February, 2012

On the vendor prefixes problem

People have asked me to explain the vendor prefix problem. This is me (Bruce) explaining what I believe to be true (a couple of details are fuzzy to me, so forgive any errors – I’m trying to explain the concept). This is NOT a statement of Opera’s position or intents, so don’t be a dick and blame them for my opinions or mistakes.


On Monday at the CSS Working Group, Microsoft, Mozilla and Opera announced that each are considering supporting some -webkit prefixed CSS properties. (Search the minutes for “Vendor Prefixes”. Florian is from Opera, Tantek represents Mozilla, Sylvaing is Microsoft’s glamorous rep, and Tab is from Google. Glazou is Daniel Glazman and Plinss is Peter Linss, the two co-chairs of the Working Group.)

Lots of developers, despite evidence to the contrary, have assumed that mobile Web = WebKit browsers, because that’s the rendering engine in Android and iThings.

Suppose a developer made site a while ago and used the experimental, pre-standardised code -webkit-border-radius and didn’t use the cross-browser future-proof method.

The real CSS property border-radius has been long been standardised and supported without prefixes in all the major browsers. But the -webkit- prefixed version still lingers on in Safari and Chrome, so that legacy code looks fine in the webkit browsers, but broken in Opera, Firefox and Internet Explorer.

The webkit team have said that they won’t remove such legacy properties for compatibility reasons, and I haven’t heard howls of indignation about this. So the recent proposal is that non-webkit browsers will support -webkit-border-radius as if it were border-radius and thus won’t look “broken”.

I imagine that sites that only use -webkit-transition and -webkit-text-size-adjust etc will be similarly supported.

This is an approach suggested by Daniel Glazman, co-chair of the CSS Working Group:

The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set.

Exactly which prefixes would be supported in this way and whether they would be the same in Opera, Microsoft and Firefox, I don’t know.

Personally – PERSONALLY – I’m pretty depressed about all this. I’ve spent 10 years – pretty much since IE6 came out – evangelising cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.

Daniel has put out a call to action for developers to fix their sites and mend their ways: CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*. Chris Heilmann of Mozilla has launched a community action called Pre-fix the web!. Read them. Join in. I truly hope they work (although fear it’s too late).

Comment if you like, but I won’t be able to moderate them for a few days, so better to write your own blog posts!

(added 18:45)

I should add that we will still need responsible developers using vendor prefixes right – this is not the end of vendor prefixes. From those who teach, from those who developers look up to, from those selling frameworksWe still need better, responsible evangelism and demos.

The proposal is to support a subset of -webkit- prefixes, especially the archaic stuff like -webkit-gradient, so that those sites don’t look dreadful in non-webkit browsers. The plan is not to support everything that the webkit devs pull out of their hats, every time they get the urge to extend CSS.

So, we still need to use cross-browser future-proof vendor prefixes if we decide to let experimental, pre-standardised code out on production sites.

(added 10 Feb 09:30)

Robert O’Callahan of Mozilla has a post on Alternatives To Supporting -webkit Prefixes In Other Engines which pretty accurately sums up the situation, too.

Reading List: mobile development approaches

Just three links for this reading list, because they show a profound schism in the way people are thinking about building applications that have previously been desktop only and take them to mobile.

The schism is the same as we’ve long had on desktop. It’s simply: do you make your target audience as wide as possible, or do you only design for people who use the same technology as you do?

The nations’s favourite social-media based conference organiser thingy, Lanyrd, launched its mobile version two days ago. I don’t own an iThing, but I assume it’s great there, and it looks and works excellently on Opera Mini and Opera Mobile on Android.

Jake Archibald, JavaScript developer at Lanyrd, said

“Although we’re employing some ‘new and shiny’ browser features, we’ve taken the righteous path of progressive enhancement and been liberal with our testing and support. While most mobile offerings are targeted at particular devices or WebKit, our support includes quirky devices like the old Blackberry 9000 (yes, it still haunts people’s pockets), the Kindle, and even basic feature-phones if they can run Opera Mini. The site works as expected without JavaScript.

Compare this with the 37Signals’ blogpost yesterday, provocatively entitled Developing for old browsers is (almost) a thing of the past:

It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.

What is this fabulous remedy that 37signals have found? Simply, ignoring users of browsers that you don’t want to support. “Supporting your browser is hard – let’s go shopping”, as Barbie says, or Regressive Ken-hancement in strict Computer Science terminology.

Compare this with Jake Archibald’s comment:

All it took was *not* doing everything wildly different to how you should develop a standard website.

Summarising this dichotomy is an excellent article Did we lose track of the big picture?:

It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) – from targeting users, to focusing on devices and modern browsers.

We write about new techniques without considering fall back mechanisms, we use ARIA “hacks” that look like anti-patterns and we use frameworks that have chosen to ignore oldIE.

If you read no other high-level articles this month, read that one.

(Last Updated on 8 February 2012)