16 ms·

“The working group should not agree to freeze whatever syntax Chrome ships”

282 points by cylo 13y ago

coldtea 13y ago
Hah. Remember when Blink was announced, how some people said "competing engines would be good for the web"? And how the Blink team/Google paid lip service to improving the web going forward, better standards compliance, etc. 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. IE is catching up but limping. Webkit is not updating that fast anymore. Opera, nobody but 10 people ever cared about. Besides, they're just Blink now. Anybody holding their breaths for full ES6 support?
- briandh 13y ago
  An awful lot of Firefox users happen to value its "BS" plugin ecosystem quite heavily.
  - coldtea 13y ago
    They might (though the vast majority just uses 2-3 plugins at most, ad block etc, that could as well be merged into core). But this "awful lot of firefox users" is, in aggregate, awfully few judging from FF's sliding market share.
    - briandh 13y ago
      The type of users who value extensions heavily are the type that evangelize browsers, and the type whose friends and relatives ask them what browsers to use.
    - politician 13y ago
      Bringing Ad Block into the core would violate the wink, wink, nudge, nudge arrangement between Mozilla and their default search provider Google. If Mozilla did this, the value of being a default search provider in Firefox would fall to around zero, and Mozilla would close up shop as 90% of their revenues disappeared.
      - Wohui 13y ago
        Interesting, and concisely put. Now I'm wondering whether FF users are obliged to use google (the same way we get obliged to turn off adblock on sites we don't wish to hurt).
        sliverstorm 13y ago
        "Obligated" is the wrong word, but if your goal is to support FF then yes, you should probably use Google. Or perhaps donate instead.
        magicalist 13y ago
        I'm pretty sure at least Bing has a revenue sharing program with Mozilla for search results from the search bar (they did as of Firefox 4[1], at least). Google just won the auction to be the default. Not sure about the other default search engines, though. [1] http://arstechnica.com/information-technology/2010/10/citing-relevance-mozilla-to-include-bing-in-firefox-4-search-box/ http://arstechnica.com/information-technology/2010/10/citing...
      - fpgeek 13y ago
        Bringing Ad Block into the core also sounds like a violation of the browser abstraction to me. A browser is supposed to show me what I give it. Specifying and implementing policies about what content is "good" or "bad" and should be treated specially seems logically separate to me.
        coldtea 13y ago
        You realise that such features can come with a on/off setting right? Plus there's no such a "browser abstraction". A browser is just supposed to be useful for surfing the web, and if blocking ads is part of that, then so be it. Nobody talks about a "mailer abstraction" ("a mailer is supposed to show me what is coming into my account"), when mailers have built-in spam email filters. Not to mention that similar things already exist in browsers. Browsers eg. stop you going into "bad" content ("fishing", "malware" etc sites). They stop your visit, show you a warning page, and ask if you're sure you want to continue. Technically those are just other pages, they are content too (and sometimes they even have been labelled wrongly).
    - jasonlotito 13y ago
      You have an incredibly odd definition of "awfully few."
- matthewmacleod 13y ago
  This is a shallow misreading of the situation. "competing engines would be good for the web"? They will. 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. Plugin systems are key to a good browsing experience; Chrome includes almost entirely the same feature set, so your argument is void; and, overall, there's no evidence that Firefox is particularly burdened by anything. IE is catching up but limping. IE caught up already, and I don't see any evidence that it's "limping" Webkit is not updating that fast anymore. Well, there are fewer contributors now. But it's kind of hard to draw any conclusions about how fast it's updating given how little time has passed since Blink forked. Anybody holding their breaths for full ES6 support? Yep, we're making good progress, and Firefox 29/Chrome 33 are doing better than ever. Still work to be done, but the ES6 spec isn't even finished yet, so that's to be expected. In other words, chill out. Everything's looking pretty good, there are loads of excellent browsers available, and they're mostly getting better. It's not perfect, but what platform is?
  - lelandbatey 13y ago
    If I may chime in on this: > IE is catching up but limping. IE caught up already, and I don't see any evidence that it's limping. I actually kind of agree, and I'm surprising myself in saying that. Just from a consumers perspective, I found at least one place where IE offers something that I directly wanted to do that couldn't be done on any other browser. I wanted to watch a HD Netflix on my laptop, but the Silverlight client had no hardware acceleration so it played terribly. Turns out, there is a hardware accelerated HTML5 version of Netflix that's only usable using IE since only IE has the necessary DRM. I was quite surprised. Ignoring the potential ethical quagmire here, I thought it was interesting that there was something where IE gave me a better experience.
    - fpgeek 13y ago
      I believe that hardware-accelerated HTML5 version of Netflix is also used on ChromeOS (since Silverlight isn't an option). It surprises me a bit to hear that the same doesn't happen with desktop Chrome.
- masklinn 13y ago
  > Anybody holding their breaths for full ES6 support? For which browser? Because currently, Gecko leads by a half marathon, and it's a marathon: http://kangax.github.io/es5-compat-table/es6/ http://kangax.github.io/es5-compat-table/es6/
chucknelson 13y ago
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? 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.
- bzbarsky 13y ago
  From the shadow DOM spec author: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ay9tVGRa8Rg/jPv0j06mP7EJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d... There's been a lack of progress in that it's taking a while, but there are a bunch of still-open unresolved issues... The problem with big complex features. ;)
- Helianthus 13y ago
  They're commenting in this topic, and they seem clueless as to why anyone would object at all.
