[forms] Number input intrinsic size.

[emilio]

What is the issue with the HTML Standard?

We just found out that Blink and WebKit have some magic default sizing behavior for <input type=number>, derived from the min / max attributes:

<input type="number"> | <input type="text"> <br>
<input type="number" size="4"> | <input type="text" size="4"> <br>
<input type="number" min="0" max="100"> | <input type="text"> <br>

In particular:

• size seems to be ignored.
• if you have both min and max, and the step is not any, then you infer a size based on "sign + max digits + dot (if needed) + decimals (if needed)". The logic seems to come from WebKit so it matches in both.

So, I think inferring size from min / max if possible makes sense. However, I think disregarding size otherwise feels wrong?

My proposal would be to:

1. Standardize the WebKit/Blink min/max behavior. It's not pretty but it makes sense I guess.

2. Standardize the Firefox size behavior (that is, still honor size if present, probably with higher priority than min/max, but I guess either order works).

Would something like that feel palatable? The first is probably a requirement for compat, but <input type=number size="N"> getting completely ignored seems unfortunate otherwise.

[emilio]

cc @mfreed7 @josepharhar @annevk

[mfreed7]

Icky.

So the spec and MDN both say size doesn't apply to number inputs. I'm not sure if there was logic behind that decision? It does seem reasonable to me to expand it to include number inputs, but yeah I'd be concerned about compat.

[emilio]

@mfreed7 the compat issue you linked is tangential to whether number inputs respect the size attribute. I've never seen a compat issue on Firefox for respecting size.

[mfreed7]

@mfreed7 the compat issue you linked is tangential to whether number inputs respect the size attribute. I've never seen a compat issue on Firefox for respecting size.

Right, of course. I just meant that changing the layout size of <input type=number> based on attributes can be a source of breakage. The Firefox issue was about min/max, but I don't see a reason, a-priori, to assume that changes to the width based on size won't break something too. I don't think we have any use counter data measuring <input type=number size> usage. Do you have any data on this?

[emilio]

I do not. Happy to add it and come back here in a couple months if you want (but changing based on size is what I'd expect off-hand since that's what happens on most other text inputs)

[annevk]

cc @pxlcoder @nt1m

[mfreed7]

I do not. Happy to add it and come back here in a couple months if you want (but changing based on size is what I'd expect off-hand since that's what happens on most other text inputs)

Cool, thanks! I agree with the sentiment that it would make sense for size to work on number inputs, if it's web compatible.

[annevk]

Reading this thread again I'm not sure about doing 2 as size would be a presentational attribute here.

[dbaron]

I think size is at the border of presentational versus semantic: as a semantic you could see it as saying "this is the number of characters that the input's value should be able to hold".

[annevk]

That's fair and it seems like we haven't attempted to make it non-conforming generally, but then the proposal would have to include:

1. Make size conforming to use for <input type=number>.

[emilio]

Sure, consider that part of the proposal :)

[emilio]

So the spec seems to account for something like this here. I still think that the size attribute would make sense for number inputs, and if people are on board it'd be a matter of editing that section. Happy to write such a patch.

[annevk]

Should it end up with a different width because of the inline number manipulation buttons? I noticed that in Firefox data:text/html,<input type=number value=3 size=1> currently ends up with an obscured value.

cc @whatwg/forms

[emilio]

Yes, that is fixed already fwiw: https://bugzilla.mozilla.org/show_bug.cgi?id=1905743

[annevk]

That's what you get for testing with a July 2 Nightly.

I think it's reasonable to add this, but I don't think editing just that section is enough. You also need to make size a conforming attribute for this control.