5 ms·

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"

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
You seem to be saying that the problem has been obvious for 3+ years. Has the solution also been obvious? Even to nongooglers? I haven't followed this closely, but from the surface it seems as if a couple of paragraphs in a public spec document 9 months ago could have diffused a lot of these ostensibly reasonable sounding criticisms.
- slightlyoff 13y ago
  A previous solution based on explicit naming of "parts" of shadow DOMs was withdrawn several months ago. And update was given the the CSS WG last November that outlined the changes. FWIW, the "::part()" solution would have _worked_. It's entirely feasible that we could have improved the world by providing Shadow DOM with that as the primary styling mechanism. Not ideal, though. So we have been willing to change course in response to feedback. Here's the Blink bug: https://code.google.com/p/chromium/issues/detail?id=309504 https://code.google.com/p/chromium/issues/detail?id=309504 All of this happened in the open, in consultation with other vendors (not necessarily at WG meetings, which aren't where you design features anyway). Remember the context here: Googlers have been doing the heavy lifting on this front for _years_. It's exciting that others are starting to pay attention to the problem space. That they don't think providing Shadow DOM to users is as urgent as we do is their right. We, however, are willing to take some pain in this (relatively small) instance, should they not be willing to help us work through the naming issue in short-order (which, as you can see from the thread, is the actual request; our goal is to improve things through web developers, preferably via collaboration.
  - potch 13y ago
    The concern is shipping a non-standard solution and then encouraging developers to use it is the first step toward lock-in. No matter how much you flag something as experimental, it will be used, and the developers who built things using it will move on. When other browsers later implement the standard, nobody goes back to build it in to their projects- they're working on new projects now. This is how Firefox can support Web Audio and still not have it work on the majority of sites that use it. A differing implementation is just as bad as a prefix, and hurtful to future developers who will have to code for it to reach a compatibility matrix.
  - pcwalton 13y ago
    The problem is that it won't be your pain, it'll be other vendors' pain as they have to reverse engineer Blink's implementation.
    - slightlyoff 13y ago
      The details of both the semantics and syntax in question have been widely discussed and understood. It's pure hyperbole to appeal to "reverse engineer Blink's implementation" (which, as you might be aware, is Open Source). Here's a refresher for those who missed it: https://docs.google.com/a/chromium.org/document/d/1cxW4MtsDbCUTdnr_7lxwrlywmpKj04aD5TRVKjd446o/edit?pli=1 https://docs.google.com/a/chromium.org/document/d/1cxW4MtsDb...
      - ddebernardy 13y ago
        The fact that web developers will then need to worry about differing implementations across browsers and -- pray not -- across blink versions, on the other hand, is not hyperbole. If it's ready to ship with nobody else agreeing on how it should work, please do everyone a favor and ship it with a prefix. If only as a courtesy to fellow developers who will need to deal with this mess. Nevermind that you don't want a prefix. Use one. Better prefix hell than different implementations using the same syntax.
        deleted 13y ago
potch 13y ago
I'm suggesting if people in the appropriate working group feel as if a particular solution to a problem (regardless of how old the problem is) wasn't given due consideration, the notion of "speak now or we'll ship anyway" is not productive. I don't believe that Google in particular is a bad actor in the standards community. Far from it! I do feel as if something as fundamentally paradigm-shifting as Web Components needs care and thought to be done correctly and respectfully. Saying "we're going to ship this solution ASAP, any last-minute objections" puts unnecessary stress and time constraints on the task of making the best, most useful solution possible.
- slightlyoff 13y ago
  Progress delayed is progress denied. If you want a better web platform, that means wanting one that is different than the one we have today. It is also the case that standards committees are not outfitted with effective fitness functions (the ability to predict market success, e.g.). The best we can do is to iterate and be data-driven. I do not know what "correctly" means in this context, and I submit that you don't either. What we _are_ doing is making the progress we can with the best available data we can gather (polyfilling via Polymer, building large-scale apps, observing existing libraries and their challenges, etc.). It's fine to critique the method, but bring data. If you have specific concerns regarding their utility or design of these specs, I'm hopeful they can be aired as we continue to iterate. Shipping is not the end; it's a new beginning.
  - shadowmint 13y ago
    Then do everyone a favor and namespace your apis so it's obvious they are not standards compliant and can be cleanly used at the same time as other browser implementations until the standard is ready.
  - forgottenpass 13y ago
    Progress delayed is progress denied. If that's how you really feel, why bother paying lip service to the w3c?
    - 13y ago
