First of all, I don't want to come off as argumentative. I think we agree on the fundamentals: Implementation should come before standardization. Vendors should feel free to experiment. The W3C should focus more on quickly standardizing things that are already working in the field.
Today, experimental and prefixed features used in the wild are creating real problems for interoperability and competition. But I don't think there's a villain here, and I'm not blaming WebKit. Both the browser vendors and the W3C are using processes that were designed to certain solve problems. Now those processes are creating new problems and might need to change in response.
But, to answer your direct question (although I think this is getting on a tangent from the original post):
> "What are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform?"
Dart is an example of something that Google has proposed (not "WebKit" as a group) that I and many others - even others like Oliver Hunt within the WebKit community - do not think benefits the web platform. Some people would put Web SQL Database in this category; I don't have an informed opinion about that one. (Though I do know it's the reasons some versions of Gmail wouldn't even load in mobile Firefox.)
> "Where did Webkit actually get things wrong?"
Apple's "meta viewport" tag is something that they released in Safari and evangelized to developers without specifying it or getting community feedback. I had the pleasure of reverse-engineering it for Gecko. Among other things, it's not even implemented in a layer where it makes sense. (It should be part of style, not markup.) Apple never proposed it as a standard; other people eventually did and are trying to fix some of the problems. Unfortunately, the basic design is locked in by legacy content (and has been since soon after Apple shipped this feature in the first release of mobile Safari).
But frankly, I don't care so much whether they get things "right" or "wrong." As bad as meta-viewport is, at least Firefox and Opera and Android and IE can implement support for it without controversy, and be compatible with sites that use it. The way that prefixed CSS properties are (a) released to market by browser vendors, (b) evangelized to web developers, and (c) deployed on production web sites is creating a situation where new browsers are either locked out of existing sites or have to implement each others' prefixes. This is not a stable equilibrium.
This is an awesome comment, and thanks for writing it.
One thing I didn't have going into this thread that I have now is appreciation for how different this problem is in the mobile space than on the "desktop" web. It's easier to be frustrated with web standards in the desktop world, where Webkit seems like an unalloyed force for good. I can see how much trickier it is for your team given the fact that Gecko has been relegated to second class status by the market.
What doesn't benefit the Web platform is being tossed aside because of superior native development frameworks. That's a far bigger danger than someone forgetting to add a '-moz-' prefixed CSS properly.
A number of people seem to have a somewhat extremely optimistic view that they're going to make Javascript competitive in performance and memory use compared to native on mobile platforms. There's just no evidence that it's going to happen anytime soon. It's just not even close, despite how magical emscripten or Mandreel might seem.
With more and more browsing activity shifting to mobile, and with the majority apps being entertainment/multimedia/games, holding steadfast to the idea that there are not benefits to alternate VMs is more of a dangerous than transient breakage of pages.
Yes, the prefixes are a problem, but the Web needs to evolve fast to keep up. A period of incompatibility and fragmentation can be tolerated. It's happened before, chaos and disequilibrium followed by periods relative calm.
I'm more worried about stagnation, and a future where the web gives way more to the client-server internet days, with everyone running OS specific native apps that read and store data behind walled-garden non-HTTP clouds.
Today, experimental and prefixed features used in the wild are creating real problems for interoperability and competition. But I don't think there's a villain here, and I'm not blaming WebKit. Both the browser vendors and the W3C are using processes that were designed to certain solve problems. Now those processes are creating new problems and might need to change in response.
But, to answer your direct question (although I think this is getting on a tangent from the original post):
> "What are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform?"
Dart is an example of something that Google has proposed (not "WebKit" as a group) that I and many others - even others like Oliver Hunt within the WebKit community - do not think benefits the web platform. Some people would put Web SQL Database in this category; I don't have an informed opinion about that one. (Though I do know it's the reasons some versions of Gmail wouldn't even load in mobile Firefox.)
> "Where did Webkit actually get things wrong?"
Apple's "meta viewport" tag is something that they released in Safari and evangelized to developers without specifying it or getting community feedback. I had the pleasure of reverse-engineering it for Gecko. Among other things, it's not even implemented in a layer where it makes sense. (It should be part of style, not markup.) Apple never proposed it as a standard; other people eventually did and are trying to fix some of the problems. Unfortunately, the basic design is locked in by legacy content (and has been since soon after Apple shipped this feature in the first release of mobile Safari).
But frankly, I don't care so much whether they get things "right" or "wrong." As bad as meta-viewport is, at least Firefox and Opera and Android and IE can implement support for it without controversy, and be compatible with sites that use it. The way that prefixed CSS properties are (a) released to market by browser vendors, (b) evangelized to web developers, and (c) deployed on production web sites is creating a situation where new browsers are either locked out of existing sites or have to implement each others' prefixes. This is not a stable equilibrium.