1592734 - Chrome and Firefox disagree on where to place anchors with certain CSS.

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Thomas Wisniewski [:twisniewski]]

Attachment: testcase.html

In the attached test-case, Firefox and Chrome differ on how to position the links. Firefox lays them out vertically, while Chrome does so horizontally.

At first glance, it seems to be a case where Firefox is adding layout space between the anchor tags due to the whitespace between the elements. But I'm not 100% sure if that's the full story here, or why Chrome would be collapsing the whitespace and Firefox would not (the display:table seems to be the key somehow).

Either way it's an interop issue, and seems to be the root cause behind the layout differences seen at https://webcompat.com/issues/43507

Comment 2

[Daniel Holbert [:dholbert]]

My first guess is that this is just a difference in choice of default font, and the relative lengths of the words "left" and "right".

The testcase has a table that's exactly as wide as its contents, and then it specifies a width on the first element:

a:first-child {
    width: 40%
}

If that increases the width of that child, then the children won't fit (since the parent's width is only as wide as their contents), and they'll linewrap.

I can make Chrome behave like Firefox if I increase that width (e.g. width:50%), and I can make Firefox behave like Chrome if I decrease it (e.g. width:30%).

So this may largely be a question of font metrics. However, there's also one additional difference that's in play here (visible after I remove that width decl). In Chrome, the whitespace between the two <a> elements does not seem to be rendered. In Firefox, that space does seem to be rendered. That occupies a bit of extra space and (together with possible font differences) explains why the math works out a bit differently and why the word "left" makes up a smaller portion of the content-width in Firefox (and hence why specifying width:40% may represent an increase in its size [triggering a linewrap] rather than a decrease).

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (does whitespace between inline elements directly inside of a table show up or not?)

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #2)

However, there's also one additional difference that's in play here (visible after I remove that width decl). In Chrome, the whitespace between the two <a> elements does not seem to be rendered.

Testcase 2 demonstrates that behavior difference. Here's a data URI with the key part:

data:text/html,<div style="display:table"><span>a</span> <span>b</span></div>

EdgeHTML agrees with Firefox, FWIW, while Safari agrees with Chrome (unsurprising since they share a lineage).

I suspect Chrome/Safari are wrapping each span in its own table-cell here, and discarding the whitespace between them (which is proper to do between table-cells); whereas, Firefox & Edge are wrapping the whole run of inline content in a single table cell, which then means there's no reason to discard the space.

The Firefox/Edge behavior feels more correct here. We should be treating "a b" the same, regardless of whether the characters are wrapped in spans or not. I'm not sure how much this is specced though... (lots of table behavior is under-specified)

Comment 5

[Daniel Holbert [:dholbert]]

Looks like this is specced (and Firefox/Edge match the spec).
Spec text is at https://www.w3.org/TR/CSS21/tables.html#anonymous-boxes
Quote:

 2. Generate missing child wrappers:
    1. If a child C of a 'table' or 'inline-table' box is not a proper table child,
       then generate an anonymous 'table-row' box around C and all consecutive
       siblings of C that are not proper table children
    ...
    3. If a child C of a 'table-row' box is not a 'table-cell', then
       generate an anonymous 'table-cell' box around C and all consecutive
       siblings of C that are not 'table-cell' boxes.

The wrapper is supposed to wrap the element and all consecutive siblings that aren't table-boxes. So Firefox/Edge are correct to generate a wrapper around <span>a</span> <span>b</span>, and Chrome/WebKit are incorrect.

Comment 6

[Daniel Holbert [:dholbert]]

This is a known Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=694374

Comment 7

[Thomas Wisniewski [:twisniewski]]

Thanks. I'll ping that bug to see if we can't get some eyes on this before it becomes so entrenched that the web relies on Blink/WebKit's bug.