Page MenuHomePhabricator

Determine how to set input[type=number] visual width (and maybe visual widths of other inputs)
Closed, DeclinedPublic


Input fields that are numbers should set the max length attribute based on the largest number that they allow.

This attribute should then be used to set the width of the input so that the user gets a visual cue of how big a number they can enter. Minimum and maximum widths should also be specified.



Event Timeline

bzimport raised the priority of this task from to Needs Triage.
bzimport set Reference to bz70973.
bzimport added a subscriber: Unknown Object (MLST).

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=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 and .

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.


.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).

Prtksxna updated the task description. (Show Details)Dec 3 2014, 12:03 PM
Prtksxna triaged this task as Normal priority.
Prtksxna set Security to None.
Prtksxna closed this task as Declined.
Prtksxna claimed this task.

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

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.