Skip to content

[css-display] Parent box of run-in or non-principal box #3158

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
Loirooriol opened this issue Sep 26, 2018 · 10 comments
Closed

[css-display] Parent box of run-in or non-principal box #3158

Loirooriol opened this issue Sep 26, 2018 · 10 comments
Labels
Closed Accepted as Obvious Bugfix Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-display-3 Current Work

Comments

@Loirooriol
Copy link
Contributor

Loirooriol commented Sep 26, 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.

Run-in boxes are described as an exception, but their "parent box" is not properly defined. Should be done in https://drafts.csswg.org/css-display-3/#run-in-layout. Intuitively it will be the "block box that does not establish a new block formatting context" to which the run-in sequence "is inserted as direct children".

And also the "parent box" of a non-principal box is not defined. In all element-generated cases it seems to be the principal box of the generating element. For anonymous boxes, maybe the nearest ancestor in the box tree which is a principal box.

@Loirooriol Loirooriol added the css-display-3 Current Work label Sep 26, 2018
@fantasai
Copy link
Collaborator

I don't think we need to define that if Box A is made to be a direct child of box B, Box B is the parent of Box A. That's implied because we're assuming people understand the semantics of English.

Is there something else I'm missing here?

@Loirooriol
Copy link
Contributor Author

@fantasai I'm complaining that the definition is not clear. Frankly I'm not sure whether this "parent box" concept just refers to the parent (the graph theory concept) in the box tree?

In that case I don't get why you are providing some kind of partial definition. It's confusing because it's looks like you are trying to define something different than the trivial concept, but it's not properly defined. And as you say, it's implied, so I would just remove it.

If this is a different concept, the definition should state the difference clearly, like

The parent box of a box is its nearest ancestor in the box tree which is not an element-generated non-principal box.

@fantasai
Copy link
Collaborator

fantasai commented May 16, 2019

The sentence you're quoting in the OP is there because otherwise we've defined that there's an element tree (which has parent-child relationships), and each element generates a box, but it's not otherwise defined how the boxes are related into a tree. The parent-child relationships of the boxes, in the general case, is not implied by anything else in the spec than this sentence.

As for “I'm complaining that the definition is not clear”, what, specifically, is not clear? What alternative interpretation are you coming up with that isn't intended by the spec, and how is that supported by the spec?

@Loirooriol
Copy link
Contributor Author

Loirooriol commented May 16, 2019

what, specifically, is not clear?

Well, it seems the definition is excluding element-generated non-principal boxes for some reason. And it's not clear whether this is intentional.

Like if you have a <tbody> which is a child of a <table>, the definition implies that the parent box of the table-row-group box is the table wrapper box instead of the table grid box.

it's not otherwise defined how the boxes are related into a tree

OK, it seems what you are trying to impose is

In the box tree, the boxes generated by an element are descendants of the principal box of any ancestor elements.

I would prefer something like that: it's not a concept definition but an instruction for the tree construction, and has no vague exception. Sure, it's still not completely detailed, but this can't be done in a single sentence.

@fantasai
Copy link
Collaborator

Well, it seems the definition is excluding element-generated non-principal boxes for some reason. And it's not clear whether this is intentional.

Aha. That's definitely an error. :)

In the box tree, the boxes generated by an element are descendants of the principal box of any ancestor elements.

Hm, that's a good one. I've rearranged some of the sentences and incorporated yours, it's now a separate paragraph before the one defining "anonymous boxes", like this:

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.

What do you think?

@Loirooriol
Copy link
Contributor Author

Loirooriol commented May 21, 2019

That's great, thanks! Well, as a mathematician I would use "Usually" instead of "In the general case" since being an ancestor is more general than being a parent, though I guess the expressions are synonyms in normal English :)

Another nit: "such as" is repeated in the same sentence, maybe replace one of them with "like" or another synonym.

@fantasai
Copy link
Collaborator

The "general case" is the parent box being the principal box of the nearest ancestor element that generates a box. :)

Switched to like and moved parenthetical. Current text:

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.

@fantasai fantasai added Agenda+ Closed Accepted as Obvious Bugfix Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Commenter Response Pending labels May 23, 2019
@fantasai
Copy link
Collaborator

fantasai commented May 23, 2019

Agenda+ to confirm, and request republication.

List of changes at https://drafts.csswg.org/css-display-3/#changes ; specific changes can be seen at

@fantasai
Copy link
Collaborator

Disposition of Comments https://drafts.csswg.org/css-display-3/issues-cr-2018

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Parent box of run-in or non-principal box, and agreed to the following:

  • RESOLVED: Republish Display
The full IRC log of that discussion <dael> Topic: Parent box of run-in or non-principal box
<dael> github: https://github.com//issues/3158
<dael> fantasai: Trying to load this. I suspect this issue is just verifying something
<dael> astearns: This is where you asked for repub so maybe this should be the last.
<dael> fantasai: I think we brought this in F2F when requested pub. I think we reviewed
<dael> astearns: And there are changes from a month ago. No changes to spec since F2F
<dael> fantasai: I think when we resolved to pub it was including these and we forgot to remove agenda+
<dael> astearns: We did resolve to repub a month ago?
<dael> fantasai: Yeah
<dael> astearns: It's jsut not in this issue.
<dael> astearns: That was display.
<dael> fantasai: Yes, we don't have resolution for grid. Do for display
<dael> astearns: Should we re-resolve to publish display?
<dael> fantasai: I think resolution was in F2F but we can do it again
<dael> astearns: Objections to republish Display?
<dael> astearns: There's a DoC and a diff
<chris> sounds good to me
<dael> RESOLVED: Republish Display
<chris> rrsagent, here
<RRSAgent> See https://www.w3.org/2019/06/19-css-irc#T16-09-25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted as Obvious Bugfix Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-display-3 Current Work
Projects
None yet
Development

No branches or pull requests

3 participants