-
Notifications
You must be signed in to change notification settings - Fork 132
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
No focus loss #4
Comments
Thanks for the info! I'll take a look at the focus issue tomorrow. Regarding the issue where you need to press enter to have the option selected, that's intended. If you take a look at http://vst.mn/tmp/select.html in Chrome. Tab to the select and then use your arrown keys, when you click outside of the select it will go back to the default option. Firefox behaves the other way around, when you use your arrow keys and then click outside of the select it will keep the option selected with the arrow keys selected. I choose to "mimic" Chrome, don't know if that decision was good or not. Any way, I'll get back to you regarding the focus bug. |
Sorry, now I read your comment again. I'll take a look at the tab vs. click also! |
I tested only in Chrome, and in your select demo (http://vst.mn/tmp/select.html) Chrome acts as expected, changing value using arrows will immediately select the value and if you click outside value will not resetted to previous/default. Checked in a last Firefox, it behaves the same way as Chrome, i bet last Opera will do the same. Also checked IE 10, same behavior :) |
Also 'no focus loss' affects only style of elements, space/arrows/keys works as expected. |
Below are two screen captures, one using Chrome and one using Firefox. I do the same thing in both examples:
In Chrome, Safari and Opera I get the result seen in this[1] video, when clicking outside the select it falls back to the value initially selected. In Firefox and IE10 and IE11 I get the result seen in this[2] video, when clicking outside the select the option selected using the arrow keys stays selected. Is this the same behavior you see? [1] - http://f.cl.ly/items/373z03131x0x1j1B0809/select_chrome.mp4 |
Changed the markup produced by the SoD to use span’s instead of div’s and also fixed an issue when focus is changed and no selection has been made.
Closing this for now. If you're not happy with the current behavior just let me know and we'll figure something out. |
Now i got your point, you open list using a click on it, but i meant situation, when select field is in focus (using label or 'tab' from previous field), but is not open, just like in my GIF. And, suddenly, behavior i am talking about doesn't changed. So the whole difference is that in your case select options list is open, in my case it is closed. When select options list is closed all browsers behave the same way:
|
I meant that navigation through the options using keyboard should differ for case when options are shown and case when they are not shown. |
Thanks for the detailed explanation! I just committed some changes. Download any of the .js files here https://github.com/vestman/Select-or-Die/tree/master/_src and give it a try... (you might need to download the CSS also since I made changes to it yesterday in regards of issue #5) |
Great, seems fixed to me (both issues), thanks a lot :) |
So when you've got many selects in row and tabbing through them they ain't loses focus.
Also when SoD select catch the focus and you switch value by arrows or holding some keys on keyboard and then you tab to the next field selected value is still selected, but if you just click somewhere value returns to the previous state. In the last case only pressing enter will actually set the selected value.
Here is a gif to illustrate this issue. Red border color is set only for
.sod_select.focus
The text was updated successfully, but these errors were encountered: