Review the text decoration offset for links

[36degrees]

What

Revisit the default value for the text decoration offset on links, set by $govuk-link-underline-offset:

https://github.com/alphagov/govuk-frontend/blob/c9d331c2a155de6244c8fb240c22923e074a8099/src/govuk/settings/_links.scss#L39-L46

Why

As noted in https://github.com/alphagov/govuk-frontend/pull/2183#issuecomment-831933308, when we introduced the new link styles we had to make a compromise on the offset of the underlines, as Chromium-based browsers measured the offset differently to other browsers, putting the underline further away.

This issue appears to have been fixed as of Chrome 104 (https://bugs.chromium.org/p/chromium/issues/detail?id=1251634). Once Chrome 104 reaches widespread adoption, we can revisit the value now that the behaviour in different browsers is consistent.

Who needs to work on this

Designer

Who needs to review this

Designer and developer?

Done when

• [ ] Chrome 104 has decent adoption
• [ ] We've reviewed the default value for the underline offset ($govuk-link-underline-offset) and made any changes
• [ ] We've checked we're happy with the appearance in all supported browsers

[36degrees]

Changes to links in Chrome 104:

https://user-images.githubusercontent.com/121939/182565784-ced5f6f7-16cc-45d8-9774-7ee303c3100b.mov

[colinrotherham]

Just tagging @christopherthomasdesign on this issue as it might be a good time to look at this again

Background

We think Chrome v104 (August 2022) lifted link underlines 1px higher than before, but we only confirmed this when our Percy visual regression tests upgraded from Chrome v98 to Chrome v108

Decimal places

We've nearly finished our switch from Node Sass (deprecated) to Dart Sass (latest) to generate CSS. This means we're now seeing line-height calculated to 10 decimal places like ~line-height: 1.31579~ line-height: 1.3157894737

In a good way, we're now seeing the same styles as other service teams that already switched to Dart Sass

But strangely this has affected link underlines too (GIF showing before/after):

☝️ Note: With 10 decimal places we strangely lose the underline breaks for descenders

[colinrotherham]

Some screenshots for reference

Safari 16.2, iOS

Safari 16.3, macOS

Chrome 110, macOS

Firefox 110, macOS

Edge 110, Windows

[christopherthomasdesign]

Have done some exploration into this now.

I asked the GDS design community to give feedback on a couple of options. It's worth noting that I've gone on the assumption that it's best for the underline offset to be set at a whole number of pixels away (rather than half pixels). I think this should result in more consistent rendering across different devices – let me know if this is wrong.

The consensus was that for 19px body copy, an equivalent of a 3px underline offset looks better than 2px. This is because the underline interferes less with the overall shape of the text, which should be better for readability.

It does means that on Chrome the descenders can slightly bump into the line because it doesn't do ink skipping at that distance:

But we decided the benefits to readability (from the line being further away) outweighed that.

When I was playing around with this in Frontend, I changed the value to $govuk-link-underline-offset: .1578em !default; which should calculate to 3px offset when used with 19px text. There's probably a cleverer way to calculate this number in the code, you'll need to help me with that 😅

I'm not sure if we want to apply this value to links at all sizes in the scale. I had a look at it in the frontend review app in different browsers, and thought it looked fine at all the sizes. I think we currently just have one value that calculates the offset for all type sizes, rather than setting a different one for each size in the scale. I'm fine with the value being optimised for body text, as most links will appear at that size. But interested to hear what others think.