Extra Extra! Web Developers Jump On 1 Preferred Rendering Engine, Take 2

Well, it’s official: webkit is the new IE.

Back in the so-called Bad Old Days, you built for IE and then if you felt like it, you built for Everyone Else.

Today, everyone has great hatred for IE. The way it didn’t (and still sometimes doesn’t) follow “web standards”, the way it forced many of its proprietary tags/attributes/features onto everyone, the way we’re still dealing with JScript vs Javascript, the way we’re still dealing (sometimes) with people new to web development wondering how they can change the colours of scollbars like they can in IE…

It sure is easy to blame IE, isn’t it? They created all these neat-o (for the times) features, and it was a dominant browser, and everyone piled on. Clients want promised magical features, so developers want features, and features only need enough implementation in the wild to become part of the standard, or at least the “standard” of “what everyone is building”. But who’s fault is it really?

Isn’t it also the fault of web developers deciding they like some vendor-specific feature so much, they are willing to use it (whether it’s experimental or not; whether it’s still in testing phase or not; most importantly, whether there are any plans for anyone else to have that feature or not) to the point that, there are so many implementations in the wild that now all other vendors must deal with it?

You know what the mark of a “hip, modern web page” is? Besides that it’s written more in new Javascript APIs than actual markup, I mean?
The big sign that your site is hip and modern is the “BEST VIEWED IN LATEST WEBKIT” statement you’ve place on there.

Sound familiar?

Well, folks, after the past few years of “mobile? that means webkit!” and iWhatevers claiming the most hype (if not actually the most numbers of actual users/visitors/customers), it seems the other browser vendors have found themselves in a pickle. And it’s because people are building for webkit, the exact same way they used to build for IE. Why is the latter so wrong and horrid while the former is Teh Most Awesome Thing Since Sliced Bread?? I don’t understand. They are both wrong. They both encourage monocultures. Monocultures suck (they are easier to develop for, sure, but they are more vulnerable to security problems and remove user choice, which yes I realise many developers would love to remove user choice, but as a card-carrying hippy I am for user software choice and diversity… am I the only one??).

But so anyway, for those of you who care, here is an interesting discussion that’s going on now: http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html just do a ctrl-f a few times for “vendor prefix” to get to that part of the discussion. Yup, the non-webkits are actually considering adding -webkit vendor prefixes.

Here’s a bit of the beginning for those too lazy to click the link. First, imagine the discussion going on in a secret lair.

That’ll help you stay interested if you’re easily bored.
The bolded emphases are all mine.

Oh yeah, and making UA strings lie (like they always needed to, since developers are sniffing):

Alan: Or are there other complications where they’re doing browser-sniffing
or otherwise wouldn’t work even if you implement these prefixes?
Alan: I’m wondering about the efficacy of implementing webkit prefixes.
tantek: None. We will also need to send a webkit-tricking UA string.
tantek: Just like WebKit sent “like Gecko” in its UA string, we have to do
the same thing again

Yikes. Well. This is what we get for sniffing and blocking. This is what we deserve. However, having seen instances where sniffing (for Device mostly) was the only reasonable option for something mobile, this tells me we have a bigger problem. Our servers need to know more of certain things, and the UA needs to send this info on first request.
And yet, anything anyone develops will immediately be compromised by the same people coming to these forums and going on Stack Overflow and Quora and other places asking “how can I write just for Browser X” or, what’s more fashionable nowadays, “how can I write just for iDevice version X?”

So long as we insist on writing per device, per UA, per some-feature-nobody-else-even-has, the more the reliability of detection goes down the drain.

Some people believe vendor prefixes are evil in and of themselves and we should get rid of them. But instead I agree with whoever it was (Meyer? I know others also agree with having prefixes) who pointed out that having vendor prefixes when any particular feature is still being tested, and not yet ironed out is great, since once the browser can deal with the feature correctly and natively, then any (possibly/likely buggy) vendor-specific implementations can be easily left out.
The option to not being able to leave out vendor prefixes because the vendor has a sh*tty implementation? That’s right, hacks. Lots and lots of juicy, fugly, likely-to-break-when-the-next-version-comes-out-in-6-weeks hacks. And now that the average web page, even the simple ones, have multiple javascripts, multiple stylsheets (possibly not even written in real CSS but any of the hipster pre-processors, meaning m0aR files), that means we as visitors to any particular website get the joy of bandwidth-sucking extra bloat-code in the form of hacks. Yay. And more maintenance work for us as developers. Yay yay.

