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?
As the Apple person in question, my primary objection isn't about whether I "want it standardized yet". It's more that this hasn't even reached step 0 of the standards process (writing an "editor's draft", a document that writes stuff up in standardese but hasn't necessarily been documented by the WG yet) and Google is saying "we're shipping now and then will likely be unwilling to change it". Furthermore, it's not like there are only some edge cases to work out.
There are also substantive objections to the content of what is being shipped. Not only on the names (which Google invited comment on) but also on the intended semantics. It's pretty hard to usefully comment on the semantics without a draft spec and some time for discussion.
That's why most browser vendors try to make sure there is at least a draft, time for discussion, and rough consensus before shipping a feature enabled and unprefixed.
For what it's worth, Apple WebKit engineers agree with many Google Blink engineers about lots of standards topics, we actively collaborate on many things, and we actively support the goals of Web Components and of this particular styling feature, if not necessarily all the details. So your "proxy war" narrative is false.
However, I feel that Google is not being a good standards citizen in taking this particular action.
> MPAA doesn't ship a browser and can't control features by fiat.
DRM extensions (EME) have shipped in Chrome and IE already (with whole W3C process steamrolled), so it seems that MPAA does control browser features — by proxy (Google Play/Xbox video store).
Missed the point. All W3C committee member influence the set of features covered by W3C standards. That's what the W3C committe is for.
But the allegation here is that Google is ignoring the standardization process and shipping features before getting signoff via a committee draft, and that's a bad thing. The MPAA can't ship features at all, so they would never have access to this trick without convincing a browser vendor to do it for them.
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.
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?
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]
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_.
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.
We prefixed our pointer events implementation (which, yes, prefixes have issues and we should stop doing this IMO). Blink is talking about unprefixed, on by default. We updated the implementation and only removed prefixes once we could demonstrate consensus with other browsers (Candidate Recommendation, in this case was one signal of that).
Matt and Rossen from our team were at the CSS F2F where this is discussed with some hesitation on design and I'm sure they'll weigh in further on www-style (this API area's not my cup of tea).
A consensus process, while annoying at times and never perfect, makes for a better and more interoperable web.
I realize that I'm an outlier but I support prefixing as a possible solution to this sort of thing; but that's even more out of favor with the CSS WG than what's being proposed (AFAICT).
Looking forward to timely www-style feedback, it's much appreciated.
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.
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.
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.
Meaningful progress is progress for the most people. To achieve that, it's often most effective to create coalitions to help you achieve that progress in areas you yourself cannot. This is where collaboration and standards come in.
What's going on now is a request for collaboration. It has been somewhat de-railed, but I have hope. Barring consensus, we feel the risks are outweighed by the gains for developers in having changed things in the bit of the world our codebase addresses.
Perhaps you weren't looking for a real answer, but there's one anyway.
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.
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.
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.
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.
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).
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.
Being open source has never been an excuse to break the standards process. It's disheartening to see open source being used to justify this behavior again (first with PNaCl, now this).
What's special is that recently browsers have been much better about not randomly shipping features unless there is some consensus from the other browsers. Instead, they've been implementing them behind runtime flags, getting specs written and agreed on, _then_ shipping.
As in, recently there have in fact not been these sort of arguments because browsers have somewhat cooperated to iron out issues before shipping.
> So what? Surely this kind of argument happens any time you have a proposed standard from a single vendor.
The declarative nature of CSS means you have to set syntax in order to test things out while also making it bad to deprecate syntax (no meaningful conditionals). Attempted workarounds are things like the vendor prefixes disaster.
I was under the impression that post-split Blink was going to do the same thing Mozilla does and turn on unprefixed experimental features for Canary/Beta and flag them off in the release channel until things hit CR.
There isn't a lot of debate that the feature in question is desired but it seems like goog is jumping the gun. I'd guess it's because they have internal stakeholders (polymer, angular).
P.S. If anybody on the committee is reading and cares about a random guy on the internet's opinion: +1 ::shadow, ::shadow-all
It sounds like there's issue here where Google hasn't actually proposed a standard. They have an implementation which seems to at least not be completely documented, or not at all? I can't tell with just a little reading.
So, it's more than just an Apple v Google spat, the Google fellow is just saying "we don't want to take the time, so here accept what we ship or gtfo".
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?