[css-display] More precise box transformations

[Loirooriol]

CSS Display has some handwaving about display types belonging to elements or boxes. Mostly it's clear what it means, but I think that Box Type Transformations should be more precise, and differentiate between elements, element-generated boxes, anonymous boxes, and text runs.

I think it should say something like this:

• Definition: blockifying a principal box blockifies the generating element.
• Definition: inlinifying a principal box inlinifies the generating element.
• Definition: blockifying or inlinifying a text run does nothing.
• Definition: blockifying an element sets its outer display type to block and, if its inner display type is layout-internal, it is set to flow.
• Definition: inlinifying an element sets its outer display type to inline unless it was layout-internal. If the inner display type is flow, the box recursively inlinifies its in-flow children.
• Note: blockifiying or inlinifying an element without display types has no effect.
• Note: blockifiying or inlinifying an element affects the computed value of display.
• Note: blockifications and inlinifications happen before the creation of anonymous boxes to fix the box tree.
• Assert: CSS specifications MUST prevent text runs from remaining as direct children of a parent box which blockifies its contents, e.g. by wrapping the text runs inside appropriate anonymous boxes.
• Assert: CSS specifications MUST prevent anonymous inline-level boxes from being generated as direct direct children of a parent box which has blockified its contents, e.g. by generating anonymous block-level boxes instead.
• Assert: CSS specifications MUST prevent anonymous block-level boxes from being generated as direct direct children of a parent box which has inlinified its contents, e.g. by generating anonymous inline-level boxes instead.
• Assert: CSS specifications MUST prevent text runs, boxes and elements from being simultaneously blockified and inlinified.
• Assert: CSS specifications MUST prevent non-principal element-generated boxes from being blockified or inlinified.

[tabatkins]

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?

[Loirooriol]

No, I think this was all.

[fantasai]

Agenda+ for WG verification:

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

[fantasai]

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

[Loirooriol]

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?

[c-smile]

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.

[Loirooriol]

@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;

[c-smile]

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

[tabatkins]

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.

[c-smile]

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.

[Loirooriol]

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.

[tabatkins]

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.

[dbaron]

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...)

[astearns]

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

[fantasai]

@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.

[fantasai]

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

[css-meeting-bot]

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

The full IRC log of that discussion

<dael_> Topic: Defining box ↔ element style correspondence
<fantasai> https://github.com//issues/1643#issuecomment-374414522
<dael_> Github: https://github.com//issues/1643
<fantasai> https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3
<dael_> fantasai: We got two issues out of the one filed. First is that it's not defined that the things that apply to and element apply to a box. We tightent hat in this change set ^
<dael_> fantasai: That's the first issue.
<dael_> florian: Is it a one to one corrispondance?
<dael_> fantasai: No because some apply to principle box and some to others. On a table some are to wrapper box and some to table. So we said computed value to the box to which it applies.
<dael_> astearns: Quick read from me seems like that change is good.
<dael_> astearns: It's really expanding on the sort sentence we had.
<dael_> fantasai: Yes.
<dael_> astearns: Objections to this change?
<dael_> RESOLVED: Accept change set https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3
<dael_> florian: Question, you're saying inherited prop inherit through box tree. Does that do strange when some boxes are surpressed?
<dael_> fantasai: I don't htink so. When they're surpressed they're not in the box tree.
<dael_> fantasai: I don't know of a ase when an element generates two boxes where one is the child then the other and there's a surpressed box between.
<dael_> florian: So children of display:none has no inheritence?
<dael_> fantasai: Inheritence happens in the element tree. Before and after boxes inherit. Anon boxes inherit. First you do the cascade, then inheritencec, then you get prop for every element in the tree.
<dael_> florian: Sentence i"m reacting to is a clarification, not a requirement. It's not clear that's what was meant. It confused me.
<dael_> fantasai: Sentence says [reads]. So I don't know where you'll get a problem.
<dael_> florian: If you think enough there's only one explination and it's the sane one.
<fantasai> + In general, <a>inherited properties</a> are assigned to the <a>principal box</a>,
<fantasai> + and then inherit through the box tree
<fantasai> + to any other boxes generated by the same element.
<dael_> astearns: If you can come up with something clearer feel free to make a PR
<dael_> florian: This is fine.
<dael_> astearns: Second change?
<dael_> fantasai: Second it was asking for guidance on box tree construction. We added an appendix.
<fantasai> https://drafts.csswg.org/css-display-3/#box-guidelines
<dael_> fantasai: It has four bullet points of things you need to define if you're writing a spec that changes boxes.
<dael_> astearns: Looks fine to me.
<dael_> florian: That's useful.
<dael_> astearns: Objections to adding this appendix to display 3?
<dael_> RESOLVED: Add the appendix https://drafts.csswg.org/css-display-3/#box-guidelines to Display 3
<dael_> fantasai: That's if for this issue. There was a grumble about 2.1 termonology.

[davidsgrogan]

@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]

@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.

[fantasai]

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?

[Loirooriol]

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