Some people build furniture. Some people knit. Some people have hobbies that don’t involve HTML specs from the 90s. I am not those people. So here’s a story about <input> , how it got to be the jerk that it is, and why it needs to die in a fire.

The early years

1995 was a good year. Friends, ER, Xena were all on TV. TLC had dominated the charts with “Waterfalls”. Browsers were ok, because HTML was pretty ok. We had Mosaic, Netscape and IE1, and the HTML2 spec was finally getting around to standardizing forms. 1995 was the year when <input> was born, and now that it’s about old enough to drink, we need to have a talk.

Input initially came along with 8 types: text , password , checkbox , radio , image , hidden , submit and reset , and in a separate RFC that followed, file .

Wait, did you say image? Yeah, let’s talk about it.

<input type="image" src="cat.png"> looks like an image, but it’s actually an image button that also submits the (x,y) coordinates of where you clicked on the image. Unless you don’t specify a src file, in which case it’s an “image button” that says “Submit”. Unless you’re in Firefox, in which case it says “Submit Query” and looks like a label. Unless you’re in IE in which case it doesn’t say anything at all.

Also, for your local pub trivia night, the message that the type=file input to indicate you haven’t done anything is “No file chosen”, “no file selected”, “No file selected”, and just an empty textbox on Chrome, Safari, Firefox and IE respectively.

Right, ok.

And now, a <textarea> rant

I always thought input and textarea came at later dates, and that explained why they’re kind of insanely different. This is kind of true, since input was around in Mosaic since at least 1993, and it was a fixed-up implementation of ISINDEX . However, on the record, they were both children of the HTML2 spec, which decided that <input> is a self closing tag and uses a value attribute, while <textarea> needs a closing tag and uses its contents, even though they both just hold text that someone else has entered:

<input value= "batman" > <textarea rows= "1" > batman </textarea>

Update: someone pointed out that <textarea> needs to support multilines, and newlines aren’t allowed inside attributes values, which is why it needed to use its contents. Makes sense!

1995-2011, the slow years

In 1999, HTML4 only added type="button" . My favourite part about it is that with no custom styles, an <input type="button"> and an <input type="button" value="Submit"> on the same line, do not align vertically on Chrome/Safari/Edge.

Then everything got worse

Later, in 2011, the HTML5 spec added a billion new input types. It’s now 2015, and most are not implemented. The TL; DR of the missing features is: type=color only works on Firefox/Chrome, date/time inputs only work on Chrome/Edge/iOS, and everything that works on Chrome works on Opera. Here’s a demo of all of the different input types to date, so that you can compare and sob by yourself.

Let’s talk about some interesting ones.

<input type="search"> has some arbitrary text padding, borders, and badass mid-2000s-style rounded corners, all of which are inconsistent across all browsers, and almost impossible to get rid of.

If you’re on a lucky browser that does support type="date" , don’t worry about styling the date picker — there are 8 weirdo ::webkit pseudo-selectors out there, but they’ll only let you style the input textbox, and not the actual date dropdown. CSS is bad for your health anyway.

Just when you thought it couldn’t get any worse, JavaScript

You see, I can justify CSS quirks. I worked on Chrome for 2 years, I work next to the Blink team now, I understand we’re all writing different renderers and they all have their own CSS bugs. However, the <input> API isn’t quirky — it’s literally just a jar of spiders, and the moment you open the jar, it’s too late. You’re covered in spiders. Even your cat is a spider now. Better find some fire.

Since 1995, inputs with type radio and checkbox have had an extra attribute, checked , to determine their checked status. Since an HTMLInputElement is an HTMLInputElement is an HTMLInputElement , this also means that all other input types have this property; it just gets ignored. So even though it doesn’t make sense, this is perfectly fine:

var textInput = document . querySelector ( ' input[type="text"] ' ); console . log ( textInput . checked ); // prints false. textInput . checked = true ; console . log ( textInput . checked ); // prints true. // did not open the hellmouth.

Cool. Cool cool cool.

Inputs also have text, and text can be selected, so the HTMLInputElement prototype also defines two properties, selectionStart and selectionEnd which are two numbers defining your selection range. So you can do:

document . querySelector ( ' input ' ). selectionStart += 2 ;

And advance the beginning of the text selection by 2 characters. Super pedestrian, except for the fact that the selectionStart — and brethren — attribute is only available for inputs of type text , url and password and just accessing it (not even setting it) throws an exception for all other types:

Uncaught DOMException: Failed to read the 'selectionStart' property from 'HTMLInputElement': The input element's type ('number') does not support selection.

Even though manually I can totally select that text:

So in some cases, irrelevant properties can be interacted with, but in other cases they open the hellmouth. Neat-o. That’s just the kind of consistency I look for in an API.

🙈

There’s more. I’m sure there’s more. The thing is, browsers have had 21 years to sort out inputs, and they haven’t even managed to agree on how to communicate “you haven’t picked a file”.