feat(button): Add padding mixin, adjust icon margin

[kfranqueiro]

This addresses the following:

• Adds mdc-button-horizontal-padding mixin to parameterize left and right padding (one value applies to both)
• Updates mdc-button-stroke-width mixin to accept an optional padding parameter, since this mixin adjusts the button padding to maintain the same size when considering the added stroke
• Reduces effective padding between icon and nearest edge of button (left for LTR, right for RTL)
  • This is done via negative margin on the icon element rather than adjusting padding on the button; the latter would have required adding a class to button when using an icon, and would have caused complexity for both the padding and stroke-width mixins to accommodate different padding values for buttons with vs. without icons

Resolves #2400.

[codecov-io]

Codecov Report

Merging #2420 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2420   +/-   ##
=======================================
  Coverage   98.91%   98.91%           
=======================================
  Files         104      104           
  Lines        4234     4234           
  Branches      534      534           
=======================================
  Hits         4188     4188           
  Misses         46       46

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4f83757...73f1e24. Read the comment docs.

[aprigogin]

Can you update this CL to handle the MD cases we need to support (like text icon button). Alternatively, you can leave additional comments on #2413.

[kfranqueiro]

I'm totally up for updating this PR, though might need to wait until tomorrow... Maybe just as well since we need to figure out what to do about the text button + icon case anyway.

Pasting the list from #2400 to reflect status on this PR:

• The icon-less text button (not contained) needs 8px padding on each side (currently it is 16px)
• The contained button with an icon should have:
  • 12px padding to the left of the icon
  • 8px padding between the icon and the text
    • Need to suppress space from between icon and label (inline-flex might work), or revise padding to assume that space will exist
  • 16px padding to the right of the text
• The contained button with an icon should handle RTL by flipping the icon to the right side, and all appropriate padding should also flip
• The text button with an icon needs an audit for its padding (not sure if it should be closer to the icon-less text button, or closer to the contained button with an icon)
• The text button with an icon should also handle RTL

To me the real kicker is what we expect text buttons with icons to do. Everything else in this PR is really simple so far, and accomplishes this by adding a padding mixin and with minimal impact to the existing stroke mixin (i.e. you automatically get the correct reduced icon margin in all cases). If the icon treatment is consistent across all types of buttons (as it is right now in the PR), this remains simple... if we need to treat icons in flat buttons specially, we need to disentangle what that means for the styles and mixins.

Update: I pushed a commit to POC handling flat buttons having even padding while others have the reduced margin for icons. This assumes that whenever our mixins are used for e.g. stroke or fill, that the appropriate modifier class is also used, which I think is a safe assumption based on how our styles are structured (and how our demo page uses our classes and mixins).

Update 2: Checked with design and we arrived upon 12px padding on the icon side of the button for contained buttons (vs. 16px on the other side), but equal 8px padding on both sides of the button for flat text buttons.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[googlebot]

CLAs look good, thanks!

[aprigogin]

should --raised be listed twice?

[kfranqueiro]

Whoops... clearly I misread a bit when I was looking at the selectors below to apply this to.

[aprigogin]

strictly speaking we should be adding /* @NoFlip */ on these. At the same time, I understand the argument about them being the same. Lets hope that never changes.

[kfranqueiro]

Hm, yeah, I didn't think about it here since I know we handle @noflip within our RTL stuff now, and these styles are equal and not RTL-dependent. If these ever did change to being asymmetrical, we'd absolutely want to add @noflip (probably automatically via use of mdc-rtl mixins).

I think if we wanted to take that strict of a stance about @noflip we'd have several instances across the repo where left and right are equal that we're not flagging right now.

[aprigogin]

LGTM