The Sad State of HTML Email Input Fields and IDNs
grepular.com
grepular.com
In that case, it varies so much across browsers to be almost unusable. Some (like Firefox) don't seem to support the calendar aspect, some have a terrible calendar UI, some fallback to the device calendar UI, some let you select invalid dates despite greying them out and that's before you get to the actual data, how it's formatted or the lack of any events associated with the fields.
Honestly, it seems like today's browsers just can't seem to handle any of the newer input types in any reasonable way.
I’ve got a version of Chrome here that, if you query with .value from JS the value of a datetime-local field, returns you a String in "MM/DD YYYY" format. Despite the user’s locale being de_DE.
I’ve also discovered one browser only supporting ISO8601, and another only support it if one removes the time section of it. Another only if you have a time section, but remove the time zone part at the end.
It’s such a horrible mess.
Surely you're not suggesting that the representation of the date that is returned by the browser should be locale-dependent? That would be a nightmare.
At least when it’s locale-dependent I can use a look up table and parse it somehow, but getting it back in MM/DD YYYY?
I’d love to just get ISO8601 ideally, btw, but who knows if that will ever happen.
(Also, you should check out Microsoft Excel, its date type and CSV converter are both locale-dependent. Locale of the program opening the file, not the file itself. A file created in de_DE will be unusable in en_US)
User side: just show/accept whatever the site owner wants, or if it's too difficult, stick to ISO 8601 (it's the standard, damn it).
JS side: just ISO 8601.
Id est: use max="100000". Then on one IE/Edge 16000 is an error but 15000 is OK. Different IE/Edge box its 18000 cap.
I have to make a custom UI component to make this work (riotjs)
Now, I also happen to be working on refactor of our Intl code, so I should be able to help with the number field being inconsistent. If you can file a bug and prepare a minimized testcase, I'd be happy to fix it! :)
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=888320 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1069609
https://www.w3.org/TR/html5/forms.html#e-mail-state-(type=em...
User agents may transform the value for display
and editing; in particular, user agents should
convert punycode in the value to IDN in the
display and vice versa.
Which isn't to say this isn't a thorny problem; more discussion of the issue here https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489
I disagree with that. Neither the client nor the server need to know anything about punycode. The only time punycode is required is at the very last moment when it comes time to actually send an email to that address. Whether it's the email sending library or the mail server it's self, it doesn't matter.
A user should be able to type "person@ü.example.com" into a form. I should receive "person@ü.example.com" on the server side. I should save "person@ü.example.com" to the database. I should be able to send "person@ü.example.com" back to the browser for display, and I should be able to pass "person@ü.example.com" as the To address to my mail sending library.
Punycode is an implementation detail that I shouldn't need to think about.
I'd also agree that my code should be able to handle unicode, for a different reason: I never trust validation by a browser (old clients, bad clients, malicious clients)
The "." in a domain name is no longer always a period. It can be any of
U+002E ( . ) FULL STOP
U+FF0E ( ． ) FULLWIDTH FULL STOP
U+3002 ( 。 ) IDEOGRAPHIC FULL STOP
U+FF61 ( ｡ ) HALFWIDTH IDEOGRAPHIC FULL STOP
1. Validation
2. Autofill hints
3. Native helper widgets (date calendar, number input spinner)
4. Mobile keyboard layouts
And, confusingly, while most `type`s are text inputs with differing values of the above, others are very, very different (radio, checkbox, select, file, etc). Still others use completely different tags (like <textarea>) and you even have to switch on `value` or `checked` for checkboxes.
Many people use `type="tel"` or `type="number"` just for the mobile layouts, and spend a long amount of time working around all the awful bugs in number inputs. Our own `<NumberInput>` React component works around multiple browser bugs and took weeks to get right. The incidental complexity even creates very hairy React bugs (https://github.com/facebook/react/issues/7253).
Even if you get around all the bizarre failures in differing implementations, you still have ridiculous spec bugs like the (intended) lack of selectionEnd/selectionStart on number inputs (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24796) and the like.
I don't know if anyone is championing splitting these concerns into separate attributes, but the web really needs it.
The real problem here is all the systems we use are more complex than people realize. Things like names (http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...) & time (http://infiniteundo.com/post/25326999628/falsehoods-programm...) just cause issues that most developers will end up just ignoring, because in the end its just edge cases that will happen maybe once or twice, ever. Why put in the effort?
So strictly speaking xn--p38h.ws is not an IDN, and Google is doing the right thing by not allowing it. This doesn't make your job any easier, of course.
If you really want to explore this rabbit hole some good reading. RFC 4290 RFC 5891 RFC 6912 RFC 7940
Gmail for example still allows me to email myself at \u1F63B.*.com or xn--238h.*.com
You can see the complete list of characters here:
ftp://ftp.unicode.org/%2F/Public/idna/8.0.0/IdnaMappingTable.txt
"The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born."
Sometimes we need someone to enforce standards, and not just say "anything is valid".
We need the W3C again.
1. Better detection of the platform than I can do myself. That leads to a UI targeted at the platform (different default phone keyboards, etc).
2. Uniform UIs across websites. I hate having to learn a new calendar widget on every website, it's worse for regular users, not to mention any users that need accessibility features that are prooobably not included in most home-rolled (or even popular) widgets.
3. Basic validation. Just to help the user a bit. I'll validate it again on the back-end, and I might even be validating it myself on the front-end. But basic validation helps and, once again, that uniformity thing shows up again here since the user could be aware of how that widget reports errors on their platform already and could be looking for them.
The niggling part that doesn't is where we decide where our level of abstraction is. It can be very convenient to be able to declare what the type is. If you don't do it in the markup, you're likely going to want this in some kind of library. And that library will need to be extensible or you've just shifted the problem, and now it's the library. So that part of it needs to be well thought out and portable. But in the end, I do think that the solution is more tractable in logic rather than markup.
Though maybe markup tries to do too much. Look at all the additions to HTML5. It's great to be able to express so much more in the markup. Yet there are still going to be times where you're going to come across a situation that doesn't fit neatly into the existing elements. So you're going to add some extra domain-specific meaning to the markup you're using. You can work around this with class attributes, but that's just it: it's a work around.
Enough rambling.
I think there's a corresponding issue with display and behavior and the intersection of markup, CSS, and JavaScript, boiling down to inadequate separation of concerns.
Note that nobody actually wants to embed the code for validation within the document, but you want to be able to properly identify a form-elements attributes so as to allow clients to make a smart choice about validation, presentation, defaults etc.
JPEG decoding is also logic, but it's also pretty useful for client to know that the binary stream it's reading may best be handled with the jpeg library.
We've occasionally had an unusual but syntactically correct address cause problems in the past because it wasn't processed properly, but we get problems with people who have accidentally mistyped their address when signing up and then can't log in to our systems all the time. If you have a system where the email address is the primary ID for a user's account and you're charging real money, this is not a trivial problem and it does not have a simple solution: requiring active confirmation at sign-up time does horrible things to conversion rates, but anything else is potentially vulnerable to security issues later.
Only the local part of an email address potentially being case sensitive causes us more headaches in this area today.
servers that have case sensitive mailboxes are more likely to be used for throwaways or the user may control the server anyways so they could still respond to normalized local parts
as for verifying the email at registration you could check to see what the remote smtp server responds to when you issue the RCTP command to check if they consider the email valid
We could normalise, and as far as I'm aware none of the largest e-mail services allow distinctions based on case so most of the time it would be OK. It would still be a security risk, though.
as for verifying the email at registration you could check to see what the remote smtp server responds to when you issue the RCTP command to check if they consider the email valid
You can, but many servers including some of the major services will just return a false positive for any mailbox to prevent that technique being used to collect addresses to spam, and even those that don't may consider such requests when not followed with a real message to be a black mark on the sender.
2. One customer requested the ability to enter decimals in a field, but to keep up/down spinner in steps of whole numbers. You can't do that, the step attribute makes any values other than (min + N * step) invalid. I can see some sense in that, but I think the step attribute should only affect the increments/decrements done by the spinner, not completely reject certain values. (Though you can use step=any to mark all values valid and step by 1.0, which is good enough for common cases.)
The user thinks they have typed in something valid, but JavaScript (or value from form submit) only gets to see "". E.g. use a thousands separator or paste in a trailing space and you will get an error "input must not be left blank".
There are worse issues with the less common input types.
Of course it's a valid choice, but many people will consider this a serious issue.
It would also be very useful if the validation is extensible, as different projects require different validation rules.
I'd also want validation rules that are portable between the client and the server to reduce code duplication.
One combination I've been toying with is using clojure.spec[1] with ClojureScript/Clojure with varying levels of success. I imagine you can do similar things using server-side JavaScript.
> we should use another technology to do other things we've been commandeering it to do.
What types of things are you thinking of?
http://www.w3schools.com/html/tryit.asp?filename=tryhtml_inp...
the firefox implementation will gladly accept the invalid test.@example.com but won't accept the valid "test"@example.com
this is just a case of poor validation which we are now stuck with
As such, it's just not a good idea use one for now.
As an aside, I don't even know why IDN's are allowed, it offers too many opportunities for domain spoofing and phishing.
IDNs will take years to be pervasive, just like Unicode before it, because it is a painful upgrade to something designed in a different era. It doesn't mean the endeavour isn't worthwhile.
You know that statement clearly is not true. Just look at keyboard designs used the world over.
I know English is increasingly pervasive, but there are still billions of people who don't speak it at all or speak it only very poorly (and it's not exactly very easy to learn). The internet is a global network, and so should allow people to communicate easily in their own languages. This current pain with IDN is just a legacy of the internet's origins in America and Western Europe.
Heck, the example in the article are just using one letter found in German. You don't need to go very far from English to find these problems.
www.cítíbank.com
instead of
www.citibank.com
a very real problem and will make the web more dangerous and will encourage the further growth of "walled gardens" on the internet which I think most here agree is a bad thing.