[select] To what extent should customizable select implement the old <select>'s interface?

[dandclark]

This is a broad question that we've danced around in the past, but I think we need to settle on a direction for the new customizable <select>'s interface.

I see two competing directions:

1. Customizable select (I'll use the working name <selectmenu>) should have the same interface as the web platform's old <select> to the extent that this is possible.
2. We should design customizable <selectmenu>'s interface from scratch, ignoring any precedent set by old <select>.

Thus far the content at https://open-ui.org/components/select has mostly followed approach (1), where the set of properties is basically a copy/paste of old <select>. Advantages of this approach are that developers already familiar with <select> would be able to learn the new <selectmenu> more easily, and pages written with the old <select> could more easily be converted to use the new <selectmenu>. Unnecessary differences between the two element types could be a source for confusion.

On the other hand, the new element is a good opportunity to improve or modernize the old <select>'s interface. For example, @domenic pointed out here that HTMLOptionsCollection is a legacy "fake array" type, and introducing new instances should be avoided.

Should we consider drafting an IDL for <selectmenu> from scratch? Or use basically the same IDL, with some edits to remove or replace legacy stuff like HTMLOptionsCollection? Or something in between?

I have a slight preference to start from scratch and at least see what we can come up with, but I'd like to hear thoughts from others.

[domenic]

+1 to starting from scratch, carrying over only the good parts. To me that's one of the biggest benefits of using a new element type.

I'd suggest

• disabled, form, name, labels, and validity checking interfaces as common to all form elements

• required, multiple, and autocomplete if <selectmenu> supports them; I'm not sure what the latest thinking is especially on multiple.

• type I'm not so sure about; all form controls have it, so probably <selectmenu> should? But <select>'s precedent of "select-one" + "select-multiple" is very strange, and I've never heard of anyone actually using type, so I dunno.

• I honestly don't remember what size does (and it's not so obvious from the spec) so you'd need to figure out something there.

• Probably do not have any of the child manipulation stuff (options, length, named and indexed getters and setters, add(), remove()). The DOM itself is good for that. You could contemplate an ObservableArray<HTMLOptionElement> but I wouldn't.

• selectedOptions (or selectedOption if you're not supporting multiple) seems good

• selectedIndex seems not so useful comparatively and I'd drop it (and it seems actively bad if you're supporting multiple)

• value seems likely too useful to omit, although again it's problematic if you're supporting multiple.

[melanierichards]

Agree with a principled approach of:

1. Start with select
2. Inventory interfaces, evaluate what to keep ("the good parts")
3. Evaluate what is missing/odd behavior and seize the opportunity to do something better

We should be mindful that updating <selectmenu>'s interface will impact:

• User agent implementation details
• Developer experience: we may want a principle that roughly says, "if we create inconsistencies in the DX from <select>, those changes should be meaningful in that they unlock new, desirable functionality or address old pain-points or confusion". Even a good change is something that developers will have to keep track of, particularly with progressive enhancement…I could see this principle being an artificially high bar, though, so it's certainly up for discussion.
• Potentially, the user experience: we should be most careful with this category and should validate with user research depending on the change. Thinking here of things like typeahead behaviors that sort of blur the lines between a combobox and a selectmenu. Perhaps I'm thinking about this at too broad of a scope, though e.g. whether to support multiple would be relevant here.

[css-meeting-bot]

The Open UI Community Group just discussed [Popup] To what extent should customizable select implement the old select's interface? #380.

The full IRC log of that discussion

