Upcoming WHATNOT meeting on 2024-12-12

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10805) and I will post the meeting notes there in a bit. The next one is scheduled for December 12, 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.

[schenney-chromium]

My calendar says 2024-12-19. I suspect that's correct and the date here is not.

[past]

Meetings are weekly, but in alternating times. I added you to this one as well, and let me know if you'd like to be in the 1am PST slot too.

[schenney-chromium]

Thanks. I don't think I'll be up at 4am very often so no need for the 1am PST meeting.

…

On Thu, Dec 12, 2024 at 12:29 PM Panagiotis Astithas < ***@***.***> wrote: Meetings are weekly, but in alternating times. I added you to this one as well, and let me know if you'd like to be in the 1am PST slot too. — Reply to this email directly, view it on GitHub <#10825 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4M64LBRGQJWHWNYU33SBT2FHBY7AVCNFSM6AAAAABTDJFECCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZZGU3TOMZUGU> . You are receiving this because you commented.Message ID: ***@***.***>

[past]

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

Agenda

Attendees: Panos Astithas, Stephen Chenney, Penelope McLahlan, Olli Pettay, Di Zhang, Mason Freed, Joey Arhar, Chris Harrelson
Scribe: Joey with help from Mason

1. Review past action items
   1. Luke will take a look at the Dialog light dismiss PR.
      1. Done.
   2. Joey will add the proposed text to the spec PR for customizable select events.
      1. Done.
   3. Panos will ask Shu for a Chromium opinion on ShadowRealm.
      1. Done.
2. Carryovers from last time
   1. None.
3. New topics
   1. [Di] tabindex vs reading-flow property
      1. Olli will review or find someone from Gecko to review. It would be great to have Elika's review as well, since she had some concerns previously.
   2. [Joey] How to spec user interaction for select
      1. Consensus to move forward with mousedown/mouseup events for web compat and consistency with current behavior. Joey will update the PR accordingly.
   3. [Anne] Revamped Scoped Custom Element Registries
      1. To be discussed in the Dec 19 meeting.

Action Items

1. @smaug---- will review or find someone from Gecko to review tabindex vs reading-flow property. It would be great to have @fantasai's review as well, since she had some concerns previously.
2. @josepharhar will update his PR per the consensus in How to spec user interaction for select.

Minutes

topic: luke will take a look at dialog light dismiss
panos: he did leave a set of comments. anything else to do on this one?
mason: we talked about it this morning at openui and he gave another +1.
olli: click handling when you have multiple dialogs open
mason: if you find a problem let me know

topic: customizable select events
panos: joey added spec text

topic: shadowrealm
panos: i talked to shu. he brought up similar concerns to apple and mozilla. i understand there was an intent to prototype, so someone will try to implement this? for now the situation is exactly as you understood it, everyone is neutral

topic: reading-flow
panos: i understand that we want to discuss that next time so that olli can review
olli: and anne will be here
panos: ill capture that as an action item
mason: elika is also going to review right?
di: i tagged her. she hasn't commented on it yet

topic: user interaction for select
joey: see the issue - I commented a few days ago, with two options for events. There have been a few comments, but none from Apple or Mozilla folks. Olli, any thoughts?
Olli: not yet. I'm trying to figure out what the behavior should be. When the user clicks on an option, where should the click event go? I think you're proposing mouseup, which means the click goes to the option after the popover closes. That might be fine, just need to check the case where the option element has a click listener.
joey: I agree - I added a bullet for this. Developers expect the click event to work. Mason was surprised by this. Main reason to do mouseup thing is that it enables the click and drag thing. It's hard to weigh the two. Mouseup is better for users, click is better for developers and spec.
Mason: priority of constituencies does this for you: users win
Joey: what do you think? Important thing for the user - do the mouseup thing? So far two people have said they do the mousedown/drag/mouseup thing. So it is a real thing.
Olli: I'm definitely not strongly against mouseup, just need to think about it.
Mason: does that work across platforms
Joey: basically yes, Mac, Win, Linux all work on Chrome and Firefox.
Chris: seems like since it works and users are used to this behavior, we should preserve it.
Joey: mobile is a bit different, needs to be explored.
Joey: desktop this is consistently the case.
Olli: you get a mousedown right before the click event. If you just do touch down, you get pointerdown and touchstart.
Olli: maybe mousedown mouseup is fine. I think we need to use those, not pointerevents. Because you get mouse first, then pointer. To capture more legacy scripts.
Joey: with that in mind,
Chris: that user experience seems important because it's there for all platforms and browsers. So option 2 sounds right.
Olli: I think I agree. Click handling would be a bit weird. Click would happen on the option which would be weird.
Joey: developers will have to know which events to look for, but MDN will document that for them.
Olli: we should make sure selection doesn't start when you click and drag, on any platform.
Joey: let's make sure. Maybe add user-select:none to the UA stylesheet.
Olli: sounds good.
Roughly resolved among this group: option 2 (mousedown/mouseup, not click) is better, based on the priority of constituencies. Also add user-select:none to UA stylesheet for appearance:base-select.

