Repository navigation
[css-display] More precise box transformations #1643
Description
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
blockand, if its inner display type is layout-internal, it is set toflow. - Definition: inlinifying an element sets its outer display type to
inlineunless it was layout-internal. If the inner display type isflow, 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.
Activity
tabatkins commentedon Dec 8, 2017
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:
Was there something else that needs fixing?
Loirooriol commentedon Dec 8, 2017
No, I think this was all.
[css-display] Add spec-author guidance for box construction, per #1643.
fantasai commentedon Mar 19, 2018
Agenda+ for WG verification:
fantasai commentedon Mar 19, 2018
@Loirooriol Please let us know if these edits are satisfactory!
Loirooriol commentedon Mar 19, 2018
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
displayapplies) 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 commentedon Mar 22, 2018
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
displaything.Like flexbox inside table-cell still prohibited by current CSS state of affairs.
It really should be something like this:
and
in the same way:
Otherwise we will keep inventing that wheel forever.
Loirooriol commentedon Mar 22, 2018
@c-smile I expect that a future level of the spec will say
7 remaining items
fantasai commentedon Apr 4, 2018
@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.
[css-display-3] table grid box -> table box to match CSS2.1 terminolo…
fantasai commentedon Apr 4, 2018
@dbaron Switched “table grid box” to “table box”. Also filed #2501
css-meeting-bot commentedon Apr 4, 2018
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/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3RESOLVED: Add the appendix https://drafts.csswg.org/css-display-3/#box-guidelines to Display 3The 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 commentedon Apr 10, 2018
@tabatkins
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)?
https://jsfiddle.net/dgrogan/9uduq99L/5/
dbaron commentedon Apr 12, 2018
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.
[css-display-3] table grid box -> table box to match CSS2.1 terminolo…
fantasai commentedon Jul 25, 2018
@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 commentedon Jul 25, 2018
I suspect some future update may require more precise definitions to avoid ambiguity, but I guess the meaning is clear enough for now, OK.