
A story about &lt;input&gt; - kevincennis
http://meowni.ca/posts/a-story-about-input/
======
idbehold
She didn't even touch upon the crazy <input type="number"> which will allow
the user to enter in non-number input such as a dollar signs and letters.
However, when you try to access said input's value from the DOM it will give
you back an empty string since what the user entered (and what is still
displayed to the user) isn't a valid "number". Great!

In this case the input won't even fire a change event because before the user
entered anything the value was "" and after the user entered the invalid input
the value (according to the DOM) is still "". No change!

~~~
tobr
Number inputs are amazingly bad. In many languages, comma is considered the
correct decimal separator [1], but if your users enter that they will break
the input in about half of the browsers.

As far as I understand, there's no way to feature detect this stuff. Why not
just use text input? Because on iOS, `type="number"` is the only way to get a
keyboard with both digits and a decimal separator. So, browser sniffing it
is...

[1] [http://www.statisticalconsultants.co.nz/blog/how-the-
world-s...](http://www.statisticalconsultants.co.nz/blog/how-the-world-
separates-its-decimals.html)

~~~
idbehold
The mobile on-screen keyboards are the only reason I even attempted to use
<input type="number">. I could've gotten away with using <input type="tel">
which doesn't have any type of validation associated with it, but the keyboard
presented on iOS doesn't have a period key (or a comma for those other
languages) which means you can only enter natural numbers. Android on the
other hand does provide a way to enter periods form the "tel" on-screen
keyboard.

What I don't understand is why this weird validation behavior only exists for
<input type="number"> and not for other input types that have built-in
validation rules such as <input type="email"> and <input type="url">. Imagine
an <input type="email"> reporting that its value is an empty string if the
user didn't enter a completely valid email address.

~~~
joshuahutt
I actually had that exact problem, when writing an app with Ionic. It looks
like a "feature" of Angular, as can be seen on their documentation [1].

[1]
[https://docs.angularjs.org/api/ng/input/input%5Bemail%5D](https://docs.angularjs.org/api/ng/input/input%5Bemail%5D)

~~~
idbehold
You can still get the actual value from DOM even if Angular is updating your
model with an empty string.

------
ksks
I am creating a test app that record and replay user's actions on web apps, so
I have to deal with many low level html/js behaviors, boy was I surprised when
I found out those quirkiness she talked about and many others during
development.

For example, if you have a <form> with a text field (input[type=text]) and a
submit button, if you hit 'Enter' in the text field, you get a submit event,
nothing surprising. But did you know you also get an artificial click event on
the submit button, before the submit event?

Now what if you don't have the submit button? Then hitting the 'Enter' key
would still generate a submit event, but without any artificial click event
now.

OK, what if you want to have two textfields now (and still no submit button)?
Then hitting 'Enter' would...you guessed it, NOT generate any submit events.
No submit event, no artificial click, not even moving the focus from one text
field to the other.

But what if you have a non text base input (color, date, range, etc) and hit
'Enter' on it? Yes, you get a submit event, but ONLY if you have a submit
button. Otherwise no, even if you have just a single non-text based input.

And all these are just for Chrome. Other browsers behave somewhat differently.

~~~
apendleton
I've had the best luck just globally swallowing the submit event and
pretending like it doesn't exist, and deciding for myself when to submit based
on clicks or keystrokes.

------
destructionator
The <input type="image"> isn't just an image, it actually inputs data too. It
tells the server the coordinates on the image where your click occurred.

Everybody seems to think they are just for decorating submit buttons, but
that's not true - their primary purpose is telling those coordinates of the
click!

~~~
yoha
I was really surprised by this so I had to check by myself. This is true! And
I never learned that all the time I roamed the Internet.

Thanks for spreading arcane knowledge!

~~~
junto
You obviously never had the misfortune to deal with image maps - the Ramsey
Bolton Bastard brother of Flash. :-)

~~~
MichaelGG
They were very popular before that. I recall finding great use for them around
97. Easiest way to have complicated graphical navigation.

