Reading List – Vendor prefixes, mobile, monoculture

The first reading list of 2012 is themed, rather than the usual miscellany. It’s about the Open Web and the dangers it faces.

I’ve nailed my colours to the mast – most lately in The Pastry Box:

The Web is about communication. It connects many people who previously were isolated such as those with disabilities or those in oppressive regimes. It’s a World-Wide Web, not a Wealthy Western Web. If your super-clever site only works with a mouse and monitor, on the latest $2000 super-spec laptop, with a fat broadband connection, you’re missing the point.

The ideal of universality is fundamental to the Web. Some bloke called Tim said

The principles of universality of access irrespective of hardware or software platform, network infrastructure, language, culture, geographical location, or physical or mental impairment are core values in Web design.

One of the most worrying trends we see at the moment is the erosion of this idea. In a survey, Peter-Paul Koch asked "Do you hope that WebKit will become the only rendering engine, and that the others will gradually disappear?". Shockingly, 32% have replied “yes” (at time of writing). You read that correctly! 32% actively wish for a monoculture. Because, y’know, cross-browser development is hard – so let’s go shopping! Who cares about the users? Who cares about the future? We’ve been here before with IE6- the darling of developers at the time – and look how well that went.

It’s pretty obvious that this is a case of a group of developers that believes that everyone should be just like them and should use the same devices and browsers. After all, despite all their genuflecting to Safari on their iPhones, it appears from December’s mobile statisitics (as written up by PPK) that

Opera once more overtakes Safari. It’s clear now that Android’s untrammeled growth has ended, and that the race for first position will continue to be between Opera and Safari.

(If you’d like to start testing your sites in the number one mobile browser, there are plenty of Opera testing tools available. Note: Opera is my employer, but this is my personal opinion.)

Stephanie Rieger writes in A plea for progressive enhancement

we have to start building sites using solid, future friendly principles such as progressive enhancement…not just when it’s handy or simple, but all the time.

and goes on to show a Barack Obama re-election site in which it was impossible to navigate in many devices, even some new high-spec devices. In a news report about this, the journalist quotes my three incredibly ground-breaking, never-before-heard rules:

Yes, I know! Utterly new concepts.

However, we’re approaching a monoculture on mobile. This is not the work of an evil organisation, but it’s developer-constructed. Few people are stupid enough to use Olde-Skool browser sniffing and blocking, but we’re seeing lots of people breaking cross-browser compatibility by neglect rather than design.

One way this happens is developers using only one vendor’s CSS vendor prefix even when other vendors support the same properties. Of course, for experimental things only implemented by one rendering engine, that’s fine. That’s what vendor prefixes are for.

The trouble comes about when people do something like -webkit-transition for widely-supported properties, without the corresponding -o- for Opera, -ms- for Microsoft and -moz- for Mozilla.

Last week, Mozilla developer Boris Zbarsky wrote

People never aim to create content that’s cross-browser compatible per se, with a tiny minority of exceptions. People aim to create content that reaches users. What that means is that right now people are busy authoring webkit-only websites on the open web because they think that webkit is the only UA that will ever matter on mobile. And if you point out this assumption to these people, they will tell you right to your face that it’s a perfectly justified assumption. The problem is bad enough that both Trident and Gecko have seriously considered implementing support for some subset of -webkit CSS properties.[my emphasis]

Three years ago, David Baron (also of Mozilla) wrote Should implementors copy vendor prefixes from each other?, and in 2010 Microsoft announced that it would support -webkit- prefixes, but eventually decided against it.

Since then, we’ve had many more debates about the merits of vendor prefixes (see previous reading list), and even the co-chair of the CSS Working Group, Daniel Glazman, wrote

The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web.

I believe vendor prefixes were a good idea, and remain so if used in a cross-browser, future-proof way. But because so many people only use the -webkit- one, I’m starting to wonder too if vendor prefixes should be considered harmful

30 Responses to “ Reading List – Vendor prefixes, mobile, monoculture ”

Comment by Matt Wilcox

This is not a technology problem, it’s an education problem. I am vehemently against neutering capabilities of languages simply because bad authors can mis-use them. Following that logic to its conclusion means never adding new technology because it can always be mis-used. Stagnation, in other words. It’s the “authors don’t need variables in CSS” argument, in different clothes.

