[css-display] Make `table-caption` and `table-cell` <display-outside> values

[fantasai]

Splitting out from @MatsPalmgren's comment in https://github.com/w3c/csswg-drafts/issues/3771:

Random thought: maybe marker should be a display value rather than a position value.

It should be a new <display-outside> value, or an additional keyword, in that case. I think it would ruin this feature if you can't specify the marker's internal layout to be grid etc. Compare table-caption/cell, which has severely limited layout because you can't specify a <display-inside> value.

::marker, table-caption, <legend> and <summary> have a lot in common in this respect. They are in-flow by default, but not quite, since they aren't flowed normally together with other children in the layout context. Semantically, they're like a third variation of "flow" (besides in-flow, out-of-flow). I wonder if we should model them in the same way for that reason. Either through <display-outside> or a new property. E.g.

<display-outside> = block | inline | run-in | marker | caption | cell | legend | summary

This would add a lot more power to authors to control the layout without having to add wrapper elements. E.g. <caption> would have display: caption flow-root by default, but you could also specify <caption style="display: caption grid"> to display its children using Grid layout. legend | summary allows an arbitrary child to be displayed as the rendered legend/summary in a fieldset/details element.

(FYI, It would be trivial to support table captions/cells with internal grid/flex/table layout in Gecko. The only thing missing is some way to specify it in CSS.)

It would be trivial to make table-caption a <display-outside> value in the spec, too. Should we do it? (By which I mean, does anyone actually want to implement it?)

[ExE-Boss]

I’d like to also see table-cell to also be a <display‑outside> value.

[fantasai]

@ExE-Boss That's much harder. :) Table captions just lay out like regular blocks, for the most part. Table cells participate in table layout algorithms, which are mostly a mystery of multi-decade multi-layered reverse-engineering.

[MatsPalmgren]

@fantasai Yes, I think we want to support both of these in Gecko, please add them to the spec. I've implemented WIP patches for both and it seems fairly straight-forward to support (now that we've implemented the general multi-keyword display syntax).

It's worth noting that table-caption/cell are block formatting contexts by default and it's not really possible to make them not be that. I.e. flow and flow-root both behaves as flow-root. I've kept them as distinct computed values though, and they serialize to distinct values, it's just that flow behaves as flow-root at used-value time.

table-caption/cell ruby creates a block box with an inner anonymous ruby box, like block ruby.

[FremyCompany]

At first glance, why shouldn't all table-internal elements have themselves as their display-outside value? You can't get any of these to perform a layout outside the usual table structure, and it doesn't appear to me you can meaningfully categorized them as either flow-root or flow, can you?

@MatsPalmgren why do you think table-caption and table-cell should be a display outside but not table-row for instance? (not judging, just trying to understand)

[MatsPalmgren]

In a sub-tree of boxes making up a table, the table-caption/cell boxes are leaves, so they can easily have arbitrary layout inside them without affecting any "table layout".

