2026-05-01 [10:58:59.0542] This is not ad 🚨 Join Our Hackers Forum 🚀 Join the Premier Hackers Forum for Educational Insights! Unlock valuable knowledge and discussions on cybersecurity, ethical hacking, and more. 💡 Our community focuses on Education & Knowledge Sharing. 🔗 Join the [BlackHat Nexus community](https://t.me/+FBXOwE4iLC8yNDhk) and connect with like-minded tech enthusiasts and professionals. 2026-05-04 [04:42:41.0363] What's the correct way to preserve links to definitions when you change their contents in the HTML spec? I seem to recall there being some legacy-id attribute or something but can't seem to find it. [05:06:54.0865] Luke Warlow: just use an id attribute on the dfn [05:07:36.0131] But then the "new" name doesn't get linkified iirc? I guess that's probably okay? Context is HTMLOrSvgElement getting renamed [05:18:48.0116] Luke Warlow: yes it will. It will just use the old ID for the links, which is fine. We have a lot of history captured in fragment identifiers. [08:12:19.0777] Ms2ger: where is serialization and deserialization of WebAssembly.Memory defined? [08:20:54.0993] Uhhh [08:21:45.0014] I assumed https://webassembly.github.io/spec/web-api/#serialization but that's Module [08:22:50.0343] Is it serializable? [08:25:31.0692] Ms2ger: WebKit has code for it, in Firefox I get an exception that suggests it is (but it might be about SharedArrayBuffer instead). I should probably create a decent test; COOP + COEP makes that a bit awkward. [08:47:13.0922] Ms2ger: yeah, so Firefox definitely preserves the object brand through `structuedClone()` (`WebAssembly.Memory`) [08:47:36.0616] I couldn't find test coverage on WPT, but somehow everyone is doing this? [08:47:49.0105] * Ms2ger: yeah, so Firefox definitely preserves the object brand through `structuredClone()` (`WebAssembly.Memory`) [08:52:02.0720] https://github.com/WebAssembly/spec/issues/2155 [08:55:44.0419] Thanks [08:56:32.0888] It does ring a vague bell to me, but I can't remember the situation [14:24:52.0435] Hey, I'm trying to understand some of the media element handling. In a media element's [internal play steps](https://html.spec.whatwg.org/multipage/media.html#internal-play-steps), the resource selection algorithm is invoked if `networkState` is `NETWORK_EMPTY`, but as far as I can tell, in all cases where this happens, the resource selection algorithm would end up returning early and setting `networkState` back to `NETWORK_EMPTY`. If so, why invoke it? [14:25:44.0477] It's possible that the `src` attribute gets set immediately after e.g. calling `play()`, sure, but that would also cause another invocation of the resource selection algorithm. [14:26:13.0500] is there something I'm missing here? 2026-05-05 [23:17:29.0693] zcorpan: ping on https://github.com/whatwg/html/pull/12389 [23:20:02.0446] Andreu Botella: when the resource selection algorithm reaches step 4 the internal play steps continue with step 2 as far as I can tell. [23:35:35.0542] Does anybody how to reach out to Rniwa? They don't appear to be present in this chat room and I would like to ping them on https://github.com/w3c/selection-api/pull/356 (or at least ask whether we should submit PRs to this spec to fix issues we find in Servo) [23:58:53.0444] I've pinged him just now. [00:49:37.0872] Not sure where you see that; it only stays at `NETWORK_EMPTY` if there is no media provider/src/source [02:13:59.0917] Which WebIDL parser / syntax highlighter is it that the HTML spec uses? I notice the changes I made to WebIDL syntax for e.g. Reflect="rel" still doesn't syntax highlight correctly but I did update the two linked parsers [02:19:11.0144] Luke Warlow: highlight is https://github.com/whatwg/html/blob/main/var-click-highlighting.js I think [02:19:24.0297] sideshowbarker: ^^ [02:20:46.0960] Maybe it's not actually, that script is too small for syntax highlighting. [02:21:06.0134] I think that's for the cross linking highlighting rather than syntax [02:22:12.0819] Yeah for highlighting there was some python thing I set up. Oh guess we're still using that [02:23:51.0462] And I recall that for webidl we were using Peter’s parser. But I could be misremembering [02:24:10.0579] It's been a long time since I touched that stuff [02:24:56.0254] * Yeah for highlighting there was some python thing I set up. I guess we're still using that [02:27:02.0132] bs-highlighter it seems it's perhaps this python package, which is derived from bikeshed itself [02:31:57.0054] https://github.com/tabatkins/highlighter - okay so it looks like it might just be that this needs its dependencies bumped and then hopefully the rest will fall out of that. [05:34:29.0767] annevk: What should we do with doc-PiP? [06:02:11.0894] zcorpan: I'm not sure. It doesn't really feel like it meets the bar given there's no good cross-platform story. [06:39:03.0385] annevk: Would webkit's position change if we (or chromium) were to add support on mobile? [10:27:48.0144] Yeah, the only way that `networkState` could be `NETWORK_EMPTY` is if there's no media provider/src/source, but calling `play()` or clicking a play button won't change that [10:29:09.0485] AFAICT, if you ever make any change that gives the media element a provider/src, that will already invoke the resource selection algorithm by itself [10:30:25.0438] zcorpan: I'm not sure, as that's obviously not our primary objection here. I'd rather we all invest in making Media Session capable enough for the use cases. [10:30:33.0785] so the only time that the internal play steps will invoke the resource selection algorithm is when it's guaranteed it won't fine a media provider/src [10:30:37.0734] * so the only time that the internal play steps will invoke the resource selection algorithm is when it's guaranteed it won't find a media provider/src [10:51:17.0758] ...so, do I understand correctly that the only observable effect of the internal play steps invoking the resource selection algorithm is that immediately after calling `play()`, `networkState != NETWORK_EMPTY`? [16:15:58.0767] if anyone has a w3c contact that link should likely point to https://storage.spec.whatwg.org/ instead 2026-05-06 [23:04:32.0380] Andreu Botella: not sure, it seems to flip some other things as well. I haven't tried to figure out what ends up happening. Probably warrants some test or a look to see if existing tests cover it. [23:05:21.0410] nektro: no, HTML is correct for that one. Web Storage is `localStorage` and `sessionStorage`. [09:15:54.0297] could i get some attention on https://github.com/whatwg/webidl/pull/1578 and https://github.com/web-platform-tests/wpt/pull/58397? i'm hoping to advance the tc39 stack accessor proposal this month, but i'd need to get at least directional approval on all 3 of those in the next week or two to do that :-) [13:46:29.0411] Ah I need to bump that project, that's on me [14:01:56.0444] done 2026-05-07 [01:25:00.0863] annevk: for https://github.com/whatwg/infra/pull/709 (using infra for sanitizer), do we need infra to allow embedders to define an "equality" operator and how all the algorithms like "contains" use it? or is it enough that the sanitizer section says something to the effect of "items in this lists are considered equal when..." [01:27:07.0004] Noam Rosenthal: there is an open issue on equality we need to get to at some point. I think I would accept Sanitizer without that getting defined, but we should note it in the HTML source that it needs to be done. [01:27:18.0944] Open issue against Infra that is. [01:27:27.0935] SG, I'll link the open issue from a note [01:27:30.0734] I guess zcorpan also needs to say if that's okay. [01:27:49.0329] I don't think we want a note. Either XXX or a source comment. [01:28:06.0044] Yea I meant one of these things [01:28:43.0570] Maybe I'll get a chance to send an infra PR for equality operators at some point (without blocking sanitizer work) [03:35:25.0460] Sounds good [06:18:17.0589] sideshowbarker: not sure if you're still awake, but we're getting a 404 when running the HTML checker for about the last two hours it seems https://github.com/whatwg/infra/actions [06:20:10.0335] sideshowbarker: ah, and per https://github.com/validator/validator/commits it seems you pushed something that broke CI there; I guess that adds up [06:31:17.0655] hi, some of you are coming to the Web Engines Hackfest in June 15-17, so we were thinking if it'd be a good idea to arrange a WHATNOT meeting there, it could be an extraordinary one or we can try to move one of the usual ones to fit into the hackfest days/times; that would give more people the chance to see how these meetings happen; WDYT? if you feel it's a good idea, should we fill an issue at https://github.com/whatwg/html/issues/ to start organizing it? [07:29:17.0564] Are we having trouble with the HTML checker? I have a build failure in https://github.com/whatwg/fullscreen/actions/runs/25492816064/job/74805083038?pr=232 [07:33:01.0814] foolip: yes, see above. [07:34:14.0247] Am I correct in thinking that a request's "destination" does not get copied over when you perform `new Request(fetchEvent.request)` in a Service Worker? From reading https://fetch.spec.whatwg.org/#dom-request I think that's right, but that seemed odd so I can't tell if I'm missing something. [07:35:04.0012] Yes, we can't let the service worker pretend what request it's making. [07:36:34.0630] Wait sorry can you clarify "pretend what request it's making"? Sec-Fetch-Dest derived from destination is copied over (just not exposed to JS), right [07:37:01.0529] * Wait sorry can you clarify "pretend what request it's making"? Sec-Fetch-Dest derived from destination is copied over (just not exposed to JS), right? [07:43:43.0294] Ah I guess that's OK since they'll get re-generated anyways when the SW re-fetches the new request? (Man, service workers are complicated.) [07:44:19.0495] Sec-Fetch-Dest is always computed from scratch for each HTTP request [07:45:14.0496] Right, so as long as we strip the request's destination concept member when we copy requests, we ensure that Sec-Fetch-Dest is effectively "wiped" if the SW tries to copy/fetch the request on its own. Is that right? [07:45:33.0860] * Right, so as long as we strip the request's destination concept member when we copy requests, we ensure that Sec-Fetch-Dest is effectively "wiped" (or at least doesn't retain its old privileges) if the SW tries to copy/fetch the request on its own. Is that right? [08:02:38.0285] Yea all the service workers fetch() requests are regular fetches because you can cache them/share them/use them for any destination later on [08:08:31.0284] So the original fetch event's request retains its `destination`, and can be forwarded straight to `fetch()` and its `Sec-Fetch-Dest` will be generated accordingly, in a way that no script-constructed Request could, right? But that changes right when you copy the original request into a new Request—"destination" is lost and therefore you can't preserve `Sec-Fetch-Dest` etc. Is my mental model of this right? [08:13:03.0693] When you call `fetch()` I think `destination` will be reset. [08:15:00.0325] Ah I think you're right, because fetch() just delegate to the Request ctor right away, which doesn't carry over destination. [08:15:12.0788] * Ah I think you're right, because fetch() just delegates to the Request ctor right away, which doesn't carry over destination. [08:15:15.0956] * Ah I think you're right, because fetch() delegates to the Request ctor right away, which doesn't carry over destination. [08:16:58.0792] right, it's a rule of thumb that you can't use the same request for two different fetches. it's always cloned at some point [08:22:37.0785] Hmm, I'm not sure that's the right mental model. You need to clone a request if you want to reuse it because we want the developer to be aware of the allocation cost. That's why bodies are consumed and not reusable anyway. [08:27:46.0550] Maybe, but it was so far a useful mental model for me to remember how some things work especially around the fetch/sw integration. it's never the same request object [08:28:00.0452] * Maybe, but it was so far a useful mental model for me to remember how some things work especially around the fetch/sw integration. it's never the same internal request object [09:05:08.0430] I have a local PR for equality. I'll post it when the PRs stop failing and my previous PR lands 2026-05-08 [03:25:23.0505] annevk: in https://github.com/whatwg/html/pull/12389 was you intention that parsing `