WHATNOT meeting minutes 2025-08-22 & 2025-08-28

[noamr]

What is the issue with the HTML Standard?

Retroactively opening this issue to post minutes of some WHATNOT meetings in August 2025. Prior meeting was #11541 and subsequent meeting is tracked in #11622.

[noamr]

Minutes, 2025-08-22

Agenda

Attendees

Mason Freed, Dan Clark, Alex Keng, Olli Pettay, Leo Lee, Joey Arhar, Domenic Denicola

Carryovers:

Should we Remove XSLT

New topics:

Updates on Proposal: Customized built-in elements via elementInternals.type #11061:
Mixin with Reactive Controllers pattern: #11061 (comment)
Mixin with subclass factory pattern: #11061 (comment)
Rendering select as a listbox is a one-line widget that opens a popup on iOS and Android · Issue #8189 · whatwg/html · GitHub
Add the interestfor attribute #11006

Minutes:

Still tentative support for XSLT removal
Some discussion of alternatives for customized built-in elements and API shapes
The [explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ElementInternalsType/explainer.md) is updated with the static property approach per last week’s discussion.
Alex: In terms of accessing built-in properties, mixin with Reactive Controllers pattern is similar to current internals.buttonMixin proposal where new built-in properties are exposed through a property of the custom element.
Olli: Refactoring existing interfaces to HTMLButtonElement → HTMLButtonMixin → HTMLElement would not be web-compatible.
No prior art of exposing built-in subclass factory
Domenic: Exposing the new functionality on elementInternals (and requiring developers to manually expose things on the outer element) would fit the way this kind of thing has been done in the past.
Domenic: may be good to expose utility functions to help authors write wrappers
Domenic will comment in issue
Some discussion of <select> popup and in-page mobile/desktop behavior

[noamr]

Minutes: 2025-08-28

Attendees

Mason Freed, Noam Rosenthal, Stephen Chenney, Luke Warlow, Lea Verou, Olli Pettay, Jake Archibald, Benjamin VanderSloot, Kagami Rosylight, Domenic Farolino, Joey Arhar, Jan-Niklas Jäschke, Keith Cirkel, Simon Pieters

Agenda

Review past action items

None

Carryovers

Rendering select as a listbox is a one-line widget that opens a popup on iOS and Android · Issue #8189 · whatwg/html · GitHub
Add the interestfor attribute #11006 - needs review
Should we remove XSLT from the web platform? #11523
mozilla/standards-positions#1287
https://github.com/mfreed7/xslt_polyfill
https://github.com/mfreed7/xslt_extension

New topics

Proposal: Support image formats in <video> · Issue #11554 · whatwg/html
Listen to and (hopefully) resolve between:
How to handle addEventListener on CSSPseudoElement? · Issue #12163 · w3c/csswg-drafts
[css-pseudo-4] Proxying pseudo-elements as "real" (<slot>) elements · Issue #12575 · w3c/csswg-drafts
Proposal: Add Writing Mode to CanvasRenderingContext2D and offscreen Issue #11449

Minutes

Noam: Let’s go through.. No past action items. Few carry overs.

Joey: First one (rendering <select> as listbox). Would like to hear back on mozilla standards position. Spoke to Olli about this last week.

Olli: Didn’t get a chance to get to that…. XSLT took some time. Try to get to this this week.
Joey: Thank you.

Mason: Interestfor, mentioned last meeting, I need to check all boxes. I would love a review. Current spec PR - thanks to Phillip - aligns to chromium

Keith: On my list

Mason: Corresponding changes to CSS spec are linked too. Check those out.

Dominic: Don’t see CSS PRs in OP of spec PR, are they further down?

Mason: I’ll get those added. They’re in spec text but we should add pointers directly.

Dominic: Couple from random comments but OP would be easier.

Mason: I’ll get Phillip to do that.

Mason: XSLT is here as a carry over. Thanks for standards positions. Is anyone from WebKit able to provide a standards 
position? Would be much appreciated. Without anything else changing my plan is pushing forward - exploring usecases, sites found to use XSLT, plus the list Simon put together. Making sure there’s a story to tell for those, so we don’t break them. There’s a polyfill I’ve been working on which is pretty functional at this point. Works in line in an RSS feed which gets it working for developers who add it. There is a browser extension which injects the polyfill on any site, meaning those still work.

Jake: If I wrote something about XSTL is it worth linking to the polyfill/extension?

Mason: For sure, the links are::::::
Mason: Several people are PRing to polyfill which is great.
Luke: Is there a situation where that extension could pre-ship with the browser? Some ship by default (maybe not publicly facing). If it’s found it’s not webcompat, too many routes reliant on this, is that doable?
Mason: It has come up, but we’re loathed to do it. Anything published by the browser is owned by the browser forever. The thing I did do which we’re happy doing, if you navigate to a site that uses XSLT, it’ll come up with a banner pointing to a search for XSTL extensions. So it’s close to what you asked for.

