The problem for Google is that an extensible web is a threat t their business model based around search. This is why they are so adamant about force pushing web components and polyfills. It's the least offensive (and least compute intensive) approach to their web crawler.
It's much easier and cheaper for them (as a business) to get everyone to adopt a half-baked and half-thought out standard that allows their crawler to extract content from a page without having to execute javascript to understand what is there.
With the right APIs, a JavaScript rich web can still be an accessible web for the physically impaired. OS X is proof that this possible. However, this approach makes it far far more expensive for web crawlers at scale since it's not as simple as just parsing a document. Forcing everything into a cheaply parseable document is just Google externalizing their costs on the rest of society.
Every decision made for blink needs two be viewed with two lenses: (1) what does this change mean for the Chrome web browser?; and (2) what does this change mean for the Google web crawler? At the end of the day, those two are closely related.
More pertinent to this issue, one of the Googler posts in the relevant public-pointer-events discussion cites that site:
http://lists.w3.org/Archives/Public/public-pointer-events/20...
There is a huge difference between the polyfill that is Polymer and the W3C Web Components specification.
The former is a polyfill that developers can only rely on if they explicitly include it as a dependency in their project. The latter is a feature that is (or at least should be) baked into the current version of every modern web browser out there.
The former conveys an architectural design decision that you must consciously make and that there may be other legitimate alternatives (known and unknown) that you may want to consider instead of the one you're familiar with. The latter conveys that there is one true way of accomplishing task/need X and to stray from using that standardized feature is only for either heretics or the brave.
The former creates a scenario that promotes a proliferation of alternatives. The latter squanders the intellectual capacity of the community with respect to a specific problem that is "officially solved".
To declare a "problem officially solved" with an inadequate solution is professional malpractice, IMHO.
The issue I'm talking about here was the fiasco earlier this year where the Chrome team announced the intent to ship web component features without the use of a developer flag despite the fact that the feature that was not defined in a w3c spec draft much less a mature spec[0]. When you have the market share that Chrome has, shipping without requiring a developer flag is tantamount to saying "Standards schmandards! We're gonna do whatever we want like we're building Internet Explorer in the late 90s!"
[0] http://lists.w3.org/Archives/Public/www-style/2014Feb/0103.h...
I know that the Safari devs are unencumbered and disagree with the Google approach, but I don't know what position they do support as an alternative. I just know that their position does not coincide with Google's position.
TBH, there isn't a whole lot of diversity among those working in this space. There are a lot of developers working on graphics, rendering and layout. There are a lot of developers working on web standards. The intersection of those two groups if plotted as a Venn diagram, is pretty small. After all we really only have a few user agents out there: webkit (safari), blink (chrome), gecko (firefox), servo (?) and trident (internet explorer).
The web would benefit immensely from having many more of the devs in the former group involved. I personally would love to hear ideas and get contributions from developers that work on projects/technologies like qt and wpf.
You might find this academic paper from James Mickens interesting, which explores this exact idea in detail:
http://sigops.org/sosp/sosp11/current/2011-Cascais/printable...
Ugh, that's such a defeatist attitude. And it seems unfounded. Most developers use some form of abstraction on top of native events, such as jQuery or React.
I wish we could move towards a model where browser vendors would expose low level APIs and let libraries implement simple interfaces on top of them. At the moment we end up having to write browser-specific hacks that "guess" the state of the world based on weird heuristics and browser sniffing: https://github.com/facebook/react/blob/master/src/browser/ev...