| 08:01 | <annevk> | Domenic: you didn't hit submit for your Infra PR review (at least I'm not seeing it) |
| 08:04 | <Domenic> | Domenic: you didn't hit submit for your Infra PR review (at least I'm not seeing it) |
| 11:43 | <jgraham> | Ran into a web compat report yesterday where apparently if a domain looks like punycode (i.e. starts xn--) but isn't valid punycode, Chromium will just treat it as an ascii domain, but Gecko will refuse to resolve it. That seems like the kind of thing annevk probably knows about :) |
| 12:05 | <annevk> | jgraham: yeah, ASCII fast paths, let me look up the issue number |
| 12:07 | <annevk> | jgraham: https://github.com/whatwg/url/issues/438 |
| 12:08 | <jgraham> | Thanks! |
| 12:11 | <annevk> | jgraham: the last comment by timothygu can probably be turned into a WPT |
| 12:11 | <annevk> | Also pinged the UTS46 experts just now to see if we can move it forward a tiny bit |
| 12:31 | <annevk> | In case anyone is interested in some ToASCII spelunking: https://github.com/whatwg/url/issues/603#issuecomment-1377190876 I had forgotten how complicated it is (my write up skips a lot of steps) |
| 12:54 | <annevk> | jgraham: it might be that toascii.window.js covers those cases already btw |
| 13:05 | <annevk> | jgraham: pretty sure they do, e.g., there's xn--a there |
| 13:05 | <annevk> | jgraham: only Chromium-based browsers fail tests there |
| 13:22 | <jgraham> | annevk: https://github.com/webcompat/web-bugs/issues/116505 was the bug report, which is about Chrom[e|ium] allowing access to a site that Gecko does not. |
| 13:25 | <annevk> | Note that Safari also cannot access that domain |
| 13:25 | <annevk> | https://github.com/whatwg/url/issues/543 is a further subtle difference that exists between Gecko and WebKit, whereby Gecko doesn't seem to check the bidi rules, but WebKit does |
| 13:25 | <annevk> | I don't think that's tested currently |
| 13:26 | <jgraham> | Yeah, not saying it's a high priority issue; I don't recall seeing another similar bug report (and no one else did either), just that there's a non-zero number of sites relying on Chromium-specific behaviour here. |
| 13:27 | <jgraham> | (although it's also hard to tell how common it is because we probably get way fewer bug reports from users in regions that are likely to actually use non-ascii domains vs North America / Western Europe) |
| 13:48 | <annevk> | jgraham: it's part of Interop 2022 and soonish 2023 so hopefully that'll help. |
| 13:49 | <annevk> | jgraham: it seems there is existing test coverage, except perhaps for the bidi stuff which I just wrote a comment on. I think that's the last of the IDNA issues. Not as much as I feared really so hopefully this national nightmare will soon be over. |
| 15:41 | <annevk> | jgraham: I'd like to blame you for my "The Bidi Rule" day |
| 15:57 | <annevk> | (On the flipside, if we finally solve the ToASCII side of IDNA due to this I probably owe you something.) |
| 16:02 | <jgraham> | Haha. I'm going to suggest it's your own fault that you're known as "the person who will be interested in IDNA issues" ;) |
| 16:38 | <annevk> | api.csswg.org is down TabAtkins |
| 16:59 | <Dominic Farolino> | Sanity check wanted (annevk or others). The following algorithm style feels wrong to me, do you agree?
Imagine some more rigorous wording, but it's the structure that I'm concerned with. The author is looking for a way to do something like async/await in spec prose, but I think the above is broken because you can't return something while in-parallel, from an algorithm that is not running in-parallel. The second you go off-thread you have a post a task back to the main thread, in which case you're now dealing with callbacks, not a linear return sequence from the same algorithm that returns something asyncly. Does that sound right? |
| 17:00 | <Dominic Farolino> | As I mentioned the motivation I'm gathering here, is that the author wanted to do something like async/await in spec, instead of having a long chain of callbacks all the time. It seems like nothing like that is actually possible though? |
| 17:00 | <Andreu Botella> | The various module and script fetching algorithms are written in an async/await-like style |
| 17:01 | <Andreu Botella> | you could look into those |
| 17:05 | <jgraham> | I think a key question is whether it's actually doing something where the ordering is observable from content. If it is (and I assume something running on the DOM manipulation task source would be) it should probably explicitly use queue a microtask or some other integration. |
| 17:05 | <jgraham> | (but uh, I'm also not an expert here, and so I'd wait for an actual HTML editor to give an opinion) |
| 17:11 | <TabAtkins> | annevk: reported |
| 17:38 | <Dominic Farolino> | The approach there seems to be:
That seems doable and nice. Keeps it linear, but is explicit about posting tasks which are sort of the "callbacks" |
| 17:43 | <Dominic Farolino> | Although now thinking about it more, I'm not really sure if that works for the spec changes I'm reviewing, just because the algorithms that would be broken up by the step 2 all return a specific value, and I don't know if that really makes sense here, since the caller would have to know that the algorithm doesn't return its value synchronously. Like that's the only reason async/await actually works... because async functions always return promises, and there doesn't seem to be a spec infra equivalent |
| 17:53 | <jfernandez> | jgraham: would you mind ack your support for the text about the custom handler automation ? Thanks. https://github.com/whatwg/html/pull/8267#issuecomment-1340331151 |
| 18:08 | <wanderview> | annevk: When you get a chance https://github.com/whatwg/html/pull/8447 is ready for review again. Thanks. |
| 18:08 | <annevk> | wanderview: ta, hopefully tomorrow |
| 18:10 | <annevk> | Dominic Farolino: yeah that initial algorithm doesn't work; the second approach kinda works but I wouldn't recommend it as it's rather confusing |
| 18:10 | <annevk> | Dominic Farolino: just break up the algorithm |
| 18:18 | <Dominic Farolino> | annevk: you mean into a series of algorithms and explicitly defined callbacks? |
| 18:19 | <Dominic Farolino> | I guess people are wondering if there is some async/await spec prose equivalent to avoid the chain of callbacks etc. Seems like no, though |
| 18:31 | <annevk> | Dominic Farolino: yeah not really. At some point we tried to use promises, but that has all kinds of issues as well. We could perhaps define Infra-promises at some point, maybe. |
| 18:32 | <Andreu Botella> | there used to be an informal async/await-like syntax for some of the script and module fetching algorithms in HTML, but it's now been replaced with fetch callbacks |
| 18:33 | <annevk> | Dominic Farolino: to be clear, inside "in parallel" it's perfectly fine to wait on stuff that's happening "in parallel" to that. Gets complicated fast though. |
| 18:44 | <Dominic Farolino> | Yeah that makes sense. The issue is when an algorithm that suspends itself before returning a value.... actually wants to return a value. That doesn't seem valid. At that point you have to "return" the value by calling a callback with said value. In my mind, once the control flow of an algorithm is interrupted by something "in parallel" you can no longer return concrete values from it without some sort of async/await infra |
| 23:31 | <snek> | how do i coax people to review and merge wpt prs https://github.com/web-platform-tests/wpt/pull/36733 |