| 08:00 | <annevk> | The GitHub hover popovers actually make text selection impossible. Try to select the username of the last commit shown on https://github.com/whatwg/fetch. It's not possible and breaks down differently in each browser. |
| 08:42 | <Luca Casonato> | Works for me in Chrome on Linux. |
| 08:43 | <annevk> | It's not jank if you do it slowly and the dialog pops up while you're doing it? |
| 08:44 | <annevk> | It's definitely jank here. There's ways to workaround it, but it's not a great experience. |
| 08:45 | <annevk> | emilio: could whatwg/dom/dom.bs be added to Searchfox as well? I just got "Your blame took too long to compute." from GitHub. :-( |
| 08:47 | <emilio> | annevk: I don't see why not... Add a whatwg-dom dir in https://github.com/mozsearch/mozsearch-mozilla/ much like whatwg-html? |
| 08:48 | <annevk> | Anyone willing to volunteer? For various reasons it'll be hard for me to make that contribution. |
| 10:45 | <zcorpan> | TabAtkins: I got a linking error for the quirks spec:
Having epub squat on HTML element names doesn't seem ideal? |
| 13:33 | <TabAtkins> |
|
| 13:57 | <annevk> | I wasn't entirely sure as it seems they do in fact define a language that defines similar elements but they are not the same elements? And so I wasn't sure what to recommend them. But maybe we should file an issue anyway? |
| 14:24 | <annevk> | Interesting, neither Chromium nor WebKit seem to really implement the keep the global around for initial about:blank? Or maybe there are more ways to reset "is initial about:blank" than the specification suggests? |
| 14:32 | <annevk> | https://github.com/web-platform-tests/wpt/pull/51895 has my test. This result makes some sense to me as at least in WebKit the script environment is heavily intertwined with the navigable document. But maybe it's more subtle somehow? |
| 15:12 | <annevk> | TabAtkins: so it's https://www.w3.org/TR/epub-34/#sec-smil-body-elem which is a separate body element |
| 15:12 | <TabAtkins> | Oh, hmmm |
| 15:12 | <annevk> | TabAtkins: so maybe we need some additional namespacing to distinguish the various elements? |
| 15:14 | <TabAtkins> | I mean we could put for=html on everything |
| 16:10 | <Simon☀️> | Does anybody happen to know what exactly Chrome is doing here: https://github.com/whatwg/html/issues/8013? People keep reporting this as a bug to Firefox annoyingly often. |
| 16:31 | <annevk> | Dominic Farolino: I noticed you didn't review all the <select> PRs. I don't think it's a good idea to merge only some of them. I don't think that's an "end" state anyone really considered. |
| 16:42 | <Dominic Farolino> | I don't think it's an "end" state. The parser PR is ready and approved by Simon, and the last open thread is done from our perspective. I haven't finished reviewing https://github.com/whatwg/html/pull/10629 but I think having it fast-follow seems fine to me. We'd love any reviews you might have time to submit though. |
| 16:46 | <annevk> | I left a number of comments. There also appear to be inconsistencies between the PRs. I do think all PRs should land within a couple of hours from each other. |
| 17:45 | <Luke Warlow> | I don't think the parser change itself need be reliant on the rest right? It would seem okay for a browser to ship the parser change today and ship the rest of appearance base-select in future? |
| 17:48 | <Luke Warlow> | I don't think the parser change itself need be reliant on the rest right? It would seem okay for a browser to ship the parser change today and ship the rest of appearance base-select in future? |
| 21:27 | <jarhar> | In order to show how all the select PRs can be merged, I merged them all myself into one and put it here: https://github.com/whatwg/html/pull/10548 There were a few merge conflicts that I resolved. |