Minutes of 7th meeting, 15 May 2025

[gesa]

Please review these minutes fully and carefully—they are not a transcript like TC39, but rather me doing my best to summarize the conversations. I may have gotten something wrong.

[andreubotella]

Suggested change

	It isn’t yet clear what the best approach will be to accept FormData. Andreu has added [a TODO to the Minimum Common API specification](https://min-common-api.proposal.wintertc.org/#issue-92f53c35) and [an issue in the MCA proposal](https://github.com/WinterTC55/proposal-minimum-common-api/issues/63) to discuss more broadly. The catch is that WP tests typically require creating an HTMLFormElement in order to test the FormData, which server-side runtimes would not be expected to support. Some recent changes to WPT do appear to provide, if not a 1:1 test, at least code that can reliably be reused by MCA testing.
	Constructor tests are challenging because existing runtimes already have their own behaviour depending on whether zero, one, or two arguments (un)defined.
	There was some discussion about filesystem-related APIs. There is intentionally no way to read from the filesystem in the MCA, and there had been previous conversations about defining a filesystem layer on top of the MCA, perhaps including APIS from the [WHATWG FS standard](https://fs.spec.whatwg.org/) and the [File System Access spec](https://wicg.github.io/file-system-access).
	In browsers, the `FormData` constructor takes two optional arguments which are HTML elements, which allow constructing a `FormData` from the current state of an HTML form. Server-side runtimes don't support HTML elements, but the exact behavior on whether they should support non-`undefined` arguments differs across existing runtimes. There's [a TODO to the Minimum Common API specification](https://min-common-api.proposal.wintertc.org/#issue-92f53c35) and [an issue in the MCA proposal](https://github.com/WinterTC55/proposal-minimum-common-api/issues/63) to discuss this more broadly.
	**Andreu Botella** went through the FormData WPT tests [in this issue](https://github.com/WinterTC55/proposal-minimum-common-api/issues/86#issuecomment-2884169434), although for the `constructor.any.js` test, whether it should be included in the MCA test suite depends on the resolution of the aforementioned open issue about the constructor arguments.

[andreubotella]

Suggested change

Due to a number of conflicting assumptions made about any given runtime’s event loops, not every server runtime is consistent in event management. **Andreu Botella** will go through the WPT and Fetch spec in finer detail between meetings and bring them on a future agenda.

The MCA does not explicitly state that server-side runtimes need to have an event loop similar to that in browsers, but the spec machinery behind many of the APIs does. WPT has tests for the event loop and for running scripts as defined in the HTML spec. **Andreu Botella** will go through these tests and the event loop definition in the HTML spec in finer detail between meetings and bring them on a future agenda.

[andreubotella]

Suggested change

	### 4.1.3 JS Tests
	There are a number of tests against the ECMAScript language itself, not just the Web Platform; **Andreu Botella** will research whether those were meant to be implemented in Test262.
	### 4.1.3 JS Specification Tests
	There are a number of WPT tests in the `js` folder against the ECMAScript language itself, not just the Web Platform; **Andreu Botella** will research whether those were meant to be implemented in Test262, and whether they can be moved there.

[andreubotella]

Suggested change

Chrome is now shipping Observable, so TC55 has run out of time to start making decisions about its place in the Minimum Common API. It’s a significant API to implement, and relies once again on a predictable event loop.

Last year **Dominic Farolino** [opened an issue about whether the Observable API would be part of the MCA](https://github.com/WinterTC55/proposal-minimum-common-api/issues/72). Chrome is now shipping Observable, so TC55 has run out of time to start making decisions about its place in the Minimum Common API. It’s a significant API to implement, similar to events in that other web platform features might build on it in the future. The committee had previously established that the MCA should be a superset of the APIs exposed in ShadowRealms, and Observables will be exposed there, which is a point in favor of adding it.

[andreubotella]

Suggested change

	On the browser side, the Sanitizer API’s intended purpose is to prevent cross-site scripting vulnerabilities—making it clear to developers identifying “safe” and “unsafe” markup. It will work with ECMAScript TrustedTypes. It *may* be meaningful to developers working on server runtimes, but would require implementing DOM APIs. **Andreu Botella** & **Owen Buckley** will try to bring **J.S. Choi (invited expert)** in to participate in a future meeting to discuss.
	On the browser side, the Sanitizer API’s intended purpose is to prevent cross-site scripting vulnerabilities—making it clear to developers identifying “safe” and “unsafe” markup. It will work with ECMAScript TrustedTypes. It *may* be meaningful to developers working on server runtimes, but would require implementing DOM APIs, or at the very least an HTML parser. **Andreu Botella** discussed possibly including it in a level sitting on top of the Minimum Common API.
	**Andreu Botella** & **Owen Buckley** will try to bring **J.S. Choi (invited expert)**, who had [opened the issue to consider it in the MCA](https://github.com/WinterTC55/proposal-minimum-common-api/issues/87), in to participate in a future meeting to discuss.

[andreubotella]

Suggested change

	The next meetings will take place as Google Meet video calls fortnightly. The next scheduled is on 29 May, 2025 at 16:30 CEST.
	The next meetings will take place as Google Meet video calls fortnightly. The next scheduled is on 29 May, 2025 at 16:30 CEST. This meeting overlaps with the TC39 plenary, however, so it might need to be cancelled depending on the TC39 scheduling.