8 ms·

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 alrea

by 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.
  - munificent 13y ago
    I don't know about the CSS stuff that spawned this thread, but the rest of the shadow DOM stuff is polyfilled to work in other browsers: https://github.com/Polymer/ShadowDOM https://github.com/Polymer/ShadowDOM
    - potch 13y ago
      This is speculation: The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. Think about what it takes to make DOM invisible in the browser in a polyfill- overriding every DOM method to filter out shadowed nodes. I've heard reports of 10x slowdowns on DOM operations with this polyfill in place. The kicker? Web Components (specifically Custom Elements) lose almost all their encapsulation without Shadow DOM. Those of us who are betting heavy on Web Components as The Future™ are pretty anxious about this.
      - munificent 13y ago
        > The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. I'm not sure what you mean by "moving forward quickly". They've been hammering on this in the public eye for over three years. How many more years of salary should they pay before they get it out the door? At some point, you just have to ship.
- potch 13y ago
  When the features don't work the same way in every browser, it hurts the platform. Poorly designed features are impossible to take back. (see also AppCache). Web Components is moving quickly, but there has to be an element of care. Shipping features before they're ready is driven by marketing and PR, not engineering maturity.
- gress 13y ago
  If you want a proprietary platform controlled by a single vendor, code for iOS or Android.
johnward 13y ago
So it's almost like the IE 6 days except that in this case the standards actually are influenced by Google instead of MS just doing whatever the hell it wanted. So slightly better but still not good. Plus if there is anyone I trust to do what is right for the user it's going to be Mozilla not Google.
- ajross 13y ago
  That argument seems isomorphic to demanding that all software design and feature innovation happen within the W3C commitee process. Certainly that's not how most successful features have worked historically...
  - potch 13y ago
    The historical processes boil down to: 1) Single Browser Ideates -> Single Browser Ships -> Time Passes -> Other Browsers Ship -> Standard. This caused delay in implementation and vendor prefix hell. 2) W3C Ideates -> W3C Bikesheds -> Browsers Implement. This causes things like AppCache that work on paper, but don't adequately cover developer use cases and address the needs of the platform. The ideal process (in my opinion) 1) Single Vendor Ideates -> W3C Evaluates/Refines -> Browsers Implement Under Feature Flags -> Standard -> Feature Flags are removed. This process, depending on the size/scope of the change, should take about 6mo to a year. For a permanent irrevocable change to a cross-browser API? That is mature and prudent. edit: formatting.
    - masklinn 13y ago
      You (2) is not correct. Most W3C specs are edited if not outright proposed by browser implementor teams. And of course nobody anywhere ever prevented browsers from shipping stuff under feature flags (most of ES6 was in Firefox since the days of FF3/FF4, with slightly different semantics, and with an opt-in behind a version flag for instance). Hixie (HTML5 editor, CSS Selectors Level 3 editor) works at Google since 2005 and worked at Opera before, Shadow DOM's editor is Google's Dimitri Glazkov
duaneb 13y ago
I don't think that people have double standards for Google, it's that the potential flaws aren't obvious.... Where's the competition and alternatives? We're stuck between making decisions too quickly and Google becoming the de facto standard. EDIT: To be clear, I find Google's actions in this regard to be surprisingly impolitic and ill-conceived. Anyone who reads it should have alarm bells.
- potch 13y ago
  Google should respect the desire of other parties to be given adequate time to review their proposals. Being told "you have to object NOW because we're going to ship" doesn't allow third parties to actually identify technical issues. It's like someone committing code without letting their peers review that code for flaws. It's a recipe for cementing flaws into the web platform. Intended or not, there is arrogance in the notion that external discussion of Google's proposal won't improve it.
  - ndesaulniers 13y ago
    It's like someone force pushing to production without letting their peers review that code for flaws. FTFY
    - username223 13y ago
      I believe SPDY, er, Google HTTP 2.0, has that feature.
