Upcoming WHATNOT meeting on 02-05-2026

[cwilso]

What is the issue with the HTML Standard?

Last week we held our weekly triage call (#12113) and the meeting notes are posted there. The next one is scheduled for February 5, 2026, at 9AM PDT. Note that this is 1 week later in the Americas-EMEA friendly time.

People interested in attending the next call who need the invite please respond here or reach out privately to @cwilso, or the editors. Please tag issues and PRs for the next call using agenda+ in all WHATWG repositories across issues and pull requests and we would like to invite anyone that can contribute to join us.

[keithamus]

Added #11980 to the agenda. @scottjehl wishes to attend and present. I'll reach out with invite details.

[nicolo-ribaudo]

@legendecas will join for #10432, I already shared the invite with him.

[cwilso]

Minutes:

• #11980 Add support for video and audio element lazy-loading Scott Jehl (from Squarespace) introduced PR 11980, a proposal to add support for video and audio lazy loading via a loading attribute with eager (default) and lazy states. They explained that this follows the precedent of the image and iframe elements and is needed because video is the heaviest asset on websites. The proposal includes HTML standard updates, about 30 web platform tests (WPTs), and browser patches for Gecko, WebKit, and Chromium. The proposal also addresses deferral of the video poster image and notes that Chromium already defers autoplay until the element intersects the viewport. Squarespace is looking for next steps and feedback on their lazy loading proposal, having addressed all requested revision. Simon Pieters indicated that the spec change needs positive signals from Chromium and/or WebKit, but the tests mostly look good. Keith Cirkel suggested the proposal is either Stage 1 or Stage 2, Chris Wilson agreed to mark it as Stage 1 and asked if anyone from Chromium was ready to weigh in for Stage 2. Mason Freed, while not ready to commit to Stage 2, offered to find a Chromium reviewer. Keith outlined concrete next steps, which include reaching out to WebKit (Anna) and Chromium engineers, with Mason Freed following up on the Chrome side. Olli Pettay and Keith discussed the practical need to land the WPTs before the Gecko patch, noting that this will require updating the patch after the tests sync.
• #11460 PR for Change definition of select element list box and drop-down box rendering: Joey Arhar needs feedback from Anne.
• #11536 PR for Change light dismiss to use click events Olli Pettay started reviewing and Joey believes they addressed the feedback.
• #12069 PR for Define base appearance for select multiple drop-down needs more review, and a standards position has been opened.
• #11040 .elementInternals accessor property - whatwg/html Benjamin Beaudry introduced the issue regarding the element internals accessor property, explaining that the encapsulation model breaks accessibility testing tools that read ARIA attributes directly from the DOM. These tools, which are part of the accessibility testing ecosystem (e.g., ax core), consequently flag false positives when encountering custom elements using element internals, causing developers to disable their accessibility testing CI steps. Benjamin clarified they are trying to fix backward compatibility for existing tools, not move all testing to Web Driver immediately, which is the long-term ideal. Keith Cirkel expressed caution about solving temporary problems, arguing the ideal is for users to adopt Web Driver for accessibility testing. Benjamin countered that they do not want to characterize widely used tooling as "broken" and that many enterprise environments restrict the use of Web Driver or extensions, penalizing those who try to implement accessibility testing. Benjamin proposed a pragmatic solution: a read-only getter specifically for ARIA attributes set via element internals to restore functionality for current testing tools without breaking encapsulation principles. Lea Verou suggested that if the problem is just the role, there are other proposals like default role and current role. Mason Freed favored adding a mode parameter (open or closed) to attachInternals, similar to shadow roots, which would solve this issue and others like subclassing custom elements. Benjamin feared an opt-in only solution would negatively affect accessibility, as most authors would default to closed, meaning internals would not expose accessibility information to testing tools.Good discussion, but more review and follow-up are needed.
• Declarative keyboard focus navigation for a scoped set of composite widgets #11641 Jacques Newman thanked Olli Pettay for feedback and asked for the proposal to move to Stage 2, as it meets the entrance criteria. Mason Freed agreed it met the criteria, suggesting only that the "early draft" title of the PR should be updated. Jacques Newman confirmed Apple had intended to review the proposal but had not provided specific concerns or feedback since November. Chris Wilson decided to mark the focus groups proposal as Stage 2, noting that they would follow up with Apple to ask for more review bandwidth, as there are a few issues requiring their input. Jacques Newman confirmed that the proposal is written so that the browser determines what is focusable, and the focus group logic only modifies sequential navigation order.
• TC39 AsyncContext Integration #10432 Nicolò Ribaudo presented an update on the TC39 async context integration proposal, which is at Stage 1 in WhatWG and TC39. The proposal aims to implicitly propagate values across asynchronous code flows, primarily for front-end frameworks (associating code with UI rendering) and tracing. The most complex integration point is with Web APIs, specifically events, which has been under discussion for a year. Nicolò detailed a new approach for event propagation based on a "dispatch context". The criteria for context propagation states that synchronous APIs (including EventTarget) do not interact with async context. For events triggered by external causes (e.g., user clicks, cross-agent communication), the event listeners run in an empty context. Context propagation occurs when an event is asynchronously triggered on a specific object due to an action on that object (e.g., XMLHttpRequest.send() storing context on the request object for later events like load). This principle also applies when an API creates an object that subsequently fires an event, such as index DB open. Nicolò also discussed the synchronous context used when setting the source on an HTML element and noted that Chrome is experimenting with this for creating DOM elements for task attribution, which they described as a smaller, limited version of sync context. They explained that events falling outside the defined categories run with an empty context, which typically applies to events fired due to asynchronous JavaScript calls on a different object, such as setting a class triggering an animation end event or sending a message in a port. Nicolò Ribaudo also expressed interest in feedback on whether the current approach is moving in the right direction, especially regarding past concerns about event handling, and mentioned that spec text is being written for less controversial APIs.

[noamr]

I've removed Agenda+ for everything that was discussed on this call. Please re-add if need to re-discuss.