Type=Numeric does not prevent typing non-numeric characters (DOC ISSUE?)

[Jason Baker]

Please verify the version of auro-input you have installed

2.17.6

Please describe the bug

1. Set type="numeric" on an auro-input
2. Attempt to type non-numeric characters (E.g. abc)

Not that this may be a doc example issue. Likely "numeric" should just be "number" but we have a working example on the docsite that sets the type to "numeric".

Reproducing the error on the docsite

This issue is reproducible on the Auro docsite

Expected behavior

The HTML5 input type=numeric does not allow non-numeric characters to be entered. We should follow this pattern.

We already prevent typing non-numeric characters into inputs that are typed for dates and credit cards.

What browsers are you seeing the problem on?

No response

Additional context

No response

[Dale Sande]

@jason-capsule42 when you say,

The HTML5 input type=numeric does not allow non-numeric characters to be entered. We should follow this pattern.

I am not sure what you are referencing. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number

I remember this being added with the Cleave.js work around credit card numbers and to be derived from the numericKeyboard object. I see that Cleave.js defined this in their API as well.

### `numericOnly`

A `Boolean` value indicates if it only allows numeric letters (0-9).

Ignored by `creditCard` and `date` shortcuts mode, the value will always be `true`.

`numericOnly` doesn't work on it's own, you have to either specify the shortcuts mode or `blocks` option to enable the formatter.

**Default value**: `false`

I see that the example is clearly broken and accepts alpha characters as well as numeric characters. I also see that the max attribute is not stopping the entry of more than 10 characters or throwing an error message when losing focus.

I do have concerns about redefining how the standard type number is implemented in the client if we are considering using type number as a custom element attribute.

[Jason Baker]

I see that the example is clearly broken and accepts alpha characters as well as numeric characters.

In the HTML5 input element type="number" prevents typing any non numeric character. The auro-input component is using type="numeric" which is not a thing at all in HTML5 input element. So when auro-input tries to apply it to the HTML5 input it has no affect on the behavior of the HTML5 input - thus, not blocking non-numeric characters. Our component should be following the HTML5 spec here.

The credit-card and date examples work because CleaveJS has it's own layer of preventing non-numeric characters being typed into those specific types. This is a heavy handed solution because I think CleaveJS is actually just cleaning up those characters rather than actually preventing them from being typed in the first place.

I also see that the max attribute is not stopping the entry of more than 10 characters or throwing an error message when losing focus.

That is because the validation library was built with the expectation that input was following the HTML5 standard of type="number" rather than making up it's own type. The auro-formvalidation utility has been updated since discovering this issue to validate on both type number as well as numeric to handle this issue.

Too add more context - I am not suggesting we remove the support for inputMode which does use numeric. I am saying that we conflated the valid inputMode="numeric" with type="numeric" which is wrong. We should continue to support inputMode="numeric" as it currently is used. We should just not be documenting examples that show type="numeric".

[Jason Baker]

Moving this back to triage - not sure how I mistakenly moved this one to work in progress before.