Mail list Etiquette [Was: Re: Shadow tree style isolation primitive]

[Arthur Barstow]

[ Apologies for cross-posting ]

On 2/4/15 6:56 PM, Ryosuke Niwa wrote:
That sounds rather demeaning and insulting [1]. public-webapps, or a 
mailing list of any W3C working group, isn't an appropriate forum to rant.


Given this thread resulted in some "heated" replies, I'd like to remind 
everyone of WebApps' e-mail list etiquette policy:


[[


*WebApps' members appreciate and encourage frank technical discussions 
on our mail lists but all discussions must be done in a respectful 
manner. Please note this respect requirement is codified in the Process 
Document via the following participation criteria "Social competence in 
one's role 
". 
Additionally, seeCode of Ethics and Professional Conduct 
and if you did not 
attend/Kindergarten/, we expect our list participants to adhere to the 
basic principles inAll I Really Need To Know I Learned In Kindergarten 
.

*]]

Please focus on technical comments and always be respectful.

-Thanks, ArtB

[1] http://www.w3.org/Consortium/cepc/ - R. Niwa 

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 10:11 AM, Dimitri Glazkov 
wrote:

> ... Hanging "but"?! Oh lordy. Oooh, let me turn this into a contemplative
> sidebar opportunity.
>
> Shadow DOM and Web Components seem to have what I call the "Unicorn
> Syndrome". There's a set of specs that works, proven by at least one
> browser implementation and the use in the wild. It's got warts
> (compromises) and some of those warts are quite ugly. Those warts weren't
> there in the beginning -- they are a result of a hard, multi-year slog of
> trying to make a complete system that doesn't fall over in edge cases, and
> compromising. A lot.
>
> So there's a temptation to make new proposals (unicorns) that are
> wart-free, but incomplete or not well-thought-out. Don't get me wrong. I
> like new ideas. What I would like to avoid is judging a workhorse against a
> unicorn. Armed with your imagination, unicorn will always win.
>

I shouldn't have sent this. It was uncool of me. My bad. Please accept my
apologies.

:DG<

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Feb 5, 2015, at 3:51 PM, Dimitri Glazkov  wrote:
> 
> On Thu, Feb 5, 2015 at 2:53 PM, Ryosuke Niwa  > wrote:
> 
>> On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov > > wrote:
>> 
>> On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay > > 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.
> 
> 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.
> 
> Let's do it.
> 
> For example, at the WebApps F2F meeting last spring, you mentioned that 
> explaining builtin element is a goal of web components.
> 
> Yep. I would like to emphasize that "explaining the platform" is not a 
> self-goal. It's a constraint, which helps guiding the thinking about new 
> primitives and behaviors. Relying on builtin elements to inform discovery of 
> Shadow DOM was a real thing. I hope you remember me going through that huge 
> refactoring in WebKit.

Okay.

> Yet, the web components as spec'ed today doesn't explain any builtin elements 
> due to its lack of strong encapsulation.  
> 
> There are two distinct concepts mixed in here: 
> 
> 1) the type 2 encapsulation. There's no barrier for this to happen. There's 
> broad agreement that we should do it, and even recent work by hayato on 
> outlining specific places where the "open" and "closed" modes differ. The 
> research he provided shows that it's a fixed set of changes 
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775 
> ), enabled by a flag as 
> we discussed at the spring session.

Like we've argued many times in the past, type II encapsulation should be 
default and components should opt-in to open up its internals.  In that regard, 
our position perfectly aligns with what Olli says.  That is, representatives of 
two major browser vendors agree on this matter.

> 2) the actual, honest-to-goodness security boundary (isolation) that builtins 
> enjoy thanks to the C++/JS bindings layer. This is a much more difficult 
> problem, but something we definitely want to tackle at some point in the 
> future. Maybe Realms are the answer.

Like I've mentioned in the past, we did a through case study of this model and 
we've discovered a number of problems with existing web components features 
that we believe are not fixable in the future.

If you're asking us to go study layout manager use case, which we did do, 
please go study our use case as well.

> And insertion points, which is a huge source of complexity, is only needed to 
> explain details and summary elements.
> 
> For builtins, yes. For general composition problem, they are essential.

Sorry, maybe I was short on words.  What I meant is that they're not needed for 
builtin elements.  During our study of layout manager use case, we did come to 
consolation that something akin to insertion points and node distributions are 
necessary.

> 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.
> 
> This is true. Multiple roots per element is an extension that enables 
> reasoning about subclassing in terms of DOM. You are definitely overstating 
> 

Re: Shadow tree style isolation primitive

[Maciej Stachowiak]

> 
> ... Hanging "but"?! Oh lordy. Oooh, let me turn this into a contemplative 
> sidebar opportunity.
> 
> Shadow DOM and Web Components seem to have what I call the "Unicorn 
> Syndrome". There's a set of specs that works, proven by at least one browser 
> implementation and the use in the wild. It's got warts (compromises) and some 
> of those warts are quite ugly. Those warts weren't there in the beginning -- 
> they are a result of a hard, multi-year slog of trying to make a complete 
> system that doesn't fall over in edge cases, and compromising. A lot.


Compromise
1. a. A settlement of differences in which each side makes concessions.

I don’t remember any of that happening. I guess you mean a different definition 
of “compromising”?

Regards,
Maciej

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 2:53 PM, Ryosuke Niwa  wrote:

>
> On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov  wrote:
>
> On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay  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.
>
>
> 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.
>

Let's do it.


> For example, at the WebApps F2F meeting last spring, you mentioned that
> explaining builtin element is a goal of web components.
>

Yep. I would like to emphasize that "explaining the platform" is not a
self-goal. It's a constraint, which helps guiding the thinking about new
primitives and behaviors. Relying on builtin elements to inform discovery
of Shadow DOM was a real thing. I hope you remember me going through that
huge refactoring in WebKit.



> Yet, the web components as spec'ed today doesn't explain any builtin
> elements due to its lack of strong encapsulation.
>

There are two distinct concepts mixed in here:

1) the type 2 encapsulation. There's no barrier for this to happen. There's
broad agreement that we should do it, and even recent work by hayato on
outlining specific places where the "open" and "closed" modes differ. The
research he provided shows that it's a fixed set of changes (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775), enabled by a flag as
we discussed at the spring session.

2) the actual, honest-to-goodness security boundary (isolation) that
builtins enjoy thanks to the C++/JS bindings layer. This is a much more
difficult problem, but something we definitely want to tackle at some point
in the future. Maybe Realms are the answer.


> And insertion points, which is a huge source of complexity, is only needed
> to explain details and summary elements.
>

For builtins, yes. For general composition problem, they are essential.


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

This is true. Multiple roots per element is an extension that enables
reasoning about subclassing in terms of DOM. You are definitely overstating
the complexity. It's not that difficult -- just a list of pointers instead
of one pointer.


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

