From -alpha To -webkit: Fix All the Prefixes

Posted

Mozilla has sparked a bit of controversy lately by talking about supporting the -webkit prefix, a prefix that has not traditionally been supported by a browser that doesn’t actually use the WebKit rendering engine (Mozilla uses their own rendering engine, Gecko, which is targeted by the -moz prefix).

The reason for this, in a nutshell, is that Mozilla is dissatisfied with the way web designers are targeting—or rather not targeting—their Firefox Mobile. You see, the default rendering engine for the majority of mobile web use is WebKit-based. On the iPhone, it’s Safari (and almost every other browser in the App Store). On Android phones, Google also uses WebKit. On this platform, one could download Firefox for Android, and Mozilla is disappointed that this browser is being ignored by web designers when it has the capacity to display the same high level features that WebKit can.

I’ll leave it at that, for now. If you need more information, there is plenty of literature out there already.

My knee-jerk reaction was that this move was a little bit crazy. A lot of talented designers are survivors of the Internet Explorer 6 nightmare—I mean monoculture—and a significant portion of them agree that we’re at risk of a WebKit monoculture that will lead to incomplete standards support and technological stagnation. A second internet dark age, so to speak. Conversely, Mozilla believes that not supporting the -webkit standard will bring on the same monoculture.

Vendor prefixes allow designers to target experimental features in new browsers—at their own risk—without having to wait years for the official standard to develop. Furthermore, they allowed for standardized overrides to supersede any of the prefixed versions, which kept websites future-friendly, in addition to being cutting-edge.

I thought the main problem might be evangelism. Tutorials abound with information about cross-browser compatibility for new features, and once you drill that into a designer’s head, they have the skills to build truly cross-browser websites.

About this time, a developer from Mozilla sent several tweets to me, basically dismissing my concerns, saying I’m wrong, and that evangelism hasn’t worked. It was a strange exchange that turned into an “I’m right, you’re wrong” pissing match that I have to say shook my allegiance to the Firefox browser. So, that did nothing to convince me that Mozilla might be on to something.

Then I read what Peter-Paul Koch had to say about it and the thing that sunk in for me was that some or many or most web designers don’t want to write the same style three to five different times. Personally, I think that’s lazy and a sign of a bad craftsman, but that doesn’t change the way it is. Designers don’t want to compensate for the flaws in the standardization process, they just want to write it once and have it work.

Koch’s solution was that we let the browsers implement -webkit support, but eventually migrate that into a new -beta prefix that all browsers will share. If one browser screws up one of the properties and ruins it for all the rest, well, “this serves as a powerful reminder to web developers that they’re meddling with forces they can only comprehend after a study of the spec.” I can see where he’s coming from; I feel that’s how current prefixes should be kept in mind.

A List Apart, the authority on web design, also posted a really great interview between CSS master Eric Meier and current Mozilla standardista Tantek Çelik. First, I have to give Meier a lot of credit for digging in and asking the hard questions. Second, Çelik did a much better job showing the thinking that led to their current direction than did the Mozilla dev I chatted with. It seems as though “the WebKit-specific mobile web is growing faster than we can evangelize, especially in contrast to WebKit-specific evangelism, both implicit and explicit.” So, evangelism is a bigger problem than I thought.

To this, designer superstar Andy Clarke said, “I’m sorry [Tantek]. That is tough shit.” I’m going to have to disagree here. In an ideal world Clarke would be right. It’s a bit slimy that a Gecko browser would be paying attention to properties it’s explicitly told to ignore. But this is a user problem more than it is an author or vendor problem. According to Çelik, “[Users] are seeing downlevel or ‘feature-phone’ ultra-minimal and reduced functionality experiences.” As the W3C’s own Priority of Constituencies states, “In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.” Users first. Authors second. Secondarily, Mozilla does have a commercial interest in protecting their users. I can’t begrudge them that.

Later, Koch followed up on his -beta post with a post about adding in an -alpha prefix, as well. This would be for new features that were, um, truly experimental? Moreso than the -beta prefix, anyway. Plus, -alpha could disappear or change at any moment, while -beta would be effectively stable and supported for life.

Kyle Weems, designer and creator of the CSSquirrel comics, tweeted at me: “I think -webkit adoption is a mistake, but I think -alpha and -beta would be serious problems too.” Agreed. -alpha and -beta would carry all the same problems as -webkit minus the part about Mozilla not being a WebKit browser, which is at least a step forward. But we still have legitimate concerns here. It seems unfair that the designers like Weems and Clarke and Meier (and me) who are doing it right should get punished with significantly less flexible and altogether more unpredictable web prefixes. Is there a better way?

Here is my answer:

  • Forget -alpha. It’s too ambiguous and unnecessary. Prefixes are, by definition, experimental and subject to change. They’re dangerous, and they should stay dangerous.
  • Forget universal -webkit support. -webkit is called -webkit because it’s used by WebKit browsers only.
  • -beta is keeper because it solves a problem. Lazy web designers who don’t care about their clients can rely on a single prefix, that all browsers can support, without too much effort. Furthermore, when the experimental implementations become stabilized before they’re officially welcomed into the spec, it would allow the hard workers to condense their verbose system of prefixes to a single one. Hell, I would love to have as few gradient declarations as possible.
  • Here’s the first key part, though: continue to support all the vendor prefixes. Essentially, each -beta feature would be mapped to the appropriate vendor prefix. For example, -moz-border-radius would be the same as -beta-border-radius. This way, when a browser does come along and screw up an implementation, designers can work around the bug by targeting the other browsers. If Safari accidentally inverted border-radiuses, we could break it down from -beta to each individual prefix, minus -webkit.
  • The second key part is that evangelism for building to standards must not flag. Designers must—absolutely must—include standards-based overrides so that their sites will continue to work into the future. I think the best way to do this is to rapidly pull support for experimental properties once the spec is put in place. It must be in a designer’s second nature that if they don’t play by the rules, their websites are going to degrade over time. Again, prefixes are dangerous! Use them wisely.

It’s definitely a lot to think about, and this is one of those instances where the decisions we make now will be echoing for a long time. I don’t see my proposal as a compromise, because the solution doesn’t hurt anybody. This solves an real problem, while working within the existing system.

Comments

No comments allowed at this time. Read my commenting policy.

← Older Newer →