Journal tags: prefixes

Vendor prefixes didn’t work. The theory was sound. It was a way of marking CSS and JavaScript features as being experimental. Developers could use the prefixed properties as long as they understood that those features weren’t to be relied upon.

That’s not what happened though. Developers used vendor-prefixed properties as though they were stable. Tutorials were published that basically said “Go ahead and use these vendor-prefixed properties and ship it!” There were even tools that would add the prefixes for you so you didn’t have to type them out for yourself.

Browsers weren’t completely blameless either. Long after features were standardised, they would only be supported in their prefixed form. Apple was and is the worst for this. To this day, if you want to use the clip-path property in your CSS, you’ll need to duplicate your declaration with -webkit-clip-path if you want to support Safari. It’s been like that for seven years and counting.

Like capitalism, vendor prefixes were one of those ideas that sounded great in theory but ended up being unworkable in practice.

Still, developers need some way to get their hands on experiment features. But we don’t want browsers to ship experimental features without some kind of safety mechanism.

The current thinking involves something called origin trials. Here’s the explainer from Microsoft Edge and here’s Google Chrome’s explainer:

• Developers are able to register for an experimental feature to be enabled on their origin for a fixed period of time measured in months. In exchange, they provide us their email address and agree to give feedback once the experiment ends.
• Usage of these experiments is constrained to remain below Chrome’s deprecation threshold (< 0.5% of all Chrome page loads) by a system which automatically disables the experiment on all origins if this threshold is exceeded.

I think it works pretty well. If you’re really interested in kicking the tyres on an experimental feature, you can opt in to the origin trial. But it’s very clear that you wouldn’t want to ship it to production.

That said…

You could ship something that’s behind an origin trial, but you’d have to make sure you’re putting safeguards in place. At the very least, you’d need to do feature detection. You certainly couldn’t use an experimental feature for anything mission critical …but you could use it as an enhancement.

And that is a pretty great way to think about all web features, experimental or otherwise. Don’t assume the feature will be supported. Use feature detection (or @supports in the case of CSS). Try to use the feature as an enhancement rather than a dependency.

If you treat all browser features as though they’re behind an origin trial, then suddenly the landscape of browser support becomes more navigable. Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”

You can also do it for well-established features like querySelector, addEventListener, and geolocation. Instead of assuming that browser support is universal, it doesn’t hurt to take a more defensive approach. Assume nothing. Acknowledge and embrace unpredictability.

The debacle with vendor prefixes shows what happens if we treat experimental features as though they’re stable. So let’s flip that around. Let’s treat stable features as though they’re experimental. If you cultivate that mindset, your websites will be more robust and resilient.

When I was in Boston, speaking on a lunchtime panel with Rachel at An Event Apart, we took some questions from the audience about CSS grid. Inevitably, a question about browser support came up—specifically about support in Internet Explorer 11.

(Technically, you can use CSS grid in IE11—in fact it was the first browser to ship a version of grid—but the prefixed syntax is different to the standard and certain features are missing.)

Rachel gave a great balanced response, saying that you need to look at your site’s stats to determine whether it’s worth the investment of your time trying to make a grid work in IE11.

My response was blunter. I said I just don’t consider IE11 as a browser that supports grid.

Now, that might sound harsh, but what I meant was: you’re already dividing your visitors into browsers that support grid, and browsers that don’t …and you’re giving something to those browsers that don’t support grid. So I’m suggesting that IE11 falls into that category and should receive the layout you’re giving to browsers that don’t support grid …because really, IE11 doesn’t support grid: that’s the whole reason why the syntax is namespaced by -ms.

You could jump through hoops to try to get your grid layout working in IE11, as detailed in a three-part series on CSS Tricks, but at that point, the amount of effort you’re putting in negates the time-saving benefits of using CSS grid in the first place.

Frankly, the whole point of prefixed CSS is that is not used after a reasonable amount of time (originally, the idea was that it would not be used in production, but that didn’t last long). As we’ve moved away from prefixes to flags in browsers, I’m seeing the amount of prefixed properties dropping, and that’s very, very good. I’ve stopped using autoprefixer on new projects, and I’ve been able to remove it from some existing ones—please consider doing the same.

