Skip to content

[css-display-3] parent box vs anon boxes #3259

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
prjnt opened this issue Oct 28, 2018 · 5 comments
Closed

[css-display-3] parent box vs anon boxes #3259

prjnt opened this issue Oct 28, 2018 · 5 comments

Comments

@prjnt
Copy link

prjnt commented Oct 28, 2018

https://drafts.csswg.org/css-display-3/#css-parent-box says:

The parent box of an element’s principal box is (except in the case of run-in) the principal box of its nearest ancestor element that generates a box.

The above implies that an anonymous box is not the parent box of any element's principal box, whereas I believe that it is desired that anonymous boxes can have an element's principal box as a child box, and that the anonymous box should sometimes furthermore establish the containing block for an element's principal box.

@Loirooriol
Copy link
Contributor

I believe that it is desired that anonymous boxes can have an element's principal box as a child box

IMO the problem is that this "parent box" concept has a misleading name. It doesn't refer to the parent node in the box tree. So I agree that anonymous boxes can have children in the box tree, but they are just not taken into account by this "parent box" concept. I don't know whether this is appropriate because I haven't seen any use of the concept.

anonymous box should sometimes furthermore establish the containing block

I'm not that sure. In CSS2, it's true that anonymous boxes can generate a containing block, but then they are skipped when doing percentage resolution:

Anonymous block boxes are ignored when resolving percentage values that would refer to it: the closest non-anonymous ancestor box is used instead.

However, I haven't seen this statement ratified by any CSS3 spec. This makes me think that maybe anonymous boxes can no longer generate a containing block. In fact, before the big rewrite, CSS Box defined containing block like this:

<li>Otherwise, if the parent has a <a>principal
box</a> that is a <a>block container box</a>
(e.g., if the parent is a 'table-cell' or a 'block'),
then the containing block is the content edge of the
parent's <a>principal box.</a>

@prjnt
Copy link
Author

prjnt commented Oct 29, 2018

Renaming this concept to something other than "parent box" might well be an appropriate fix, assuming that there is indeed prose that intends to refer to this concept rather than parent node in box tree and that such prose can be updated to use the new name.

[Regarding anonymous boxes and percentages, note that the quoted CSS2 visuren.html text is limited to anonymous block boxes: other anonymous boxes, such as anonymous table cells, still establish the containing block in the sense of being used as the basis for resolving percentage widths.]

@fantasai
Copy link
Collaborator

No, it's just an error. The definition should match @prjnt's expectations in the OP. :)

fantasai added a commit that referenced this issue May 16, 2019
@fantasai
Copy link
Collaborator

OK @prjnt , I posted some edits. Lmk if it looks correct now or if you have any suggestions for improvement!

@fantasai
Copy link
Collaborator

Based on feedback from @Loirooriol in issue 3158, the text now reads

In constructing the box tree, boxes generated by an element are descendants of the principal box of any ancestor elements. In the general case, the direct parent box of an element’s principal box is the principal box of its nearest ancestor element that generates a box; however, there are some exceptions, such as for run-in boxes, display types that generate multiple container boxes (such as tables), and intervening anonymous boxes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants