18 ms·
A story about <input>
- jordanlev 11y agoYeah, 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.
- tejaswiy 11y agoGotta disagree - Unix etc. are open, built by consensus, and have very good APIs. HTML / CSS for some reason is a clusterfuck.
- toyg 11y agoUnix was also extremely inconsistent, before the Linux monoculture became dominant. It can still be painful to support BSDs, HPUX, Solaris etc.
- SixSigma 11y agoIt's almost like the competing browser vendors didn't want the spec to work !
- pcwalton 11y ago> 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…
- RyanZAG 11y agoArchitected 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 11y agojordanlev 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
- AnimalMuppet 11y agoHeh. 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.
- catshirt 11y agoyou'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.
- AnimalMuppet 11y agoI 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.
- ebbv 11y agoI 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.
- dragonwriter 11y ago> 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.)
- jordanlev 11y agoYeah, 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" :)
- sosuke 11y agoReally 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 11y ago<input value="In an <input> tag's "value" attribute,�a;you can put any text" />
- ocfx 11y agoher page is all bubbly and cute
- Mz 11y agoIt's also a good read.
- vdnkh 11y agoAnd really nicely designed/styled
- Mz 11y agoI 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 11y agoIt 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 11y ago> 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.
- pavel_lishin 11y agoThat 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.
- gtk40 11y agoOr any link.
- junto 11y agoI too enjoyed her writing style - quirky, lighthearted and jovial, which in retrospect is odd, since the entire article is basically one big complaint!
- workergnome 11y agoOr click on the little party horn.
- talhoffer 11y agoCheck the source for an image too.
- keithpeter 11y agoWould 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).
- gk1 11y agoAnd an emoji used as an element id.
- spurgu 11y agoSource: https://github.com/notwaldorf/emoji-selector https://github.com/notwaldorf/emoji-selector
- dclowd9901 11y ago
- deleted 11y ago[deleted]
- methyl 11y ago> 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 11y agoShadow DOM is there in Chrome and might soon be added to WebKit. I personally don't think they will last.
- rictic 11y agoEdge and Firefox are getting native shadow dom too!
- runn1ng 11y agoThe author of the article actually works at Polymer.
- odbol_ 11y agoWait, 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.
- methyl 11y ago> 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.
- grayrest 11y agoI always considered the quiet years up until 2005ish. After that we had XForms and the WhatWG hijincks to keep the web nerds entertained.
- nathancahill 11y agoWell? Are you not entertained?
- peterwwillis 11y agoApparently 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 11y agoI would say that Javascript as a language doesn't suck, but many of these old browser API's do.
- MichaelGG 11y agoCrazy 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 11y agoAt least the scoping and verbose lambda problem have been solved in ES6, with the introduction of let-vars and fat arrow functions, respectively.
- vanderZwan 11y agoYeah, 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/ http://p5js.org/
- oblio 11y agoI'm sorry to say this, but that site is horrible. It's almost blinding, the colors should be toned down.
- moron4hire 11y ago
- LukeShu 11y agoHey HN staff, there's a bug here: body shows fine, but the title renders as "A story about <input>"
- recursive 11y agoI'm seeing this as well. The served html says <title>A story about &lt;input&gt; | Hacker News</title> It looks like it got double encoded.
- nathancahill 11y agoFunny, 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?print=pretty https://hacker-news.firebaseio.com/v0/item/10433793.json?pri...
- natzim 11y agoOh boy...
- deleted 11y ago[deleted]
- szatkus 11y agoCommaFeed has similar problem. http://imgur.com/Bijmmuh http://imgur.com/Bijmmuh
- scintill76 11y agoThe API is returning "title" : "A story about <input>" for me. I don't consider that correct encoding, as "<" 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.
- idbehold 11y agoShe 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!
- STRML 11y ago<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.
- Keats 11y agoAny plans on open sourcing yours?
- nmjenkins 11y ago> 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.
- idbehold 11y agoI don't believe that will work since the input.value will become an empty string before you can do your replacement.
- draw_down 11y agoWelcome to web development!
- destructionator 11y agoThe <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 11y agoI 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 11y agoYou obviously never had the misfortune to deal with image maps - the Ramsey Bolton Bastard brother of Flash. :-)
- MichaelGG 11y agoThey were very popular before that. I recall finding great use for them around 97. Easiest way to have complicated graphical navigation.
- junto 11y agoAll was find until you had to define clickable areas as polygons. Urrrrgh.
- snowwrestler 11y agoImage 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.
- krapp 11y ago
- mschuster91 11y agoWhat'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.
- rch 11y ago> 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.
- ShirsenduK 11y agoI'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 11y agobecause of "rants like this" open standards evolve and these issues gets fixed, otherwise if nobody ranted - nothing would have been fixed
- vatotemking 11y agoRant - 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.
- mstade 11y agoFun 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.
- webXL 11y agoYou 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.
- rictic 11y agoCustom elements can have their own JS apis! They're not just for style. Check it: http://www.html5rocks.com/en/tutorials/webcomponents/customelements/ http://www.html5rocks.com/en/tutorials/webcomponents/custome...
- mstade 11y agoSure, 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.
- pornel 11y agoIndeed. 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.
- p4bl0 11y agoOh, it seems Firefox still has this bug that "<" and ">" and rendered as-is in the window title bar and tab title and not as '<' and '>'.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- LukeShu 11y agoIt's not a bug in Firefox, it's a bug in HN, it's double-escaping the <title>.
- p4bl0 11y agoOh 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!
- oneeyedpigeon 11y agoThis 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 11y agoAnd 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.
- Mz 11y agoI 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?
- yashafromrussia 11y agoThis makes me want to dive in deeper
- crankin 11y agoOpening 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 11y agoYeah, see my comment above. Got a screenshot of it.
- crankin 11y agoThe HN iOS app actually displays an input field for a brief second in the title of this article. Anyone else notice that?
- vito 11y agoSame 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.
- ksks 11y agoI 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 11y agoI'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.
- myfonj 11y agoAd `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 11y agoBut "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 11y agoIʼ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/HTMLInputElement https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl... [type]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-type https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
- 11y ago
- CM30 11y agoI 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 11y ago<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.
- dlubarov 11y agoI 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 http://www.quirksmode.org/dom/inputfile.html
- Chos89 11y agoGood and fun read. I'd marry her. 10/10
- whoopdedo 11y agoDid anyone else see the title and think this would be about Perl?
- neduma 11y agoI 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 11y agoYeah, me too! Although after reading the article, 'input' is clearly unworthy of being glorified in an Antoine de Saint-Exupéry redux.
- anonymousjunior 11y agoAnd people wonder why there's a 300+ line angular directive maintaining our Credit Card input box...
- gotchange 11y agoJust 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.
- eric-hu 11y agoThat 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?
- deleted 11y ago[deleted]
- greggman 11y agoInput 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 11y agoI'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.
- personjerry 11y agoThe mouseover link colors on this site...
- rfeague 11y agoDamn, that's some great writing. :)
- SchizoDuckie 11y agoNow shall we talk about date pickers? With timezones? And input/output formats? Nah, let's not :P
- al2o3cr 11y agoInput tags are a pain, but the prospect of every designer getting to make up their own UI controls gives me Flash-backs. ;)
- trymas 11y agoGreat article. Though links on that site can produce headache..
- bricss 11y agoIf you stupid its always hard to deal with any API.