ajross 13y ago
The last example seems implausible: the MPAA doesn't ship a browser and can't control features by fiat. I guess I'm not understanding the firestorm here (rather, I am, but in an uncharitable way as YET ANOTHER !@#?! Apple vs. Google proxy war on HN). Google developed a feature they like and want to ship it. They want it to be a standard. Apple (at least this one Apple person) doesn't want it standardized yet. Google is noting that they are going to want to ship this anyway ("threatening to ship it anyway" if you swing that way). So what? Surely this kind of argument happens any time you have a proposed standard from a single vendor. What's special about Shadow DOM that it can't tolerate this kind of disagreement?
- potch 13y ago
  You're right, the MPAA example is inapt. As regards what makes Shadow DOM special? It's not special. The issue is that Google has made many public claims toward a Brand New Day of participation in standards with Blink. [1] Vendors and developers were beginning to have cautious optimism that upcoming standards wouldn't be as rushed and fragmanted as they were in the past. This action directly contradicts the previous goodwill. [1] http://www.chromium.org/blink#new-features http://www.chromium.org/blink#new-features
  - slightlyoff 13y ago
    Just to be clear, Googlers (myself included) have been constantly participating in the standards process both pre-and-post fork. There's nothing "brand new day" here; conscientious standards engagement is just how we roll here on the Blink team. Regarding charges of this being "rushed", note that it has been clear for 3+ years (since we started talking about these features publicly and engaging in the standards process for them) that we needed a way to style shadow DOM that enabled author and component-author styles to co-exist and be selectively populated into the eventual tree. This isn't new, nor has it been "rushed". Many iterations of the design have lead to this point. How many more years of bottle-aging & iteration do you suggest? On what basis?
    - kybernetikos 13y ago