Now imagine webkit implements something new and crappy. It won’t be crappy when they finally get it right, but initially, it’s crappy (let’s say, due to a webkit-specific bug… lord there are plenty of those). Meanwhile, Mozilla and Opera manage to implement the same feature and it’s way less crappy because they don’t have the webklit bug.

With vendor extensions, you could test out the new feature just for the ones who Got It Right (here, Mozilla and Opera), and leave out the -webkit version because it’s hairy donkey balls. And vice-versa: a working -webkit something that breaks in Mozilla due to a Gecko bug (lord knows there are plenty of those), same thing. Great, use the -webkit version and leave the -moz version out until they get their sh*t together. This is all great and wonderful

and little forest creatures gather around the white beautiful young singing heroine in sympathy for her horrid fairy-tale plight

while multicultural children hold hands in a circle around her and sing kum-ba-ya…

but now if -webkit-badassery-level: awesome++; starts (sorta) working in IE, now what? Yes, we are all screwed. Or, I mean, we lose the probably single redeeming value of vendor-specific prefixes, don’t we? We might as well go back to no prefixes and just let everyone send out their buggy implementations and let us do dirty dubstep hacks around it like we did in the Good Bad Old Days.

Remember these? Were they not fugly?

Why do we want them back? Do we?

So I ask: maybe, just maybe, we as web developers should stand up and take a little responsibility? Maybe we shouldn’t just blab about progressive enhancement or feature-detection. Maybe we shouldn’t let our employers put out job ads stating things like “cross-browser” and “web standards” when those don’t even mean anything. How about we either put our code where our mouths are, and stop trying so hard to break the web to make some Apple-drooling corporate customer happy cause now he can see his FaceSpace iWhatever App thingie yay, OR we should just stop lying to each other about following these so-called web standards and just be brutally honest with everyone else:
We don’t write for older browsers, we don’t write for non-Apple mobile devices, we don’t actually do that progressive-enhancement thing, and we sniff UAs because it’s freaking awesome and lets us send one set of code to iPhone 4’s and another set to iPad2’s. Back in the CSS War Room, this is what the numbers are showing.

And then when UA sniffing stops working because everyone’s UA string is going to claim it’s “Apple Webkit Something Something”, we’ll whine and b*tch and complain about not being able to send out our specific version of code. (instead of, I dunno, lobbying that the vendor with the offending code fix it right away? or, if we’re C++ devs, fixing it ourselves?)

Because right now, we are encouraging that “breaking the web” thing everyone’s always whining about. We’re breaking it in favour of webkit today, and who knows what tomorrow. If we can’t trust vendor-specific prefixes to be vendor-specific, then they are broken and we might as well get rid of them entirely.

yeah, ideally,

(uh-oh, there’s that hippie left-wing rhetoric that reminds us of Utopia, lawlz)

new features would be looked at by all vendors and bugs and implementation ideas worked out and then added to the standard, so that it’s in the specs and we can all use them correctly and other vendors can look up how to implement it correctly and everything can be happy unicorn puke and double rainbows.

unicorn puke++

The browser vendors are just reacting to what we do on the web. Guess what? There are a crapload more of us than there are of them. Who has the power here? I mean, yeah, it’s fun to blame Apple or webkit but that’s like blaming IE for our earlier behaviour isn’t it? Or we can just blame uneducated clients demanding stupid things… stupid things some developer promised them. Or, I dunno, doesn’t every web developer out there have a blog about nothing somewhere nowadays? Didn’t they all rally around stopping that sh*tty SOPA law just a month ago (after that, everyone was happy cuz like, “teh evil SOPA is gone and now we can go back to our entertainment cuz it’s not like there aren’t 5 other bills doing the same thing as SOPA except we don’t care” blah blah)? If we’re done patting our backs for that, why not a similar effort to spread the word and convince web developers to watch what they’re doing when throwing all these -webkit-this and -webkit-that all over the place??

