Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-display] More precise box transformations #1643
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:
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?
added a commit
Mar 19, 2018
referenced this issue
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
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
Like flexbox inside table-cell still prohibited by current CSS state of affairs.
It really should be something like this:
in the same way:
Otherwise we will keep inventing that wheel forever.
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
In ideal world flexbox should be just
and flexes should be just flex units: width:
So grid and flexboxes could use the same flexibility principles and complement each other rather than compete as we have them now.
Not necessarily, flex and grid items may establish a FFC or a GFC instead of a BFC.
Table sizing is much more messed up.
This looks like
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.
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.
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...)
@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.
added a commit
Apr 4, 2018
The Working Group just discussed
The full IRC log of that discussion<dael_> Topic: Defining box ↔ element style correspondence
<dael_> Github: https://github.com//issues/1643
<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.
<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.
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)?
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.
added a commit
May 7, 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?