This is where my intro sentence is useful. Explaining builtins is not a
self-goal. We browser developers don't _need_ to explain the platform for
any other purpose other than extracting useful primitives for web
developers.


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

The distribution discussion terminated early because the people who were
interested in solving this problem withdrew from it. I even organized a
regular VC to facilitate the work, but there was no interest. I am still
interested in developing a good distribution API, but I don't want to walk
alone.


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

Re: Shadow tree style isolation primitive

[Bjoern Hoehrmann]

* Dimitri Glazkov wrote:
>Shadow DOM and Web Components seem to have what I call the "Unicorn
>Syndrome". There's a set of specs that works, proven by at least one
>browser implementation and the use in the wild. It's got warts
>(compromises) and some of those warts are quite ugly. Those warts weren't
>there in the beginning -- they are a result of a hard, multi-year slog of
>trying to make a complete system that doesn't fall over in edge cases, and
>compromising. A lot.
>
>So there's a temptation to make new proposals (unicorns) that are
>wart-free, but incomplete or not well-thought-out. Don't get me wrong. I
>like new ideas. What I would like to avoid is judging a workhorse against a
>unicorn. Armed with your imagination, unicorn will always win.

There has never been much of a consensus on the problems that need to be
solved, so it is not really surprising that a consensus-solution is not
forthcoming; instead we have continous scope creep and eternal delays.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov  wrote:
> 
> On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay  > 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.

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 
> , 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 t

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 10:52 AM, Marc Fawzi  wrote:

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

