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: ciampo <mciampini@git.wordpress.org>
Co-authored-by: aduth <aduth@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.

Size Change: 0 B

Total Size: 3 MB

_{compressed-size-action}

I guess one question is whether we want to apply similar changes to the Button component from @wordpress/components, although I'm always a bit wary of applying changes to that component 😅

I like the video, thanks for doing this. I'll defer to Andrew and Jay if he chimes in on technical pieces, though ask about this one:

--wp-ui-button-min-width: calc(4ch + 2 * var(--wp-ui-button-padding-inline));

Should this be a CSS variable? Is this how an implementer should change the min-width? Or should they not change the min-width from the default 4?

The --wp-ui-button-min-width exists mostly as an internal variable to the UI package (for example, it's used by IconButton to unset it). I'm not sure if we have a documented official stance on --wp-ui-* variables, whether we advise consumers against reading/writing them or not.

Regardless, my preference would be to assume that the Button's min width is a DS decision that should not be advertised as tweakable for the consumers — after all, we're using a quite conservative 4ch value. If we find that this min-width gets in the way of our consumers more than it helps them, then we may as well not have an internal min-width at all and expect consumers to add one if/when needed with custom styles?