1qaz2wsx3edc 13y ago
This is a bit jaded, and I mean it light heartedly. But I'd be more inclined to listen to the W3 if they'd shoot down DRM. I no longer believe they have the web's interest at heart. Might as well let Google steamroll, if they're bound to steamroll things themselves.
- anon1385 13y ago
  But Google was one of the main driving forces behind the DRM proposal…
  - magicalist 13y ago
    "Google" was also one of the main forces combating DRM in HTML. Amongst others, the guy with his foot in his mouth in this thread (Tab) was one of the most vociferous opponents of the DRM proposal. (there's also, of course, Hixie, but it's not surprising that his opinion wouldn't be informed by his employers)
    - josteink 13y ago
      "Google" was also one of the main forces combating DRM in HTML. Bullshit. Utter and complete bullshit. Google was one of the initial enablers of DRM on the web. Without Google enabling it, nobody could have used DRM on the web and it would have been a non-issue. If they were "against DRM" they should have stood their stance. But they didn't. Because to them being able to sell ChromeOS with Netflix-support was more important than the integrity of the open web itself. And so it shall stand in the history-books: When the web was poisened with DRM, it was done so first by the hands of Google. There's no way they can claim they "were actually against it" when they were the ones doing the original sin. Fuck Google. Seriously fuck Google for this one. Fucking standards-maimers.
      - magicalist 13y ago
        Quit with the histrionics. You can be passionate without the informationless drama. Read what I wrote again. I never made any claim like Google "were actually against it". I said that several of the most outspoken in combatting the proposal in the HTML working group (which is still an editor's draft, btw, and certainly not fait accompli) are employed by Google, and they will likely continue fighting it. Notable among them has been Tab[1] and, not for nothing, hixie[2], the editor of the HTML spec at the WHATWG, where he refuses to put in any sort of DRM to a specification for the open web. That's exactly what you hope to see when a company doesn't force the people it pays to be on a standards body to toe the company line. [1] http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0190.html http://lists.w3.org/Archives/Public/public-html-admin/2013Fe... (with many others on that list) [2] https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2 https://plus.google.com/107429617152575897589/posts/iPmatxBY... (see also: posts to public-html)
jessaustin 13y ago
The original announcement implied that name-change bikeshedding was the only thing holding up this wonderful feature. TFA counters that disagreements remain over "the syntax and the semantics". ISTM that this kind of difference of opinion is expected and nearly unavoidable, but doesn't portend especially dire consequences. The difference between "feature-switch" and "google-kicks-ass-hell-yeah-suck-it-wc3-feature-switch" was a PITA in the past, but now we have tools to abstract away the details. If web developers collectively decide that the pending Chrome feature is more broken than simply having obnoxious names would imply, then we'll just have to endure another round of this when Mozilla or whoever comes out with the next version.
mathattack 13y ago
Well, they just made Dimitri Glazkov famous.

by potch 13y ago

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.
- munificent 13y ago
  I don't know about the CSS stuff that spawned this thread, but the rest of the shadow DOM stuff is polyfilled to work in other browsers: https://github.com/Polymer/ShadowDOM https://github.com/Polymer/ShadowDOM
  - potch 13y ago
    This is speculation: The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. Think about what it takes to make DOM invisible in the browser in a polyfill- overriding every DOM method to filter out shadowed nodes. I've heard reports of 10x slowdowns on DOM operations with this polyfill in place. The kicker? Web Components (specifically Custom Elements) lose almost all their encapsulation without Shadow DOM. Those of us who are betting heavy on Web Components as The Future™ are pretty anxious about this.
    - munificent 13y ago
      > The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. I'm not sure what you mean by "moving forward quickly". They've been hammering on this in the public eye for over three years. How many more years of salary should they pay before they get it out the door? At some point, you just have to ship.
potch 13y ago
When the features don't work the same way in every browser, it hurts the platform. Poorly designed features are impossible to take back. (see also AppCache). Web Components is moving quickly, but there has to be an element of care. Shipping features before they're ready is driven by marketing and PR, not engineering maturity.
gress 13y ago
If you want a proprietary platform controlled by a single vendor, code for iOS or Android.

johnward 13y ago

So it's almost like the IE 6 days except that in this case the standards actually are influenced by Google instead of MS just doing whatever the hell it wanted. So slightly better but still not good. Plus if there is anyone I trust to do what is right for the user it's going to be Mozilla not Google.

ajross 13y ago
That argument seems isomorphic to demanding that all software design and feature innovation happen within the W3C commitee process. Certainly that's not how most successful features have worked historically...
- potch 13y ago
  The historical processes boil down to: 1) Single Browser Ideates -> Single Browser Ships -> Time Passes -> Other Browsers Ship -> Standard. This caused delay in implementation and vendor prefix hell. 2) W3C Ideates -> W3C Bikesheds -> Browsers Implement. This causes things like AppCache that work on paper, but don't adequately cover developer use cases and address the needs of the platform. The ideal process (in my opinion) 1) Single Vendor Ideates -> W3C Evaluates/Refines -> Browsers Implement Under Feature Flags -> Standard -> Feature Flags are removed. This process, depending on the size/scope of the change, should take about 6mo to a year. For a permanent irrevocable change to a cross-browser API? That is mature and prudent. edit: formatting.
  - masklinn 13y ago
    You (2) is not correct. Most W3C specs are edited if not outright proposed by browser implementor teams. And of course nobody anywhere ever prevented browsers from shipping stuff under feature flags (most of ES6 was in Firefox since the days of FF3/FF4, with slightly different semantics, and with an opt-in behind a version flag for instance). Hixie (HTML5 editor, CSS Selectors Level 3 editor) works at Google since 2005 and worked at Opera before, Shadow DOM's editor is Google's Dimitri Glazkov

duaneb 13y ago

I don't think that people have double standards for Google, it's that the potential flaws aren't obvious.... Where's the competition and alternatives? We're stuck between making decisions too quickly and Google becoming the de facto standard. EDIT: To be clear, I find Google's actions in this regard to be surprisingly impolitic and ill-conceived. Anyone who reads it should have alarm bells.

potch 13y ago
Google should respect the desire of other parties to be given adequate time to review their proposals. Being told "you have to object NOW because we're going to ship" doesn't allow third parties to actually identify technical issues. It's like someone committing code without letting their peers review that code for flaws. It's a recipe for cementing flaws into the web platform. Intended or not, there is arrogance in the notion that external discussion of Google's proposal won't improve it.
- ndesaulniers 13y ago
  It's like someone force pushing to production without letting their peers review that code for flaws. FTFY
  - username223 13y ago
    I believe SPDY, er, Google HTTP 2.0, has that feature.

ajross 13y ago

The last example seems implausible: the MPAA doesn't ship a browser and can't control features by fiat. I guess I'm not understanding the firestorm here (rather, I am, but in an uncharitable way as YET ANOTHER !@#?! Apple vs. Google proxy war on HN). Google developed a feature they like and want to ship it. They want it to be a standard. Apple (at least this one Apple person) doesn't want it standardized yet. Google is noting that they are going to want to ship this anyway ("threatening to ship it anyway" if you swing that way). So what? Surely this kind of argument happens any time you have a proposed standard from a single vendor. What's special about Shadow DOM that it can't tolerate this kind of disagreement?

