Upcoming WHATNOT meeting on 2024-12-05

[annevk]

Today we held our weekly triage call (#10789) and I will post the meeting notes there in a bit. The next one is scheduled for December 5, 9am PST. 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 editors. We will be tagging issues for the next call again using agenda+ To be discussed at a triage meeting in all WHATWG repositories across issues and pull requests and we would like to invite anyone that can contribute to join us.

[schenney-chromium]

I'd like to attend.

[annevk]

It looks like you're already on the invite list and have accepted the invite.

[past]

Thank you all for attending the meeting today and a special thank you to Chris for taking meeting notes! Here are the notes from this meeting (the next one is at #10825):

Agenda

Attendees: Luke Warlow, Joey Arhar, Panos Astithas, Stephen Chenney, Keith Cirkel, Emilio Cobos Álvarez, Mason Freed, Olli Pettay, Anne van Kesteren, Chris Wilson, Di Zhang
Scribe: Chris Wilson

1. Review past action items
   1. Olli and Domenic to check the Last-Event-ID PR with relevant teams
      1. [Olli] asked valentin, he didn't have concerns
   2. Noam to get web developers to comment on ShadowRealm issues.
      1. Noam: didn't receive anything definitive. Recommending that the patrons of the ShadowRealm project evangelise and gather more developer interest.
      2. [Olli] FWIW, asked around if anyone knows examples how ShadowRealms would be used in non-trivial cases in order to understand its performance characteristics better, but no examples so far. -
      3. [luke] fix: update near-membrane-dom to use ShadowRealm salesforce/near-membrane#243 - here's a potentially outdated PR for how Salesforce plan to use ShadowRealm fwiw
      4. Panos will ask Shu for a Chromium opinion.
   3. ShadowRealm PR to explore the idea of associating ESO with principal realms/globals + ShadowRealms/their globals.
2. Carryovers from last time
   1. Olli will review the Atomic move PR this week. (explainer)
      1. [Olli] reviewed it some more, will need to look at also the HTML part. (But looking rather good so far)
   2. Canvas Text Metric investigations (from time before)
      1. Comments on the issue regarding Intl.Segmenter
      2. Renaming getIndexFromOffset
      3. WebKit implementation under way
3. New topics
   1. [Mason] Dialog light dismiss PR.
      1. Luke will take a look.
   2. [Joey] customizable select events
      1. Joey will add the proposed text to the spec PR.

Action Items

1. @lukewarlow will take a look at the Dialog light dismiss PR.
2. @josepharhar will add the proposed text to the spec PR for customizable select events.
3. @past will ask Shu for a Chromium opinion on ShadowRealm.

Minutes

topic: last-event-id pr
Olli:concerns are just around is this web-compatible.
PA: haven't seen any comments from Chromium, assume Domenic is still looking. Let's wait for that and the response from the PR author on web compat.

Topic: ShadowRealm issues.
PA: Any definitive next steps?
Olli: I think there might some misunderstanding inside Google about whether they support this; Domenic said neutral, which would make all browser vendors neutral. May want to ask around. Seems only V8 folks in approval? Curious to know how this would be used on actual web sites, but haven't had any answer.
Luke: fwiw, I've added a link to a PR for Salesforce's planned use.
Anne: also checked if it's interesting for JS in other environments, like node.js. Haven't really gotten much support; seems like maybe just the salesforce case is the only solid request?
PA: So, waiting for both two vendor support, and some real world examples of use.
Joey: the PR links to a chromium issue titled implement callable realms filed by Shu. Should ask?
Luke: yes, that's the old name for ShadowRealms. I'm currently working on the blink tie-in.
Olli: Spidermonkey has this too, but I think we need to answer if we actually want this for the web. Not sure how strong the interest is, and the feature is quite complicated.
Anne: having an implementation is not reason enough to ship it.
PA: seems like we're in an interesting space where the spec proposal needs to agree with the platform.
Anne: In TC39 you don't need implementer support to progress stages, just neutrality? Seems like maybe that's what's happened here.
Keith: I think Github's also interested for the SSR use case, but that's kind of scoped to node. Not just Salesforce.
Anne: on server side only?
Keith: Yes.
PA: I'll ensure Domenic has asked Shu, and get an answer by the next meeting. We should add the implementer interest request label on this as well.
Anne: I think Shu commented on the superseded PR, but yes.

Topic: Atomic move PR
PA: done, but need to do more?
Olli: Yes. Added some comments, but need to look at estimate part.
Anne: went through this last week, but there was some fairly elaborate web developer backlash on the PR. Should read up on it.
Mason: there's an updated explainer that goes through that debate.
Anne: doesn't change consensus. I'd prefer that we start out with one thing then revisit in a year. No browser engineer has found the performance claims credible.
Olli: Yes, definitely ship first and analyze.
Mason: +1

Topic: Canvas Text Metric investigations
Stephen: We talked about 2 weeks ago, just want to update and keep moving. Anne asked about the international segmenter. Possible to use, but does things in logical order, not visual order. Renaming has gone through, and for getting the index of a particular offset in the string. We've got some work going on at Igalia to implement. No significant pushback from Webkit on implementing. Googlers getting back in, will update again soon.
Anne: Does this api have the same set of inputs? Like, locale is missing…
Stephen: agree. Working on it.

Topic: Dialog light dismiss PR.
Mason: just wanted to raise awareness. It's had a few rounds of review, one quick change in behavior recently, about nested dialogs, but seems pretty good, wanted to elicit any comments. Feel free to take a look at PR.
Luke: I'll take a look at it. Seems in a pretty good state. Does this include the request close side of things?
Mason: Yes.

Topic: customizable select events
Joey: Thanks Olli for taking a look at the implementation. Some feedback about click events being omitted on certain things. Instead of listening to mouse up we should use the activation behavior concept. Should take a look after I take a look. Also looking for some feedback from Domenic. I wrote a sample paragraph that could be in the spec. Is this the right level of detail?
Anne: would it only fire when you opened with a mouse, or always?
Joey: tried to make it encompass keyboard/mouse/pointer. Should maybe be looking at pointer instead of mouse.
Anne: there are lots of synthetically generated events with pointers and touch because of legacy. I think you get both events. Not sure about ordering. We also need to define focus. If these objects have activation behavior they will need to participate in the focus model.
Mason: via up/down arrows, not tab, as that would leave the object
Anne: And then the focus pseudoclass needs to match, and focus and blur fire…
Luke: focus does move the options, and would stop matching on the select; presumably the blur would fire on it.
Anne: does focus not do an inclusive container?
Mason: I think that's focus-within. Already focus and blur should be handled like for every other element. What's defined in the HTML spec is the sequential focus navigation, which controls what happens when you hit tab.
Luke: I thought this would be a composite control, where you don't necessarily remove focus, it's contained…
Mason: It's a little weird.
Keith: Maybe active descendant is the thing to use, seems like a new thing…
Mason: I'm talking about the dev exp of currently selected option and applying visual treatment to it.
Keith: may need a new pseudoselector.
Anne: focus-within can do this, can't it?
Mason: just did a quick demo, and it's an old-style select. You don't see a focus ring after you've picked it.
Luke: Is this like an open ui focus group?
Mason: Yes. Seems like the exact behavior we're looking for.
Luke: reading flow changes?
Anne: needs to be part of the focusable area model…
Joey: The way I implemented this does not involve these concepts. When you open the picker it focuses the option. Iterates through the list to do next/previous. That's it.
Mason: Can it be to spec that way?
Anne: I think they have to be defined separately, don't participate in tabbing. Needs to take focus away, though.
Luke: One thing that could be useful would be if we got focus-group out of this. I know it would be more complicated.
Joey: We don't want to make the author use focus-group, but this could be a building block toward that.
Joey: I'll put this perspective in for further review.
Olli: related is the activation of options. Right now it's basically mouse down?
Anne: activation behavior also has various open issues already around stuff like this where implementations don't quite match.
Olli: do we want the contents of the options to be interactable, or just static?
Anne: currently at least the content model is quite restricted.
Mason: The current situation is hard to make accessible. Might be able to address it in the future.
PA: sounds like clear next steps. Any other topics?