Shadow tree encapsulation and CSS

[annevk]

I'd like to open this as a tracking issue to figure out to what extent CSS and Selectors violate the encapsulation principles we agreed on and what can be done about it. If you know of any such issues please add them here.

A clear one to start with is :focus-within. If :focus matches and :focus-within does not, there's a shadow tree. (To be clear, the mere fact of exposing that there is a shadow tree violates encapsulation, as previously established.)

cc @emilio @tabatkins @fantasai

[emilio]

/cc @rniwa too

[emilio]

Well, to be clear, the condition here is that :focus-within matches, :focus does not, and document.activeElement is the element you're testing against.

[tabatkins]

There is no case in which :focus matches but :focus-within doesn't; that's impossible, as :focus-within is defined as a superset of :focus. Did you mean the reverse, where an element matches :focus-within but none of the inclusive descendants match :focus?

[emilio]

Yeah, that's it.

[tabatkins]

What is returned by document.activeElement when the focus is in a shadow tree? Does open/closed matter?

[emilio]

It's retargeted, it doesn't matter whether it's an open or closed ShadowRoot.

[tabatkins]

If it's retargeted, doesn't that affect :focus, too? The Selectors definition of :focus is deliberately a little vague to allow host languages some wiggle room in defining it.

[emilio]

Right now it does not in any browser. It could be defined to be like that and make :focus match for all containing shadow hosts, but that wouldn't be a reasonable definition, you need to account for the cascade origin as well at least. See:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/X-qPSmdSR_g/kZ-4UHdpAwAJ

/cc @hayatoito

[tabatkins]

Are you referring to the fact that UA sheets match in all shadow contexts? (Thus a retargeted :focus rule would match on every shadow host up to the outer light DOM, when an element in a deeply-nested component was focused.)

That could be taken care of, I suppose.

[tabatkins]

But note then that the issue in Anne's original comment is thus further wrong; there's nothing wrong with :focus-within, as it exposes no information not already exposed via JS (the retargeted .activeElement), but rather this is an old issue with focus (more generally, not just the :focus pseudo-class) and shadow DOM, which has been known for years.

(In other words, it's the pre-existing fact that :focus and .activeElement can mismatch that reveals there's a shadow tree. :focus-within doesn't bring anything new here.)

[annevk]

That is a good point, I should not have filed this in haste. If both :focus and :focus-within were to match on shadow hosts, as they do on other elements that have no (node tree) children and are focusable (somehow), it'd be fine. It's unclear if that's doable for :focus at this point of course. (Apart from the default style sheet problem @emilio raised.)

The thing that's true for :focus is also a question for :fullscreen and I suppose this new :picture-in-picture pseudo-class.

The other issue I was thinking of when filing this is whatwg/html#3748.

[hayatoito]

FYI.

• :focus is defined at https://w3c.github.io/webcomponents/spec/shadow/#focus
• It looks there is an filed issue: Upstream focus navigation behavior for delegatesFocus from W3C spec. whatwg/html#2013
• @rakina took over focus related works from the former google who was working on this.

[rakina]

@rakina took over focus related works from the former google who was working on this.

FYI, I'm not working on this area anymore. cc @chrishtr who's taking over things related to this.