Firefox (correctly) honors space between children of anonymous table cell, unlike Blink/WebKit

RESOLVED INVALID

Status

()

enhancement
P3
normal
RESOLVED INVALID
Last year
Last year

People

(Reporter: karlcow, Assigned: heycam)

Tracking

57 Branch
Unspecified
Android
Points:
---
Bug Flags:
webcompat ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webcompat][wptsync upstream], )

Attachments

(4 attachments)

This is a spin-off of https://webcompat.com/issues/14419
we will still try to contact the site to change their CSS.

But there's definitely a difference of behavior in between Chrome and Firefox here. Not sure which browser is right or if we are in undefined land.


Test: https://codepen.io/webcompat/pen/rdPmbw


<ul>
  <li>foo</li>
  <li>foo</li>
  <li>foo</li>
</ul>

<ul><li>foo</li><li>foo</li><li>foo</li></ul>

with 


ul {
  display: table;
  width: 200px;
}

li {
  display: inline-block;
  width: 33.3333333%;
}


These two have different renderings in Firefox, but the same rendering in Chrome.


The rounding in Firefox and Chrome is different.
for this specific case (as displayed in the respective devtools)

Firefox is 66.6667px
Chrome  is 66.6562px
Flags: webcompat?
Posted file test
I think it's not to do with the rounding, but instead the generation of the text frame for the white space.
This one doesn't have display:inline-block on the <span>s.
For that second attached test, the frame tree for the one with the white space in it looks like this:

  TableWrapper(div) ::-moz-table-wrapper
    Table(div)
      TableRowGroup(div) ::-moz-table-row-group
        TableRow(div) ::-moz-table-row
          TableCell(div) ::-moz-table-cell
            Block(div) ::-moz-cell-content
              Inline(span)
                Text "a"
              Text "\n "
              Inline(span)
                Text "a"

Since the two spans are within the same inline formatting context, I wouldn't expect the white space only box to be collapsed away.  Does that sound right to you Daniel?  Though I guess we could just more generally be within the "table layout is incompatible" world here.
Flags: needinfo?(dholbert)
(In reply to Cameron McCormack (:heycam) from comment #3)
> Since the two spans are within the same inline formatting context, I
> wouldn't expect the white space only box to be collapsed away.  Does that
> sound right to you Daniel?

That does sound right.

FWIW, Edge and pre-Blink Opera (Presto) agree with our rendering, on both testcases here. So Chrome's behavior seems likely to just be a WebKit-specific behavior (a bug?) that they inherited in Blink.

(Also worth noting, RE the flexbox comparison in the original codepen: the Flexbox spec explicitly says that each child element gets its 'display' blockified, and that whitespace between those blockified children *does not get rendered*.)

Maybe Chrome is wrapping each span in its own table-cell? That would explain their behavior -- because whitespace between table-cells isn't rendered, I think.
Flags: needinfo?(dholbert)
I see this is already reported as https://bugs.chromium.org/p/chromium/issues/detail?id=694374 and that bz there has pointed out how it can cause compat problems.  Perhaps we should add a WPT test for this case.
(In reply to Daniel Holbert [:dholbert] (away 4/24 - 5/11) from comment #4)
> Maybe Chrome is wrapping each span in its own table-cell? That would explain
> their behavior -- because whitespace between table-cells isn't rendered, I
> think.

BTW I checked this by creating a <table border="1"> and using script to insert a couple of spans with white space between them, but only got a single table cell border, so it must be some other rule they are applying to remove the white space.
Comment on attachment 8968429 [details]
Bug 1452870 - Add WPT test for white space between adjacent elements in the same anonymous table cell.

https://reviewboard.mozilla.org/r/237128/#review243038

::: testing/web-platform/tests/css/css-tables/anonymous-table-ws-001.html:2
(Diff revision 1)
> +<!DOCTYPE html>
> +<title>CSS Test: White space between elements for which a single anonymous table cell is generated is not removed</title>

Optional nit: this sentence is hard to parse (particularly the snippet "is generated is not removed")

How about we bump "is not removed" towards the beginning (and maybe also s/is not/should not be/ to make it extra-clear that we're describing an expectation, rather than describing a bug / bad outcome)

e.g. Maybe replace with
CSS Test: White space should not be removed between elements for which a single anonymous table cell is generated
Attachment #8968429 - Flags: review?(dholbert) → review+
Summary: The text is not properly aligned. → Firefox (correctly) honors space between children of anonymous table cell, unlike Blink/WebKit
Assignee: nobody → cam
Status: NEW → ASSIGNED
Pushed by cam@mcc.id.au:
https://hg.mozilla.org/integration/autoland/rev/b06fe2f80ddf
Add WPT test for white space between adjacent elements in the same anonymous table cell. r=dholbert
Autoland will probably call this "FIXED", but that's not really right since we're not changing our behavior -- the patch here was just a test to enforce our already-existing behavior.

Given that this bug (as filed) is a Chrome bug and not a Firefox bug and we're not landing code to change our behavior, I think this is INVALID -- I'll preemptively resolve it as such before autoland-bot calls it fixed.
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → INVALID
Created web-platform-tests PR https://github.com/w3c/web-platform-tests/pull/10517 for changes under testing/web-platform/tests
Whiteboard: [webcompat] → [webcompat][wptsync upstream]
https://hg.mozilla.org/mozilla-central/rev/b06fe2f80ddf
Whiteboard: [webcompat][wptsync upstream] → [webcompat]
Upstream PR merged
Whiteboard: [webcompat] → [webcompat][wptsync upstream]
You need to log in before you can comment on or make changes to this bug.