Otherwise, the War Room’s gonna do one of these

Yeeeeeeeeeee haaaaaaaaaawwwww!! -webkit-webkit-webkit-webkit
badger badger badger badger
mushroom mushroom
badger badger badger badger

Nice post, poes. Crikey, if the other browser vendors are thinking like that, why don’t they just quit and admit defeat?

Just a couple of small things.

  1. This instantly reminded me of PPK’s vendor prefix article from 2010. His actual stance (abolish all vendor prefixes) (at least, that’s the stance in that one article) is less important than this terrifying/hilarious snippit:

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?


  1. Playing devil’s advocate, doesn’t the new approach to updating mean that it’s a little better than it was with IE? We still (depending on the project, of course) need to test our sites in IE6, more than a decade after it was released.

On the other hand, Chrome 4 (which came out less than two years ago) had no support for inline SVG. But when people bemoan the fact that we still can’t embed SVG straight into our HTML, which browser(s) are they probably talking about? (Okay, so it’s a contrived example :confused: )

Bugs, mistakes, and failed ideas never, ever go away on the Internet. But this new automatic, behind-the-scenes, nigh-unstoppable update scheme seems to minimize their effect, doesn’t it?

But this new automatic, behind-the-scenes, nigh-unstoppable update scheme seems to minimize their effect, doesn’t it?

For Grandma? Maybe. For those browsers who do update every 15 seconds. Which IE doesn’t.

For enterprise? Those who went boldly and left IE for Firefox have started coming back to true old IE, simply because sysadmins revolt against the idea of adminning 1000’s of machines every 6 weeks because Mozilla sez “yo dawg we heard you like apps…”

It’s hard enough work clamping those browsers down by hand so the users don’t click on those stupid shoot-the-monkey, win-the-boobs sidebar flash games and download craploads of virusses… got IE? Dayum, that shizzle can stay on your systems for decades. Lawlz.

But yeah that might be a saving grace: if this decision were temporary enough that newer browsers would replace this duct-tape idea. You can see from the csswg record that some believe this will haunt us for decades… like that great-aunt we offed for the insurance money whose poltergeist keeps throwing things at the new baby

the same way all browsers also admitted defeat when IE managed to win the internetz and kill off netscape?

why is there this lazy obsession from certain developers that all browsers should just use the same engine (and just looking at webkit-specific fragmentation, even that isn’t the be all and end all)? sigh…

More PPK goodness: The Great WebKit Comparison Table

On this page I compare 21 WebKits in order to prove that there is no “WebKit on Mobile”…

Back in the so-called Bad Old Days, you built for IE and then if you felt like it, you built for Everyone Else.

Makes sense to me, they were building for the vast majority of their users first.

I agree with you that building for Chrome and then complaining about the rest is a trend that is becoming more prominent and those developers need reminding to build stuff for users and not browsers.

Opera is the little guy who will most likely miss out, lucky for him he gets it right nearly always so if you build things correctly you shouldn’t have to do too much extra.

Web standards won, things should work in FF, Chrome, Safari, Opera, IE9+
IE6-8 should also work if the user share warrants it (which it does)

Opera is the little guy who will most likely miss out, lucky for him he gets it right nearly always so if you build things correctly you shouldn’t have to do too much extra.

Opera is the one fretting the most (see comments by Florian in the link… represents Opera). Mobile is their big market, and webkit is their largest competitor really (leaving out that big proxy browser that almost controls China).


Where’s the T-shirt? Or Occupy Webkit tents.

For the too-lazy-to-click (bold mine, ellipses where I’ve removed stuff):

That’s us. Ya’ll do that social-media whatsit stuff, right? Spread the word. Fix your sites. Stop offering your customers an “iWhatever app” automatically instead of seeing if a responsive web site for ALL browsers/devices would work better (even if utlimately, then does end up being your client’s best solution… at least you considered other possibilities). Edjumacate your clients that mobile != iPhone/Pad.

Occupy Webkit
Opera. Code for the 1%

