We're not entirely sure what are all the problems you're trying to solve with this issue, but there seem to be at least two:

• Make sure that we reflect style computation from boxes to elements for all properties correctly when an element generates multiple boxes.
• Record the guidelines for authoring box generation rules; this probably goes in an appendix since it's aimed only at spec writers.

Was there something else that needs fixing?

No, I think this was all.

Agenda+ for WG verification:

• box ↔ element style value correspondance in b2d484c
• box construction spec guidance in 533ac0a

@Loirooriol Please let us know if these edits are satisfactory!

Much better, thanks! But I'm still not convinced that boxes have display types. Boxes may have characteristics like level or formatting context, but probably only elements and tree-abiding pseudo-elements (i.e., things to which display applies) should have display types. So I would prefer to define box blockifications and inlinifications in terms of element blockifications and inlinifications (which are not currently defined). Do you think it's worth?

We refused many times to introduce separate outer display and inner display / flow properties. But each time we are bumping into problems of that too vague display thing.

Like flexbox inside table-cell still prohibited by current CSS state of affairs.

It really should be something like this:

display: table-cell;  /*outer requirement */
flow:flexbox;          /* content layout style - flexbox */

and

display: list-item;  /*outer requirement */
flow:flexbox;         /* content layout style - flexbox */

in the same way:

display: table-cell;  /*outer requirement */
flow:grid;          /* content layout style - grid */

Otherwise we will keep inventing that wheel forever.

@c-smile I expect that a future level of the spec will say

<display-outside>  = block | inline | run-in | table-caption | table-cell;
<display-listitem> = <display-outside>? && <display-inside>? && list-item;

Do you mean this https://drafts.csswg.org/css-display/ ?

The "can't set a table-cell to work like a flexbox" is intentional, and is the exact reason we eventually merged display-inside/display-outside back together into the single 'display' property. I would have liked that, but turns out it's fairly tricky in all the existing browsers - being a table cell is already complicated enough without having to worry about satisfying flexbox constraints as well.

Immediate children of flexbox or grid are laid out exactly as display[-inside]: table-cell elements: all of them establish BFC (block formatting context) and use the same rules of min/max calculations.

I do not see any intentionality there.

Ok, but what about display:list-item then?

In ideal world flexbox should be just

display: block | inline-block | table-cell | list-item | etc.;
flow: horizontal | horizontal-wrap | vertical | vertical-wrap;

and flexes should be just flex units: width: 1fx | 1fr (as in grid spec) or something like that.

So grid and flexboxes could use the same flexibility principles and complement each other rather than compete as we have them now.

all of them establish BFC

Not necessarily, flex and grid items may establish a FFC or a GFC instead of a BFC.

use the same rules of min/max calculations

Table sizing is much more messed up.

flow: horizontal | horizontal-wrap | vertical | vertical-wrap;

This looks like flex-flow.

and flexes should be just flex units: width: 1fx | 1fr

This is in https://wiki.csswg.org/ideas/mistakes, too late to change now.

Anyways I don't see how this is related to the issue, if you have some proposals you should create new issues.

Immediate children of flexbox or grid are laid out exactly as display[-inside]: table-cell elements

Unfortunately, this isn't true. table-cells aren't allowed to ever overflow, even if you try to explicitly size them; they also have some weird interactions with their sibling table-cells when % sizing is used. This ends up making them pretty complicated, unfortunately.

Ok, but what about display:list-item then?

Theoretically fine (it's no more complicated than putting ::before on a flexbox), but low implementor interest. The grammar is compatible with us adding it to flexbox/grid in the future, too. For now, tho, it's only combinable with block and inline.

I'd note the edit uses the term "table grid box" which is not used anywhere else; other occurrences use "table box".

(I'd also note I'm not crazy about defining the principal box for tables as being the table wrapper box rather than the table box, since I've generally viewed "principal box" as being the one that most of the properties in CSS apply to. But the spec has moved towards defining it as the one that positioning schemes apply to, so oh well...)

reopening this because something under discussion and agenda+ shouldn't be in the closed state

@dbaron CSS2.1 defines the principal box as the box that “contains descendant boxes and generated content and is also the box involved in any positioning scheme”. https://www.w3.org/TR/CSS21/visuren.html#block-boxes CSS Display is just being consistent with that.

@dbaron Switched “table grid box” to “table box”. Also filed #2501

The Working Group just discussed Defining box ↔ element style correspondence, and agreed to the following resolutions:

• RESOLVED: Accept change set https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3
• RESOLVED: Add the appendix https://drafts.csswg.org/css-display-3/#box-guidelines to Display 3

@tabatkins

table-cells aren't allowed to ever overflow, even if you try to explicitly size them

This isn't the first time I've read this, but there appears to be a simple counterexample. Could you take a moment to explain the apparent contradiction, for my own edification (or possibly for yours)?

<table style="border: 1px solid blue;">
    <td style="max-width: 20px;">Overflow</td>
</table>

https://jsfiddle.net/dgrogan/9uduq99L/5/

@dbaron CSS2.1 defines the principal box as the box that “contains descendant boxes and generated content and is also the box involved in any positioning scheme”. https://www.w3.org/TR/CSS21/visuren.html#block-boxes CSS Display is just being consistent with that.

The version of that sentence in CSS 2.1 doesn't define principal boxes that way; it's just a description of principal block boxes. The current CSS level 2 editor's draft does, though. It's a pretty substantive edit that I'm not sure was intentional.

Much better, thanks! But I'm still not convinced that boxes have display types. Boxes may have characteristics like level or formatting context, but probably only elements and tree-abiding pseudo-elements (i.e., things to which display applies) should have display types. So I would prefer to define box blockifications and inlinifications in terms of element blockifications and inlinifications (which are not currently defined). Do you think it's worth?

@Loirooriol I think that, unless the distinction becomes necessary because not having it creates significant confusion and misinterpretation of the specs, we should not make the distinction. We blur a lot of fine distinctions we could make in our discussions, because the cognitive load of being super-precise is unnecessary for understanding. Similarly, the spec should not slice everything up excessively: only insofar as it helps understanding, and not so far that it hinders it. I think in this case, it's not worth making the distinction. We can revisit if it becomes an actual problem down the line, though. Let me know if this is acceptable?

I suspect some future update may require more precise definitions to avoid ambiguity, but I guess the meaning is clear enough for now, OK.