Last modified: 2014-09-24 05:10:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T72973, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70973 - Determine how to set input[type=number] visual width (and maybe visual widths of other inputs)
Determine how to set input[type=number] visual width (and maybe visual widths...
Status: NEW
Product: MediaWiki
Classification: Unclassified
MediaWiki UI (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 70974
Blocks: 70913 70405
  Show dependency treegraph
 
Reported: 2014-09-17 23:29 UTC by Prateek Saxena
Modified: 2014-09-24 05:10 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Prateek Saxena 2014-09-17 23:29:16 UTC
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.
Comment 1 Jon 2014-09-17 23:44:52 UTC
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.
Comment 2 Matthew Flaschen 2014-09-18 06:57:39 UTC
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)?
Comment 3 Matthew Flaschen 2014-09-18 23:04:17 UTC
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;
}
Comment 4 Matthew Flaschen 2014-09-19 04:08:59 UTC
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).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links