Avoid vertical overflow when using horizontal overflow

[redtrumpet]

I would like to make my bigger equations scrollable, especially on mobile. However, if I add overflow-x: auto to either the .katex or the .katex-display class, there appears also a vertical scroll bar. So apparently, the content of the .katex-block is higher than its height. Is there any way to avoid this?

Here is a MWE

[edemaine]

I believe the issue is that the scrollbar takes up part of the .katex box's height, so by adding the scrollbar, it suddenly doesn't have enough height to render without a scrollbar. If you move the overflow-x: scroll rule to the containing div instead of the .katex element, then you get the desired behavior.

[redtrumpet]

I would like to scroll the equation only, not the full document. This is why I want to add overflow-x to .katex-display. I scratched my own itch now by using overflow-y: hidden, hoping that nothing will actually ever be hidden.

Still my question stands: Why does .katex-display have content of height bigger than its own, which can be seen by adding a vertical scroll bar via overflow-y: scroll? Is this intendet behaviour?

Thanks for your time!

[edemaine]

I agree that this seems like a bug, probably long-standing. Issue #312 seems like it might be related. A simple fix might be to add a little vertical padding to .katex, like padding-block: 3px...

[ronkok]

Why does .katex-display have content of height bigger than its own, which can be seen by adding a vertical scroll bar via overflow-y: scroll?

We get into deep waters here. I'll start with the short version: The TeX system of vertical alignment does not fit easily into HTML. The KaTeX workaround happens to create that extra height, which does not displace text, but does make the div a tiny bit taller.

If you are still curious, read on for details. KaTeX emulates TeX, so its vertical alignment calculations are done relative to the height and depth of each individual glyph. That's how it can do accurate vertical alignment of accents, fraction bars, radicals, etc.

The HTML system of text alignment is instead done on a line box. There is a single line box height for an entire font, not for each glyph. So the top of the line box is a little taller than the tallest glyph in the font and the bottom of the line box is a little lower than the lowest descender in the font.

It is difficult to force a line-box system to act like TeX. That extra line box "padding" keeps displacing things. It's a hard problem. Safari claims that it supports MathML, but its accents have rotten vertical alignment and it looks to me like the accents are placed over the line box, not the glyph. There is a project underway to bring MathML to Chromium, but progress on that project has slowed to a crawl and they are stuck on exactly this problem.

The KaTeX workaround starts by calculating the tallest point of a group of vertically aligned things (say for instance a fraction). KaTeX creates a little span styled as inline-block and creates an invisible vertical strut that extends from the baseline to set the top of the span. Then each math element is put into a span that is given CSS styling of a table cell. These spans are each displaced vertically a precisely calculated distance from the top of the enclosing span. Because these little spans have the equivalent of table-cell CSS, they will obey that vertical alignment even if the line box overflows the cell dimensions.

So we have overcome the tyranny of line box dimensions and have done so without displacing any nearby text. But if you put a border around the katex-display span, you'll see that the top of that invisible strut is a little taller than the text.

[6502]

Why fighting with CSS rules for layout instead of just using absolute positioned divs? Honest question... I bumped into the lack of support for \hfill and why it's hard to implement and I realized that instead of just ignoring CSS layout rules (what I always do) KaTeX decided to fight with it. Curious why...

[edemaine]

I'm not sure exactly (the original decision long predates me) but my guess would be "font ligatures/kerning" which makes it difficult to predict the rendered width of text. That said, MathJax's SVG engine does it, with absolutely positioned glyphs (rendered as paths though). So it might be possible, with ligatures and kerning explicitly represented... But it would be a major undertaking.

Also, I'm not sure how you'd expect to get a good bounding box (the original issue of this thread) with position:absolute...