Get people educated. Press the vendors to include notes that competitor vendor implementations are available in their own documentation. Call out magazine articles that only use one prefix – no matter how convenient that is to the author. It’s harmful to the reader who may easily miss the distinction between example code and production code and simply copy verbatim.

Educate, educate, educate.

Comment by Molly E. Holzschlag

It’s both a technology problem and education problem. Vendor prefixes, like many things, have been morphed into a covert way to put features into a browser in a non-standard way. To implement this stuff is certainly a vendor’s right, however, it is not in the spirit of the Web and that is the core of the technology problem.

In terms of education, as an educator I can honestly tell you that while we can hit, at this time, maybe the top 2% of active working web folk we’re succeeding better than ever before. Conferences and blogs don’t cut it. And as helpful as W3C/Opera WaSP/InterAct frameworks are (and should be more encouraged) nothing beats in depth-education. So I’m with you on that. And there are probably 25 truly decent educators in our field at this time, most of whom are working on outreach (a part of, but not the heart of) education.

My 2 worthless US pennies,
Molly

Comment by Algy Taylor

Vendor prefixes are the work of the devil! It goes totally against what I see the web as being – free, open, democratic.

Prefixes, on the other hand, are not far (if at all) short of going back to the bad old days of IE6 – it locks people in to using one particular setup … normally webkit … if they want to view a site as intended. My own feelings/approach to it is to fight the vendor prefixes on the fields and refuse to implement them. The only way you can ensure that this ridiculous fragmentation doesn’t happen is to actively work against it, not to pander to specific rendering engines – be that Gecko, Trident, Webkit, Presto* or any others.

* not that I be slandering Opera, who by and large seem to be spot on with things.

Comment by Matt Wilcox

I don’t think vendor prefixes have morphed – they were always intended that way. As a manner by which developers could test how incomplete specifications might work in the real world. Because we do need to test these things – imagine if Flexbox 1 had not had such extreme testing. We’d be saddled with it as a final spec.

The problem with vendor prefixes is how they’ve been used by authors as though they are final or standard CSS. That’s an education problem.

The argument might be made that vendors could supply a preferences toggle to turn support for vendor-prefixes on or off, and ship with it off. That enables developers to play with incomplete implementations but shields average users from ever seeing their effects. The problem with that is it also completely neuters the benefits that vendor prefixes bring – namely that it encourages experimentation and rapid feedback and progression. If authors couldn’t use those prefixes on public sites, the majority would never experiment with them because no one would ever see them.

Trying to make a technology solution for this would end up either:

* Disabling them and thus making them useless.
* Parsing other vendors tags, which can’t work for all the reasons Microsoft discovered.
* Attempting to have the cake and eat it too.

There isn’t an acceptable technology solution that doesn’t also kill the reason they’re there in the first place.

Comment by David

@Matt
So basically your point is “let’s teach developers that these features should only be used experimentally” ?
Well, that’s the idea : stop shipping prefixes in official releases.

Comment by Matt Wilcox

@David. Yes, that’s always been the idea. But if you stop shipping them, you end up with these new ideas never being tested properly. Testing in this way is vital – look at what happened with Flexbox to learn why. Disabling them is a non-option.

Comment by David

@Matt
I used to agree with you, but the fact is : some of us developers are stupid. They won’t listen to your advice. They’ll simply copy-paste cool code without reading the warnings.

You put responsibility on authors. I put it on implementors.
Aren’t they responsible for testing their stuff ? Aren’t they responsible for conforming to standards ?

Comment by Algy Taylor

@Matt – does it matter that they’re not ‘fully’ tested before it’s put out in an official release (or rather, a standard feature in an official release)? Whether they’re faulty implemented as ‘-webkit-blink’ or faulty as ‘blink’, it doesn’t really matter to the end user anyway. They might as well be implemented *properly*, save a massive ‘future backwards compatibility problem’.

Comment by Odin Hørthe Omdal

@Matt – well that’d work with having -draft1-flexbox -draft2-flexbox et al. When the spec does big changes that’ll break older implementations, it can up the number. It’s better tying it to the actual spec than the rendering engine.

The ‘draft’ part should also tell the developers that this is something that won’t be infinitely supported. As they seem to be thinking about vendor prefixes…

Comment by Bruce

