DatePicker (brainstorming)

[nikgraf]

Open question:

• [x] Change name? DatePicker to Calendar - no
• [x] Separate config file for i18n? - yes
• [x] focus of days (yes/no) - maybe split component into datepicker & calendar - discussed

Todos:

• [x] Nik: styling
• [x] Styling API
• [x] change aria tags
• [x] sanitizing and passing user props like other components - props added for wrapper and day
• [x] Review behavior of ReadOnly date picker
• [x] Nik, Jyoti - review whole code/ logic to improve/ simplify it
• [x] Default belle animated focus styles for wrapper, Bootstrap and belle-with-default-focus styling for datepicker in docs
• [x] Update docs/configuration page after styling api is finalized

  Suggestions

• [x] Treat Days & Prev/Next navigation likes buttons with custom focus behaviour (maybe build a custom click/touchable area/button).
• [x] make other month days clickable as well (switch to that month after the click)
• [x] update focus based on hover (when I hover a box it should be focused)
• [x] Focus for days does not maps to the DOM focus event, it is a state that is maintained at react component level. The trouble can come if user whats to attach a callback to focus, blur or keyDown of days, right now we donot handle these events at day level but at wrapper level and we take action for days also depending on what is value of currentFocusedDay. Possible fixes:
• Leave it as open issue for now and we will think of a solution only if someone really needs.
• We can add 3 props onDayFocus(), onDayBlur() and onDayKeyDown() and call them passing them the wrapper event object and currentFocusedDay value, whenever the event occurs for wrapper and there is some day focused.

The reason for keep the focus state independent from DOM focus was WAI-ARIA specification that current date should be focused as date picker of focused. And focus behavior while tabbling which was not achievable with DOM focus.

• [x] refactor focusedDateKey behaviour
• [x] fix weekend, disabled, readOnly style style
• [x] maybe min date / max date? - is this really needed (Jyoti)
• [x] try an date range example
• [x] investigate possible timezone issues - I did thought about it initially but I think time-zone will have no impact on date-picker, only locale will have and that too in respect of look and feel of date-picker.(Jyoti)
• [x] check if touch cancel is nowhere missing anymore
• [x] export prev/next arrows to style
• [x] make sure each element has a props entry to be overwritten (depcrecate the classname overwrites) - hey Nik I really wonder if anyone will ever need that (Jyoti)
• [x] improve test suite - In Progress (Jyoti)
• [ ] bootstrap styles for the datepicker
• [x] update docs
• [ ] code comments
• [x] ask for feedback: Jyoti, Andrey, Andraz, Valentin
• [x] ask for feedback: people who wrote the aria recommendations - Very good idea (Jyoti)
• [x] other month day select works even if its configured to be hidden in date-picker (Jyoti)
• [x] Why are we using this, onClick of <ActionArea> rather than touchStart or mouseDown ?

  Bugs

• [x] Focus should stay on the Datepicker when clicking a Day
• [x] Focus should become active when you click anywhere in the datepicker
• [x] All standard events we overwrite should have callbacks e.g. onFocus
• [x] Somethings odd with collapsed stylings (1px less on the right side)
• [x] Jumping with the keys to a date from the next year doesn't work
• [x] Jumping with the keys to a date from the previous year doesn't work
• [x] focused style not distinguishable from weekend style
• [x] When today is selected its color should remain blue.
• [x] When I select a day its kind of pressed like button, but it does not comes up again - thats kind of not expected. I think there is no reason for selected day to remain pressed.
• [x] How about more distinguishable styling for selected/ hovered days.
• [x] Other month days are not distinguishable in disabled date-picker.
• [x] May be it will be nice to have a little border in modified hoverFocus style so that users will know intuitively that day is focused also.
• [ ] Left and Right date navigations should be reversed for locales with RTL true.

[LucaColonnello]

Have someone a sketch or psd or jpeg for the ui?

[jpuri]

References: https://github.com/JedWatson/react-date-input https://github.com/Rudeg/react-input-calendar

[dmitry]

Most powerful react date picker: https://github.com/gpbl/react-day-picker

I've checked around 5 different date pickers. This one is powerful, because it gives ability to a user modify dates depending on requirements, plus it has most powerful support of i18n (possible to push own localization keys into a component, instead of moment.js).

[jpuri]

Yep @dmitry , this one is real good. Thanks.

[nikgraf]

Today @jpuri & I did some brainstorming. We thought about providing two components:

<DatePicker>

The datepicker component is just the component to select a date. In mobile situations people might want to use it directly. It's also great to just show a calendar in case no event listeners are bound. This also allows people to cover more complex date/range selections with custom components.

<DateInput>

The dateinput looks like an input field. By default we put a calendar icon next it. But clicking the calendar icon a datepicker will open. The text is still editable, but is going to be validated like in this example: http://rudeg.github.io/react-input-calendar/

