| 01:54 | <devsnek> | is there a first class name for `document.body.parentElement` |
| 02:10 | <MikeSmith> | devsnek: the document element? the root element? document.documentElement? |
| 02:10 | <MikeSmith> | or otherwise is “first class name” some specific term of art? |
| 02:10 | <devsnek> | MikeSmith: yeah i meant `document.documentElement` |
| 02:10 | <devsnek> | thank you |
| 02:13 | <MikeSmith> | ah OK |
| 02:13 | <MikeSmith> | cheers |
| 03:21 | <Domenic> | annevk: we forgot to pick up the review drafts after the holidays |
| 05:10 | <annevk> | Domenic: ah I can do some today |
| 10:53 | <MikeSmith> | big +1 to the new official slogan the nginx project chose for itself |
| 10:54 | <MikeSmith> | quoted in https://lists.w3.org/Archives/Public/www-tag/2019Jan/0001.html |
| 10:54 | <MikeSmith> | “Nginx does not comply with HTTP/1.1, let alone TAG findings.” |
| 11:56 | <jgraham> | That mail is from 2019? It suddenly feels like 2004 again. |
| 13:04 | <yoav> | Hey y'all! A Bikeshed question. I'm hitting validation issues at https://travis-ci.org/whatwg/fetch/builds/480969414?utm_source=github_status&utm_medium=notification as part of https://github.com/whatwg/fetch/pull/773. I have two <dfn>s with the same name and I'm not sure how to disambiguate them... |
| 13:07 | <annevk> | yoav: you need to use <a for=/> or <a for=request> explicitly |
| 13:08 | <annevk> | yoav: <a>s are the problem, not <dfn>s from a quick glance |
| 13:08 | <yoav> | oh, so when referring to one of them I need to say which one. Makes perfect sense! |
| 13:08 | <yoav> | annevk: thanks! :) |
| 15:16 | <Domenic> | annevk: note that if by "fast back" you mean bfcache, it looks like soon we'll have 3/3 browsers implementing it, so we may want to tighten the spec around that |
| 15:19 | <annevk> | Domenic: yeah, I heard in the last meeting around COOP |
| 15:19 | <Domenic> | I mainly wonder if making it mandatory will decrease complexity |
| 15:19 | <annevk> | Domenic: nobody was super rushed to make it work for COOP scenarios though, as that would be a lil more involved (though on reflection it's not that complicated from an HTML Standard perspective) |
| 15:20 | <Domenic> | Gotcha |
| 15:20 | <annevk> | I have never really worked with it myself. I suspect jgraham and zcorpan have some experience writing tests around it, but that's quite a while ago now |
| 15:22 | <zcorpan> | bfcache? Yeah I recall writing some test to make sure that an open websocket caused the doc to be discarded or so |
| 15:22 | <zcorpan> | Haven't tested bfcache itself in detail though |
| 15:23 | <annevk> | It's so weird how this feature has no real standardized name. At least as far as I know bfcache is a Gecko term |
| 15:23 | <Domenic> | "the way that sometimes history state entries have a Document still and sometimes they don't" |
| 15:41 | <annevk> | 🎉 |
| 15:52 | <Domenic> | Gosh the iframe section just has so many random unconnected normative requirements and notes in a row |
| 16:07 | <Ms2ger> | I see you're very excited to rewrite it all :) |
| 16:11 | <annevk> | Could really use some nested browsing context container abstraction… |
| 18:04 | <Domenic> | annevk: why is "Sharing it within an agent cluster is not allowed by JavaScript."? |
| 18:08 | <annevk> | Domenic: then a worker/worklet would not have independent forward progress? |
| 18:09 | <Domenic> | annevk: sure, for workers and worklets, but those have their own 1:1 agent/event loop already |
| 18:09 | <Domenic> | It's the window case we're discussing |
| 18:09 | <annevk> | Domenic: you cannot have multiple of those in one cluster |
| 18:09 | <annevk> | Domenic: and that was not clear from your phrasing |
| 18:09 | <Domenic> | Ah, right. |
| 18:10 | <Domenic> | I'm still working on this |
| 18:10 | <Domenic> | I asked internally and then learned that agents and threads are not 1:1 (makes sense in retrospect) |
| 18:11 | <Domenic> | So now I need to think harder about what the spec is communicating, both in the agents section generally and in your proposed change vs. the slight-update-to-the-status quo that I am somewhat advocating for. |
| 18:11 | <annevk> | Yeah, I guess there is some sharing, but it’s not required or observable |
| 18:11 | <Domenic> | I think it's observable that you can starve other pages |
| 18:12 | <Domenic> | a.com can busy-loop to stop b.com's tasks from executing, even though they're different agents. So I think that leans toward them sharing an event loop. |
| 18:12 | <Domenic> | I think it's even testable using postMessage |
| 18:13 | <Domenic> | Although not in a very deterministic fashion |
| 18:13 | <Domenic> | Gotta lunch now though, so haven't thought as hard as I need to |
| 18:13 | <annevk> | If they are in the same process you have Sectre problems though |
| 18:13 | <annevk> | So not particularly compelling longer term |
| 18:14 | <annevk> | Spectre |
| 18:14 | <Domenic> | I don't think anyone is signed up for guaranteeing that every origin gets its own process, no matter how many tabs you have open. |
| 18:14 | <Domenic> | But regardless, consider two same-origin pages that aren't in the same URSOBC. |
| 18:16 | <annevk> | Yeah, but then how do you proof it? Timers and BroadcastChannel? Shared worker maybe? |
| 18:17 | <annevk> | Also, separate event loops does not mean much, UA could still interleave them as spec does not put reqs on them |
| 18:19 | <annevk> | We want process per site long term, with some guarantee as I understand. Perhaps by paging background tabs to disk or some such |
| 18:19 | <Domenic> | Separate event loops per spec require you to drain them all in parallel |
| 18:19 | <Domenic> | There's no provision for blocking indefinitely on another event loop |
| 18:21 | <Domenic> | I realize it may be hard to write tests for, especially deterministic ones, but it's still "observable", especially to users. |
| 18:21 | <annevk> | I guess, ok, it prolly does not matter much anyway as tasks already have an owner, but sharing same-site window agents we could do |
| 18:22 | <annevk> | Allowing that, anyway |
| 18:22 | <annevk> | I’d also love to clarify the task record snd how it differs between event loop types |
| 18:23 | <annevk> | and* |
| 18:24 | <annevk> | Draining them in parallel is a pretty good point, although UAs could in theory halt on every step of course and all we could claim is that perf is bad, which isn’t a thing standards care about… |
| 18:25 | <Domenic> | Lol I guess. Just would rather have something more like the implementation |
| 18:25 | <Domenic> | The task struct definitely could use cleanup |
| 18:32 | <Domenic> | I also will PR something to make it clear agents and threads are not 1:1 (it's more likely event loops and threads will be). I think the current non-normative text is a bit misleading. |
| 21:49 | <devsnek> | is anyone here experienced with EME |
| 21:57 | <Domenic> | https://blog.whatwg.org/drm-and-web-security |
| 22:00 | <devsnek> | oh its w3c not whatwg |
| 22:00 | <devsnek> | (and btw i hate eme, but i'm trying to use a stream that has widevne) |
| 22:02 | <Domenic> | Basically, probably not a lot of people around here have much expertise in the area, given sentiments like the above ;) |
| 22:02 | <devsnek> | yeah |
| 22:03 | <devsnek> | as far as i can tell no one on the internet has experience with eme |
| 22:03 | <devsnek> | except the developers at the companies that pushed eme |
| 22:04 | <Domenic> | This seems plausible |