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

Introduce "open" DOM property for <select> element #2072

Open
DataTables opened this issue Nov 21, 2016 · 2 comments
Open

Introduce "open" DOM property for <select> element #2072

DataTables opened this issue Nov 21, 2016 · 2 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms

Comments

@DataTables
Copy link

DataTables commented Nov 21, 2016

The issue

Related to #263 I've recently been looking at when I can submit a Javascript controlled form when the return key is pressed. For an <input> element it is trivial - just submit the form. For a <select> element this doesn't appear to be possible, nor is implementation behaviour consistent across browsers.

When the options are shown (in a <select> of size=1) I would like to know if the options list is shown or not. The idea being that if the options are shown then the return key is being used to select an option. If the options list is not shown, the return key is being used to submit the form as with an input element.

Currently only Chrome will give the behaviour above, due to the fact that it appears not to trigger keydown when the options list is shown. All other browser's will see the return key, but with no way to distinguish if it came from the list being open or not.

There are a number of workaround suggestions for this (1, 2, 3) but generally only consider mouse interaction and not keyboard accessibility.

Proposal

Introduce a new open (displayed, or some similar term) property to the <select> element's DOM interface. This would be a readonly boolean value, where it is true while the options list is shown, and false otherwise.

This would make it trivial to detect the return key, and decide if the form should be submitted, or it was simply an option selection, in which case it wouldn't submit.

Unresolved

  • When size > 1 for a <select> this option is probably useless. What should it do at this point - always be true since the list of options is shown?
@domenic domenic added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms labels Nov 21, 2016
@domenic
Copy link
Member

domenic commented Nov 22, 2016

Hmm. I appreciate the desire to solve the problem here, but I am not sure a new property is the correct way to do it. Maybe the best fix would be to tackle #263 more head-on? For example, I think if all browsers did not fire keypress when using the Return key to select an option, that would solve your issue, right?

Alternately, forms already automatically submit when the return key is pressed if there is a submit buton in them. Would this suffice for your use case?

@DataTables
Copy link
Author

Hi - thanks for your reply.

Yes, addressing #263 directly would probably address the issue. It wasn't clear to me that #263 should cover that, but if the return key didn't trigger any browser events while showing the options list, that would certainly solve the issue I've been seeing. Having said that, I'm not sure that is entirely the correct approach since that behaviour exists in all browser's other than Chrome.

Perhaps a couple of other options:

  • Events triggered when the options list is shown / hidden
  • When a key event is triggered to select an element (return when the list is shown), the target element could be the <option> rather than the <select> as it appears to be currently. That way we could use preventDefault if the return occurs on an <option> tag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms
Development

No branches or pull requests

1 participant