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...
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.)
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:
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!
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.
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.
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.
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".
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.
> 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.
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…
I too enjoyed her writing style - quirky, lighthearted and jovial, which in retrospect is odd, since the entire article is basically one big complaint!
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.
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.
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.
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.
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].
The 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.
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
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.
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:
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.")
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.
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.
> 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.
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.
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.
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.
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!