Pre-fix the web: Webkit-only solutions hurts the open web

No, it's not, but it isn't going away. Designers and Web Developers want to do more than current standards (and browser implementations) allow for.

A lot of the new CSS stuff doesn't require the vendor prefixes, since those vendors now support the prefix-less version. So you don't need to go "-webkit-border-radius: … -moz-border-radius: …", instead do "border-radius: …". We're at the stage where we need less CSS declarations.

The problem is that some sites only have "-webkit-border-radius:…". They should just drop the "-webkit-".

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?

In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it.

Prefixing isn't a function of the standards bodies, it's a function of browsers that want to implement stuff without worrying about peoples' experiments doing something stupid when the standards body picks the same property name but with different semantics.

edit: here's a scary thought, what if standards bodies picked Microsoft's version of CSS Transforms back in the '90s:

  #myObject {
     filter: progid:DXImageTransform.Microsoft.Matrix(sizingMethod='auto expand',
          M11=1.5320888862379554, M12=-1.2855752193730787,
          M21=1.2855752193730796, M22=1.5320888862379558);
  }

If you want to only support standardized features then only support standardized features. That's a decision for individual developers to make. What you are proposing is to strip developers of the ability to test out non-standard features.

And contrary to your claim that prefixes are just applied blindly, some CSS features have indeed been implemented differently by different browsers — gradients and the flexible box model, to name just a couple. Prefixing is the only reliable way to get the feature before the W3C actually produces a standard with it 10-15 years down the road (I wish that was hyperbole, but it isn't — just look at how long they plugged away at XHTML 2 with no end in sight before everybody got tired of waiting and started implementing HTML5). The point of prefixes is to ensure that the W3C are never faced with a choice between standardizing a CSS feature against their will and breaking the Web.

Although I don't like the bloat from an ideological standpoint, in practice this is the best way we've come up with. But to make reading, writing and maintenance easier, I generally like using a CSS metalanguage with a library like SASS+Compass or Stylus+Nib. That way, you can just write, say, "transition: color .5s linear" and it'll get translated into the appropriate cross-browser code.

Webkit’s might is the problem here. Dropping prefixes without having some alternative solution in place is definitely not the solution. That’s why it’s a hard problem.

Web design takes place from the standpoint of what is possible to accomplish with the most-supported features. From that starting point, vendor prefixes only allow developers to improve their product for users of more modern browsers, and in doing so, place a vote of support for the rapid completion of the prefixed feature.

If you decline to use "-webkit-", you put your website at a disadvantage compared to others that do use the prefix, and you still have to return to the site at some point in the future in order to implement the feature once it's widely supported.

I suppose there's an argument to be made for saving a little bit of hassle in the present time, but that's highly situational and since CSS is so easy I don't think it holds muster.

If Webkit's codebase defines the "standard" then the decision-making process is no longer open, even if the source code (eventually) is. It is controlled by a small number of people, primarily at Google and Apple, who have their existing products and product plans to consider when adding features and changing behavior.

Think about what that means if you are trying to compete with those two. Forget trying to create a competing code base, they control like 90% of the existing mobile web. But even if you adopt Webkit you're at a huge disadvantage because they're months ahead--you can't just fork the code and go your own way, you also have to adopt whatever they include later because it's the standard.

I don't think either propriety vs opensource or dead vs active development are important to the overall question of "is standardizing on a single implementation a bad idea?"

Yes, the fact it had dropped out of active development made it worse to standardize on, but it was already a bad idea.

The same goes for open source. Yes, it can be forked to get away from something bad, but if only one browser/engine becomes standardized on by users and developers, then that engine's team has complete control over what the web becomes regardless of competing implementations are doing.

It creates a HUGE hurdle to pull the web in another direction. People weren't "stuck" with IE6 because it wasn't opensource, they were stuck because the distributor wasn't releasing new versions that also did what the competing products wanted supported.

If just a few really popular sites have broken mobile sites because of this, that's a big problem!

So I think you undermined your own argument completely.

Sure, that's one approach. But what if you want one of those features?