Focused day (today) shown monthly

[gbiorczyk]

Hello,

I have a problem with the focused class being added to the current date. When they move from March to April, April 29 becomes active, why? This is not today's date.

Every month, the 29th of the month has focused class, which in my opinion should only be March. The problem also occurs in the demo: https://raw.githack.com/mymth/vanillajs-datepicker/v1.1.4/demo/

Can you help me with this?

[mymth]

The focused class is not today marker. It's a kind of cursor for arrow-key operation. (Note that the todayHighlight option is off by default)

You should be able to easily understand how it works if you repeat pressing randomly chosen arrow key a couple of times immediately after the picker is shown then press the enter key, and repeat this key operation a couple of times.

[gbiorczyk]

@mymth Thank you very much, you are right. That solved the problem completely!

[espen]

I think this is confusing UX-wise. If I click next month why is the current date highlighted with another color? It looks like an indicator for the selected date. Regardless of the UX-issue here I really see no purpose of this, can you explain why this is implemented? Why should the user be informed of the day number of the selected date?

[mymth]

If you haven’t done, I’d like you to try doing these and see what happens: After clicking the next button, press one of the arrow keys (←,→,↑,↓) one or a couple of times and press the enter key Press the other arrow key(s) a couple of times and press the enter key, then repeat the same with different arrow key patterns Repeat the same in other months’ calendars Change the view to month-/year-view and repeat the same

I’m not a UI/UX expert. So it would be appreciated if you go to https://uxsolutions.github.io/bootstrap-datepicker and https://flatpickr.js.org/examples/ and do the same check as the above, then tell me what (not which) is the best UI you think for arrow-key operation. I’ll be happy if I can hear other people’s opinions.

[espen]

I think my confusion stems from the inline widget not responding to key presses. Is that a bug or intentional? If the latter perhaps disable this CSS function for inline? I use inline so that is why I could not understand why it is the way it is. For input it makes more sense when navigating with keyboard.

I like both of the approaches in the links you posted. Preferably the bootstrap-datepicker, but both seem to 1) do not show any indication until key press 2) reset indication when navigating (so April 7th is not focused when doing next month on March 7th).

Thanks for investigating and other examples.

[mymth]

Inline picker's not responding to key press is one of the things inherited from bootstrap-datepicker. So it's intentional. (See the last bullet of https://mymth.github.io/vanillajs-datepicker/#/overview?id=inline-picker) And, like you said and as bootstrap-datepicker does, I should have disabled the .focused class on inline picker.

Without thinking carefully, I thought that that limitation is because <div> element doesn't fire keyboard events. But I've just found that it actually does when it has the tabindex attribute. Maybe I should remove the limitation.

In regard to your thoughts, I'm sorry but to be honest, it looks to me like only telling about what is not distracting for mouse-operation users and not really thoughtful about the usability of keyboard operation. Those 2 date pickers are the ones I used before I started this project. Flatpickr was the No 1 candidate when I was looking for a plain JS replacement of bootstrap-datepicker. But I eventually decided to create my own one because I wanted one with a good keyboard operation support but couldn't find any. And using the opportunity, I tried to improve the questionable behaviors I see in them. 
For example, on Flatpickr,

• You have to press an arrow key first to turn on the keyboard operation, then you can start navigating the focused date from the second key press.
• You have to do the above every time when you change the month/year using mouse.
• The arrow keys to turn on the keyboard operation changes depending on whether it's before moving to other month/year. If it is, the keys are arrow-up and down, and if not, the keys are arrow-right and left.
• When the keyboard operation starts with arrow-right, the initial focused date is the day on the right-bottom corner, and if it starts with arrow-left, the initial focused date is the day on the left-top corner. In many cases, those days are not a day of the month displayed in the calendar. But when you move to other month, it's because you are going to select a day of that month. How come you need to start with a previous/next month's date?

And on bootstrap-datepicker,

• Let's assume today is March 14th. If you move to next month then immediately press the enter key, April 14th becomes the selected date even though no focused date is shown.
• If you move the focused date to March 17th first, then move to next month then immediately press the enter key, March 17th becomes the selected date and the calendar goes back to March.
• In both cases, you see exactly the same thing right before pressing the enter key: April's calendar with no focused date. Why the difference in the result?
• The same happens if you press an arrow key instead of the enter key. If you press arrow-up instead of enter in the first case, April 7th becomes the focused date. And in the second case, March 10th becomes the focused date and the calendar goes back to March.
• In the first case, the UI doesn't represent the program's state correctly. If the picker doesn't show focused date in calendar, shouldn't it show the focus first then allow the user to select the focused date, like Flatpickr? Or, if the picker does have the focus on a date, shouldn't it be displayed on the calendar?
• In the second case, the UI is correct. But you moved to April to select a day in the next month. How come you need to be taken back to March?

So the current behavior of this library is my attempt to improve the above and thus, adopting your points seems like backward evolution to me.