Other table-internal values can't have arbitrary layout inside them without fundamentally changing what a table is. Imagine for example a display:table-row flex. This box would lay out its children using flexbox layout so they would not be "table cells" at all and the table's columns would be meaningless on this row. (It'd be kind of a "column-span:all" box but for tables.) And for <td>/<th> children inside that flexbox, we'll create a row/row-group/table wrapper for them unless the author also changed their display. You also get tricky issues like what does rowspan=2 mean if the second row has flex layout inside? While it might be possible to specify all this and implement it, I doubt it would be worth the effort.

@FremyCompany Not sure I understood your question correctly though. Please elaborate on the concrete syntax you're suggesting if I misunderstood.

[FremyCompany]

@MatsPalmgren Thanks, you replied exactly clarifying the right thing! If I understand, your reasoning is that it's not useful for table-row to be an outside display because it couldn't have a paired display-inside anyway. That's a fair point. I guess in my opinion they are just display-outside values that force their display-inside value rather than display-inside values whose display-outside is irrelevant, but I guess both visions are possible and justifiable.

[MatsPalmgren]

Right, if we don't allow combining them with other keywords (and I see no reason to) then it seems easier to keep them as <display-internal> single-keyword values in the spec. How they are represented internally in layout engines is up to implementors to choose. It's not observable as long as the value serializes to the right (single) keyword.

[FremyCompany]

Sounds fair. Happy to support your proposed change, with that justification in mind.

I would still point out that vertical-align has interesting interactions with table-cell that assume that it's display-inside is a flow so I would not be pushing too much to allow to change this, except if everyone is on-board.

For table-caption I see no reason not to implement the change, it seems like an improvement without downside to me. That part should be straightforward to resolve on.

[MatsPalmgren]

CSS Box Alignment already explains how vertical-align interacts with its properties. But yes, a few minor spec edits are likely needed there since it currently assumes that table-cells always have block layout inside. vertical-align should only be applied to table-cells that are using block layout inside. For other <display-inside> values, the Alignment properties should apply normally per that value. (This should fall out naturally for UAs that already support Alignment for flex/grid layout etc. It seems to work fine in my tree anyway, fwiw.)

[FremyCompany]

Yes, I just wanted to point out changes would be needed there. Your proposed behavior is what I would think it should do, indeed. But adding this into Firefox without adding it into other browsers only makes the table behavior less interoperable, and is a bit against my goal here.

But if Blink folks agree with the change, then I am fine with it as well.

[FremyCompany]

Just realized there is another issue we will want to resolve here.

If table-cell is a display-outside value but table-row is a display-inside value, you can now technically have a table-cell table-row element. The Table Fixup algorithm does not assume that this situation is possible. Besides, it could not possibly fix this in any way since a single box has two conflicting values.

So, I would still lean towards making all table-internal displays be display-outside types and (for all but table-cell and table-caption be display-inside types as well, but in all thse cases the display-outside type erases the display-inside type to the same value (so you can never have table-row grid or table-row table-column or something weird like that).

[MatsPalmgren]

@FremyCompany I think you're misreading the syntax. table-row is a <display-internal> keyword, which can't be combined with any other keywords so it's effectively a single-keyword value.

[FremyCompany]

Oh, ok, never mind then. Didn't realize what I wanted was already in the spec. So yeah, then, only the questions about table-cell interoperability remains.

[FremyCompany]

cc @davidsgrogan (who is currently on vacation, and will probably get back to us later)

[css-meeting-bot]

The CSS Working Group just discussed Make `table-caption` and `table-cell` <display-outside> values, and agreed to the following:

• RESOLVED: Do not add table-cell/table-caption as display-outside values at this time

The full IRC log of that discussion

<AmeliaBR> Topic: Make `table-caption` and `table-cell` <display-outside> values
<AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/3940
<fremy> @AmeliaBR, we moved that issue to TPAC
<fremy> @AmeliaBR you skipped one list issue :)
<fremy> oh, ok
<AmeliaBR> fantasai: Matts wanted to support allowing flex/grid inside table caption. Maybe also table-cell, but there are more layout issues there, so the focus is on caption right now.
<AmeliaBR> TabAtkins: Chrome would have issues with doing this for table cell, although that makes me sad. But I think caption is OK.
<AmeliaBR> iank_: I think it's OK to do this with table-caption. Will need to check.
<dbaron> dbaron: Do table captions affect the table size, or does the table size affect the table caption's size?
<AmeliaBR> fremy: They can in that if the caption is wider than the table, the table gets stretched to the wider size.
<AmeliaBR> florian: That doesn't seem like a very hard interaction to handle.
<AmeliaBR> dbaron: The harder interaction would be if the table layout affected the caption size.
<AmeliaBR> iank: (missed)
<AmeliaBR> iank_: Can we delay this, then?
<AmeliaBR> florian: So, no to table-cell since it's too hard. And no to table-caption as there isn't strong enough demand.
<fantasai> s/(missed)/Was there any demand from authors, or just requesting for completeness?/
<florian> s/no to table-caption/not yet to table-caption
<AmeliaBR> astearns: objections to wontfix?
<tantek> aww
<tantek> hoping its postpone rather than wontfix
<tantek> see you at TPAC!
<AmeliaBR> RESOLVED: Do not add table-cell/table-caption as display-outside values at this time

[SebastianZ]

TabAtkins: Chrome would have issues with doing this for table cell, although that makes me sad. But I think caption is OK.

@tabatkins Does that mean that Chrome people would be willing to implement this for table cell (and maybe other mentioned display types) but it requires bigger changes in layout code?

iank: (missed) iank_: Can we delay this, then? florian: So, no to table-cell since it's too hard. And no to table-caption as there isn't strong enough demand.

@frivoal / @bfgeek: From reading the IRC log, it doesn't read like that was the outcome of the discussion but I guess the important part of the discussion lies in the missed part. As I understand @MatsPalmgren's note, allowing different values like table-cell currently defined in <display-internal> to be used as <display-outside> values would be fairly easy in Gecko.

Sebastian