Upcoming WHATNOT meeting on 2025-01-16

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10878) and I will post the meeting notes there in a bit. The next one is scheduled for January 16, 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+ in all WHATWG repositories across issues and pull requests and we would like to invite anyone that can contribute to join us.

[annevk]

I would like to briefly discuss #10737 where a box was checked despite explicit multi-implementer interest not yet being obtained leading to it incorrectly being merged. While in this case it's probably fine, that's not how we agreed to cooperate.

[schenney-chromium]

I would like to discuss Issue #10884: figuring out what a get of the canvas text styles direction attribute should return: inherit or the resolved value. My primary question is whether this kind of problem has arisen elsewhere as a precedent, and what we think might be best for developers.

I'd like to involve canvas folks in next week's meeting, or a later one, to cover Issue #10862 (the lang attribute for canvas text) and Issue #10677 (additional canvas text metrics). I'm not sure of the best way to do that.

[andreubotella]

@nicolo-ribaudo and I would like to discuss the web integration of AsyncContext (#10432).

[annevk]

@whatwg/canvas ^^

[past]

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

Agenda

Attendees: Andreu Botella, Anne van Kesteren, David Baron, Emilio Cobos Álvarez, Joey Arhar, Keith Cirkel, Luke Warlow, Mason Freed, Nicolò Ribaudo, Noam Rosenthal, Olli Pettay, Rakesh Goulikar, Scott Haseley, Chris Harrelson, Di Zhang, Panos Astithas, Stephen Chenney, Michal Mocny
Scribe: Nicolò, Stephen

1. Review past action items
   1. Tantek will ping Olli and Simon for Mozilla's opinion on stage 3 for customizable select.
      1. Done.
   2. Anne will create a label to tie Revamped Scoped Custom Element Registries issues (and spec PR) together.
      1. Will add the label once many more issues are filed.
2. Carryovers from last time
   1. [Joey] Stage 3 for customizable select
      1. The next issue is still a blocker for Olli and Anne.
   2. [Joey] How to spec user interaction for select
      1. Olli and Anne will play with the Chromium implementation and review the proposal more closely.
   3. [Joey] Rendering <select> as a listbox is a one-line widget that opens a popup on iOS and Android
      1. The discussion will continue in the issue.
   4. [Mason] Add commandfor & command attributes to HTMLButtonElement
      1. Keith will continue iterating on the PR.
   5. [Mason] Add popover=hint
      1. Merged!
3. New topics
   1. Discussed the need to get explicit implementer support before ticking the relevant checkbox on PRs. This can be either written or verbal, linkable or not, but it needs to be explicit.
   2. [Andreu] TC39 AsyncContext Integration
      1. Everyone is encouraged to take a look at the issue and add comments.
   3. [Noam] Async css
      1. Carryover.
   4. [Di]: Composed live ranges
      1. Carryover.
   5. [Stephen]: Canvas TextStyles direction getter
      1. Carryover.

Action Items

1. @smaug---- and @annevk will play with the Chromium implementation and review the proposal for How to spec user interaction for select more closely.

Minutes

PA: Follow up on the action item from last meeting?
Olli: Still need to take a look more, it's tricky.

PA: Status of the second action item?
Anne: Happy to create a label if needed, and there might be a new GitHub feature to help with it. I was only planning to do it if needed.
Mason: there is a web components F2F meeting in a few weeks.

PA: Going back to Stage 3 for customizable select to talk about the blockers. Olli, can you describe your reluctancy more in detail?
Olli: It's about specifying user interaction in a good way. It's quite unusual compared to what we have in the platform right now, and I haven't read much from the WebKit side.
Anne: We have not looked at it in detail yet. The PRs seem quite informal still. They are just "if preventDefault is called then to this thing", rather than using the logic from the events spec. I don't have a good idea for how to write spec for this well.
Joey: I'm trying to move as much as possible into algorithms, hopefully that helps.
Chris: Would it help if Joey walked you through it?
Anne: Not much
Chris: Are you talking about how to write the spec, or about what the behavior should be.
Anne: Both, less clear on the spec. It's not that I don't understand what's written. Part of the problem is that we don't have a lot of precedent for defining this in detail, so defining how for example this should be defined with mouse events, how they interact, and how does it relate with the features we already have.
Chris: Can you write down the questions, so that Joey can answer them?
PA: Feel free to get into the details.
Joey: I can talk about what we specced and how I implemented it, and how we got there. The issue is that there are different goals you might have for speccing that thing, and after I posted it there was also the issue about click-and-drag behavior. In order to make it work well we wanted to listen to the mouse event instead of click. Then in a WHATNOT meeting a while ago we decided that it's an important thing to support. So we went with mouseup, and added the changes to use mouseup instead of click, and it broke some demos, because if you click the invoker button, the picker will render on top, and then when the user releases the mouse it triggers mouseup. I looked at workarounds, also the MacOS selector which works similarly, and it requires you to hold down the mouse for a long time before releasing it in order to close the picker. Also looked into making sure that both the case where the picker is below works (you can click down and drag to the first option), and I came up with a series of events I posted in the issue. The way I specced it is that the browser may fire a mouseup event on an option element, and it will cause the picker to be closed. Based on how I specced it, it's still open whether click-and-drag actually works. Also, adding things for other events to make other things work better is not part of the spec but it's technically following it.
Chris: What you said is that the spec doesn't mandate support dragging, but Chromium does and conforms to the spec as written.
Joey: Yes. Mouseup is what may select an option, so if the user wants to prevent one from being selected they can preventDefault mouseup.
Mason: They are all mouse behaviors, and not pointer behaviors (they don't happen on touch).
Anne: What happens on touch?
Joey: For click and drag, the issue is not really present. When you touch the button to open the picker, the mousedown is not fired until you release your finger, so the whole click-and-drag based on mousevents is never going to happen. Also, it's not a gesture implemented on iOS: the picker doesn't show up until when you release your finger. Supporting click-and-drag is not important on touch: if we listen to pointervents instead, we'd open the picker while your finger is still on screen which is not what we want.
Mason: These are all prototyped in Chromium, if you want to try it.
Chris: And is it in WPT?
Joey: I'm adding an optional WPT test for this click-and-drag.
PA: So the proposal from Joey is one concrete path. Are there other potential directions to consider?
Olli: And we need to think about whether there are some issues in that path. Do we handle events in the right way? When the author wants to handle some events in some way, does it work? Because this is very new in the platform.
PA: Are these questions obvious to you Joey?
Olli: These are questions to us all, I need to try out Chromium and figure out how well it works.
PA: So, you have some fuzzy concerns, but you hope they'll become concrete once you play with it?
Olli: We don't know because we never specified anything like this, so weneed to be careful.
David: Not specifying and not having interop are two different things. We have complicated things we have interop on without having them specifying, maybe more with key events rather than mouse events.
Anne: That wheelevent for input type=number is like that. When it's focuses it changes the current number in Chromium and WebKit
Olli: but only if you have eventListener somewhere in the viewport.
Anne: That's a side effect of how event dispatch works. Threre is some weird event handling already in widgets.
Olli: But not in specifications.
Anne: Part of the problem is that all these user input actions don't have an official definition anywhere. It was the goal for UI Events, but it hasn't happened yet.
PA: So, to not block Joey, AI for Olli and Anne is to look at the Chromium implementation and describe what needs to behave in a particular way.
Joey: I also described the behavior in a comment on GitHub.
Anne: Yes, the PR does a good job. That's clear, it's less clear wether it does what we want.
Chris: Would some demos/videos help?
Anne: D Baron already described it well, that's clear.
David: There are some other subtle cases, like what happens when you click and the poopup appears where the mouse is already there. MacOS makes it so that the current selected option is the one under the mouse, but on the web you can move it.
Anne: That's fair, I don't think there is an issue with that.
Anne: There are other issues with <select> that are still outstanding. Henri raised some parsing concerns about the parser resulting in duplicate nodes, and it wasn't clear if the resolution for the content model case is the correct one. It's reasonable if images are for the value and not for the value, but the thread didn't make it feel like it was carefully considered. Did Domenic actually suggest to have the fourth thing where there is a human-facing case not exposed to any API? To not expose what the value was, which is weird to me.
Joey: The thing I added to the spec is what Domenic wanted. I'll follow up to check if the concern is addressed.
Anne: I don't actually like that behavior. With the alt used for the label but not value. It's part of the contents, and if the label is not set it defers to the content, and the value too. My preference would be to alter what the content is of an option element. It's also easier for web devs with simple images and simple strings (Like country names), which could be used for label/value at the same time.
Joey: Yeah that makes sense. If there is no other text the alt text can be used as the value.
Anne: Yea. I gave an example in the issue for an option with a single image with an alt. Why do you have to duplicate it, why you don't have to if you have a simple string.
PA: Timebox. Is the next topic related?
Mason: That's a future capability. We just identified 3 things blocking stage 3:

• content model question
• user interaction patterns
• parsing problems
  Are these the only ones?
  Chris: Henri is the only one with the third concern.
  Olli: I was trying to convince Henri to think of it in a different way, that's fine.
  Mason: We all had Henri's position initially, it just takes time to get there.
  Anne: If Henri can be persuaded fine, but if he actually has something then…
  Olli: Yes we should listen.

Topic: Rendering <select> as a listbox is a one-line widget that opens a popup on iOS and Android

Joey: Old issue from Simon blocking customizable select for select multiple. On mobile, poup, inline no-popup. To make progress, need some way to render same on different platforms. Any thoughts on the issue?
Anne: Will chat with folks at next internal sync
Luke: Desirable behavior may need a switch between 2 options: list and dropdown. Be consistent across platforms with developer control. Nice if the switch in CSS to enable media queries etc. Personally prefer dropdown for multiple to have a common model for single/multiple select. Firefox even different on mobile, so no consistency.
Mason: Popup multi-select is hard to display multiple options within the page. Several possibilities, not consistent.
David: Chrome Android 2 methods phone/tablet. Tablet more like desktop. Switch between the behavior is the size attribute, combined with multiple attribute.
PA: Any more?
Anne: Anyone have metrics for how common listbox even is?
Mason: Not common for the native case. Custom probably lots.
Olli: In bugzilla very common.
Luke: Any metrics tricky due to custom and may reflect how bad existing is rather than developer needs.
Joey: 0.4% for multiple attribute.
Olli: Size?
Joey: Don't have that but would hope it's lower.
PA: Any more?

PA: Mason of Keith for Add commandfor & command attributes to HTMLButtonElement
Mason: Any comments on issue?
Anne: Thought something was there?
Mason: Response to last comment exists.
Keith: Replied. Not ready to merge yet but maybe try multi PRs.
Anne: Trying to recall. Maybe multi PRs could be good.
Amazon: What was not in PR?
Keith: Way spec defines button types is awkward and needs refactoring.
Anne: Impacts other things, such as missing constraint validation impacts.
Mason: So there's a need to clarify spec that may reveal other?
Anne: Yes.
Mason: Will help if possible.
Anne: Can share offline chat.
Keith: Will summarixe and report.

PA next topic: Add popover=hint
Mason: Done.
Anne: Anyone looking at WPT for that?
Mason: Up yesterday but blocked. Not sure why?
Anne: Firefox failures? Unstable (flakiness)
Mason: Adding tests will cause failure
Anne: Not that, tests no consistent.
Mason: Will look
Luke: Might be Azure problem
Anne: Maybe tooling not working as expected.

PA New topic …
Anne: Something to raise … Add Dialog Behvaior .. check boxes all checked, so merged, but implementor interest was not explicit. In this case WebKit is probably OK, so not asking for revert. But we should be sure that this does not happen again. Please be careful about what boxes are checked
Mason: Though support existed based on request for position. Do we need agreement?
Anne: Need implementor interest. Someone just saying "that's fine" is enough. Not as formal as standards position but should be public. Not a signal if some reviews PR. That's just making sure that spec is right, not implementor interest.
Mason: Though they had enough.
Anne: Problem is standards folks might not match implementors.
Mason: Seems like we always need Standards Positions.
Ollie: Asking on the spec issue is good enough for small things.
Anne: Often says WebKit seems fine, but has not asked internally.
Mason: But comments seemed to be in agreement.
Anne: Don't check the checkbox unless it's explicit, not just "I expect it to be OK"
PA: Meeting agreement would be fine.
Anne: Historically, has been in chat, verbally, meetings
PA: Not what Anne's objecting to.
Anne: Not concerned with the method of explicit agreement, but that there was no explicit agreement.
PA: Subtle difference because nobody is against the feature.
Anne: I didn't want to invoke the revert process for something that's noncontroversial, but I did want to bring it up.

PA: Topic: TC39 AsyncContext Integration
Andreu: Need browser support for integration. Browser side is not clear. Was to preserve state related to sync code, such as metrics, timing. E.g. handle await/setTimeout currently no way to track across interruption. Another use case to handle multiple async stuff, handle abort of promises that are no longer relevant due to reject of one thing. Have context that gets propagated across tasks. Sometimes simple, sometimes need to track flow. Proposal has document describing various different API that take callbacks and how they behave. For events, change since last meeting, rather than event listener register context, conext now relevant to whatever caused the dispatch. Async stuff needs to be propagated eg. XHR stores and returns. More complex intteractions. For initial rollout, for non sync dispatch only a limited set to track events, means browsers do not need to track all the context. Hopefully could increase in the future. For other events, when no context (e.g. click event) context variable would have initial value.
PA: Out of time. So look at PR and add comments.
Andreu: Web integration PR has merged. Some updates.
Nicolò: Will put all links in the HTML issue.
PA: Thank you all, this was very productive, see you next time.