[Input Date Picker, Input Time Picker] Individual month, day, year individual inputs

[SkyeSeitz]

Check existing issues

• I have checked for existing issues to avoid duplicates

Description

Similar to MUI's date picker , make calcite-date-picker and calcite-time-picker's month, day, year entries individual inputs, where arrow keys can be used to adjust value. This would also help avoid the current issue with being able to enter invalid characters.

Acceptance Criteria

• calcite-date-picker and calcite-time-picker include individual inputs for month, day, year.
• upArrow & downArrow can be used to increment the values
• rightArrow & leftArrow can be used to move between month, day, year inputs
• direct entry still possible, but consider not accepting invalid characters

Relevant Info

Related to refactors and enhancements in epic #6714

Which Component

Input Date Picker & Input Time Picker

Example Use Case

No response

Priority impact

p4 - not time sensitive

Calcite package

• @esri/calcite-components
• @esri/calcite-components-angular
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/eslint-plugin-calcite-components

Esri team

Calcite (design)

[geospatialem]

Once this effort is picked up for development work, a short check-in can be scheduled with Skye to confirm the design efforts for both components.

[eriklharper]

Related: #5639

[geospatialem]

Blocked by #3455

[github-actions]

Issue #3455 has been closed, this issue is ready for re-evaluation.

cc @geospatialem,@DitwanP

[DitwanP]

I can see this being useful but not sure that this is still needed as I think the same thing can be accomplished now by just tabbing to the individual month, year, and day of the date-picker.

Also the criteria of "upArrow & downArrow can be used to increment the values" would change the current behavior of opening the date-picker and design because the way the MUI example does this is having a calendar icon and the end of the input that can be used by the keyboard to open the picker.

@SkyeSeitz @ashetland Any thoughts on this?

[SkyeSeitz]

Thanks for the thoughts, Ditwan! I still see this as a valid enhancement to pursue since typing out a date can often be a much more efficient workflow for keyboard users (and beyond) than tabbing through the Date Picker UI.

Currently, if tabbing into Input Date Picker, the input is activated for direct entry- masked inputs could just allow for a better direct entry experience without even having to open the Date Picker via the downArrow.

Unlike MUI, clicking into Input Date Picker does in fact trigger Date Picker to open, but I am not sure that is an issue since input behavior is essentially the same regardless:

[eriklharper]

I can see this being useful but not sure that this is still needed as I think the same thing can be accomplished now by just tabbing to the individual month, year, and day of the date-picker.

A big reason we want to move to individual inputs is to ease localization of the time values, in addition to a more efficient keyboard experience. We can translate time separator values (hourSuffix, minuteSuffix and secondSuffix) and make them static so that the user doesn't have to type them, making it easier to parse the localized number and meridiem values.

Also, I recommend we make the date-picker and time-picker popups only activate when the toggle button is activated. User should be able to focus into the input, type the value they want, and then blur it to move onto the next input without needing to navigate in and out of the popover, which is redundant to the text input anyway. If they want the popover input experience, they can click it to open it and then enter it that way. This is how the native Chromium (and other browsers) implement time and date inputs.