open-ui
open-ui copied to clipboard
[Popup] Ensure that delegatesfocus cannot trap focus
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.
+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.
@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 :)
Yep, what @chrisdholt said :)
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/openui/open-ui/issues/379
<hdv> github: https://github.com/openui/open-ui/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)?
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.
Given the recent resolution (https://github.com/openui/open-ui/issues/368#issuecomment-1138881225) 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.
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.
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.