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.
Ideally,
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
SNAAAAAAAKE