| 00:21 | <jmdyck> | Recently added to the HTML spec, "A new {{CustomElementRegistry}} object." (x2) is odd. Shouldn't they be "a new <code>CustomElementRegistry</code> object"? |
| 04:45 | <Domenic> | annevk: thoughts on https://github.com/whatwg/fetch/pull/1820 appreciated. |
| 06:13 | <annevk> | jmdyck: ouch. Will fix. |
| 06:13 | <annevk> | That's what you get for editing DOM and HTML at the same time. |
| 06:19 | <annevk> | Domenic: oh, I think I gave a review of what you already surmised, oops |
| 06:19 | annevk | thinks a bit more |
| 06:20 | <Domenic> | Maybe I just need to audit all uses... |
| 06:21 | <Domenic> | A lot of cases seem to be misusing request's window when they should be using its client |
| 06:22 | <Domenic> | A lot of others are just setting window to no-window |
| 06:23 | <annevk> | The latter is fine. The former I agree with is likely wrong. But I do think we want something like a Window object here, not just an abstract reference to a tab. |
| 06:23 | <annevk> | When we present something to the end user it's important that the end user can attribute it to a particular origin. |
| 06:23 | <Domenic> | Hmm, curious to learn why |
| 06:24 | <Domenic> | Well I see you commented on GitHub |
| 06:25 | <annevk> | End users need to be able to blame the address bar. If we end up showing a dialog for an unrelated website, we've done it wrong. |
| 06:25 | <Domenic> | The navigation case seems tricky though because do we really want to associate browser UI navigation with the previous Window object that just so happens to be in this tab? |
| 06:26 | <annevk> | Yeah that is a tricky case and I doubt we'd want to use the previous Window. It probably needs to show a blank page or something beneath the authentication dialog? |
| 06:26 | <Domenic> | I mean in practice it'll show the previous page beneath it in the actual UI. But it might influence the contents of any dialogs, in theory. |
| 06:27 | <annevk> | Are you sure that's what happens for this case? That would seem quite confusing. |
| 06:27 | <Domenic> | I'm about 90% sure, will try to reproduce |
| 06:28 | <Domenic> | Wooooah you're right. Go to https://example.com, then open https://labs.w0s.jp/http/authorization/basic/ . |
| 06:29 | <Domenic> | OK so... maybe introduce a third value, "browser-ui-navigation" or something? And then let that show WWW-Authenticate dialogs, etc., with a special callout to blank out the page or similar? |
| 06:49 | <annevk> | Yeah, something in that direction seems reasonable. Though it might also be subject to a same-origin check I suppose. |
| 06:50 | <Domenic> | Right, testing does show that to be the case, OK. Will give it a shot. |
| 07:47 | <acr> | unsure whether i should ask here, but im submitting request for standards-position to ffox (done already) and webkit, should i first check with anyone that it's an ok write up / context , or just file it? |
| 07:49 | <annevk> | Just don't deviate from the template provided. |
| 08:15 | <acr> | Do you prefer the description as done here? https://github.com/mozilla/standards-positions/issues/1215, or less verbose? |
| 08:29 | <acr> | annevk: i can add you as webkitten or whatever as well, if that's an issue you want to comment on, otherwise ill add marcocaceres i think, which may have an opinion about the privacy concerns, iiuc. (spec has a single paragraph about it though, from what i remember) |
| 08:48 | <acr> | done |
| 14:27 | <Ms2ger> | So, a fun (sort of) question: the resource selection algorithm says it's always run from a task, but it uses Await a stable state which starts "When an algorithm running in parallel is to await a stable state...". Does that mean there's a step missing to go parallel before awaiting a stable state? |
| 14:50 | <annevk> | Ms2ger: yeah, there's potentially more borked as well. There's an issue tracking trying to get rid of "await a stable state" |
| 14:58 | <Ms2ger> |
|
| 14:59 | <Ms2ger> | Thanks for the pointer :) |
| 23:36 | <akaster> | The real question is did you find a bingo winner of an issue? https://bingobaker.com/view/8880946 |