How to spec user interaction for select

[josepharhar]

What is the issue with the HTML Standard?

As part of customizable select, there is desire to add something to the spec that explains how the user can interact with the select element. There is already some paragraphs related to choosing options, which basically just says that input and change events should be fired after the user chooses an option.

Potential actions:

• Activating the button to toggle the picker open/closed
• Choosing an option
• Navigating between options (arrow keys)

Potential requirements:

• What events are fired in each case?
  • Are we allowed or disallowed from talking about pointerup, pointerdown, mouseup, mousedown, keyup, keydown, keypress, and click in the spec?
  • Can/should we talk about the details of these events, such as what the key property of a relevant KeyboardEvent should be?
• Is there a consistent set of events? Or might they be different depending on input mode or platform? (keyboard vs mouse)
  • Should we provide a list of different events that input modes or devices can choose from?
• What does calling preventDefault on any relevant events do?
• What elements are the events fired on?
  • For actions related to options, I would hope that we can fire the events on options rather than the select element.
  • More generally, I don't want to change the fundamentals of how keyboard and mouse events work in web content inside the picker popover in the browser.
• Making everything the same for appearance:auto and appearance:base
  • [select] keyboard behavior openui/open-ui#1087 (comment)
  • I could imagine that it could be hard or not compatible to patch this event behavior into native pickers, but who knows.
  • There are also platform specific variations, like the selection-follows-focus and click-and-drag behaviors for select elements in chrome on windows and linux.
• Ending up with some way of opening the base appearance popover without user activation, whether that's select.click() or select.showPicker()
  • Is it ok for appearance:base <select> not to require user activation before showPicker()? #10604
  • select: use cases for opening the picker without user activation openui/open-ui#1127
• Hopefully we can end up with something that is actually testable in WPT with existing things like test_driver.click() and test_driver.Actions(), so that all the tests I've written so far don't just become non-interoperable suggestions.

Potential solutions:

• Use activation behavior
  • Would make things like select.click() and option.click() work
• Patch pointer events like we did for popover light dismiss
• Just say that the user agent must provide a way to do these things, like the existing "concept-select-picked" spec

[josepharhar]

@domenic @annevk @smaug----

[annevk]

I think it's important context to state why this is important: the popup is not script-observable without appearance: base. E.g., keydown is not fired when cycling through options.

[josepharhar]

At whatnot we discussed this, and it sounded helpful to start by providing a list of situations where preventDefault would change the behavior. There was also a discussion about reusing the popovertarget activation behavior to open the popover picker.

[annevk]

FWIW, when I played with this yesterday it seems that pressing the down arrow on a closed select element does fire a keydown event on the select element (and opens the picker). So that at least is already exposed regardless of appearance.

[smaug----]

Sure, the focus is in that case on select. In the new case the focus is on option elements.