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: Loirooriol via GitHub <sysbot+gh@w3.org>
Date: Wed, 17 May 2017 16:09:34 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-302139862-1495037373-sysbot+gh@w3.org>
After the edit in CSS ruby it's a bit more clear, but the ordering in https://github.com/w3c/csswg-drafts/issues/1355#issuecomment-301878155 should probably be explicitly explained in the Introduction of CSS Display.

However, I think it's not that simple. For example,

> position and float both blockify, and take it out-of-flow so the others don't do anything

This is not what happens in a flex or grid context, because floating does not apply to flex or grid items, so "others" (the blockification induced by the formatting context) does "something". But floating applies in a ruby context. So I believe Tab's step number 1 in fact is something like the following:

>  1. Import the contents of the document node into an undefined box with flag keep-open set to false.
> 
> To import the contents of a node *N* into a box *B* with a boolean flag keep-open, do
>  1. Let *F* be an undefined formatting context.
>  2. If *B* is not undefined,
>     1. Set *F* to the formatting context established by the nearest inclusive ancestor box of *B*.
>  3. For each child node *C* of *N*
>     1. If *C* is an element node,
>        1. Import element *C* into box *B* in a context *F*.
>     2. Otherwise, if *C* is a text node,
>        1. Assert: *B* and *F* are not undefined.
>        1. Consume following text node siblings.
>        2. This sequence of text nodes generate a text run *T*, which is assigned the same styles as the generating text nodes.
>        3. Tentatively insert the text run *T* into *B* using *F*'s algorithm.
>  4. If *B* is not undefined and flag keep-open is true,
>     1. Close box *B* using *F*'s algorithm.
> 
> To import an element *E* into a box *P* in a context *F*,
>  1. If *E* is the root element,
>     - `display: contents` is treated as `block`.
>  2. If `display` has the value `none`,
>     - Positioning and floating do not apply.
>     - The element *E* generates no box.
>     - End this algorithm.
>  3. If `display` has the value `contents`,
>     - Positioning and floating do not apply.
>     - The element *E* generates no box.
>     - Import the contents of *E* into the box *P* with flag keep-open set to true.
>     - End this algorithm.
>  4. *E* generates a box *B* according to the `display` value, which is assigned the same styles as *E*.
>  5. Let in-flow be a boolean flag.
>  6. If the *E* is the root element,
>     - Not sure if it has already been decided whether `position` may be treated as `static` and `float` may be treated as `none` or not. Handle appropriately.
>  7. Otherwise, absolutely positioning applies if specified. In that case,
>     - The box *B* is blockified.
>     - Floating does not apply.
>     - Set in-flow flag to false.
>  8. Otherwise, if *F* blockifies,
>     - The box *B* is blockified.
>     - Floating does not apply.
>     - Set in-flow flag to true.
>  9. Otherwise, floating applies if specified. In that case,
>     - The box *B* is blockified.
>     - Set in-flow flag to false.
> 10. Otherwise, if *F* inlinifies,
>     - The box *B* is inlinified.
>     - Set in-flow flag to true.
> 11. Otherwise,
>     - Set in-flow flag to true.
> 12. If *P* is defined,
>     1. If box *B* has a `flow` inner display type and has a different `writing-mode` than box *P*,
>        - The inner display type of box *B* computes to `flow-root`
>     2. Tentatively insert *B* into *P* with in-flow flag using *F*'s algorithm.
> 13. Otherwise,
>     - The box *B* is blockified.
>     - The box *B* becomes the root box.
> 14. Possibly let *B* establish a new formatting context according to its inner display type.
> 15. Import the contents of *E* into the box *B* with flag keep-open set to false.

Each formatting context should define (this is Tab's step 2):

 - When a new box is tentatively inserted inside another box in that formatting context, whether anonymous boxes should be inserted in between, or the inner one should break the outer one, etc. This might depend on the display types of these two boxes and on the in-flow flag.
 - When a text run is tentatively inserted inside another box in that formatting context, whether anonymous boxes should be inserted in between, or the text run should be discarded, etc. This might depend on the display types of that box.
 - When a box is "closed" in that formatting context, whether anonymous boxes should be inserted inside, or the box should be discarded, etc. This might depend on the display types of that box.
 - Additional hooks may be needed.

But what if some of these anonymous boxes inserted in-between do inlinify or blockify their contents, or do something which is supposed to be handled in Tab's step 1? I don't think this is currently possible, but as Boris says, adding a new fixup could mess this up.

Anyways, in the algorithm above I'm sure I missed lots of details. I would love someone to do it properly and include it in some spec.

-- 
GitHub Notification of comment by Loirooriol
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1355#issuecomment-302139862 using your GitHub account
Received on Wednesday, 17 May 2017 16:09:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 10:12:53 UTC