-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[List] Add keyboard navigation #15421
Conversation
@eps1lon Regarding:
I might be missing what the problem is, but it seems to behave the same as in |
https://deploy-preview-15421--material-ui.netlify.com/demos/lists/#checkbox:first example
2nd example
Ideally both demos would have checkboxes that can be toggled via keyboard and arrow navigation would work. |
My changes in #15360 move some logic out of MenuList into Menu such that the keyboard navigation is just about the only thing left in MenuList. This means that someone could fairly easily opt-in to this functionality by simply using MenuList instead of List. I wonder if that may be an easier-to-maintain solution (keeping this encapsulated within MenuList with that being the primary responsibility of MenuList) rather than trying to share this functionality between List and MenuList. The key handling is about to get more complicated since I've now started working on #8191 which will require remembering some information across key events. This means that the Another option would be to just move the functionality from |
It isn't shared any more, that was just a poor abstraction on my part. The keyboard functionality now resides in List only on my local branch, which MenuList picks up by wrapping List.
Oops, should have read the whole way down. Yes, exactly this. I think trying to manage these separate efforts as discrete PRs and merging them later may be more work than combining them at the outset. If you're happy to include this change as part of your PR, then we can close this one. |
I definitely agree that this should be done with the changes in #15360 as the starting point, since there are significant changes to the keyboard focus logic. I'm happy to take care of the changes, but I'm not sure I want to add it into #15360 since there are already a number of different things in it, and I don't want to complicate its review and derail it getting merged by adding more changes to it. I have some further thoughts/questions/concerns around the details of how this should work. I'll take some time to write up my thoughts within the next day or two. |
Continues #15334 (I must have accidentally clicked "Close" when replying to @eps1lon.)
This is still very much a discussion draft / WIP, as the tabIndex code would also need to move, tests fixed up etc. I wish "draft" was the default PR option, since you can convert a draft PR to open, but not the other way around!