And when it comes to IE11, I’ll continue to categorise it as a browser that doesn’t support CSS grid. That doesn’t mean I’m abandoning users of IE11—far from it. It means I’m giving them the layout that’s appropriate for the browser they’re using.

Remember, websites do not need to look exactly the same in every browser.

South by Southwest has become a vast, sprawling festival with a preponderance of panels pitched at marketers, start-ups and people that use the words “social media” in their job title without irony. But there were also some great design and development talks if you looked for them.

Samantha gave a presentation on style tiles, which I unfortunately missed but I’ll be eagerly awaiting the release of the audio. I also missed some good meaty JavaScript talks but I did manage to make it along to Jen’s excellent introduction to HTML5 APIs.

Andy’s talk on CSS best practices was one of the best presentations I’ve ever seen. He did a fantastic job of tackling some really important topics. It’s a presentation (and a presenter) that deserves a wider audience, so if you’re involved in putting together the line-up for any front-end conferences, I highly recommend that you nab him.

Divya put together an absolutely killer panel called CSS.next, all about how CSS gets specced and shipped, and what’s coming down the line. All of the panelists were smart, articulate, and well-informed. The panel was very enlightening, as well as being thoroughly enjoyable.

And then there was the Browser Wars panel.

This is something of a SXSW tradition. Arun assembles a line-up of representatives from browser makers—Mozilla, Google, Microsoft, and Opera—and then peppers them with some hardball questions. Apple is invited to send a representative every year, and every year, Apple declines.

There was no shortage of contentious topics this year. The subject of Google Dart was raised (“Good luck with that,” said Brendan). There was also plenty of discussion about the recent DRM proposal submitted to the HTML working group. There was a disturbing level of agreement amongst all the panelists that some form of DRM for video was needed because, hey, that’s just the way things go…

As an aside, I must say I found the lack of imagination on display to be pretty disheartening. Two years ago, Chris was on the Browser Wars panel representing Microsoft, defending the EOT format because, hey, that’s just the way things go. Without some form of DRM, he argued, we couldn’t have fonts on the web. Well, the web found a way. Now Chris is representing Google but the argument remains the same. DRM, so the argument goes, is the only way we’ll get video on the web because that’s what the “rights holders” demand. And yet, if you are a photographer, no such special consideration is afforded to you. The img element has no DRM and people are managing just fine, thank you. Video, apparently, is a special case …just like fonts. ahem

Anyway…

The subject of vendor prefixes also came up. Specifically, the looming prospect of non-webkit browsers parsing -webkit prefixed properties was raised.

I saw a pattern amongst all three subjects: the DRM proposal, Dart, and browsers implementing another browser’s vendor prefix. All three proposals were made to address a genuine problem. The proposals all suffer from varying degrees of batshit craziness but they certainly galvanised a lot of discussion.

For example, Brendan said that while Google Dart may not stand a hope in hell of supplanting JavaScript, some of the ideas it contains may well end up influencing the development of ECMAScript.

Similarly, Mozilla’s plan for vendor-prefixing certainly caused all parties to admit the problem: the W3C was moving too slow; Apple should have submitted proprietary properties for standardisation sooner; Mozilla, Microsoft, and Opera should have been innovating faster; and web developers should have been treating vendor-prefixed properties as experimental features, not stable parts of a spec.

So the proposal to do something batshit crazy and implement -webkit-prefixed CSS properties has actually had some very positive effects …but there’s no reason to actually go ahead and do it!

I tried to make this point during the audience participation part of the panel, but it was like banging my head against a brick wall. Chaals kept repeating the problem case, but I wasn’t disputing the problem; I was trying to point out that the proposed solution wouldn’t fix the problem.

It was a classic case of the same kind of thinking we saw in the SOPA proposal:

1. Something must be done!
2. Implementing -webkit prefixes is something.
3. Something has been done.

The problem is that it won’t work. Adding “like Webkit” to the user-agent string will probably have much more of an effect and frankly, I don’t care if any of the browsers do that. At this point, a little bit more pissing into the bloated cesspool of user-agent strings is hardly going to matter. A browser’s user-agent string isn’t an identifier, it’s a reverse-chronological history of the web. Why not update the history booklet to include the current predilection amongst developers for Webkit browsers on mobile?

