Splitting out from @MatsPalmgren's comment in https://github.com/w3c/csswg-drafts/issues/3771:
Random thought: maybe
marker
should be adisplay
value rather than aposition
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 begrid
etc. Comparetable-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 havedisplay: 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?)
I鈥檇 like to also see table-cell
to聽also be聽a聽<display鈥憃utside>
value.
@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.
@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
.
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)
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.
@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.
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.
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.
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.)
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.
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).
@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.
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.
cc @davidsgrogan (who is currently on vacation, and will probably get back to us later)
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
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
Most helpful comment
@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.