Joey: if we want to do mousedown/mouseup instead of click, we'd need a new spec concept.
Mason: this is like dialog and popover
Joey: this is different from popover and dialog
Olli: pointerdown isn't being fired - I'll leave a comment on the PR.
Chris: could this concept be defined in the <Select> PR, and see if it works. And then if so, once we have a second use case, refactor into a new algorithm?
Joey: I'm doing this for Anne, so I want to ask him what he wants.
Chris: we could unblock by just doing it inline for now.
Joey: will do.
Olli: makes sense. Relatedly, let's say we want to do this later for date picker. Let's also test a tiny bit those other types of pickers to see if the behavior is the same.
Mason: I think <select> is the only one, but let's definitely check.
Panos: Any other thoughts?

Chris: I also want to bring up the .click() method on <select>. If we go with the above resolution, the click wouldn't cause the select to open. And wouldn't cause options to be chosen.
Mason: showPicker is there.
Chris: we'd need something to be able to select an option.
Mason: there's no way to close the picker. So we'd need either .click() or a new way to pick an option.
Olli: click() only sends an event. It's on the html element too. We should have a specific method.
Olli: is focus() sufficient?
Chris: should we file a new issue for something like hidePicker() for <select>.
Mason: what about user activation for showPicker()
Joey: autofill is unrelated to showPicker()
{discussion about what triggers autofill}
Olli: showPicker needs to be consistent.
Olli: would we consume user activation?
Mason: good question
Joey: there might be other issues. e.g. calling window.open without user activation will show the popup blocker.
Stephen: From a user perspective, if a page showed the picker upon load, that would be confusing. It's not clear to me that disallowing it isn't good.
Mason: there are some examples that are "good" like starting with the picker open.
Chris: we can start with requiring user activation and if there are use cases later, we can relax the requirement.
Panos: sounds like consensus? Anything else?
Rough consensus: don't have .click() trigger closing the popover. Instead mint a new method (on select or option) to close the picker {can be done later, if needed}. Keep the user activation requirement on showPicker().

Chris: With this in the spec, is this enough for Stage 3?
Olli: event handling - can users interact with the content of the element.
Chris: you mean interactive elements?
Olli: e.g. contenteditable?
Chris: that violates the content model.
Olli: maybe ok. Maybe this is the last issue holding back stage 3. The styling part - not sure how much time that'll take.
Joey: the styling could be already done. There's a complete proposal.
Chris: is it correct to say that nobody raised specific concerns. We just need to check that all properties are justified, etc.
Joey: Elika tweaked some numbers, Jen asked for the presentation I gave, Emilio seems like he doesn't like flex but Tab thinks flex is table stakes. I like the flex. Emilio hasn't commented since. Those are the only concerns I've heard.
Panos: want to bring stage 3 back up next week?
Joey: Yep!
Olli: I still need to ask Henri about the parser.
Chris: the standards position says positive, with a caveat about the parser.
Olli: I need to ask him. I didn't see any issues, but he is very careful.
Panos: Please tag it for next week, for stage 3.
Olli: the spec PR doesn't fire pointerevents. It should also hint at keyboard behavior like arrow keys and home/end, etc. I don't know how exactly to specify those.
Joey: want to chat about pageup/down?
Olli: Current select element does support those.
Joey: yes. If you're focused on the button (at least windows/linux Chrome) if you do Home, it'll change the selected option to the first, Page up/down do things. When picker is open, home/end do the same thing, but pagedown/up go one viewport page down.
Mason: these shouldn't do anything while the picker is closed.
Olli: testing the Chrome prototype, hitting pagedown was scrolling the page, not the picker. Should work on the picker. Want something about this in the spec.
Joey: add paragraphs like mousedown/up that say "the user can do an action that scrolls to the top", etc. without saying Home or PageDown, etc.
Olli: can be a non-normative note with examples about what happens. Should be able to read the spec and implement what other browsers do. Like "browsers typically …".
Joey: ok I'll add that.