On vendor prefixes and WODs
With yesterday’s revelation that Opera are going to support WebKit prefixes, the vendor-prefix issue which first raised its head back in February, was once again brought to the fore. Personally I don’t think that vendors supporting each other’s prefixes is a good thing.
At the moment we don’t have the technical ins and outs of how or what Opera will supprt exactly, as this will be released by Opera in a detailed blog post soon. But from comments I’ve seen from some Opera people on Twitter, it appears that it will only be a handful of the more common WebKit prefixes. Opera evangelist Bruce Lawson provided .net magazine with a statement indicating that:
…too many authors of mobile sites only use the WebKit-prefixed version, and not even the standard, unprefixed one, when it is available…[which]…leads to a reduced user experience on Opera, Mobile Firefox and Mobile IE, which don’t receive the same shiny effects, such as transitions, gradients and the like, even if the browser supports those effects.
Fair enough, I think, but I also don’t think that vendors should be pandering to the needs of bad web developers. If you’re a web developer who only uses WebKit prefixes then you’re not a very good one.
Web developers should be testing what they produce in a number of browsers, at least Firefox, Opera, Safari, Chrome and the latest Internet Explorer. If a client says “I like this animation here, but why doesn’t it work in my IE8?”, it’s ok to give the excuse that the browser doesn’t support it. If the client wants that support, then further discussions can ensue.
Why is it any different for the WebKit Only Developer (from here on known as a WOD) who gets asked why the website whizziness doesn’t work in Firefox or Opera? It would make the lazy developer (which is what a WOD really is) dig a bit deeper and discover the world of other vendor prefixes and stacking them to support other browsers, and thus improving them as a web developer. This is what we should be aiming for and the vendors shouldn’t be supporting WODs and other lazy developers.
Ultimately my message to vendors is this: continue doing your good work and stop supporting the WODs.
12 Responses
Hi Ian
nice, reasoned article, thanks.
There are about only a handful of aliases so far scheduled for support, and many of those are features that browsers support without prefixes at all (Opera removes its prefixes when the feature becomes stable enough to be unprefixed, which is the right thing to do).
WebKit browsers don’t remove support for prefixes when they are ready for unprefxing, because they don’t want to break sites. Neither do we.
But your post contains a misconception: “I … don’t think that vendors should be pandering to the needs of bad web developers.”
We’re not. We’re pandering to the needs of our users. They are *a quarter of a billion people* who get ugly or broken sites. But we can easily error correct that, in a non-magic, entirely predictable way, by aliasing some webkit properties.
Bruce, thanks for taking the time to comment.
I agree that removing the prefixes when a feature becomes stable is the right thing to do, naturally this is what all vendors are aiming for.
It’s true vendors can easily correct the “broken sites” for users, but the sites are broken because of the bad developers who didn’t bother to test their site in other browsers.
Also, most of these prefixes only add extra whizziness to sites (I assume – since we haven’t seen a list yet), so all that’s “broken” might be a lack of rounded corners, gradients (which the developer should have provided a fallback colour for) and animations. This is the fault of the developer, not the vendor.
You diagnose the list pretty well!
The most common complaint we got was about sites that had, say, white text on a graient background. The gradient had only -webkit- prefixing and there was no fallback background-color. This meant many buttons etc were white text on a white background. This isn’t a whizziness-deficiency; our customers called it “a broken website in Opera”.
I see your point, and yes, customers will blame Opera which is unfair as it isn’t Opera’s fault it’s the (lazy) developer’s fault for not providing a default background colour!
But because of this I can see why Opera, as a business, has chosen this option. I still don’t agree with it though
Interesting discussion.
Bruce: You say that a quarter of a billion people will get these ugly and broken sites but I’m yet to see hard numbers from any of the vendors on how bad this situation actually is.
I’m in no doubt that some website developers are not using prefixes right but I’d like to honestly know a few things;
1. How many websites are doing this?
2. How many users are *actually* visiting these website (and therefore, being affected)
3. Why is the problem so bad that it’s not worth our time reaching out to these problem websites, or on better education about prefixes?
My concern right now is that it seems these decisions are being made based on the observations of a few ‘broken’ websites and complaints from a selectionn of users. I’m yet to see or hear of these issues myself.
Rob
Rob
Hi Rob, we have numbers and analysis (and so, AFAIK, do you in Firefox).
This Moz site is linked from the A List Apart article with Tantek http://people.mozilla.com/~atrain/mobile/Evangelism/chrome-compare/chrome-compare.html
Here’s another analysis that Firefox did https://bugzilla.mozilla.org/show_bug.cgi?id=708406
I’d like ours to be published, but that’s not my call.
I think the main question is what exactly is broken on these sites? I guess this’ll come to light from (hopefully) a list of what will be supported but does not having a rounded corner really mean a site is broken?
The problem is that prefixed properties are prototype behaviours that can (and do) change frequently. If the Webkit dev team makes a change will this be reflected by Opera? How will they know the full implementation of a prefixed property? The problem this creates is a Webkit led web build and defined towards specific browsers and devices. Again and again, it’s no suprise the (mainly) iPhone owning designers and developers are testing amd building to this first but this high ownership within the industry doesn’t reflect the wider public.
It would help more if Opera put their weight behind getting the CSS working groups to speed up specifications and adoption rather than pave the way toward an uncompetitive web.
Thanks Bruce, the Mozilla bug certainly contains a whole bunch of data but the outcome is still not clear. It’s definitely good research though, over 18,000 websites analysed in some areas.
Regardless of the final decision, we should be more public (all of us) about proving exactly why this is a good idea. It’s such a delicate issue that we can’t afford to just say “because it’s the only way” or something similar.
I’m working to get clarifcation on the Mozilla position on this and hopefully we can try and get some of this research out in a publically-understandable fashion.
While I understand why Opera has taken this decision, I think it’s a bad thing for the Web, and specifically for WODs. To me, it’s like saying “hey you, you’re doing it absolutely wrong, but that’s ok you can continue, we’ll handle that for you”. And what could be the consequence of that ? More and more WODs… Sadly.
I think there are three kind of WOD: the bad developer, who don’t care about user experience, standards, best practices, browser (in)compatibilities & so on; the lazy developer (which is a sort of bad developer); and the developer who is “not aware of”, but in most cases we can’t blame him. And I’m afraid that Opera’s decision will increase the number of bad and lazy developpers, which is never is good thing.
It reminds me the case of HTML tag soup, where each browser can handle bad formatted HTML structure, and here also browsers are saying “ok you’re doing it wrong, but don’t worry we can handle that”. It does not help to have better developpers, but only to lower the barrier to web developpement, which bring more and more bad developpers… And that makes me sad.
Pingback: Bruce Lawson’s personal site : Reading List
What if i developed a page at a time where only a webkit, or firefox, or what ever extension existed?
I might not be responsible for that page anymore, not alive, not using computers, etc.. That page will then, never get updated to support more extensions as they appeared.
I guess that’s why opera goes this route. css that’s out there and that’ll not get updated. Because there’s no lazy developer there: there’s simple none around at all anymore.
A fair point Dave!