Open emilio opened 1 month ago
cc @mfreed7 @josepharhar @annevk
@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 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?
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)
cc @pxlcoder @nt1m
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.
Reading this thread again I'm not sure about doing 2 as size
would be a presentational attribute here.
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".
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:
size
conforming to use for <input type=number>
.Sure, consider that part of the proposal :)
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.
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
Yes, that is fixed already fwiw: https://bugzilla.mozilla.org/show_bug.cgi?id=1905743
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.
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:In particular:
size
seems to be ignored.min
andmax
, and the step is notany
, 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 disregardingsize
otherwise feels wrong?My proposal would be to:
Standardize the WebKit/Blink
min
/max
behavior. It's not pretty but it makes sense I guess.Standardize the Firefox
size
behavior (that is, still honorsize
if present, probably with higher priority thanmin
/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.