Perhaps stopping shipping prefixes once the full version is stable. Eg, no longer supporting -blah-border-radius or -blah-transition once the unprefixed version has broad support. I’m not sure what browser vendors do. (Opera removes prefixed support)

That would break sites that don’t use the unprefixed version. On the other hand, using experimental, pre-standardised code on production websites carries an element of risk.

Comment by Matt Wilcox

@David – I agree. And you know what – not our problem. It’s a problem for the designer. Why are we taking responsibility for it? In the end, they build a poor website that doesn’t work well. People with better knowledge won’t make the same mistake.

Neutering languages to avoid these problems is the same as making education easy so less able kids don’t fail their exams. “Just don’t ask hard questions, too many kids fail them”. So what? Changing it holds the smart kids back because they’re never taught anything better.

You can’t hold implementers responsible for this – they are explicitly flagging these properties as WIP, that’s what the vendor prefix means.

@ Algy

You’re seem to not understand how this works. The point of them is they are testing of unfinished ideas. If the ideas are not tested then they take a lot lot longer to mature – if they ever do. CSS is getting a lot more features a lot faster because we get to test these things. It’s like any inventing process – you can’t complete the whole thing on paper and then implement it. You go through prototypes and working models. That’s what vendor prefixes are. You can’t just skip all the middle bits and end up with a functional, robust, well implemented finished product. Especially in the case of CSS, where once it’s codified as a standard it can never change. To change it breaks backward compatibility, which is why it simply doesn’t happen.

Comment by Matt Wilcox

@ Odin

The problem is that many of these are implemented by vendors before the CSS WG has anything standardised. That’s the point. If things were already agreed upon then there’d be no need for the prefix.

You’re assuming that it’s a central organisation coming up with new CSS features, and then vendors go and implement it, get feedback, and a revision process takes place. That’s not how it works. Each vendor comes up with their own feature or implementation of a feature – because there isn’t a template for a standardised way yet. Those then get tested and refined, then the CSS WG decide which is most appropriate, and that’s what gets standardised. That’s why there are different syntax’s for gradients depending on which vendor you’re using.

Comment by Matt Wilcox

@odin – I do like your suggestion of more clear naming convention though. What exists is functionally fine, but unless you already understand the reason for a prefix you won’t know that it’s experimental just by looking.

Comment by George Katsanos

The AMBASSADOR of Web Standards Mr Jeffrey Zeldman couple of weeks ago to his blog in reply to Stephanie Rieger’s deathstone on RWD:

Eventually this nutty market will stabilize around a few winning Android platforms (e.g. Kindle Fire) and common breakpoints will emerge

So, what do you expect to happen when a bunch of people driven by profit lead the market.. First it was RWD instead of traditional mobile design, (madness) then it’s clear suggestion for Webkit Monoculture (because Apple is designers sweetheart with its authoritative control over every little user detail) and you ain’t seen nothing yet.

Comment by Steve Dennis

I agree, but only to a point. Sites still should be built with their audience in mind. Concepts like return on investment don’t just disappear with the invention of the internet, and it is up to the browsers, standards bodies, and tool makers to make good development easier and cheaper so that there’s no financial reason to NOT make good accessible websites.

I’m not saying good web developers shouldn’t strive for excellence, but it can easily double project budgets as it currently stands, and that’s just not good enough.

Developing good, accessible websites needs to be easier than developing bad ones.

Comment by Jeremy

I’ve shared this with my development team. I agree with the sentiment that this is a developer problem, not a vendor problem and it’s primarily driven by laziness – not even time – since many of these issues don’t go beyond adding the appropriate lines for -o-, -moz-, and -ms-.

-webkit may dominate our analytics and even our pockets (most of the devs I know have an iphone – talk about monoculture), but that’s no excuse for not testing beyond what we only see in front of us. I’m in the process of building a modest device library for testing so that I can get those other devices in front of me. Brad Frost wrote an excellent blog post on how to pull together a comprehensive device library without spending too much.

One of the best ways to grasp this problem is to use the devices themselves and experience the frustration of broken pages. It’s arrogant to believe that only those with the latest, greatest devices deserve to consume your wonderful content and design.

Comment by Adrian Schmidt

