W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2017

Re: [csswg-drafts] Please define how the various box tree fixups interact

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Wed, 17 May 2017 22:36:22 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-302250667-1495060581-sysbot+gh@w3.org>
Filed @upsuper's question about inlinification of layout-internal types as #1390.

Wrt @bzbarsky's comment https://github.com/w3c/csswg-drafts/issues/1355#issuecomment-301968713

```<span style="display: grid"><span style="display: ruby-text-container"><div></div></span></span>```

According to CSS Display, 

> To create the box tree, CSS first uses cascading and inheritance, to assign a computed value for each CSS property to each element in the source tree. (See [CSS3-CASCADE].)
> Then, for each element, it generates zero or more boxes as specified by that element’s display property.

The question in @bzbarsky's example is that, if we resolve `ruby-text-container`'s computed value first, then it becomes `block` and the inner `div` remains a `block` as well. If we resolve the inner `div`'s computed value first, then it becomes an `inline-block`.

A general principle of CSS is that constraints, insofar as we can make them so, are insensitive to a timeline and described as a steady state, and appending elements to the tree shouldn't have unexpected implicit side-effects on earlier elements. If we convert the innermost `div` to `inline-block` because it is inside a `ruby-text-container`, and then convert the `ruby-text-container` to a `block`, then we notice that the inner `div` has lost its reason for being an `inline-block`. This isn't how we want things to work: starting with a tree without the inner div, and then inserting it later, it would be a `block` not an `inline-block`.

Furthermore, inheritance and style computation works from the top down. We compute against the computed value of a parent's `display`, not its specified or cascaded value. And if we're looking at the box tree, certainly the boxes so generated are done based on the computed value of `display`, not its specified or cascaded value, because the computed value is what determines the type of box to generate. So I think we can safely say that the intent is for this example to result in a grid containing a block containing a block.

>  In my example above with grid and ruby-text-container, does the fixup, if any, for the <div> take place before or after fixup, if any, for the inner <span>? Where is this ordering defined? Are all fixups applied to a given element before any fixups are applied to its descendants, or is each fixup performed as a separate pass over the tree?

Computed value fixups that reference either a parent's `display` value or its box type by definition reference its computed `display` value (which is final), not some hypothetical in-between state. This requires that all fixups are applied to a parent before its children are evaluated.

GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1355#issuecomment-302250667 using your GitHub account
Received on Wednesday, 17 May 2017 22:36:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:12 UTC