html
html copied to clipboard
whatwg
Fix #4562: add support for internationalized email addresses
Changes the ABNF and surrounding text to match what current browser implementations do, which includes support for non-ASCII characters on both the left and right side of the email address. Discussion in #4562 includes the genesis of these changes.
- [ ] At least two implementers are interested (and none opposed):
- Firefox (edit by @annevk)
- …
- [ ] Tests are written and can be reviewed and commented upon at:
- …
- [ ] Implementation bugs are filed:
- Chrome: …
- Firefox: …
- Safari: …
(See WHATWG Working Mode: Changes for more details.)
:boom: Error: Wattsi server error :boom:
PR Preview failed to build. (Last tried on Jan 15, 2021, 8:00 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
:rotating_light: Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
:link: Related URL
<html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.
@domenic is it really needs implementer interest if it documents what browsers currently actually do? I see that the issue has this tag, but I don't think it's accurate.
I wasn't under the impression that this was what browsers do. For example it doesn't seem to match https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/forms/email_input_type.cc;l=47-53;drc=1dea8d7ba92cfec5e553d3a4699115b1dc8dd707 . Web platform tests would certainly help, in any case.
As I documented in the issue browsers currently have somewhat different behavior, but none seem to allow non-ASCII before @, so that alone would be a significant change that is subject to https://whatwg.org/working-mode#changes. I do think it's a change worth making however.
@domenic, @annevk You're right. I was having a brain cramp--I spent time testing the right hand side and neglected the left-hand side (which we are changing here).
Would it make sense to break this into two PRs? One to fix the current misalignment of the spec with support for IDNs and one to fix 4562?
(clicked the close button by mistake)I think that would be good, although I'd suggest before writing any spec text, writing web platform tests.
Currently, the spec text evidently isn't clear enough for the domain part, since Blink, Gecko, and WebKit all do different things. My reading of the current spec text is that it best supports what Blink does. However, https://www.ietf.org/archive/id/draft-ietf-emailcore-as-09.html#name-use-and-validation-in-html- ends up attributing what appears to be just the WebKit interpretation as a general HTML problem.
The current PR does not make things as clear as I'd like from implementor perspective.
I think it would be good as basis for discussion if the upcoming PR update took a position on each of the questions I listed on the issue. (As noted there, I think specifying Blink's general approach of replacing the domain with the ToASCII form when the ToASCII operation does not raise errors is the least risky way forward. I do think tweaks are needed to the Blink specifics. In particular, I believe UTS 46 processing needs to be run in the non-transitional mode like Blink, too, does for URLs.)