jrossi_msft 13y ago
The particular part of the Shadow DOM spec that sparked this discussion (the "cat and the hat" combinators)was introduced less than 4 months ago and was met with some objections just this last week at the CSS F2F meeting. So the 3+ years comment is a bit unfair in this context. I certainly appreciate the level of investment Google has made here and I can sympathize with how it feels to just want to ship a feature already! I've been pumped for web components ever since the first pitch you and Dimitri gave us in a hotel suite a few years ago at TPAC. But keep in mind that both Microsoft and Mozilla have (failed) experiences in building component models for the web (e.g. HTAs). This isn't an easy feature to get correct. The web needs us to get this right and shipping it before there's consensus isn't how we're going to succeed in that regard. -Jacob Rossi [IE team, but speaking on my own opinions]
- slightlyoff 13y ago
  Hi Jacob, I sympathize with the hesitation that you must feel regarding a request to analyze a feature on a short timeframe, it is however the case that MSFT has in the recent past (Pointer Events, which are GREAT) used its prerogative to ship features ahead of standardization. That contrasts with the current scenario in which agreement by the WG on the names of the APIs _would in fact change our course_. I noted the timeline as I understand it here: https://news.ycombinator.com/item?id=7187024 https://news.ycombinator.com/item?id=7187024 The web platform is behind. It's regrettable that we are, but that's the current situation. If you'd like to help, I encourage you to help weigh alternative in the www-style thread. Engagement on the content and not the process would go a long way at this moment.
  - Helianthus 13y ago
    >Engagement on the content and not the process would go a long way at this moment. In all honesty this is a terrible and frightening attitude for you to express. It validates that: * You have contempt for the process. * You demand others shut up about it. You are making it obvious that Google is a problem.
    - deleted 13y ago

kybernetikos 13y ago

You seem to be saying that the problem has been obvious for 3+ years. Has the solution also been obvious? Even to nongooglers? I haven't followed this closely, but from the surface it seems as if a couple of paragraphs in a public spec document 9 months ago could have diffused a lot of these ostensibly reasonable sounding criticisms.

slightlyoff 13y ago
A previous solution based on explicit naming of "parts" of shadow DOMs was withdrawn several months ago. And update was given the the CSS WG last November that outlined the changes. FWIW, the "::part()" solution would have _worked_. It's entirely feasible that we could have improved the world by providing Shadow DOM with that as the primary styling mechanism. Not ideal, though. So we have been willing to change course in response to feedback. Here's the Blink bug: https://code.google.com/p/chromium/issues/detail?id=309504 https://code.google.com/p/chromium/issues/detail?id=309504 All of this happened in the open, in consultation with other vendors (not necessarily at WG meetings, which aren't where you design features anyway). Remember the context here: Googlers have been doing the heavy lifting on this front for _years_. It's exciting that others are starting to pay attention to the problem space. That they don't think providing Shadow DOM to users is as urgent as we do is their right. We, however, are willing to take some pain in this (relatively small) instance, should they not be willing to help us work through the naming issue in short-order (which, as you can see from the thread, is the actual request; our goal is to improve things through web developers, preferably via collaboration.
- potch 13y ago
  The concern is shipping a non-standard solution and then encouraging developers to use it is the first step toward lock-in. No matter how much you flag something as experimental, it will be used, and the developers who built things using it will move on. When other browsers later implement the standard, nobody goes back to build it in to their projects- they're working on new projects now. This is how Firefox can support Web Audio and still not have it work on the majority of sites that use it. A differing implementation is just as bad as a prefix, and hurtful to future developers who will have to code for it to reach a compatibility matrix.
