Upcoming WHATNOT meeting on 2026-03-12

[cwilso]

What is the issue with the HTML Standard?

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

PLEASE ALSO NOTE THAT DUE TO THE TIME OF YEAR, THIS WILL BE ONE HOUR EARLIER FOR EUROPEAN PARTICIPANTS!

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.

[scottjehl]

Would it be possible to get a status check on #11980 on today's agenda? Thank you!

[cwilso]

yep, done

[cwilso]

Minutes:

• Review of Pull Requests: We began by reviewing the status of several pull requests, noting that there are several awaiting further review from WebKit.
• Discussion of PR 11933: Add Text Imports: Eemeli Aro introduced this PR, which aims to add support for importing with type: text where the imported string is returned as a module, similar to type: json but without the JSON parsing. The proposal is at Stage 3 in TC39, and it was confirmed that HTML standards do not require formal staging progression if the PR is approved by editors and merged, although staging can be useful for garnering implementer buy-in. Anne van Kesteren noted that the proposal already has buy-in from at least two implementers and primarily requires that the PRs and tests are acceptable. A point of discussion arose regarding a test that seemed to require a parser failure upon encountering a UTF-16 byte order mark (BOM), which Eemeli Aro agreed to investigate to ensure consistency with standard UTF-8 parsing instructions. It was determined that the PR seems to be advancing, and Chromium reviewers were encouraged to look at the PR.
• Status of 11687: Declarative CSS Modules: Kurt Catti-Schmidt explained that they had stripped the specification PR down to only include declarative modules, based on a design discussed previously. They specifically requested comments and feedback on the stripped-down PR from both WebKit and Mozilla implementers. An additional comment was noted regarding concerns that moving forward with inlines is premature and that the PR does not currently address elements moving around.
• Update on 11856: Controls Attribute for Image Element: there is a PR based on previous comments. Anne van Kesteren noted that they are awaiting further feedback from the Google media team for official support for the PR. Mason Freed confirmed they would follow up to see if a comment could be provided.
• Issue 3520: Meter Interoperability Issues: Luke introduced this issue concerning interoperability problems with the meter element's pseudo-classes, noting that while all three major browsers implement the spec's algorithm, there is a subtle difference in behavior regarding boundary conditions between WebKit/Chromium and Firefox. Given the low usage of the meter element, Olli Pettay suggested aligning with the Chromium behavior. Luke will proceed by assuming the WebKit/Chromium algorithm, but they may propose the Firefox algorithm if they find a strong argument for it, and they noted that the spec needs rewriting for clarity.
• Presentation of 12150: Platform Provided Behaviors for Custom Elements: Ana Sollano Kim introduced their proposal for platform-provided behaviors, which aims to allow custom elements to adopt native behaviors like form submission. The proposal, which is starting with submit behavior, has received positive signals from the web components community group, and Ana Sollano Kim requested next steps to move the proposal to Stage 1. Ana Sollano Kim received permissions to manage the related issues to clean up duplicates. Luke raised a point about the future work section concerning element behavior, suggesting that concepts like default role and default tab index should be thoroughly explored, especially given that element internals already allows setting an implicit role. Dan Clark noted that grouping roles and behaviors together allows for a comprehensive application of behaviors, such as those that might come with an inherent ARIA role, suggesting that this supports a cleaner, single-shot approach. The group agreed to move the proposal to Stage 1, acknowledging that this signifies that the problem is interesting enough to investigate, even if a final solution is not yet agreed upon.
• Review of 11935: Optional Destination Size for Image Decode: Anne van Kesteren introduced this proposal, which aims to improve the efficiency of image decoding by allowing them to specify a smaller expected display size when calling decode. Noam Rosenthal noted potential complexities related to image identity and how this interacts with the window's list of images. Noam Rosenthal was asked to provide their feedback on the issue tracker.
• Status of 11980: Lazy Loading for Media Elements: Scott Jehl provided a status update on this proposal, which is currently at Stage 2, with positive standards positions from Mozilla and Chromium, and a proposed positive position from Agalia for WebKit. The feature is in Chrome Canary, and implementations for WebKit and Firefox are in late review. The proposal was requested to move to Stage 3, and Chris Wilson agreed, noting that the remaining open issues are for Simon to review.
• Request for Stage Two for 11542: Out of Order HTML Streaming: Philip Jägenstedt requested Stage 2 status for this proposal, noting that the specification text is in good shape across four related specs (DOM and HTML) concerning processing instruction parsing and the template for mechanism. The discussion focused on the necessity of the marker attribute within the mechanism, which is intended for compatibility with existing sanitizers. Consensus was reached that the rough API shape is appropriate, and the proposal moved to Stage 2.
• Discussion of 11752: Expose Element Behavioral Attributes in Element Internals: Luke introduced this proposal, which aims to allow custom elements to implicitly set behavioral attribute values like draggable or popover via element internals, similar to how implicit roles are set. The primary concern raised by Mason Freed and Anne van Kesteren was the potential overlap with the "Platform Provided Behaviors" proposal, suggesting that a unified approach for applying built-in behaviors to custom elements might be preferable. Luke acknowledged the similarity but suggested their proposal might be more focused on single-attribute equivalents, whereas the other proposal deals with collections of behaviors. Dan Clark agreed that there is overlap, proposing a distinction where the Microsoft proposal handles chunks of interdependent behaviors (e.g., form submission), while Luke's proposal might handle single, less-baggage-laden attributes. Luke committed to reaching out to the web components community to discuss whether the two proposals can be drawn as separate or if a single overall API should be used .