Luke: The other side, if it’s not webcompat, what would be the plan? A document policy added? I as a site owner can say I don’t want it running. I don’t know the nature of the vulns. Giving site authors an opt out seems useful. If deprecation is going to take a while.

Mason: Good idea. If we’re moving ahead with deprecation there’ll be an enterprise policy to opt back in but I hadn’t thought of early opting out.

Keith: the search - are we worried about phishing? idk what the security model is for chrome extension store, but i know there are extensions that report website usage statistics, so someone could make an extension ocalled xslt thing and then exfiltrate users site data. is that a concern? also, is the extension compatible with all browsers or just chromium?
mason: im not an extension expert, but its a simple extension thats 20 lines long. idk if its directly compatible or just needs modifications. im now afraid of the phishing thing

keith: theres presumably a security team looking at that, so its just a case of throwing the commentary to that team? telling them thats a vector and that theres nothing mentioning xslt that could climb that

mason: youre right that makes it more vulnerable. ill talk to extensions about this.

Noam: Anything else on this?

Mason: Anyone else in the room not okay with this? Or are we all okay moving forward?

Simon: Okay with moving forward. One question: How do we find devices that are affected. Seems tricky. Try to ship to a number of users to see who complains but are there other strategies? 

Mason: Rooting out cases… (missed)

Simon: We don’t have data for logins on specific devices that are in users local network, for e.g.

Mason: Same for every deprecation, to varying degrees. Embedded could be more difficult. Lots of loud warnings that might get noticed, and in Chrome turned off completely way early in pre-stable channels so it breaks early in pre-stable. When the time comes to turn off, be careful and slow… turn it back on as we find new use cases. Suggestions appreciated.

keith: do you have a usecounter to see when people use the extension?
mason: there is a counter on the extension being installed, i dont have a use counter for the other thing now. ill take that as an action item

Luke: Other idea - is it plausible that it can be allowed on local IPs only? Stuff like routers can work but open web doesn’t. Not the greatest but better than nothing.
Mason: A world where all of this is possible, but it means that population is still vulnerable. It’s not as good but it’s an option if we need to take it.

Mason: Mutation events got removed successfully with little fanfare and had 200x the usage. 

Noam: I don’t see problem with embedded. They don’t have to upgrade to new chromium, if they do they can put their own extension on their device. It’s almost a lost problem wrt deprecation, they chose what version.

Mason: Data served from a device with a modern browser. So a server, serving XSLT. You would need something like an extension.

Stephen: The biggest invisible population is enterprise. No use counter will ever tell you what’s going on there. Government service sites which rarely get updated, but still important to the population are the biggest risk.

Mason: +1, what i’m most worried about. Been reaching out to enterprise folks. If everyone could do this fact finding mission - find a way to contact this population that would be great.

Lea: Embedded devices - having as browser flag might help? But wouldn’t help with enterprise.

Noam: Cautiously moving forward then?

Mason: That’s the conclusion I’m going to draw unless someone says otherwise.

Noam: Supporting image formats in video. Did we discuss this?

