Hi, I present to your attention the translation of the article by Monica Dinkulescu '<I> you, bringing me down'. Literary translation from English is not my main specialization, therefore inaccuracies are possible in the text. Edit calls to send a personal message, and if you have something to say, well in the comments. Special thanks to @Kt for editorial changes. Enjoy reading.


Some people make furniture. Some people knit. Some people have hobbies that do not overlap with the HTML specifications from the 90s. But I'm not one of them. And here's a story about how <input> became the crap it is, and why it should be burned.

early years

')
1995 was a cool year. Friends, Ambulance, Xena on TV. TLC occupied the top of the charts with the hit " Waterfalls ". With browsers was normal, because HTML was all very normal. We had Mosaic, Netscape and IE1, and when approving HTML 2 specs, finally, it took time to standardize the forms. The ninety-fifth was the birth year of <input> , and now that he is old enough to buy alcohol in a store, we need to talk.

Initially, <input> came to us in eight forms: text , password , checkbox , radio , image , hidden , submit and reset , as well as with a separate subsequent RFC , file .

Wait, did you say image ? Yes, let me tell you about him.

<input type = 'image' src = 'cat.png'> looks like a normal image, but in fact it is a button image that, when clicked, also transmits the x and y coordinates of the place where it was clicked. At the same time, if no image is specified for the src attribute, the “image-button” will become a button with the “Submit” message. And if Firefox happens, the button text will change to “Submit Query” and the button will look like plain text. And if you open an example in IE, in this case you will not see anything.



And here is a question worthy of your local club “What? Where? When? ", If the element type = 'file' , then the text that will be displayed in place of this element when none of the files are selected:" No file selected "," no file selected "," No file selected ", and just empty text block in Chrome, Safari, Firefox and IE respectively.

Okay, fine.

And here is a tirade in honor of <textarea>

I always thought that input and textarea were invented at different times, and this explains why they are so insanely different. This is generally the case; input has been part of the Mosaic browser since at least 1993, and it has been, in effect, a corrected implementation of ISINDEX . Nevertheless, officially, they were both children of HTML2, who decided that <input> is a self-closing tag in which the value of the tag is placed in the value attribute, while for the <textarea> tag you need a closing tag and its value is stored in its content, even if both tags are used only to store plain text that someone entered:

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

Small update: someone prompts that <textarea> should support multiline text input, and line breaks are not allowed inside attribute values, which is why we have to use the contents of the tag. And it makes sense!

1995-2011, average years

In 1999, in HTML4 only one new tag type was added = 'button' . What I particularly like about this is that without any additional custom styles, <input type = 'button'> and <input type = 'button' value = 'Submit'> placed on the same line do not coincide vertically in Chrome / Safari / Edge.

Everything gets worse

Later, in 2011, the HTML5 specification added thousands of new types for <input> . And today, most of them are not implemented. Here is a short list of broken features: type = color only works in Firefox / Chrome, date / time only works in Chrome / EDGE / iOS, and everything that works in Chrome works in Opera. Here is a comparison of all available input types for today, so you can compare and cry in private.

Let's talk about some interesting facts.

<input type = 'search'> has strange randomly selected indents between the text and the border, as well as rounded corners that are popular in the mid-2000s, whose appearance differs from browser to browser and is almost impossible to get rid of.



And if your browser is lucky to support type = 'date' , do not worry about styling the date picker - we have 8 wonderful :: webkit pseudo-selectors that will help you customize the style of the text box, but not one to style the drop-down date picker! In any case, know that CSS is bad for your health.

And at that moment when you thought that there would be no worse: JavaScript

You see, I can justify the quirks of CSS. I’ve been working on Chrome for 2 years, now I’m working with the Blink team, I understand that we all write different renderings and that they have their own CSS bugs. However, the <input> API can not even be called strange - it is literally like a bank of spiders, and at that moment when you open the can, it is too late. You're all in spiders. Even your cat has become a spider. It is better to burn everything here.

Since 1995, form elements with the types radio and checkbox have the additional attribute 'checked' which allows to determine the state of the element. Since HTMLInputElement is HTMLInputElement and this is HTMLInputElement , it turns out that this attribute is also present in all other types of the <input> element, but it is simply ignored. Yes, even if it does not make sense, it’s amazing:

 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!

<input> contains text, the text can be selected, and in the HTMLInputElement prototype two properties are defined: selectionStart and selectionEnd are two numbers that define the selection range. So you can do:

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

And move forward 2 characters from the beginning of the text selection. The mega-ordinary exception to this fact is that selectionStart is an attribute that is available only for input types with text , url, and password types. It is also available for calling (it is not even configured) by throwing an exception for all other element types as well:

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

Even if I can manually highlight this text:



It turns out that in some cases the properties can actually be used, and in other cases they will show their “wolfish grin”. Sumptuously. This is what consistency I am looking for in the API.

Unfortunately, that's not all. I'm sure that is not all. The fact is, browser developers had 21 years to fix the display of inputs, but they could not even agree on how to write "you haven't picked up a file."

Now imagine a future in which web components are supported natively, anyone can write their own <better-input> - the real DOM encapsulated element, and not just the noodles from the DIVs. Imagine how you use this <better-input> , that its implementation does not differ from browser to browser, it looks the same everywhere, and that it probably knows how to bake you a cherry cake. Just imagine.