A story about <input>
meowni.ca
meowni.ca
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!
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.
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.
User enters: `1245|`
Navigates back: `12|45`
Enters 'a3': `12453|`
Instead of: `12345`
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...
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.
[1] https://docs.angularjs.org/api/ng/input/input%5Bemail%5D
"<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.
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.
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.
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).
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.
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.
Edit: I also signed up for Twitter with that address and the confirmation mail was delivered.
Really? How would you enter a street address into a form consisting of just text inputs?
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.
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.)
"Google Inboxbeta only works in Chrome"
I’d say things are just as bad as before
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.
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...
Probably invented by some lunatic.
The raw Win32 API is worse than the Web APIs.
Windows might not be top-brand chicken, but it's at least poultry.
I just used an <input type=text> and checked its content upon keydown instead.
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.
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.
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!
Thanks for spreading arcane knowledge!
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.
No one would bother with such things today when CSS has animation and whatnot.
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.
There's good and bad APIs from both open standards and closed ones.
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
Oh, there aren't any? Then jordanlev's idea of the only possible way to create one is, shall we say, purely hypothetical.
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 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.
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".
;-)
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?).
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.
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.
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 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.)
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" :)
Bonus easter egg: place your mouse over the author's photo.
This author was on usethis not so long ago. Funny and probably as sharp as razors to work with (in a good way).
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.
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.
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.
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.
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.
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.
<title>A story about &lt;input&gt; | Hacker News</title>
It looks like it got double encoded.
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...
Time to avoid /newest.
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.
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.
For now I use Material Design Lite. All the beauty of Polymer without the framework forcing you to do all that weird stuff.
Screenshot: http://i.imgur.com/FKPvJsq.png
Feels pretty sketchy; I wonder what other kinds of things could be snuck in there.
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
data:text/html,<input id=i type=text checked><script>document.write(i.multiple);i.type='checkbox'</script>
[HTMLInputElement]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl... [type]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
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?
It's nonsense, really. HTML is user-agent-agnostic. User agents have free reign in how they implement controls to suit their platform.
Maybe she is writing for a more general audience, with a goal of Resistance is Futile, You Will Be Assimilated?
Heck, even non webcomponent solutions don't work with non-English languages. AirBnB's message UI breaks with Japanese innput
Nah, let's not :P
Though links on that site can produce headache..
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...
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.
The article didnt seem like a rant to me. These are all valid criticisms of the built-in form elements.
So the web is the same as it was 15 years ago. Still glad i'm not a web dev.
Writing actual website though? No thanks.
And even new APIs suck. Look at the silliness npm encourages people to do.