Skip to content

[css-overflow-5] :focus and :focus-within styles with focused scroller pseudo-element #11361

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
flackr opened this issue Dec 12, 2024 · 2 comments

Comments

@flackr
Copy link
Contributor

flackr commented Dec 12, 2024

When the user has focused a ::scroll-button or ::scroll-marker, the returned document.activeElement is the scrolling container as the activeElement API expects an element and this is consistent with having an "inner navigable" on the scrolling container similar to a shadow tree or inner frame per https://html.spec.whatwg.org/multipage/interaction.html#dom-documentorshadowroot-activeelement-dev:

For the purposes of this API, when a child navigable is focused, its container is focused within its parent's active document. For example, if the user moves the focus to a text control in an iframe, the iframe is the element returned by the activeElement API in the iframe's node document.

Similarly, when the focused element is in a different node tree than documentOrShadowRoot, the element returned will be the host that's located in the same node tree as documentOrShadowRoot if documentOrShadowRoot is a shadow-including inclusive ancestor of the focused element, and null if not.

The question is when these pseudos are focused, which elements have :focus or :focus-within styles?

Since the pseudos themselves can be styled by :focus, I think the most natural would be that the scrolling container matches :focus-within but not :focus. This seems the most natural, but is inconsistent with iframes and shadow dom (see demo):

  • When an element in a subframe is focused, it seems to not apply focus or focus-within to the frame container
  • shadow dom applies :focus to the host element and :focus-within to it and its ancestors.
@tabatkins
Copy link
Member

I agree with this, and think the "inconsistency" is just fine. Despite some similarities, pseudo-element trees aren't shadow DOMs or iframes; they more closely resemble ordinary light-dom subtrees in the relevant aspects here.

(iframes are independent documents, and so can each have a focused element; reflecting their focus into the parent would imply the parent document can have multiple focused elements, violating an invariant we currently hold to. Shadow trees don't expose their existence at all in many ways, and the outside world instead sees only the host element; the host thus can't be :focus-within without exposing the existence of a shadow tree that holds the :focus.)

So, the focused pseudo-element should match :focus, and when a scroll-marker is focused, the scroll-marker-group should match :focus-within.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-overflow-5] :focus and :focus-within styles with focused scroller pseudo-element, and agreed to the following:

  • RESOLVED: The document.activeElement is the scroll container for a focused ::scroll-marker or ::scroll-button. :focus matches only on the specific focused pseudo-element. :focus-within matches on the ::scroll-marker-group for ::scroll-marker, and the scroll container and all ancestors for both ::scroll-marker and ::scroll-button
The full IRC log of that discussion <andreubotella> flackr: Scroll markers and scroll buttons are focusable, and we need to have reasonable behavior for the active element and :focus and :focus-within pseudos
<andreubotella> flackr: the focus elment has to be an element, or it would break existing content
<andreubotella> flackr: similar to shadow dom
<andreubotella> flackr: similar to shadow dom where the host is focused, the scrolling container is the host of the pseudoelements
<andreubotella> flackr: the :focus and :focus-within pseudos follow the existing behavior, so :focus only matches on the pseudo which is focused, and :focus-within matches on the scroll container and the scroll marker group
<andreubotella> flackr: and any ancestor of the scroll container
<andreubotella> flackr: if you have a focused element, that's the thing that has focused and the ancestors have :focus-within
<andreubotella> flackr: this does the same for pseudos with the requirement that it needs to be an element
<flackr> Proposed resolution: The document.activeElement is the scroll container for a focused ::scroll-marker or ::scroll-button. :focus matches only on the specific focused pseudo-element. :focus-within matches on the ::scroll-marker-group for ::scroll-marker, and the scroll container and all ancestors for both ::scroll-marker and ::scroll-button
<andreubotella> RESOLVED: The document.activeElement is the scroll container for a focused ::scroll-marker or ::scroll-button. :focus matches only on the specific focused pseudo-element. :focus-within matches on the ::scroll-marker-group for ::scroll-marker, and the scroll container and all ancestors for both ::scroll-marker and ::scroll-button
<fantasai> scribenick: fantasai
<emilio> It looks reasonable, but flackr is there any way for script to detect whether the scroll container or a marker is focused?

flackr added a commit to flackr/csswg-drafts that referenced this issue Jan 28, 2025
…asses.

This defines the focus related properties and pseudo-class matching
as resolved in w3c#11361.
tabatkins added a commit that referenced this issue Jan 29, 2025
…do-classes for focused navigation pseudos. (#11590)

* Define the expected activeElement and matching focus-related pseudoclasses.

This defines the focus related properties and pseudo-class matching
as resolved in #11361.

* Update css-overflow-5/Overview.bs

---------

Co-authored-by: Tab Atkins Jr. <jackalmage@gmail.com>
@flackr flackr closed this as completed Feb 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants