Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay <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 and
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  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.


> Personally I think composition piece itself doesn't legitimate the
> complexity of shadow DOM.
>

I accept this as a personal opinion, not a fact.


> 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, as
examples in the wild.


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


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


> So, start with composition but keep the requirements for the proper
> encapsulation in mind by not introducing
> syntaxes or APIs which might make implementing encapsulation harder.
>

Agreed.

>
>
> Are there cases where encapsulation and composition contradicts? I guess
> that depends on the definition of those both.


Yes.

:DG<