Reduce unnecessary selector specificity for Button block

[oxyc]

Description

See #23222 (comment).

The selector used is unnecessarily specific (0,3,0) and it only needs to be (0,2,0) to override the block default margins since it's enqueued after and thus take location precedence.

I'd still leave the comment about it being specific since ideally it would be just .wp-block-button but it cant because of the block default margin selector (which in turn is there to override list margin-left properties.

There's some minor spacing difference between the buttons in editor and frontend but that's shown in master already and is unrelated to this.

One real world reason I'd argue this is needed is because it's much more common for themers use to .wp-block-buttons .wp-block-button than it would be for them to even know you can chain selectors like .wp-block-buttons .wp-block-button.wp-block-button. So to override it we'd probably see lots of .entry-content .wp-block-buttons .wp-block-button.

How has this been tested?

Tested adding buttons in twentynineteen and twentytwenty

Screenshots

Twentytwenty Editor:

TwentyTwenty Frontend:

TwentyNinteen Editor:

TwentyNineteen Frontend:

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[oxyc]

ping @jasmussen if you can think of any cases I'm missing

[jasmussen]

Wonderful! Thanks for the PR. I'm out for the day but will review tomorrow.

[jasmussen]

First off, thank you for keeping on this. It may seem like a trivial change, but it is one that potentially has serious quality of life improvements to themers. These details really matter.

I took this for a spin in the Twenty Nineteen theme. Before:

Editor and frontend above, both look the same, and correct.

After:

Above is also editor and frontend. As far as I can tell, things work as intended, even with the reduced specificity. Code also looks good, and the math seems right, for that reason, I'm approving, and thanks again.

I would love if @kjellr has time to sanity check this, but in absence of that, let's get this in.

[kjellr]

Yep, that seems fine on my end!