You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm opening this issue for the future, after we see product market fit. I don't think that we should care too much about this now.
But after, it seems that we have an opportunity to remove code duplication between Base UI and Floating UI to reduce the bundle size, and avoid fixing bugs twice. The duplications that I could see:
Since 1 and 2 are small utilities, I don't think they're too major to worry about right now
For 3, to support tabbable portals, the FocusGuard solution works robustly across all formats (keyboard, touch, screen readers). The tabbable dependency is indeed used internally in Floating UI, as it handles complex scenarios with shadow roots in spite of the extra bundle size. Floating UI also only lets tabbable elements receive focus, unless there is nothing tabbable to focus, then it focuses the popover itself as a fallback. In general I don't think focusing non-tabbable elements is a good thing because they aren't interactive - the screen reader virtual cursor is what "focuses" those elements.
Summary
I'm opening this issue for the future, after we see product market fit. I don't think that we should care too much about this now.
But after, it seems that we have an opportunity to remove code duplication between Base UI and Floating UI to reduce the bundle size, and avoid fixing bugs twice. The duplications that I could see:
FocusTrap
was explicitly to not depend ontabbable
to avoid its bundle size and rely on the browser instead. [Modal] Better focus management material-ui#15450 divea bit into it. Also, [FocusTrap] Trap to only focus on tabbable elements material-ui#23827 is interesting as show that there are strong different ways to approach this.
The text was updated successfully, but these errors were encountered: