Upcoming WHATNOT meeting on 2024-09-12

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10589) and I will post the meeting notes there in a bit. The next one is scheduled for September 12, 9am PDT. Note that this is 1 week later in an Americas+Europe friendly time.

People interested in attending the next call please respond here or reach out privately to @past, @cwilso or the spec editors. We will be tagging issues for the next call again using the agenda+ label in all WHATWG repos and we would like to invite anyone that can contribute to said issues to join us.

[past]

Thank you all for attending the meeting today, and special thanks to Emilio and Simon for the excellent minuting! Here are the notes from this meeting (the next one is at #10622):

Agenda

Attendees: David Baron, Olli Pettay, Vladimir Levin, Emilio Cobos Álvarez, Panos Astithas, Sanket Joshi, Dominic Farolino, Mason Freed, Di Zhang, Joey Arhar, Benjamin VanderSloot, Keith Cirkel, Yoav Weiss, Simon Pieters, Ana Sollano Kim, Kagami Rosylight, Chris Wilson
Scribe: Emilio with help from Simon

1. Review past action items
   1. Olli will ping Yulia and Jonco for Dynamic import maps.
      1. Jonco commented. Yoav would love some reviews from Gecko and WebKit.
2. Carryovers from last time
   1. [Joey] Content model and 'what' to render for stylable <select> elements
      1. Simon will take a look. It would be good to have someone from WebKit also.
   2. [Yoav] Add a noopener-allow-popups value to COOP
      1. Dominic will take a look.
   3. [Joey] Timing of cloning for the <selectedoption> element
      1. Joey will pursue synchronous cloning
3. New topics
   1. [pastithas] We have an additional HTML editor.
   2. [pastithas] Reminder to add topics to the agenda for TPAC meetings.
   3. [pastithas] Proposing to skip next week's meeting ahead of TPAC.

Action Items

1. @zcorpan will take a look at content model and 'what' to render for stylable <select> elements.
2. @domfarolino will take a look at add a noopener-allow-popups value to COOP.

Minutes

Panos: Reviewing past action items.
… jon commented there
Yoav: Active work on the PR, some reviews from chrome, would be nice to have reviews from WebKit and Mozilla.
… there was a decision to make about whether forwarding the map for the tree, initially we went for piping the import map through but based on feedback from Chrome we did the global map there
… would make importmaps significantly more useful so would be great to have more feedback there
Panos: Carryovers
Content model and what to render for stylable selects.
Joey: We want to render more elements inside <select>, and thus we need to update the content model which is very strict right now to allow <div>, <span> and most other stuff. I sent a PR but it needs review, would be great to move it forward.
Panos: So you're looking for reviews from Gecko and WebKit.
Joey: Yes
SimonP: I can take a look
Joey: Thanks and thanks for the parser changes review
Panos: Anyone from WebKit around? If not I'll capture on the notes that it'd be nice.
Let's move to "Add a noopener-allow-popups value to COOP"
Yoav: PR is ready, blocked on refactoring PR which should also be ready to land, would love reviews on that. Anne has been doing a lot of the reviews, but he dropped off due to travel or vacation or what not. I don't know if I should wait for him to be back or if someone else can look. I know Dom Farolino took a look at one of them.
Dom Farolino: I think the refactoring is ready, do you also need eyes on the other one?
Yoav: Landing the refactor would be great, would be great to get eyes on the other too, I know the chromium reviewers looked at the PR but not sure how thoroughly.
Dom Farolino: Can try to take a look
Panos: Cloning of the element
Joey: Seems like Olli would prefer no microtasks, posted some comments about CEReactions
Dom: I have a question about the CEReaction timing.
Joey: We don't need to capture every detail in the spec.
… If we're not going to do microtask I don't think we need to look at intersectionobserver, and we just need to look at the hooks for DOM changes we already have.
… In the implementation I might reuse some of the MutationObserver infrastructure
Dom: [missed about appending a whole subtree and reusing CEReactions time to clone once]
Joey: We need an ancestor walk in order to do it naively which would be slow, so we'd need to set some bits on the subtree that gets tracked. Olli mentioned Gecko can observe subtree mutations easily.
Olli: Yeah we have an internal mutation observer, the way we'd implement it would be making the <option> an observer
Dom: And then you'd do the cloning at CEReaction
Olli: Yeah we could
Dom: CEReactions timing vs individual cloneNode is observably different
Mason: Yeah if you have an unupgraded element
Dom: Or adding <script> elements.
… Anyways it seems we're in agreement about it being observable
Olli: Don't have to use CEReactions necessarily, but yeah something similar
Dom: Piggy-backing off CEReaction seems a bit weird because it's not a custom-element, should it be generalized?
Joey: It may be easier for parsing to do it at non-CEReaction timing.
… there are cases where there might not have script running
Dom: That's how CEReactions work tho, there's the backup queue… Is that a deal breaking perf issue for the parser?
Mason: I don't think so, as long as it is only for <option>, we only have the constraint of it being performant for insertions in the tree and that when script returns it can be observed.
Sanket: IIRC we also need to toggle this when the user moves around and changes the selected option right? It seems this might cause performance issues
Mason: I think it'd be weird for script to observe the intermediate state.
Sanket: Is it a property? Because we could make that lazy
Mason: need to update the selected option synchronously so that APIs behave consistently.
Sanket: We've seen issues with authors changing selected options synchronously a lot of times…
Mason: Can you elaborate?
Sanket: Can try to find it.
Mason: If there's a use case we can try to fix it, otherwise we should just make it very clear what's happening.
Keith: Keydown on the <select>?
Mason: That'd happen once right?
Emilio: On Windows, changing the hovered option changes the selected option. It's similar to what Keith mentioned. Users can mousewheel on the select, and now you need to clone 7 times instead of once. Is that a perf issue?
Mason: That would be correct to do though?
Emilio: Yes. But if the clone is expensive, and maybe users don't care about the intermediate state… The consistent thing would be to clone.
Mason: Can throttle.
Emilio: A bit hacky though to work around a perf issue. We should make sure to understand the impact before shipping.
Dbaron: You shouldn't send movement events faster than the refresh rate.
Emilio: We should make it work the way we want. Reevaluate if there's still a perf issue.
Mfreed: Use CEReactions time
Emilio: CEReactions or sync cloning could work either way I think.
Mfreed: We can try implementing one and see if it works ok.
Emilio: sounds reasonable.
Smaug: We can use the beginning of the CEReactions queue. It would show up as sync cloning.
Sanket: Sync thing is fine… Are we adding more complexity vs sync?
Mason: The biggest hurdle we have is that we can't walk the tree every time the tree is changed. We can take an action item to try implementing something and report back.
Sanket: You don't specifically want CEReactions time?
Smaug: I'm not sure, might be better to have something like CEReactions but in front of the queue.
Mason: Options: Purely sync, slower than sync but before CEReactions, and during CEReactions
Olli: I don't prefer the last option.
Joey: Intend to pursue fully sync (with optimization internally). If there is feedback about perf issues we can make changes. Main concern is doing a treewalk in every mutation.
Olli: Was also pondering about parsing and what if network packet falls inside the selected option. Do we want to wait for something?
Joey: Not inclined to wait for anything, just observe mutations to the DOM.
Mason: What do browsers do now? There's an issue today right?
… my guess would be to wait for the closing tag?
Olli: Might be a bit worse visually if you have complicated content in the option.
Mason: There's two issues right? Waiting for the end of <select> and not for <option>.
Olli: We probably shouldn't wait for <select>, common to have lots of options.
… If you have some image there then something else, might be weird-looking
Mason: Arguably it's worse that a different option can be selected entirely.
… partially rendering the selected option feels the same as partially rendering the page
… so whatever happens happens?
Olli: fair
Panos: Other thoughts?
No new topics, but a couple notable things… New editor (Dom Farolino), congrats!
Dom: 40% of the editors are named Dom now.
Panos: TPAC is coming. There's an agenda there, lmk if you want more stuff discussed
… inclined to cancel next meeting, which is generally not super-well attended
… I'll make a not and cancel if nobody objects
Keith: Mild objection, APAC time is sometimes the only meeting some people can attend
… not sure if it's our call to cancel it
Panos: Fair, will create an issue and see how people respond, haven't seen usual suspect respond positively to the agenda yet
… definitely will cancel the meeting during TPAC