[css-multicol] 'column-span' and tables

[dbaron]

The definition of column-span says:

Applies to: in-flow block-level elements

The definition of block-level element says that it applies to things with display: block, display: list-item and display:table.

Then the definition of column-span goes on to say:

The element establishes a new block formatting context.

This means that (1) column-span: all applies to tables and (2) when it does, they become block formatting contexts.

Having a single edge case in which tables can establish block formatting contexts doesn't make sense. This shouldn't happen.

That said, given the lack of consideration to this issue, I wonder whether column-span is really intended to apply to tables.

What do existing implementations do? (IIRC, Gecko is the last engine to implement column-span, which would have made me expect the spec to be in better shape than it appears to be.)

/cc @tabatkins @gregwhitworth @neerjapancholi

[gregwhitworth]

Looking at this testcase: https://jsfiddle.net/kememj9w/2/

It works on tables in Chrome/Edge (didn't test Safari). Granted following normal table layout rules it shrinks to fit its content so you have to set the width to 100% in order to consume the available width of the columns that span: all provides it.

[frivoal]

I think this is merely imprecise wording, not an actual expectation that tables should establish a BFC. The goal was, IIRC, the margins of descendants of two adjoining spanners would not collapse with each other, and that floats from one would not intrude in the other. For that, block spanners need to establish a BFC, but tables are fine as is.

[FremyCompany]

Just wanted to mention that this property would have to be hoisted if we want to apply it on tables (like every single css property except background and border, but hey as long as we want the spec to be a whitelist...)

[mstensho]

The way I see it, the goal was to keep column row content from interacting with spanners, and to keep things inside spanners from interacting with things inside other spanners, be it margins of floats. Just saying that they establish a new block formatting context may be too simplistic.

Tables should be allowed to become spanners. I've never worked on an engine that has this distinction between "table wrapper box" (which includes captions) and "table box" explicit in code (neither Presto nor Blink have this), so I don't really know, but for tables to become spanners, you obviously also need to isolate column content from the captions. We shouldn't leave the captions in the column rows, for instance.

Back to Blink, implementing column-span:all for tables was really simple, since Blink's table layout object contains all captions, and the caption margins do never collapse with content on the outside. Nor does it allow intruding floats. Is it a bug in Blink for the "table wrapper box" to always establish a new block formatting context? Because that is what we effectively do.

[FremyCompany]

I've never worked on an engine that has this distinction between "table wrapper box" (which includes captions) and "table box" explicit in code (neither Presto nor Blink have this)

Oh yeah I have a strong opinion this concept should be removed from the spec altogether. If your engine does that for any reason, up to you, just make sure the observable behavior is identical. But some people have diverging opinions about it. I will make a case for that change next f2f I go to. 

[EDIT] Adding these links so I don't forget https://jsfiddle.net/vhLpok8g/ https://jsfiddle.net/vhLpok8g/1/

[astearns]

Removing agenda+ until #1072 is resolved

[neerjapancholi]

Tested this on different browsers and posting results with screenshots:

Test case: https://jsfiddle.net/kememj9w/2/
Description: ‘Column-span: all” is applied to a table to check if it spans all columns. (Same as test case provided by @gregwhitworth).

Chrome 56.0.2924.87 (64-bit)	Safari 10.0.3 (11602.4.8.0.1)	Edge 38.14393.0.0
Table spans all columns. But ‘width: 100%’ must be set on the spanner	Table spans all columns. But ‘width: 100%’ must be set on the spanner (**One bug that I see in Safari only is that on resizing, content at the end of the last column before the spanner seems to be duplicated from the first column after the spanner.)	Table spans all columns. But ‘width: 100%’ must be set on the spanner

Result screenshot (Taken from Safari but result for table spanning is identical to Chrome and Edge)


[frivoal]

So bugs aside, we seem to have the same (sensible, IMHO) behavior everywhere. Does that look like a resolution or does someone disagree?

[mstensho]

Yeah, looks like they all agree, right? Having to set width:100% to make the table take up all available width of the multicol content box is only sensible, since a table with auto width will "shrink to fit".

See https://www.w3.org/TR/2011/REC-CSS2-20110607/tables.html#auto-table-layout

"If the 'table' or 'inline-table' element has 'width: auto', the used width is the greater of the table's containing block width, CAPMIN, and MIN. However, if either CAPMIN or the maximum width required by the columns plus cell spacing or borders (MAX) is less than that of the containing block, use max(MAX, CAPMIN)."