WHATWG on 2026-04-16

06:10	<annevk>	I disabled comments on commits for a bunch more WHATWG repositories. I don't think anyone has been relying on that as I would've seen it, but let me know if this creates a problem.
06:11	<annevk>	Also, if someone has a connect at GitHub that could turn that into an organization setting: I think we'd love that.
07:05	<sideshowbarker>	I had completely forgot I’d said I was gonna do that, sorry
07:56	<annevk>	I will be a bit late, but do plan to attend WHATNOT
08:59	<Noam Rosenthal>	(For `muted`): On September 25, 2010 IRC: "[04:18] <Hixie> i don't see any way to have a muted="" content attribute that is reflected by the IDL attribute, since it would mean that if the user had requested a blanket mute of all audio... it would magically sprout a muted="" attribute in the DOM each time the document was parsed" So it sounds like a `defaultValue` sort of reasoning
09:02	<annevk>	Right, but that doesn't explain the creation-time magic.
09:02	<Noam Rosenthal>	annevk: where did you see that an import map key is a tuple? https://html.spec.whatwg.org/multipage/webappapis.html#module-specifier-map seems to be string->url
09:03	<annevk>	Noam Rosenthal: I thought we were discussing the module map. Was I confused?
09:05	<Noam Rosenthal>	Yes I think so. The `<style specifier="...">` thing changes the import map which doesn't have a "type" but probably should in some form
09:05	<annevk>	I think I did read out loud "A module map is a map keyed by tuples consisting of a URL record and a string." so if I was confused nobody corrected me at the time.
09:06	<Noam Rosenthal>	Yes, the module map is keyed by tuples. So that's where the confusion is
09:08	<annevk>	Sorry, I still haven't entirely wrapped my head around these `<style>` proposals. I find it weird that'd we have `<style specifier>` but not `<script specifier>` for instance. But yes, I can see how it could be used to clobber the import map. (I'm pretty sure someone said module map though and we also discussed the fetching pipeline of these things, none of which really apply to inline style sheets.)
09:10	<Noam Rosenthal>	Agreed, I think it's a design issue with `<style specifier>`. We need a type-safe way to define styles in importmap so that it fetches them with the right fetch destination, regardless of the new `<style specifier>` thing.
09:13	<Noam Rosenthal>	https://www.w3.org/Bugs/Public/show_bug.cgi?id=13327 alludes to this is a way to prevent extra `volumechange` events. but anyway I'll leave this to foolip
09:13	<annevk>	TabAtkins: Denis from the W3C found that Bikeshed behaves differently between URL and file input. He commented on the issue.
09:15	<annevk>	Noam Rosenthal: no I don't think so, before that it already had the "When a media element is created" magic. The problem is that you can't actually observe attributes when an element is created. It's always created without attributes.
09:35	<Noam Rosenthal>	ah ok `importmap` is just a specifier/url map and that's fine. it doesn't fetch anything (only the module map does). This is an issue with allowing a `<style>` element to have impact on shadow-piercing global state. There is no CSP issue
11:08	<Luke Warlow>	I notice that WPT now has test262 in a third_party folder. I wonder if something similar could be done for https://github.com/html5lib/html5lib-tests? I seem to recall mention of moving it to WPT recently but can't find where that was (might have been on the select parser changes)
11:13	<jgraham>	Note that https://github.com/web-platform-tests/wpt/tree/master/html/syntax/parsing has the html5lib tests, just directly converted to a form that allows them to be run in browsers, rather than doing the conversion at runtime.
11:16	<Luke Warlow>	Huh, TIL in that case maybe we don't need to do anything.
11:21	<jgraham>	Unrelated: https://github.com/w3c/webdriver-bidi/pull/1061 tries to define a "specification realm" which is essentially a construct for calling specification text that assumes it's running as part of script execution, without that script execution being visible to web content (e.g. via global error handlers, or unhandled promise rejection events or similar). The use case is stuff like getting a network stream from some call to `fetch` and wanting to be able to read that stream without accidentally leaking that read to content. Is this a bad idea? :) The alternative where we try to run algorithms in whatever content realm makes the most sense (e.g. the one associated with the document or worker that initiated a network request) seems like it might work for most(?) cases, but with the cost that we need to plug every case where the execution could leak to the web content.
11:22	<jgraham>	Yeah, I don't think we need to do anything. The issue you mentioned is based on the idea that wpt should be the canonical home of these tests, and libraries like html5lib should import them, rather than the other way around. That has merit, but it's not necessary per-se.
12:14	<Ms2ger (🌴 back 15 April)>	Perhaps one notable risk is that you're calling into specification prose that expects the realm it gets is a Window, or either a Window or a Worker, and is not well defined in your case
12:18	<jgraham>	Yes, agreed.
12:35	<annevk>	It would make working on the HTML parser a lot easier.
16:44	<annevk>	I wonder how this is actually implemented.
16:44	<annevk>	If we can change the specification in some way so it can be used for such purposes without requiring synthetic realms that'd be better I think.