SelectControl: Add "minimal" variant

[mirka]

Closes #57720

What?

Adds a "minimal" variant to SelectControl.

Why?

Some use cases in Data Views are calling for a borderless variant.

Testing Instructions

See the "Borderless" story for SelectControl.

Testing Instructions for Keyboard

It should still show a focus indicator when focused.

Screenshots or screencast

Ideally, the SelectControl width hugs the currently selected option. 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.)

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). It would be great if we could avoid adding this complexity now, and treat this width-hugging as a progressive enhancement until field-sizing arrives in Safari and Firefox.

As a fallback, the width will adjust to the longest option in the set. (Unlike the "default" variant, where the width takes up all the available space.)

Chrome	Firefox	Safari

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ciampo]

Code changes LGTM, although I'll let @jameskoster experiment with this component in Data Views first before approving to make sure this new variant fulfills the end goal there.

Also, I wonder if we should pick a variant name that is less literal and tied to the border, since the border removal is not the only change applied in this variant (and for better flexibility in the future). Maybe something like lean ? I'm not good at naming 🙈

[mirka]

Also, I wonder if we should pick a variant name that is less literal and tied to the border, since the border removal is not the only change applied in this variant (and for better flexibility in the future). Maybe something like lean ?

I'm not too worried about "borderless" for the moment, but "minimal" could be another possibility?

[tyxla]

Looking good 👍

FWIW I like minimal a lot, it provides enough flexibility that doesn't bind us to specific style properties like border.

[jameskoster]

+1 for the more semantic name. 'Minimal' seems good.

This implementation will work well for the filter operator UI, this one:

I'm curious to gather more thoughts on the page selection design though (cc @mtias @jasmussen), which this implementation will not serve 100% as things stand:

Two points:

• The typography is different, is there a way to avoid overrides, or would it be acceptable in this case?
• It doesn't seem ideal for each option to be so verbose, imagine a screen reader announcing options "Page 1 of 3, Page 2 of 3, Page 3 of 3..." and so on.

It might be better to do something more minimal using the inline label option:

Speaking of... the inline label option causes the select to fill the container, is that fixable?

[jasmussen]

I'm curious to gather more thoughts on the page selection design though

The design is solid enough, and I would specifically think that a minimal select could be useful for cases like that, I'd think it a primary use case. Can variant inherit text styles, instead of come with its own?

[jameskoster]

Can variant inherit text styles, instead of come with its own

That's an interesting idea.

The design is solid enough

Which one? :)

As it stands, this design would result in extremely verbose options:

The alternative would be to do something like this so the options can simply be "1, 2, 3, 4, 5...":

[ciampo]

The alternative would be to do something like this so the options can simply be "1, 2, 3, 4, 5...":

From previous conversations we should be careful in removing the "of [total pages]" text, especially given that we're already removing visual prominence from the control.

[jameskoster]

Thanks for the reminder @ciampo. If the verbose options aren't considered a big problem, then the "Page x of y" design is the way to go.

Did you have any thoughts about the type styles?

[ciampo]

If the verbose options aren't considered a big problem

I don't think so. From what I remember, verbosity in this scenario was seen as a plus, as it gave a lot of context (especially to users that don't rely on sight).

the inline label option causes the select to fill the container, is that fixable?

Looking at Storybook, think that in general SelectControl always fills the width of its container.

Not sure if it's a good idea to change the behaviour, but in the worst case scenario you could always wrap SelectControl in another HTML element (or set something like width: fit-content on it)

The typography is different, is there a way to avoid overrides, or would it be acceptable in this case?
...
Can variant inherit text styles, instead of come with its own?
...
Did you have any thoughts about the type styles?

Are you proposing that the select "trigger" (ie. the value shown by the dropdown when collapsed) uses the same styles of the control labels? Or that it inherits whatever text styles would come from the CSS cascade?

[mirka]

Speaking of... the inline label option causes the select to fill the container, is that fixable?

@jameskoster This shouldn't be the case 🤔 It should hug the current option text (Chrome) or adapt to the longest option (Firefox, Safari). Can you still reproduce?

Did you have any thoughts about the type styles?

From a technical standpoint (don't know about the design systems standpoint), I am fine with an override in this case. I'd say it's safe.

<SelectControl className="my-select-control" />

.my-select-control select {
  text-transform: uppercase;
}

[jameskoster]

Can you still reproduce?

Yup, here's a demo:

wide-select.mp4

[mirka]

Yup, here's a demo:

Ah ok, good catch. I fixed it in labelPosition="edge" (fbcbbae), but I'd say the behavior is correct in labelPosition="side". I also noticed that labelPosition="edge" cannot be utilized in the default variant SelectControl (#63586), but that's a separate issue.

[jasmussen]

Sidenote, noticed this:

const SelectControlChevronDown = () => {
	return (
		<InputControlSuffixWrapperWithClickThrough>
			<DownArrowWrapper>
				<Icon icon={ chevronDown } size={ chevronIconSize } />
			</DownArrowWrapper>
		</InputControlSuffixWrapperWithClickThrough>
	);
};

That appears to use the full-size chevronDown icon. It should use the chevronDownSmall unscaled, no? We might need to add some negative margins left and right of the icon itself, so the chevron is close to the text despite the 24px footprint. Not a blocker for this PR, just noticed.

[mirka]

That appears to use the full-size chevronDown icon. It should use the chevronDownSmall unscaled, no?

Ok, I'll make a note to follow up on this 👍

[mirka]

Does anyone have any blockers to merging this? FWIW it's as early as we can be in the 6.7 release cycle so we'll have a good amount of time to iterate on the details.

[tyxla]

Tests well in Storybook, code looks good, no blockers from my side. 👍

[ciampo]

Looking good for me, we can merge if we have the green light from the design team 🚀

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

Should we add a TODO in the code and/or open an issue for using field-sizing when available to all browsers?

[mirka]

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

Should we add a TODO in the code and/or open an issue for using field-sizing when available to all browsers?

This PR already adds the styles that will work in browsers with field-sizing implemented (Chrome), and there are no extra styles to clean up when all browsers support it. So I think we're good.

[ciampo]

🤦 I looked for field-sizing in the code, and didn't check for fieldSizing

[jameskoster]

Seems good to me!