Skip to content
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

Implement form keyboard navigation #3982

Open
Manishearth opened this issue Nov 14, 2014 · 12 comments
Open

Implement form keyboard navigation #3982

Manishearth opened this issue Nov 14, 2014 · 12 comments

Comments

@Manishearth
Copy link
Member

@Manishearth Manishearth commented Nov 14, 2014

(Not sure if there is a spec for this)

It's not as simple as it seems. For example, when tabbing out of a radio button, you need to tab to the next radio button only if no button in that group is selected, else you skip the radio buttons in the same group.

@jdm
Copy link
Member

@jdm jdm commented Nov 14, 2014

https://html.spec.whatwg.org/multipage/#sequential-focus-navigation seems relevant but doesn't discuss input elements, and https://html.spec.whatwg.org/multipage/forms.html#radio-button-state-(type=radio) doesn't mention anything about focus or inertness.

@Manishearth Manishearth added this to the Dogfooding milestone Nov 14, 2014
@brunoabinader
Copy link
Contributor

@brunoabinader brunoabinader commented Nov 22, 2014

I believe @kmcallister has an experimental patch that provides such functionality, am I right?

@jdm
Copy link
Member

@jdm jdm commented Nov 22, 2014

Not that I'm aware.

@kmcallister
Copy link
Contributor

@kmcallister kmcallister commented Nov 22, 2014

Nope, I was just hooking key events directly for my own purposes, nothing to do with forms.

@jdm jdm removed this from the Dogfooding milestone Dec 17, 2014
@jdm
Copy link
Member

@jdm jdm commented Dec 17, 2014

I don't actually think that keyboard-based focus navigation is a blocker for effective dogfooding. Nice to have, for sure.

@jmcomets
Copy link
Contributor

@jmcomets jmcomets commented Nov 12, 2016

Hi everyone!
I'm reviving this thread after looking through #12071. The patch seemed more like a quickfix to me, it seems awkward that TriggerDefaultAction is returned when handling a tab key event for an input element.

IMHO the tab key handing should be implemented globally, as it cycles the "currently focused area". It doesn't seem like anything's in place to do this though.

I'll open a PR that cleans up #12071 in a bit and look into implementing tab navigation.
Any thoughts?

@jdm
Copy link
Member

@jdm jdm commented Nov 12, 2016

Note, @nerith has been working on this and there's an in-progress PR at #13460. Thanks for your interest, however! Perhaps there is something you can contribute to that work.

@jmcomets
Copy link
Contributor

@jmcomets jmcomets commented Nov 12, 2016

From the look of the commits, it looks exactly like what I was hoping for. The PR looks quite finished now, I'll probably contribute elsewhere. Thanks for the update!

@jdm
Copy link
Member

@jdm jdm commented Mar 20, 2017

#15936 is the most recent effort. It's a good start, but there is a bunch more work that needs to go into it before it's ready to merge. The original author is no longer able to work on it.

@spastorino
Copy link

@spastorino spastorino commented Mar 20, 2017

@jdm after returning from my long vacation will start working on it.

@jdm
Copy link
Member

@jdm jdm commented Mar 20, 2017

Note: said vacation ends in May, so this is available for other people to work on before that time.

@CYBAI
Copy link
Collaborator

@CYBAI CYBAI commented Dec 18, 2017

@jdm I'd like to try to take the #15936 one from @nox and try to finish it. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants
You can’t perform that action at this time.