Re: Shadow tree style isolation primitive

[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 <rniwa@apple.com> wrote:
> On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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]

The style defined for <bar> *in <bar>'s setup code* (that is, in a
<style> contained inside <bar>'s shadow tree) works automatically
without you having to care about what <bar> is doing.  <bar> is like a
replaced element - it has its own rendering, and you can generally
just leave it alone to do its thing.

In the previous examples, we weren't talking about defining styling
for <bar>s that are specifically inside of <foo>s, just how to style
<bar> generically, regardless of its context.  Current shadow DOM
makes that easy to do without requiring the different components to
know about each other in any way; the declarative CSS mechanisms we
were previously discussing did not.

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

I listed several in the text you're responding to, and previous replies.

~TJ

Received on Tuesday, 13 January 2015 01:42:01 UTC