| 12:06 | <hsivonen> | I think it's a description of how WebKit interpreted what HTML says. Arguably, the HTML spec text supports better what Blink does, and to construe the IETF draft concern to cover Blink, one would have to assume it to mean Blink using the transitional mode for input type=email. As for the on-issue discussion, so far, I'm failing to steer the discussion to my specific questions about the rules. Evidently, the current spec text isn't clear enough about "the rules", since Blink, Gecko, and WebKit all have different interpretations. |
| 12:11 | <hsivonen> | Anyway, it's bad that Hixie didn't write down the rationale for making up non-RFC local-part syntax. My findings from today are: 1) Fastmail front end does not reject consecutive dots but back end refuses to go through with sending. 2) Apple Mail app warns about consecutive dots but allows the user to send anyway. 3) iCloud back end tries to send out consecutive dots. 4) Gmail rejects incoming consecutive dots despite ignoring the dots in mailbox matching for RFC-compliantly-dotted incoming addresses. |
| 12:13 | <hsivonen> | Since, Fastmail gets away with refusing to send to addresses with consecutive dots, being able to send to consecutive-dot addresses probably isn't a competitiveness-level mail-compat issue. Since the Apple stack enables sending to addresses with consecutive dots, it's not the case that email software would universally block consecutive dots. |
| 12:45 | <annevk> | hsivonen: what I find frustrating is that instead of talking about non-ASCII addresses, we keep getting dragged into discussing the subtleties of the ASCII rules, which impact an even smaller subset of end users. Given that multiple providers reject consecutive dots today I would be somewhat inclined to stick with that, but I could be persuaded I suppose. (I could see how they could lead to spoofing issues of sorts.) |
| 13:59 | <hsivonen> | I thought that it was relevant to deal with if we're taking the time to change implementations of the local part, but I guess it was unconstructive that I mentioned the dots in my list of questions. Sorry. I skipped that question in my follow-up to your domain-part answers. |
| 14:02 | <annevk> | hsivonen: oh, that criticism wasn't necessarily aimed at you. It's been a somewhat recurring theme of the thread. |
| 14:29 | <freddy> | annevk: Given the holiday in Germany this Thursday, are you attending the WHATNOT meeting? I'm interested in the agenda item about integrity, but would propose the meeting topic will be postponed... https://github.com/whatwg/html/labels/agenda%2B |
| 14:33 | <annevk> | freddy: no I declined. I'm taking Friday off too. |
| 15:02 | <freddy> | Panos Astithas: Hi!, can we please postpone the integrity agenda item from WHATNOT this week? ☝️ |
| 15:27 | <Panos Astithas> | Of course, I'll carry it over to the next meeting unless you tell me otherwise. |
| 15:34 | <freddy> | wfm |
| 20:23 | <smaug> | keithamus: this is still a very vague idea - but somehow bind invoking to pushState (or I guess session history in general). The idea being that going back could trigger some invoketarget with a certain action. (This all to make things more declarative) |
| 20:54 | <keithamus> | Interesting… can you say more? |
| 21:22 | <Richard Gibson> | I think I disagree with this reasoning; the question of "which element experienced the event?" is answered not by failing to bubble but by the target property. Failing to bubble just makes delegation difficult for generally no good reason (as is the case for e.g. <details> toggle) |
| 22:00 | <Luke Warlow> | keithamus: this is still a very vague idea - but somehow bind invoking to pushState (or I guess session history in general). The idea being that going back could trigger some invoketarget with a certain action. (This all to make things more declarative) |
| 22:37 | <zcorpan> | smaug: maybe CloseWatcher integration is better suited? |
| 22:41 | <smaug> | Some URL stuff might work, since that works with session history. And yes, possibly like with dialogs, but also for other (not yet defined) declarative features |
| 22:43 | <zcorpan> | smaug: https://html.spec.whatwg.org/#close-requests-and-close-watchers |
| 22:43 | <zcorpan> | or maybe I don't follow :) |
| 22:43 | <smaug> | Not sure that works with random declarative stuff. I want something which can take the page back to some earlier state without any use of JS |
| 22:49 | <Luke Warlow> | BFCache does that to some extent. But yeah it'd be interesting to have a way to codify URL -> "app" state |
| 22:49 | <Luke Warlow> | Having said that I think the pattern of using URLs for dialogs was partly a result of the lack of a close watcher API. |