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.

Sign up for GitHub

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

Jump to bottom

[Feature Request] Add option to keep previous behavior of not keeping the focus on input after auto-hiding #47

Open
benface opened this issue Jan 6, 2021 · 4 comments
Open

[Feature Request] Add option to keep previous behavior of not keeping the focus on input after auto-hiding #47

benface opened this issue Jan 6, 2021 · 4 comments

Comments

@benface
Copy link

benface commented Jan 6, 2021

From the CHANGELOG for version 1.1.0:

I much prefer the previous behavior of not keeping the focus. Could that be made configurable? I suggest a blurOnHide option.
@mymth
Copy link
Owner

mymth commented Jan 17, 2021

Could you elaborate on your issues with the new behavior and the benefits of the old one?

@benface
Copy link
Author

benface commented Jan 17, 2021

@mymth I like that the user is able to modify the date by typing in the field if they need to, but for my use case (selecting a shipping date in the near future), that should be a rare occurence. Keeping the field focused when the picker is no longer visible has two undesirable effects:

  • It makes it look like the user is not done, like they have to do something more with that field, e.g. enter some text after the date. At worst, it makes it look like there was an error with the date they've chosen.
  • It makes it easy to accidentally modify the date the user has chosen, because they might not expect the field to be editable when the picker is not visible. And there is no visual confirmation of the date they've entered, so it's hard to notice.

I would ask you the opposite question: what benefits does the new behavior have over the old one?

Thank you for the excellent library. <3

@mymth
Copy link
Owner

mymth commented Jan 25, 2021

The new behavior is the same as native form controls' (e.g. <select> and <input type="date"> — they stay focused after the popup-menu/picker hides on select) and the same as keyboard operation's.
This was actually my original intention but I had to change it to follow bootstap-datepicker's way after I noticed the problem with re-showing the picker after auto-hide and couldn't find a simple solution.

You probably think these aren't benefits. I can't fully disagree if you say so, to be honest. But to make the date picker behave as close to native elements as possible and consistently regardless of being operated by mouse or keyboard is one of the key concepts of this library and was the main focus of the update.

One small benefit of the new behavior is user can also use the tab key to move to the next field. With the old behavior, the focus moves to <body> after the picker auto-hides. Clicking the field is the only way for user to move to the next field.

The points you mentioned are the reason why the autohide option is disabled by default. Although those concerns are understandable, I'm not sure how serious they are because, since the old behavior required it, users already know they need to click the next field before starting typing. And when they have made an unintentional modification not moving to next field accidentally, they probably take it as bad luck and simply re-type if the field is a normal <input type="text"> or <textarea>. To me, it seems unlikely that they respond differently when the same happens on a date picker field.

Anyway, I'd like to see if this feature request gets thumbs up from other people too. And if I decide to add this feature after having requests from a certain number of people, the option name will be like blurOnAutohideByClick.

@benface
Copy link
Author

benface commented Jan 25, 2021

Thank you for the detailed answer @mymth, you make some great points and you have pretty much convinced me that this change is for the better. I may even keep autohide disabled in my project, I'll try it and see. I'll keep this issue open in case someone else wants to chime in, but feel free to close it if it doesn't get any attention.

@mymth mymth mentioned this issue Oct 4, 2021
Closed
@mymth mymth mentioned this issue Mar 20, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@benface @mymth