Adds this experimental control to the components package's private apis so it can be leveraged in the block editor

Continuing the conversation from #57331 (comment), the new version of CustomSelectControl is under active development, and therefore at the moment it would be best not to use this component outside of the editor.

Still, we can gather the requirements that consumers may encounter, which may inform the next steps in shaping the component's public APIs.

Looking at the list of suggested additions:

• Updates the component to wrap the control's label in VisuallyHidden if the new hideLabelFromVision prop is true

This makes sense, although we need to be careful when doing so since control labels are actually quite an important accessibility feature (@andrewhayward )

• Merges any new popoverProps value with the components existing values for gutter, sameWidth and store then passes those through to the underlying components

What is the reason for exposing the whole popoverProps object? What popover prop would you like to access?

This makes sense, although we need to be careful when doing so since control labels are actually quite an important accessibility feature

Definitely! I'm curious about the best way to handle it since the hideLabelFromVision currently exists in CustomSelectControl so I've also added it in the draft for the legacy adapter, for backward compatibility.

Thanks for the extra information @ciampo and @brookewp 👍

and therefore at the moment it would be best not to use this component outside of the editor.

I take it this meant "outside of the components package?" Otherwise, the editor is exactly where I want to use it 🙂

This makes sense, although we need to be careful when doing so since control labels are actually quite an important accessibility feature

This PR followed the approach used in the BaseControl and multiple other components, including the v1 CustomSelectControl. If that falls short on accessibility, it sounds like we have some big problems across lots of components!

What is the reason for exposing the whole popoverProps object? What popover prop would you like to access?

I found in #57331 that I needed to tweak the popover's wrapperProps. The z-index for the select control was insufficient in the sidebar, so other elements such as the stacked color indicators of color controls below the block styles would float over the select popover.

It appeared that the Ariakit component would recalculate and apply the z-index as an inline style making it tough to fix that issue via CSS alone.

I take it this meant "outside of the components package?" Otherwise, the editor is exactly where I want to use it 🙂

Yep, I definitely meant "components package" 🤦

This PR followed the approach used in the BaseControl and multiple other components, including the v1 CustomSelectControl. If that falls short on accessibility, it sounds like we have some big problems across lots of components!

Thank you for the extra context! We'll keep it into account when iterating on CustomSelectControl

The z-index for the select control was insufficient in the sidebar, so other elements such as the stacked color indicators of color controls below the block styles would float over the select popover.

It appeared that the Ariakit component would recalculate and apply the z-index as an inline style making it tough to fix that issue via CSS alone.

That's interesting. At least, we are probably going to replicate the same z-index as the legacy CustomSelectControl, and hopefully that should solve the issue 🤞

In the longer term, I would love for popover-based UI to move away from hardcoded z-index, and just be based on receiving a dynamic value (ie. latest popover-based component gets the higher z-index)

I found in #57331 that I needed to tweak the popover's wrapperProps. The z-index for the select control was insufficient in the sidebar, so other elements such as the stacked color indicators of color controls below the block styles would float over the select popover.

It appeared that the Ariakit component would recalculate and apply the z-index as an inline style making it tough to fix that issue via CSS alone.

@aaronrobertshaw Do you believe it's a bug or something that could be addressed in Ariakit? If you can create an issue on https://github.com/ariakit/ariakit/issues, I'd love to take a better look.

Right now, at the moment it opens, the popover wrapper element will replicate the computed z-index value you pass to the original component. In theory, this should've worked:

  popoverProps={{
-    wrapperProps: { style: { zIndex: 1000000 } },
+    style: { zIndex: 1000000 }
  }}

Or even this:

<CustomSelect
  popoverProps={{ className: "class-with-higher-z-index" }}
/>

In the longer term, I would love for popover-based UI to move away from hardcoded z-index, and just be based on receiving a dynamic value (ie. latest popover-based component gets the higher z-index)

I agree (assuming you meant "latest popover-based component that opens gets the highest z-index"). That's akin to how the native popover attribute works with the top layer.

Thanks for the nudges in the right direction @diegohaz 👍

Do you believe it's a bug or something that could be addressed in Ariakit?

No, I don't think there's a bug in Ariakit. By the looks of it, it's working as expected.

In theory, this should've worked:

Both the suggestions work, thank you. In hindsight I was probably just distracted by the inline style for the z-index on the wrapper and targeted overriding that not appreciating that the wrapper would replicate the computed z-index.

All these approaches still require the ability to pass the popoverProps to the underlying component here. So I think this PR is still valid and also @wordpress/components specific.

@brookewp and @ciampo, if the v2 CustomSelect components are still under active development would you prefer I close this PR for now?

I have an alternate PR up using a dropdown until we can make the switch to the new select control.

if the v2 CustomSelect components are still under active development would you prefer I close this PR for now?

I have an alternate PR up using a dropdown until we can make the switch to the new select control.

The component is not ready yet. If you need to implement that piece of functionality soon, using a dropdown sounds like a good option. We could close this PR and put #57331 on hold. As soon as v2 is ready, you should be able to pick it up again.

Sorry for the disruption!

Sorry for the disruption!

Not a problem at all given it turns out we had an obvious alternative all along 😄

I'll close both PRs for now. I have the feeling the block style variation sands will shift again before the time comes to reimplement the UI.