DatePicker: Use compact button size

[tyxla]

What?

This PR updates the DatePicker to use compact size for the Prev and Next buttons.

Why?

In #65018 we're replacing the size violations, but that applies only to components outside the @wordpress/components package. Here, we're updating the button sizes within a @wordpress/components to match the sizing guidelines.

How?

We're making the prev / next buttons compact.

My understanding is that icon buttons should be compact (32px) and not 40px (nor the 36px that they are now). Can you verify that's the case @WordPress/gutenberg-design?

Testing Instructions

• Test the "Prev" and "Next" buttons of the DatePicker make sense and look/work well with the compact sizing:
  • In Storybook: /?path=/story/components-datepicker--default
  • In the post editor by selecting a publish date.

Testing Instructions for Keyboard

Same

Screenshots or screencast

Before	After

[github-actions]

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: tyxla <[email protected]>
Co-authored-by: ciampo <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ciampo]

Changes LGTM, although they don't really have an impact because of style overrides.

As we are exploring designs for expressing a date range, it could be a good opportunity to rethink this aspect too — I'm not really sure we need to use a Button here.

[tyxla]

Changes LGTM, although they don't really have an impact because of style overrides.

I did spot the width styles, but they were making the button a square, which is why I didn't remove them. I guess if we want to remove them, we'll need to do it in a coordinated effort that tests all icon buttons across the editor. The height is actually considered.

As we are exploring designs for expressing a date range, it could be a good opportunity to rethink this aspect too — I'm not really sure we need to use a Button here.

Icon buttons are a thing, aren't they? Or do you mean we can use "Prev" and "Next" links instead of arrow buttons? Or perhaps in a border sense using the native datepicker UIs?

[ciampo]

🤦 Ignore my previous comment — for some reason, I thought that we were talking about the button used for each day in the calendar, and not the one used for prev/next months.

Nonetheless, changes LGTM

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/6.7 branch. Please resolve the conflict manually and create a PR to the wp/6.7 branch.

PRs to wp/6.7 are similar to PRs to trunk, but you should base your PR on the wp/6.7 branch instead of trunk.

# Checkout the wp/6.7 branch instead of trunk.
git checkout wp/6.7
# Create a new branch for your PR.
git checkout -b my-branch
# Cherry-pick the commit.
git cherry-pick 0bfec0f91843b993a929e6aafe9548cf07690eea
# Check which files have conflicts.
git status
# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue
# Push the branch to the repository
git push origin my-branch
# Create a PR and set the base to the wp/6.7 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[tyxla]

@noisysocks if I understand correctly, this has already been backported, but let me know if I can help with anything.