2025-04-01 [07:28:18.0521] mfreed: will the MutationEvents deprecation trial end on May 13? 2025-04-03 [04:19:30.0041] TIL github has a "close as duplicate" feature [08:28:13.0395] annevk: do you think you'll be able to get to the select PRs soon? [09:49:57.0620] Heads up WHATNOT attendees, as mentioned at https://github.com/whatwg/html/issues/11170, I will cancel today's meeting. I am wondering what to do about next week's meeting, as most if not all regular Chromium attendees won't be attending, including facilitators like myself. Can I get any signals of who is planning to attend next Thursday's meeting (9am PDT) or if people would rather skip next week as well? [13:54:50.0848] I would attend, but I guess not a good time to discuss about XSLT there either šŸ™‚ [16:22:09.0279] Yeah, we should probably do that in a future meeting. 2025-04-04 [22:57:07.0099] Dominic Farolino: I suspect next week, yes [22:57:51.0382] Panos Astithas: seems okay to cancel to me [23:15:32.0165] Dominic Farolino: also, maybe you could elaborate a bit on your plan as not all the PRs seem ready. How are we not going to end up with an inconsistent state? [07:43:08.0201] some of the PRs define the same concept about how to find the association between option and select elements i think, but i can easily resolve those merge conflicts [07:43:32.0241] i split up the PRs as best i could to make them independent to make them easier to review [07:43:44.0017] i am confident there wont be an inconsistent state [07:44:05.0155] would it help for me to merge them all together into a separate mega PR? [08:32:48.0812] I think it's fine to keep them separate, though if they have conflicts that will present some issues. [09:13:56.0766] bakkot: it's happening: https://github.com/whatwg/html/pull/11143 (first real Float16Array dep I'm aware of and the OG use case) [09:15:19.0565] šŸŽ‰ glad that work ended up being useful [09:15:45.0635] of course it was mostly other people who did the actual work but I'd have felt bad if I prompted them to do implementations and then it wasn't actually used 2025-04-05 [19:32:17.0333] In the HTML spec, what determines whether a `
` is `class="switch"`? [06:32:42.0291] E.g., if you search (case-insensitively) for "run the appropriate set", you get 5 hits, each followed by a `
`, of which 3 are switches, and 2 aren't. [13:15:34.0701] Expanding the search finds ~8 "run the appropriate steps|substeps|set of steps|etc.|" that are `switch` and ~2 that aren't 2025-04-06 [14:51:21.0091] There are certainly more examples, I just picked that search as an easy way to show some contrasting cases. 2025-04-07 [21:24:16.0393] Hi! I want to know if there's any likelihood of footnotes becoming an element of HTML. They're mentioned in the HTML spec in section 4.14.4 as a feature without "a dedicated mechanism." The spec then suggests alternatives. Of the alternatives: using is inaccessible, using <a> causes me to easily lose my place in the text with how I prefer to have it positioned on the screen, and the other suggestions don't apply to the type of footnotes I'm interested in. Altogether, I feel pretty dissatisfied with the state of footnotes on the web. :( I genuinely love reading footnotes in fiction (for jokes and translation notes!) but the UX for footnotes on the web makes it so that the inconvenience of them outweighs the joy I'd get from reading those extra bits when they'd be most appropriate. I was happy enough to overlook the inconvenience but after so many encounters I feel like there has to be a better way. [21:24:34.0521] <Smudge> * Hi! I want to know if there's any likelihood of footnotes becoming an element of HTML. They're mentioned in the HTML spec in section 4.14.4 as a feature without "a dedicated mechanism." The spec then suggests alternatives. Of the alternatives: using <title> is inaccessible, using \<a> causes me to easily lose my place in the text with how I prefer to have it positioned on the screen, and the other suggestions don't apply to the type of footnotes I'm interested in. Altogether, I feel pretty dissatisfied with the state of footnotes on the web. :( I genuinely love reading footnotes in fiction (for jokes and translation notes!) but the UX for footnotes on the web makes it so that the inconvenience of them outweighs the joy I'd get from reading those extra bits when they'd be most appropriate. I was happy enough to overlook the inconvenience but after so many encounters I feel like there has to be a better way. [21:37:35.0737] <jschoi> Iā€™m not part of WHATWG, but this is a topic I am interested in. However, note that there are many ways to do footnotes: 1. As is most popular on the web, you can put footnote content at the very end of a page or section and link references to them in the main text. 2. Using CSS Grid, you can make footnote content appear in a sidebar, Edward Tufte style (https://www.edwardtufte.com/wp-content/uploads/2024/03/VE-Spread-Detail-2.jpg). This is my personal preferred way to do footnotes. 3. Using HTML Popovers, you can put footnote content declaratively in a popover element, then add references to them in the main text using buttons. The buttons can declaratively make their respective popovers appear. For all three methods, an `<aside>` element could contain the footnote content. But all of these are quite different semantically. Thatā€™s the problem with trying to standardize ā€œfootnotesā€. The semantics of what we call ā€œfootnotesā€ are diverse and may be quite specific to the document context that they appear in. Some people will want content at the very end; some people will want them in a sidebar near their references; some people will want popovers. (With that said, Iā€™m a bit surprised nobody else has asked this question in the whatwg/html GitHub repository. But I know that this has been discussed many times in the past.) [21:53:48.0639] <Smudge> Yeah! Language is funky and weird. I'm using "footnotes" to mean notes that appear in a page's footer, which is more relevant for print than web. I think print might have more specific words for these that haven't reached web people. šŸ¤” Something in my brain is telling me that "endnotes" is for the ones that appear at the very end of a work. I haven't played with HTML Popovers yet. I'll look into that some more! Thanks for the tip, jschoi! [22:05:00.0541] <jschoi> Smudge: If youā€™re most interested in layout out footnotes in printed pages, youā€™re looking for the [CSS Generated Content for Paged Media Module](https://www.w3.org/TR/css-gcpm-3/). You might also be interested in the generated cross-references in the (confusingly similarly named) [CSS Generated Content Module](https://www.w3.org/TR/css-content-3/). [22:05:36.0033] <jschoi> * Smudge: If youā€™re most interested in laying out footnotes in printed pages, youā€™re looking for the [CSS Generated Content for Paged Media Module](https://www.w3.org/TR/css-gcpm-3/). You might also be interested in the generated cross-references in the (confusingly similarly named) [CSS Generated Content Module](https://www.w3.org/TR/css-content-3/). [22:06:15.0487] <jschoi> * Smudge: If youā€™re most interested in laying out footnotes in printed pages, youā€™re looking for the [CSS Generated Content for Paged Media Module](https://www.w3.org/TR/css-gcpm-3/). You might also be interested in the generated cross-references in the (confusingly similarly named) [CSS Generated Content Module](https://www.w3.org/TR/css-content-3/). Please note that both of these are still under development and therefore have little browser support. [22:08:03.0848] <Smudge> Those are good to know about! I'd like to make my footnotes work in both print and web if possible. Thank you, again! [22:29:34.0744] <annevk> There's a section on footnotes: https://html.spec.whatwg.org/multipage/semantics-other.html#footnotes [23:54:58.0964] <Smudge> > <@annevk:matrix.org> There's a section on footnotes: https://html.spec.whatwg.org/multipage/semantics-other.html#footnotes Yes, I mentioned as much before, but the suggested alternatives to implement the type of footnotes I'm looking for each have undesirable limitationsā€”of them, only the first two are relevant and of those, the first is inaccessible and the second I find disorienting. šŸ˜” [02:20:18.0696] <Andreu Botella> There aren't any ways to detect whether a cross-origin iframe or parent is in the same agent, right? [02:21:15.0998] <Andreu Botella> I'm assuming we don't want a new API to make that information potentially exposable, right? [02:44:46.0158] <annevk> keithamus: https://github.com/whatwg/html/issues/10802 has gotten a bit messy since the "good first issue" label was added. Are you willing to untangle it and give the people that showed up some more feedback? [02:45:24.0831] <annevk> And maybe we should consider this the final nail in the coffin for that label. Unfortunate, but it doesn't seem to work well. [02:45:36.0216] <annevk> * And maybe we should consider this the final nail in the coffin for that label. Unfortunate, but it doesn't seem to work well. Or maybe too well? [02:46:05.0770] <annevk> Andreu Botella: that's right. [02:47:33.0816] <annevk> Andreu Botella: although, what we really don't want to expose are the actual process boundaries. Maybe exposing agents can be okay, but we're in the midst of changing the agent boundary through the `document.domain` removal so hmm. [02:48:23.0179] <Andreu Botella> implementation-wise, would that map to e.g. having different V8 isolates, even if it's in the same process? [02:51:59.0969] <annevk> I'm not sure. Browsers don't really have a good handle on agents which is another reason to avoid exposing them I suppose. [02:56:42.0277] <Andreu Botella> For AsyncContext, I don't think cross-origin events would be too much of an issue, but Scott Haseley pointed out that at least in Chrome, the `focus` and `blur` events can be fired synchronously across agents (related to https://github.com/whatwg/html/issues/3506), so that might have to be special cased [02:57:59.0350] <Andreu Botella> since for events fired sycnhronously, AsyncContext would always propagate the context, which would be able to be used to detect whether the iframes are in the same agent, or even in the same process [02:58:09.0125] <Andreu Botella> * since for events fired sycnhronously, AsyncContext would always propagate the context, which would be able to be used to detect whether the iframes are in the same agent/process [04:22:52.0317] <annevk> Noam Rosenthal: just to confirm, appending Math.random() to an image URL's query is sufficient to cache bust it right? [04:24:07.0139] <Noam Rosenthal> annevk: yea unless someone is fiddling with the random seed [04:38:30.0152] <Noam Rosenthal> (I've used `performance.now()` for this a few times and that caused flakes on some platforms) [04:38:59.0721] <Noam Rosenthal> If I'm doing this in a test I usually prefer to have an incrementing index [04:58:43.0294] <Luca Casonato> Is there currently a way to have an element be persistently at the top of the top layer? Imagine a side-drawer that is implemented as a `<dialog>`, but then you also want a global toast that can show ontop of the dialog backdrop (and dialog). Because top layer ordering is controlled by opening order, this means that one would have to make the toast a `popover` and then close and re-open it everytime something else gets added to the top-layer, so that the toast is always at the top of the top layer. Is there a better way? [04:59:34.0015] <annevk> Noam Rosenthal: should be fine here, they're all reftests [05:00:18.0946] <annevk> Luca Casonato: I don't think so. Might be worth filing an issue on. [05:00:46.0673] <Luca Casonato> @anne [05:01:03.0936] <Luca Casonato> @annevk Will do. The more I get exposed to the top layer, the more I feel like it is not a good abstraction :( [05:05:59.0491] <Luca Casonato> > <@lucacasonato:matrix.org> @annevk Will do. The more I get exposed to the top layer, the more I feel like it is not a good abstraction :( https://github.com/whatwg/html/issues/11193 [05:09:31.0546] <annevk> Luca Casonato: yeah maybe. What's at least clear is that developers would like more control over it. Though how to give that and not run into other issues doesn't seem straightforward to solve. [05:30:51.0582] <annevk> krosylight: thanks for closing that PR, please don't forget the "invalid" label next time [05:32:11.0086] <annevk> (The "invalid" label is what helps GitHub determine whether certain people are spammy.) [06:18:56.0577] <Luke Warlow> > <@annevk:matrix.org> Luca Casonato: yeah maybe. What's at least clear is that developers would like more control over it. Though how to give that and not run into other issues doesn't seem straightforward to solve. Yeah I hear this a lot from people. They want control via CSS or at least a way to have more control. But I struggle to see how this doesn't end up being z-index wars all over again. [06:19:55.0670] <Luca Casonato> > <@lwarlow:igalia.com> Yeah I hear this a lot from people. They want control via CSS or at least a way to have more control. But I struggle to see how this doesn't end up being z-index wars all over again. I mean I can deal with z-index. I can not deal with not having any control at all šŸ˜† [06:21:46.0620] <Luke Warlow> I suspect we'd maybe be better trying to directly solve the specific use cases rather than ripping open the layer for all to access. Like perhaps we need a toast primitive that is always on top. [06:23:47.0411] <Luca Casonato> Thatā€™s an option too for sure. [06:43:46.0672] <Simon WĆ¼lker> Hi! When trying to build the DOM standard locally with `make local` I get the following error: ``` LINE 6103:64: Multiple possible 'head' element refs. Arbitrarily chose https://html.spec.whatwg.org/multipage/semantics.html#the-head-element To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block: spec:html; type:element; text:head spec:epub-34; type:element; text:head <{head}> āœ˜ Did not generate, due to errors exceeding the allowed error level. make: *** [Makefile:19: local] Error 2 ``` Is there something I'm doing wrong or is this a known issue? [06:55:55.0179] <smaug> oh, fun, session history rewrite changed the meaning of script-closeable. I wonder why [06:56:07.0446] <smaug> * oh, fun, session history rewrite changed the definition of script-closeable. I wonder why [07:02:44.0732] <annevk> Simon WĆ¼lker: it's known insofar I just encountered it myself. You can add ` text: head` as a final line to the link-defaults block as a workaround for now. [07:03:01.0060] <annevk> * Simon WĆ¼lker: it's known insofar I just encountered it myself. You can add ` text: head` as a final line to the link-defaults block as a workaround for now (including the leading space). [07:14:26.0045] <Luca Casonato> How does hit detection work for the top layer (where is it specified)? In my tests the first layer of the top layer always sits ontop of any newer layers (which do render on top of the first layer). Both Chrome and Firefox behave this way seemingly. [07:14:49.0485] <Luca Casonato> * How does hit detection work for the top layer (where is it specified)? In my tests the first layer of the top layer always sits ontop of any newer layers for hit detection (but newer layers do render on top of the first layer). Both Chrome and Firefox behave this way seemingly. [07:49:38.0531] <annevk> Luca Casonato: hit testing is famously not defined [08:48:10.0662] <Luca Casonato> > <@lucacasonato:matrix.org> How does hit detection work for the top layer (where is it specified)? In my tests the first layer of the top layer always sits ontop of any newer layers (which do render on top of the first layer). Both Chrome and Firefox behave this way seemingly. Oh it seems like this happens because when the dialog is opened through `showModal()`, it makes the rest of the page `inert`, including the other things in the top layer above it. [08:50:32.0441] <Luca Casonato> I think https://html.spec.whatwg.org/multipage/interaction.html#blocked-by-a-modal-dialog should get an exception for elements in the top layer above the subject dialog. I'll open an issue. [09:04:09.0515] <Luca Casonato> https://github.com/whatwg/html/issues/11195 [10:14:56.0299] <Luke Warlow> There's actually been some discussion about this recently related to the interactivity property. Essentially you need to do more than just "uninert" the top layer items. AT won't let you navigate to the higher items otherwise 2025-04-08 [01:00:12.0394] <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. [01:42:24.0285] <Luca Casonato> Works for me in Chrome on Linux. [01:43:56.0724] <annevk> It's not jank if you do it slowly and the dialog pops up while you're doing it? [01:44:23.0647] <annevk> It's definitely jank here. There's ways to workaround it, but it's not a great experience. [01:45:35.0127] <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. :-( [01:47:04.0457] <emilio> annevk: I don't see why not... Add a whatwg-dom dir in https://github.com/mozsearch/mozsearch-mozilla/ much like whatwg-html? [01:48:13.0108] <annevk> Anyone willing to volunteer? For various reasons it'll be hard for me to make that contribution. [03:45:04.0087] <zcorpan> TabAtkins: I got a linking error for the quirks spec: > LINK ERROR: Multiple possible 'body' element refs. > Arbitrarily chose > https://html.spec.whatwg.org/multipage/sections.html#the-body-element > To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block: > spec:html; type:element; text:body > spec:epub-34; type:element; text:body Having epub squat on HTML element names doesn't seem ideal? [06:33:46.0553] <TabAtkins> > <@zcorpan:mozilla.org> TabAtkins: I got a linking error for the quirks spec: > > LINK ERROR: Multiple possible 'body' element refs. > > Arbitrarily chose > https://html.spec.whatwg.org/multipage/sections.html#the-body-element > > To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block: > > spec:html; type:element; text:body > > spec:epub-34; type:element; text:body > > Having epub squat on HTML element names doesn't seem ideal? Yeah that sucks, we should open an issue on them [06:57:30.0818] <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? [07:24:47.0854] <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? [07:32:32.0718] <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? [08:12:18.0039] <annevk> TabAtkins: so it's https://www.w3.org/TR/epub-34/#sec-smil-body-elem which is a separate `body` element [08:12:35.0835] <TabAtkins> Oh, hmmm [08:12:45.0505] <annevk> TabAtkins: so maybe we need some additional namespacing to distinguish the various elements? [08:14:18.0055] <TabAtkins> I mean we could put for=html on everything [09:10:48.0545] <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. [09:31:23.0158] <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. [09:31:29.0902] <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. [09:42:54.0883] <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. [09:46:16.0877] <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. [10:45:15.0800] <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? [10:48:54.0350] <Luke Warlow> > <@lwarlow:igalia.com> 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? It's also one where having tests merged etc would be useful to the wider ecosystem. I've had to patch at least one npm package to include the new behaviour for it to work correctly. I imagine frameworks would benefit from it too? [14:27:25.0616] <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. 2025-04-09 [18:17:53.0587] <Domenic> TabAtkins: annevk : this seems like a case for link-defaults, just on a larger scale? Like maybe all WHATWG specs get link-defaults for all HTML elements? Or maybe "all web specs", if we can operationalize that? Or even all Bikeshed specs, so that epub-related specs are the ones that need to override the link defaults? (But I'm not sure how such epub-related specs would necessarily find that out...) [18:43:10.0165] <TabAtkins> Yeah, I'm gonna have to figure something out. The big global namespace works *adequately* for W3C specs, but as more come online these sort of conflicts will happen more often. [19:32:45.0397] <TabAtkins (Vacation until May)> FYI, I'm on vacation until nearly the end of the month. [23:09:31.0010] <annevk> Luke Warlow: the parser change is tied to the other PRs as well, which is why I'd really like to see some kind of plan for landing these five PRs before signing off [23:10:02.0803] <annevk> Luke Warlow: for instance, the `selectedoption` PR also makes parser changes (and also impacts the content model) [23:10:56.0607] <annevk> Oh, I see jarhar did something like that now. Maybe that's easier to review. [23:15:07.0547] <annevk> Domenic: interesting, https://software.hixie.ch/utilities/js/live-dom-viewer/?.%3Cscript%3E%0Aiframe%20%3D%20document.createElement(%22iframe%22)%3B%0Aiframe.src%20%3D%20%22about%3Ablank%22%3B%0Adocument.body.append(iframe)%3B%0Aiframe.contentWindow.eval(%22self.globalSave%20%3D%205%3B%22)%3B%0Aiframe.onload%20%3D%20()%20%3D%3E%20%7B%0A%20%20w(%27load%27)%3B%0A%7D%3B%0A%3C%2Fscript%3E doesn't give a load event in Chromium/WebKit at all [23:16:46.0129] <annevk> And we did revamp open() to be a giant document state reset. Perhaps that was really the case that kept the weird Window : Document 1:2 relationship alive? [23:17:07.0948] <Domenic> Want to save that to a clickable link? [23:17:24.0735] <annevk> https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13650 [23:18:18.0257] <Domenic> The load event fires synchronously: https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=13651 [23:18:33.0420] <Domenic> I'm still a little confused on the relationship between load events and 1:2 Window:Documents... [23:20:25.0915] <Domenic> E.g. same-origin.html in https://chromium-review.googlesource.com/c/chromium/src/+/804797 doesn't use load events at all and I think it's testing window object reuse. [23:21:09.0364] <Domenic> * E.g. same-origin-initial.html in https://chromium-review.googlesource.com/c/chromium/src/+/804797 doesn't use load events at all and I think it's testing window object reuse. [23:23:20.0456] <annevk> Ah yeah it does. And if you set `.src` after connection it does take effect. I do see replacement then. https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13652 [23:28:42.0949] <annevk> Domenic: that test is pretty clear, but it seems the PR got abandoned? I tried to find it on wpt.fyi but it's not there. [23:29:37.0328] <Domenic> Yes, I think Daniel was unsure what the spec expected exactly, and we didn't give him clear enough answers fast enough... [23:33:44.0441] <annevk> Ah, that's too bad. Is it easy for you to create a WPT PR out of those tests? [00:56:00.0868] <Domenic> Eh, I'd have to verify they match the spec, which could take some time... if there's traction on solving this problem I might make the time [01:06:12.0774] <annevk> Domenic: just a draft PR would be nice so we can see the results. [01:07:08.0466] <annevk> I'm not really committed to solving it just yet, but I'm interested in learning more. [01:46:35.0535] <annevk> Noam Rosenthal: the Deferred fetching PR logs a CI error [01:47:38.0637] <annevk> Noam Rosenthal: there's also very many unresolved comment threads (though it seems like you did address them, just not hit resolve) [02:05:54.0961] <annevk> Noam Rosenthal: in https://github.com/whatwg/html/pull/10903 I think you forgot to push [02:06:47.0755] <annevk> Generally it's a good idea to push before resolving as otherwise you have entered a race with the reviewer. (Which you lost this time around. šŸ˜›) [04:23:45.0225] <Noam Rosenthal> Hehe I actually pushed to my private repo and forgot that I used a branch in the whatwg repo for this one... but yea noted [05:20:26.0474] <Noam Rosenthal> All closed and no CI errors. [05:25:26.0137] <annevk> Noam Rosenthal: thanks, do you remember who we clash with on "allowed to use"? I wonder if that's an upstream bug. [05:25:41.0598] <Noam Rosenthal> Attribution reporting [05:26:05.0339] <Noam Rosenthal> sorry "private aggregation" [05:26:11.0209] <Noam Rosenthal> https://patcg-individual-drafts.github.io/private-aggregation-api/#privateaggregation-allowed-to-use [05:40:59.0887] <annevk> Noam Rosenthal: can you file a bug against them? They should have used "for" [06:34:11.0692] <Noam Rosenthal> It does have a for, but the links in fetch don't have a `for=/` [06:34:22.0440] <Noam Rosenthal> https://respec.org/xref/?term=allowed+to+use looks right [06:50:51.0606] <annevk> Noam Rosenthal: ah okay, then we should update the links and not add a default [06:51:38.0558] <Noam Rosenthal> Right, I can prepare a small PR for the existing stuff and then update the fetchLater one [06:51:48.0694] <Noam Rosenthal> Or is this problem only in the fetchLater PR? [06:57:42.0243] <Noam Rosenthal> OK it's just in that PR, updated [07:29:57.0873] <annevk> Oh no, fetch.bs also can't compute blame anymore. [11:45:08.0191] <zcorpan> annevk: looks like various things on window are replaced by a javascript: document replacement: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13656 [15:07:34.0681] <jmdyck> In the ImageData commit that was merged into HTML yesterday, the "Initialize an ImageData object" algorithm no longer uses its 'defaultColorSpace' parameter. Seems odd. [16:33:05.0477] <LI Daobing> Hi, I think I found a bug in https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream , where could I report it? 2025-04-10 [17:05:52.0562] <Domenic> javascript: URL navigation is just a normal navigation I believe. It's a new Window, and a new Document. [01:59:13.0483] <keithamus> annevk: WPTs for revamped scoped custom elements test `Element` `customElementRegistry` - but the spec IDL has `Element` `customElements` - which one is the most up to date? Was this the compat issue? [02:00:04.0756] <keithamus> nvm, looks like I answered my own question looking at https://github.com/web-platform-tests/wpt/commit/1b4c64d41f2b8f41b7b6215900eaf63e2e8a9f94 [02:56:02.0809] <annevk> jmdyck: thanks, that's fixed now. [02:57:00.0892] <annevk> LI Daobing: file an issue against whatwg/html on GitHub. Also linked from the top of https://html.spec.whatwg.org/multipage/ [02:58:11.0399] <annevk> keithamus: which specification still has `customElements`? I thought I had updated all of that quite a while back. [02:59:48.0830] <annevk> * keithamus: which specification PR still has `customElements`? I thought I had updated all of that quite a while back. [02:59:56.0705] <keithamus> I think it's actually just the comment: https://github.com/whatwg/html/issues/10854#issue-2735341285 [03:00:21.0592] <annevk> Oh, well please don't implement based on that. [03:00:44.0925] <keithamus> I was just stubbing out the necessary APIs based on it [03:01:19.0640] <annevk> Oh no. Well, I'll update it, but please don't do that again. We really need implementers to implement based from the specification drafts. [07:20:26.0332] <Maxim Vaarwel> Please tell me to what case this condition is applicable? What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "_blank". > 3. Set windowType to "new with no opener". [07:21:25.0616] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". [07:21:50.0650] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". [07:24:37.0375] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 9. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 17. If noopener is true or windowType is "new with no opener", then return null. [07:24:51.0170] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 9. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 17. If noopener is true or windowType is "new with no opener", then return null. [07:25:28.0672] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 9. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 17. If noopener is true or windowType is "new with no opener", then return null. [07:25:52.0988] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > > > 9. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 17. If noopener is true or windowType is "new with no opener", then return null. [07:26:12.0914] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 9. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 17. If noopener is true or windowType is "new with no opener", then return null. [07:27:21.0573] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 5. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 13. Let targetNavigable and windowType be the result of applying the rules for choosing a navigable given target, sourceDocument's node navigable, and noopener. > 17. If noopener is true or windowType is "new with no opener", then return null. [07:27:59.0479] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 5. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 13. Let targetNavigable and windowType be the result of applying the rules for choosing a navigable given target, sourceDocument's node navigable, and noopener. > 17. If noopener is true or windowType is "new with no opener", then return null. [07:28:14.0322] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 5. Set noopener to true. > 6. Set name to "\_blank". > 7. Set windowType to "new with no opener". > ... > 8. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 13. Let targetNavigable and windowType be the result of applying the rules for choosing a navigable given target, sourceDocument's node navigable, and noopener. > 14. If noopener is true or windowType is "new with no opener", then return null. [07:28:36.0664] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 5. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 13. Let targetNavigable and windowType be the result of applying the rules for choosing a navigable given target, sourceDocument's node navigable, and noopener. > 14. If noopener is true or windowType is "new with no opener", then return null. [07:30:05.0425] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 5. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 13. Let targetNavigable and windowType be the result of [applying the rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) given target, sourceDocument's node navigable, and noopener. > 14. If noopener is true or windowType is "new with no opener", then return null. [07:30:56.0076] <Maxim Vaarwel> * What example satisfies it? I tried many ways and none of them worked. [The rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) > 4. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then: > 1. Set noopener to true. > 2. Set name to "\_blank". > 3. Set windowType to "new with no opener". > ... > 5. Return chosen and windowType. [window open steps](https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-open-steps) > 13. Let targetNavigable and windowType be the result of applying [the rules for choosing a navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) given target, sourceDocument's node navigable, and noopener. > 14. If noopener is true or windowType is "new with no opener", then return null. [08:51:07.0789] <Shima Ryuhei> Hey, I have a question about this part of the Streams spec. In the spec, there's this assertion during return(): Assert: reader.[[readRequests]] is empty, as the async iterator machinery guarantees that any previous calls to next() have settled before this is called. But it seems like this assumption can be broken if you call return() directly before the previous next() settles. Hereā€™s a minimal example: ``` let controller; const stream = new ReadableStream({ start(c) { controller = c; } }); const iter = stream[Symbol.asyncIterator](); let next1Promise = iter.next(); let next2Promise = iter.next(); controller.enqueue("Hello"); await next1Promise; iter.return(); ``` This was originally raised in Node.js here: https://github.com/nodejs/node/issues/57679 [08:54:00.0915] <Shima Ryuhei> * Hey, I have a question about this part of the Streams spec. In the spec, there's this assertion during return(): > Assert: reader.\[\[readRequests\]\] is empty, as the async iterator machinery guarantees that any previous calls to next() have settled before this is called. But it seems like this assumption can be broken if you call return() directly before the previous next() settles. Hereā€™s a minimal example: ``` let controller; const stream = new ReadableStream({ start(c) { controller = c; } }); const iter = stream[Symbol.asyncIterator](); let next1Promise = iter.next(); let next2Promise = iter.next(); controller.enqueue("Hello"); await next1Promise; iter.return(); ``` This was originally raised in Node.js here: https://github.com/nodejs/node/issues/57679 [08:57:41.0637] <Shima Ryuhei> * Hey, I have a question about this part of the Streams spec. In the spec, there's this assertion during return(): https://streams.spec.whatwg.org/#rs-asynciterator > Assert: reader.\[\[readRequests\]\] is empty, as the async iterator machinery guarantees that any previous calls to next() have settled before this is called. But it seems like this assumption can be broken if you call return() directly before the previous next() settles. Hereā€™s a minimal example: ``` let controller; const stream = new ReadableStream({ start(c) { controller = c; } }); const iter = stream[Symbol.asyncIterator](); let next1Promise = iter.next(); let next2Promise = iter.next(); controller.enqueue("Hello"); await next1Promise; iter.return(); ``` This was originally raised in Node.js here: https://github.com/nodejs/node/issues/57679 In this section of the Web IDL spec, should the return method call the asynchronous iterator return steps only after the previous next call has settled? Or am I missing something? [09:10:59.0820] <zcorpan> Hmmm. The test uses the initial about:blank document and then sets `src`, which is a case where Window is not replaced ( https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13663 ). But even when navigating from a document that is not the initial about:blank, I get window reuse when navigating to a javascript: URL, see https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13662 [09:13:00.0858] <zcorpan> The first case is https://html.spec.whatwg.org/#initialise-the-document-object:~:text=If%20browsingContext%27s%20active%20document%27s%20is%20initial%20about%3Ablank%20is%20true%2C%20and%20browsingContext%27s%20active%20document%27s%20origin%20is%20same%20origin%2Ddomain%20with%20navigationParams%27s%20origin%2C%20then%20set%20window%20to%20browsingContext%27s%20active%20window%2E [09:15:16.0518] <zcorpan> The javascript: case is https://html.spec.whatwg.org/#the-javascript:-url-special-case which creates a Document (if a string is returned) but I'm not sure now if it says to reuse the window [09:49:18.0289] <zcorpan> Wait, === will compare the WindowProxy, right? How do I tell if the Window was replaced? [10:41:07.0395] <zcorpan> https://chromium-review.googlesource.com/c/chromium/src/+/804797/5/third_party/WebKit/LayoutTests/external/wpt/html/browsers/the-window-object/reuse-across-navigation/same-origin.html uses an expando, which makes sense, but I couldn't get that to work in live dom viewer. Maybe the issue is testing in live dom viewer [11:29:55.0836] <Maxim Vaarwel> annevk Dominic Farolino could you help me? 2025-04-11 [18:18:18.0171] <Domenic> Window reuse is only done via https://html.spec.whatwg.org/#initialise-the-document-object step 6. There is no other part of the spec that would do it. [18:29:34.0064] <akaster> Who runs the bot that created <https://github.com/w3c/ServiceWorker/issues/1740>? It should be run against <https://w3c.github.io/webappsec-credential-management/>. I found a few violations of that principle, such as in <https://w3c.github.io/webappsec-credential-management/#algorithm-request> 13.2 [20:21:23.0094] <Domenic> Based on the name, I'd suspect `@dontcallmedom` on GitHub. [20:21:40.0980] <Domenic> The bottom of the message links to its repo. [04:14:13.0920] <zcorpan> > <@domenicdenicola:matrix.org> Window reuse is only done via https://html.spec.whatwg.org/#initialise-the-document-object step 6. There is no other part of the spec that would do it. Thanks. https://html.spec.whatwg.org/#the-javascript:-url-special-case:navigate-html will get to that step, but yes, reuse only happens from initial about:blank per spec 2025-04-15 [01:19:00.0669] <sideshowbarker> PSA: https://github.com/w3c/spec-maintenance ā€”Ā and in particular, the spec list at https://github.com/w3c/spec-maintenance#specs Would love patches with additions to that list of specs ā€”Ā or suggestions here about what to add ā€”Ā and also in general, would love to have feedback about the problem statement (or patches), and help with getting some momentum going on this [01:23:05.0615] <annevk> sideshowbarker: this framing seemingly excludes "hit testing" or image formats, which have no real specification, but should probably be included. [01:23:44.0776] <annevk> https://wiki.whatwg.org/wiki/Specs/todo [01:24:08.0107] <annevk> (We're making progress on Form control styling though.) [01:38:28.0041] <akaster> https://w3c.github.io/editing/docs/execCommand and https://console.spec.whatwg.org/ fit the bill imo [01:39:38.0115] <akaster> console re: table (#21) and `%c` formatting. execCommand for... obvious reasons I'd say [01:43:52.0475] <sideshowbarker> Thanks ā€”Ā made some refinements/additions along those lines [01:44:18.0232] <sideshowbarker> Thanks ā€”Ā will add those now [01:56:38.0354] <sideshowbarker> Added [01:59:39.0870] <sideshowbarker> annevk: High-level about the framing: If thereā€™s a better term than ā€œspec maintenanceā€, Iā€™m happy to change that. Iā€™m not wedded to any of this. At this point, itā€™s just trying to articulate the actual problem(s), and having some concrete cases to point to. Just trying to get something more going ā€” to describe the problem and whoā€™s feeling the pain from the problem, and exactly what kind of pain [02:01:07.0756] <annevk> Don't really have concrete thoughts so far, but sounds like a great thing to make some progress on! [02:01:58.0796] <sideshowbarker> /me heads off for a while to cook dinner [02:56:45.0710] <Noam Rosenthal> Not sure how to word it but UI events are a bit undermentained... e.g. they still don't have a processing model and the events somehow magically make it into the event loop [02:57:27.0559] <Noam Rosenthal> sideshowbarker: ^^^ wrt your unmaintained spec list [03:48:56.0579] <sideshowbarker> Thanks ā€” šŸ’Æ% agreed thatā€™s one that should be included; added now [07:49:22.0983] <smaug> Why does the popup in HTML spec move to bottom left when clicking something on it. So annoying. At least it isn't animated like in some other specs though. [08:27:58.0472] <annevk> smaug: because it can no longer be anchored to the definition as that's unlikely to still be in the viewport [08:29:15.0497] <annevk> smaug: I suppose it could be kept in the same place, but then it likely overlaps... Prolly best discussed in an issue if you want to drive some change. [08:38:11.0151] <smaug> oh, perhaps someone has had different use case in mind vs how I use it [08:39:53.0880] <smaug> I click a thing and then from the popup I open new tabs. And it is a bit annoying that when I ctrl+click first link in the popup, a tab is opened in background but at the same time popup moves to different place [08:42:30.0468] <annevk> Ah, maybe we can detect cmd+click and contextmenu separately? Changing the anchoring is only relevant if you go through all of the references inline. I never actually thought to open those links in a new tab. [08:42:41.0960] <annevk> Worth filing an issue on. [08:53:48.0736] <jmdyck> In the HTML spec, what is `<span data-x="">` for? [08:55:06.0112] <Ms2ger> X-references [08:59:35.0069] <jmdyck> Hm, don't think so. E.g., in 4.8.4.4.9, the first example has `<span data-x="">XYZ Corp</span>`, but that's not a cross-ref to anything. [09:00:21.0089] <zcorpan> jmdyck: empty string means to *not* cross-reference anything [09:01:39.0011] <jmdyck> Right. So why create a `<span>` if it's not going to do anything? [09:02:39.0048] <jmdyck> like, i could understand a `<span data-x="">` if it also had some other attributes [09:04:10.0436] <jmdyck> (e.g. `<span data-x="" class="XXX">`) [09:07:30.0563] <jmdyck> Or I could understand it if `span` got special styling, but that doesn't appear to be the case. [09:08:22.0643] <jmdyck> (e.g., in that example, `XYZ Corp` isn't rendered differently. Not for me, anyhow.) [09:14:55.0818] <jmdyck> (It looks like `span` does have special styling in `ul.domTree`, so leave aside those occurrences.) [09:29:41.0733] <jmdyck> I think maybe they're vestigial. [09:37:27.0801] <smaug> Luke Warlow: am I missing something or does https://github.com/whatwg/html/pull/10954/files handle somehow 'connected' trees only in attribute change case, but any trees in insertion steps [09:37:45.0460] <smaug> keithamus: ^ [09:39:25.0056] <smaug> Basically, if dialog element is inserted to some random not-connected element, dialog setup would run, but when removing open attribute then, dialog cleanup wouldn't happen [10:48:00.0698] <keithamus> smaug: that makes sense. We should check if it's in a document tree and has a browsing context. That should be sufficient, right? [10:49:41.0157] <smaug> likely šŸ™‚ the setup is complicated. Need to then also check how things like requestClose() works if the element isn't document, or not in browsing context connected document. Right now it just asserts that there is a close watcher [10:52:14.0255] <smaug> * likely šŸ™‚ the setup is complicated. Need to then also check how things like requestClose() work if the element isn't document, or not in browsing context connected document. Right now it just asserts that there is a close watcher [10:52:21.0344] <smaug> * likely šŸ™‚ the setup is complicated. Need to then also check how things like requestClose() work if the element isn't in document, or not in browsing context connected document. Right now it just asserts that there is a close watcher [10:57:06.0072] <keithamus> I'll try to get some tests down tomorrow. [12:21:48.0718] <Luke Warlow> So you're right it is missing something (because chromium still was), chromium has been updated to handle it but you're also right that there's still crash cases. This will need some further thought. I think requestClose() will need some handling in the disconnected case (possibly an early return possibly a throw?) [12:22:42.0597] <Luke Warlow> In the case that we make a dialog and the append it to a disconnected div and then append that div into the document body do the dialogs insertion steps get ran again? [12:47:29.0147] <keithamus> I wonder; is the easiest thing to avoid asserting that the close watcher exists, and instead create it if it doesnā€™t? Obviously for some instances that will mess with history activation but in the case of request close I donā€™t think it matters, right? [12:48:55.0425] <Luke Warlow> The easiest thing I think is to just not spec and implement requestClose the way it's currently written [12:54:20.0568] <Luke Warlow> If we updated dialog.requestClose() to be this, it would just work. We could also then drop dialog's `enable close watcher for requestClose()` and `request close return value`. ``` 1. If this does not have an open attribute, then return. 2. Let canceled be the result of firing an event named cancel at this, with the cancelable attribute initialized to true. 3. If canceled is false, close the dialog this with returnValue. ``` [13:13:24.0518] <Luke Warlow> * So you're right it is missing something (because chromium still was), chromium has been updated to handle it but you're also right that there's still a crash case. This will need some further thought. I think requestClose() will need some handling in the disconnected case (possibly an early return possibly a throw?) 2025-04-16 [17:16:10.0008] <Domenic> The downside of that is that then we have to keep it implicitly in sync with the close watcher spec text. Maybe we can refactor though...