Re: Shadow tree style isolation primitive

> On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> [oof, somehow your latest response flattened all of the quotes]
> 
> On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> ? I didn't mention DOM APIs.  I'm referring back to the example you're
>>> replying to - if you use a <bar> element inside your <foo> component,
>>> and you know that <bar> has isolation styles, you have to specifically
>>> call that out inside your <foo> 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 <bar> 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 <bar> 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/ <http://jsfiddle.net/seyL1vqn/>
[2] http://jsfiddle.net/seyL1vqn/1/ <http://jsfiddle.net/seyL1vqn/1/>

- R. Niwa