The depths of the input element(htmhell.dev)
htmhell.dev
The depths of the input element
https://www.htmhell.dev/adventcalendar/2023/8/
22 comments
Good article.
Please don’t use autocapitalize=words for name input fields. It makes people named de Haan unhappy.
Please don’t use autocapitalize=words for name input fields. It makes people named de Haan unhappy.
Love to see recognition of inputmode. Remember, the one true ZIP code field is
<input type="text" inputmode="numeric">
> Love to see recognition of inputmode. Remember, the one true ZIP code field is
Would that allow me to enter my alphanumeric zip code on a cellphone?
Would that allow me to enter my alphanumeric zip code on a cellphone?
Rather than arguing about what is and isn't a zip code, here's an actual answer: no, at least on Firefox Android (and I assume generally on Android devices), if you have "inputmode=numeric", then the only keyboard available to the user is the phonepad-style number keyboard, and they cannot switch to another keyboard.
This honestly surprised me, my expectation was that it would select a keyboard by default, but you'd still be able to switch to other keyboards manually. So I guess if your zip/postcode/PLZ/etc field needs to accept international values, don't use inputmode=numeric (or similar) on it.
This honestly surprised me, my expectation was that it would select a keyboard by default, but you'd still be able to switch to other keyboards manually. So I guess if your zip/postcode/PLZ/etc field needs to accept international values, don't use inputmode=numeric (or similar) on it.
You may have an alphanumeric postal code but as far as I'm aware there are no alphanumeric ZIP codes.
Falsehoods programmers believe about addresses:
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...
For a document that purports to provide clarity they're sure playing fast and loose with terminology. The first one on the list should be "all postal codes are ZIP codes" because that's false but but evidently programmers believe it.
United Kingdom and Canada, for example, have alphanumeric ZIP codes.
https://en.wikipedia.org/wiki/Postal_code#Alphanumeric_posta...
https://en.wikipedia.org/wiki/Postal_code#Alphanumeric_posta...
I think the point is that those are "postal codes", not "ZIP codes."
Mine's an 'eircode', but there's no eircode field on Amazon deliveries, and we're told to use it as a zip code. Naming aside, companies that don't let me use "D02 R9D3" [sic] as a 'zip code', and mandate zip codes and/or lack a freeform field to put it in, can't deliver to me.
I'm of the mind that you can't just casually cast naming or precision aside when talking about data collection.
If I'm askimg for a ZIP code I probably already know I can't deliver to you. If I thought I could deliver to you I'd collect the data necessary to do so, though not by asking you to pretend that the meaningful differences are not meaningful.
Others operate differently, Amazon makes a bunch more revenue than me, YMMV.
If I'm askimg for a ZIP code I probably already know I can't deliver to you. If I thought I could deliver to you I'd collect the data necessary to do so, though not by asking you to pretend that the meaningful differences are not meaningful.
Others operate differently, Amazon makes a bunch more revenue than me, YMMV.
Canadians have long dealt with this: credit card companies have a fun hack where your postal code has 3 numbers and 3 letters; drop the letters and add 2 zeros. So v4r 2x3 becomes 42300. Since this is used as one component in identity verification, the lossy correspondence is apparently considered good enough.
<p>You can get a kind of self-close with this.
<p>Although it only works on some elements.
<p>Although it only works on some elements.
They're referring to the use of the trailing slash in examples like this:
<input type="text" inputmode="numeric" />
Such slashes were mandatory in XHTML for such elements but aren't a thing in HTML. They're also not invalid, the HTML validator says "Info: Trailing slash on void elements has no effect and interacts badly with unquoted attribute values."
Such slashes were mandatory in XHTML for such elements but aren't a thing in HTML. They're also not invalid, the HTML validator says "Info: Trailing slash on void elements has no effect and interacts badly with unquoted attribute values."
The trailing slash itself is not invalid, per se, but it'a very hard for any following markup to be valid unless the element is void.
A particularly nasty one is any attempt to use a supposedly self-closing script tag:
A particularly nasty one is any attempt to use a supposedly self-closing script tag:
<script src="..." />
> Chrome and Edge have been known to send the contents of <input> elements to a spellchecking service over the network, exposing whatever was in the field
One day maybe someone will write a client side spell checker that can work without sending things to a data centre to be rendered.
One day maybe someone will write a client side spell checker that can work without sending things to a data centre to be rendered.
[deleted]
Hasn't Apple done that with the iOS/WatchOS resident language models, for one example?
I read the parent comment here as sarcasm... We've had offline spell checkers for decades. Sending our text to some server for checking is a modern horror
Nice write-up! The nuances between browsers can be annoying yes, if I remember correctly the spellcheck behaviour for contenteditable div are also different between FF and Chromium-based.
We should not be sticking to what works for "most people". I am sorry.