[css-tables] Fixup collapsible whitespace

[gregwhitworth]

Compat Issues: Maybe

Description:
2.1 stated to keep the whitespace if the element next to it would generate a table wrapper. Our proposal is to not care about whether a table wrapper would be created in further steps of the algorithm. Gecko behaves like that, Blink sort of does too but has other bugs in this space. Edge follows the 2.1 version and will need to adjust to match that of Gecko. That said, you can only see Edge's interop issue if you remove the UA defaults of white-space (because white-space:normal collapses the resulting white spaces anyway).

Proposed Option:
Accept new text that aligns with what Blink (although buggy) and Gecko already do.

Anonymous inline boxes which contain only white space, are the first and/or last child of a tabular container, and whose immediate sibling (if any) is a table-non-root box, are treated as if they had display: none.

Testcases:
https://jsfiddle.net/nbh4r9u8/1/
https://jsfiddle.net/nbh4r9u8/2/
https://jsfiddle.net/nbh4r9u8/3/

Browsers Passing Test:
Firefox passes
Chrome has an issue with whitespace collapsing

[FremyCompany]

Since this is a breaking change from CSS 2.1, we need to issue an CSS 2.2. update.

[bzbarsky]

The issue says that 2.1 "stated to keep the whitespace" and that Gecko does this, but that there is a change needed from 2.1? That's a bit confusing. Which part is wrong?

In terms of the actual behavior on https://jsfiddle.net/nbh4r9u8/1/ it looks to me like the 2.1 algorithm is wrong per what we were trying to write down. I'm not sure where in the numerous rewrites and attempted simplifications it went awry.

The simplest testcase that demonstrates the problem with what CSS 2.1 has written down right now is this:

<span style="display: table-row; white-space: pre; background: red">        </span>

Per CSS 2.1 as written there should be a red box here, right? Actually, now I can't tell whether the "if any" in https://www.w3.org/TR/CSS21/tables.html#anonymous-boxes step 1 substep 3 means that if there aren't any the text is dropped or whether it means it gets kept. This really needs to be reworded to be clear about what it's trying to say. I _think_the intent is that the text is dropped unless it has a sibling that satisfies certain criteria; more on the criteria below.

I'm trying to recall what the "proper table descendants" bit of https://www.w3.org/TR/CSS21/tables.html#anonymous-boxes step 1 substep 3 was meant to do. @fantasai do you recall why that was needed? Because simply removing it would address the issue here, as far as I can tell; the whitespace in https://jsfiddle.net/nbh4r9u8/1/ would then get removed by that step.

Another testcase worth considering:

<span style="display: table-row; white-space: pre; background: red">
  <span style="display: table-row-group; background: yellow">group</span> 
  <span style="display: table-cell; background: green">cell</span>
</span>

Should there be any red there? I believe there would be if CSS2.1 were implemented as written even with the change from https://logs.csswg.org/irc.w3.org/css/2016-09-19/#e720481 that was resolved yesterday, but is that the case in any browsers?

[bzbarsky]

Note that this issue was raised as far back as 2011. See https://lists.w3.org/Archives/Public/www-style/2011Oct/0567.html which also proposes removing the "proper table descendants" bit.

The W3C list archive breaks threading nicely on this one, but the discussion continues with https://lists.w3.org/Archives/Public/www-style/2012Jan/0700.html and https://lists.w3.org/Archives/Public/www-style/2011Nov/0117.html with the latter being confused by a missing "not" in the original post. See the s/do/do not/ bit in https://lists.w3.org/Archives/Public/www-style/2011Nov/0122.html

It looks like the original tests I wrote for this stuff at http://web.mit.edu/bzbarsky/www/testcases/table-anonymous-objects/ don't test either of the two situations above, for which I apologize....

[bzbarsky]

Oh, and the unclear "if any" thing was already brought up as an issue, by me, back in https://lists.w3.org/Archives/Public/www-style/2010Jul/0376.html. As was the "proper table descendant" thing. I don't see any obvious reply to that mail so far, but that may just be the archive stupidity... That said, https://www.w3.org/Search/Mail/Public/advanced_search?keywords=&hdr-1-name=subject&hdr-1-query=Proposal+for+a+replacement+for+section+17.2.1+&hdr-2-name=from&hdr-2-query=&hdr-3-name=message-id&hdr-3-query=&period_month=&period_year=&index-grp=Public__FULL&index-type=t&type-index=www-style&resultsperpage=20&sortby=date shows no messages after that one responding to it, so those comments simply never got addressed. Unless the mail addressing them had some other subject?

[FremyCompany]

Ok sorry for the confusion, some cut/paste refactoring went wrong and things like "it" and "this" referred to wrong things after we moved things around in sections.

The proposal that was accepted is to match the current new text, which should be Gecko implements now.

[bzbarsky]

The proposal that was accepted is to match the current new text

@FremyCompany Where is this text? I would like to see what it says.

Presumably https://drafts.csswg.org/css2/ is not it, nor is https://www.w3.org/TR/CSS22/, right?

[FremyCompany]

The new text is in the css-tables-3 spec:
https://drafts.csswg.org/css-tables-3/

Another testcase worth considering:

 <span style="display: table-row; white-space: pre; background: red">
  <span style="display: table-row-group; background: yellow">group</span> 
  <span style="display: table-cell; background: green">cell</span>
</span>

Should there be any red there? I believe there would be if CSS2.1 were implemented as written even with the change from https://logs.csswg.org/irc.w3.org/css/2016-09-19/#e720481 that was resolved yesterday, but is that the case in any browsers?

I believe with the proposed text there should be no red. Edge displays red in that case right now. I don't want this to be the behavior the spec mentions.

[FremyCompany]

https://drafts.csswg.org/css-tables-3/#fixup-algorithm

1. Remove irrelevant boxes:
   • Children of a table-column are treated as if they had display: none.
   • Children of a table-column-group which are not a table-column are treated as if they had display: none.
   • 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 contain only white space, are the first and/or last child of a tabular container, and whose immediate sibling (if any) is a table-non-root box, are treated as if they had display: none.

[bzbarsky]

Thanks. That's much better. I still think the "if any" thing is confusing and would prefer something more explicitly written out, but it's a bit less confusing in the new phrasing. And the other part of the change looks good.

[gregwhitworth]

Agreed @bzbarsky, this whole section (and much of the table spec IMO) is like a giant word puzzle. I broke it out a bit more and didn't bury the lead.

How about this for making it more explicit:

Anonymous inline boxes which meet the following creteria are treated as if they had display: none:

• contain 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

[bzbarsky]

If you say "which meet all of the following criteria", sounds good.