The long-standing difficulties of styling
legend are finally getting addressed …although I’m a little shocked that the solution involves extending
-webkit-appearance. I think that, at this point, we should be trying to get rid of vendor prefixes from the web once and for all, not adding to them. Still, needs must, I suppose.
Tuesday, September 25th, 2018
The long-standing difficulties of styling
Tuesday, July 17th, 2018
Rachel follows up on my recent post about CSS grid in old IE with her thoughts.
As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.
Friday, July 13th, 2018
CSS grid in Internet Explorer 11
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
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.
Monday, September 12th, 2016
Bookmark this page! Who knew that so much knowledge could be condensed into one document? In this case, it’s life-saving
git commands, explained in a user-centred way.
So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english.
Tuesday, April 26th, 2016
Ted has snuck a blog post out from behind Apple’s wall of silence, and it’s good news: WebKit is not going to use vendor prefixes for new features.
Tuesday, August 25th, 2015
Alex recounts the sordid history of vendor prefixes and looks to new ways of allowing browsers to ship experimental features without causing long-term harm.
Monday, August 4th, 2014
One more reason why you should never sniff user-agent strings: Internet Explorer is going to lie some more. Can’t really blame them though—if developers didn’t insist on making spurious conclusions based on information in the user-agent string, then browsers wouldn’t have to lie.
Oh, and Internet Explorer is going to parse -webkit prefixed styles. Again, if developers hadn’t abused vendor prefixes, we wouldn’t be in this mess.
Tuesday, May 8th, 2012
Proposition to change the prefixing policy from Florian Rivoal on 2012-05-04 (email@example.com from May 2012)
This seems like a sensible way for browsers to approach implementing vendor-prefixed CSS properties.
Thursday, March 15th, 2012
South by CSS
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.
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
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.
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:
- Something must be done!
-webkitprefixes is something.
- 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?
-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?”
Wednesday, March 7th, 2012
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.
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.
- Prefixes are not developer-friendly.
- Recent features would have been in a much better state without prefixes.
- 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.
Friday, November 18th, 2011
Alex weighs in on the newly-reopened debate on vendor prefixes, roundly squashing Henri’s concerns.
Wednesday, November 16th, 2011
Daniel responds to Henri’s call-to-arms on vendor prefixes. While he stridently disagrees with most of what Henri suggests, there is also overlapping agreement: they both want vendor prefixes to ship only in experimental builds, not stable browser releases.
Tuesday, November 15th, 2011
This is a very thoughtful piece by Henri on vendor prefixes and it’s well worth a read …however the thought of one browser implementing support for vendor-prefixed properties intended for a different browser does make me quite quesy.
Tuesday, July 6th, 2010
An excellent argument in favour of vendor prefixes in CSS, from Eric.