I suspect we will need to use a class approach.
e.g. when generating an input, take a look at the number of maxlength
if maxlength < 5 add mw-ui-input-short
if maxlength > 5 and maxlength < 10 use mw-ui-input-medium

Numbers are arbitary, but I think something like
[maxlength=1],
[maxlength=2],
[maxlength=3],
[maxlength=4] {
width: 40px;
}
would be overkill.

Why is this specific to numbers (seems like same concept applies to text). If we specify an exact width, why do we need minimum and maximum width (seems like they won't apply)?

maxlength may not be a good choice, since maxlength does not work for input type="number", so it's misleading to expose that to the output for input type number. See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#attr-maxlength and https://html.spec.whatwg.org/multipage/forms.html#concept-input-apply .

The class approach (mw-ui-input-medium) seems reasonable. If we want to auto-add that, we could use min and max, since we have that in some places (e.g. preferences) even though it is not currently generated to the output (see bug 71026) for browser compatibility reasons.

However, if that fails (e.g. is too coarse), we might have to specify them (in per-page CSS) directly.

I.E.

.mw-some-field {

width: 200px;

}

Could we just use size (i.e. not strip it)? You said it affected rendering. Do you remember exactly what the issue was?

AFAICT, width: 100% takes precedence (at least in Firefox, did not do cross-browser testing yet).

Thus, it would only affect mw-ui-input-inline (which has "width: auto;" allowing size to work). That's probably what we want anyway (either full-width or specified size).

In T72973#806697, @Prtksxna wrote:

With T72405 declined, I think we should decline this too.

The visual width issue may come up again (it is not really limited to input type=number, per the title), but if so we can re-open if needed.