Replies: 1 comment
-
Thanks for starting this discussion! I'd much rather avoid breaking changes whenever possible. That's definitely an every-present consideration. Focus-trap's initial focus behavior has been as it is for a very long time, and it isn't just for dialogs, although that's probably a common use. So at first glance, this sounds like another option to opt-in to new behavior which could eventually be flipped around to be opt-out with a future major version (i.e. permission to break stuff if it makes things generally better). There's definitely something to be said about not interfering with an element that has Dialog element-specific could support could look like simply checking if:
Instead of throwing the "your focus trap must have at least one tabbable element in it" error at (4), set focus to the container node -- or rather just let it have focus. Thing is, this behavior of falling back focus to the dialog itself sounds like a browser behavior which is probably fairly new, unless Another thing to check is whether setting the Yet another consideration is if the Also note that Tabbable defaults its So if the container isn't included, and the container is the Maybe Focus-trap's default behavior should change to include the container IIF the container is a That's probably still a breaking change, but maybe just a minor. Assuming we'd consider it breaking, then at least there would be a relatively easy way to opt-out and hopefully it would actually end-up being something that seems intuitive to most consumers so wouldn't cause too much grief. Otherwise, we avoid the breaking change and you can opt-in by setting |
Beta Was this translation helpful? Give feedback.
-
Currently the first tabbable node (using the
tabbable
package) is focused upon activating the trap unless specified otherwise via theinitialFocus
option:focus-trap/index.js
Lines 792 to 796 in 7b28c40
focus-trap/index.js
Lines 269 to 289 in 7b28c40
This isn't how native dialogs worked up until recently (in most implementations they looked for the first focusable one) nor does this behavior match the updated spec (albeit much closer to it) for dialogs as well as popovers, see whatwg/html@a9f103c
In order for focus-trap to become compatible, it would need to add an additional step before the existing one that checks for
autofocus
being set on either a focusable descendant of the dialog or the dialog itself (the latter is also supported by the updated spec I linked to above).I'm creating this thread to understand whether the maintainers would welcome such a change (maybe being aligned with native HTML widgets that manage their focus is not a priority, or you'd like to avoid any breaking changes) and discuss the appropriate way of implementing it and communicating it to developers that use this library.
Beta Was this translation helpful? Give feedback.
All reactions