~~~
junto
All was find until you had to define clickable areas as polygons. Urrrrgh.

------
jordanlev
Yeah, the haphazard/inconsistent nature of HTML/CSS/Javascript is the flip
side of the "open standard" coin. I always tell students "a perfectly
architected system would mean it's controlled by one company, and you'd need
their permission and/or have to pay money to build those apps/sites" (then I
talk about the negatives of the app store review process to demonstrate the
point).

Which of course doesn't mean we shouldn't be trying to improve them... just
something I remind myself whenever I start to get angry about all the annoying
things that need to be thought about when writing HTML/CSS/JS.

~~~
RyanZAG
Architected system designed by one company isn't a silver bullet. Win32 or COM
APIs? Even modern iOS has stuff like Core Data which is an incredible pain to
work with. Don't think anybody needs to even get started on some of the APIs
lurking in Android...

There's good and bad APIs from both open standards and closed ones.

~~~
catshirt
jordanlev said "a perfectly architected system would mean it's controlled by
one company"

not "every system controlled by one company is perfectly architected"

to counter, you'd need to find an example of a perfectly architected system
developed as an open standard by multiple companies

~~~
RyanZAG
I was going to do a quick search for "open standard" systems to try and pull
out the gems that really are good to help prove the point - but I realized I
wasn't entirely sure on which systems fit as 'open standard' and which don't.
It's more of a spectrum of openness.

Anyway, the best example of an open system that is better than other system
designs controlled by single companies is extremely obvious: UNIX.

I'd say it's closer to perfect than all the other OSes that are heavily
controlled by single organizations. Or does UNIX not fit as an open standard
from it's origins? If so, Javascript, css, etc come from similar origins
(Netscape?).

~~~
ATsch
I would disagree about the UNIX standard being a) comunity developed, as the
UNIX the specification describes was mostly developed by AT&T/Bell Labs and b)
being an open specification, as it is owned by Novell, who only allows usage
of the UNIX trademark after verification and a large sum of money.

That said most moden _NIXes are community developed and although they are
arguably superior to non-_ NIX systems, they are (again, arguably) about as
much of a mess as HTML.

