Upcoming WHATNOT meeting on 2025-01-09

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10861) and I will post the meeting notes there in a bit. The next one is scheduled for January 9, 3pm PST. Note that this is 1 week later in an Americas + APAC 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+ in all WHATWG repositories across issues and pull requests and we would like to invite anyone that can contribute to join us.

[past]

Hey @whatwg/triage, the agenda is sparse for this instance and I intend to cancel it if no new topics are added by EOD tomorrow.

[josepharhar]

How about these?

• stage 3 for customizable select Customizable <select> element #9799
  • I addressed the user-select and alt text issues brought up at the last meeting
• mouseup event handling workarounds How to spec user interaction for select #10762

[gaynbres]

Ayuda para recuperar un archivo

[past]

How about these?

• stage 3 for customizable select Customizable <select> element #9799

  • I addressed the user-select and alt text issues brought up at the last meeting

• mouseup event handling workarounds How to spec user interaction for select #10762

I already had the first and I added the second now, thanks. That said, these are the only topics for this instance and RSVPs are light too. Happy to keep the meeting if it will be useful to you though.

[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 #10906):

Agenda

Attendees: Joey Arhar, Panos Astithas, Tantek Celik, Dan Clark, Dominic Farolino, Mason Freed, Chris Harrelson, Chris Wilson
Scribe: Chris Wilson

1. Review past action items
   1. Anne will create a label to tie Revamped Scoped Custom Element Registries issues (and spec PR) together.
      1. Carryover.
   2. Dom will update Introduce moveBefore() state-preserving atomic move API with the stage 3 label.
      1. Done.
2. Carryovers from last time
   1. [Joey] Stage 3 for customizable select
      1. There are no known open issues to discuss. Please raise them if you know of one. Tantek will ping Olli and Simon for Mozilla's opinion here.
3. New topics
   1. [Joey] How to spec user interaction for select
      1. Skipping this week since Olli is out.
   2. [Joey] Rendering <select> as a listbox is a one-line widget that opens a popup on iOS and Android
      1. We had a good discussion and will continue the discussion next week to get more perspectives.
   3. [Mason / Keith] Add commandfor & command attributes to HTMLButtonElement
      1. Carryover.
   4. [Mason] Add popover=hint
      1. Carryover.

Action Items

1. @tantek will ping Olli and Simon for Mozilla's opinion on stage 3 for customizable select.

Minutes

PA: First item, Anne on Revamped Scoped Custom Element Registries. Haven't seen the label applied, let's carry over. Dom did update the moveBefore atomic state API with stage 3.
PA: Tantek, any Mozilla opinion on Stage 3 for customizable select?
T: haven't prepared for this, would prefer to defer to Olli/Simon. I'll ping them.
PA: Joey, How to spec user interaction for select?
JA: skip. On Rendering <select> as a listbox is a one-line widget that opens a popup on iOS and Android, interested if anyone has ideas of what to do here. If we don't add anything it'll have to be a button with popup on mobile and an image thing with those on desktop, which I don't think is acceptable. Anne seemed to point to underlying previous fixes; not sure I could find useful context from that.
T: I think just giving developers control is going to wind up in the same place.
MF: existing select single doesn't do that; it gives dev full control over the popover (though it's always a popover). My mental model for select-multiple, with the parent base, is that if it's always in the page, it's trivially easy for the developer to put a button in the page. Not sure if that aligns with what you suggested, T.
T: These are just suggestions for interaction-mode.
MF: on a new device, you can render it yourself if you want to, but I think the nuance is that we want to capture all the systems we know about today and what happens, and let developers control it.
DC: we're not competing against native control, but against devs having to roll their own for multiple select. If we build something that doesn't let developers control what it looks like, they'll just go back to rolling their own.
TC: I think we're getting stuck on the term "control". We do want to give the developer a way to suggest "this is what I want" but have the provision that this is a suggestion, and the UA may come up with a reason it should look differently .
PA: Joey, any next steps you want to capture here?
JA: no. I still don't have any ideas other than another attribute to solve the problem of platform specific rendering rules, so if anyone has ideas…
TÇ: do we already have established hints-vs-attributes methodology?
JA: not really; switching of modes from in page things to popup via CSS is difficult or impossible. As a result of an attribute change it's possible. I'd like to hear from Anne on this.
PA: will carry over. Also carry over final topics from Mason, as they need Anne. Thanks all!