<hdv> topic: [Popup] To what extent should customizable select implement the old select's interface? #380
<hdv> Github issue: https://github.com//issues/380
<hdv> dandclark: so there's two sides to this: one is the behavior should be pretty much like the old select
<hdv> dandclark: if you have two select elements that are similar to the dropdown idea and they have different properties that is a little suspicuous
<hdv> dandclark: the other side: it could be a good opportunity to introduce a new element that fixes some mistakes from the past
<hdv> dandclark: this could be a good chance not to repeat mistakes from the past
<hdv> dandclark: so, with select, do we want to fix mistakes from the past, or start from scratch?
<hdv> dandclark: what I took away from melanierichards last time, we shouldn't hesitate to fix problems from the past, but if things to do work we can keep them
<hdv> dandclark: today I'd like to discuss what general direction to take
<hdv> Zakim, please draft minutes
<Zakim> I don't understand 'please draft minutes', hdv
<melanierichards> q?
<hdv> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2021/08/05-openui-minutes.html hdv
<hdv> bkardell_: I think there is a balance to be had here
<hdv> bkardell_: I'm in favour of staying weird most of the time. We have things that are weird, but at least you only have to learn the weird thing once and not twice
<hdv> bkardell_: I think developer sentiment and adoption is very important here. Because we're speculating what to do from a technical standpoint, but it's important what developers are going to grok
<hdv> bkardell_: and what has most chance to be adopted
<hdv> bkardell_: I also think that this has a relationship to which things have 'design affordance controls'
<hdv> bkardell_: for instance, selects could be presented modally, like on mobile, but it could also presented as checkboxes or radios on larger screens, there are lots of ways to display the same thing
<nicole> q
<una> q+
<hdv> melanierichards: if I'm interpreting correctly… you're saying we could check temperature with the broader dev community
<nicole> q+
<hdv> ack bkardell_
<melanierichards> q?
<hdv> bkardell_: so I think we should learn from the past but not be bound by it
<hdv> bkardell_: sooner rather than later we should try to articulate that and see if developers can agree
<hdv> una: we do have some input from the community, we asked what they're struggling with and forms is on the top of that list, specifically styling forms
<hdv> una: so not sure if the community cares about implementation details, but they do care about easy of use
<hdv> una: the select dropdown is unlike many other form elements… you can style a text box but you cannot style a select menu
<hdv> una: there is always a million use cases that don't fit inside that mental model
<hdv> una: we have to keep focusing on simplicity I think
<hdv> bkardell_: so for context, we were talking about the IDL for this
<hdv> una: keeping it simple would be ideal
<masonf> q+
<hdv> melanierichards: I think the main crux to this conversation…  dandclark and @@@ were working on prototyping select, and wondered whether the interface should match select
<hdv> ack una
<hdv> ack nicole
<hdv> nicole: first point I wanted to make… we'll have to take a lot of these things on a case by case basis
<hdv> nicole: we asked developers what they would want to see improved, and the answers varied a lot depending on what control it was about
<hdv> nicole: I also wanted to +1 to what una said, that styleability of forms control came up as the first thing in the surveys
<hdv> nicole: the second thing that came up often was people wanted to control the contents of select menus / options
<hdv> nicole: so making things styleable right out of the box, without having to do something weird like `appearance: none` is what people are after
<hdv> ack masonf
<melanierichards> q?
<hdv> masonf: I wanted to come back to the API shape… I think it would be fine to depart from the API of the original <select> where it makes sense
<hdv> masonf: where we depart from it, we should have good motivation for it
<hdv> masonf: if there's something bad, we should feel ok to diverge from it
<hdv> bkardell_: we should lower the barrier for people to give feedback… so it will help if we describe in detail what we were thinking
<hdv> melanierichards: are we already doing that in our process or is this something that needs to change?
<una> q+
<hdv> bkardell_: I think dandclark and masonf are going to take a crack at developing some kind of API shape… and that will involve some choices
<melanierichards> q?
<hdv> bkardell_: we probably agree it does not need to be exactly the same as the last… but I do think we want to articulate clearly why some of the shape is not the same as the original thing
<hdv> ack una
<hdv> una: also wanted to add to that… we should make it very clear to user why they would use one version of the other… there should be some very clear differentation
<hdv> melanierichards: before we go to the next issue, what is the takeaway we can give to dandclark ?
<hdv> nicole: I agree with una, we want to make sure they are different… but can be tricky because some things are already used and it is not possible to fix them in place
<hdv> nicole: so we want to be careful when we ship that we differentiate… but sometimes we can't fix aspects of the ones that already exists
<hdv> una: that's probably part of the issue… when we have something that we can't change because of backwards compatibility… we shouldn't ship something that is the same, there should be a clear differentatior
<hdv> nicole: maybe the takeaway is we need a one page doc or something, have written down, so that we can ensure it matches the idea everyone has in their heads
<hdv> melanierichards: what I'm hearing… people feel we need to take a decision on a case by case basis… we should be careful not to try and find one overarching principles. If we diverge from the existing select, we want to make sure it is intentional and we should document it.
<melanierichards> q?
<hdv> melanierichards: what do you think belongs in that one pager, nicole ?
<bkardell_> q+
<hdv> nicole: I think a set of steps… if there's anything we can fix in place, we should do it. Then, if we can't do that, we should make sure we can differentiate it and make sure we can demonstrate when to use one and when the other… 
<hdv> nicole: in cases where we think we want to make a change, we should try and document our reasoning about it, maybe even as part of the research
<melanierichards> q?
<hdv> ack bkardell_
<hdv> bkardell_: listening to nicole, I thought what nicole said and what una said about differentation weren't the same use of the word… 
<hdv> bkardell_: one is somewhat similar-ish, but falling short of a thing or to… the other is, we create something that is completely new vs the old thing. Which were you thinking of una ?
<hdv> una: I think if we have distinct elements, we need distinct use cases
<hdv> nicole: like select and selectmenu ?
<hdv> una: yes or popup… from a user's perspective the use case is different
<melanierichards> q+
<hdv> bkardell_: in my head I was thinking of those differently
<hdv> bkardell_: I was thinking about… if we would have <tooltip> in addition to <popup> it would be two new elements
<melanierichards> q-
<hdv> una: the use case is different, so one element would be styleable the other not
<hdv> melanierichards: so it sounds like a one pager would be good, that people could respond to on a PR or something
<hdv> melanierichards: is there anyone who would like to volunteer on that?
<hdv> una: could also start as an issue
<hdv> melanierichards: maybe respond to the issue we're currently discussing
<hdv> nicole: I could do that
<hdv> bkardell_: will there be a bullet in that document that addresses the issue we started with? how closely should a new element follow the old element in terms of its API shape?
<hdv> nicole: we're probably going to discuss my first version

