Re: Shadow tree style isolation primitive

Following this thread because there is real need for what is being
discussed.

However, until that need is satisfied, here is what we're thinking to
achieve style encapsulation, using current-world technologies, and I'm
hoping you would point out any problems you see with doing it this way.

1. We build components that render DOM elements, e.g. via React or
something like that.
2. We write or generate a stylesheet per component and name the .css file
same as component name, and convert it from CSS to a named subtree (e.g.
CSS.componentName.styles: { ... }) in a global JSON structure (build time)
3. The components consume style rules from that data structure at run time
and convert them to inline styles on the elements they render. The inline
styles are injected and rewritten based on component state. We use CSS3
transitions rather than style tweening.
4. For @keyframes, we create a style element in the document and namespace
them like component-name-keyframe-name.

Not using this list as a Stackoverflow substitute. My purpose here is to
show one way of achieving style isolation without Web Components, Shadow
DOM, etc, and figure out whether the web needs anything more than we
already have.

On Thu, 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> 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<
>