fidotron 13y ago
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. The recent arguments regarding Adobe's arbitrary region stuff were very enlightening on this.
- jlongster 13y ago
  Mozilla has a vested interest in keeping the web a "document viewer platform"? Are you serious? Have you even heard of Firefox OS?
  - chrisrhoden 13y ago
    > while almost every other web player (except Mozilla)
    - jlongster 13y ago
      Oops, my bad. I didn't see "except". Ignore this! (assuming that it wasn't edited in :))
- RivieraKid 13y ago
  Exactly my thoughts. Web is a shitty app platform. And because it's a decentralized platform – the specification is developed separately from the implementations – it's moving forward too slowly. Currently, the native platforms and the web is a mess imho. Tons of web standards, android, ios, linux, windows, osx, etc. Web and native platforms have different strenghts but there's no platform that combines them. I wish there was one solid, well-designed platform for both interactive documents and applications and for both mobile devices and desktops. I'm (no longer) a fan of Google, but I'm beginning to think that if Google did this with Chrome, it would be a positive thing. Imagine the massive amount of programmer man-hours it would save.
  - pcwalton 13y ago
    > I'm (no longer) a fan of Google, but I'm beginning to think that if Google did this with Chrome, it would be a positive thing. Just so we're clear, you think that it would be a positive thing if Google unilaterally dictated Web standards by using its market power?
bryanlarsen 13y ago
Here's the reply: http://lists.w3.org/Archives/Public/www-style/2014Feb/0138.html http://lists.w3.org/Archives/Public/www-style/2014Feb/0138.h... 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." the Shadow DOM is pretty awesome, so I'll agree with the "benefit to authors sufficiently great" part. No comment on the rest.
- mcphage 13y ago
  This part of his reply annoyed me: "Attributing an ultimatum to my words is blatantly violating the Principle of Charity, especially since I've very explicitly clarified that I'm talking about the latter." Given his words were "Whatever API gets shipped will be frozen almost immediately. If you want to suggest name changes, as we brainstormed a bit at the f2f, do so RIGHT NOW or forever hold your peace." ... I'm a proponent of the principle of charity, but I don't know how to read that as anything other than an ultimatum.
  - chc 13y ago
    This is the other way of reading it: He's essentially saying, "Once this is shipped, the cat will be out of the bag and we will not be able to put it back in, so if you need the cat for something, you should do it now." That's not what is traditionally meant by "ultimatum," because an ultimatum implies that you want someone to do something and will do something else to injure them if they fail to meet your demands.
    - deleted 13y ago
      [deleted]
    - agwa 13y ago
      Your cat analogy still sounds like an ultimatum to me: threatening someone with not being able to work with the cat unless they acquiesce to their demand to work with the cat on a very short timeframe. Here's how the email fits your definition of an ultimatum: Demand: that the working group suggest changes to the proposal "RIGHT NOW." Injury if they don't comply: Google will ship the API anyways and freeze it so the working group can't later change it without breaking compatibility with a major web browser.
deleted 13y ago
[deleted]
- deleted 13y ago
  [deleted]
sw87 13y ago
Everyday a little bit closer, Google the new Microsoft. Not surprising.
- chc 13y ago
  Were you not around during the dark days of IE? "Pushing for quick progress on standards" was not exactly a major complaint people had against them.
  - chadwickthebold 13y ago
    I thought the issue was exactly that - that MS pushed for adoption of proto-standards before there was any sort of agreement on how they should actually be interpreted/implemented.
    - chc 13y ago
      Not exactly. The original problem with Microsoft's behavior was that Microsoft simply ignored standards that did exist and replaced them with subtly different standards of their own, so that they broke standards-compliant pages. They also pushed for proprietary technologies that they wouldn't allow others to use, like ActiveX and VBScript, but their breaking standards was worse. The second problem was that once Microsoft had achieved dominance, it stopped adding anything at all to IE. This made the Web platform largely stagnant for years. At no point was the problem "Microsoft came up with this cool new idea and implemented it before the standards bodies had the requisite seven years to agree on it." That's what Firefox and Safari were doing, and most people agreed that it was pretty good. These ideas Firefox and Safari came up with became HTML5. In fact, so did one idea Microsoft had that didn't break existing standards — XMLHttpRequest.
      - saurik 13y ago
        This is a rewrite of history: if you actually read the material published at the time, Netscape ignored the standards (even actively scoffing at them), and Microsoft's IE was seen as the white knight that actually cared enough to be on the mailing list with the standards body, working on their DTDs in public. Now, as everyone is always "citation needed" on this, as maintaining this myth is a much stronger goal for most people than doing even minimal backing research, here are some places I've talked about this before in more detail, the second link containing a very large number of citations if you go through to the bottom of the thread. https://news.ycombinator.com/item?id=5216141 https://news.ycombinator.com/item?id=5216141 https://news.ycombinator.com/item?id=5716787 https://news.ycombinator.com/item?id=5716787 Your comment about VBScript is silly, given that JavaScript was also non-standard Netscape-specific Java-laden ludicrousness that also "broke the web" (script elements were implemented in a way that required special hacks to an HTML parser to even parse due to nested < having a different meaning, and done without any requirement for backwards-compatibility to ones that would see the content as part of the document). It was only due to Microsoft's JScript (ehich went hand-in-hand with VBScript and ActiveX in the same way JavaScript worked with Java as "LiveScript" in Netscape) that ECMAScript got standardized at all. Seriously: I simply don't understand why everyone perpetuates this madness when you can't substantiate any of it if you look at the actual history... every comment bashing IE always repeats this stuff, so everyone thinks of it as gospel truth, but it really is all just myth at this point: "citation needed".
