Last modified: 2014-11-12 10:33:25 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 T72405, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70405 - Special:Preferences: Custom (other) input field for Time offset is too long
Special:Preferences: Custom (other) input field for Time offset is too long
Status: RESOLVED WONTFIX
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: 70973 70404
Blocks: 70913
  Show dependency treegraph
 
Reported: 2014-09-04 16:59 UTC by Jared Zimmerman (WMF)
Modified: 2014-11-12 10:33 UTC (History)
7 users (show)

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


Attachments

Description Jared Zimmerman (WMF) 2014-09-04 16:59:36 UTC
max input is 6 characters, control width should be ~70 pixels to fit content
Comment 1 Jon 2014-09-04 17:37:21 UTC
This is another example of the problem in Bug 70404. Inputs are currently do described as being relative to their container.
Comment 2 Matthew Flaschen 2014-09-06 04:09:08 UTC
Can you clarify the bug?  What page is this on?
Comment 3 Jared Zimmerman (WMF) 2014-09-06 07:00:55 UTC
Preference > appearance > timezone offset(?) > other (?)

Sorry I'm mobile—
Comment 4 Matthew Flaschen 2014-09-09 05:32:52 UTC
Thanks.

Special:Preferences => Appearance tab => Time offset => Other (specify offset)

Then, the text field below is too long.
Comment 5 Jon 2014-09-16 23:52:16 UTC

*** This bug has been marked as a duplicate of bug 70404 ***
Comment 6 Matthew Flaschen 2014-09-18 05:38:25 UTC
Not fixed, while that is, so changing to a dependency.

Note, this is apparently not a number (if you choose "Fill in from browser", it shows e.g. "-04:00", obviously varying based on your actual timezone).
Comment 7 Prateek Saxena 2014-09-18 20:49:07 UTC
This should get fixed once bug 70974 and bug 70973 are resolved. Isn't that right Jared?
Comment 8 Matthew Flaschen 2014-09-18 23:10:54 UTC
No, this is not a number.  Anyway, I have concerns about the idea of using maxlength for input type="number" (see bug 70973).
Comment 9 Jared Zimmerman (WMF) 2014-09-19 00:42:34 UTC
What are your concerns Matt? If the form only accepts certain inputs why should we allow users to create input that will result in an error 100% of the time
?
Comment 10 Matthew Flaschen 2014-09-19 02:05:33 UTC
(In reply to Jared Zimmerman (WMF) from comment #9)
> What are your concerns Matt? If the form only accepts certain inputs why
> should we allow users to create input that will result in an error 100% of
> the time

Prateek asked whether bug 70973 ("Set input[type=number] width according to the maxlength attribute") would address this.

As I said, this input can not be marked as a number, since it is not pure numeric input.  "-04:00" is considered a string.  Since this can't use input[type=number], the current bug 70973 proposal would not solve it.

My more general thoughts about bug 70973 are given there; in short, maxlength does not affect input[type=number], so using it for CSS may be confusing and semantically incorrect.
Comment 11 Jared Zimmerman (WMF) 2014-09-19 03:50:17 UTC
Does that mean that phone number and credit card fields that limit both characters and string length are using JavaScript for client side form validation rather than basic properties on the fields themselves?
Comment 12 Gerrit Notification Bot 2014-09-19 04:40:33 UTC
Change 161421 had a related patch set uploaded by Mattflaschen:
Add maxlength of 6 for time correction in preferences

https://gerrit.wikimedia.org/r/161421
Comment 13 Matthew Flaschen 2014-09-19 04:47:21 UTC
We're already using input[type=text] here, so we can add the maxlength here, as long as we know what the right value is.  I looked into it, and it seems 6 is safe, as you said.  That's what the above patch does.

For now at least, this will only affect the number of characters you can type in, not the visual size.

It should be either an hour value (e.g. -12 to +14) or a 5 or 6-digit offset string (like -15:00), both of which fit in 6.

---

(In reply to Jared Zimmerman (WMF) from comment #11)
> Does that mean that phone number and credit card fields that limit both
> characters and string length are using JavaScript for client side form
> validation rather than basic properties on the fields themselves?

A lot of these are probably input[type=text], since the custom ones (number, tel, email, and pattern attribute etc.) are relatively new.  The text ones generally probably use JS validation (or only server-side), and maxlength in many cases.

There is now input[type=tel] (https://html.spec.whatwg.org/multipage/forms.html#telephone-state-%28type=tel%29) for telephone.

For credit card, it recommends the "numeric" input mode (https://html.spec.whatwg.org/multipage/forms.html#attr-fe-inputmode), but it could also be done with pattern or custom JS.

There is also now the "pattern" attribute (https://html.spec.whatwg.org/multipage/forms.html#attr-input-pattern), which checks against a regex.

With these new attributes, we need to initially be careful (so basically, cross-browser testing) of browsers that may "support" them in that they block form submission, but don't tell the user what's going on (i.e. why it's invalid).  

However, I think this is mainly an issue for the validation attributes like required/min/max, not the type.

The spec also recommends (https://html.spec.whatwg.org/multipage/forms.html#number-state-%28type=number%29), "The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows)."
Comment 14 Jared Zimmerman (WMF) 2014-09-19 04:50:25 UTC
Thanks Matt, very illuminating.
Comment 15 Jon 2014-09-22 17:39:23 UTC
How do we want to deal with the size visually?
Comment 16 Gerrit Notification Bot 2014-09-22 17:52:32 UTC
Change 161421 merged by jenkins-bot:
Add maxlength of 6 for time correction in preferences

https://gerrit.wikimedia.org/r/161421
Comment 17 Jon 2014-09-22 22:57:13 UTC
It seems bug 70973 covers visually styling so marking as closed to avoid confusion.
Comment 18 Matthew Flaschen 2014-09-24 05:10:21 UTC
It's not fixed.  Let's use a dependency so we don't forget about it.
Comment 19 Gerrit Notification Bot 2014-10-20 18:02:30 UTC
Change 167628 had a related patch set uploaded by Mattflaschen:
Revert "Add maxlength of 6 for time correction in preferences"

https://gerrit.wikimedia.org/r/167628
Comment 20 Gerrit Notification Bot 2014-10-20 18:21:54 UTC
Change 167628 merged by jenkins-bot:
Revert "Add maxlength of 6 for time correction in preferences"

https://gerrit.wikimedia.org/r/167628
Comment 21 Prateek Saxena 2014-11-12 01:21:41 UTC
Bartosz points out that "System|60" is also a valid value, and it's 9 letters long in I47ec2c07929069cb5243c306a1c502751e57a31b.

Should we mark this as Wont Fix then?
Comment 22 Bartosz Dziewoński 2014-11-12 10:33:25 UTC
Let's do it.

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


Navigation
Links