https://bugzilla.wikimedia.org/show_bug.cgi?id=70405
--- Comment #13 from Matthew Flaschen <[email protected]> --- 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)." -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
