Buttons: Improve unstyled button styles to visually match link appearance

[aduth]

Related Slack conversation: https://gsa-tts.slack.com/archives/CNCGEHG1G/p1616421634001700

Why: The use of an unstyled button is intended to take the visual appearance of a link. The proposed changes resolve some discrepancies that currently exist:

• Avoid customizing the underline offset
• Reset font smoothing using inherit (see Buttons: Use "inherit" for font smoothing reset uswds/uswds#4115 for detail)

Live Preview: https://federalist-2f194a10-945e-4413-be01-46ca6dae5358.app.cloud.gov/preview/18f/identity-style-guide/aduth-unstyled-buttons-links/components/buttons/

Screenshot:

Before	After

This was originally observed in the IdP, where an equivalent link and unstyled button did not appear the same. See examples below which show a real link on the left vs. an unstyled button on the right. The IdP customizes the default font smoothing of text, which currently causes a difference in appearance between links and unstyled buttons (see uswds/uswds#4115). Separately, we should consider if this is actually something we should be doing, perhaps as part of the ongoing work to migrate to Public Sans font (see related guidance).

IdP Before	IdP with underline offset fix	IdP with underline offset & smoothing fixes

[aduth]

Interesting that the tests pass 🤔 I would expect visual regressions to be flagged here.

[zachmargolis]

Interesting that the tests pass 🤔 I would expect visual regressions to be flagged here.

I tried running locally, got some timeouts, but also this:

 FAIL  test/screenshot.test.js (118.968 s)
  ● screenshot visual regression

    assert.strictEqual(received, expected)

    Expected value to strictly be equal to:
      0
    Received:
      4
    
    Message:
      Expected "/research/1-flow-diagrams/" to visually match the live site.

🤷

[zachmargolis]

LGTM

[aduth]

but also this:

The diffs should be in your local relative tmp folder to take a look at what it might be considering different. 4 seems like a strange result, since I'm pretty sure that number is "total pixel difference", and 4 feels very small. If I had to guess looking at that particular page, I'd guess something with how those very-large-images are loaded or scaled.

I recall some recent discussion about possibly removing / moving / updating those pages, which might incidentally help clear up some of the flakiness around that page.

[aduth]

Interesting that the tests pass 🤔 I would expect visual regressions to be flagged here.

Taking a look locally, I think the issue is that text-underline-offset support in Chrome is relatively new (v87), and the version of Chromium used in the visual regression tests is a bit older, and therefore the previous styling effectively did nothing because it wasn't supported.

[aduth]

These styles only apply for hover, active, and disabled 🤦 Should have also duplicated above, after the @include button-unstyled. Was misled by the fact that this is substituting the behavior of no-knockout-font-smoothing.