Re: Shadow tree style isolation primitive

> On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
> 
> On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay <olli@pettay.fi <mailto:olli@pettay.fi>> wrote:
> On 02/05/2015 02:24 AM, Dimitri Glazkov wrote:
> However, I would like to first understand if that is the problem that the group wants to solve. It is unclear from this conversation.
> 
> Yes. The marketing speech for shadow DOM has changed over time from "do everything possible, make things awesome" to "explain the platform"
> to the current "enable easier composition".
> So it is not very clear to me what even the authors of the spec always want, this said with all the kindness :)
> 
> I appreciate the affirmation, the kindness, and the smiley. Though since this is public forum, I have to add a few things:
> 
> 1) The original "Component Model" (as it was known back then) charter from 2011 clearly includes easier composition as one of its main goals, as illustrated by https://wiki.whatwg.org/wiki/Component_Model <https://wiki.whatwg.org/wiki/Component_Model> and https://wiki.whatwg.org/wiki/Component_Model_Use_Cases <https://wiki.whatwg.org/wiki/Component_Model_Use_Cases>. In fact, we definitively solved at huge chunk of these problems. For example, Polymer is a clear illustration that https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager <https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager>  is nearly 100% solved and there are now examples in the wild of most of these use cases solved with Web Components. There's still lots of work to do, of course. But 
> 
> 2) Refining terminology and the way to describe problem space is a natural part of working on solutions for that problem space. Calling it "marketing" is just not helpful.

I agree his wording was a bit harsh.  But let me try to explain where Olli is coming from because I do sympathize with what he's saying here.

For example, at the WebApps F2F meeting last spring, you mentioned that explaining builtin element is a goal of web components.  Yet, the web components as spec'ed today doesn't explain any builtin elements due to its lack of strong encapsulation.  And insertion points, which is a huge source of complexity, is only needed to explain details and summary elements.  The ability to attach multiple generations of shadow DOM to a single host element, which is another source of an enormous complexity, is not required to explain any builtin HTML elements at all as far as I know.  So it appears that there is a precedence in adding features to Web components that are not needed for builtin elements but desirable for other use cases.  Yet, you (Google representatives as the collective) in the past argued that you didn't want to add support for imperative API for selecting distributed elements because that can't explain builtin elements even though we've listed a few use cases that can't be adequately addressed unless we have an imperative API.

So I have a hard time understanding that exactly which use cases and problems you're trying to solve (and have solved) in web components because it seems to drift left and right every time we discuss different issues.  Let us not discuss goals and objectives, etc… because they're too abstract at this point.

> Personally I think composition piece itself doesn't legitimate the complexity of shadow DOM.
> 
> I accept this as a personal opinion, not a fact.

Like I mentioned earlier in the thread, I fully agree with Olli's position here.  I don't think I'll be interested in implementing shadow DOM in WebKit at all if the only use case we're solving at first is the layout manager use case.

I've done a fair amount of web programming myself, and most recently I've been using Ember.js to write a new UI for our performance dashboard.  Granted, I only have ~5000 lines of JS code so it's not nearly as big as Gmail or many other modern Web apps but I've encountered a lot more pressing issues that need to be addressed in the platform than having to soft-ecapsulate DOM and CSS rules.

> Though, it is not clear what composition means to different people. Is the need for insertion points part of
> composition? In my mind it might not be. It is part of the stronger encapsulation where
> one has hidden DOM between a parent node and a child node.
> 
> For example, this is clearly where you haven't thought through the problem space. Sure, you don't need insertion points for simple hierarchical composition. But as soon as you get to the Layout Manager use case (not to belabor a 4-year old doc), you run into the need for insertion points. Take https://www.polymer-project.org/docs/elements/layout-elements.html <https://www.polymer-project.org/docs/elements/layout-elements.html>, as examples in the wild.

Yet, the web components as currently spec'ed doesn't address other use cases listed.  So again, I'd like to remind us all that different participants of the working group care about different use cases.  Like you regard the layout manager use case to be very important, others regard other use cases to be much more important.  We all have differences in opinions.  We need to find a point to where we can all compromise or else we'll never agree on anything ever.

> Is event retargeting part of composition?
> 
> This one is something I am eager to explore. Event retargeting came directly from trying to address the goal of explaining the native controls, and it might be something we could separate from the pure composition primitive.

Indeed.  I've talked with multiple Web developers over the last couple of years and they all raised the concern over the event retargeting mechanism being baked into the browser.

> That said, I think we should aim for something stronger than just enabling easier composition.
> The end goal could go as far as let pages to implement their own form controls. And to make that
> all less error prone for the users of such components requires encapsulation.
> 
> Again, I accept this as a personal opinion, but I would like to push back on this. Stronger encapsulation comes with its own host of problems for developers. Before taking this as a fact, I encourage first exploring the trade-offs and trying to prototype/build/tool/test components. I've done it. I've learned the lesson.

I don't think Olli needs to do that exercise to know there are valid use cases.  Social sharing buttons are everywhere on the Web, and being able to encapsulate them will benefit the Web.

- R. Niwa