potch 13y ago
You're right, the MPAA example is inapt. As regards what makes Shadow DOM special? It's not special. The issue is that Google has made many public claims toward a Brand New Day of participation in standards with Blink. [1] Vendors and developers were beginning to have cautious optimism that upcoming standards wouldn't be as rushed and fragmanted as they were in the past. This action directly contradicts the previous goodwill. [1] http://www.chromium.org/blink#new-features http://www.chromium.org/blink#new-features
- slightlyoff 13y ago
  Just to be clear, Googlers (myself included) have been constantly participating in the standards process both pre-and-post fork. There's nothing "brand new day" here; conscientious standards engagement is just how we roll here on the Blink team. Regarding charges of this being "rushed", note that it has been clear for 3+ years (since we started talking about these features publicly and engaging in the standards process for them) that we needed a way to style shadow DOM that enabled author and component-author styles to co-exist and be selectively populated into the eventual tree. This isn't new, nor has it been "rushed". Many iterations of the design have lead to this point. How many more years of bottle-aging & iteration do you suggest? On what basis?
  - kybernetikos 13y ago

1qaz2wsx3edc 13y ago

This is a bit jaded, and I mean it light heartedly. But I'd be more inclined to listen to the W3 if they'd shoot down DRM. I no longer believe they have the web's interest at heart. Might as well let Google steamroll, if they're bound to steamroll things themselves.

anon1385 13y ago
But Google was one of the main driving forces behind the DRM proposal…
- magicalist 13y ago
  "Google" was also one of the main forces combating DRM in HTML. Amongst others, the guy with his foot in his mouth in this thread (Tab) was one of the most vociferous opponents of the DRM proposal. (there's also, of course, Hixie, but it's not surprising that his opinion wouldn't be informed by his employers)
  - josteink 13y ago
    "Google" was also one of the main forces combating DRM in HTML. Bullshit. Utter and complete bullshit. Google was one of the initial enablers of DRM on the web. Without Google enabling it, nobody could have used DRM on the web and it would have been a non-issue. If they were "against DRM" they should have stood their stance. But they didn't. Because to them being able to sell ChromeOS with Netflix-support was more important than the integrity of the open web itself. And so it shall stand in the history-books: When the web was poisened with DRM, it was done so first by the hands of Google. There's no way they can claim they "were actually against it" when they were the ones doing the original sin. Fuck Google. Seriously fuck Google for this one. Fucking standards-maimers.
    - magicalist 13y ago
      Quit with the histrionics. You can be passionate without the informationless drama. Read what I wrote again. I never made any claim like Google "were actually against it". I said that several of the most outspoken in combatting the proposal in the HTML working group (which is still an editor's draft, btw, and certainly not fait accompli) are employed by Google, and they will likely continue fighting it. Notable among them has been Tab[1] and, not for nothing, hixie[2], the editor of the HTML spec at the WHATWG, where he refuses to put in any sort of DRM to a specification for the open web. That's exactly what you hope to see when a company doesn't force the people it pays to be on a standards body to toe the company line. [1] http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0190.html http://lists.w3.org/Archives/Public/public-html-admin/2013Fe... (with many others on that list) [2] https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2 https://plus.google.com/107429617152575897589/posts/iPmatxBY... (see also: posts to public-html)

jessaustin 13y ago

The original announcement implied that name-change bikeshedding was the only thing holding up this wonderful feature. TFA counters that disagreements remain over "the syntax and the semantics". ISTM that this kind of difference of opinion is expected and nearly unavoidable, but doesn't portend especially dire consequences. The difference between "feature-switch" and "google-kicks-ass-hell-yeah-suck-it-wc3-feature-switch" was a PITA in the past, but now we have tools to abstract away the details. If web developers collectively decide that the pending Chrome feature is more broken than simply having obnoxious names would imply, then we'll just have to endure another round of this when Mozilla or whoever comes out with the next version.

mathattack 13y ago

Well, they just made Dimitri Glazkov famous.