WHATWG on 2025-09-25

01:16	<Sacha Greif>	just a heads up that this year's State of JS survey is now open: https://survey.devographics.com/en-US/survey/state-of-js/2025 as usual any help spreading the word will be much appreciated!
01:46	<Domenic>	Can anyone think of "entry points" for script execution in a Document (not worker) apart from <script> elements and inline event handlers? That is, if we cut off those two sources of script, is that enough to prevent any script from executing? Or is there some other way the browser might call into scripts?
02:23	<arai>	`<a href="javascript: ...">` can execute script when clicked
02:24	<Andreu Botella>	Not sure if a meta redirect to a javascript: url can also do that
06:17	<Maxim Vaarwel>	annevk: Hello, I have a question related to the reflecting of IDL attributes, specifically those related to ElementInternals. The classic definition of reflection in the specification is: "In general, this means that the IDL attribute getter returns the current value of the content attribute, and the setter changes the value of the content attribute to the given value." In other words, by changing one attribute, we see changes in the other directly. But if we look at the IDL attributes within ElementInternals, we see that "content attributes" are the internal content attribute map. Therefore, changing an IDL attribute in ElementInternals won't change the content attribute on the element, but according to the specification, the attribute in the internal content attribute map, which can't be directly observed, will change. What's the point of such reflecting if the "content attribute" is in the internal content attribute map and we can't directly change attributes and their values (as is the case with a regular IDL attribute and its content attribute on an element)? Why do we need the concept of reflecting for attributes in ElementInternals then? P.S. I also found your comment in one of the PRs: https://github.com/whatwg/html/pull/8496#discussion_r1024223828 Does this PR clarify my question?
06:22	<freddy>	Domenic: <iframe src=javascript...> is also interesting. It's not same-document script same-origin with a handle to `parent`, so depending on what you do, that's interesting
06:35	<annevk>	Maxim Vaarwel: it's mainly a specification convenience. We want the "reflecting" IDL members of ElementInternals to work the same way as their Element counterparts API-wise (in terms of the values they can be set to and the values they return) and also not have to bother specifying them from scratch. It seems reasonable to add a note of sorts to clarify that.
07:15	<Daniel Fiala>	Hi everyone, (I hope I'm sending this correctly...) I'm curious if there has been any prior discussion or consideration around creating a native Web API for managing localization resources at the browser level? Currently, web applications handle i18n by loading translation files via JavaScript, but this means every app implements its own solution for: Detecting and negotiating user locale preferences Loading and caching translation files Managing locale switching Providing translated strings to the application It seems like there could be value in a standardized approach where: Web apps could declare available locales and translation resources (similar to how manifests work) The browser would handle locale negotiation, file loading, and caching A unified API would provide access to localized strings This could reduce bundle sizes and provide consistent UX for locale selection I understand the `Intl` API handles formatting, etc, but I haven't found anything for regular web pages to declaratively provide translation resources that the browser manages. Has this been discussed before? Are there technical or any other reasons why this should remain in userland? Or might this be worth exploring as a potential standard? Thanks for any insights!
07:25	<annevk>	Mozilla has a proposal somewhere for applying https://messageformat.unicode.org to arbitrary HTML documents. Can't find it atm.
07:50	<Daniel Fiala>	I didn't know about MessageFormat 2, and I found a proposal for it here https://github.com/tc39/proposal-intl-messageformat (not sure if you meant this one), but thank you very much for the pointer.
07:51	<Domenic>	PSA: jmdyck's mega-PR to wrap all algorithms and var-scopes in whatwg/html has been merged! Outstanding PRs may need rebases, and probably need to add `<div algorithm>` wrappers. (The build process will complain about them missing soon: https://github.com/whatwg/html-build/pull/311 .) You can now click on variables in the spec and see other instances of them highlighted! See documentation in https://github.com/whatwg/html/blob/main/CONTRIBUTING.md#algorithms
08:51	<Luke Warlow>	Is it intentional this only works on single page?
09:00	<Luke Warlow>	https://github.com/whatwg/html/pull/11705
15:02	<zcorpan>	Is there a reason we haven't enabled auto-merge?
15:36	<annevk>	zcorpan: CI is not that slow. And sometimes it leads to accidents I think because you can still push to the branch and that might end up getting merged, but not as a linear commit necessarily.
15:39	<zcorpan>	annevk: ok, fair. I didn't know pushing another commit would also be auto-merged
18:48	<bakkot>	A problem I've run into several times is that AbortSignals hold their listeners even after being aborted. For long-lived signals this often causes leaks. This is observable, even, because someone can manually fire a `dispatchEvent(new CustomEvent('abort'))` even after the signal is aborted. Is there any reason that AbortController's `.abort()` couldn't remove the existing listeners? It already removes any web platform stuff which is listening (https://dom.spec.whatwg.org/#run-the-abort-steps, step 2) but afaict user-defined abortables can't opt in to this.
18:49	<bakkot>	The best you can do right now is to always use `{ once: true }`, but even that isn't quite the same because then it will be removed if someone does a `signal.dispatchEvent(new CustomEvent('abort'))`
18:55	<bakkot>	Having AbortController's `abort()` automatically remove listeners from the signal would be very helpful but really want I want is for user-defined abortables to automatically get the same behavior as web-platform ones, i.e., bypassing the event infrastructure entirely. That gives you things you basically always want: someone manually doing a `dispatchEvent` on the `signal` won't trigger your callback another listener doing `stopImmediatePropagation` won't prevent your callback from being triggered the callback is automatically released once the signal is aborted adding a callback after the signal is already aborted won't do anything (and in particular won't hold a reference to your callback) I don't understand why the web platform uses a completely different set of infrastructure for abortables with all these nice properties and forces user code into this second-class event-based path with a bunch of footguns.