- pcwalton 13y ago
  The problem is that it won't be your pain, it'll be other vendors' pain as they have to reverse engineer Blink's implementation.
  - slightlyoff 13y ago
    The details of both the semantics and syntax in question have been widely discussed and understood. It's pure hyperbole to appeal to "reverse engineer Blink's implementation" (which, as you might be aware, is Open Source). Here's a refresher for those who missed it: https://docs.google.com/a/chromium.org/document/d/1cxW4MtsDbCUTdnr_7lxwrlywmpKj04aD5TRVKjd446o/edit?pli=1 https://docs.google.com/a/chromium.org/document/d/1cxW4MtsDb...
    - ddebernardy 13y ago
      The fact that web developers will then need to worry about differing implementations across browsers and -- pray not -- across blink versions, on the other hand, is not hyperbole. If it's ready to ship with nobody else agreeing on how it should work, please do everyone a favor and ship it with a prefix. If only as a courtesy to fellow developers who will need to deal with this mess. Nevermind that you don't want a prefix. Use one. Better prefix hell than different implementations using the same syntax.
      - deleted 13y ago

potch 13y ago

I'm suggesting if people in the appropriate working group feel as if a particular solution to a problem (regardless of how old the problem is) wasn't given due consideration, the notion of "speak now or we'll ship anyway" is not productive. I don't believe that Google in particular is a bad actor in the standards community. Far from it! I do feel as if something as fundamentally paradigm-shifting as Web Components needs care and thought to be done correctly and respectfully. Saying "we're going to ship this solution ASAP, any last-minute objections" puts unnecessary stress and time constraints on the task of making the best, most useful solution possible.

slightlyoff 13y ago
Progress delayed is progress denied. If you want a better web platform, that means wanting one that is different than the one we have today. It is also the case that standards committees are not outfitted with effective fitness functions (the ability to predict market success, e.g.). The best we can do is to iterate and be data-driven. I do not know what "correctly" means in this context, and I submit that you don't either. What we _are_ doing is making the progress we can with the best available data we can gather (polyfilling via Polymer, building large-scale apps, observing existing libraries and their challenges, etc.). It's fine to critique the method, but bring data. If you have specific concerns regarding their utility or design of these specs, I'm hopeful they can be aired as we continue to iterate. Shipping is not the end; it's a new beginning.
- shadowmint 13y ago
  Then do everyone a favor and namespace your apis so it's obvious they are not standards compliant and can be cleanly used at the same time as other browser implementations until the standard is ready.
- forgottenpass 13y ago
  Progress delayed is progress denied. If that's how you really feel, why bother paying lip service to the w3c?
  - 13y ago

jrossi_msft 13y ago

The particular part of the Shadow DOM spec that sparked this discussion (the "cat and the hat" combinators)was introduced less than 4 months ago and was met with some objections just this last week at the CSS F2F meeting. So the 3+ years comment is a bit unfair in this context. I certainly appreciate the level of investment Google has made here and I can sympathize with how it feels to just want to ship a feature already! I've been pumped for web components ever since the first pitch you and Dimitri gave us in a hotel suite a few years ago at TPAC. But keep in mind that both Microsoft and Mozilla have (failed) experiences in building component models for the web (e.g. HTAs). This isn't an easy feature to get correct. The web needs us to get this right and shipping it before there's consensus isn't how we're going to succeed in that regard. -Jacob Rossi [IE team, but speaking on my own opinions]

slightlyoff 13y ago
Hi Jacob, I sympathize with the hesitation that you must feel regarding a request to analyze a feature on a short timeframe, it is however the case that MSFT has in the recent past (Pointer Events, which are GREAT) used its prerogative to ship features ahead of standardization. That contrasts with the current scenario in which agreement by the WG on the names of the APIs _would in fact change our course_. I noted the timeline as I understand it here: https://news.ycombinator.com/item?id=7187024 https://news.ycombinator.com/item?id=7187024 The web platform is behind. It's regrettable that we are, but that's the current situation. If you'd like to help, I encourage you to help weigh alternative in the www-style thread. Engagement on the content and not the process would go a long way at this moment.
- Helianthus 13y ago
  >Engagement on the content and not the process would go a long way at this moment. In all honesty this is a terrible and frightening attitude for you to express. It validates that: * You have contempt for the process. * You demand others shut up about it. You are making it obvious that Google is a problem.
  - deleted 13y ago