Text shifts slightly when hovering over link in Firefox

[Skepfyr]

System information

zola 0.19.2
tabi v3.1.0 (also tested on main 05d042d)
firefox 135.0 (64-bit) on Linux (this doesn't appear to reproduce on Chromium)

Expected behaviour

When hovering over a link I expect the layout of the page to remain the same, this is true for most links but isn't always the case.

Actual behaviour

This picture most clearly shows the issue (purple lines added to highlight offset)

I believe the issue occurs if the last character of a link and the next character overlap due to kerning/ligatures, in this example the r and the comma overlap when the link isn't being hovered over but they separate when it is. This pushes the rest of the line slightly right. I believe the font I'm ending up with is "Source Serif" but I'm not entirely sure about that.

Steps to reproduce

1. Create a webiste using the tabi theme
2. Add a page containing link which ends in an r and the next character is a comma (eg [link-r](http://example.com), foo)
3. zola serve and open the page in Firefox
4. Try hovering over the link in the page

Additional context

No response

Final checklist

• I've checked that the issue isn't already reported.
• I've tested with the latest version of tabi to check if the issue has already been fixed.

[welpo]

Thanks for reporting this!

I can't reproduce on Firefox 135.0 on macOS nor on Windows:

If you want to tinker, you could try editing either removing this block entirely:

tabi/sass/parts/_misc.scss

Lines 132 to 143 in 09e724a

	a:not(.no-hover-padding):hover::before {
	display: inline-block;
	position: absolute;
	z-index: -1;
	inset-block-end: 0;
	inset-block-start: 0;
	inset-inline-end: -0.15em;
	inset-inline-start: -0.15em;
	background-color: var(--primary-color);
	max-inline-size: 105%;
	content: "";
	}

(this is responsible for increasing the size of the background colour shift on hover)

or maybe just change the value of max-inline-size.

[Skepfyr]

Huh, I think you "fixed" this between me raising the issue and you trying to reproduce! Specifically, because you're using ::before now instead of ::after (from #443 and therefore in v4.0.0) the reproducer I used no longer has the issue. I can still hit the same issue if the first character of the link overlaps with the character before, e.g. Reproducer[, weird link] foo but I suspect it's significantly less likely for anyone to hit that, because most links will be preceded by white space.

I'm not particularly bothered by this issue any more so feel free to do what you want with this bug report, it's still there but probably won't ever affect anyone.

(In the testing I ended up doing before I realised this, the issue appears to be caused by the pseudo-element existing with display: inline-block or position: absolute: if the pseudo-element didn't have both of those properties the issue disappeared)