[jpuri]

Collecting couple of design / api thoughts about the component:

1. The component will have 2 properties month, year. They will be by default current month and current year. The component will by default show that month and year to user to select date from.
2. Current date (today) will be highlighted on the component but not selected.
3. User can give a default date to the component using - defaultValue, value or valueLink props. Once a new date is selected onUpdate will be called and also component will be updated depending on which property -> "defaultValue, value or valueLink" is used.
4. Like rating we should provide some api method for user to be able to unset the date.

[jpuri]

Rating component will support these 3 states:

1. Enabled and can be modified: Component is enabled and value can be changed:
2. Disabled: http://www.w3.org/TR/html401/interact/forms.html#h-17.12.1
3. Read-Only: http://www.w3.org/TR/html401/interact/forms.html#h-17.12.2

ARIA-properties supported:

1. aria-label
2. aria-current
3. aria-selected
4. aria-disabled
5. aria-readonly

Reference for localization data: https://github.com/jquery/jquery-ui/tree/master/ui/i18n

When using date-picker with input box - date input, focus styles of date picker should be totally disabled and CTRL + keys can then be used for kayboard navigation. This might mean much complexity for keyboard handling :(

For days in datePicker it will be better to have a new state (in addition to focus state), so that both mouse and keyboard events can be handled seemlessly. This state may not have any styling associated with it.

Reference: https://jqueryui.com/datepicker/

Highlighting weekend in calendar will be an optional feature. Though many calendar's do no include weekend information as locale data. I think locale data is good place to do that. There will be a property 'styleWeekend' which when true will result in highlighting weekend.

[luisrudge]

please don't forget to add a date range picker :heart:

[luisrudge]

I tried a lot of date pickers. From a library consumer perspective, I ended up using this one: http://zippyui.com/react-date-picker/

The api is very simple and I created a date range picker on top of it pretty easily.

[dmitry]

@luisrudge I've also tried a lot of date pickers, and found https://github.com/gpbl/react-day-picker very simple to read, to modify and implement a features. On the first sight looks like not possible to implement some features like range of dates, blocking dates etc., but after looking into the modifiers feature you can find out that the power of this date picker is huge. Also almost all the date pickers force you to use moment.js, but only this one gives you option to implement your own i18n interface.

[luisrudge]

@dmitry awesome! Thanks! This is date picker is really great. It has range as well!

[nikgraf]

@jpuri interesting read regarding focus behaviour: http://ux.stackexchange.com/questions/52849/datepicker-behavior

[nikgraf]

@jpuri I thought about the ctrl+up as well, but the issue here is that even on OSX these keyboard short cuts are used for different things by default.

look what I found: http://www.w3.org/TR/wai-aria-practices/#datepicker - I suggest to exactly use the keyboard short cuts as they propose.

This also has some nice hints regarding behaviour: https://www.w3.org/WAI/PF/HTML/wiki/Datepickers

[jpuri]

KeyStrokes to be implemented:

• [x] Tabbing - current date to be set active.
• [ ] Control+Page Up - Moves to the same date in the previous year.
• [ ] Control+Page Down - Moves to the same date in the next year.
• [x] Space - Singleton Mode: acts as a toggle either selecting or deselecting the date.
• [ ] Home - Moves to the first day of the current month.
• [ ] End - Moves to the last day of the current month.
• [ ] Page Up - Moves to the same date in the previous month.
• [ ] Page Down - Moves to the same date in the next month.

Implemented ones:

1. Shift+Tab - reverses the direction of the tab order.
2. Up Arrow and Down Arrow - goes to the same day of the week in the previous or next week respectively.
3. Left Arrow and Right Arrow - advances one day to the next, also in a continuum.
4. Enter - Enter confirms the selected date(s).

[jpuri]

WAI-ARIA support:

• [x] The current month has a label representing the month and year. It is advisable to use a role heading but is not essential. This "label" should have a unique ID.
• [x] The container for the day of week headers and numeric days of the week has a role of grid.
• [x] Each name for the day of the week has a role columnheader and is not navigable via the keyboard.
• [x] Each numeric day of the week has the role gridcell.
• [x] When a day is selected its aria-selected is set to true, otherwise it is set to false or removed.
• [x] Changes in aria states, identified here, as well as focus, are clearly styled to show the user where their point of regard is and what days are selected.

[jpuri]

• [x] Creating spans for arrows.

[nikgraf]

@jpuri I updated the sub-tasks on top (added suggestions & bugs I found)

[jpuri]

Nice @nikgraf , I plan to work on all the bugs you highlighted, lets also catchup some time to discuss the suggestions.

[jpuri]

My feedback: Great component :) But I am doubtful about merged hover and focus states. This can create unexpected behaviors like someone can hover over a date and press enter to select it - something which will never work for simple button.