Ensure that delegatesfocus cannot trap focus

[flackr]

If delegatesFocus automatically focuses the first focusable child when the element is focused, then we need to make sure that shift+tab or similarly trying to navigate out of the element is possible. This is likely only an issue if we extend delegatesfocus to other elements #367

E.g.

<button id="A"></button>
<div delegatesfocus>
  <button id="B"></button>
</div>

If the user has B focused, and presses shift+tab, I would expect A to be focused.

[melanierichards]

+1, definitely expecting the same behavior from your example.

Also, I realized I had misinterpreted the comment in our original discussion and was thinking you meant SHIFT + TAB'ing into the popup, or whatever element has delegatesfocus applied. Here is what I would expect (using popup as a proxy for "thing that has delegatesfocus applied"):

Author programmatically sets focus to the popup (in script)

<button id="A"></button>
<popup delegatesfocus>
  <button id="B"></button>
  <button id="C"></button>
</popup>
<button id="D"></button>

B receives focus.

User tabs forward to the popup from "A"

<button id="A"></button>
<popup delegatesfocus>
  <button id="B"></button>
  <button id="C"></button>
</popup>
<button id="D"></button>

B receives focus.

User shift + tabs backward to the popup from "D"

<button id="A"></button>
<popup delegatesfocus>
  <button id="B"></button>
  <button id="C"></button>
</popup>
<button id="D"></button>

C receives focus (normal shift + tab behavior)

User shift + tabs backward from "B"

<button id="A"></button>
<popup delegatesfocus>
  <button id="B"></button>
  <button id="C"></button>
</popup>
<button id="D"></button>

A receives focus.

[chrisdholt]

@melanierichards just to confirm, the above is all expected with the popup visible (open) - correct? The above doesn't account for instances where it's hidden, yes? Just covering bases :)

[melanierichards]

Yep, what @chrisdholt said :)

[css-meeting-bot]

The Open UI Community Group just discussed [Popup] Ensure that delegatesfocus cannot trap focus #379 — See also #367.

The full IRC log of that discussion

<hdv> Topic: [Popup] Ensure that delegatesfocus cannot trap focus #379 — See also #367
<melanierichards> zakim, take up item 1
<Zakim> agendum 1 -- [Last Call for Participation] Anchor Workshop -- taken up [from hdv]
<bkardell_> s/a new element/a new 'superset' element that we introduce to fulfill shortcommings of an old one that we cannot adapt directly
<bkardell_> s/a new element/a new 'superset' element that we introduce to fulfill shortcommings of an old one that we cannot adapt directly (like selectmenu)
<hdv> una: it would be great if people comment on the presentation so that we can take it to CSSWG
<melanierichards> zakim, take up item 3
<Zakim> agendum 3 -- [Popup] Ensure that delegatesfocus cannot trap focus #379 — See also #367 -- taken up [from hdv]
<melanierichards> https://github.com//issues/379
<hdv> github: https://github.com//issues/379
<hdv> flackr: one of the issues we found is that focus could get trapped when you use spatial navigation
<hdv> flackr: so I wanted to make sure we figure out how this would work. If we do it naively, I think we could skip elements that have delegatesfocus
<melanierichards> q?
<bkardell_> spatnav as a specific or just updown arrows?
<hdv> bkardell_: do you mean like browser spatial navigation or do you mean arrow keys?
<hdv> flackr: I mean the @@@ spec
<hdv> flackr: so for popup the intention is to trap focus in the element
<melanierichards> q+
<hdv> flackr: maybe that's just the behavior of popup, not part of delegatesfocus
<hdv> melanierichards: there is also some thought being given to focus trapping primitives, that may help address that
<melanierichards> q?
<hdv> melanierichards: we have one minute left so probably don't want to rush to a conclusion
<flackr> https://www.w3.org/TR/css-nav-1/
<hdv> s/the @@@ spec/https://www.w3.org/TR/css-nav-1/
<hdv> RRSAgent, draft minutes please
<RRSAgent> I have made the request to generate https://www.w3.org/2021/08/05-openui-minutes.html hdv
<melanierichards> zakim, please part
<Zakim> leaving. As of this point the attendees have been melanierichards, bkardell_, dandclark, silverdust, hdv, una, Francis_Storr
<bkardell_> ah flackr - does anyone implement that tho? iirc no - it was a prosal, I was even mildly involved in trying to sort something out there, but I didn't think it went somewhere ultimately. I think there was even a counter proposal from google (david I think)?

[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.

[mfreed7]

Given the recent resolution (#368 (comment)) to wait on delegatesfocus for Popup until later, and possibly pursue a more general delegatesfocus type feature, I'm going to remove the popup label from this issue.

[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.

[mfreed7]

So Popover shipped without delegatesFocus, and based on my experience, I'm not sure it's actually a needed use case (because of autofocus and also the default focus "fixup" behavior of popover). Tentatively, I'm going to close this issue.