Prefixing just did not work. We should push the standards bodies to drop that nonsense ASAP.<p>Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution, and in fact circumvents the original purpose of prefixing--you're assuming that all vendors implement the feature identically, in which case why prefix at all?<p>The W3C meeting discussion on this was very depressing. Rather than trying to collaborate on standards that move the web forward, Webkit contributors want to get a leg up with proprietary extensions and make the others struggle to catch up.<p><pre><code> tantek: I think if you're working on open standards, you should propose
your features before you implement them and discuss that here.
smfr: We can't do that.
sylvaing: We can't do that either.
tantek: We're going to push you to do that sooner and sooner.
jdaggett: If you're proposing something that's going to be put on a Web
page, how is that proprietary?
</code></pre>
<a href="http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html" rel="nofollow">http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.h...</a><p>And we've just started this developer nightmare; right now it's mainly focused on CSS prefixing. Thanks to Apple refusing to share its touch patents, the W3C is stalled on touch event standards as well.
Internet Explorer 6 was released in 2001. I realize this is not central to the article, but "A lot of products were made in the end 90s that only worked in Internet Explorer 6" bothered me. Perhaps it simply made me feel old, but I'd like to think its some sort of noble sense of historical correctness.
One way to quickly find code that uses -webkit- only CSS properties is to use the GitHub's code search with queries like: <i>language: css +"-webkit-" -"-moz-"</i>.
Can't we just convince devs to <i>not</i> use prefixed code? That stuff is experimental, it is <i>guaranteed</i> to break in the future. I know it's hard, but wait for the standard to be standardized, or realize that every time you type "-webkit-" you're making a commitment to fixing your site at some point in the future.
the comparison between IE6 and Webkit is unfair: Webkit is completely open-source and under active development, whereas IE6 was propriety and dead.<p>as a pragmatist I don't see it as an bad thing if Webkit becomes close to 100% of the browser market...
According to Mozilla's own research[1]:<p><pre><code> how many sites in your mobile Webkit browser crawl use at least one of 'transition', 'transition-timing-function', 'transition-duration', 'transition-property', 'transition-delay' (ignoring prefixes)?
1245 / 30087 = 4.13%
how many use them only with -webkit prefixes (no -moz or unprefixed versions of the properties)?
336 / 30087 = 1.12%
how many use them only with -webkit prefixes and unprefixed (no -moz versions of the properties)?
365 / 30087 = 1.21%
</code></pre>
Is it really that serious an issue if it only crops up in 1.12% of mobile sites (where webkit has the overwhelming marketshare).<p>[1] <a href="https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#Data_on_vendor-specific_prefixes" rel="nofollow">https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#D...</a>
While it's important to support cross-browser compatibility, it is equally important to deliver to the user the possible design experience. Unfortunately, this may come as a loss to the functionality of non-supporting browsers but I think in the end, it's worth it. Of course we should strive to enforce compatibility but not at the expense of creating a design of lesser-quality (as a result of being wrapped in cross-browser compatibility).
Can't we just have type="text/css' and type="text/css+webkit"? Wouldn't utilizing MIME types solve this problem for all parties? W3C can continue to be ineffective without vendors subverting its control. Vendors get a namespace in which to stick their ill-thought experiments. Developers get to isolate vendor-specific CSS away from the standard stuff.<p>edit: clarification, hopefully
The point behind prefix was to support experimental CSS features and the prefix gets dropped once it's out. This is not Webkit specific, other browsers do the same. It's a pretty bad idea indeed, but I am not sure why you are pointing at webkit only.
The problem is that using prefix-less names means that it needs to be standardized before any experimentation can be done.<p>Standards that get ratified before any experimental implementations exist tend to be horrible.