2026-06-02 [07:42:03.0966] Sorry I missed this before. Do you have a reproduction of a perf issue for this? Is the concern around style invalidation? [07:46:59.0718] keithamus: yeah it's about invalidation [07:48:18.0313] (You also have to ensure `:heading` is as optimized as a type selector is.) [07:50:21.0949] So a headingoffset changes and you walk the tree and invalidate prior offsets? Why do you need to walk up and down? [07:58:56.0828] keithamus: if an element gets replotted, that might impact an arbitrary descendant heading element, but in order to compute the offset for that heading element you have to go up [08:00:16.0895] oh yeah. To the first `headingreset` or root, I guess. Does this actually cause perf issues though? [08:00:48.0161] keithamus: I suspect it will cause issues on websites as large as GitHub that are already prone to perf issues [08:01:50.0192] I suppose one could keep a flag on trees as to whether or not they have a reset, to avoid a walk for nothing [08:02:33.0013] There's quite a few optimizations possible of course, but the question I'm having is whether this is too complexity for the amount of benefit we're getting. [08:05:38.0150] My implementation is close to done, but sunk cost fallacy and all that. [08:29:02.0610] * There's quite a few optimizations possible of course, but the question I'm having is whether this is too much complexity for the amount of benefit we're getting. [09:31:46.0227] Luke Warlow: hmm, I guess we don't have good tests for Trusted Types + moveBefore [09:33:01.0339] > <@smaug:mozilla.org> Luke Warlow: hmm, I guess we don't have good tests for Trusted Types + moveBefore We have at least 1 test iirc. But yes we perhaps need more. I was taking a look earlier at that due to the differing implementations but everything seemed to work as expected. 2026-06-03 [07:34:47.0108] Hi! I think it would be useful to have a topic for the Sanitizer. We plan on moving some of the issues from the WICG repo to HTML. [07:49:41.0339] Tom Schuster: you should now have that power. [07:52:38.0452] Indeed, thanks Anne! [08:45:44.0285] I vibe'd https://zcorpan.github.io/whatwg-contrib-report/ LMK if something seems incorrect [08:55:43.0404] zcorpan: it seems like it does not account for affiliation changes, which skews the numbers toward current employers significantly. [08:56:22.0468] annevk: Yes. There's a disclaimer about that at the top. I couldn't think of a way to track that with available data [08:57:15.0299] That note doesn't reflect the situation for Hixie (who left Google afaik). [08:58:28.0436] Hmm hixie has no Entity affiliations in the later tables. Might be a bug [08:58:48.0506] Also funny that Hixie is still #1 after being away for a decade plus. [08:59:16.0068] What are we even doing. [08:59:49.0558] No it's correct, the spec overview doesn't say hixie is associated with Google, just that Google is the top entity [09:00:53.0953] Yeah :) The switch to PRs makes the commit count have different weight... Some PRs have 100+ commits before squashing [09:02:23.0081] Indeed, the process has changed completely. I was kidding in case that was unclear. I would love the addition of reviewer analysis. [10:26:03.0011] There are also plenty of folks who have had multiple relevant affiliations over time (including Hixie, who did plenty of spec work at Opera before going to Google). [10:28:32.0984] Yeah, that's kinda what I meant. For my share of the commits Apple benefits significantly in this overview at the cost of Mozilla and to a lesser extent (presumably) Opera. [11:10:39.0478] (It seems it doesn’t know heycam is at Apple now, though again that would give credit to the wrong company.) 2026-06-04 [23:03:55.0408] Has anyone looked into why `dfn.js` or whatever we are using these days in HTML does not work on whatpr.org? [23:05:41.0964] Okay, it seems like the problem is that it's looking for it in the wrong place. I wonder if it would be as simple as making those links point to html.spec.whatwg.org. [01:45:35.0883] zcorpan: I think https://github.com/w3c/editing/pull/536 is correct, but would appreciate you taking a look. It would be really nice btw if that specification pointed to its GitHub repository (even though it's a mega-repo). [01:52:31.0502] annevk: thanks, merged. I can add a link [01:59:18.0171] Oh, html-dfn.js relies on xrefs.json. So solving that properly would actually be a bit of work. [02:01:36.0496] https://github.com/w3c/editing/pull/537 [02:02:00.0420] smaug: any concerns with me landing the BoundaryPointsRange mixin PR? [02:02:40.0706] Aw, looks like I can't stamp there. [02:05:07.0011] Trying to see how it gets used with OpaqueRange [02:05:39.0546] I guess OpaqueRange will then also define startOffset/endOffset (but not *Containers) [02:06:05.0762] smaug: I was thinking it'd define start/end to make it a bit clearer they are different, but yes [02:06:11.0462] (yes, they should be start/endOffset, not just start/end. No need to make things too complicated using different terms for effectively the same thing) [02:06:29.0296] Well I think they are different things. [02:07:02.0905] If we ever had a type for BoundaryPoint, then we could add start/end to AbstractRange and it would return BoundaryPoint or an integer. [02:08:21.0427] That would be confusing to return either boundary point or integer , no ? [02:09:16.0685] It would depend on the concrete class what you get. For the concrete classes it'd be consistent. But as I understand it the proposal here is to return the boundary point as an integer. Not to return just the boundary point offset. [02:09:25.0576] I think these things really are offsets. Offsets in some either virtual or non-virtual data construct [02:10:42.0356] Well sure, but a boundary point is an offset too. In the case of range it just happens to consist of a node and an inner offset. [02:11:05.0978] Sure [02:13:46.0015] So, we have startContainer/endContainer as an additional (what is the word I'm looking for here...) starting point for the offset. OpaqueRange just conceptually has the same start/endContainer (for the API user), so those aren't needed. [02:18:31.0024] But why should the API user be concerned with that? It seems conceptually cleaner if an OpaqueRange just has two flat boundary points. [02:19:23.0987] I guess that is fine. (assuming they are called start/endOffset 🙂 ) [02:23:04.0076] I can't immediately see lots of AbstractRange usage anywhere [02:25:00.0472] But still pondering how much do we gain from the mixin vs just having nullable containers [02:26:59.0065] One option is ofc also to keep existing ranges as they are now and add AbstractRange or OpaqueRange to highlight API and such [02:27:39.0101] * One option is ofc also to keep existing ranges as they are now and add (AbstractRange or OpaqueRange) to highlight API and such [02:28:07.0582] Hm I think it'd be weird to have nullable containers, but the nullability depending on the concrete class (nullable for OpaqueRange, not nullable for (Static)Range) [02:28:35.0737] Right, that was my first suggestion. I got the feeling the group preferred mixins because they wanted a shared super class? [02:29:33.0655] (I don't like calling them start/endOffset because I think it will make people think of the containers, which would be wrong.) [02:31:18.0020] * Right, that was my first suggestion (`AbstractRange or OpaqueRange` that is). I got the feeling the group preferred mixins because they wanted a shared super class? [02:32:52.0576] (but there are no containers around...so which container to think about) [02:32:56.0091] Are there other APIs where AbstractRange is used, I mean other than Highlight [02:33:09.0537] Can find any [02:33:45.0061] * Can't find any [02:36:22.0093] Maybe (AbstractRange or OpaqueRange) in Highlight would be the cleanest? (I didn't want mixin, I would have created the super-abstract thingie 😛 ) [02:37:24.0842] Highlight is the only example I know of. I don't mind adding `typedef (AbstractRange or OpaqueRange) AnyRange;` for the Highlight API. [02:37:50.0352] sounds good to me. jjaschke ^ ? [02:39:00.0072] Then we would have a new range type that doesn't inherit the range base type? [02:39:45.0735] yes. Because OpaqueRange is different enough, I guess [02:40:54.0692] Note that none of this has to reflect C++ or in fact how we organize the internal concepts in the specification. This is about what's exposed to JS. [02:42:00.0109] It's still a range... What if we have `AbstractRange { startOffset, endOffset }`, OpaqueRange is a direct child, and then have an intermediate `NodeRange { startContainer, endContainer }`, and `StaticRange` and `Range` inheriting from that? [02:42:15.0807] I guess that is pretty similar to the mixin idea [02:42:26.0544] So not sure I'm adding too much value here 😅 [02:59:58.0512] I kinda like that actually. That’s the new super class idea, but with better naming. [03:02:09.0499] And I think it addresses the boundary point vs boundary point offset concern too. As only node ranges have more complex boundary points. smaug? [03:04:36.0961] We could do that [03:07:18.0875] Of course, the weird thing is that an opaque range is still a node range underneath and has to be updated just like a live range is. In terms of backing concepts this will be somewhat involved to make clean. [03:18:00.0813] with custom elements it wouldn't need to be node range underneath. One could use it to create selection in canvas based UI... but now, how would that work with highlight API. It wouldn't [03:18:36.0908] * with custom elements it wouldn't need to be node range underneath. One could use it to create selection in canvas based UI... but now, how would that work with highlight API. It wouldn't? [03:19:05.0174] jjaschke^ [03:20:09.0859] or perhaps the controller side does need to pass container node always. That would prevent canvas use case, but that is fine [03:30:23.0893] Yeah I think ultimately it has to be a node range. [03:30:50.0092] Would work with the draw element stuff btw. [03:45:54.0644] And to be clear the start and end containers can be different as well so the controller has to look a lot like Range essentially. With some way to also set the fake offsets. [06:22:38.0021] I wasn't aware of the canvas use cases for OpaqueRange. Is the idea to apply highlights etc to canvas text rendered via `fillText` and `strokeText`? [06:23:11.0880] For the HTML-in-Canvas thing selection stuff is all the same as if the HTML was outside the canvas. [06:29:44.0228] Stephen Chenney: I think Olli was just spitballing [07:01:41.0384] I summarized the range inheritance discussion here with some informal voting options: https://github.com/whatwg/html/issues/11478#issuecomment-4622847878 [07:46:44.0119] jjaschke: did you implement https://github.com/whatwg/html/pull/12263 already? Curious if the test coverage is good. [07:47:14.0628] annevk: curious, does https://github.com/whatwg/html/pull/12491 look controversial to you? It matches browser rendering, but via UA sheet rather than internal magic, much like we did for `` and co. [07:47:37.0525] Saying because I'd like to land that change in Firefox to fix a regression, and _ideally_ I'd update WPTs for the UA styles, but I can also land a reftest and follow-up :) [07:51:17.0936] emilio: I think usually people prefer expressing things in the style sheet, so no, doesn't seem controversial. But I can't find equivalent rules for ``. [07:52:23.0537] annevk: the selector that I'm tweaking to remove `[type=image]` as an exception would match `type=button` ;) [07:52:51.0728] But type=button doesn't need `content-box` (clips border-box instead) [07:59:23.0331] emilio: so what's the difference with 0 vs content-box (which also gets 0 I guess implicitly)? You can't specify padding? [08:00:38.0961] annevk: if there is padding, `` clips to it, `button` doesn't. [08:03:21.0125] annevk: (this reminds me that https://github.com/w3c/csswg-drafts/issues/13185 probably also needs HTML spec edits...) [08:07:19.0150] emilio: yes it does. [08:58:26.0038] Landed yesterday. I added a few [tests](https://phabricator.services.mozilla.com/D290555#change-hjtN9AjmELL4), and tripped over a case today, for which I'll also add one. [09:48:48.0630] dandclark: in case I didn't mention, IIRC referenceTarget tests are still missing cases where there are nested shadow DOMs and initially the relevant ID isn't there in some shadow DOM, but is added later (which should trigger updating references) 2026-06-05 [00:31:29.0704] sideshowbarker could you maybe ping siusin for https://github.com/w3c/selection-api/pull/356? [00:50:41.0518] Noam Rosenthal I should have done it the other way around (so you could try it out), but you and Dominic Farolino now have access to the main branch on Fetch as well. I thought that was already the case, but apparently we have quite a few restrictions in place to prevent mishaps. [01:07:43.0105] Thanks! Seems like I have merge rights now [01:11:32.0599] I went ahead and merged it [01:30:55.0169] jjaschke: I noticed that disabled was not recalculated during post-insertion which seems like a bug [01:31:28.0399] jjaschke: and I think I also kinda agree with one of your earlier comments about just using microtask for all the things; seems that would make it more predictable [03:33:19.0174] https://ladybird.org/posts/changing-how-we-develop-ladybird/ > We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers. [03:47:29.0696] annevk: And also the implementations would likely become simpler if everything's a microtask [04:24:54.0567] jjaschke: yeah I pushed a commit to jarhar's PR to show that; we wouldn't need post-connection steps [04:40:48.0132] emilio: I think I'll add a test later today for the select clip issue; looks like we had some leftover imperative styling in WebKit that should be restricted to the native appearance. Looks like an easy fix [04:56:58.0986] Sweet! 2026-06-08 [00:57:16.0365] annevk: is there precedence for moving issues from incubation to whatwg? [08:53:51.0607] Hi all, just a friendly reminder to post any discussion topics for this Thursday's joint CSSWG/WHATWG/OpenUI task force meeting to the meeting agenda issue: https://github.com/whatwg/html/issues/12503 [09:56:25.0448] hsivonen: we've found that we need an ASCII passthrough path for IDNA. Too many incorrect xn-- labels with legitimate websites unfortunately. I'm working on all the updates required for that now. 2026-06-09 [01:54:35.0039] Interesting that such Web compat issues haven't ended up on my plate and it took Safari this long to end up with that conclusion. [01:55:40.0696] annevk: Do you have a theory of how legitimate Web sites end up with bogus xn-- labels? [01:57:23.0470] Chromium's layer above ICU4C didn't look particularly coherent to me. I'm curious how that layer in Chromium came about, what problems it was supposed to fix, and if that layer is the cause of some new problems now. [04:59:05.0330] Who has admin access to WICG org? I can't move back whatwg/sanitizer-api [04:59:26.0242] I do, I think [08:38:18.0371] hsivonen: I was wondering if there's some kind of Punycode library out there that people use to turn random Unicode into ASCII and then use the result as domain labels, but I don't really have anything concrete. [15:32:35.0485] keithamus smaug: I think I realize what is wrong with `headingoffset` now. The specification looks at the flat tree instead of doing the same as the `lang` attribute. 2026-06-10 [05:00:48.0512] keithamus: I created https://github.com/whatwg/html/pull/12562 and am working on test updates. Do you know offhand if HTML AAM needs changes? [05:04:21.0364] It won’t, it calls out to computed heading level. But also I think we want slotted content to correctly compute heading level right? It would be unfortunate to have slotted content not derive its level from the slot and such. [05:22:02.0056] keithamus: I don't think we want that. That's not what we do for the lang attribute either. The flat tree is mainly for layout and this is not a layout thing. [05:37:19.0237] I guess I'd like to discuss this more broadly with folks because I think we really want to use the flat tree. If we don't use the flat tree it'll mean slotted elements can only rely on the host element for offsets which essentially precludes the possibiltiy of making a compositional element which creates a heading heirarchy. So like ```

