Component: Select

[patrickarlt]

Esri/calcite-web#1017 and Esri/calcite-web#1021

Also See: https://ionicframework.com/docs/api/select

[macandcheese]

For reference here is how Material handles this... https://material-components.github.io/material-components-web-catalog/#/component/select they allow both a native and an "enhanced" select which would visually match what our dropdown looks like.

[patrickarlt]

I think we still need a disscusion about what want this componetn to look like. @pr3tori4n got a really good start on this in #44 but has to put it on hold. We never really got a solid idea of what we want the the UI and API for this component to look like and given discussions around what other things like dropdowns should look like that has happened in teams I still think we need to spend more time defining what we want selects dropdowns to look like.

After looking at what @macandcheese posted about Material Designs select I think we have a pretty good idea of what <calcite-select> should look like based on:

• https://material.io/develop/web/components/input-controls/select-menus/
• https://material-components.github.io/material-components-web-catalog/#/component/select

I think that our own <calcite-select> should look like this:

<calcite-select>
  <select name="foo" >
    <option value="bar">Bar</option>
    <option value="baz">Baz</option>
    <option value="zip">Zip</option>
    <option value="zot">Zot</option>
  </select>
</calcite-select>

This should use the native <select> element for the active states similar to the un-enhacned Material design selects this allows for good a11y support and native controls on mobile.

I also think we should support a mode property that would support 3 values:

• standard - use the native <select> element for active states for the best possible accessibly and mobile UI. This should use the "Idle", "Hover" and "Clickdown" state from the the updated Calcite Dropdown UI and the standard <select> UI for the "Open" states
• enchanced - use the "Open" and "Open Hover" states from the updated Calcite Dropdown UI
• auto - come up with predicates to try to automatically switch between standard and enhanced modes depending on User Agent Strings and touch support.

For example:

<calcite-select mode="enhanced">
  <select name="foo" >
    <option value="bar">Bar</option>
    <option value="baz">Baz</option>
    <option value="zip">Zip</option>
    <option value="zot">Zot</option>
  </select>
</calcite-select>

<calcite-select mode="auto">
  <select name="foo" >
    <option value="bar">Bar</option>
    <option value="baz">Baz</option>
    <option value="zip">Zip</option>
    <option value="zot">Zot</option>
  </select>
</calcite-select>

In addition I think we should also support a style property would would accept standard, small, colored from the updated Calcite Dropdown UI. Colored would correspond to "White" in the Calcite styles but be with a light/dark theme and we could also allow custom colors via CSS properties.

@macandcheese I still have a lot of questions around the updated Calcite Dropdown UI. For example:

• Does the "Dropdown" text change to reflect the selected value(s)?
• Does this support selecting multiple values? for example should we support <select multiple>?
• Can we add a "Small White" style?

I also think that we should save the "Navigation Dropdown" pattern for a separate component. I also think that we need to be strict here. <calcite-select> is PURELY for wrapping native <select> elements in custom styles, nothing else.

[patrickarlt]

I think we need to limit our scope on this to avoid things getting crazy with people wanting thing like multi select menus (#46), filtering selects filter dropdowns ect...

[patrickarlt]

It isn't that I don't want to do stuff like multi selects, search ect... but I think we need to make forward progress rather then bike shedding these components.

[kumarGayu]

IMO those are new component. but might use some styling concept from this component.

[macandcheese]

OK, pardon the super quick and sloppy mockups, but this is how I've been thinking about these components. The first two are pretty straightforward, the last one I think needs more design consideration, and is composed of some other components, but shouldn't hold up work on the first two.

[patrickarlt]

@macandcheese I really need to see what you "real" mockups look like because those are ~100x better then my best mockups most days. 😄

I REALLY like the components in #2 (comment) and it lines up pretty well with what I proposed in #2 (comment). Looking at the designs it looks like we should also support <select multiple> and <optgroup> in both <calcite-select> and <calcite-multi-select>/<calcite-filtered-dropdown>. I'm going to propose we call this <calcite-search-select> OR we add a searchable boolean to <calcite-select> but that would mean that <calcite-select> is going to be HUGE and COMPLICATED so I think a separate component would be better.

@macandcheese a few questions:

1. Would the "Selects" component above support selecting multiple values and displaying them? is is hard to tell if the middle example is a hover state or is both "Yellow" and "Black" are selected.
2. What is the purpose of the chips in the second Multiple Select example? If they are meant to represent the items I have selected are the always visible? I really like the UX of the first mockup much better.

[macandcheese]

Would the "Selects" component above support selecting multiple values and displaying them? is is hard to tell if the middle example is a hover state or is both "Yellow" and "Black" are selected

Yep, that was an oversight, we'd need to handle multiple values in the "input" field or otherwise style a semantic <select multiple>... Since the "input" in those designs is just a standard CW input and not managed by this component, we will need to handle that somehow. This is currently what a CW <select multiple> looks like:

What is the purpose of the chips in the second Multiple Select example? If they are meant to represent the items I have selected are the always visible? I really like the UX of the first mockup much better.

Functionally they are the same as in the example to the left, they provide a way to "untoggle" selected items - that was just a different design idea. In that example, the "drawer" they are contained within would be visible when the "typeahead results" are not visible so users could always dismiss items.

I do kind of like the one of the left as well, but you can get in a weird "narrow input" state depending on length and count of selected chips, and when it breaks to two lines it can also be weird... The one on the right lets the input always maintain width / height while the drawer beneath handles multiple chips better (IMO anyway, ha)... We can work on the design and UX of that component in a separate issue from <select> or <dropdown> - I have an old Sketch file with a handful of other directions, but functionally they all do the same thing: match the functionality of https://esri.github.io/calcite-web/documentation/patterns/#filter-dropdown while: 1) not requiring a user to "click into" the component to show the input field (always show the filter input field) 2) keep the chips visible in addition to the typeahead results (the current CW implementation appends them behind the results which is kind of weird IMO).

I think a separate component would be better.

100% agree, and should coincide with updated chips, which could be used here and in a few other areas : #47

[patrickarlt]

As discussed in yesterdays meeting I'm closing this issue. It appears there wasn't much interest in building an "enhanced" select unless we also built the full mobile sheet UI which is pretty unnecessary considering we get it for free in browsers and <select> elements are fairly easy to restyle and already styled in Calcite Web.

This could be reopened later if we decide the full "enhanced" select experience is worth it.