Friday, April 27, 2012

Don't Blame Opera, Blame Devs

Opera logo merged with Safari logo.On Wednesday news broke that Opera was going to support some Webkit CSS vendor prefixes. On its surface I thought this wasn't exactly big news. There was a good deal of hubbub about this back in February (Browser Makers Caving to Vendor Prefix Misuse) when word got out that Mozilla, Opera and Microsoft were all considering supporting the -webkit prefix.

Many standards-focused developers (including me) were horrified, even though this has been a concern for over two years (as I note in Perplexing Prefixes). Some of them even took action to either convince developers to fix their code, get like-minded developers to fix others' code, or petition browser makers not to cave.

I think it's fair to say that the first two tactics haven't worked. In light of that, it was just a matter of time before the browser makers would start supporting the dominant codebase — even if it's only dominant because of developer misuse.

Now Opera is catching a lot of heat from people for caving. Some are pointing to Microsoft's statement that it won't support the -webkit prefix as an example of how not to play the game. Others feel betrayed that Opera, often the most standards-compliant of all the browsers, would now make such a move. Few of these people consider the business case for Opera. Opera has dominated the mobile market, and when web sites don't render properly — because of a developer who is either not coding to standards or is not including the -o prefix alongside the -webkit prefix — users may move to the browser that doesn't look broken. Opera is making a business decision to protect itself.

Wednesday on Twitter I placed the blame at the feet of lazy web developers. I still feel that way. My previous posts on this topic have been clear on this. If web developers took the time to learn the specifications, look at code generated by editors (if they use them), tested in other browsers, and shed their myopic view of how people surf, we would not be in this position. Developers can fix the code, see errors when testing, and otherwise not cut corners. I suspect there are lots of developers who know this and lots more who can be educated by the names and voices on the web now.

And then I saw this, retweeted by Zeldman, possibly in a show of support:

If her percentage is not hyperbole and applies to all the sites she manages, then the time it took her to see those numbers and produce that tweet is about how long it takes to open Opera and paste in a web address.

This is why the browser makers are caving. This attitude is pervasive. Hers is just one example. I have seen similar comments around the web, ranging from those who have no idea what browsers visit their sites to those who just don't care. Telling someone they are wrong, myopic, and definitely not serving the needs of their users, clients, or even the rest of the web, just causes that person to ignore you or lash out.

You can run the math yourself using the percentage in the tweet. Take a site with a million visitors and you'll see that 0.3% is 3,000 users. In accessibility circles, that's an unacceptable number of users to shut out. Imagine 0.3% is an acceptable number to ignore on a larger site, perhaps even as big as Facebook with 800 million users. At 0.3% that's 2.4 million users. At what number of users is 0.3% acceptable? How many developers of large sites feel bolstered by such an attitude, reinforcing their own poor habits?

The question to web developers really should be, how many users are you willing to sacrifice because you are too lazy to open a browser and at least look?

This example of webs.com shows that just opening the home page in Opera would have shown it's broken, meaning either they didn't look or they don't care. In Opera it looks like this (as compared to Safari), hiding its main sales pitch (the issue starts at line 86 of the webs.com CSS file):

Screen shots of webs.com as seen in Opera and Safari.

There just isn't an excuse. Stop blaming the browsers and the editors and instead review your code and test in browsers.

Related

Posts that pre-date this news from Opera:

And a post that pre-dates all of this stuff:

Update 11:40am

Opera has posted the announcement about the vendor prefix changes: Opera Mobile Emulator build with experimental WebKit prefix support. If you read through it, you will see only 13 -webkit properties (shadow, transform, border, transition) which are just being aliased to existing -o prefixes. It looks like Opera is not trying to mimic how Webkit renders the styles, only map the prefixes to Opera's existing support.

Update April 30, 2012

More posts and articles have surfaced over the weekend and today. I link them here:

Update May 2, 2012

Update July 6, 2012

Thiemo Mättig tried to comment below, but had trouble with the form. He let me know that he reached out to Webs.com to notify them of the bad CSS I mention above. All Webs.com did was add a solid background color, no -o- prefix and no unprefixed version.

6 comments:

  1. The only alternative that Opera had to using someone else's prefix was to drop the prefix altogether, which would have been a considerably worse idea, as some of the arguments of CSS properties may still change, like the gradient arguments changed a while back.

    Some sites look worse on Opera simply because a lot of front-end developers don't care about it, not because they are behind the curve in terms of standards support, and that is unfair for both Opera and its users.

    I don't think this decision could have been made lightly, because right now Opera has compromised itself to behaving and acting exactly like Webkit browsers, rather than trying to follow the standards specification. If those two coincide, then there won't be any issues for users, but...

    If things start rendering differently on Opera, they will have to try to make it as close to Webkit as possible, rather than as close to the spec, and that may be bad, but that is in a possible future, not in the present. Right now, this decision makes sense, and I'm glad someone was able to explain why in such a concise way.

    ReplyDelete
  2. Marco, what I like about Opera's approach is that it isn't trying to mimic Webkit's rendering of the 13 prefixed styles, it's just mapping those prefixes to Opera's own existing prefixes. Users may not get exactly the same appearance as Webkit users, but at least they get something (which would be handy in my webs.com example above).

    ReplyDelete
  3. The prefixes they are adopting are relatively harmless, even if there are differences they shouldn't impact sites too much. A lot of people are blowing it out of proportion.

    I still hope the differences aren't too high, because the people that neglected Opera will take any and every chance they can to discredit them and stop supporting them.

    This decision might have been the most technically-sound one, but in terms of PR they're going to need some time to mend these wounds.

    ReplyDelete
  4. I don't mind if browsers check for prefixed properties (in a generic way), but I completely disagree if they decide to check only webkit prefixed properties.

    ReplyDelete
  5. I suspect that Opera is reacting to the dominant prefix, which doesn't make it right or ideal, just pragmatic.

    ReplyDelete
  6. Wow, that womans tweet is completely disgusting. She's the kind of "developer" the world could do without, she's the kind that causes these problems, it's thanks to people like her that Opera had to do this... She's a complete moron....

    ReplyDelete