Remy Sharp’s take: http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/

tl;dr: “Bat sh*t crazy.”

One valid option is to use just use Compass’ CSS3 modules.

.magic   {
  @include border-radius(4px);

What would be nice is if instead of creating all these vendor prefixes in their rendering engines, IF THEY ACTUALLY IMPLEMENTED THE FEATURE WITHOUT THE PREFIX.

Of course, that would require the spec to be clear on how a feature needs to be implemented and that all browser vendors all implement it the same way. You know, so we don’t end up with 4 different ways to do transitions.

In the immortal words of someone on my twitter feed:

[I]OH: “That’s why we call it a ‘Spec’, because we 'spect it to work that way.”

[/I]Now, I’ll be the first to admit that I use these vendor prefixes for a bunch of features (border-radius repeated a bazillion times, anyone?). But I do try to be as inclusive as possible here. (i.e. use -webkit -moz -ms -o and of course one last entry without the prefix)

I was going to make a further point, but I forgot. I think it may have had something to do with vendor prefixes starting out as implementations of things that are not yet in the spec or are experimental or something. Maybe someone (who is more knowledgeable than me in this area) can elaborate on that?

Certainly if you’re using any of the preprocessors that do this, there is zero excuse to be only writing -webkit prefixes… except when you are using one that only exists as -webkit in the first place.

In other words, everything I’ve been saying the past SIX YEARS… the saying about “those who forget history” is cute, but it’s outright depressing to see it in action. Deploying draft specifications in incomplete implementations? Browser specific code? Implementing new ‘standards’ before the old ones are even completely implemented?

As I’ve said a billion times here, “What is this, 1998?!?”

Though I’m starting to think that’s unfair – to 1998… as for me at least, the web was more useful THEN than it is now. All those wonderful new tools and specifications that were supposed to make it more usable, has been abused by people who have no business even making websites to the point that many sites I used to visit every day, I’ve stopped visiting due to jumping the gun on idiocy like HTML 5, bloating out the pages for nothing with broken/half-assed scripting, and letting the PSD jockeys piss away all the bandwidth. (or in the case of jquery/mootools, completely-assed scripting)

You’ve been saying stuff? Whoops, I cleared my browser cache and erased my memory :stuck_out_tongue:

I’m going to try to paraphrase you in the next project I work on that has some ridiculous design. I work in advertising, so that should be fairly soon.

It’s funny actually, his are the views that got me to join the forums. It’s nice to have a voice for minimalism and functionality to think on as a reminder of some of the reasons why the types of behavior this thread talks about should be professionally abhorrent. Especially when so many people around the web have a tendency to want to code on the “cutting edge” even though users/readers don’t actually care to the extent that it doesn’t really improve anything for them.

Or worse, makes it less useful – see jQuery for nothing, AJAX for nothing, and massive code bloat resulting in broken layouts, inaccessible layouts, broken keyboard navigation, pages that don’t even TRY to be accessible… we’ve been given all these tools and given tons of recommendations – HTML itself is a very SIMPLE specification if you take more than half a second to try and understand it and SHOCK bother to learn ALL the tags…

But you still get people using tables for layout, blissfully unaware of half the tags that should be in tables or forms when using them properly – we’re still dealing with browser makers who are rushing into new DRAFT specifications when they still have decade plus old gaping holes in the old ones – we have people writing PHP who don’t even understand HTML, which is what it’s supposed to output – at which point what in blue blazes qualifies them to do a blasted thing in PHP?

I keep saying “setting it back a decade or more” – maybe that’s not an accurate assessment either since it seems like the majority of developers out there and resources for nubes to learn from have never actually pulled their collective heads out of 1998’s tuchas.

See HTML 5 – welcome to 1998. Mr. Peabody and his boy Sherman would be proud.

Just remember the number one thing you have to tell the art f… art f… art folks…


I wish I had a gold medal for every time I said that around here. You wouldn’t believe (well, maybe you would) some of the crap that comes across my desk.

Anyone want to take bets on how many times I’ve been asked if we can do video in email?

You can complain all you like but reality is no one is going to change what they are doing.