[Panel] k-tab-button line-height cuts text off

[renestalder]

Describe the bug
When using tabs with umlauts, the k-tab-button cuts off the upper part of the text.

The issue seems to be the overflow: hidden on .k-button-text class. Removing this, resolves the issue, but also possibly removes the overflow elipsis behavour. Another solution is to raise the line-height on k-tab-button.

To Reproduce
Steps to reproduce the behavior:

1. Create a panel blueprint with tabs (at least two)
2. Set "Übersichtsseite" for the label of one tab

Expected behavior

The text to be fully visible.

Screenshots

Kirby Version

3.5.0

Issue already existed prior 3.5.0.

Console output

Desktop (please complete the following information):

• OS: Pop_OS (Ubuntu) 20.10
• Browser: Firefox
• Version: 84

Smartphone (please complete the following information):
–

Additional context

Nitpick: The text is already rendered tiny and thin on my system and I would additionally suggest raising the weight of the font itself a bit to overcome accessibility issues.

[afbora]

Could be related with #2922? Because i couldn't reproduce the issue.

[renestalder]

Could be related with #2922?

In my case, it's not. In the second screenshot you find in the ticket description ("expected behaviour"), I removed the overflow with the browser dev tools, showing the same font family with the umlauts (as the umlaut can now overflow out of the element).

Also, that's not my system font. As the Panel defines a list of possible fonts, it takes the first that matches, in my case Nimbus Sans (even though that's not my system font), but my system font would be "Bahnschrift" and after that, "DejaVu Sans" (which correctly renders with sans-serif as font family defined).

I'm quite certain that's because of the overflow: hidden and how different fonts render.

Alternatively, you can reproduce it by lowering the line-height on the tab. Then you see how the text cuts off due to the overflow behaviour (which normally wouldn't without the overflow).

[renestalder]

There's something interesting I found.

Most of the websites are using Helvetica as an alternative font, and Ubuntu is trying to set Nimbus Sans as a similar font even you have Helvetica font. Also, the default font on Firefox is DejaVu Sans, but the default fonts are working just if the styles don’t specify a font family in a website.

Source: https://gokmengorgen.net/blog/2020/05/how-to-fix-default-fonts-problem-on-firefox/

The font that basically triggers the rendering on my system is "Helvetica" in the font stack of the panel, but Ubuntu seems to render Nimbus Sans.

Anyway, that probably might not necessarily change the fact that the line-height is screwed up depending on which OS font is applied. I guess you could test with a wide range of font families and wouldn't find an issue, but still, as the font stack can fall back to sans-serif, that issue can occur.

[distantnative]

I have tried to reproduce it on my machine, but not chance - always visible no matter what font, font size etc. I pick.

According to https://gokmengorgen.net/blog/2020/05/how-to-fix-default-fonts-problem-on-firefox/ it sounds more like something to fix on the system.

There is also actually no line-height set as far as I can see, but just the system's/browser's default. So it sounds like your system picks Nimbus Sans which cannot display umlaute at default line height. To what do you need to set the line-height for it to become visible?

[renestalder]

@distantnative Thanks for giving this another shot.

Just to make sure: I can easily fix that on my system. I don't bring this up because of me. I bring this up because it made me aware of the difference in font rendering due to the dynamic font-stack defined as being the panel font combined with the overflow: hidden, which can cause issues on different systems, but clearly any Ubuntu default installation. I strongly agree that that only occurs for a niche audience most of the time.

The fix is either to remove overflow: hidden or to raise the line-height to at least 1.4 (at least as tested for Nimbus sans, might not be enough for all font-families).

The root of the problem is probably how browsers render fonts, with the default line-height just being an assumption it might work for every font-family, quoting MDN:

[line-height] depends on the user agent. Desktop browsers (including Firefox) use a default value of roughly 1.2, depending on the element's font-family

If you decrease the line-height for every other font to, let's say, to 0.8, it will still be rendered properly without overflow: hidden, but not with (you can actually reproduce that in the panel). Now for Nimbus sans (which is, as said, picked up by Firefox on a default Ubuntu installation, based on the font-stack you used for the panel), that whole thing seems to be worse because it starts to cut-off at line-height 1.3 (browser default being line-height 1.2), and at line-height 1, the text isn't even readable.

And it's important to remember: it only happens because overflow: hidden.

Now let's quickly forget Nimbus sans and think of the fact, that every user can set their own font in the browser. Not that this might be done often, but it's a default functionality of the browser, the same as text zoom is. Both features can, for example, be used to increase accessibility. I rather look at it from this point of view than the "Ubuntu default installation problem".

[distantnative]

As far as I am aware overflow: hidden is needed for situations where overly long titles, tabs etc. could mess up the layout. That's why I am looking for alternative solutions - removing it might fix this described problem, but cause a lot of problems elsewhere, which is why we need to be very careful about such changes.

[renestalder]

Sure, that's right. Without the overflow: hidden the text-overflow: ellipsis; can't work, which seems necessary if you don't want text to break to a new line.

[distantnative]

@afbora untested - but could it be that the recent CSS changes on the tabs also solved this issue?

[afbora]

@distantnative I already couldn't reproduce the issue from the first time 🤷‍♂️

[renestalder]

@distantnative Is that a change that is already in one of the releases? At least on Kirby 3.6.0 rc.2 there is so far no difference.

However, I feel like we could easily close this one down here for being a very odd edge case and just leave it with that. It only happens in the Nimbus Sans case, and I switched browsers recently that handles the defaults differently/is using Arial instead of Nimbus Sans and doesn't come with this issue.

[distantnative]

Agreed, let's close this for now