This sounds pretty neat and similar to thing that Christopher Chedeau
presented in his "CSS in your JS" talk (http://vimeo.com/116209150). I
can't think of a better example of the Web Platform (and CSS in particular)
completely failing the developer. I admire your and Christopher's
desperation and persistence to stay successful within the constraints of
the existing system.

FWIW, with Shadow DOM, you simply don't need any of these build steps or
factorings. Just write your styles in your component.

:DG<

Re: Shadow tree style isolation primitive

[Marc Fawzi]

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  wrote:

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

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 9:41 AM, Dimitri Glazkov  wrote:

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

... Hanging "but"?! Oh lordy. Oooh, let me turn this into a contemplative
sidebar opportunity.

Shadow DOM and Web Components seem to have what I call the "Unicorn
Syndrome". There's a set of specs that works, proven by at least one
browser implementation and the use in the wild. It's got warts
(compromises) and some of those warts are quite ugly. Those warts weren't
there in the beginning -- they are a result of a hard, multi-year slog of
trying to make a complete system that doesn't fall over in edge cases, and
compromising. A lot.

So there's a temptation to make new proposals (unicorns) that are
wart-free, but incomplete or not well-thought-out. Don't get me wrong. I
like new ideas. What I would like to avoid is judging a workhorse against a
unicorn. Armed with your imagination, unicorn will always win.

:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

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

Re: Shadow tree style isolation primitive

[Olli Pettay]

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



Personally I think composition piece itself doesn't legitimate the complexity 
of shadow DOM.
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.
Is event retargeting part of composition? It might not, if composition was to 
deal with nodes which are all in document
(and if nodes part of the composition were in document, we wouldn't have all 
the is-in-document issues).
And so on.


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


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





-Olli

Re: Shadow tree style isolation primitive

[Anne van Kesteren]

On Thu, Feb 5, 2015 at 1:37 AM, Tab Atkins Jr.  wrote:
> By your statements implying that composition issues can just be
> handled by better discipline and some selector modification, in the
> message I responded to earlier.  I'm not sure how to interpret those
> statement if you didn't mean that composition wasn't worth solving.

I think Olli already clarified that he is happy to solve that use
case, but that it's unclear that the complexity of shadow DOM is
warranted.

Note though that e.g. React is out there solving this without need for
shadow DOM. Ember is out there and cannot use shadow DOM due to its
coupling of style isolation primitives with event retargeting and
therefore also has its own solution. (And last I heard seems to take
inspiration from React.) Talking to the developers working on these
frameworks it's pretty clear we haven't exactly nailed it here and
that it's worth exploring what can be done instead.


-- 
https://annevankesteren.nl/

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Thu, Feb 5, 2015 at 11:03 AM, Olli Pettay  wrote:
> On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote:
>> You don't need strong isolation primitives to do a lot of good.
>> Simple composition helpers lift an *enormous* weight off the shoulders
>> of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
>> precisely that composition helper right now.  In most contexts, you
>> can't ever touch something inside of shadow DOM unless you're doing it
>> on purpose, so there's no way to "friendly fire" (as Brian puts it).
>
> If we want to just help with composition, then we can find simpler
> model than shadow DOM with its multiple shadow root per host and event
> handling
> oddities and what not. (and all the mess with is-in-doc is still something
> to be sorted out etc.)

Try to. ^_^

>> Stronger isolation does solve some problems, sure.  But trying to
>> imply that those are the only problems we need to solve,
>
> No one has tried to imply that. I don't know where you got that.

By your statements implying that composition issues can just be
handled by better discipline and some selector modification, in the
message I responded to earlier.  I'm not sure how to interpret those
statement if you didn't mean that composition wasn't worth solving.

~TJ

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Thu, Feb 5, 2015 at 10:56 AM, Ryosuke Niwa  wrote:
>> On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr.  wrote:
>> On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
>>> Why do we need shadow DOM (or something similar) at all if we expose it
>>> easily to the outside world.
>>> One could even now just require that elements in "components" in a web page
>>> have class="component", and then
>>> .component could be used as >>>. Sure, it would require :not(.component)
>>> usage too.
>>> And from DOM APIs side one could easily implement filtering for the contents
>>> of "components" using small script libraries.
>>
>> Aa;erlhas;dlgpasodifapsldikjf;
>>
>> I keep hearing this kind of sentiment pop up, and I'm like, have you
>> ever done serious webdev?  I know a lot of browser devs haven't, and I
>> don't know if you have or not, but this is the sort of thing that is
>> plain as day if you have.
>
> That sounds rather demeaning and insulting [1].  public-webapps, or a mailing 
> list of any W3C working group, isn't an appropriate forum to rant.

Most browser devs are not webdevs.  This is not an insult nor is it
demeaning.  I've been a member of the W3C for many years, and problems
with browser devs not understanding the issues of real webdevs "on the
ground" have always been rampant.  It's a large part of the reason I
joined the W3C in the first place, so I could help develop CSS specs
that were important for webdevs but being ignored by the browser devs
in the group.

If you find that demeaning, I'm sorry?  It's not something you can
ignore; it's always an elephant in the room when trying to solve
problems that frustrate webdevs.  It really is important to ensure
that browser devs sit down and listen to people with real webdev
experience (such as, for example, Brian Kardell).

>> You don't need strong isolation primitives to do a lot of good.
>> Simple composition helpers lift an *enormous* weight off the shoulders
>> of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
>> precisely that composition helper right now.  In most contexts, you
>> can't ever touch something inside of shadow DOM unless you're doing it
>> on purpose, so there's no way to "friendly fire" (as Brian puts it).
>>
>> Stronger isolation does solve some problems, sure.  But trying to
>> imply that those are the only problems we need to solve, because
>> they're the only problems related to "explaining the current DOM",
>> shows a serious lack of insight into the types of problems experienced
>> by webdevs today, when developing complex webapps.
>
> While I agree those are problems worth solving, let us recognize and respect 
> that different participates of the working group care about different use 
> cases and are interested in solving different set of problems.

That's precisely what I'm getting frustrated with - when people make
suggestions that composition isn't important, and people can "just use
better selectors and some discipline" to solve those problems, it
makes it difficult to have productive conversations.  Composition is a
massive problem with today's webapps.  Isolation is a minor problem
that is important for some valuable use-cases, so it shouldn't be
ignored, but neither should it be elevated to the sole important thing
to be discussed here.

>> There is no naming scheme that accomplishes this.  There is no amount
>> of discipline that will help.  Devs are humans, and webpages are very
>> complicated multi-party computer programs, and helping people organize
>> and manage that complexity is an enormous win.  Existing Shadow DOM
>> composition is a tailored solution to that.  If it looks complex, it's
>> because the platform is complex, and so there's a lot of interface to
>> deal with.  Its core, though, is just "what if this piece of the
>> document was hidden from the rest of the document by default", and you
>> can't cut away much of Shadow DOM without losing that entirely.
> ...
>> Separate-but-related rant: And like, the sort of mindset that can just
>> throw out "Sure, it would require :not(.component) usage too." like it
>> was just some simple thing, easy to implement and do, is amazing.
>> You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors,
>> and need to do it for EVERY COMPONENT.  Heck, to do it correctly, you
>> have to do in on EVERY COMPOUND SELECTOR *within* each selector.  It's
>> optimizing in the exact wrong direction; you have to explicitly say
>> every time that you don't want to match against a finite set of
>> components; missing it once, or adding a new component that you
>> haven't expressed in your
>> giant-list-of-exclusions-on-every-selector-in-your-page, means you've
>> got a potential styling bug.
>
> However, the use case we're talking here is multiple teams working on a 
> single website potentially stepping on each other's toes; implying the 
> enormous size of the entity working on the website.  I have a hard time 
> imagining that any organization of that scal

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Wed, Feb 4, 2015 at 3:56 PM, Ryosuke Niwa  wrote:

>
> > On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr.  wrote:
> >
> > On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
> >> Why do we need shadow DOM (or something similar) at all if we expose it
> >> easily to the outside world.
> >> One could even now just require that elements in "components" in a web
> page
> >> have class="component", and then
> >> .component could be used as >>>. Sure, it would require :not(.component)
> >> usage too.
> >> And from DOM APIs side one could easily implement filtering for the
> contents
> >> of "components" using small script libraries.
> >
> > Aa;erlhas;dlgpasodifapsldikjf;
> >
> > I keep hearing this kind of sentiment pop up, and I'm like, have you
> > ever done serious webdev?  I know a lot of browser devs haven't, and I
> > don't know if you have or not, but this is the sort of thing that is
> > plain as day if you have.
>
> That sounds rather demeaning and insulting [1].  public-webapps, or a
> mailing list of any W3C working group, isn't an appropriate forum to rant.
>

+1.


> However, the use case we're talking here is multiple teams working on a
> single website potentially stepping on each other's toes; implying the
> enormous size of the entity working on the website.  I have a hard time
> imagining that any organization of that scale to not have a sever-side or
> pre-deployment build step for the website at which point they can add a
> preprocessing step to modify all selectors.  e.g. even a website I worked
> on with only four other people had a build step before we could deploy it.
>

The need to modify selectors on the server side is highly symptomatic of
the composition problem remaining unsolved. This processing is not due to
the burning desire of the developers to munge their selectors, but rather
due to their inability to reason about the composition of styles, and
having to rely on out-of-band composition.

For all the criticism Shadow DOM receives, it is currently the only
solution that solves this problem. As I mentioned before, I am very open to
using Shadow DOM to extract a simpler primitive that is more focused on
solving the style composition problem in-band.

However, I would like to first understand if that is the problem that the
group wants to solve. It is unclear from this conversation.

:DG<

Re: Shadow tree style isolation primitive

[Olli Pettay]

On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote:

You don't need strong isolation primitives to do a lot of good.
Simple composition helpers lift an *enormous* weight off the shoulders
of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
precisely that composition helper right now.  In most contexts, you
can't ever touch something inside of shadow DOM unless you're doing it
on purpose, so there's no way to "friendly fire" (as Brian puts it).


If we want to just help with composition, then we can find simpler
model than shadow DOM with its multiple shadow root per host and event handling
oddities and what not. (and all the mess with is-in-doc is still something to 
be sorted out etc.)






Stronger isolation does solve some problems, sure.  But trying to
imply that those are the only problems we need to solve,

No one has tried to imply that. I don't know where you got that.

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr.  wrote:
> 
> On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
>> Why do we need shadow DOM (or something similar) at all if we expose it
>> easily to the outside world.
>> One could even now just require that elements in "components" in a web page
>> have class="component", and then
>> .component could be used as >>>. Sure, it would require :not(.component)
>> usage too.
>> And from DOM APIs side one could easily implement filtering for the contents
>> of "components" using small script libraries.
> 
> Aa;erlhas;dlgpasodifapsldikjf;
> 
> I keep hearing this kind of sentiment pop up, and I'm like, have you
> ever done serious webdev?  I know a lot of browser devs haven't, and I
> don't know if you have or not, but this is the sort of thing that is
> plain as day if you have.

That sounds rather demeaning and insulting [1].  public-webapps, or a mailing 
list of any W3C working group, isn't an appropriate forum to rant.

> You don't need strong isolation primitives to do a lot of good.
> Simple composition helpers lift an *enormous* weight off the shoulders
> of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
> precisely that composition helper right now.  In most contexts, you
> can't ever touch something inside of shadow DOM unless you're doing it
> on purpose, so there's no way to "friendly fire" (as Brian puts it).
> 
> Stronger isolation does solve some problems, sure.  But trying to
> imply that those are the only problems we need to solve, because
> they're the only problems related to "explaining the current DOM",
> shows a serious lack of insight into the types of problems experienced
> by webdevs today, when developing complex webapps.

While I agree those are problems worth solving, let us recognize and respect 
that different participates of the working group care about different use cases 
and are interested in solving different set of problems.

> There is no naming scheme that accomplishes this.  There is no amount
> of discipline that will help.  Devs are humans, and webpages are very
> complicated multi-party computer programs, and helping people organize
> and manage that complexity is an enormous win.  Existing Shadow DOM
> composition is a tailored solution to that.  If it looks complex, it's
> because the platform is complex, and so there's a lot of interface to
> deal with.  Its core, though, is just "what if this piece of the
> document was hidden from the rest of the document by default", and you
> can't cut away much of Shadow DOM without losing that entirely.
...
> Separate-but-related rant: And like, the sort of mindset that can just
> throw out "Sure, it would require :not(.component) usage too." like it
> was just some simple thing, easy to implement and do, is amazing.
> You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors,
> and need to do it for EVERY COMPONENT.  Heck, to do it correctly, you
> have to do in on EVERY COMPOUND SELECTOR *within* each selector.  It's
> optimizing in the exact wrong direction; you have to explicitly say
> every time that you don't want to match against a finite set of
> components; missing it once, or adding a new component that you
> haven't expressed in your
> giant-list-of-exclusions-on-every-selector-in-your-page, means you've
> got a potential styling bug.

However, the use case we're talking here is multiple teams working on a single 
website potentially stepping on each other's toes; implying the enormous size 
of the entity working on the website.  I have a hard time imagining that any 
organization of that scale to not have a sever-side or pre-deployment build 
step for the website at which point they can add a preprocessing step to modify 
all selectors.  e.g. even a website I worked on with only four other people had 
a build step before we could deploy it.

[1] http://www.w3.org/Consortium/cepc/

- R. Niwa

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
> Why do we need shadow DOM (or something similar) at all if we expose it
> easily to the outside world.
> One could even now just require that elements in "components" in a web page
> have class="component", and then
> .component could be used as >>>. Sure, it would require :not(.component)
> usage too.
> And from DOM APIs side one could easily implement filtering for the contents
> of "components" using small script libraries.

Aa;erlhas;dlgpasodifapsldikjf;

I keep hearing this kind of sentiment pop up, and I'm like, have you
ever done serious webdev?  I know a lot of browser devs haven't, and I
don't know if you have or not, but this is the sort of thing that is
plain as day if you have.

You don't need strong isolation primitives to do a lot of good.
Simple composition helpers lift an *enormous* weight off the shoulders
of web devs, and make whole classes of bugs obsolete.  Shadow DOM is
precisely that composition helper right now.  In most contexts, you
can't ever touch something inside of shadow DOM unless you're doing it
on purpose, so there's no way to "friendly fire" (as Brian puts it).

Stronger isolation does solve some problems, sure.  But trying to
imply that those are the only problems we need to solve, because
they're the only problems related to "explaining the current DOM",
shows a serious lack of insight into the types of problems experienced
by webdevs today, when developing complex webapps.

There is no naming scheme that accomplishes this.  There is no amount
of discipline that will help.  Devs are humans, and webpages are very
complicated multi-party computer programs, and helping people organize
and manage that complexity is an enormous win.  Existing Shadow DOM
composition is a tailored solution to that.  If it looks complex, it's
because the platform is complex, and so there's a lot of interface to
deal with.  Its core, though, is just "what if this piece of the
document was hidden from the rest of the document by default", and you
can't cut away much of Shadow DOM without losing that entirely.



-

Separate-but-related rant: And like, the sort of mindset that can just
throw out "Sure, it would require :not(.component) usage too." like it
was just some simple thing, easy to implement and do, is amazing.
You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors,
and need to do it for EVERY COMPONENT.  Heck, to do it correctly, you
have to do in on EVERY COMPOUND SELECTOR *within* each selector.  It's
optimizing in the exact wrong direction; you have to explicitly say
every time that you don't want to match against a finite set of
components; missing it once, or adding a new component that you
haven't expressed in your
giant-list-of-exclusions-on-every-selector-in-your-page, means you've
got a potential styling bug.

I, just, man.  What.  I'm unclear how to have a productive discussion
when this is entertained as a serious suggestion.

~TJ

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Wed, Feb 4, 2015 at 11:36 PM, Olli Pettay  wrote:
> Why should even !important work if the component wants to use its own
> colors?

Because that's how !important usually works.  If the author has
progressed to the point of doing !important, we should assume that
they know what they're doing and let it work.  At the end of the day,
it should be possible for the outer page to have some way of styling
any part of a non-sealed (a la inputs, etc) shadow DOM.  Anyone
claiming this isn't necessary should be sentenced to a year of doing
web dev with jQuery components and hostile clients.

~TJ

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Feb 4, 2015, at 4:56 AM, Olli Pettay  wrote:
> 
> On 02/03/2015 04:22 PM, Brian Kardell wrote:
>> 
>> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay > > wrote:
>> 
>>On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>> 
>>Brian recently posted what looks like an excellent framing of the 
>> composition problem:
>> 
>>
>> https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/
>>
>> 
>> 
>>This is the problem we solved with Shadow DOM and the problem I would 
>> like to see solved with the primitive being discussed on this thread.
>> 
>> 
>> 
>>random comments about that blog post.
>> 
>>[snip]
>>We need to be able to select mount nodes explicitly, and perhaps 
>> explicitly say that all such nodes should be selected.
>>So, maybe, deep(mountName) and deep(*)
>> 
>> Is there a reason you couldn't do that with normal CSS techniques, no 
>> additional combinator?  something like /mount/[id=foo] ?
> 
> That leaves all the isolation up to the outside world.
> If ShadowRoot had something like attribute DOMString name?; which defaults to 
> null and null means deep(name) or deep(*) wouldn't be able
> to find the mount, that would let the component itself to say whether it can 
> deal with outside world poking it CSS.
> 
> 
>> 
>> 
>> [snip]
>> 
>>"It still needs to be possible from the hosting page to say “Yes, I mean 
>> all buttons should be blue”"
>>I disagree with that. It can very well be possible that some component 
>> really must control the colors itself. Say, it uses
>>buttons to indicate if traffic light is red or green. Making both those 
>> buttons suddenly blue would break the whole concept of the
>>component.
>> 
>> 
>> By the previous comment though it seems you are saying it's ok to reach into 
>> the mounts,
> If mount explicitly wants that
> 
> 
> in which case you could do exactly this... Perhaps the
>> shortness of the sentence makes it seem like I am saying something I am not, 
>> basically I'm saying it should be possible to explicitly write rules
>> which do apply inside a mount.
> I agree with "it should be possible to explicitly write rules which do apply 
> inside a mount" assuming the mount itself has been flagged to allow that.
> Otherwise it wouldn't be really explicitlyness, since >>> can just easily 
> select randomly any mount.
> 
> 
>> CSS already gives you all sorts of tools for someone developing a bit in 
>> isolation to say how important it is that
>> this particular rule holds up - you can increase specificity with id-based 
>> nots or use !important or even the style attribute itself if it is that
>> fundamental - what you can't do is protect yourself on either end from 
>> accidental error.  I feel like one could easily over-engineer a solution here
>> and kill its actual chances of success, whereas a smaller change could not 
>> only have a good chance of getting done, but have very outsized impact and
>> provide some of the data on how to improve it further.
> 
> 
> Why do we need shadow DOM (or something similar) at all if we expose it 
> easily to the outside world.
> One could even now just require that elements in "components" in a web page 
> have class="component", and then
> .component could be used as >>>. Sure, it would require :not(.component) 
> usage too.
> And from DOM APIs side one could easily implement filtering for the contents 
> of "components" using small script libraries.
> 
> 
> [Perhaps a bit off topic to the style isolation]
> In other words, I'm not very happy to add super complicated Shadow DOM to the 
> platform if it doesn't really provide anything new which
> couldn't be implemented easily with script libraries and a bit stricter 
> coding styles and conventions.

I concur.  I don't think introducing something as complex as shadow DOM is 
worth our effort if the only problem we're solving is multiple teams at a large 
company stepping on each other.  They could simply use their own framework or 
library, or even create their own convention, to solve that problem for 
themselves.

- R. Niwa

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Wed, Feb 4, 2015 at 7:56 AM, Olli Pettay  wrote:

> On 02/03/2015 04:22 PM, Brian Kardell wrote:
>
>>
>>
>> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay > o...@pettay.fi>> wrote:
>>
>> On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>>
>> Brian recently posted what looks like an excellent framing of the
>> composition problem:
>>
>> https://briankardell.__wordpress.com/2015/01/14/__friendly-
>> fire-the-fog-of-dom/
>> > friendly-fire-the-fog-of-dom/>
>>
>> This is the problem we solved with Shadow DOM and the problem I
>> would like to see solved with the primitive being discussed on this thread.
>
>
[snip]

> If ShadowRoot had something like attribute DOMString name?; which defaults
>> to null and null means deep(name) or deep(*) wouldn't be able
>>
> to find the mount, that would let the component itself to say whether it
> can deal with outside world poking it CSS.


That actually doesn't sound crazy to me.  I mean, it actually fits
pretty nicely into the conceptual model I think and it would add a whole
additional layer of possible protection which is explainable in sort of
"todays terms" with minimal new 'stuff'... the combinator is new anyway and
you're dealing with mount in what seems like a good way there.  I think I
like it.


[snip]

> [Perhaps a bit off topic to the style isolation]
> In other words, I'm not very happy to add super complicated Shadow DOM to
> the platform if it doesn't really provide anything new which
> couldn't be implemented easily with script libraries and a bit stricter
> coding styles and conventions.


I'd suggest that you're radically over-stating - you really can't "easily
solve this problem", even with much stricter coding style, as I explained
in that post.  This is a problem and even without named mount protection
above, this would be a giant leap forward because the -default- thing is to
not match.  Doing 'right' by default is a giant win.  That said, as I say
above, I kinda like the named mount idea...


-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

[Olli Pettay]

On 02/03/2015 04:22 PM, Brian Kardell wrote:



On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay mailto:o...@pettay.fi>> wrote:

On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:

Brian recently posted what looks like an excellent framing of the 
composition problem:


https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/



This is the problem we solved with Shadow DOM and the problem I would 
like to see solved with the primitive being discussed on this thread.



random comments about that blog post.

[snip]
We need to be able to select mount nodes explicitly, and perhaps explicitly 
say that all such nodes should be selected.
So, maybe, deep(mountName) and deep(*)

Is there a reason you couldn't do that with normal CSS techniques, no 
additional combinator?  something like /mount/[id=foo] ?


That leaves all the isolation up to the outside world.
If ShadowRoot had something like attribute DOMString name?; which defaults to 
null and null means deep(name) or deep(*) wouldn't be able
to find the mount, that would let the component itself to say whether it can 
deal with outside world poking it CSS.





[snip]

"It still needs to be possible from the hosting page to say “Yes, I mean all 
buttons should be blue”"
I disagree with that. It can very well be possible that some component 
really must control the colors itself. Say, it uses
buttons to indicate if traffic light is red or green. Making both those 
buttons suddenly blue would break the whole concept of the
component.


By the previous comment though it seems you are saying it's ok to reach into 
the mounts,

If mount explicitly wants that


in which case you could do exactly this... Perhaps the

shortness of the sentence makes it seem like I am saying something I am not, 
basically I'm saying it should be possible to explicitly write rules
which do apply inside a mount.

I agree with "it should be possible to explicitly write rules which do apply inside 
a mount" assuming the mount itself has been flagged to allow that.
Otherwise it wouldn't be really explicitlyness, since >>> can just easily 
select randomly any mount.



 CSS already gives you all sorts of tools for someone developing a bit in 
isolation to say how important it is that
this particular rule holds up - you can increase specificity with id-based nots 
or use !important or even the style attribute itself if it is that
fundamental - what you can't do is protect yourself on either end from 
accidental error.  I feel like one could easily over-engineer a solution here
and kill its actual chances of success, whereas a smaller change could not only 
have a good chance of getting done, but have very outsized impact and
provide some of the data on how to improve it further.



Why do we need shadow DOM (or something similar) at all if we expose it easily 
to the outside world.
One could even now just require that elements in "components" in a web page have 
class="component", and then
.component could be used as >>>. Sure, it would require :not(.component) usage 
too.
And from DOM APIs side one could easily implement filtering for the contents of 
"components" using small script libraries.


[Perhaps a bit off topic to the style isolation]
In other words, I'm not very happy to add super complicated Shadow DOM to the 
platform if it doesn't really provide anything new which
couldn't be implemented easily with script libraries and a bit stricter coding 
styles and conventions.



-Olli




If this doesn't seem -hostile- to decent further improvements, finding 
something minimal but
still very useful might be good.






--
Brian Kardell :: @briankardell :: hitchjs.com 

Re: Shadow tree style isolation primitive

[Olli Pettay]

On 02/03/2015 07:24 PM, Dimitri Glazkov wrote:

Not trying to barge in, just sprinkling data...

On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell mailto:bkard...@gmail.com>> wrote:



On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay mailto:o...@pettay.fi>> wrote:

On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:

Brian recently posted what looks like an excellent framing of the 
composition problem:


https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/



This is the problem we solved with Shadow DOM and the problem I 
would like to see solved with the primitive being discussed on this thread.



random comments about that blog post.

[snip]
We need to be able to select mount nodes explicitly, and perhaps 
explicitly say that all such nodes should be selected.
So, maybe, deep(mountName) and deep(*)

Is there a reason you couldn't do that with normal CSS techniques, no 
additional combinator?  something like /mount/[id=foo] ?


That's ::shadow in the scoping spec: 
http://dev.w3.org/csswg/css-scoping/#shadow-pseudoelement



[snip]

"It still needs to be possible from the hosting page to say “Yes, I mean all 
buttons should be blue”"
I disagree with that. It can very well be possible that some component 
really must control the colors itself. Say, it uses
buttons to indicate if traffic light is red or green. Making both those 
buttons suddenly blue would break the whole concept of the
component.


This is still possible, and works in a predictable way with today's styling 
machinery. Use inline styles on the button that you want to be green/red
inside of the scope, and no /deep/ or /mount/ or >>> will be able to affect it: 
http://jsbin.com/juyeziwaqo/1/edit?html,css,js,output ... unless the
war progressed to the stage where "!important" is used as hammer.



Why should even !important work if the component wants to use its own colors?






:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

Not trying to barge in, just sprinkling data...

On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell  wrote:

>
>
> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay  wrote:
>
>> On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>>
>>> Brian recently posted what looks like an excellent framing of the
>>> composition problem:
>>>
>>> https://briankardell.wordpress.com/2015/01/14/
>>> friendly-fire-the-fog-of-dom/
>>>
>>> This is the problem we solved with Shadow DOM and the problem I would
>>> like to see solved with the primitive being discussed on this thread.
>>>
>>>
>>
>> random comments about that blog post.
>
>
>
>> [snip]
>> We need to be able to select mount nodes explicitly, and perhaps
>> explicitly say that all such nodes should be selected.
>> So, maybe, deep(mountName) and deep(*)
>>
>> Is there a reason you couldn't do that with normal CSS techniques, no
> additional combinator?  something like /mount/[id=foo] ?
>

That's ::shadow in the scoping spec:
http://dev.w3.org/csswg/css-scoping/#shadow-pseudoelement


>
>
> [snip]
>
>> "It still needs to be possible from the hosting page to say “Yes, I mean
>> all buttons should be blue”"
>> I disagree with that. It can very well be possible that some component
>> really must control the colors itself. Say, it uses
>> buttons to indicate if traffic light is red or green. Making both those
>> buttons suddenly blue would break the whole concept of the
>> component.
>>
>
This is still possible, and works in a predictable way with today's styling
machinery. Use inline styles on the button that you want to be green/red
inside of the scope, and no /deep/ or /mount/ or >>> will be able to affect
it: http://jsbin.com/juyeziwaqo/1/edit?html,css,js,output ... unless the
war progressed to the stage where "!important" is used as hammer.

:DG<

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay  wrote:

> On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>
>> Brian recently posted what looks like an excellent framing of the
>> composition problem:
>>
>> https://briankardell.wordpress.com/2015/01/14/
>> friendly-fire-the-fog-of-dom/
>>
>> This is the problem we solved with Shadow DOM and the problem I would
>> like to see solved with the primitive being discussed on this thread.
>>
>>
>
> random comments about that blog post.



> [snip]
> We need to be able to select mount nodes explicitly, and perhaps
> explicitly say that all such nodes should be selected.
> So, maybe, deep(mountName) and deep(*)
>
> Is there a reason you couldn't do that with normal CSS techniques, no
additional combinator?  something like /mount/[id=foo] ?


[snip]

> "It still needs to be possible from the hosting page to say “Yes, I mean
> all buttons should be blue”"
> I disagree with that. It can very well be possible that some component
> really must control the colors itself. Say, it uses
> buttons to indicate if traffic light is red or green. Making both those
> buttons suddenly blue would break the whole concept of the
> component.
>

By the previous comment though it seems you are saying it's ok to reach
into the mounts, in which case you could do exactly this... Perhaps the
shortness of the sentence makes it seem like I am saying something I am
not, basically I'm saying it should be possible to explicitly write rules
which do apply inside a mount.  CSS already gives you all sorts of tools
for someone developing a bit in isolation to say how important it is that
this particular rule holds up - you can increase specificity with id-based
nots or use !important or even the style attribute itself if it is that
fundamental - what you can't do is protect yourself on either end from
accidental error.  I feel like one could easily over-engineer a solution
here and kill its actual chances of success, whereas a smaller change could
not only have a good chance of getting done, but have very outsized impact
and provide some of the data on how to improve it further.  If this doesn't
seem -hostile- to decent further improvements, finding something minimal
but still very useful might be good.




>
>
> -Olli
>



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

[Olli Pettay]

On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:

Brian recently posted what looks like an excellent framing of the composition 
problem:

https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/

This is the problem we solved with Shadow DOM and the problem I would like to 
see solved with the primitive being discussed on this thread.




random comments about that blog post.

"Its intuitive then to create a combinator in CSS which allows you to select the 
mount explicitly"
Yes, I agree with that assuming the mount actually wants to be selectable.
And even if all the mounts were selectable, we don't have atm a way to select 
some particular
mount explicitly. And I think we should have that explicitly-ness. >>> or 
/deep/ are like
select all and cross your fingers you selected what you wanted, and not 
anything more.
We need to be able to select mount nodes explicitly, and perhaps explicitly say 
that all such nodes should be selected.
So, maybe, deep(mountName) and deep(*)


"It still needs to be possible from the hosting page to say “Yes, I mean all buttons 
should be blue”"
I disagree with that. It can very well be possible that some component really 
must control the colors itself. Say, it uses
buttons to indicate if traffic light is red or green. Making both those buttons 
suddenly blue would break the whole concept of the
component.


Without the explicitly-ness we're back having the initial problems we're trying 
to solve, as the
blog says
"That is, preventing accidental violence against your allies is really hard – it’s simply too easy to accidentally select and operate on elements that 
aren’t “yours“. "

Same explicitly-ness should apply to things like Event.path etc.




(I still think shadow DOM needs proper encapsulation, even if components would 
all be 'allies'. A use case for encapsulation
would be rather similar to private: or protected: in many languages. But 
encapsulation is perhaps a bit different issue from
weaker isolation.)



-Olli

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

Brian recently posted what looks like an excellent framing of the
composition problem:

https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/

This is the problem we solved with Shadow DOM and the problem I would like
to see solved with the primitive being discussed on this thread.

:DG<

Re: Shadow tree style isolation primitive

[Anne van Kesteren]

On Wed, Jan 14, 2015 at 2:11 AM, Brian Kardell  wrote:
> So if that is a given, why can we not start there and explain how it would
> work and use it to fashion increasingly high abstractions - hopefully with
> the ability to do some experimentation outside of native implementations?

Because you don't want CSS to influence markup or DOM. So putting the
primitive in markup or DOM is the wrong way around.


-- 
https://annevankesteren.nl/

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Tue, Jan 13, 2015 at 8:09 PM, Ryosuke Niwa  wrote:

>
> On Jan 13, 2015, at 3:46 PM, Brian Kardell  wrote:
>
>
>
> On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa  wrote:
>
> To separate presentational information (CSS) from the semantics (HTML).
>> Defining both style isolation boundaries and the associated CSS rules in an
>> external CSS file will allow authors to change both of them without having
>> to modify every HTML documents that includes the CSS file.  Of course, this
>> is a non-starter for Web apps that require a lot of scripting, but style
>> isolation is a very useful feature for a lot of static pages as well.
>>
>> - R. Niwa
>>
>>
> Ryosuke,
>
> Should you also be able to do this from JavaScript/DOM in your opinion?
> Like, forget shadow dom as it is today in chrome or proposed -- should you
> be able to do something like
>
> ```
> element.isolateTree = true;
> ```
>
> and achieve a similar effect?  If not, why specifically?
>
>
> Or element.setAttribute('isolatetree', true);  I can't think of a reason
> not to do this.
>
> - R. Niwa
>
>
So if that is a given, why can we not start there and explain how it would
work and use it to fashion increasingly high abstractions - hopefully with
the ability to do some experimentation outside of native implementations?


-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Jan 13, 2015, at 3:46 PM, Brian Kardell  wrote:
> 
> 
> 
> On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa  > wrote:
> 
> To separate presentational information (CSS) from the semantics (HTML).  
> Defining both style isolation boundaries and the associated CSS rules in an 
> external CSS file will allow authors to change both of them without having to 
> modify every HTML documents that includes the CSS file.  Of course, this is a 
> non-starter for Web apps that require a lot of scripting, but style isolation 
> is a very useful feature for a lot of static pages as well.
> 
> - R. Niwa
> 
> 
> Ryosuke, 
> 
> Should you also be able to do this from JavaScript/DOM in your opinion?  
> Like, forget shadow dom as it is today in chrome or proposed -- should you be 
> able to do something like
> 
> ```
> element.isolateTree = true;
> ```
> 
> and achieve a similar effect?  If not, why specifically?

Or element.setAttribute('isolatetree', true);  I can't think of a reason not to 
do this.

- R. Niwa

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa  wrote:

To separate presentational information (CSS) from the semantics (HTML).
> Defining both style isolation boundaries and the associated CSS rules in an
> external CSS file will allow authors to change both of them without having
> to modify every HTML documents that includes the CSS file.  Of course, this
> is a non-starter for Web apps that require a lot of scripting, but style
> isolation is a very useful feature for a lot of static pages as well.
>
> - R. Niwa
>
>
Ryosuke,

Should you also be able to do this from JavaScript/DOM in your opinion?
Like, forget shadow dom as it is today in chrome or proposed -- should you
be able to do something like

```
element.isolateTree = true;
```

and achieve a similar effect?  If not, why specifically?




-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

On Jan 13, 2015, at 4:15 AM, cha...@yandex-team.ru wrote:

> 13.01.2015, 00:57, "Ryosuke Niwa" :
>>>  On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote:
>>> 
>>>  09.01.2015, 16:42, "Anne van Kesteren" :
  I'm wondering if it's feasible to provide developers with the
  primitive that the combination of Shadow DOM and CSS Scoping provides.
  Namely a way to isolate a subtree from selector matching (of document
  stylesheets, not necessarily user and user agent stylesheets) and
  requiring a special selector, such as >>>, to pierce through the
  boundary.
>>>  Sounds like a reasonable, and perhaps feasible thing to do, but the 
>>> obvious question is "why?"
>>> 
>>>  The use cases I can think of are to provide the sort of thing we do with 
>>> BEM today. Is the effort worth it, or are there other things I didn't think 
>>> of (quite likely, given I spent multiple seconds on the question)?
>> 
>> The benefit of this approach is that all the styling information will be in 
>> one place.  CSS cascading rules is already complicated, and having to 
>> consult the markup to know where the selector boundary is will be yet 
>> another cognitive stress.
> 
> Sorry, I'm dense this morning for sure. Why would all the styling information 
> be in one place? I'm still thinking from the model of BEM, where the benefit 
> is that for a particular block you can collect everything (styling, scripts, 
> whatever magic you want - or just a couple of plain tags and 4 words) in one 
> place, and the different pieces get stitched together without having to worry 
> about how they will impact each other because ordinarily they won't.

To separate presentational information (CSS) from the semantics (HTML).  
Defining both style isolation boundaries and the associated CSS rules in an 
external CSS file will allow authors to change both of them without having to 
modify every HTML documents that includes the CSS file.  Of course, this is a 
non-starter for Web apps that require a lot of scripting, but style isolation 
is a very useful feature for a lot of static pages as well.

- R. Niwa

Re: Shadow tree style isolation primitive

[chaals]

13.01.2015, 00:57, "Ryosuke Niwa" :
>>  On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote:
>>
>>  09.01.2015, 16:42, "Anne van Kesteren" :
>>>  I'm wondering if it's feasible to provide developers with the
>>>  primitive that the combination of Shadow DOM and CSS Scoping provides.
>>>  Namely a way to isolate a subtree from selector matching (of document
>>>  stylesheets, not necessarily user and user agent stylesheets) and
>>>  requiring a special selector, such as >>>, to pierce through the
>>>  boundary.
>>  Sounds like a reasonable, and perhaps feasible thing to do, but the obvious 
>> question is "why?"
>>
>>  The use cases I can think of are to provide the sort of thing we do with 
>> BEM today. Is the effort worth it, or are there other things I didn't think 
>> of (quite likely, given I spent multiple seconds on the question)?
>
> The benefit of this approach is that all the styling information will be in 
> one place.  CSS cascading rules is already complicated, and having to consult 
> the markup to know where the selector boundary is will be yet another 
> cognitive stress.

Sorry, I'm dense this morning for sure. Why would all the styling information 
be in one place? I'm still thinking from the model of BEM, where the benefit is 
that for a particular block you can collect everything (styling, scripts, 
whatever magic you want - or just a couple of plain tags and 4 words) in one 
place, and the different pieces get stitched together without having to worry 
about how they will impact each other because ordinarily they wont.

(The corresponding "cognitive price" is that if you *want* to do things 
page-wide across a bunch of different blocks, you need to think more).

Could you provide a slightly longer-form answer for dummies (i.e. me) please?

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Shadow tree style isolation primitive

[Hayato Ito]

"Intent to remove 

Re: Shadow tree style isolation primitive

[Marc Fawzi]

Can someone shed light at why Scoped Style Element was removed from Chrome
experimental features?

http://caniuse.com/#feat=style-scoped

In suggesting @isolate declaration, I meant it would go inside a scoped
style element. If there are nested scope style elements and each have
@isolate then it means that the styles don't bleed from parent with scoped
style to child with scoped style if child has @isolate

The big question is why was scoped style element removed from Chrome 37's
experimental flags?

Just curious.



On Mon, Jan 12, 2015 at 6:27 PM, Ryosuke Niwa  wrote:

>
> > On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr. 
> wrote:
> >
> > On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa  wrote:
> >>> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. 
> wrote:
> >>> [ryosuke, your mail client keeps producing flattened replies. maybe
> >>> send as plain-text, not HTML?]
> >>
> >> Weird.  I'm not seeing that at all on my end.
> >
> > It's sending HTML-quoted stuff, which doesn't survive the flattening
> > to plain-text that I and a lot of others do.  Plain-text is more
> > interoperable.
> >
> >>> The style defined for  *in 's setup code* (that is, in a
> >>> 

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr.  wrote:
> 
> On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa  wrote:
>>> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr.  wrote:
>>> [ryosuke, your mail client keeps producing flattened replies. maybe
>>> send as plain-text, not HTML?]
>> 
>> Weird.  I'm not seeing that at all on my end.
> 
> It's sending HTML-quoted stuff, which doesn't survive the flattening
> to plain-text that I and a lot of others do.  Plain-text is more
> interoperable.
> 
>>> The style defined for  *in 's setup code* (that is, in a
>>> 

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa  wrote:
>> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr.  wrote:
>> [ryosuke, your mail client keeps producing flattened replies. maybe
>> send as plain-text, not HTML?]
>
> Weird.  I'm not seeing that at all on my end.

It's sending HTML-quoted stuff, which doesn't survive the flattening
to plain-text that I and a lot of others do.  Plain-text is more
interoperable.

>> The style defined for  *in 's setup code* (that is, in a
>> 

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr.  wrote:
> 
> [ryosuke, your mail client keeps producing flattened replies. maybe
> send as plain-text, not HTML?]

Weird.  I'm not seeing that at all on my end.

> The style defined for  *in 's setup code* (that is, in a
> 

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

[ryosuke, your mail client keeps producing flattened replies. maybe
send as plain-text, not HTML?]

On Mon, Jan 12, 2015 at 5:23 PM, Ryosuke Niwa  wrote:
> On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr.  wrote:
>> On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa  wrote:
>>> On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr.  wrote:
 ? I didn't mention DOM APIs.  I'm referring back to the example you're
 replying to - if you use a  element inside your  component,
 and you know that  has isolation styles, you have to specifically
 call that out inside your  styling so that it (a) is shielded
 from your foo styles, and (b) is able to pick up the global definition
 for bar styles.  This is relatively clumsy.  Some of the other
 solutions attach the "I want to be isolated" information to the
 element itself more directly, so you don't have to worry about what
 you put inside of yourself.
>>>
>>> This is no more clumsy than defining an insertion points in shadow DOM.  Or
>>> am I misunderstanding you?
>>
>> Yeah.  In Shadow DOM, you can just *use* the  element, without
>> having to think about it.
>
> I don't know what you mean by one doesn't have to think about it.  The style
> applied on  won't propagate into the shadow DOM by default [1] unless
> we use /deep/ or >>> [2]

The style defined for  *in 's setup code* (that is, in a

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr.  wrote:
> 
> [oof, somehow your latest response flattened all of the quotes]
> 
> On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa  wrote:
>> On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr.  wrote:
>>> ? I didn't mention DOM APIs.  I'm referring back to the example you're
>>> replying to - if you use a  element inside your  component,
>>> and you know that  has isolation styles, you have to specifically
>>> call that out inside your  styling so that it (a) is shielded
>>> from your foo styles, and (b) is able to pick up the global definition
>>> for bar styles.  This is relatively clumsy.  Some of the other
>>> solutions attach the "I want to be isolated" information to the
>>> element itself more directly, so you don't have to worry about what
>>> you put inside of yourself.
>> 
>> This is no more clumsy than defining an insertion points in shadow DOM.  Or
>> am I misunderstanding you?
> 
> Yeah.  In Shadow DOM, you can just *use* the  element, without
> having to think about it.

I don't know what you mean by one doesn't have to think about it.  The style 
applied on  won't propagate into the shadow DOM by default [1] unless we 
use /deep/ or >>> [2]

>>> I listed a number of APIs in the text you're responding to, all of
>>> which may or may not want to pay attention to style isolation,
>>> depending on the use-case.  I'm not saying you necessarily need DOM
>>> isolation for any given use-case.  I'm saying that there are a lot of
>>> APIs that query or walk the DOM, and whether they should pay attention
>>> to a "style isolation" boundary is a question without clear answers.
>> 
>> I don't understand what you mean here.  As far as I know, there are only two
>> sensible options here:
>> 
>> Style isolation implies DOM subtree isolation in all DOM APIs
>> Style isolation doesn't affect DOM APIs at all
>> 
>> Shadow DOM does 1.  I'm suggesting that we need a mechanism to do 2.  It's
>> not terrible if we introduced @isolate to do 1 and also provided shadow DOM
>> to do 1.  In that world, shadow DOM is a syntax sugar around @isolate in the
>> CSS land with DOM API implications.
> 
> I mean, those are two possible options.  They're not the only ones.
> For example, you could say that all selectors pay attention to the
> isolation boundary, so qSA is affected.  That's *a* consistent answer,
> and could be very reasonable - people often use qSA to do
> styling-related things, and having it respect the style boundaries
> makes sense there.
> 
> I'm saying there are multiple places you can draw the line.  I think
> there's a nice defensible spot at the point you end up with when you
> do DOM isolation - everything that cares about the DOM tree (which
> includes CSS selectors, defined in terms of the DOM tree) gets locked
> out by default.  Anywhere else has arguments for it, but I don't think
> any of them are particularly more compelling than any other.

What are other sensible alternatives?  I agree there are other options but they 
aren't sensible as far as I'm concerned.

[1] http://jsfiddle.net/seyL1vqn/ 
[2] http://jsfiddle.net/seyL1vqn/1/ 

- R. Niwa

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Mon, Jan 12, 2015 at 4:45 PM, Ryosuke Niwa  wrote:
> I understand your use case but please also understand that some authors
> don't want to write a few dozen lines of JavaScript to create a shadow DOM,
> and hundreds of lines of code or load a framework to decoratively isolate
> CSS rules in their pages.

I agree that having a *simpler* way to define the shadow boundaries
could potentially make sense.  It wouldn't be a matter of splitting
apart more primitives, but instead of defining new sugar on top of the
existing stuff, to have a simple declarative mechanism for "make this
element push all of its contents into a shadow tree", potentially also
with some simple way to define styles for elements of that type.

I'm not saying the current status quo is 100% ideal, just that I think
the lines it draws are theoretically pretty useful.

Previously I said that it was a problem if the isolation selector
could pierce isolations - I think that's true of *general* selectors,
because, for example, classes are often reused for different meanings
in different parts of the page.  But if we restrict it to *element
names*, it's probably more okay; those are more identity-based, which
is part of why we're using them for components in the first place.
Imagine that the markup could look something like:

```

  
  /* Or whatever, just need some declarative mechanism for custom
element names. */


  ...

...

p { color: red; } /* only affects the p.two element, as p.one is
inside the x-foo's isolation */
x-foo::shadow p { color: blue; } /* does target the p.one element,
standard shadow-dom styling rules */
@in-shadow-of x-foo {
  p { color: green; }
  /* treated as a style *inside* the shadow dom, for short selectors
and normal specificity rules */
  /* thus, this targets p.one */
  /* interacts with the previous `x-foo::shadow p` rule in
already-defined shadow-dom way. */
  /* this style is also shared between the various x-foo elements that
may be on the page */
  /* to style a single specific one, append a