~~~
skissane
While what you have said is true about the origins of UNIX, the current
reality has changed. The current UNIX standard is developed in an open fashion
- anyone can contribute
([https://www.opengroup.org/austin/](https://www.opengroup.org/austin/)).

Novell no longer owns the UNIX trademark - it now belongs to the not-for-
profit industry consortium The Open Group. You don't need to pay any license
fees to read or implement the standard, only to access the official test suite
and use the trademark. Those fees go to The Open Group to pay for the
maintenance of the standard and test suite; to the best of my knowledge, none
of that money goes to Novell.

------
pavel_lishin
That was really well written; I hope she writes more stuff, it looks like the
blog is updated really sporadically.

Bonus easter egg: place your mouse over the author's photo.

~~~
talhoffer
Check the source for an image too.

~~~
gk1
And an emoji used as an element id.

~~~
spurgu
Source: [https://github.com/notwaldorf/emoji-
selector](https://github.com/notwaldorf/emoji-selector)

------
mstade
Fun read, but to say web components would solve any of this is just wrong.
You've got to remember that there are two sides to the coin: presentation and
functionality. The presentation problem can be solved by web components (more
accurately: the encapsulation of presentation,) but the functionality bit
should be solved with proper JS APIs. That there were no proper JS APIs
available 21 years ago is understandable – after all the language barely
existed. But that we don't have proper input APIs today is just silly.

~~~
shadowmint
To be fair, that's only true of one type of input; the file picker; possibly
the color picker too...

The rest of the input types are just text values and some presentation.
There's no _technical_ reason for them to all be as absolutely terrible as
they are; it's just legacy bloat.

That said, I agree, 'in general' web components probably aren't going to be
'the thing' any time soon; the polyfills are too rubbish, and the native
browser support basically doesn't exist yet.

...but the issue is mostly module imports and the shadow dom being
ridiculously slow and terrible with nested components.

Input types are inherently simple; there is no reason to have another
component inside your input; simple web-components for the most common input
types (text, textarea, date, number) seems like a very reasonable and
plausible goal.

You've got to admit, if there was a simple way to get consistent cross browser
responsive input tags, it'd be awesome.

~~~
kalleboo
> Input types are inherently simple

Maybe if all you need to support is English.

I have so much trouble typing Japanese even in many _native_ apps (cross
platform libraries are usually the culprit), I can't imagine Web developers
ever getting it right... For instance it's quite broken off and on in Google
Docs.

------
sosuke
Really fun read! Oh man, file, that could take up another post entirely
couldn't it?

I wonder about textarea though, I always related the closing tag requirement
to XML where you could not put CDATA into attributes. So was it shortsighted
to have <input> use value instead?

This is where I run away screaming like my hair is on fire, specifications are
a beast.

~~~
kragen
<input value="In an &lt;input&gt; tag's &#34;value&#34; attribute,&#0a;you can
put any text" />

------
LukeShu
Hey HN staff, there's a bug here: body shows fine, but the title renders as "A
story about &lt;input&gt;"

~~~
recursive
I'm seeing this as well. The served html says

<title>A story about &amp;lt;input&amp;gt; | Hacker News</title>

It looks like it got double encoded.

~~~
nathancahill
Funny, my HTML based HN app on iOS actually rendered[0] an input field in the
title. Disappeared after a second. No one submit titles with
<script>alert()</script> please!

It looks like the title in the API is encoded correctly[1].

[0] [http://i.imgur.com/CDnwDZJ.jpg](http://i.imgur.com/CDnwDZJ.jpg)

[1] [https://hacker-
news.firebaseio.com/v0/item/10433793.json?pri...](https://hacker-
news.firebaseio.com/v0/item/10433793.json?print=pretty)

~~~
scintill76
The API is returning "title" : "A story about &lt;input&gt;" for me. I don't
consider that correct encoding, as "&lt;" is not a special escape sequence in
JSON, and expecting API consumers to either blindly trust you did their
escaping for them, or HTML-decode JSON strings to use in another context, is
silly. It is probably another symptom of something HTML-escaping the title
when it shouldn't be.

~~~
nathancahill
Yes, you're right.

------
CM30
I can't agree more with the points raised in the post.

But input type file... now that's really screwed up at the moment. Ever wanted
to style that thing? Good luck, there's pretty much no cross browser CSS
support for styling just about any of it. Oh, you can do some stuff in Webkit
or Blink, but good luck trying to do the same for Gecko or Trident/Edge
powered browsers.

Ah well. The input element is at least easier to style than the select one.
That one's so annoying to customise that just about every major site replaces
it with a Javascript version.

~~~
nommm-nommm
<input type='file'> is unbelievable for its inability to be styled. IE is even
more bizarre in that it displays the full path of the file chosen in a text
field with a blinking cursor like you can type when active but ignores
keyboard entry - except the backspace or delete keys that removes the file if
there is one selected. IE11 changed file selection from double-click on
mystery text field to single click on mystery text field. Browse always worked
however.

------
crankin
Opening the HN app on iOS actually loads an input field in the title of this
article for a split second. Anyone else notice that?

~~~
nathancahill
Yeah, see my comment above. Got a screenshot of it.

------
anonymousjunior
And people wonder why there's a 300+ line angular directive maintaining our
Credit Card input box...

------
neduma
I originally thought it is a really story about `input` like the one with
`printf` - [http://ferd.ca/the-little-printf.html](http://ferd.ca/the-little-
printf.html)

~~~
jaza
Yeah, me too! Although after reading the article, 'input' is clearly unworthy
of being glorified in an Antoine de Saint-Exupéry redux.

------
p4bl0
Oh, it seems Firefox still has this bug that "&lt;" and "&gt;" and rendered
as-is in the window title bar and tab title and not as '<' and '>'.

~~~
LukeShu
It's not a bug in Firefox, it's a bug in HN, it's double-escaping the <title>.

~~~
p4bl0
Oh right. I remembered having problem with this a few years ago, so I didn't
bother to check and just assumed it was the same problem. Thanks for
correcting me!

------
methyl
> Now imagine the future where Web Components are supported natively, and
> someone else is allowed to write a <better-input>, an element that is a
> real, encapsulated DOM element, and not just a div soup.

For now, you can just use Polymer any other components-backed library like
React. I think it's good enough, although native support of Shadow DOM is very
exciting.

~~~
ShirsenduK
Shadow DOM is there in Chrome and might soon be added to WebKit. I personally
don't think they will last.

~~~
rictic
Edge and Firefox are getting native shadow dom too!

------
crankin
The HN iOS app actually displays an input field for a brief second in the
title of this article. Anyone else notice that?

~~~
vito
Same on Android, and the same weird second delay. Huh.

Screenshot: [http://i.imgur.com/FKPvJsq.png](http://i.imgur.com/FKPvJsq.png)

Feels pretty sketchy; I wonder what other kinds of things could be snuck in
there.

------
mschuster91
What's painfully missing is a way to properly style the textbox of a file
upload separately from its button.

At the moment it's only possible in Chrome, with the added downside that you
cannot combine the pseudoselector with any other rules because Firefox and IE
will drop the ENTIRE rule as they cannot parse the pseudoselector.

------
gotchange

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

I guess I'm nitpicking here but she meant the DOM or Web API and not
JavaScript because it's not the fault of the underlying language that they
made a mess of their API this way.

------
myfonj
Ad `textInput.checked = true;`, this quite a misconception. You can totally
set `anyDOMnode.whateverProperty = 'batman'` and retrieve it back. Itʼs just
few special DOM object properties that are mapped to HTML attributes on
certain types of elements that actually do something meaningful, like the
@checked property of HTMLinputElement objects that happen to have
@type="checkbox".

~~~
apendleton
But "checked" on a text input isn't undefined; it exists and is false. It's
not the same as just being able to hang arbitrary crap on any DOM node; it
exists in the API, and some other nonsensical input properties don't and are
undefined, and still others throw errors when you try to access them. It's
bonkers API inconsistency that can reasonably be called out.

~~~
myfonj
Iʼm not defending the API, and I admit I was commenting without proper
understanding here, so yes, you are right that that property is really defined
as false. But Iʼd like to correct your statement about 'some defined some
undefined' properties. Fact is that all [HTMLInputElement] interface instances
no mater what [type] they are shares exactly the same set of properties. And
because that "type" is also just one of the them you can for example convert
password input into text input and text input into checkbox just by setting
itʼs @type value:

    
    
        data:text/html,<input id=i type=text checked><script>document.write(i.multiple);i.type='checkbox'</script>
    
    

Yes, it is weird and in retrospect it seems silly that there are not extra
interface for each type of input (there is no HTMLRadioButton interface for
<radio> tag DOM elements inheriting from some abstract HTMLFormElement
interface). Perhaps some witness of standardizing process have good argument
for that. (My guess it something like "Oooh, so many Elements, that means so
many tags, no, letʼs keep that simple, ok? They are mostly similar anyway.")

[HTMLInputElement]: [https://developer.mozilla.org/en-
US/docs/Web/API/HTMLInputEl...](https://developer.mozilla.org/en-
US/docs/Web/API/HTMLInputElement) [type]: [https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/in...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input#attr-type)

------
eric-hu
That was a fun read, and now the million dollar follow up question: What can
be done to improve the situation?

Is there even a single place that catalogs or demonstrates such
inconsistencies? Could anyone demonstrate the ways in which HTML elements are
inconsistent across desktop and mobile browsers in a compelling enough way to
draw the attention of all the browser teams out there?

------
oneeyedpigeon
This is really well written, and an interesting read for all us markup nerds,
but I don't understand why the author persists with criticising browsers for
extremely minimal differences in language used to communicate that a file
hasn't been selected. If the meaning is there, why on earth should each
browser be utterly stripped of personality?

~~~
TazeTSchnitzel
And this is assuming the world only speaks one language, English. Should the
other-language strings also match across browsers? Should it be embedded in
the specification?!

It's nonsense, really. HTML is user-agent-agnostic. User agents have free
reign in how they implement controls to suit their platform.

------
greggman
Input might suck but I'm not looking forward to webcomponent based solutions
that break in every non European language in strange ways. Is your
webcomponent going to handle right to left input?

Heck, even non webcomponent solutions don't work with non-English languages.
AirBnB's message UI breaks with Japanese innput

------
GigabyteCoin
I'll never forget the first time I saw "Submit Query" as the value for a
submit button I had created. I spent hours scratching my head and double-
checking that I had indeed not written "Submit Query" anywhere in my HTML and
was absolutely flabbergasted.

------
grayrest
I always considered the quiet years up until 2005ish. After that we had XForms
and the WhatWG hijincks to keep the web nerds entertained.

~~~
nathancahill
Well? Are you not entertained?

------
al2o3cr
Input tags are a pain, but the prospect of every designer getting to make up
their own UI controls gives me Flash-backs. ;)

------
personjerry
The mouseover link colors on this site...

------
rfeague
Damn, that's some great writing. :)

------
yashafromrussia
This makes me want to dive in deeper

------
SchizoDuckie
Now shall we talk about date pickers? With timezones? And input/output
formats?

Nah, let's not :P

------
whoopdedo
Did anyone else see the title and think this would be about Perl?

------
bricss
If you stupid its always hard to deal with any API.

------
trymas
Great article.

Though links on that site can produce headache..

------
ocfx
her page is all bubbly and cute

~~~
Mz
It's also a good read.

~~~
vdnkh
And really nicely designed/styled

~~~
Mz
I would like to see a helluva lot more like this. I often don't read coding
articles. I read this one. I enjoyed it. I learned something.

~~~
douche
It is a very nice, clean design. The rainbow blink effect gives me a little
bit of a headache, but other than that it's a pleasure to read.

Also, ASCII squirrels are always a pleasant bonus.

As always when I learn about the guts of the web, I'm amazed anything ever
works. It's like the Rube Goldberg breakfast machine...

~~~
duderific
> As always when I learn about the guts of the web, I'm amazed anything ever
> works.

So true. Whenever my wife is complaining about something on her computer not
working (or being too slow), I try to remind her of the amazingness that a
computer works AT ALL, and quite reliably at that.

------
draw_down
Welcome to web development!

------
ShirsenduK
I'm of the opinion that this is how open standards evolve and have immense
respect for people who got us to where we are today. Rants like this not so
much.

~~~
usaphp
because of "rants like this" open standards evolve and these issues gets
fixed, otherwise if nobody ranted - nothing would have been fixed

------
peterwwillis
Apparently HTML is annoying, different implementations aren't always
compatible and Javascript sucks.

So the web is the same as it was 15 years ago. Still glad i'm not a web dev.

~~~
vlunkr
I would say that Javascript as a language doesn't suck, but many of these old
browser API's do.

~~~
MichaelGG
Crazy scoping rules? Crazy conversion rules? 8 character lambda keyword?
Crappy numeric type? It's safe to say it sucks. It's understandable, given the
10 day timeframe it was created in plus the constraint of needing to be "like"
Java for cachet. It's less understandable how so many have doubled down on it.

And even new APIs suck. Look at the silliness npm encourages people to do.

~~~
michael_fine
At least the scoping and verbose lambda problem have been solved in ES6, with
the introduction of let-vars and fat arrow functions, respectively.

------
rch
> 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.

~~~
TheDong
Re-posting a snippet of the blog isn't useful or valuable on its own. I am
quite able to read a blog post without you copy-pasting it into the comments.

~~~
rch
Fair enough. It's still a good line :)

