Hacker News Reader

Comment by slightlyoff | Hacker News Reader

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?

View on HN

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]

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

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.

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

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.

Progress delayed is progress denied.

If that's how you really feel, why bother paying lip service to the w3c?

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.

Here's the Blink bug: 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.

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 problem is that it won't be your pain, it'll be other vendors' pain as they have to reverse engineer Blink's implementation.

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/1cxW4MtsDb...

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.

Problem is - even if something is open source, doesn't mean it will be easy to pull and implement in your code base...

Maybe cat/hat Shadow DOM depends on some C lib that causes incompatibility with a lib you use, which means you'll have integration problems.

> (which, as you might be aware, is Open Source)

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

That's moving the goalposts. The full context of your statement was:

> it'll be other vendors' pain as they have to reverse engineer Blink's implementation

Which was the salient point I was replying to. Quoting out of context to imply I made statements I did not is...disheartening.

Reply on news.ycombinator.com