Open ObliviousHarmony opened 1 month ago
I do agree this change was a bit aggressive and potentially breaking for existing third-party Placeholder consumers.
I understand the intent of this change was to responsively collapse elements when the container width is narrow. I can suggest, for example, adding something like a Placeholder.ResponsiveContainer
subcomponent so consumers who want this behavior for some parts of their Placeholder UI can opt into it:
<Placeholder>
<InputControl />
<Placeholder.ResponsiveContainer>
<Button>Primary</Button>
<Button>Secondary</Button>
</Placeholder.ResponsiveContainer>
</Placeholder>
@jasmussen Would something like that be an acceptable solution for the original intent?
I understand the intent of this change was to responsively collapse elements when the container width is narrow.
That's correct, and suggestion sounds good at a glance.
That seems like a really good way to support more aggressive responsiveness while still giving consumers plenty of control. We're using the useResizeObserver()
hook to render an entirely different component at smaller breakpoints to handle responsiveness and so ideally the placeholder component isn't providing any responsiveness for us.
Description
In https://github.com/woocommerce/woocommerce/pull/48911 we found that https://github.com/WordPress/gutenberg/pull/59275 introduced a new width style for all
<Button>
components used in a<Placeholder>
component. This change here is a breaking change and we had to add a style to override it.I would argue that the
.components-placeholder__fieldset > *
selector is also a bit aggressive, however, setting the width to all buttons used in a<Placeholder>
component seems excessive.Step-by-step reproduction instructions
<Button>
component inside of a<Placeholder>
Screenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes