Note by Manuel: Not all screen readers announce the field as “read only”. You may want to test it first and decide whether to support it with an additional description.
One other thing to consider, how spellchecking is implemented is left to the browser. Chrome and Edge have been known to send the contents of elements to a spellchecking service over the network, exposing whatever was in the field. If your elements are capturing sensitive data, like personally identifiable information, like names or birth dates, or passwords, then you should set spellcheck=“false” to avoid sharing it.
I’m going to have a stroke. Don’t break my user agent for imaginary security concerns.
The default behaviour for an on a mobile device is to capitalise the first word and make all other characters lowercase. This is fine when writing a sentence, however things like names and addresses expect all words to be capitalised. Other inputs, like airline ticket identifiers and UK postcodes expect their input to be in all capitals.
The autocapitalize attribute is your friend in this case and saves your users having to use the shift key to produce text in the format you want it.
Capitalise the first letter of every word with autocapitalize=“words” and capitalise every letter with autocapitalize=“characters”.
‘saves your users having to use the shift key to produce text in the format you want it.’ is such a stupid motivation that I’m struggling to believe it isn’t satire. There are two distinct things here:
The capitalisation conveys semantics. If it’s part of the name, it’s important to preserve what the user sends. The owner of a name has much better understanding of the correct capitalisation than you.
The capitalisation is a form of normalisation. In this case, don’t require anything and do the conversion after submission.
I would argue that if you know that the input should legitimately be all upper case or similar (like UK postcodes) it is still good to use autocapitalize=characters. It saves the careful use from having to put their keyboard in caps mode and gives confidence to the format that you expect. But then yes, you should also normalize on the backend.
It just makes the shift key start in the pressed state for the first character of each word on mobile. The user can of course toggle shift off if needed. It’s just a convenience for the common case.
Oh, I’ve seen that. It’s frustrating because my motor memory for typing my name on a mobile keyboard involves hitting shift and now shift is in the unexpected state and I turn it off, then have to go back and edit.
My favourite is that when you delete it doesn’t re-apply the shift key but in my head I need to start from scratch again so I end up getting it wrong the second time without fail as well.
If you like the features offered by the input element attributes but you have a hard time remembering what they are or are prone to misspelling, try using an HTML generation library that encodes that information. It makes it really hard to make dumb mistakes. I can recommend mine: https://yawaramin.github.io/dream-html/dream-html/Dream_html/HTML/index.html#val-autocomplete
Jesus, no. That’s on the screenreader!
I’m going to have a stroke. Don’t break my user agent for imaginary security concerns.
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ Falsehoods Programmers Believe About Names
‘saves your users having to use the shift key to produce text in the format you want it.’ is such a stupid motivation that I’m struggling to believe it isn’t satire. There are two distinct things here:
I would argue that if you know that the input should legitimately be all upper case or similar (like UK postcodes) it is still good to use
autocapitalize=characters. It saves the careful use from having to put their keyboard in caps mode and gives confidence to the format that you expect. But then yes, you should also normalize on the backend.Sure, if the capitalisation is a hint that the case is irrelevant and will be discarded then it’s a valuable visual clue.
It just makes the shift key start in the pressed state for the first character of each word on mobile. The user can of course toggle shift off if needed. It’s just a convenience for the common case.
Oh, I’ve seen that. It’s frustrating because my motor memory for typing my name on a mobile keyboard involves hitting shift and now shift is in the unexpected state and I turn it off, then have to go back and edit.
My favourite is that when you delete it doesn’t re-apply the shift key but in my head I need to start from scratch again so I end up getting it wrong the second time without fail as well.
If you like the features offered by the
inputelement attributes but you have a hard time remembering what they are or are prone to misspelling, try using an HTML generation library that encodes that information. It makes it really hard to make dumb mistakes. I can recommend mine: https://yawaramin.github.io/dream-html/dream-html/Dream_html/HTML/index.html#val-autocomplete