Re: Shadow tree style isolation primitive

[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.  If it happens to also use shadows to
isolate its contents, that's irrelevant to you; you dont' have to make
a single change to your <foo> component in order to recognize that.
That's nice composition, which isn't *strictly* necessary in any
solution, but it's a really good thing.

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

~TJ

Received on Tuesday, 13 January 2015 01:00:29 UTC