[stubbornella]

Capturing the principles we discussed today and were added to the issue. Please consider this a bad first draft to be heavily edited. :) This will eventually go in "principles" on the open-ui site. In trying to write this down, I think @melanierichards really nailed it above. I'll highlight her point.

If changing the interface creates inconsistencies in the DX from <select>, those changes should be meaningful in that they unlock new, desirable functionality or address old pain-points or confusion.

Don't feel obligated to keep parts of the interface that don't make sense, but also don't make unnecessary changes. Consider the following when deciding whether or not to carry forward an existing control's interface:

• Does the old interface makes sense? (we should define "makes sense")
• Would changing the interface improve the UX, based on UX Research?
• Is the interface is common to all form elements like validity checking?
• How frequently the interface is used?
• Does the interface do something sensible, predictable, and reasonable in the context of the new control?
• Are there generic APIs that deliver the same functionality as the control specific interface? Ex. Rely on DOM methods when possible for child manipulation
• Align with developer sentiment.
• Is this interface used in popular implementations of the control in the ecosystem/popular frameworks? Do those implementations expose a similar interface?

Process when choosing to diverge

• Add a description to the research in Open-UI outlining why the decision was made to change the interface/control

[stubbornella]

@domenic do you mind checking if I properly abstracted the principles from your example.

[bkardell]

I am really supportive of the idea of trying to outline principles like this, so I'm happy to see this started. I'd like to try to rephase/clarify my comments from the meeting which I think helped us wind up here but I think were slighly different (probably poor articulation on my part), because I still think they are important, but am not sure if we discussed/agree on it...

It seems to me we have broad agreement (including from me) that we should approach this as something like "inspired by prior art in the platform where pracitical, but free from unnecessary or unfortunate baggage". However, that's a somewhat fuzzy as a statement, and easy enough to agree with. At the end of the day, we will be proposing a very specific API - some developers will learn about it when it is still words or filed as an intent somewhere. We know they will have questions and reactions. I have seen a lot of things go badly on either end of that and intended to suggest that once we had concrete ideas ("here is the IDL") on this specific API, we should not consider it "baked".
That we should specifically try to go out and explain why we made those those particular choices in a way that is simple and accessible... "Here is a specific proposal, and we know there are likely to be questions - some things will feel familiar, some are new -- here are some answers to questions we expect you'll have, and we'd like to field more questions or hear feedback"
.

[domenic]

@domenic do you mind checking if I properly abstracted the principles from your example.

Which example are you referring to?

[gregwhitworth]

Since I missed this session, I'm curious what the concrete scenarios for <selectmenu> are that we're referring to? As the principles seem to be what we're already doing for <selectmenu> or am I missing something?

[korenevskiy]

Hello. what do you think? Do you think this could be an analogue of the new "Fully stylable and accessible selects https://codepen.io/captainbrosset/pen/jOGVebx " function, it seems to me that it is very similar in many ways #283 , but at the same time it has wider possibilities. We can use Labels as options for the text field. This way we will get an expandable SELECT, but we can also design many other new controls.

[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.

[josepharhar]

Thanks for the feedback domenic. I believe that the current selectmenu implementation agrees with all of your points, especially since we aren't handling multi-select with the current selectmenu element

disabled, form, name, labels, and validity checking interfaces as common to all form elements

disabled, form, name, labels, and checkValidity have been implemented.

required, multiple, and autocomplete if supports them; I'm not sure what the latest thinking is especially on multiple

required is implemented.

We aren't going to do multiple for now. We might use a different tag name instead of multiple when we do multi-select.

Autocomplete will be supported when we implement autofill support: https://bugs.chromium.org/p/chromium/issues/detail?id=1427728

type I'm not so sure about; all form controls have it, so probably selectmenu should? But select's precedent of "select-one" + "select-multiple" is very strange, and I've never heard of anyone actually using type, so I dunno.

Type is supported and returns "selectmenu". I'm not worried about extending it for multiple if we reuse the same element for multiselect since I don't think its likely, but if we do, then I guess we could extend it like select does "selectmenu-multiple"

I honestly don't remember what size does (and it's not so obvious from the spec) so you'd need to figure out something there.

The size attribute is for multi select right? The current selectmenu element doesn't support multi select and doesn't implement the size attribute, and I think we should keep it unsupported.

Probably do not have any of the child manipulation stuff (options, length, named and indexed getters and setters, add(), remove()). The DOM itself is good for that. You could contemplate an ObservableArray<HTMLOptionElement> but I wouldn't.

Selectmenu does not implement any of these

selectedOptions (or selectedOption if you're not supporting multiple) seems good

selectmenu.selectedOption is supported and implemented

selectedIndex seems not so useful comparatively and I'd drop it (and it seems actively bad if you're supporting multiple)

selectedIndex is not supported

value seems likely too useful to omit, although again it's problematic if you're supporting multiple

value is supported

[josepharhar]

If anyone has any further suggestions for things to implement or not from the existing select element, please open new issues. I don't think that there is any further actionable feedback in this issue