1731010 - Github shows tab characters of mismatching widths, due to specifying font on inline-level vs. block-level ancestor

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase.

EXPECTED RESULTS:
Consistent indentation.

ACTUAL RESULTS:
Indentation is much smaller on first line.

NOTE:
It seems we are rendering the tab characters using the metrics from the div wrapper, rather than from the span (which is the tab characters' direct container).

This is responsible for a webcompat issue that affects the diff viewer on GitHub. In their diff viewer, the "main diff" sections (red/green/white backgrounds) has tabs rendered in a smaller font, whereas the "manually-expanded contextual code" sections (gray background) has tabs rendered in the correct larger font. This creates indentation mismatch as shown here:
https://twitter.com/Akien/status/1438219820697329671

One affected sample-page:
https://github.com/godotengine/godot/commit/5179124fd1f33c625181ea7cbd4eb109dfb71eb5
STR for that page: click the blue up-arrow to expand more contextual code at the top of the diff (above "1551"). Look at the expanded code with the gray background vs. the code with the white/green/red background, and notice that the indentation differs abruptly between the two sections.

Comment 1

[Daniel Holbert [:dholbert]]

Chrome 95 and Safari 14.1 both give EXPECTED RESULTS.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of issue on Github (differing indentation from different rendered tab widths) in Nightly 2021-09-15

Comment 3

[Alice0775 White]

I can reproduce the issue on Nightly94.0a1 Windows10.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1f4bfcfb4933f6ae310182346ede713ec0227c0e&tochange=c32a18de589ca448500f271a23b0559bd381483f

Comment 4

[Jonathan Kew [:jfkthame]]

According to the spec for tab-size,

This property determines the tab size used to render preserved tab characters (U+0009). A <number> represents the measure as a multiple of the advance width of the space character (U+0020) of the nearest block container ancestor of the preserved tab, including its associated letter-spacing and word-spacing.

the tab size is based on the advance width of the block container ancestor's space character; it is not affected by font changes on inline elements. So I think Firefox is following the spec here, and the other browsers are incorrect.

I'm surprised there doesn't seem to be a WPT testcase that highlights this; I'll try creating one.

Comment 5

[Jonathan Kew [:jfkthame]]

Specifically, in https://github.com/w3c/csswg-drafts/issues/5489 the CSSWG explicitly said this:

RESOLVED: Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container

(Previously, the spec said that tab-size only applied to blocks, not inlines; there's more discussion in the issue/IRC log.)

Comment 6

[Jonathan Kew [:jfkthame]]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1250257 about the incorrect Blink behavior.

And https://bugs.webkit.org/show_bug.cgi?id=230339 for Webkit.

Comment 7

[Alice0775 White]

so, cleared the regression flag.

Comment 8

[Daniel Holbert [:dholbert]]

Thanks, everyone! Sounds like there's no gecko bug here after all.

I'll update the bug title to track the GitHub rendering issue here (their dependence on the WebKit/Blink behavior), and I'll reclassify this as a WebCompat bug rather than a Gecko bug.

Comment 9

[Daniel Holbert [:dholbert]]

So the core issue at GitHub here is:
(1) They specify the font using the blob-code-inner class:

.blob-code-inner {
    overflow: visible;
    font-family: ui-monospace,SFMono-Regular,SF Mono,Menlo,Consolas,Liberation Mono,monospace;
    font-size: 12px;
    color: var(--color-fg-default);
    word-wrap: normal;
    white-space: pre;
}

(2) For the manually-expanded contextual lines of code (gray background), they apply that class on the block container, which is the td element:

<td class="blob-code blob-code-inner blob-code-marker" data-code-marker=" ">

(3) BUT, for the main diff section (white/green/red background), they apply that class on a span instead (and they don't specify any particular font on the block container, i.e. the td):

<td class="blob-code blob-code-addition">
  [...]
   <span class="blob-code-inner blob-code-marker" data-code-marker="+">

So for reasons discussed in comment 4 here, that means that tab characters render with inconsistent width between those two sections.

The fix here would be for them to address (3) by specifying the font on the diff-section's td element instead of (or as well as) on the span. If I make that change in devtools (just adding font-family and font-size decls on the td element), then that fixes the issue on my end.

Comment 10

[Karl Dubost💡 :karlcow]

I contacted GitHub.
Thanks Daniel.

Comment 11

[Daniel Holbert [:dholbert]]

Thanks, Karl! I've updated the URL field to include a sample affected page (see end of comment 0 for STR with that sample page, and attachment 9241500 [details] for a screenshot).

Comment 12

[Oana Arbuzov [:oanaarbuzov]]

I've checked the provided TestCase, and I can still reproduce the issue.
https://prnt.sc/NQUfAleyJEy_

It still occurs in https://github.com/godotengine/godot/commit/5179124fd1f33c625181ea7cbd4eb109dfb71eb5
https://prnt.sc/fvdIYF3nVoKQ

Tested with:
Browser / Version: Firefox Nightly 104.0a1 (2022-06-29)
Operating System: Windows 10 Pro

Comment 13

[Jonathan Kew [:jfkthame]]

Yeah, this is still not a Firefox bug, it's a site error on github. As described above, we're following the spec, whereas Blink and WebKit behave incorrectly (and their broken behavior happens to mask github's bad styling).

Relevant WPT test is https://wpt.fyi/results/css/css-text/tab-size/tab-size-block-ancestor.html.

Comment 14

[Calin Tanase]

Attachment: github issue Firefox vs Chrome.png

I was not able to reproduce the github issue on the latest Nightly. Daniel, can you take a look and confirm, please?

Tested on:
Operating system: Windows 10
Browser/Version: Firefox Nightly 111.0a1 (2023-01-25) / Chrome 109.0.5414.75

Comment 15

[Daniel Holbert [:dholbert]]

Yup, I can't reproduce either. It looks like GitHub must've fixed their bug. Hooray!