This is catastrophic. Why are the people who live for and build the web the very same that are destroying it like this?
Developers need to realize that it wasn’t the browser makers’ fault that the UI-string went to shit, it was the developers.
It’s the exact same thing here. Of course emulating another vendor’s prefix is The Wrong Thing To Do. But if going out of business is the only alternative?
Developers, don’t force browser makers into making bad decisions. Help them make the right ones instead.

Comment by Joe Crawford

The way it’s always been, from <img> to <frameset> to <object> to .innerHTML, is that vendors are free to add new crazy stuff. Sometimes that stuff sucks: <marquee>, <embed>, document.layers, document.all. Things that are good and useful end up entering a standards process and get codified. That’s how standards happen. Prefixes are awesome when they are a “staging area” for new stuff, and when they prove useful are adopted, and lose the prefix (e.g.: -moz-border-radius becomes border-radius).

Mozilla and Microsoft adopting -webkit- prefixes because developers are using it are vendors abrogating this process in hopes of being “more compatible” with WebKit are trying to shirttail themselves on webkits fast uptake in the marketplace. As PPK has pointed out, WebKit != WebKit, so this is pretty dumb.

Using prefixes as browser vendors try out new features works with MIME types and HTTP headers, there’s no reason it shouldn’t work with CSS. It breaks down when browser vendors short circuit the process. They’re not doing their job. Now, there are arguments that prefixes in general are bad. And that’s fine, but I would say that essentially you are telling the people swallowed by the flood they needed to not live in a flood plane. It’s too late.

We have prefixes, they are not going away, and as a community we need to figure out a rational process for using or not using them, and press on browser vendors to adopt a rational process that works for the web going forward.

Comment by John Allsopp

Bruce et al

an important conversation, and a complicated one IMO.

1. the problem.

I’d restate it along these lines

The web, that so many have worked so hard for so long (including Bruce and myself, andmany commenters here as well) to keep open and interoperable, is in danger of once again fragmenting.

Developers are increasingly creating sites and applications which rely heavily on the features of a specific browser engine, webkit, with little concern for ensuring interoperability with other browser engines.

This is particularly at issue with mobile browsers.

2. The cause

in the aftermath of the first, free for all browser war, where browsers used the introduction of new web technologies, extensions to HTML and CSS, the DOM and so on as competitive strategies, we saw the move toward standardisation of these technologies.
We also learned that while standardisation brings tremendous benefits, there are also downsides. Particularly, a slow down in the development of innovations.

The introduction of the concept of vendor specific prefixes that enabled experimental, and incomplete innovations particularly but not exclusively in CSS, and specifically I’d argue, Apple’s agressive adoption of vendor prefixes for once experimental but now mainstream or increasingly so technologies like transforms, transitions, animations, gradients, and other ner staples of cutting edge web design/development did some very positive things

without these, it’s likely the move to “native” technologies for application development would have been even more pronounced
it (I’d argue) reignited a sense of experimentaion, and excitement among designers and developers. Indeed, I’d go so far as to argue the HTML5 revolution is really largely a CSS3 revolution

But we also see the downsides, in particular de-facto lock-in via the use of only vendor prefixed CSS

3. The culprits

So who is at fault here?

Browser developers who use vendor prefixes? Well, they all do it, it’s countenanced as part of W3 standards, and has brought without question very important benefits

Developers who use only vendor prefixed properties? Wouldn’t this entire problem go away if in addition to whatever vendor specific prefix they use, also simply add the prefix less version?
But it’s really not as simple as that. CSS gradients are now in their third syntax iteration since their original experimental introduction in webkit about 3 and a half years ago.

4. Possible solutions

So, what can be done?

1. do nothing. Is this really that big a deal? Playing devil’s advocate, in theory it appears problemmatic, but in practice, can we point to significant real world examples of how this is having a genuionely negative impact?

2. Continue to educate folks (is our work here never done ;-)

3. Browser vendors work really hard to implement those features that see quick and excited adoption by leading edge developers? Yes it is expensive, and challenging, but IMO developers are close to the #1 market for browsers – get developers to adopt and love your browser, and you’ll benefit (ye, I know we all know this, well, except some of themarketing folks at various browser development companies I’ll leave unmentioned ;-)

4. introduce a meta element, like X-UA that developers use to expressly enable treating prefixed features as non-prefixed? Does this just move the problem further up the abstraction chain, or would it make developers conscious of the issue?

