61–70 of 177 posts
Similarly, here is your reminder than US Zip Codes aren't numbers, because many of us here in the Northeast have them start with a zero (or even two). So don't store them as integers, because Boston is 02108, not 2108. See https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes
My general rule is if you can't add two values together then they shouldn't be represented as number types.
Earlier quoted context omitted.
> a good interface will accept leading, trailing, or interior spaces Won't pattern="[0-9]*" do the exact opposite of what you're suggesting?
Yes, you're right, this isn't a great solution for credit card inputs either. They should be able handle dashes and other spacing characters and the site should be able to filter/format it automatically either on the front-end before submission or with some server-side processing. And no we don't need four different input boxes to enter a credit card numbers either. Flexibility is key here and since many websites han…
You can attempt to infer intent or meaning based on the context of the input field but often the least-problematic method is to provide instruction/hints with the field, examples of correctness, and real-time validation with specific syntax errors when invalid or unexpected data is provided. I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that.
The 4-box credit card form, while pretty terrible in many ways, at least made explicit the expectations. Often we now hide the expectations and either auto-reformat what was put in the field (which can be surprising to the user or worse can modify their input to mean something other than what they intended) or do hidden filtering, which can have the same problems but doesn't even bother to inform the user of the changes.
Javascript not having proper integers strikes again! Kind of surprised they hadn't run into more issues parsing string-ids-with-numerals into numbers.
EDIT: removed my inaccurate comment, misread article
Without any pattern specified, the code you posted will accept emojis as input, it's not a good choice for a numeric only field. It's also intended for phone numbers...
In summary the main issue is that, according to the spec, ` ` is only for numbers that are going to be parsed into a Javascript number. It has to make sense to increment, decrement or do other numerical operations on it. It's not to be used for strings or identifiers that just so happen to be numbers, e.g. credit card numbers. I'll admit this is slightly surprising to me but it does make a certain amount of sense. Th…
We must allow they to automatically use this keypad without the confusing behavior of the
EDIT: removed my inaccurate comment, misread article
How is the "tel" type a solution? According to the standard ( https://html.spec.whatwg.org/multipage/input.html#telephone-... ), it accepts every character except line feeds and carriage returns. Without any pattern specified, the code you posted will accept emojis as input, it's not a good choice for a numeric only field. It's also intended for phone numbers...