Toolbar is-active link causes layout shift

I am working on this issue

I have created a patch to address the above issue. I am attaching a screenshot for reference, showing the state before and after applying the patch.

Tested #4 and am not seeing the background effect.

I have created a new patch to address the above issue. I am attaching a screenshot for reference, showing the state before and after applying the patch.

Before:

After:

Seeing the background. Attaching a color contrast check too.

The last submitted patch, 6: 3364984-6.patch, failed testing. View results →

For #6 🐛 Toolbar is-active link causes layout shift Needs work All checks pass. Needs review.

Ahmad Smhan → made their first commit to this issue’s fork.

We could also consider to just fix the layout shift with a small CSS trick like https://css-tricks.com/bold-on-hover-without-the-layout-shift/

I'm not entirely sold on the background color solution. While there is still the underline to represent the active item, ensuring it doesn't rely on color alone, the bold text is arguably more salient and I'm concerned its removal could be (perhaps subconsciously) disruptive. If the bold were replaced with something similarly salient that I'd be more on board with.

Even if we ultimately go with the background approach, this still needs to go back to NW as it should be applied to the core/modules/toolbar/css/toolbar.menu.css file as well, as the current implementation only addresses Claro.

As far as alternate solutions

• The pseudo approach could probably be done accessibly, but it also requires knowing what the text content of the link is, and that would need to account for translations being different lengths and contrib additions to the toolbar. There are certainly ways to make this happen, but unsure if it can be done elegantly.
• Something that might work, but needs manual testing in multiple browsers and zoom depth: A quick test suggests styling inactive links to .letter-spacing: 0.0224rem; and active links to .letter-spacing: normal; miiight work. In most cases that resulted in the normal and bold text occupying the same width, and when they didn't the difference was small enough that the repaint either didn't happen or was imperceptible. This would be imprecise, but if it addresses the majority of the use cases without causing new problems this would get my vote as it would improve the experience for most users without any UX disruption.

There are also text-shadow and text-stroke approaches but I'm not sure if they are consistent enough.

Re #14

There are also text-shadow and text-stroke approaches but I'm not sure if they are consistent enough.

Good call! Even if it's not fully consistent from browser to browser, as long as there's a distinct visual difference up to 200% zoomed, one of those two approaches is probably the best way to go. That would reliably keep the widths intact. Trying both approaches out and providing screenshots of the outcomes is probably a good next step.

In my testing -webkit-text-stroke: 0.2px black looked ok in Chromium but awful in Firefox, and text-shadow: 0 0 0.75px black; looked ok but not perfect in both browsers, particularly good at 200%. Not entirely convinced this is the solution. Most other interfaces I've looked at use either a background colour (e.g. Firefox tabs) or a bottom border (PhpStorm tabs), or the link takes up a fixed amount of space and longer text doesn't matter (Slack channels, unread vs read).

FWIW Github is using the same pseduo-element trick as mentioned in #12 on a span inside the link:

<span data-content="Pull requests">Pull requests</span>

.UnderlineNav-item [data-content]::before {
  content: attr(data-content);
  display: block;
  font-weight: var(--base-text-weight-semibold, 600);
  height: 0;
  visibility: hidden;
}

Proof of concept patch with pseudo elements:

This was needs work and under discussion, no reason to mark it RTBC, also removing credit for the empty issue fork.