SelectControl: Add borderless prop

[jameskoster]

As noted in #57670, a couple of UI concepts in the data views work call for a SelectControl with reduced visual prominence. Two examples are; operator selection in filter configuration, and the page selector in pagination:

We can get halfway there by using the small size, but it would be good to have a built-in way to hide the border as well.

[ciampo]

It looks like that border is inherited from InputControl. Is having borderless controls a need that we should consider for the wider group of controls in the package? (cc @mirka )

Not my area of expertise, but have we considered the potential accessibility implications of a borderless dropdown, especially for visually impaired users? (cc @andrewhayward )

[jameskoster]

Is having borderless controls a need that we should consider for the wider group of controls in the package?

It seems unlikely there would be a need for other controls to omit the border, largely because they lose their identity with out one. A borderless SelectControl can work (in theory) because most of the time the chevron will be present and this helps indicate the purpose of the element.

Hopefully appropriate labelling, hover and focus styles can handle the accessibility requirements, but let's see what Andrew says.

[ciampo]

@mirka in terms of APIs, what do you think about adding a variant prop with type undefined | 'unstyled' ?

[mirka]

@mirka in terms of APIs, what do you think about adding a variant prop with type undefined | 'unstyled' ?

It is a possibility, but we should first assess whether the borderless style makes sense with all the available sizes/paddings, labeling options, multiple, prefix/suffix, etc. If not (which I predict will be the case here), it would be a lot simpler to make a thin facade component with a limited subset of props.

[jameskoster]

The use cases that have arisen essentially call for a select with a smaller footprint and less visual prominence. So the likelihood of the options you mention being required is minimal. If that points to a 'facade component' then I think it could work.

[ciampo]

it would be a lot simpler to make a thin facade component with a limited subset of props.

That's also a possibility. Do you think that component should live in @wordpress/components ?

[mirka]

Do you think that component should live in @wordpress/components ?

Yes, I think it's pretty generic. We can keep it locked while we work out the requirements.

[ciampo]

I think we can treat #58195 as a place to experiment with such a component's requirements, especially when striking the balance between minimal looks and accessibility.

[mirka]

@jameskoster I'm working on this right now, and I have some important questions about the adaptive width.

All the mockups for this borderless variant suggest that we want the select width to adapt to the width of the currently selected option.

• Q1: How critical is this styling feature?

  • To implement this for all browsers now, we need to add a bit of JS complexity (inject a hidden select with only the selected option, get its computed width, then explicitly set the width of the actual select).
  • There is a CSS field-sizing property in the pipeline that does exactly what we want, and it's shipping in Chrome but we're still waiting on Safari and Firefox. (They are both planning to implement it though.)
  • It is trivial to achieve a rough width fit, where the select width is equal to the longest option in the set.

  Is it acceptable to use field-sizing in Chrome and fall back to a rough width fit on other browsers until it's implemented? Or is it critical to have an exact fit on all browsers right now?

• Q2: Will we always want this fit when isBorderless?

• Q3: May we sometimes want to use this fit when not borderless?

[jameskoster]

This style variant is typically for cases where the select should be less visually prominent, so yes I think ideally the width of the resting state should 'hug' the chosen value. It's probably important from an a11y standpoint too... if the chevron is too far from the value then the nature of the control is less obvious.

Perhaps we start with field-sizing, and await feedback from Safari / Firefox users?

Q2: Will we always want this fit when isBorderless?

I would say so, yes.

Q3: May we sometimes want to use this fit when not borderless?

I can't think of a situation where we would right now.

[ciampo]

Slightly unrelated, but should we have a variant prop instead of a boolean borderless prop? That would probably give us more flexibility in the future.

[mirka]

Slightly unrelated, but should we have a variant prop instead of a boolean borderless prop? That would probably give us more flexibility in the future.

I was considering keeping the border a separate boolean if we're going to allow "à la carte" styling with the width hugging, but since we're going to couple the borderless styles with width styles, I think it's better to do variant like you said.