Bug: Input Date Picker - user is able to input more than 4 numbers for the year

[ankitagupta820]

Actual Behavior

Expected Behavior

For calcite-input type="date" or "datetime-local" the placeholder format shows mm/dd/yyyy. User should be able to enter 4 character long number for year, instead the user is able to input a 6-character number for year.

Reproduction Steps or Sample

1. Create a calcite-component using calcite-input , with type="date" or "datetime-local".
2. On the app UI, observe the placeholder value i.e mm/dd/yyyy.
3. Year component accepts more than 4 characters.

Relevant Info

Browser: Chrome, Safari, Edge

Version: @esri/calcite-components@<version>

• [ ] CDN
• [ ] NPM package

[benelan]

This issue should be fixed for calcite-input-date-picker rather than calcite-input. The issue is reproducible in the doc sample: https://developers.arcgis.com/calcite-design-system/components/input-date-picker/#sample

[anveshmekala]

Considering the native <input type='date' /> element allow users to type 6 digits for year , do we need to support character length validation . Thoughts ? @macandcheese

[macandcheese]

I generally prefer to match native, but I’m struggling to think of how having more than 4 digits is useful.

The date picker doesn’t use the day/month/field masks like native date, correct? Maybe a good item to discuss next sync?

[anveshmekala]

I generally prefer to match native, but I’m struggling to think of how having more than 4 digits is useful.

The date picker doesn’t use the day/month/field masks like native date, correct? Maybe a good item to discuss next sync?

Setting max attribute for input-date-picker would add mask for the date entered by the user . Any value greater would fallback to the maximum date allowed. It still allows user to enter 6 digits before correcting the invalid values.

[yelenakreyndel]

CC @ashetland

[geospatialem]

Will revisit prioritization after the 1.0 release next month as part of the validation epic, #4598.

We're exploring validation warnings as opposed to input restrictions to provide context to users when encountering validation errors. Which could include error messaging and danger highlighting as well as possibly integrating with the browser's validation API making our custom form components work like native ones on form submission and behavior.