Closed
Bug 1452870
Opened 7 years ago
Closed 7 years ago
Firefox (correctly) honors space between children of anonymous table cell, unlike Blink/WebKit
Categories
(Core :: Layout: Tables, enhancement, P3)
Tracking
()
RESOLVED
INVALID
People
(Reporter: karlcow, Assigned: heycam)
References
()
Details
(Whiteboard: [webcompat][wptsync upstream])
Attachments
(4 files)
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?
Assignee | ||
Comment 1•7 years ago
|
||
I think it's not to do with the rounding, but instead the generation of the text frame for the white space.
Assignee | ||
Comment 2•7 years ago
|
||
This one doesn't have display:inline-block on the <span>s.
Assignee | ||
Comment 3•7 years ago
|
||
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)
Comment 4•7 years ago
|
||
(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)
Assignee | ||
Comment 5•7 years ago
|
||
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.
Assignee | ||
Comment 6•7 years ago
|
||
(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 hidden (mozreview-request) |
Comment 8•7 years ago
|
||
mozreview-review |
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+
Updated•7 years ago
|
Summary: The text is not properly aligned. → Firefox (correctly) honors space between children of anonymous table cell, unlike Blink/WebKit
Comment hidden (mozreview-request) |
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → cam
Status: NEW → ASSIGNED
Comment 10•7 years ago
|
||
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
Comment 11•7 years ago
|
||
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: 7 years ago
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]
Comment 13•7 years ago
|
||
bugherder |
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.
Description
•