The problem is the standards process exists to keep people from swinging their weight to force rushed/poorly thought-out technologies into a platform some already accuse of fragmentation and bloat. And to people who "But this is Google!" Throwing the process under the bus today because you think your favorite tech company can do no wrong screws everyone later when management changes. Management will change. The process is here to protect the web's interests regardless of whether any one actor's intent is good or not. If Google steamrolls everyone today, who will steamroll everyone tomorrow? The MPAA is on the W3C too.
Here's the reply: <a href="http://lists.w3.org/Archives/Public/www-style/2014Feb/0138.html" rel="nofollow">http://lists.w3.org/Archives/Public/www-style/2014Feb/0138.h...</a><p>the money quote: "We feel the
standard is sufficiently advanced, the remaining issues sufficiently
small, and the benefit to authors sufficiently great to justify
shipping sooner rather than later."<p>the Shadow DOM is pretty awesome, so I'll agree with the "benefit to authors sufficiently great" part. No comment on the rest.
So Google is taking their cues from the Internet Explorer playbook.<p>Having been in (and out) of standards wars at Sun and NetApp it really cries out how challenging doing "standard" stuff is. The original IETF standards process was really powerful at keeping out cruft, it included "fully documented" and "two or three interoperable implementations, of which source code must be available for at least two of them." The goal being that someone could sit down and write an implementation, and two there were at least two pre-existing implementations they could compare against for interoperability issues/questions and testing.<p>But standards break down when it comes to captured market share. If you're market share capture depends on your "value add", then you don't benefit if anyone can implement the same thing and you have to stay compatible with them.
Why is anyone acting the least bit surprised here? Google built Chrome for one reason and one reason only. So that they could control the development of web technologies.<p>This is the tale of the scorpion and the frog playing itself out as usual.<p><a href="http://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog" rel="nofollow">http://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog</a>
This is because Google are trying to turn Chrome into an app platform to rival Cocoa, while almost every other web player (except Mozilla) has a vested interest in keeping the web a document viewer platform.<p>The recent arguments regarding Adobe's arbitrary region stuff were very enlightening on this.
Hah.<p>Remember when Blink was announced, how some people said "competing engines would be good for the web"?<p>And how the Blink team/Google paid lip service to improving the web going forward, better standards compliance, etc.<p>Firefox is ahead in some ways, too burneded by BS like a plugin ecosystem (focus on browsing damnit) and non-native UI skins, on the other.<p>IE is catching up but limping.<p>Webkit is not updating that fast anymore.<p>Opera, nobody but 10 people ever cared about. Besides, they're just Blink now.<p>Anybody holding their breaths for full ES6 support?
The Blink team seems dead-set on repeating the mistakes they made with the Web Audio API (shipping an immature, vendor-specific API to the web without third-party feedback and then forcing it through a standards process, etc). Pretty frustrating.
Shadow DOM is a very, very bad idea.<p><a href="http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/" rel="nofollow">http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/</a><p>It kills cross-browser compatibility, kills standards (since they're unreachable, undocumented elements that can handle input, interaction and affect other elements.
Any "insiders" have comments on this? Is this the Chrome team just trying to keep pushing forward, or are they technically sticking to the referenced compatibility guidelines they published?<p>I'm just wondering if there has been a lack of progress with Shadow DOM and their solution is just go-go-go to get things moving.
Forget the technical content, or the political point here - that thread is worth reading just as an excellent example of how to conduct a civilised discussion even in a situation with serious potential for strife.<p>Of particular note is how, even though it does get a bit stressed in the middle, everyone very carefully allows the discussion to calm down and restate their points with no emotional content.
Rather than link to a comment from someone at Apple part way down the thread and starting 'burn the witch' style threads on HN perhaps the OP should have started at the beginning - <a href="http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.html" rel="nofollow">http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.h...</a> - and included the Blink thread that discusses Google's position and issues in more detail <a href="https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ay9tVGRa8Rg" rel="nofollow">https://groups.google.com/a/chromium.org/forum/#!topic/blink...</a> - read Adam Barth's comments if nothing else
Reading about google shipping unpolished things too fast in chrome makes me smile, since i've just decided to stop using it as of yesterday, after realizing how bloated that software has become ( cpu & ram wise ). Wonder if that's a coincidence.
"hi relevant standards authority, you're not working fast enough for our liking, so we're doing what we wan't and if you don't like it, too bad"
if this was anyone but google, there'd be a shitstorm...
I was happy to see this from the link in the email:<p>Vendor Prefixes
Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in about:flags until the feature is ready to be enabled by default. Mozilla has already embarked on a similar policy and the W3C CSS WG formed a rough consensus around a complementary policy.<p>I remember people getting worried that app developers might tell users to dig through their about:config equivalent to access the "full version" of this site. Glad that things are moving away from vendor prefixes. Kind of sad to see web audio still vendor prefixed (and the O'Reilly book shipped with the old API, lol!), but I assume that was implemented before the webkit/blink split.
Funny how the biggest opponents of this kind of thing seem to also be the biggest fans of Javascript, which was developed by freezing whatever syntax Netscape came up with in three days. If this had been the process back in 1990 the web would never have got off the ground.
I've said it before and I'll say it again:<p>Chrome is the worst thing which has happened to the web because of what it allows Google to do.<p>MSIE ruined and fragmented the web with non-standards because it was in Microsoft's interest at the time to hinder a successfull adaptation of the web.<p>Google however is fundamentally a web-company and now they are using Chrome to shoehorn anything which fits their company onto the open web without a standards-comitee in sight, or accepting any sort of reasonable feedback.<p>This breeds monsters like HTTP2.0^W SPDY^W technogizzwizz kitchensink internet everything protocol.<p>This is much worse than anything MSIE ever did.
On another note, how great is it going to be to have components you can reuse between angular, ember, jquery and the likes? A web-components.com repository would be awesome!
A bit late to the party, but this seems relevant:<p>"[W]hy do we have an <img> element? Why not an <icon> element? Or an <include> element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an <img> element? Quite simply, because Marc Andreessen shipped one, and shipping code wins."<p><a href="http://diveintohtml5.info/past.html" rel="nofollow">http://diveintohtml5.info/past.html</a>
Oh, it's about Hat and Cat. I first saw these at a talk on Shadow DOM and the future of the web by Rob Dodson.<p><a href="http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/" rel="nofollow">http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-...</a>
The current div-soup approach with massive JS enhancement is what is a bad idea. It abuses the document model and makes information less transparent, less semantically meaningful, and makes it hard to share and reuse components between sites due to leakage. It also makes debugging and reading the DOM in an inspector far more messy.<p>Scoped CSS and Shadow DOM clear up the leakage problems and introduce proper encapsulation to the web beyond heavyweight IFRAMES. The templating system lets documents expose information in transparent ways again, rather than executing a big ball of JS just to get the DOM in a state that is meaningful.<p>Web Development has been fundamentally broken for ages. The basic ideas to fix it have been discussed for years. Every day delayed is a day for more native encroachment.