Hacker News new | past | comments | ask | show | jobs | submit login
A story about <input> (meowni.ca)
693 points by kevincennis on Oct 22, 2015 | hide | past | favorite | 181 comments



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!


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


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.


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


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


Well the definition of a valid email address is very hard to get right and it can conceivably change.


The email address format is very well defined in rfc822. What do you mean by "it can change"?


RFC 822 is so loose in what it accepts compared to conventional use that it doesn't help with validation to prevent input mistakes, though it's effectively a lost cause. Since someone could theoretically have the address:

"<blink> !_joe!jim%foo_jay\@sus/\$ch=rist;`rm -fr /`"@example.com

Perfectly fine according to RFC 822.

RFC 2822 is better and rejects that, so things have changed for the better, and theoretically could change again (though I wouldn't bet money on it).

RFC 2822 still accepts:

"joe!jim%foo_jaysus/cee=rist;`rm -fr /`"@example.com

We must accept there's no reliable and correct way to help with many classes of actual user errors on input even if the world's existing SMTP servers can actually choke on valid RFC 822/RFC 2822 addresses.


I don't see what's wrong with: "joe!jim%foo_jaysus/cee=rist;`rm -fr /`"@example.com

This is what the user says their email is. If their mail server accepts it, what's the problem? I'd rather like the original 822 to be accepted, than "simple_email@example.com" be rejected because "OMG you can't have `_` in your address!". It just leads to validation of what the developer think is kosher, rather than what will work.

This extends to so many other things: email, post code, phone number, names, ... It's terrible when developers think they know those details better than the user does.


While there's nothing "wrong" with it in the sense of following the standard, it's nice to be able to help people spot mistakes when entering things.

With email I warn on weird input, but accept provided it's compliant since the goal is to help - the miniscule fraction of people with email addresses who have really peculiar addresses are far fewer than those who make typos when entering them. '_' isn't really peculiar, though.


> help people spot mistakes when entering things

I completely agree. Here's how it should work: "your email abc+def@example.com is valid but looks unusual, are you sure it's your email? ok/cancel". Not: "your email is invalid, guess which of our made up rules it violates". But you're in a tiny minority of people who handle this properly.


I thought using email+tag is quite common nowadays to auto-sort the letters, and the site which doesn't support it is absolutely breaking the email experience.


Except like 95% of the sites out there won't accept that e-mail, and I'm betting 50+% of mail servers will choke on it too, because developers love their regexes.

RFC822 allows you to even put comments in your e-mail. joe(Hello, Hacker News! How are we doing today?)doe@example.com is a valid e-mail as well (AFAIR; it's been a few years since I had to read that and related specs and implement something according to them).


> Except like 95% of the sites out there won't accept that e-mail

And that's the problem. There's a standard. Everyone ignores it and tries to reinvent their own idea of what the standard could be. It only leads to issues. If people think that the standard is so bad, they're of course welcome to produce and post their own RFC for discussion. But making up their own version of rules is bad and pretending there is no existing standard is also bad.


> Everyone ignores it and tries to reinvent their own idea of what the standard could be.

Sure, but that's not a failing of developers, the standard just happens to be too complex to validate without language or module support. If JS had an isValidEmail() function everyone would use it and be consistent, but without one the options are to google up some massive (but still imperfect) regex, or accept any string with an @ sign in it somewhere, or choose some random point in between.


Addresses don’t need @ signs to be valid, though…


I tested "`rm -fr /`"@mydomain.com with Gmail and it works. Thanks for my new email address :D

Edit: I also signed up for Twitter with that address and the confirmation mail was delivered.


Just because someone made an rfc, doesn't mean that the rfc is the de facto standard.


RFCs are closer to de jure standards, even if they aren't forced by law.


Exactly. And de jure doesn't make something de facto automatically.


As long as the RFC is marked as such, that's exactly what it means.


You're confused about de facto vs. de jure. It's a common thing to be ignorant about, but maybe in the future don't be all "No, no, you're exactly wrong!" before double-checking.


Though, if it's so often misunderstand perhaps I should be calling it `on paper' vs `in practice'.


Adding novalidate to the form tag stops the in-built validation madness, but still gives the relevant keyboard on mobile browsers.


Not sure how I've missed this for so long, thank you.


> Why not just use text input? Because on iOS, `type="number"` is the only way to show the number keyboard

Actually, this isn't true. It will also show the number keyboard on a normal type=text input if you add a pattern="[0-9]*" property.

EDIT: Sorry, misread your comment; you wanted the decimal separator too. I believe that might be impossible to get without type=number.


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

Really? How would you enter a street address into a form consisting of just text inputs?


It's the only way to default to the number keys when the keyboard comes up. The user can of course switch to it manually in a regular text input.


There's a way to detect the system decimal separator using JavaScript, but it only works in IE and Firefox, and it doesn't work in Chrome because it is marked as 'optional' in the standard.


<input type="number"> is just completely awful. To handle it properly in our React application, we have a <NumberInput> component which is roughly 200 lines (and shrinking, thankfully), involving more than a few browser-specific validity checks and keydown handlers.

The only way to keep non-numbers out of your number input is to cancel keydown events selectively, but it's still a crapshoot. And I've been bitten a few times by that bizarre change issue you mentioned.

If there's not already a good MIT-licensed project that encapsulates inputs and gets the weird out, I think it would be worth doing, whether in React or Web Components or both.


> The only way to keep non-numbers out of your number input is to cancel keydown events selectively

There's a much simpler way: monitor the "input" event, and whenever fired, do this.value = this.value.replace(/\D/g,'');

The user will never see anything they type other than numbers.


This will blow away the cursor position:

  User enters:    `1245|`
  Navigates back: `12|45`
  Enters 'a3':    `12453|`
  Instead of:     `12345`
There are a ton of "gotchas" in this. Pretty frustrating.


The user's cursor will also be moved to the end of the inputted text with every keystroke.


I don't believe that will work since the input.value will become an empty string before you can do your replacement.


I think you would use a text input if you were writing your own component with better number behavior


You'll trigger the wrong on-screen keyboard on mobile devices. There was talk about an inputmode attribute where you could specify "numeric" to instruct the OS to present the appropriate keyboard to the user without changing the input's behavior, but it isn't supported anywhere AFAIK.


Any plans on open sourcing yours?


Who comes up with this stuff? I've used the MS GUI toolkits (WinForms, WPF, Web Forms if you consider that similar) and don't recall ever hearing about such obviously poorly designed stuff. They aren't perfect but they're fairly great. I've heard OK this about other GUI kits, too. What attracts such terrible stuff to the web?


> I've used the MS GUI toolkits (WinForms, WPF, Web Forms if you consider that similar) and don't recall ever hearing about such obviously poorly designed stuff.

The raw Win32 API is worse than the Web APIs.


but the Win32 api also comes from what, 1993? Number input type is quite a bit more recent, we might expect something better.


Actually, 1985. Windows 1.0 had the exact set of APIs which later expanded to 32-bit and subsequently 64-bit.


Having worked with WinAPI for some time no, it's not worse than Web APIs. It seems to be more well thought-through, which probably says more about the current state of the web.


I couldn't disagree more, having worked with both sets of APIs. The Web APIs have benefited from a long period of multi-vendor standardization and consensus, something the Windows API has never had.


You know what they say about making chicken salad?

Windows might not be top-brand chicken, but it's at least poultry.


Design by committee.


In many cases, the bad APIs were actually the opposite: "design by some random person at Netscape in the 90s".


Read the history of the <blink> tag if you want a example : http://www.montulli.org/theoriginofthe%3Cblink%3Etag


So it literally was invented after a night of drinking at a bar. :-) I wonder about the origins of <marquee>.


MARQUEE started out as a "feature" of very early versions of Internet Explorer, as a way for IE to differentiate itself from Netscape. (Don't hate Microsoft too much for this -- they were just following the lead of Netscape, who had their own proprietary tags. Heck, IMG started out as a Netscape-only tag.)

There was a real danger for a few years in the mid-'90s that competition between browsers would manifest itself in a proliferation of proprietary tags that only worked with one browser or another. The old "Best viewed with..." buttons that sites used to festoon themselves with (examples: http://cjihrig.com/blog/wp-content/uploads/2011/12/best_view...) were an artifact of this; they advertised that a site used one browser or another's particular set of proprietary tags, which was how you positioned yourself as "cutting edge" in, say, 1996.

Things are better now, thankfully. (Not much better, but better.)


"WhatsApp Web requires Chrome or Opera"

"Google Inboxbeta only works in Chrome"

I’d say things are just as bad as before


True, but that's because whatever site can choose to rely on a cutting edge specced feature that the other browsers haven't implemented yet. At least it's not the 4 different companies trying to one-up each other.


But that’s what previous browser wars also were about: one browser implements experimental technology, all websites target it, etc.

Chrome has become the new IE in the meaning that it supports weird special stuff, but sometimes not the official W3C definition, and webapps rarely work on multiple browsers.


The IMG tag showed up before there was a Netscape.

You know that venture giant, the 'A' in A16Z? Long time ago he was marca without the initial 'p', maintained an emacs clone called Epoch, and also hacked away on a web browser called Mosaic:

http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.ht...


You're right, of course, I was mentally mixing up Mosaic with Netscape. I blame old age.


Probably cocaine.


> I wonder about the origins of <marquee>

Probably invented by some lunatic.


Oh yeah, this bit me in a widget I made for a client. But it only bit me once I tried it in Chrome, IIRC. Browser inconsistency, yay :/

I just used an <input type=text> and checked its content upon keydown instead.


Interesting. So is there some quick and easy JS plugin that will auto validate number fields correctly? For instance, I have <input type="number" step="0.25" min="1" max="99">

If I input an invalid entry in Firefox (say 101, or 25.11), FF will highlight the box red. In Chrome it does nothing. Both allow me to submit that data just fine.


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.


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.


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!


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!


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


Image maps were the best. We could have a clickable map of the U.S. that was fast-loading, cross-browser compatible, and did not require a plugin. What's not to like?

Today the way to do that is with javascript libraries like D3.js, which handle both drawing the map and detecting/directing clicks. That was not an option 8 years ago; javascript was too slow.


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


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


Imagemaps were fun ages ago - and animating imagemap menus with javascript was even more fun.

No one would bother with such things today when CSS has animation and whatnot.


I actually did, but only with <map>, never <input type=image>.


I may or may not have used this in 2007 on a map of the counties of NY state. Perhaps a decade later than I should've, but it works well to this day!


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.


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.


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


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?).


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.


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/).

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.


Heh. Start by finding a perfectly architected system.

Oh, there aren't any? Then jordanlev's idea of the only possible way to create one is, shall we say, purely hypothetical.


you're being unnecessarily literal- we can use variable values for "perfect", most of which are clearly better than the system explained in the article.

but, if we must be so literal, i'd say you're not using your imagination. you think a literally perfect architecture is impossible? some systems are very small, you know.

that all said- they never even concretely suggested one existed in the first place. you could infer a hypothetical from their post.


I don't think that helps. I think that, if you use variable values for "perfect", and you turn the value down to the point where you start getting systems (more than one) that are considered perfect, then by that time you get some that come from corporations, and some that don't.

I think jordanlev is committing the opposite fallacy of the one RyanZAG made. RyanZAG said "companies have produced badly-architected dreck", which is true but doesn't disprove jordanlev's point. But jordanlev looks at web standards and says "open standards can only produce dreck", which is also logically wrong.

As a minimum level of validation for jordanlev's position, I'd like to see someone name the systems that corporations have produced that are above the standard of perfection that has ever been achieved by open standards.


hey, i never said i could prove he was right. :) you make a great point.

edit: i assume his point could be better articulated as "open standards have only produced dreck".

which leads back to my original post: "to counter, you'd need to find an example of a perfectly architected system developed as an open standard by multiple companies".


Sheesh guys, way to take a philosophical mental exercise and sap all the fun out of it!


You're welcome.

;-)


What's with people using Win32 API as a negative example all the time? It was verbose, but quite good even compared to the stuff you have to deal with in 2015. Sure it wasn't hot-sexy-object-oriented and you often had to pass 20 unused params, but at least it was somewhat consistent and documented, not to mention powerful.


Because it's not good. It is neither consistent ("CreateWindowEx" style naming versus "Shell_NotifyIcon" versus "CDefFolderMenu2_Create2" (huh?) versus "CreateToolhelp32Snapshot" (huh?!) versus COM), documented enough to engineer independently (witness all the strange behavior Wine has had to reverse engineer), or powerful (fork is officially unsupported, despite being supported by the NT kernel).


You're looking at a code-base that evolved from 16-bit to 32-bit to 64-bit over 25-30 years, and 10-15 major releases. You've got the 95/98 code base merging with the NT code base. You've got all the compatibility fixes that Microsoft has invested in to try to help old, poorly written code continue to work. It's accreted some cruft.


I'm not blaming anyone for the APIs being in the state that they're in. I'm simply saying that the Windows API is, today, taken as a whole, a more crufty API than the Web APIs are.


One common factor between the web and win32 is backwards compatibility. Committing to backcompat is awesome and important, but it does mean that every bad idea that gets wide use must be supported for a very long time.


Well, Microsoft is more like several companies (often with conflicting interests) operating under the same umbrella. This is well-documented.


> 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"

I think that's a mistake. While open standards create forces which tend to produce certain architectural misfeatures, being a controlled tool for a single company does to. Its just a different set of forces working against ideal architecture between the two cases.

Though, while different, overlapping. And, in the case of <input> and other web standards, the big problem is also common in single-source systems: compatibility (e.g., backward compatibility with previous systems that aren't perfectly architected for the current use case, for whatever reason -- with an open spec system that may because someone just went off spec and got popular anyway, with a closed system it might be with an older system with a different purpose that ended up being popular in the domain for which the new one is designed.)


Yeah, I see your point (and the other replies to my comment).

I certainly don't mean it as a guiding principle on how they should build software, but rather as a way to get them to think about trade-offs and realize that nothing in the real world is perfect. (These students are often fresh out of high school and still in the mindset of "the world doesn't make sense but surely that's just because I'm young, and these older people must know what they're all doing" :)


I disagree with your premise that one company being in charge of something makes it more internally consistent. You might have consistent implementation if one company does the only implementation of a standard, but the standard itself may still be completely riddled with inconsistencies. See: any product of sufficient complexity.


Gotta disagree - Unix etc. are open, built by consensus, and have very good APIs. HTML / CSS for some reason is a clusterfuck.


> Gotta disagree - Unix etc. are open, built by consensus, and have very good APIs.

No, those APIs are not good (or, at least, not obviously better). The POSIX API has just as many ugly corners as the Web APIs do. Look at SysV shm, flock vs fcntl locking, ioctl, cmsg, etc. And that's not even getting into the horrors of Xlib…


Unix was also extremely inconsistent, before the Linux monoculture became dominant. It can still be painful to support BSDs, HPUX, Solaris etc.


It's almost like the competing browser vendors didn't want the spec to work !


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.


I too enjoyed her writing style - quirky, lighthearted and jovial, which in retrospect is odd, since the entire article is basically one big complaint!


Or click on the little party horn.


Check the source for an image too.


Would that be the squirrel? Which I'm about to steal.

This author was on usethis not so long ago. Funny and probably as sharp as razors to work with (in a good way).


And an emoji used as an element id.


Source: https://github.com/notwaldorf/emoji-selector


Or any link.


I kind of wish there was more suggestion for solution than simply kvetching.


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.


Indeed. There are no good APIs for this.

With raw keyboard events a custom input won't be able to handle autocorrect, Japanese nor Chinese input. There's only draft of a Web IME API, but it still assumes you have a real `<input>` element.


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.


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


Custom elements can have their own JS apis! They're not just for style. Check it: http://www.html5rocks.com/en/tutorials/webcomponents/custome...


Sure, and that's cute, but now make me an API that picks a file from a user's hard drive – or a photo from the photo roll. Yeah.

My point isn't about putting JS on to DOM, that can be done without web components too. Rather, it's about the lack of proper access to input devices, actual data that matters.


You just said they help the presentation differences of these controls, so they solve some of this, even though they bring a different set of problems.

The JS API isn't that bad as everyone makes it out to be, especially since Microsoft is getting more standards compliant. And where it is bad, we see things like jQuery spring up, that solve more than the original problem (perhaps too much, but that's easier to fix than the browser differences).

Perhaps you might define "proper" and provide any compelling examples how the current APIs aren't up to snuff, besides not being able to programmatically select text in a number element and unused checked properties. I'm curious.


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.


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


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


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.


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

[1] https://hacker-news.firebaseio.com/v0/item/10433793.json?pri...


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.


Yes, you're right.


CommaFeed has similar problem.

http://imgur.com/Bijmmuh


Same issue on Android: http://i.imgur.com/FKPvJsq.png

Time to avoid /newest.


Oh boy...


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.


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


I wouldn't be that upset about the styling limitations if we at least had a reasonable way to give it a size. The common workaround is pretty nasty: http://www.quirksmode.org/dom/inputfile.html


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?


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


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


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


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


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


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


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!


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


The author of the article actually works at Polymer.


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


Edge and Firefox are getting native shadow dom too!


Wait, can you use Polymer components? I was under the impression they still didn't work on mobile browsers. Our did they finally fix that?

For now I use Material Design Lite. All the beauty of Polymer without the framework forcing you to do all that weird stuff.


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


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

Screenshot: http://i.imgur.com/FKPvJsq.png

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


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.


  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.


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


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.


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... [type]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...


So why does it default to a value of false in her example? Shouldn't it return undefined if that were the case?


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?


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?


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.


I don't understand why the author persists with...

Maybe she is writing for a more general audience, with a goal of Resistance is Futile, You Will Be Assimilated?


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


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.


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


Well? Are you not entertained?


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


The mouseover link colors on this site...


Damn, that's some great writing. :)


This makes me want to dive in deeper


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

Nah, let's not :P


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


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


Great article.

Though links on that site can produce headache..


her page is all bubbly and cute


It's also a good read.


And really nicely designed/styled


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.


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


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


Welcome to web development!


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.


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


Rant - speak or shout at length in a wild, impassioned way.

The article didnt seem like a rant to me. These are all valid criticisms of the built-in form elements.


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.


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


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.


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


Yeah, I'm having a blast with p5js, which is basically JavaScript and a lot of built-in functions to make it easy to work with a canvas.

Writing actual website though? No thanks.

http://p5js.org/


I'm sorry to say this, but that site is horrible. It's almost blinding, the colors should be toned down.


As someone who has been working in JS for, oh, since it was invented: no, JS as a language definitely sucks.


Javascript as a language totally sucks.


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


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: