Hi! 👋
This is the list of HTML input types. The reference is from MDN's <input> HTML input element.
Currently, 22 valid ones + 1 obsolete.
- button
- checkbox
- color
- date
- datetime-local
- file
- hidden
- image
- month
- number
- password
- radio
- range
- reset
- search
- submit
- tel
- text
- time
- url
- week
- datetime — obsolete
The Demonstration — Interface
I've made an interface to visualise and describe each of the types below. I do not stylise the shown input element so you can observe its original form.
Control and Field
"Control" is the umbrella term — it covers any interactive widget in a form: text boxes, checkboxes, radio buttons, sliders, colour pickers, buttons, the lot.
"Field" tends to get used more narrowly, usually for the sort of control where we're typing or entering a value of some kind — text, number, date, and so forth.
A "control" like a checkbox or radio button, we're just clicking or selecting, no manual typing required. Whereas a "field" wants us to actually type something.
date, month, week, and other date-time-related types — plus the obsolete datetime — can go either way — typed manually or picked from a widget. Thus, I put the label as "control/field".
name Attribute
It identifies an input so its value gets included when a form's submitted natively, acting as the key in the key-value pair sent to the server.
For radio inputs specifically, it also groups them together, ensuring only one can be selected at a time within that group.
It's not needed if we're handling values purely via JavaScript rather than native form submission.
type="url", type="email", and type="tel"
type="url" — A field for entering a web address. Looks like plain text but validates that the input is shaped like a proper URI (scheme + rest), not specifically a web link. Bit of a trap, that — ftp://files.example.com or even whatever://thing will pass just fine, since any registered or made-up scheme counts, so long as it's URI-shaped.
type="email" — A field for entering an email address. Validates against a simplified pattern (roughly [email protected]), not the full official email spec. So it'll happily wave through addresses that don't exist, and can occasionally trip up on unusual but technically valid ones.
Specifically for email address validation — it doesn't even check against the full official email spec (RFC 5322), which allows for all sorts of mad stuff like quoted strings and spaces. The HTML spec deliberately uses a simplified pattern instead, because the "correct" one is so barmy that it'd reject perfectly normal-looking addresses or accept genuinely bizarre ones.
So really, type="email" is less "is this a valid email" and more "does this vaguely resemble an email-shaped string".
Now, type="tel" — A field for entering a phone number. It's got NO built-in validation whatsoever. None. Zilch. Nowt. Ah, type="tel".
Unlike email or url, which at least pretend to check the shape of things, tel just accepts whatever we throw at it — letters, symbols, emojis, the works — because phone number formats vary so wildly across countries (dashes, spaces, brackets, country codes, extensions) that the spec basically threw its hands up and said — Not our problem, mate.
Anyway "zilch", they didn't go with "nothich". Unglamorous term, that. "Nothich." Sounds like a sneeze. But come to think of it, sounds rather Scottish — a good guttural "ch". Same sound in "loch", "Auchtermuchty", "Sassenach", and the like. Shame it never caught on. Oh for our information, loch = lake. Loch Ness = Lake Ness. "Ness" being the name of the river that flows through it — the River Ness. This has nothich to do with input types.
Right. That.
Hence, although we use proper type — either "email", "url", or "tel" — we still need to write our own script / method to validate it. Either on frontend, backend, or possibly both.
Database. Mm. For SQL-wise, we can gate that with proper CHECK constraint. And for NoSQL such as Firestore, Firebase, and MongoDB — there's Security Rules (for the Google lot) or schema validation at the database level (for MongoDB), it's a different kettle of fish entirely. But still, we can validate / gate the input.
So when frontend fails, backend fails, the database lad needs to gate that. That's all. With shouting, of course. — Oi! You frontend and backend lads! 📢 JEEEAARGHH!
Side information, for frontend, I have a post about email address validation using RegExp. It's bizarrely within "CSS invalid-valid pseudo class" topic. Well, not that bizzare.
Right, then. That'd be all. Thanks for visiting! 👋