potch 13y ago
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.
- camus2 13y ago
  the problem is the web today is not what a proper application plateform should be. Developpers have waited long enough, we need more features and it takes way to long for the W3C to deliver. At the same time, HTML5 was a coup orchestrated by the Whatwg on the future XHTML spec, It was a mistake in my opinion because the original W3C spec was way better as we would not have the discussion we are having today about web components and the shadow dom if the W3C spec had been chosen. So I dont know. Is google way of doing things short-sided? or does it really solves some issues? Time will tell. but maybe the lean approach the Whatwg took wasnt that "future proof" after all.
  - macspoofing 13y ago
    >we need more features and it takes way to long for the W3C to deliver We also need features that work across all major browsers.
    - johnward 13y ago
      It's kind of a catch22. We do need features to work across all browsers but the standards body moves to slowly. So vendors push out features they think are good. Others implement them. This is how we end up with multiple vendor prefixes. Then eventually the standards group gets around to accepting it and the vendors update to use the standard. Waiting for w3c might be the "right" way to develop standards but it also slows progress. I'm not sure which is worse. Even using the vendor prefix process things work in more browsers now than they did in the past.
gress 13y ago
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. This is the tale of the scorpion and the frog playing itself out as usual. http://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog http://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog
donrhummy 13y ago
Shadow DOM is a very, very bad idea. http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ It kills cross-browser compatibility, kills standards (since they're unreachable, undocumented elements that can handle input, interaction and affect other elements.
- badman_ting 13y ago
  It's starting to dawn on me what this will really be used for, and I can't say I'm stoked about it. But the article you've linked to seems pretty upbeat about the whole thing.
  - grayrest 13y ago
    Author of the article is the spec author.
  - donrhummy 13y ago
    I linked to an article that explains what it is and left it to you (the reader) to decide if it's good or bad. I believe it is a very bad thing.
- ivan_gammel 13y ago
  Even if it will become a standard, it may be complete evil. This concept is quite complicated for regular developer, so some day we'll see petabytes of cryptic, totally undebuggable markup. It should not be done in that way.
kevingadd 13y ago
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.
- cromwellian 13y ago
  On the other hand, the Mozilla counter proposal, which was trying to do low-latency audio by using Javascript as a DSP was pretty awful. It's like saying you'll do 3D by handing a framebuffer to JS and doing rasterization in software. "Forcing it through the standards process" sounds like the kind of rhetoric Republicans use when bills get passed they don't like.
  - kevingadd 13y ago
    Web Audio API has a similar mechanism for generating samples with JS and it's just as bad. In fact, Web Audio is worse for playback of JS-synthesized audio, not better. And lots of use cases demand playback of JS-synthesized audio: emulators, custom audio codecs, synths, etc. The Mozilla API did one or two things and did them adequately; it did them by extending an existing API (the <audio> element). Use cases it didn't cover could have been handled with the introduction of new APIs or extensions to existing APIs. The Web Audio API introduced an interconnected web of dozens of poorly tested, poorly specified components that covered some arbitrary subset of cases users care about. Most of the oversights still haven't been fixed and the spec is still full of unaddressed issues and deficiencies.
    - cromwellian 13y ago
      >Web Audio API has a similar mechanism for generating samples with JS and it's just as bad. In fact, Web Audio is worse for playback of JS-synthesized audio, not better. And lots of use cases demand playback of JS-synthesized audio: emulators, custom audio codecs, synths, etc. Generating audio samples via JS is an escape hatch, the same way rasterizing to a raw framebuffer is an escape hatch. If your system had audio acceleration hardware, and many systems do (e.g. DirectSound/OpenAL), you want to leverage that. If you are deploying a game to a mobile device, the last thing you want to do is waste CPU cycles burning JS to do DSP effects in software. This is especially awful for low end phones like the ones that Firefox OS runs on. Latency on audio is already terrible, you don't want the browser UI event loop involved IMHO in processing it to feed it. Maybe if you had speced it being available to Web Workers without needing the UI thread involved it would make more sense. >The Web Audio API introduced an interconnected web of dozens of poorly tested, poorly specified components that covered some arbitrary subset of cases users care about The arbitrary subset being, those that have been on OSX for years? AFAIK, Chris Rogers developed Web Audio based on years of experience working on Core Audio at Apple, and therefore, at minimum, it represents at least some feedback from the use cases of the professional audio market, at the very least, Apple's own products like Garage Band and Logic Express which sit atop Core Audio. You assert that the other use cases could have been handled by just extending existing APIs, but to me this argument sounds like the following: "You've just dumped this massively complex WebGL API on us, it has hundreds of untested functions. It would be better to just have <canvas> or <img> with a raw array that you manipulate with JS. Any other functions could be done [hand-wave] by just bolting on additional higher level apis. Like, if you want to draw a polygon, we'd add that." APIs like Core Audio, Direct Sound, OpenGL have evolved because of low level optimization to match the API to what the hardware can accelerate efficiently. In many cases, bidirectional, so that HW influences the API and vice-versa. Putting the burden on the WG to reinvent what has already been done for years is the wrong way to go about it. Audio is a solved problem outside JS, all that was needed was good idiomatic bindings for either Core Audio, OpenAL, or DirectSound. Whenever I see these threads on HN, I always get a sense of a big dose of NIH from Mozilla. Whenever anyone else proposes a spec, there's always a complaint about complexity, like Republicans complaining about laws because they are too long, when in reality, they don't like them either for ideological reasons, or political ones. Mozilla is trying to build a web-based platform for competing with native apps. You can see it in asm.js and Firefox OS. And they are not going to get there if they shy away from doing the right things because they are complex. Mobile devices need all the hardware acceleration they can get, and specing out a solution that requires JS to do DSP sound processing is just an egregious waste of battery life and cycles IMHO for a low end web-OS based mobile HW.
lmm 13y ago
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.
- MDCore 13y ago
  It sounds like you're trying to say that fans of JavaScript don't like freezing syntax but that that is disingenuous because JavaScript is the result of a frozen syntax thrown together in three days. Is that accurate so far? So... freezing something and throwing it out there is good? Or finding broad consensus is good? I can't tell which approach you're going for. Which "this" process are you referring to not having happened back in 1990?
ChuckMcM 13y ago
So Google is taking their cues from the Internet Explorer playbook. 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. 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.
- MichaelGG 13y ago
  When did the IETF process change? From looking at SIP (with all its combined RFCs, it's one of the largest standards), there's plenty of insane cruft. There's even an RFC that takes delight in coming up with crazy messages that are technically valid and suggestions on how implementations should try to guess the intent of the message. SIP goes back to the late 90s, so the process must have been corrupted by then.
  - ChuckMcM 13y ago
    Understand I've got some emotional baggage here[1] :-) It changed when it became more relevant than ISO, I put it right at the end of the IP/ISO war, probably 1997, 1998. Basically up until that point the people who were motivated to subvert standards efforts pretty much ignored them, they had their own transport (OSI), their own mail services (X.400) their own directory services (X.500) and basically every else. IP and its "hacked together" stuff was pretty much universally considered "on its way out" by the "players." When it became clear that IP wasn't on its way out, and in fact it was the burdensome and complex OSI standards that were going no where, the movers and shakers switched tactics, invade the IETF meetings (which did have an abusible community participation process) and drove the organization off a cliff in order to preserve their interests. A really really good example of that was SIP and IPV6 both of which started out pretty reasonably, (because neither the phone companies nor the networking companies thought either was going to be relevant in the 7 layer OSI world) until whoops, that is where the action is so lets get in there and "fix" it. [1] I sat in front of 500 engineers and explained out Sun was prepared to hand over any proprietary interest whatsoever in the RPC and XDR stacks (which had been "standards track" RFCs before that has a more explicit meaning, and so had sat there implemented by everyone but not officially 'standard') only to have Microsoft and the guy they had hoisted out of Apollo/HP, Paul Leach, invest thousands of dollars in derailing that offering, for no reason other than to try to resist anything compatible being out there. It was redonkulous in its pursuit of killing ONC/RPC at every venue. But like I said, that just made it personal for me.
cromwellian 13y ago
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. 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. 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.
ndesaulniers 13y ago
I was happy to see this from the link in the email: 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. 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.
- erichocean 13y ago
  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. For the feature's we're talking about (JS methods and CSS stuff), doing so will mean that effectively no web authors use it. It's no different than requiring a plugin to view content. Anything hidden behind a feature flag might as well not exist, at least for those two categories. For dev tools, stuff like that? Sure, feature flags are the way to go.
tiglionabbit 13y ago
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. http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/ http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-...
onethree 13y ago
"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...
ollysb 13y ago
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!
- josteink 13y ago
  And wouldn't it be awesome if multiple parties was able to read through a draft and make comments on it and provide constructive feedback before it was finalized and pushed into production on the web, to be supported for all eternity? That way we could have a good implementation of this whole thing. Sadly so far everything except the "rush this unfinished thing into production"-part is missing. Obviously Google only see their own implementation, think "all is good" and don't give a rats ass about anyone else and their opinions, but here on HN we should have a wider perspective.
josteink 13y ago
I've said it before and I'll say it again: Chrome is the worst thing which has happened to the web because of what it allows Google to do. 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. 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. This breeds monsters like HTTP2.0^W SPDY^W technogizzwizz kitchensink internet everything protocol. This is much worse than anything MSIE ever did.
rkangel 13y ago
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. 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.
bsaul 13y ago
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.
- alimoeeny 13y ago
  what do you use instead, which has better ram and cpu footprint?
  - bsaul 13y ago
    Well, actually chrome was consuming about 1 gig of ram (if you're counting all the "Chrome helpers" processes) and 2% constant CPU when i had absolutely no page opened. So pretty much anything else is better (i'm on safari right now and it feels extremely light). Note that it's not just me : https://productforums.google.com/forum/#!topic/chrome/y8VTVHmkuzU https://productforums.google.com/forum/#!topic/chrome/y8VTVH...
youngtaff 13y ago
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 - http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.html http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.h... - and included the Blink thread that discusses Google's position and issues in more detail https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ay9tVGRa8Rg https://groups.google.com/a/chromium.org/forum/#!topic/blink... - read Adam Barth's comments if nothing else
RyanMcGreal 13y ago
A bit late to the party, but this seems relevant: "[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." http://diveintohtml5.info/past.html http://diveintohtml5.info/past.html
CmonDev 13y ago
Nothing wrong with trying to do something different. Committees are too slow.

282 points by cylo 13y ago

Hah. Remember when Blink was announced, how some people said "competing engines would be good for the web"? And how the Blink team/Google paid lip service to improving the web going forward, better standards compliance, etc. 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. IE is catching up but limping. Webkit is not updating that fast anymore. Opera, nobody but 10 people ever cared about. Besides, they're just Blink now. Anybody holding their breaths for full ES6 support?

briandh 13y ago
An awful lot of Firefox users happen to value its "BS" plugin ecosystem quite heavily.
- coldtea 13y ago
  They might (though the vast majority just uses 2-3 plugins at most, ad block etc, that could as well be merged into core). But this "awful lot of firefox users" is, in aggregate, awfully few judging from FF's sliding market share.
  - briandh 13y ago
    The type of users who value extensions heavily are the type that evangelize browsers, and the type whose friends and relatives ask them what browsers to use.
  - politician 13y ago
    Bringing Ad Block into the core would violate the wink, wink, nudge, nudge arrangement between Mozilla and their default search provider Google. If Mozilla did this, the value of being a default search provider in Firefox would fall to around zero, and Mozilla would close up shop as 90% of their revenues disappeared.
    - Wohui 13y ago
      Interesting, and concisely put. Now I'm wondering whether FF users are obliged to use google (the same way we get obliged to turn off adblock on sites we don't wish to hurt).
      - sliverstorm 13y ago
        "Obligated" is the wrong word, but if your goal is to support FF then yes, you should probably use Google. Or perhaps donate instead.
        magicalist 13y ago
        I'm pretty sure at least Bing has a revenue sharing program with Mozilla for search results from the search bar (they did as of Firefox 4[1], at least). Google just won the auction to be the default. Not sure about the other default search engines, though. [1] http://arstechnica.com/information-technology/2010/10/citing-relevance-mozilla-to-include-bing-in-firefox-4-search-box/ http://arstechnica.com/information-technology/2010/10/citing...
    - fpgeek 13y ago
      Bringing Ad Block into the core also sounds like a violation of the browser abstraction to me. A browser is supposed to show me what I give it. Specifying and implementing policies about what content is "good" or "bad" and should be treated specially seems logically separate to me.
      - coldtea 13y ago
        You realise that such features can come with a on/off setting right? Plus there's no such a "browser abstraction". A browser is just supposed to be useful for surfing the web, and if blocking ads is part of that, then so be it. Nobody talks about a "mailer abstraction" ("a mailer is supposed to show me what is coming into my account"), when mailers have built-in spam email filters. Not to mention that similar things already exist in browsers. Browsers eg. stop you going into "bad" content ("fishing", "malware" etc sites). They stop your visit, show you a warning page, and ask if you're sure you want to continue. Technically those are just other pages, they are content too (and sometimes they even have been labelled wrongly).
  - jasonlotito 13y ago
    You have an incredibly odd definition of "awfully few."
matthewmacleod 13y ago
This is a shallow misreading of the situation. "competing engines would be good for the web"? They will. 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. Plugin systems are key to a good browsing experience; Chrome includes almost entirely the same feature set, so your argument is void; and, overall, there's no evidence that Firefox is particularly burdened by anything. IE is catching up but limping. IE caught up already, and I don't see any evidence that it's "limping" Webkit is not updating that fast anymore. Well, there are fewer contributors now. But it's kind of hard to draw any conclusions about how fast it's updating given how little time has passed since Blink forked. Anybody holding their breaths for full ES6 support? Yep, we're making good progress, and Firefox 29/Chrome 33 are doing better than ever. Still work to be done, but the ES6 spec isn't even finished yet, so that's to be expected. In other words, chill out. Everything's looking pretty good, there are loads of excellent browsers available, and they're mostly getting better. It's not perfect, but what platform is?
- lelandbatey 13y ago
  If I may chime in on this: > IE is catching up but limping. IE caught up already, and I don't see any evidence that it's limping. I actually kind of agree, and I'm surprising myself in saying that. Just from a consumers perspective, I found at least one place where IE offers something that I directly wanted to do that couldn't be done on any other browser. I wanted to watch a HD Netflix on my laptop, but the Silverlight client had no hardware acceleration so it played terribly. Turns out, there is a hardware accelerated HTML5 version of Netflix that's only usable using IE since only IE has the necessary DRM. I was quite surprised. Ignoring the potential ethical quagmire here, I thought it was interesting that there was something where IE gave me a better experience.
  - fpgeek 13y ago
    I believe that hardware-accelerated HTML5 version of Netflix is also used on ChromeOS (since Silverlight isn't an option). It surprises me a bit to hear that the same doesn't happen with desktop Chrome.
masklinn 13y ago
> Anybody holding their breaths for full ES6 support? For which browser? Because currently, Gecko leads by a half marathon, and it's a marathon: http://kangax.github.io/es5-compat-table/es6/ http://kangax.github.io/es5-compat-table/es6/

chucknelson 13y ago

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? 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.

bzbarsky 13y ago
From the shadow DOM spec author: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ay9tVGRa8Rg/jPv0j06mP7EJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d... There's been a lack of progress in that it's taking a while, but there are a bunch of still-open unresolved issues... The problem with big complex features. ;)
Helianthus 13y ago
They're commenting in this topic, and they seem clueless as to why anyone would object at all.

fidotron 13y ago

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. The recent arguments regarding Adobe's arbitrary region stuff were very enlightening on this.

jlongster 13y ago
Mozilla has a vested interest in keeping the web a "document viewer platform"? Are you serious? Have you even heard of Firefox OS?
- chrisrhoden 13y ago
  > while almost every other web player (except Mozilla)
  - jlongster 13y ago
    Oops, my bad. I didn't see "except". Ignore this! (assuming that it wasn't edited in :))
