FontSizePicker: Make control take up full width

[noisysocks]

What?

Removes the 280px max-width from FontSizePicker so that it takes up the full width of its parent container.

The Reset button will now also be 40px high when __size is set to __unstable-large.

Neither of these changes make any practical difference to Gutenberg which only uses FontSizePicker in the (narrow) sidebar and always hides the Reset button.

Why?

• More consistent with most other components in @wordpress/components which take up the full width.
• Styling such as this is the responsibility of the caller. @wordpress/components shouldn't know what a sidebar is or how wide it is.
• 30px tall Reset button looks weird.

How?

Testing Instructions

Storybook:

1. npm run storybook:dev
2. Go to FontSizePicker
3. Toggle on Set custom size

Gutenberg:

1. npm run dev
2. Global Styles → Typography → Text
3. Check that the Size control looks the same as it does in trunk

[noisysocks]

To me this is a bug but I classified it as an enhancement so that the minor version of @wordpress/components is bumped. I don't think it's a significant enough of a change to warrant a major version bump, but nor is it something that I'd want to slip in via a patch bump. I'm not really sure though so let me know how you'd approach this.

[ciampo]

LGTM 🚀

Tests well in Storybook (controls now go full width) and in the editor (no visual changes)

(tagging @mirka for visibility on the size change for the reset button)

More consistent with most other components in @wordpress/components which take up the full width.
Styling such as this is the responsibility of the caller. @wordpress/components shouldn't know what a sidebar is or how wide it is.

100% agree with these principles.

On a similar note, we have some work to do to remove the __experimentalIsRenderedInSidebar prop (as part of #42994) that was sneaked in as a temporary fix but has never been removed since 😅 Let me know if you want to have some fun with that too!

To me this is a bug but I classified it as an enhancement so that the minor version of @wordpress/components is bumped. I don't think it's a significant enough of a change to warrant a major version bump, but nor is it something that I'd want to slip in via a patch bump. I'm not really sure though so let me know how you'd approach this.

I'm not sure about this, probably @gziolo could share some wisdom here :)

[mirka]

Just for context, we have been classifying changes like this (removing a width constraint) as a substantial enough change to warrant a formal deprecation (e.g. #43230).

For this relatively higher-level component though, there is a much lower chance of consumers using it in arbitrary layouts, so it might be ok.

[ciampo]

Just for context, we have been classifying changes like this (removing a width constraint) as a substantial enough change to warrant a formal deprecation (e.g. #43230).

For this relatively higher-level component though, there is a much lower chance of consumers using it in arbitrary layouts, so it might be ok.

That is my bad for not flagging this as warranting a formal deprecation — sorry!

As you said, this should be ok 🤞 but I'm also fine in case we feel that putting this change under a temporary __nextUnconstrainedWidth prop is the right thing to do here