Web-bugs: kangax.github.io - layout is messed up

[afmenez]

URL: http://kangax.github.io/compat-table/es2016plus/
Browser / Version: Firefox 52.0
Operating System: Windows 10
Problem type: Layout is messed up

Steps to Reproduce

1. Navigate to: http://kangax.github.io/compat-table/es2016plus/

Expected Behavior: the table header is not obscured by the "% complete" box

Actual Behavior: the first pixel row of the table header is obscured by the "% complete" box

_From webcompat.com with ❤️_

[karlcow]

Thanks @afmenez for the bug report.

in Safari

in Firefox

This is a very minimal issue.

[karlcow]

so as we can see there are rounding issues related to the browser. I have sometimes 16px too.

<sup class="num-features" title="Number of implemented features">
    <b style="color:hsl(120,100%,25%)">100</b>%
</sup>

the line-height in Safari is 15px while in Firefox it is 16px. But this seems to come from the font. It is not specified in the CSS.

If I specify line-height: 15px; on http://kangax.github.io/compat-table/master.css

.num-features {
    position: absolute;
    top: -15px;
    right: 0px;
    font-size: 11px;
    transition-property: top;
    transition-duration: .5s;
    line-height: 15px;
}

The issue is solved.

@afmenez You seem to be the author or at least participating. This is the fix.

[adamopenweb]

@karlcow we also have this report https://bugzilla.mozilla.org/show_bug.cgi?id=1267898

[afmenez]

I have patched the css workaround as recommended by @karlcow above, but I still think this is an issue in Firefox which may cause similar problems in other sites.

[afmenez]

This is not the same issue mentioned by @adamopenweb above. That issue is related to the header of the table, this is related to a box positioned just above that header.

[karlcow]

@afmenez do you know other sites with the same issue? That would help make a case for it.

Currently the style in Firefox is defined for the sup element.
https://dxr.mozilla.org/mozilla-central/rev/722fdbff1efc308a22060e75b603311d23541bb5/layout/style/res/html.css#539-549

And in the rest of user-agent stylesheets.
https://dxr.mozilla.org/mozilla-central/search?limit=100&redirect=false&q=line-height%20ext%3Acss%20path%3Alayout/style/res%2F

I guess it's normal because it depends on the font itself.

• line-height value in Opera Blink is normal. (inspector)
• line-height value in Safari is 15px (in the inspector)

another way to fix it is

.num-features {
    position: absolute;
    top: calc(-2px - 1em);
    right: 0px;
    font-size: 11px;
    transition-property: top;
    transition-duration: .5s;
    line-height: 1em;
}

but then I was trying to understand the difference in between the font-size:11px and the height: 15px height of the box (16px in Firefox). I tried to dig a bit more around the container/contained.

and there is indeed a difference

th { outline: 1px solid blue;}
.num-features { outline: 1px solid red;}

I wonder if the pixel difference is a question of rounding or just unrelated.

[karlcow]

@dholbert what do you think about this slight difference in between those.

[dholbert]

If the issue is with headers sticking up too high like in karlcow's screenshot: I don't see that behavior locally on Linux Firefox Nightly, FWIW. Maybe this is dependent on a specific mac font? or HiDPI displays?

Anyway, I don't have any insight to offer from what we've got so far -- though I think a reduced testcase would be the best way to isolate/demonstrate the issue & get to the bottom of this. (@jfkthame knows text layout stuff better than I do, too, so he might have some thoughts too.)

[jfkthame]

It looks to me like the issue arises because the <sup class="num-features" ...> element is positioned with its top at -15px (relative to the cell that contains it), but nothing guarantees that it will actually be 15px high (and hence butt up exactly against the top of the cell).

The fragility of the layout can be demonstrated by changing the font to one that happens to have larger ascent/descent metrics; e.g. (on macOS) setting font-family: apple chancery; on that class results in a several-pixel overlap.

So a reasonable fix (as already noted in comments above) is to set an explicit line-height on the <sup> element that is being abs-positioned, to match the distance above the cell that it's being placed:

    position: absolute;
    top: -15px;
    line-height: 15px;

or similar.

In general, the default or automatic line height is not guaranteed to be consistent across browsers or platforms (or even user profiles within a single platform and browser: changes to font preferences can easily lead to significant metrics differences). So a layout like this, which relied on the assumption that the <sup> cells would be 15px high based on their content, is inherently fragile.

[karlcow]

@afmenez tell us when you deployed the fix, so we can close here as fixed.

@dholbert as always ❤️
@jfkthame thanks a lot for the hindsight, very useful.

[reinhart1010]

The issue seems to be fixed. (Nightly 60 on Linux Mint 18.3)

[afmenez]

Sorry, forgot to mention the fix in https://github.com/kangax/compat-table/pull/1078