Following-up on my mobile web development post from last week, we have Daniel Glazou, co-chair of the CSS Working Group outlining the scope of the -webkit-prefix problem.
Go read his post Call for Action: The Open Web Needs You *Now*. Or read some of what I’ve excerpted below.
As in the past with IE6, it’s not a question of innovation but a question of hardware market dominance and software bundled with hardware. But there is an aspect of the problem we did not have during the IE6 era: these web sites are also WebKit-specific because they use only “experimental” CSS properties prefixed with -webkit-* and not their Mozilla, Microsoft or Opera counterparts. So even if the browser sniffing goes away, web sites will remain broken for non-WebKit browsers.
In many if not most cases, the
-webkit-*properties WebKit-specific web sites are using do have-moz-*,-ms-*,-o-*equivalents. Gradients, Transforms, Transitions, Animations, border-radius, all interoperable enough to be browser-agnostic. Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.
Emphasis mine. As I said in my previous post, a vendor prefix means that the property is in flux, and the syntax of functionality may change radically once it’s finalized and implemented.
But here we have this mass of (primarily mobile-targeted) web sites* that are calcifying the web in its current state.
The problem is so bad that, as Glazou says in his post, other browsers will start supporting/implementing themselves the
Yes, every major browser vendor, Opera included, will likely implement support for -webkit-* prefix, turning one single implementation into a new world-wide standard.-webkit-* properties.
Save your celebration, son. Your laziness and myopia is what got us here.**. The best we can hope for is that Opera, Mozilla, and Microsoft agree to support the same set of -webkit-* properties, and agree to handle conflicts and cascades the same way.
But what if they don’t? Frankly, either way, we have a hot web development mess on our hands. We’ll either have more of the same proprietary prefix lock-in, or we’ll have a tangled mess of conflicting implementations.
Okay, so what can I do?
If there is any good news, it’s that you can get us out of this mess. Here’s how.
Step 1: Educate yourself about the state of browser support for CSS properties
Step 2: Use tools to make writing cross-browser CSS3 easier
- David Desandro’s CSS Textmate bundle
- LESS
- SaSS
- Compass
- CSS3 Please
- CSS3 Generator
- CSSLint
- Chris Coyier also has an excellent roundup of CSS pre-processing tools
- Or just write your own script to do it for you†
Step 3: Retrofit your existing code
That’s self explanatory.
Now ideally, you would also test in every browser. But I understand the tradeoffs between market share and time. For what it’s worth, Opera tries to make testing easier with its Opera Mobile emulator. You can also set up an Opera Mini test environment on your own machine. Firefox also offers a mobile emulator. For Android, install the SDK (it’s painless). Pro-tip: You can also run other Android browsers using the SDK.
Let’s not repeat the mistakes of years past in the mobile space. We know better, and we can do better.
UPDATE 1: Check out the Prefix the Web project.
*Having learned the lessons with IE6 sites that are optimized for larger screens are less guilty of this.
**Ever the one for fairness and nuance, I present Ian Lunn’s Vendor Prefixing: Standing Up for Developers.
#!/usr/bin/php path or the like for Linux users, but it runs as is for me. Save it as a file anywhere you’d like. Run it using php <path-and-filename> "unprefixed-property: value".
<?php
$pref = array('moz','webkit','ms','khtml','o');
$str = '';
foreach($pref as $p){
printf('-%s-%s;',$p,$argv[1]);
echo "\n";
}
echo $argv[1].";\n";
?>