Should the delegatesfocus attribute be extended to other HTML elements?

[melanierichards]

The popup proposal specifies a delegatesfocus attribute, which tells the user agent to move focus to the popup's first focusable descendent when the popup is shown. delegatesfocus may be a candidate for broader applicability. We should discuss how/whether the attribute should be extended to other HTML elements.

[bkardell]

Maybe? What other elements might it be extended to? All as a global? Are there some other compelling use cases you could share that don't involve shadow dom (I feel like you could implement the non-covered bits this yourself if you have your own shadow dom for the most part, but maybe I've underthought it)?

[css-meeting-bot]

The Open UI Community Group just discussed [Popup] Should the delegatesfocus attribute be extended to other HTML elements?.

The full IRC log of that discussion

<gregwhitworth> Topic: [Popup] Should the delegatesfocus attribute be extended to other HTML elements?
<una> https://github.com//issues/367
<una> Github: https://github.com//issues/367
<gregwhitworth> melanierichards: this one is a bit more open endedd
<gregwhitworth> melanierichards: as we proposing the <popup> element there are other things that come with it
<gregwhitworth> melanierichards: we want to see how those sub-proposals can be more broadly useful as there are usecases for them
<gregwhitworth> melanierichards: the question here is should the delegatesfocus attribute extend to other HTML elements
<gregwhitworth> melanierichards: as we just said in the last section it'll send focus to the first focusable element rather than the <popup> element itself
<gregwhitworth> melanierichards: one example is <dialog> element
<gregwhitworth> melanierichards: <dialog> actually follows the delegatesfocus model but there are discussions about that possibly changing
<gregwhitworth> melanierichards: should this be allowed in areas that aren't event driven such as <popup> maybe where autofocus is used
<gregwhitworth> melanierichards: maybe you have some focusable div, does that send delegatesfocus to the first element to the first focusable element on load or via script focus or end user
<gregwhitworth> melanierichards: effectively how do we handle it with non-event driven UI
<gregwhitworth> melanierichards: I'll stop there, but I'd like usecases beyond the <popup> element
<davatron5000> q+
<gregwhitworth> q?
<flackr> q+
<gregwhitworth> ack davatron5000
<gregwhitworth> davatron5000: I think it would work best in a disclosure patter. Any time a new layer is added it seems that there needs to be a delegates focus. That would be the situation
<gregwhitworth> davatron5000: my immediate thought is dialog
<gregwhitworth> davatron5000: I guess just aligning the definitions
<gregwhitworth> davatron5000: disclosure patterns or inline content don't need this
<gregwhitworth> q?
<gregwhitworth> ack davatron
<gregwhitworth> melanierichards: if there is a visibility change then that's when delegatefocus takes effect?
<gregwhitworth> davatron5000: yeah, or maybe inert change too?
<gregwhitworth> davatron5000: like a toast or inline alert badge. If that is something that people want to move focus to that because it'll need that because it's on another layer
<gregwhitworth> melanierichards: do you think that in those cases focus would immediately be moved to the descendant of the new thing or they'll need to move focus to that new thing themselves?
<gregwhitworth> davatron5000: it's probably per situation
<gregwhitworth> davatron5000: maybe it does need it for a11y assert?
<gregwhitworth> davatron5000: or you're on your bank site it says you're going to log out then it will get delegated to
<gregwhitworth> flackr: the popup steals the focus, and because it delegates it would send it to it's children
<gregwhitworth> melanierichards: I think the way you've described the <popup> behavior is correct
<gregwhitworth> melanierichards: is it reasonable for it to always behave the same way? Or can an author reason about maybe a different behavior or mechanism that we need to provide
<gregwhitworth> flackr: can you clarify what you mean by "steals focus"?
<gregwhitworth> melanierichards: wherever focus was
<gregwhitworth> melanierichards: the focus remains whereever it was invoked from but the author can set autofocus or delegatesfocus to steal the focus
<gregwhitworth> melanierichards: the toast scenario is interesting because in most cases you don't want to steal focus
<gregwhitworth> melanierichards: maybe there are scenarios where you don't want to steal that focus.
<gregwhitworth> flackr: or maybe we define <popup> to make it so that it doesn't focus by default
<gregwhitworth> melanierichards: yeah, we either do something special for event driven UI or we introduce some capability to the author
<gregwhitworth> flackr: the other question is if you would ever need this....
<gregwhitworth> flackr: nevermind yes you would
<gregwhitworth> flackr: I think not automatically stealing focus would be a valid usecase
<gregwhitworth> melanierichards: I guess follow up ?
<gregwhitworth> melanierichards: have you seen usecases with the <popup> element
<gregwhitworth> melanierichards: we don't have to think of this on the fly the issue is open
<gregwhitworth> flackr: maybe autofocus decides if it steels the focus
<gregwhitworth> flackr: yeah maybe it's not conflict resolution
<gregwhitworth> melanierichards: yeah it's combinitorial
<gregwhitworth> flackr: yeah autofocus says to steal focus and then delegates focus will say when I steal it I'm going to defer to my children
<gregwhitworth> q?
<gregwhitworth> melanierichards: in order to resolve to make the comfinitorial change we'll need usecases
<gregwhitworth> ack flackr
<gregwhitworth> flackr: we also need to make sure that it doesn't trap users in a focus element
<gregwhitworth> flackr: maybe that's already covered?
<gregwhitworth> melanierichards: yeah that's interesting, we need to possibly specify
<gregwhitworth> melanierichards: can you open a new issue on that
<gregwhitworth> ACTION: flackr to create a Github issue about focus trapping with delegatesfocus

[flackr]

@melanierichards Is delegatesfocus is based on the delegatesFocus from Element.attachShadow()? I noticed the MDN documentation for this says focus is only transferred "When a non-focusable part of the shadow DOM is clicked", i.e. suggesting it does not automatically steal focus.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.