RivieraKid 13y ago
Exactly my thoughts. Web is a shitty app platform. And because it's a decentralized platform – the specification is developed separately from the implementations – it's moving forward too slowly. Currently, the native platforms and the web is a mess imho. Tons of web standards, android, ios, linux, windows, osx, etc. Web and native platforms have different strenghts but there's no platform that combines them. I wish there was one solid, well-designed platform for both interactive documents and applications and for both mobile devices and desktops. I'm (no longer) a fan of Google, but I'm beginning to think that if Google did this with Chrome, it would be a positive thing. Imagine the massive amount of programmer man-hours it would save.
- pcwalton 13y ago
  > I'm (no longer) a fan of Google, but I'm beginning to think that if Google did this with Chrome, it would be a positive thing. Just so we're clear, you think that it would be a positive thing if Google unilaterally dictated Web standards by using its market power?

bryanlarsen 13y ago

Here's the reply: http://lists.w3.org/Archives/Public/www-style/2014Feb/0138.html http://lists.w3.org/Archives/Public/www-style/2014Feb/0138.h... 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." the Shadow DOM is pretty awesome, so I'll agree with the "benefit to authors sufficiently great" part. No comment on the rest.

mcphage 13y ago
This part of his reply annoyed me: "Attributing an ultimatum to my words is blatantly violating the Principle of Charity, especially since I've very explicitly clarified that I'm talking about the latter." Given his words were "Whatever API gets shipped will be frozen almost immediately. If you want to suggest name changes, as we brainstormed a bit at the f2f, do so RIGHT NOW or forever hold your peace." ... I'm a proponent of the principle of charity, but I don't know how to read that as anything other than an ultimatum.
- chc 13y ago
  This is the other way of reading it: He's essentially saying, "Once this is shipped, the cat will be out of the bag and we will not be able to put it back in, so if you need the cat for something, you should do it now." That's not what is traditionally meant by "ultimatum," because an ultimatum implies that you want someone to do something and will do something else to injure them if they fail to meet your demands.
  - deleted 13y ago
    [deleted]
  - agwa 13y ago
    Your cat analogy still sounds like an ultimatum to me: threatening someone with not being able to work with the cat unless they acquiesce to their demand to work with the cat on a very short timeframe. Here's how the email fits your definition of an ultimatum: Demand: that the working group suggest changes to the proposal "RIGHT NOW." Injury if they don't comply: Google will ship the API anyways and freeze it so the working group can't later change it without breaking compatibility with a major web browser.