The title

The subtitle

 ``` Something like this cannot be implemented, where the `my-article` component is able to slot various headings into the right positions and correctly build a heading heirarchy. I'm somewhat surprised about lang but I guess there aren't _many_ use cases where a page will switch language, but headings are substantially different to language because every page will have multiple heading levels. [06:22:30.0625] That's quite far from the original motivation for this feature and I no longer think we want to add slot change invalidation all over the DOM code. In general we've probably been overusing the flat tree. [06:23:25.0636] I think it would also be surprising for this feature to work fundamentally different from `lang` and `dir`. [06:37:41.0688] I do agree it's surprising how different it is from `lang` and `dir`. I think the use case is important though, I think it aligns with motivations for the feature: composition of heading structures. [07:04:59.0180] The main use case as I understand it is to be able to insert an existing fragment in a different place. Not arbitrarily re-assign heading levels that don't make sense in their own node tree to begin with. [07:05:48.0860] Like if you have a blog entry and you want to repurpose that in different templates where the offset ends up being different. I think your example above is quite distinct from that and not something that was discussed or brought up. [09:56:36.0796] zcorpan: did you see my indeterminate PR? Would be nice to land that if it looks okay [15:32:14.0668] I'm not sure I understand how Scoped Custom Element Registries ended up in Interop given the state of the tests and spec. It seems Chromium has landed tests that are not backed by the specification and there's still several big PRs in flight as well against DOM, WPT, and HTML, with nobody having really pushed any of those forward. 2026-06-11 [17:32:06.0952] In the HTML spec, some references to "concept-fe-mutable" are via an `` and some via a ``. Any idea why the difference? [17:35:30.0943] jmdyck: no, I think we'd just use `` today. [17:37:06.0634] ok thx. Shall I add a commit to that effect to #12557? [17:37:22.0137] jmdyck: sounds good! [17:59:09.0758] Done. [00:58:32.0308] Story of interop 🙂 How did Navigation end up to interop last year. And how it got implemented twice based on broken tests and not following the spec (which was also a bit broken) [00:59:38.0551] (But I like interop project, we just need to be more careful with the APIs being part of it [00:59:44.0182] * (But I like interop project, we just need to be more careful with the APIs being part of it) [02:11:48.0978] foolip: https://html.spec.whatwg.org/#concept-media-muted when the muted state is "default" it depends on whether there's a `muted` content attribute. But `setAttribute` doesn't run "set the muted state" as far as I can tell, so per spec a muted video can be unmuted with script and continue playback? It's not clear to me why we shouldn't honor mutations, so long as we pause videos that unmute when they shouldn't be allowed to play unmuted. I guess there's some webcompat risk with pausing instead of ignoring the muted change? [02:45:03.0518] setting src seems to run media element load algorithm so that would happen often creation time... I guess that works. It wouldn't be too big change [03:24:06.0805] smaug: there might not be a `src` attribute, though inserting a `source` element also runs media element load so maybe that works [03:24:27.0674] sure [03:25:19.0680] `srcObject` setter also invokes it [03:25:32.0633] Hmm, is this racy. If parser happens to add source element in a different task [03:25:43.0977] then one might be able to tweak muted attribute before that [03:26:01.0089] but if source is added in the same task, then tweaking muted doesn't work [03:26:21.0933] I mean, since tweaking muted would happen in a task after adding source [03:26:33.0418] yes [04:22:27.0147] zcorpan: are you thinking that the only time the attribute has an effect is when it's added? So that any time it's added we check if the state is "initial" and set it to true? [04:47:39.0136] foolip: If there are no web compat issues I think I'd just support mutations (in the "default" state), but I don't know if this breaks content (by pausing if muted is removed). More conservative is to "set the muted state" to true when the attribute is added. Or even only change the state if the current state is "default" [04:50:34.0957] I think it's a bit surprising that .muted = value is different from removeAttribute/setAttribute [04:52:48.0714] though `defaultMuted` exists [04:56:16.0756] zcorpan: The most conservative would be the set of hooks that approximate the old behavior, and I think that would be just the post-connection steps. We get script insertion "for free" even though we don't really want them, but that's likely web compatible. At worst it mutes when it isn't before, less annoying than the opposite. [04:59:01.0696] zcorpan: beyond that we could try to make the behavior for JS-created media elements sensible, and anything we do is a departure from the old spec+Chromium behavior of doing nothing. [05:00:34.0649] zcorpan: Unmuting in response to attribute removal seems risky to me, because it might also have to pause playback, which would never happen before. That could plausibly break sites. [05:01:10.0037] foolip: WebKit's behavior was different, which ought to give some leeway in terms of web compat [05:03:40.0136] Getting JS-created elements behave similarly to parser-created seems good. If you use a framework that JS-creates all elements, it's surprising that the muted attribute doesn't do anything [05:32:38.0218] zcorpan: right now I can't think of a downside to reacting to attribute mutation and go from initial/unset to true if the attr is present. Is that your ideal design too, if web compatible? [05:34:30.0257] foolip: but not from false to true, right? [05:40:32.0769] zcorpan: exactly, only the first absent->present transition could change the internal muted state (if "initial") [05:40:55.0933] And avoid firing `volumechange` [06:49:14.0365] sideshowbarker: hsivonen : is https://hsivonen.fi/last-html-quirk/ appropriate use of `dl`? If yes we should consider removing https://html.spec.whatwg.org/#the-dl-element:~:text=Within%20a%20single%20dl%20element%2C%20there%20should%20not%20be%20more%20than%20one%20dt%20element%20for%20each%20name 2026-06-12 [06:15:59.0623] WebKit shipped it first so it seemed like a good interop candidate? I wish those discussions were public TBH [07:42:04.0021] I remember conversations here about "abstract operation" being a legacy thing used only to link to Ecmascript... am I hallucinating? Couldn't find official documentation of this [08:31:05.0263] https://matrix.to/#/!AGetWbsMpFPdSgUrbs:matrix.org/$GGIAyoeqcNC8XU5GC9IdvjHe_qKZQ_H-VnpMRYcNtS8 - yes it's mostly ecma related. I don't think it's legacy per-se but I don't think it's used much either. [10:45:53.0135] Just received a PR with those so not sure if to treat it like a matter of taste or a matter of convention [11:19:46.0528] They are/were used in the trusted types spec, so it might be more common in W3C specs and just not super common in whatwg [14:42:58.0443] thanks Luke! [14:56:28.0863] I'm looking at grammatical ambiguity in the HTML spec, found a couple examples. The form is roughly `something is a thing whose X is foo and is bar`, where it's ambiguous where the `is bar` attaches: does it modify `something` or `X`? [14:56:49.0973] One example is in `4.10.19.5 Enabling and disabling form controls: the disabled attribute`: [14:57:27.0534] > the element > is a descendant of a fieldset element whose disabled attribute is specified, > and > is not a descendant of that fieldset element's first legend element child, if any. [14:58:29.0735] (This is disambiguated by knowing that it doesn't make sense to ask if an attribute is a descendant of something.) [14:58:49.0614] Other example is in `6.8.6 Writing suggestions`: [14:59:13.0418] > element > is an input element > whose type attribute is in either the Text, Search, Telephone, URL, or Email state > and > is mutable; [15:00:12.0641] (Disambiguated because you don't ask if an attribute is mutable.) [15:06:57.0434] In 6.8.6, you could avoid the ambiguity by swapping the order: "element is mutable and is an input element whose ....", but that doesn't work for 4.10.19.5. [15:08:51.0928] I suppose both could avoid ambiguity by repeating the elided subject. (e.g. "the element is a descendant of A and the element is not a descendant of B") ("element is an input element whose ... and element is mutable") 2026-06-13 [20:27:49.0939] Oh, and 4.10.15 has a sentence similar to 4.10.19.5. [20:29:50.0094] So I'm just wondering if the editors want to avoid these grammatical ambiguities, or are fine with the semantic disambiguation. [20:34:43.0146] (New topic:) In https://html.spec.whatwg.org/#in-extended-lifetime-worker, step 5.1: "If owner is a Document and the amount of time that owner that has been non-fully active is less than the user agent's extended lifetime shared worker timeout, then return true." The second "that" seems odd to me. Delete it? ("... the amount of time that owner has been non-fully active ...") [21:01:13.0569] I don’t think we should use them [21:08:38.0403] (Added a commit to #12557 to delete "that".) [21:33:25.0560] hi [21:38:47.0504] jmdyck: I think disambiguating is also good btw. Probably makes it easier to comprehend for some [21:42:42.0778] Domenic: you be lookin like a young epstein [00:41:02.0368] > <@jmdyck:matrix.org> I'm looking at grammatical ambiguity in the HTML spec, found a couple examples. The form is roughly `something is a thing whose X is foo and is bar`, where it's ambiguous where the `is bar` attaches: does it modify `something` or `X`? In the fieldset example I've often found it's the Oxford comma that disambiguates for me, but imo it's better to be overly verbose and be sure it's clear than to leave ambiguity. One thing that helps with that is to clearly split the conditions into lists but sometimes that would get you multiple layers of lists. [06:51:10.0284] Technically, I don't think it's an Oxford comma, because (according to the references I've found), that only arises in a list of 3 or more items. But it is a comma before a conjunction, so I'll go with that. So I think you're saying that the comma-before-and wouldn't be there if the "is specified" and "is not a descendant" were both predicates on "the disabled attribute", and so we can conclude that "is not a descendant" is a predicate on "the element". The problem with that is, the resulting grammatical structure (the intended parse) still has a comma-before-and between two predicates ("is a descendant" and "is not a descendant"), which undermines the premise that it's indicative of an incorrect parse. [06:55:04.0429] Elsewhere, the spec has other examples of `[subject] [predicate], and [predicate]`, e.g. https://html.spec.whatwg.org/#get-an-element's-target has "If target is not null, and contains an ASCII tab or newline and a U+003C (<), then ..." 2026-06-15 [04:06:32.0567] hsivonen: any thoughts on https://github.com/whatwg/url/pull/914 ? [04:22:53.0962] Noam Rosenthal: can you review https://github.com/whatwg/infra/pull/713 perhaps? [06:37:56.0903] Jake Archibald: did you look into the usage of "flat tree" in popover perhaps? I wonder if it makes sense given that display: contents or display: none takes an element out of the flat tree (as it's primarily a layout concept). Perhaps it works because popovers are in the top layer, but I wonder if implementations actually use the layout tree for this or something else. [07:18:54.0505] jmdyck: I'm not sure if you have been working on it as well, but I've been putting a little bit of time trying to figure out the HTML/IDL side of MakeRealm with Shannon Booth. [07:19:50.0904] I just noticed the update to webidl #1547 [07:20:11.0829] (and no, I haven't been working on it) [07:23:33.0630] jmdyck: one thing I'm finding is that we might have to set realm.[[GlobalObject]] to make "is exposed" work correctly. At least, that would give us a fairly minimal change. [07:31:17.0100] An alternative might be storing the global interface type on the environment. Maybe we should do that to keep the layering somewhat clean. [07:35:46.0859] I suspect I would have to read a fair bit and draw some diagrams before I could make an intelligent response. [07:57:24.0332] LGTM, seems like there are comments about issues that his PR doesn't fix that can be addressed separately but that's ok [08:12:28.0576] I didn't look into it at the time, but I just had a quick look. I agree that it shouldn't be "flat tree" given it's layout. But, in the case of `display: contents` or `display: none`… I don't think it would matter. [08:12:36.0708] annevk: both https://github.com/whatwg/infra/pull/710 and https://github.com/whatwg/html/pull/12528 are quite ready when you get a chance. I sent them through a few LLM reviews so they should be on the clean side... [09:36:48.0493] Not this week prolly [09:45:09.0565] Dominic Farolino: do you want to review https://github.com/whatwg/html/pull/12492 ? [11:41:47.0503] jmdyck: I have a draft now: https://github.com/whatwg/html/pull/12580 [12:41:52.0035] can't answer for Dominic but I added some comments 2026-06-16 [02:52:38.0864] annevk: does Safari support actions via `showNotification`? I'm wondering if https://caniuse.com/mdn-api_serviceworkerregistration_shownotification_options_actions_parameter is wrong [04:09:15.0450] I don't think we do, but I'm not sure. [08:33:40.0759] what was the room for discussion async context nicolo-ribaudo ? I have some laymen silly questions [08:37:04.0418] Noam Rosenthal: https://github.com/tc39/proposal-async-context/blob/master/README.md [09:03:57.0510] #tc39-async-context:matrix.org 2026-06-17 [00:36:03.0636] Hey, this might be interesting for people who worked on Sanitizer/Trusted Types or other recent HTML parsing changes: I am exploring how to combine the control function of Trusted Types with the safety features of the Sanitizer API to enable _implicit_ sanitization. https://github.com/mozilla/explainers/blob/main/trusted-or-sanitized-html.md. [00:46:17.0421] Hey! I think https://github.com/w3c/trusted-types/pull/606 addresses this already in some sense? [00:46:38.0021] (and we've discussed it at the sanitizer call a couple of times I think) [00:50:42.0590] I would expect to at least mention it... though I think both have a place and what you're suggesting there seems like a good trajectory [00:55:15.0715] Clearly an omission on my side not to mention it. Noted! [00:57:23.0957] I don't think it addresses the issues I see most important though. [01:00:11.0662] I'd love to hear more! Maybe if the explainer could mention what `createParserOptions` doesn't solve in that regard? It does allow you to implicitly enforce HTML sanitization. I have a feeling there's something this does better but would be good to point it out [01:04:16.0669] 1) TrustedHTML is super contextual. what has once been created as trusted for `div.innerHTML` might be cause XSS in `svg.innerHTML`. E.g.: `` 2) allowing pages to enable client-side to XSS protections with a header, potentially without even touching the code. Still needs reporting and gradual roll-outs etc. But it's a possibility :-) (It's all in the explainer. I handwrote it, 100% organic, LLMs were proof-reading, not writing this. ;)) [01:05:24.0135] https://github.com/whatwg/html/issues/12441#issuecomment-4727511027 - meeting link for anyone joining the extraordinary meeting later. [01:13:16.0477] For 1 - createParserOptions allows you to inject a sanitizer though. For 2 - sure, trusted types does require JS [01:13:46.0533] What's not in the explainer is what this solves on top of `createParserOptions`. I understand it solves things that TrustedHTML doesn't [01:19:08.0196] Yeah, but createParserOptions only works for the unsafe function calls, not any existing/legacy code [01:23:53.0637] why not? It does [01:26:20.0710] the current blink implementation and spec PR it applies also for innerHTML/outerHTML/insertAdjacentHTML/createContextualFragment. srcdoc/document.write requires also streaming sanitizer but they can work as well [01:28:13.0168] wait what. how would you pass the result the TrustedParserOptions into innerHTML? [01:29:03.0483] it effectively converts `element.innerHTML = x` to `element.setHTMLUnsafe(x, trusted_types.default_policy.createParserOptions({sanitizer: {}))` [01:29:20.0037] (with some quirks like enabling XML and disabling declarative shadow DOM) [01:30:25.0760] Also `element.innerHTML = a_trusted_html_object` should be possible. But that's not spec'ed/implemented and I'm not sure it's needed [01:37:04.0249] ah... and the conversion happens when you use a default policy? [01:37:37.0423] yes [01:43:31.0920] I agree that in a world without trusted types where we had sanitizer from the start I'd prefer something totally declarative where the mandatory sanitizer is defined in the header... perhaps also allowing declarative named sanitizer JSON configs. but trusted types do exist so perhaps createParserOptions is a good enough start? [01:50:16.0037] also trusted types allow fine grained control with `TrustedParserOptions`... requiring a sanitizer for *everything* will not work for a very common use case of injecting unsafe HTML from a trusted source alongside other safe+untrusted sources [01:51:32.0596] How common actually is it to need to be able to insert a [06:01:08.0123] * \ \ \ [06:01:33.0373] * [06:38:48.0901] dandclark: for an activation-behavior type of API, I think it would still be great to have all the "reset button a11y behavior" in there or all those things. It doesn't have to be atoms like click/focus/etc - more like "a set of behavior specifically for buttons/links/etc" [06:45:12.0661] do you all never use TCQ for WHATNOT? it's great! if we want to use it now: https://tcq.tc39.es/meeting/ninety-houses-sort [06:45:42.0059] We almost never meet in person, but maybe we should when we do [06:46:30.0701] it's also nice for full remote because it can distinguish between "new topic" and "reply to the current topic". i was really considering us to use it for the breakout for `