This is another example of the problem in Bug 70404. Inputs are currently do described as being relative to their container.

Can you clarify the bug? What page is this on?

Preference > appearance > timezone offset(?) > other (?)

Sorry I'm mobile—

Thanks.

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

Then, the text field below is too long.

• This bug has been marked as a duplicate of bug 70404 ***

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

This should get fixed once bug 70974 and bug 70973 are resolved. Isn't that right Jared?

No, this is not a number. Anyway, I have concerns about the idea of using maxlength for input type="number" (see bug 70973).

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
?

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

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?

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

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

Thanks Matt, very illuminating.

How do we want to deal with the size visually?

Change 161421 merged by jenkins-bot:
Add maxlength of 6 for time correction in preferences

https://gerrit.wikimedia.org/r/161421

It seems bug 70973 covers visually styling so marking as closed to avoid confusion.

It's not fixed. Let's use a dependency so we don't forget about it.

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

Change 167628 merged by jenkins-bot:
Revert "Add maxlength of 6 for time correction in preferences"

https://gerrit.wikimedia.org/r/167628

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?

Let's do it.