deleted 13y ago

[deleted]

deleted 13y ago
[deleted]

sw87 13y ago

Everyday a little bit closer, Google the new Microsoft. Not surprising.

chc 13y ago
Were you not around during the dark days of IE? "Pushing for quick progress on standards" was not exactly a major complaint people had against them.
- chadwickthebold 13y ago
  I thought the issue was exactly that - that MS pushed for adoption of proto-standards before there was any sort of agreement on how they should actually be interpreted/implemented.
  - chc 13y ago
    Not exactly. The original problem with Microsoft's behavior was that Microsoft simply ignored standards that did exist and replaced them with subtly different standards of their own, so that they broke standards-compliant pages. They also pushed for proprietary technologies that they wouldn't allow others to use, like ActiveX and VBScript, but their breaking standards was worse. The second problem was that once Microsoft had achieved dominance, it stopped adding anything at all to IE. This made the Web platform largely stagnant for years. At no point was the problem "Microsoft came up with this cool new idea and implemented it before the standards bodies had the requisite seven years to agree on it." That's what Firefox and Safari were doing, and most people agreed that it was pretty good. These ideas Firefox and Safari came up with became HTML5. In fact, so did one idea Microsoft had that didn't break existing standards — XMLHttpRequest.
    - saurik 13y ago
      This is a rewrite of history: if you actually read the material published at the time, Netscape ignored the standards (even actively scoffing at them), and Microsoft's IE was seen as the white knight that actually cared enough to be on the mailing list with the standards body, working on their DTDs in public. Now, as everyone is always "citation needed" on this, as maintaining this myth is a much stronger goal for most people than doing even minimal backing research, here are some places I've talked about this before in more detail, the second link containing a very large number of citations if you go through to the bottom of the thread. https://news.ycombinator.com/item?id=5216141 https://news.ycombinator.com/item?id=5216141 https://news.ycombinator.com/item?id=5716787 https://news.ycombinator.com/item?id=5716787 Your comment about VBScript is silly, given that JavaScript was also non-standard Netscape-specific Java-laden ludicrousness that also "broke the web" (script elements were implemented in a way that required special hacks to an HTML parser to even parse due to nested < having a different meaning, and done without any requirement for backwards-compatibility to ones that would see the content as part of the document). It was only due to Microsoft's JScript (ehich went hand-in-hand with VBScript and ActiveX in the same way JavaScript worked with Java as "LiveScript" in Netscape) that ECMAScript got standardized at all. Seriously: I simply don't understand why everyone perpetuates this madness when you can't substantiate any of it if you look at the actual history... every comment bashing IE always repeats this stuff, so everyone thinks of it as gospel truth, but it really is all just myth at this point: "citation needed".

