The depths of the input element | Hacker News Reader

The depths of the input element

htmhell.dev

84 pointstodsacerdoti21 comments

Ha, I actually didn't know some of this stuff. I am guilty of not being very helpful to mobile and disabled users so far, mostly because I almost never work on user facing projects. Which is terrible excuse because why wouldn't a visually impaired or disabled person not be working in a back office or something.

We should not be sticking to what works for "most people". I am sorry.

If you were sorry you would change your approach.

Good article.

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

Sad to see the invalid markup throughout. The input tag is void, it has no closing tag. Self-closing tags are not HTML!

> 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?

You may have an alphanumeric postal code but as far as I'm aware there are no alphanumeric ZIP codes.

United Kingdom and Canada, for example, have alphanumeric ZIP codes.

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.

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.

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.

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.

<p>You can get a kind of self-close with this.

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

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:

    <script src="..." />

This results in the rest of your page being interpreted as code. Oops!

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

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.

Reply on news.ycombinator.com