- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 12 Jan 2015 16:59:36 -0800
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
[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