5. Geez, I dunno, this sh*t is hard!

Does that help? Probably not ;-)

john

Comment by David

John, you forgot that another possible culprit is the spec author who is too slow.
(I don’t say it’s the case !)

HTML is less prone to such problems because Ian dictates quickly his views. (I don’t say I like it either!)

Comment by Daniel Walker

Ten years ago, here’s me, at work, in Wrox Press (well glasshaus, by then, actually). I’m sitting in that dingy office on the second floor of Arden House, that they’d put us into (the one with the corridor, that was like something out of ‘Doom’).

I’m looking at Wrox’s shonky (and shockingly overdue) new website. John Franklin comes over (I seem to recall he needed me to look up someone’s phone number: a side-effect of working for a company that moved its employees around, all the time, as a substitute for actual progress, is that no one ever knew anyone’s phone number).

He takes one look at my screen and makes a ‘bletching’ sort of noise.

Franklin: God, is that Linux? You pervert!
Me: I’m just looking at the new website in KHTML. Did you know the markup, alone, for the home page, is five and half megabytes?
Franklin: What’s “KHTML”?
Me (gesturing at the screen): The Web browser.
Frankin: Well, that looks like shit! Who the Hell thinks the world needs a new Web browser?

Comment by Jennifer Kyrnin

I agree that this is partially a problem of education, but I can tell you that all the good, valid reasons in the world will not sway someone who is determined to be lazy. And many people don’t see any difference whatsoever between browser prefixes and hacks. In fact, I have been told that prefixes are worse than hacks because they double the amount of CSS code you have to write and deliver.

Many new designers either don’t seem to want to learn HTML or CSS and just use an editor (WYSIWYG) or they won’t move to standards until “all browsers support them.” Many older designers are sticking with David Siegel’s single-pixel gif trick because it was good enough in 1997 so it’s good enough now.

John is right. Continue to educate is the best option. But it’s tiresome… :-)

Comment by Algy Taylor

@Jennifer Kyrnin – well, I think most people (to begin with) want everything in a WYSIWYG interface, because it’s easier to make things visually look like you want. Then you get in to the stage when you realise you can do far more without a WYSIWYG editor, and finally to the stage of enlightenment when you start wanting the HTML/CSS to look visually nice too!

Comment by Jennifer Kyrnin

@Algy Taylor: that is an ideal path, but I think a lot of designers learn up to a point and then they are too busy working to go forward learning new stuff. At least that’s what they tell me. :-) I can’t tell you how many people have said a variant of “my clients don’t ask for HTML5/CSS3/other standard so I don’t need to learn that”

I think education is a start, but I think getting the editors (WYSIWYG and not) to deliver standards-based design as the default is important too. There are a lot of small business owners who just want an editor like Word to put up a site and be done with it. They don’t want to learn HTML or CSS or even care about standards, so their tools should care about the open web for them.

But you’re right, it is enlightenment when you get to the beauty of code phase. :-)

Comment by Vendor prefixes: the good, the bad and the ugly

[...] However, all of these people believe that the vendor prefix system is more fundamentally broken than I do. I think the problem is a little more obvious, as you’ll notice that both of the key problems I described previously have a clear commonality: developers. Us. As Opera’s BruceLawsonsaid: [...]

Comment by lucideer

I’ve always been inordinately wary of vendor-prefixes and made every attempt to avoid them completely – though recently they’re too proliferant to really avoid.

Since we’re unlikely to ever have a web where competing vendors don’t continuously put unstable/experimental features in public releases, how about this proposal:

Instead of vendor-specific prefixes, have context-specific/semantic prefixes.
e.g.
– if a vendor wanted to add “border-radius” they wouldn’t add it as “-vendor-gradient” they would add it as “-exp1-gradient”
– if vendortwo wanted to implement it in a compatible way they would also add “-exp1-gradient”
– if vendorthree wanted to implement a newly proposed/altered incompatible version of the same property they would then call it “-exp2-gradient” or such like

This would:
(a) stop web-developers thinking in terms of browser-targeting and start them thinking about spec-targeting
(b) force web developers to be more aware of the status of each proposed spec. individually (as different properties would have different prefixes, even in the one browser)
(c) allow multiple vendors to implement the same property exactly making our CSS files less verbose