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.
The input element is within a form element, as such:
Give it a bash, mate. ⬇️
Side Note for input[type="search"] Cancel Button
Blogger (this theme specifically) hides the native search clear button. So I have to force it back to life using:
⬆️ Dear heavens.
Sorted. Moving on.
Anyway, the input[type="search"] cancel button is rendered only on Chrome and other Chrome variants.
Firefox actually doesn't render a native clear cross for input[type="search"] at all by default.
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 / time types such as date, month, week, and so on — 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"
input[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.
input[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, input[type="email"] is less "is this a valid email" and more "does this vaguely resemble an email-shaped string".
Now, input[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.
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.
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 the front end, the back end, or possibly both.
The 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 the front end fails, the back end fails, the database lad needs to gate that. That's all. With shouting, of course. — Oi! You front-end and back-end lads! 📢 JEEEAARGHH!
As a side note, for the front end, 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! 👋