Lea: We discussed CSS parts in CSSWG. 
Lea: These slides are for a different problem but overlap some of the scope.
Lea: (presents some slides: https://webplatform.design/talks/image-animation/#cover)
Lea: Doesn’t look like extensive changes required. It is arguable animated images are just video with no audio, just a different codec, essentially. One hairy thing: how do you deal with static images in video, what duration do you show? Do you still show controls? How feasible? A few details but overall seems like a small change, the gains are significant though.

Jake: With my web developer hat on I agree with all of this. Another fun thing: video with transparency on web you’re either using AV9 or AVIF, AV1 doesn’t support it. The video equivalent doesn’t have transparency. If you put a jpeg in a video - the duration? Just do the same thing as a 1 frame video, is that a duration of 0? 

Lea: Duration 0 makes the most sense. It’s about feasibility.

Jake: Talked to some implementers here, our image/video pipelines are very different so it would be implementation pain but aside from that, I like it.

Stephen: +1 to treating as single frame video. Worst case that’s viable. I think in Chrome the pipelines are quite different, so would require… it’s not very easy to implement… video always go through compositor I think. Not 100% sure. Currently if you have duplicate images in many image tags they all animate at the same rate but videos don’t, which is probably good but there’s a memory cost associated with this.
Lea: One thing someone might ask: what about the opposite, making <img> and media element, it might be great independently, it’s a lot harder, but maybe the same. In terms of API - because defaults of image are different to media elements, e.g. autoplay on by default, looping by default, webcompat of changing the prototype chain. Advantages of doing with img is a tailored UI, usually simpler UI for animated imaged 
keith: why do you need to make changes to the prototype chain? 
lea: Oh simply allowing videos in <img> is totally fine, though it doesn’t solve the issue with playback. But it would be another nice step in bringing them together and WebKit already implements it.
keith: we could propose those additional apis/attributes on img elements without any web compat risk of altering prototype chains
jake: i agree with keith, i dont think you mean that as a counterproposal, its something we could do in the future
keith: yeah if my tone wasn’t supportive i will explicitly say that wasn’t me saying its a bad idea, im just saying we can avoid compat issues this way
lea: Not a counterproposal, though i was hoping to gague whether this is a way that we may go down the line, as some of the proposals we discussed in the CSS WG would actually get in the way of that ever happening.
Noam: I think this needs implementer interest, not just “this looks like a good idea” but “we are going to do it”, in a roadmap. From idea to execution. That’s my take on this. Prototype change is somewhere between never and probably never gonna happen. Not the kind of work any browser implementer is going to take on.
Jake: Could create a mixin in specland, if there’s commonality.
Simon: I wanted to say similar. It doesn’t make sense to have image support everything video supports. Images have distinct feature sets. When we overload elements in HTML it causes problems, e.g. <input>, <object>. For web developers if they want all of what <video> does, they can use <video>. I’m not sure why I’d add all the features to <img>. It doesn’t enable anything in particular.
Emilio: Agree, e.g. decoding attribute, I don’t think we want to synchronously decode video, so +1 to just supporting images in media but the other way around seems more complicated. 
Luke: Of use cases here, how important is lazy loading?
Keith: We have open issue for this.
Simon: We can add lazy loading to video, just needs more work
Noam: We can add this to the mixin. Problem solved-ish.
Lea: Also things like fetchpriority, but high isn’t desired and use cases for low can be sort of dealt with lazy loading
Noam: Videos are specced to load with 206 range requests. Images are not, specifically. We’d need to figure that out. I don’t know if you can 206 images in the same way. Say an image with 5 minutes, or a few seconds, you just want the middle part - you probably need all of it, so can’t use ranges. A detail that once implemented can probably be figured out.
Lea: Other implementation detail is can we show controls if only controls are needed.
Simon: Range might also be webcompat issue - sending range requests from images. Expectations from server side might be to get range requests from videos but not images.
Jake: You might get a range request initially, but as soon as it realises it’s a format it can’t range request on it’ll stop.
Simon: Right but videos from <img> - having <img> always send range request might be a problem.
Lea: Yes, lets not focus on video from img. Videos already send range requests for an image, I suppose? Though right now maybe it’s not very used. Presumably video still needs to send range request to find out mime type, so initial requests are already being sent?
Noam: We can handle these details more during execution.
Lea: A lot of implementers here. Any sense from implementers, about interest?
Stephen: Igalia is involved with this, we have a client who is interested. We can start pushing this forward.
Keith: I guess you want procedural confirmation of stage 0 or stage 1?
Stephen: I agree it’s probably at the point where people want to move forward with it but we need to get a proper proposal up.
Noam: Yes if there’s no spec at all it doesn’t matter but we need a champion.
Lea: I am championing it. It’s funded.
Keith: If you assume stage 1 then the next step is to write a draft spec.
Noam: Stage 0 criteria is met.
Lea: Does anyone have requirements for stages?
Keith: https://whatwg.org/stages
Noam: Stage 0 is the group is interested.
Dominic: Stage 1 is more formal, we would need consensus that we would accept a draft spec. 
Lea: We have consensus that this is a problem worth solving? There is at least one implementer interested.
Noam: Internally, I’d like to speak with experts to ensure there are no strong objections to this.
Stephen: We’d have to do an I2P and talk with video people.
Dominic: Also consensus the problem is worth solving. Did Apple weigh in? If not we should reach out to them first, rather than surprising Apple. So we can say Stage 0 for now and reach consensus for Apple. 
Lea: So I should hold off on a draft spec PR?
Keith: Raise a standards position on webkit/standards-positions for Apple.
Simon: I should clarify the staging process is opt in. You can start with writing a PR then a proposal if that’s how you want to do it. Maybe you wouldn’t reach a stage until the requirements of that stage are met but it doesn’t prevent you from doing things that aren’t in a particular stage.
Lea: Some chicken and egg, easier if there’s a draft spec but draft spec is easier with consensus. But I get the general idea.
Noam: Anything else? … Let’s move forward

Noam: About pseudo elements. There’s a lot more pseudo elements than there were before. It’s a lot more expressive than it used to be. Desire to give them JS apis that relate to layout & UI events etc. The main thing we discussed in last meeting was to listen to clicks and other events, that go on specific pseudos - rather than defaulting to the element, without knowing where it came from. Also getBoundingClientRect, ResizeObserver, connecting a pseudo to a popover target. 2 proposals for this: 1 specific to event listeners, already a spec for IDL interface for CSSPseudoElement, that IDL interface is not the same as Element, but it’s a proxy to an element plus the name of a pseudo. So you can say “this’s before” or “this’s backdrop”. They always exist even if the pseudo element doesn’t. Might or might not happen. Style & Layout create these on the fly, not connected to JS, not in real DOM. 2 directions: current spec to have this proxy element, have that be an EventTarget. If you want to listen to clicks on a before element you call element.pseudo(‘::before’).addEventListener().Another direction proposed: proxy elements with a real element instead, the idea is that when you want a pseudo element to behave like real DOM, you add a real DOM element to proxy them. It’s not displayed by itself but represents the pseudo, but style & layout is dealt with by the pseudo element, the DOM element is just a proxy. Entirely encapsulated inside CSS world, no changes to HTML, but part of web platform. Strong opinions from this group about the other direction. We want to know what people feel about this comparison.
Lea: This is not for all pseudos? Just element backed pseudos? What is the scope?
Noam: Any pseudo.
Lea: Like first-letter?
Noam: No just tree abiding.
Lea: <slot> allow shadow dom to compose light DOM but this means slots in light DOM? The reverse of what it’s doing? If you see those pseudo elements as that. Maybe a broader thing there. I like how you can use the existing DOM and everything. I’m quite in favour of this solution. There are adjacent problems, but maybe it can solve those. A lot of interesting design space. One of the best ideas to come up with this problem.
Noam: Proposal right now is you can use any element. The cross reference between element & pseudo is in CSS, it’s a `display` value property. Having real element with semantic names is also interesting.
Luke: How does this work with AT? A button exposed as a button that is suddenly something else? Scroll marker provides its own A11y stuff, does HTML win? CSS win? Are there weird situations, stuff like if you’ve got aria-hidden on the pseudo element element. E.g. spin buttons in number are hidden, do you need to manually do that in HTML, or does it automatically do that? How does it work if it changes styles dynamically? If I hover a button and style changes to `display: pseudo(backdrop)` does that change it? Gut reaction on `display` is that it doesn’t feel like the right property here. Display is layout oriented, this seems to be entirely new.
Noam: A11y by default is the element will be display:none, plus whatever bespoke things to help with a11y. 
Emilio: This comment about CSS - it feels like … if you expose it via CSS it breaks things you could otherwise depend on, stuff like you’d need to resolve style before you can dispatch an event, so it probably needs to be in the DOM. I’d rather make something like `<layout-target>` a real element rather than this proxy thing. I haven’t thought out how this would work.
Noam: The pseudo element is not known in DOM time though, only in layout, e.g. you don’t know if there’s a backdrop until you’ve computed style, so making the association in DOM doesn’t change that.
Emilio: Imagine there’s an element named <pseudo>, you can make that element magic and not have a layout box, and layout could make it when needed, everything kind of just works, I think? But if it’s not a DOM attribute then you need to figure out how DOM apis work. DOM apis dont need to know their style in order to work.
Luke: The other thing - it does still come back to, if you have this thing that you want to be a real element, why is not a real element? Scroll markers are in some ways links, so should we have a way to make scroll markers links? File input button for example would not be a thing today, we’d add an element. Some things can’t be elements, e.g. view-transitions. I worry this is over indexing on one problem space - a small subset rather than all pseudos. Maybe we address the small subset.
Lea: One component of this is encapsulation. Arguably if you want to expose them like this encapsulation is not a conern. E.g. shadow dom backdrop might have wrappers you don’t want to expose. Other than that maybe you don’t want to write a bunch of HTML…. There are cases of elements that are generated when not supplied, e.g. tbody, etc. We don’t have a good pattern for layout generated elements right?
Noam: Right but like ::column is a pseudo element, but you don’t know how many columns you have, you might have N based on scroll, layout, etc. This is the only proposal right now that deals with this. There’s no current... Probably whatever is created in this space needs to be compatible with how pseudo elements work.
Lea: What are use cases beside backdrop? I know there are many but where is the list?
Noam: I’ll send it. Scroll markers are one. People want to know which one is clicked. Likewise view transitions, which are generated on the fly. DOM creates layout creates style creates DOM. A pseudo DOM.
Lea: What % of usecases are covered for shadow dom cases? Backdrop is solved but view transitions are not.
Noam: Shadowdom already has an element, event propagation, shadowRoot, getBoundingClientRect etc.
Lea: Not for closed shadow roots.
Keith: Time check
Noam: let’s timeout this call and continue in thread. Good start!