Need to update CSS Scoping for closed shadow tree

[kojiishi]

Cascade Order for CSS rules from different shadow trees should be aware whether a tree is closed or not, and probably define different rules if closed.

Pointed out by @rniwa in an off-list conversation.

[hayatoito]

Could you elaborate? I don't see why cascading order should be aware of a closed mode, given that a selector defined in ancestor trees is never applied to a node in a closed shadow tree.

[annevk]

We still need to say what happens to inheritance, I think.

[hayatoito]

Yeah, but that sounds an orthogonal issue to me. That's not what the cascading order should mention.

BTW, Shadow DOM had a feature of resetInheritance in the past, but we removed it from the spec because we can achieve the same effect by using css property, all.

[kojiishi]

given that a selector defined in ancestor trees is never applied to a node in a closed shadow tree.

I meant that, I agree with what you wrote and I believe it is a common understanding among us, but I could not find definitions in relevant specs (Shadow DOM spec, CSS Scoping spec, nor in the @rune-opera's proposal).

I suppose there are several edge cases that I think it's worth to clarify, such as:

1. Closed shadow tree has closed child shadow tree. Should we prevent cascading? Probably yes?
2. Closed shadow tree has open child shadow tree. Should we cascade? Probably yes?
3. Closed shadow tree has open child shadow tree, and the child uses :host. Should this work, or prevented?
4. A closed shadow tree has open child shadow tree, and the child shadow tree used ::content, in which case the distributed content could be in a closed tree. I guess it should work?

Sorry that I haven't given a full thought yet and dumping as I think, but these look a bit complicated, no?

(hayato: Sorry, I accidentally edited this comment. I hope I reverted it correctly :).

[annevk]

It does seem though that ideally all this is defined in CSS directly. Especially once we move Shadow DOM into DOM it would not make sense to define adhoc adjustments to CSS cascade and inheritance there.

[kojiishi]

It does seem though that ideally all this is defined in CSS directly. Especially once we move Shadow DOM into DOM it would not make sense to define adhoc adjustments to CSS cascade and inheritance there.

Agreed, but I would prefer making discussions and a consensus here, then update the CSS spec. @rune-opera and we tried to discuss at www-style, but didn't really work well without all background we discussed here.

So I'd like to make sure everyone is happy with what we want, then update the CSS Scoping spec. I guess it'd be easier for the editors of CSS Scoping to update the spec if the proposal is a consensus of Shadow DOM experts in this WG.

[hayatoito]

In all cases, I think we don't need to modify the proposed cascading order. To me, your concerns look to depends on the definition about how each selector should behave across shadow boundaries.

1. Closed shadow tree has closed child shadow tree. Should we prevent cascading? Probably yes?
2. Closed shadow tree has open child shadow tree. Should we cascade? Probably yes?

I think we don't need to modify the proposal in either case. That's the problem about how a selector matches an element in a child tree.

• If it doesn't match, the cascading order doesn't matter.
• If it matches, the cascading order matters. The cascading order proposal is good enough in this case, I think.

1. Closed shadow tree has open child shadow tree, and the child uses :host. Should this work, or prevented?

Yes. Note that it depends on the definition of :host. The cascading order proposal is good enough in this case.

1. A closed shadow tree has open child shadow tree, and the child shadow tree used ::content, in which case the distributed content could be in a closed tree. I guess it should work?

Yes. Note that it depends on the definition of ::content. The cascading order proposal is good enough in this case.

[kojiishi]

Ah, got the points. I was taking the proposal as an patch to CSS Cascading/Scoping, while you're thinking it only for Cascading Order, correct?

I guess then the title of this issue is incorrect, I should say "Need to update CSS Scoping for closed shadow tree." Are we in sync then?

[hayatoito]

I got it. That makes sense.

My point is:

1. We might want to update "3.2. Shadow DOM Selectors [1]" for closed shadow tree, however, I think there is no selectors which we should update for closed shadow tree. /deep/ and ::shadow were gone. Other selectors are okay as is in terms of open/closed. Note that there is a discussion about preserving /deep/ and ::shadow selectors for static profile. So we might want to update these selectors for closed shadow tree.
2. We don't have to mention closed shadow tree in "3.3 Shadow Cascading & Inheritance" [2]

The proposal [3] is trying to update only "3.3 Shadow Cascading & Inheritance".

[1] https://drafts.csswg.org/css-scoping/#selectors
[2] https://drafts.csswg.org/css-scoping/#shadow-cascading
[3] https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md

[hayatoito]

It looks we have to add one more action item:

• Making ::content take only a simple selector, instead of a selector.

The current ability of ::content, which can take a selector, makes the implementation of style engine harder. We'd like to simplify it.

We believe that a simple selector meets the requirements.

Quoted from the Polymer developer:

Re: ​​::content(selector), I am not sure how much this helps cascading per se. I am just suggesting that ::content's ability to target descendants is not necessary for us. We only need to style distributed children. If we could make that change to ::content, it seems like there is opportunity to simplify the implementation.

[hayatoito]

Given that ::content was already shipped in Blink and I've seen users who already use ::content which is followed by a (relative) selector, e.g. "::content > div", it might be difficult to change the behavior of ::content in Blink.
We might need a new name for ::content [followed-by-a-simple-selector].

[TakayoshiKochi]

I'm somewhat confused about Hayato's last 3 comments in this thread.
Are these relevant in terms of a shadow tree is open or closed?

If not, can we close this issue?

[hayatoito]

Which part of the comment is confusing?

FYI. The semantics of ::slotted (::content) is now under the discussion in
#331.
I think whether open or closed is irreverent for ::slotted, at least.

[TakayoshiKochi]

You had 3 points (below is my understanding):

1. we should mention behavior for closed shadow tree for /deep/ and ::shadow if we decide to keep them in the static profile.
2. nothing to be done for css-scoping spec's "Shadow Cascading & Inheritance" section about closed mode
3. ::slotted can take only simple selector

For 1, it might still be relevant, but for CSS Selectors spec? https://drafts.csswg.org/selectors/
For 2, if nothing to be done, it is irrelevant
For 3, as you mentioned in the previous comment, open or closed is irrelevant.

Then what is keeping this issue open?
Anyway, cascading order does not change anything whether the shadow tree is open or closed, right?

[hayatoito]

Yeah, that's what I said and I got no response from anyone.

[rniwa]

It seems like the last meeting's consensus was that we want to minimize the difference between closed and open modes in terms of styling behaviors so I think 2 is not controversial. We'll use whatever default we'd pick for both open and closed modes.

For 1, we (Apple) would not want to keep ::shadow and /deep/ even in static profile.

For 3, we (Apple) are fine with restricting it to the simple selector especially for V1. However, we might want to keep semantics for ::slotted forward compatible with more complex selectors.

[hayatoito]

@kojiishi , do you think we can close this issue?

For 1, we can use #78
For 3, we can use #331

Do you have any remaining issue or concern in this discussion?

[kojiishi]

Looks great to me, closing.