potch 13y ago

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.

camus2 13y ago
the problem is the web today is not what a proper application plateform should be. Developpers have waited long enough, we need more features and it takes way to long for the W3C to deliver. At the same time, HTML5 was a coup orchestrated by the Whatwg on the future XHTML spec, It was a mistake in my opinion because the original W3C spec was way better as we would not have the discussion we are having today about web components and the shadow dom if the W3C spec had been chosen. So I dont know. Is google way of doing things short-sided? or does it really solves some issues? Time will tell. but maybe the lean approach the Whatwg took wasnt that "future proof" after all.
- macspoofing 13y ago
  >we need more features and it takes way to long for the W3C to deliver We also need features that work across all major browsers.
  - johnward 13y ago
    It's kind of a catch22. We do need features to work across all browsers but the standards body moves to slowly. So vendors push out features they think are good. Others implement them. This is how we end up with multiple vendor prefixes. Then eventually the standards group gets around to accepting it and the vendors update to use the standard. Waiting for w3c might be the "right" way to develop standards but it also slows progress. I'm not sure which is worse. Even using the vendor prefix process things work in more browsers now than they did in the past.

gress 13y ago

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. This is the tale of the scorpion and the frog playing itself out as usual. http://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog http://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog

donrhummy 13y ago

Shadow DOM is a very, very bad idea. http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ It kills cross-browser compatibility, kills standards (since they're unreachable, undocumented elements that can handle input, interaction and affect other elements.

badman_ting 13y ago
It's starting to dawn on me what this will really be used for, and I can't say I'm stoked about it. But the article you've linked to seems pretty upbeat about the whole thing.
- grayrest 13y ago
  Author of the article is the spec author.
- donrhummy 13y ago
  I linked to an article that explains what it is and left it to you (the reader) to decide if it's good or bad. I believe it is a very bad thing.
ivan_gammel 13y ago
Even if it will become a standard, it may be complete evil. This concept is quite complicated for regular developer, so some day we'll see petabytes of cryptic, totally undebuggable markup. It should not be done in that way.

kevingadd 13y ago

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.

cromwellian 13y ago
On the other hand, the Mozilla counter proposal, which was trying to do low-latency audio by using Javascript as a DSP was pretty awful. It's like saying you'll do 3D by handing a framebuffer to JS and doing rasterization in software. "Forcing it through the standards process" sounds like the kind of rhetoric Republicans use when bills get passed they don't like.
- kevingadd 13y ago
  Web Audio API has a similar mechanism for generating samples with JS and it's just as bad. In fact, Web Audio is worse for playback of JS-synthesized audio, not better. And lots of use cases demand playback of JS-synthesized audio: emulators, custom audio codecs, synths, etc. The Mozilla API did one or two things and did them adequately; it did them by extending an existing API (the <audio> element). Use cases it didn't cover could have been handled with the introduction of new APIs or extensions to existing APIs. The Web Audio API introduced an interconnected web of dozens of poorly tested, poorly specified components that covered some arbitrary subset of cases users care about. Most of the oversights still haven't been fixed and the spec is still full of unaddressed issues and deficiencies.
  - cromwellian 13y ago
    >Web Audio API has a similar mechanism for generating samples with JS and it's just as bad. In fact, Web Audio is worse for playback of JS-synthesized audio, not better. And lots of use cases demand playback of JS-synthesized audio: emulators, custom audio codecs, synths, etc. Generating audio samples via JS is an escape hatch, the same way rasterizing to a raw framebuffer is an escape hatch. If your system had audio acceleration hardware, and many systems do (e.g. DirectSound/OpenAL), you want to leverage that. If you are deploying a game to a mobile device, the last thing you want to do is waste CPU cycles burning JS to do DSP effects in software. This is especially awful for low end phones like the ones that Firefox OS runs on. Latency on audio is already terrible, you don't want the browser UI event loop involved IMHO in processing it to feed it. Maybe if you had speced it being available to Web Workers without needing the UI thread involved it would make more sense. >The Web Audio API introduced an interconnected web of dozens of poorly tested, poorly specified components that covered some arbitrary subset of cases users care about The arbitrary subset being, those that have been on OSX for years? AFAIK, Chris Rogers developed Web Audio based on years of experience working on Core Audio at Apple, and therefore, at minimum, it represents at least some feedback from the use cases of the professional audio market, at the very least, Apple's own products like Garage Band and Logic Express which sit atop Core Audio. You assert that the other use cases could have been handled by just extending existing APIs, but to me this argument sounds like the following: "You've just dumped this massively complex WebGL API on us, it has hundreds of untested functions. It would be better to just have <canvas> or <img> with a raw array that you manipulate with JS. Any other functions could be done [hand-wave] by just bolting on additional higher level apis. Like, if you want to draw a polygon, we'd add that." APIs like Core Audio, Direct Sound, OpenGL have evolved because of low level optimization to match the API to what the hardware can accelerate efficiently. In many cases, bidirectional, so that HW influences the API and vice-versa. Putting the burden on the WG to reinvent what has already been done for years is the wrong way to go about it. Audio is a solved problem outside JS, all that was needed was good idiomatic bindings for either Core Audio, OpenAL, or DirectSound. Whenever I see these threads on HN, I always get a sense of a big dose of NIH from Mozilla. Whenever anyone else proposes a spec, there's always a complaint about complexity, like Republicans complaining about laws because they are too long, when in reality, they don't like them either for ideological reasons, or political ones. Mozilla is trying to build a web-based platform for competing with native apps. You can see it in asm.js and Firefox OS. And they are not going to get there if they shy away from doing the right things because they are complex. Mobile devices need all the hardware acceleration they can get, and specing out a solution that requires JS to do DSP sound processing is just an egregious waste of battery life and cycles IMHO for a low end web-OS based mobile HW.

lmm 13y ago

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.

MDCore 13y ago
It sounds like you're trying to say that fans of JavaScript don't like freezing syntax but that that is disingenuous because JavaScript is the result of a frozen syntax thrown together in three days. Is that accurate so far? So... freezing something and throwing it out there is good? Or finding broad consensus is good? I can't tell which approach you're going for. Which "this" process are you referring to not having happened back in 1990?

ChuckMcM 13y ago

So Google is taking their cues from the Internet Explorer playbook. 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. 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.

MichaelGG 13y ago
When did the IETF process change? From looking at SIP (with all its combined RFCs, it's one of the largest standards), there's plenty of insane cruft. There's even an RFC that takes delight in coming up with crazy messages that are technically valid and suggestions on how implementations should try to guess the intent of the message. SIP goes back to the late 90s, so the process must have been corrupted by then.
- ChuckMcM 13y ago
  Understand I've got some emotional baggage here[1] :-) It changed when it became more relevant than ISO, I put it right at the end of the IP/ISO war, probably 1997, 1998. Basically up until that point the people who were motivated to subvert standards efforts pretty much ignored them, they had their own transport (OSI), their own mail services (X.400) their own directory services (X.500) and basically every else. IP and its "hacked together" stuff was pretty much universally considered "on its way out" by the "players." When it became clear that IP wasn't on its way out, and in fact it was the burdensome and complex OSI standards that were going no where, the movers and shakers switched tactics, invade the IETF meetings (which did have an abusible community participation process) and drove the organization off a cliff in order to preserve their interests. A really really good example of that was SIP and IPV6 both of which started out pretty reasonably, (because neither the phone companies nor the networking companies thought either was going to be relevant in the 7 layer OSI world) until whoops, that is where the action is so lets get in there and "fix" it. [1] I sat in front of 500 engineers and explained out Sun was prepared to hand over any proprietary interest whatsoever in the RPC and XDR stacks (which had been "standards track" RFCs before that has a more explicit meaning, and so had sat there implemented by everyone but not officially 'standard') only to have Microsoft and the guy they had hoisted out of Apollo/HP, Paul Leach, invest thousands of dollars in derailing that offering, for no reason other than to try to resist anything compatible being out there. It was redonkulous in its pursuit of killing ONC/RPC at every venue. But like I said, that just made it personal for me.

cromwellian 13y ago

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. 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. 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.

ndesaulniers 13y ago

I was happy to see this from the link in the email: 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. 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.

erichocean 13y ago
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. For the feature's we're talking about (JS methods and CSS stuff), doing so will mean that effectively no web authors use it. It's no different than requiring a plugin to view content. Anything hidden behind a feature flag might as well not exist, at least for those two categories. For dev tools, stuff like that? Sure, feature flags are the way to go.

tiglionabbit 13y ago

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. http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/ http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-...

onethree 13y ago

"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...

ollysb 13y ago

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!

josteink 13y ago
And wouldn't it be awesome if multiple parties was able to read through a draft and make comments on it and provide constructive feedback before it was finalized and pushed into production on the web, to be supported for all eternity? That way we could have a good implementation of this whole thing. Sadly so far everything except the "rush this unfinished thing into production"-part is missing. Obviously Google only see their own implementation, think "all is good" and don't give a rats ass about anyone else and their opinions, but here on HN we should have a wider perspective.

josteink 13y ago

I've said it before and I'll say it again: Chrome is the worst thing which has happened to the web because of what it allows Google to do. 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. 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. This breeds monsters like HTTP2.0^W SPDY^W technogizzwizz kitchensink internet everything protocol. This is much worse than anything MSIE ever did.

rkangel 13y ago

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. 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.

bsaul 13y ago

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.

alimoeeny 13y ago
what do you use instead, which has better ram and cpu footprint?
- bsaul 13y ago
  Well, actually chrome was consuming about 1 gig of ram (if you're counting all the "Chrome helpers" processes) and 2% constant CPU when i had absolutely no page opened. So pretty much anything else is better (i'm on safari right now and it feels extremely light). Note that it's not just me : https://productforums.google.com/forum/#!topic/chrome/y8VTVHmkuzU https://productforums.google.com/forum/#!topic/chrome/y8VTVH...

youngtaff 13y ago

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 - http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.html http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.h... - and included the Blink thread that discusses Google's position and issues in more detail https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ay9tVGRa8Rg https://groups.google.com/a/chromium.org/forum/#!topic/blink... - read Adam Barth's comments if nothing else

RyanMcGreal 13y ago

A bit late to the party, but this seems relevant: "[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." http://diveintohtml5.info/past.html http://diveintohtml5.info/past.html

CmonDev 13y ago

Nothing wrong with trying to do something different. Committees are too slow.