[EuiFieldNumber] Safari marks as invalid floating point numbers when step is not provided

[dej611]

I've noticed this issue while testing few components in Lens, which can be quite misleading for the user I think.

This is an example of a UI affected by this:

the first time I saw it I thought the values were invalid somehow, but after the investigation I found it was the Safari correct about the spec. 😓

While by default the fallback value for step is the integer value 1, hence any floating point should be invalid, most browser do not respect this and let the user input any value. Safari is the only browser which implements the invalid check by the spec on this side.

(source: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#step )

Safari:

Chrome:

Using the any step value seems to align Safari with the rest of the browsers for the validation.

I'd propose to add a any fallback for the step prop on the EuiFieldNumber component to fix this behaviour.

[chandlerprall]

@cchaos what do you think about making any the default step in EuiFieldNumber to align browser behaviours?

Relates to #3864

[cchaos]

Can you think of any cases where consumers who have relied on the expectancy that the default step is 1 would be dramatically affected?

[dej611]

Using the palette configurator in Lens has high probability to show those invalid markers as the first 5 stops are autogenerated. Another possible common place is the new Lens reference line editor where the default value is autogenerated.
In both cases the user opens the editor for the first time and see the inputs marked in red.

[cchaos]

Thanks @dej611 for these Lens-specific use cases. Is it not possibly to change the step="any" directly on your end versus relying on the default knowing that these values may not be integers?

My question was mostly directed towards our engineers about other general use-cases of this component as it's used 180 times in Kibana alone.

[dej611]

Thanks @dej611 for these Lens-specific use cases. Is it not possibly to change the step="any" directly on your end versus relying on the default knowing that these values may not be integers?

We can solve on our side, sure.

[cee-chen]

Closing this as not planned - since it's been a while and most consumers are used to 1 being the default step at this point, and it's also clearly documented as such in our props, our suggestion to any team that needs decimal places would be to manually change their step to "any".

[cee-chen]

After the new invalid browser styling, and after having conferred with designers, we've decided to default step to "any" after all to smooth over the default browser behavior of setting :invalid state on decimal numbers while typing but setting them to :valid on blur. See #6760