Calcite input numeric does not limit typed in numbers to min/max

[patrickarlt]

Actual Behavior

When using <calcite-input> as a number the user is still allowed to type in numbers outside the min/max range. While it was mentioned that this mirrors browser behavior #622 (comment).

However <calcite-input> as a number also does not allow you to type in non-numeric number which differs from default browser behavior (which allows you to type in non numeric characters).

Expected Behavior

We have had bugs introduced because we thought min and max would actually restrict users from typeing in numbers outside the min and max it seems reasonable that most people actually expect this to limit what users can type in and make it consistent with other calcite components behavior.

It seems pretty obvious from #622 and #4276 that people expect min and max to limit the value users can type into the input.

when a number outside the min/max is entered either:

1. Set the value to the closest to the mix/max
2. Reset the value to the previous value

Reproduction Sample

https://developers.arcgis.com/calcite-design-system/components/input/

Reproduction Steps

You can reproduce this in https://developers.arcgis.com/calcite-design-system/components/input/

1. Set type to number
2. Set a min and max
3. Type something in outside the min/max range.

Reproduction Version

beta.81

Relevant Info

No response

Regression?

No response

[macandcheese]

However as a number also does not allow you to type in non-numeric number which differs from default browser behavior (which allows you to type in non numeric characters).

This is a browser-specific behavior. We do match the native input behavior in Chrome - to allow only e. Safari handles this differently (allowing any character).

A small difference I noticed between our implementation and the native one (in Chrome), is that when e is present, our input of type number lets you type a decimal (which is briefly present and then removed), whereas the native doesn't allow the decimal to be added at all when e is present.

I do think we should generally match native behavior - which in this case would mean not resetting the invalid value to the closest min / max bound. Ostensibly the consumer could perform this validation on blur. Open to thoughts here, but I could see it being equally as confusing to provide a non-standard behavior there.

I know there is a planned update to a standalone calcite-input-number component - @jcfranco do you think this can be addressed at that time?

[geospatialem]

We plan to address validation across components in the near future and have added this issue to an Epic (#4598) for tracking purposes.

[geospatialem]

For dev implementation, refer to the Figma documentation:

[github-actions]

cc @geospatialem, @brittneytewks

[geospatialem]

Verified in 2.8.0-next.19 with https://codepen.io/geospatialem/pen/jORoLWq when the component's min and max are set in https://codepen.io/geospatialem/pen/jORoLWq.

For instance:

<calcite-label>Quick! Enter a number between 5 and 10
    <calcite-input-number name="what" required max="10" min="5"></calcite-input-number>
</calcite-label>