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.

[josepharhar]

Perhaps we can make something like this paragraph that's already in the spec? https://html.spec.whatwg.org/multipage/form-elements.html#concept-select-pick

How does this sound for opening the picker?

If the select is being rendered as a drop-down box, then the user agent should allow the user to open the picker. Opening the picker will either fire a corresponding mousedown or keydown event on the select element. Calling preventDefault on either of these events will prevent the picker from opening. Otherwise, the picker is opened.

[smaug----]

One thing to define is how click works on options - current Canary dispatches click to the common ancestor of option and whatever happens to underneath the popup. I would expect click to be dispatched to the option element itself. So, activation behavior, not something else. I think the spec pr even expects this, so it might be an implementation issue, but are there tests for this?

[smaug----]

I think the expected behavior from user's point of view when dealing with Home/End/PgDn/PgUp is that those would change focus between option elements, similarly to arrow keys. Maybe some of that could be left up to the implementation, though when testing Canary, which doesn't deal with those, select does feel a bit broken.

Do we need to consider anything special for mobile? Currently select popup is a native popup there, I think in all the browsers.