Focus-related behavior for <option>s inside a <select>.

[dandclark]

DOM focus doesn't function normally for <option>s under <select> as implemented today.
Calling focus() on an <option> under a <select> does nothing. Setting a tabindex on an <option> under a <select> has no effect on tab order. An <option> under a <select> never matches the :focus pseudo-class even if it is the currently selected option. The document.activeElement can be the <select> but never one of its child <option>s.

Do we want to change some of this behavior? It could be odd if <option> still has these unique lack of interaction with normal document focus if an <option> can be slotted along with normal <div>s etc that can be focusable in a normal way. It could also be useful for the developer to be able to do things like programatically call focus() on a given option as if it were any other element.

For example:

<select>
   <option tabindex="1">option 1</option>
   <div tabindex="2" >Here's something that's in the tab order but not an option</div>
   <option tabindex="3">option 2</option>
</select>

It would be strange if the <option>s behaved differently from the <div> with respect to focus, activeElement, :focus etc.

There is of course a backwards-compatibility problem here, although a potential opt-in mechanism for all new behaviors might deserve its own Issue thread.

[gregwhitworth]

Thanks for raising this and I agree with your conclusion. I also agree with back compat concerns, from a webplat perspective but as it relates to Open UI I think we should define what makes the most sense for a <select>. I think defining what you have makes sense. Mind proposing some spec text?

[gregwhitworth]

While I can't think of any potential issues for this, @alice are you aware of any potential issues for allow focus APIs to work on the <option> element?

[alice]

What would calling focus() on an <option> achieve? Or, for that matter, having <option>s in the focus order?

I see that in Chrome currently an <option> in <select size=2> is in the focus order - <options> in <select size=0> aren't rendered unless the <select> is focused, so they are excluded from the focus order.

It seems like <div>s aren't slotted into <select>s, at least in Chrome.

[gregwhitworth]

@alice you're correct, div(s) currently aren't slotted, but we're exploring that capability and so we're trying to understand the potential interactions that may occur and whether we should/shouldn't allow it. Based on the use-cases I don't see a specific need to support this, but I also don't know if it's worth prohibiting it either.

[dandclark]

Mind proposing some spec text?

As far as I can tell, allowing <option>s to be focusable inside a <select> popup would be compliant with the current state of the spec. An <option> with a tabIndex, regardless of whether or not it's inside a <select> dropdown, meets the focusability requirements in the first row of the table at https://html.spec.whatwg.org/#data-model and I can't find anything elsewhere that would disqualify it. So I think we could just switch this behavior on without violating spec.

Thanks @alice for pointing out that <option>s in a listbox/multiselect are already focusable (unless they are not being rendered). That seems to me like an extra piece of evidence that we should allow this for <select> popups too if only for consistency's sake -- with the qualifier that should only be focusable when the popup is open, else they fail the "the element is ... being rendered" bullet in the table.

Based on the use-cases I don't see a specific need to support this, but I also don't know if it's worth prohibiting it either.

I agree, I don't see any critical use cases here, although maybe a developer of a more complex custom <select> UI might find some benefit in having tight control over the tab order. I think the main point though is more of an issue of consistency: once we start allowing other content in the <select> popup, it could be confusing if <option>s had different focus behavior than 'normal' elements.

[alice]

Could you possibly point me to the discussion around allowing slotting <div>s? I think I understand the use case, but I'd like to make sure my understanding is right.

[gregwhitworth]

@alice we're actively working out a solution currently which is where these questions are rising from. We do not have a fully formal proposal for that from a web platform perspective specifically but this anatomy and the general question does apply whether the web platform allows it or if its being implemented in JS for a component library.

[gregwhitworth]

This was discussed on the most recent telecon. Here is the resolution.

RESOLUTION: make the similar to the rest of the platform and allow other platform focus APIs to work on descendants of a select

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[andrico1234]

Closing as this issue was resolved in a telecon