But implementing -webkit vendor prefixes? Pointless! If a developer is only building and testing their sites for one class of device or browser, simply implementing that browser’s prefixed CSS is just putting a band aid on a decapitation.

So I was kind of hoping that Mozilla would just come right out and say that maybe they wouldn’t actually go ahead and do this but hey, look at all the great discussion it generated (just like Dart, just like the DRM proposal). But sadly, no. Brendan categorically stated that the proposal was not presented in order to foment discussion. And in follow-up tweets, he wrote that he actually expected it to level the mobile browser playing field. That’s an admirably optimistic viewpoint but it’s sadly self-delusional.

And what will happen when implementing -webkit prefixes fails to level the playing field? We’ll be left with deliberately broken browsers.

Once something ships in a browser, it’s very, very hard to ever remove it. During the Dart discussion, Chris talked about the possibility of removing Dart from Chrome if developers don’t take to it. Turning to the Microsoft representative he asked rhetorically, “I mean, do you guys still ship VBScript?”

The answer?

“Yes.”

A year and a half ago, Eric wrote a great article in A List Apart called Prefix or Posthack. It’s a balanced look at vendor prefixes in CSS that concludes in their favour:

If the history of web standards has shown us anything, it’s that hacks will be necessary. By front-loading the hacks using vendor prefixes and enshrining them in the standards process, we can actually fix some of the potential problems with the process and possibly accelerate CSS development.

So the next time you find yourself grumbling about declaring the same thing four times, once for each browser, remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in comparison to the disease it prevents.

Henri disagrees. He wrote a post called Vendor Prefixes Are Hurting the Web:

In practice, vendor prefixes lead to a situation where Web author have to say the same thing in a different way to each browser. That’s the antithesis of having Web standards. Standards should enable authors to write to a standard and have it work in implementations from multiple vendors.

Daniel Glazman wrote a point-by-point rebuttal to Henri’s post called CSS vendor prefixes, an answer to Henri Sivonen that’s well worth a read. Alex also wrote a counter-argument to Henri’s post called Vendor Prefixes Are A Rousing Success that echoes some of the points Eric made in his ALA article:

The standards process needs to lag implementations, which means that we need spaces for implementations to lead in. CSS vendor prefixes are one of the few shining examples of this working in practice.

Alex’s co-worker Paul disagrees. He recently wrote Vendor Prefixes Are Not Developer-friendly:

1. Prefixes are not developer-friendly.
2. Recent features would have been in a much better state without prefixes.
3. Implementor maneuverability is not hampered without prefixes.

All of this would have remained a fairly academic discussion but for a bombshell dropped by Tantek at a face-to-face meeting of the CSS Working Group in Paris:

At this point we’re trying to figure out which and how many -webkit- prefix properties to actually implement support for in Mozilla.

The superficial issue is that web developers have been implementing -webkit- properties without then adding the non-prefixed standardised version (and without adding the corresponding prefixes of other vendors). The more fundamental problem is that while vendor prefixes were intended to introduce experimental features until those features became standardised, the reality is that the prefixed version ends up being supported in perpetuity. Nobody is happy about this situation but that’s the unfortunate reality.

Among the unhappy voices are:

• Bruce who wrote On the Vendor Prefixes Problem,
• Aaron who wrote This Must Not Happen!,
• Remy who wrote Vendor Prefixes — about to go south,
• Rachel who wrote a Call for action on Vendor Prefixes on the WaSP blog, and
• Daniel once more entered the fray, writing Call For Action: The Open Web Needs You Now.

Once again, Eric sought to bring clarity to the situation in the form of an article on A List Apart, this time publishing an interview with Tantek. Alex also popped up again, writing a post called Misdirection which addresses what he feels are some fundamental assumptions being made in the interview.

Finally, Mozilla engineer Robert O’Callahan—who I chatted with briefly at Kiwi Foo Camp about the vendor prefix situation—wrote about Alternatives To Supporting -webkit Prefixes In Other Engines in which he makes clear that evangelism efforts like Christian’s, while entirely laudable, aren’t a realistic solution to the problem.

It’s all a bit of a mess really, with lots of angry finger-pointing: at Apple, at Mozilla, at web developers, at the W3C…

My own feelings match those of Eric, who wrote:

I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. … I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship.