Note that I attached the file with the original report... but your captcha thing lost it.

Deleted: baz.html 207 bytes

baz.html 207 bytes View Download

David, is this a bug or intentional?

> David, is this a bug or intentional?

I don't know anything about whitespace collapsing but suspect bug because these should produce the same output but don't:

<div style="display:table">
  <span>This</span> <span>is</span> <span>some</span> <span>text</span>
</div>

<div style="display:table-cell">
  <span>This</span> <span>is</span> <span>some</span> <span>text</span>
</div>

https://jsfiddle.net/dgrogan/q7azLrww/

I should note that this has the potential for interop problems if people write code like this:

  <div style="display: table; width: 300px">
    <button style="width: 50%; display: table-cell">One</button>
    <button style="width: 50%; display: table-cell">Two</button>
  </div>

In this situation, all browsers actually make the buttons be inline-blocks in a single cell.  But in Chrome the space goes away so the buttons are on the same line, while in browsers that handle the whitespace correctly they will end up on two lines...

It would be nice to have this bug fixed. FWIW, here is the relevant spec text:

2.2.1. Fixup Algorithm

[...] The following steps are performed in three stages:

1 Remove irrelevant boxes:
- - [...]
- - Anonymous inline boxes which contain only white space *and* are between two immediate siblings each of which is a table-non-root box, are treated as if they had display: none.
- - Anonymous inline boxes which meet all of the following criteria are treated as though they had display: none.
- - - contains only white space
- - - are the first and/or last child of a tabular container
- - - whose immediate sibling, if it has any siblings at all, is a table-non-root box

The issue bz mentions in comment 5 is causing compatibility bugs such as https://bugzilla.mozilla.org/show_bug.cgi?id=1452870 to be filed against Firefox.

Rick, could you get someone to take a look at this, please?  This is a longstanding WebKit bug that Blink inherited; the spec, sanity, Edge, and Firefox all agree on the behavior here but Chrome and Safari do something different...

> This is a longstanding WebKit bug that Blink inherited; the spec, sanity, Edge, and Firefox all agree on the behavior here but Chrome and Safari do something different...

Totally agreed that Blink behavior should change. But unfortunately these reasons apply to lots of bugs on our huge sucky backlog and we have to prioritize.

We haven't seen evidence that this bug is especially impactful, but if you (or anyone, including Francois Remy who commented above) have such evidence (many duplicates reported to FF, many instances surfacing on webcompat.com, affecting 1 or 2 big sites, etc) please tell us about it.

And thanks, heycam, for writing a test.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d4fd62da30bfecc64d7d9bd17ce5904ca3333764

commit d4fd62da30bfecc64d7d9bd17ce5904ca3333764
Author: David Grogan <dgrogan@chromium.org>
Date: Mon Apr 23 10:47:46 2018

[css-tables] Move failing wpt test to its real bug

A test that blink fails was imported and given a new bug by the
importer. We already have a bug for this behavior.

Just bookkeeping.

Bug:  834311 ,694374
Change-Id: I101c3b5dc24da8df90330a33c633ae2864295dcf
Reviewed-on: https://chromium-review.googlesource.com/1023038
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#552664}
[modify] https://crrev.com/d4fd62da30bfecc64d7d9bd17ce5904ca3333764/third_party/WebKit/LayoutTests/TestExpectations

 Issue 269500  has been merged into this issue.