Re: [csswg-drafts] [css-display] Unclear definition of "formatting context" (#5105)

Thanks @Loirooriol, I really appreciate the examples why "continuing" a FC apparently is possible.

To be able for me to understand any of it, it's logically necessary to first establish a solid definition of FC, as the given definition as "environment" is not clear. I'm kind of fishing in the dark, since without the proper definition, I can't understand it, and without understanding it, I can't come up with the proper definition. It's like finding the mathematical function that maps each input to the correct output given only the input-output pairs.

I've been trying out a few definitions and want to share my latest attempt. It's not fully watertight though as there are still places in the spec which it can't explain. Please correct me, wherever my reasoning is wrong.

---

> A formatting context (FC) is a particular box layout applied to a set of boxes.

where "box layout" is Flow Layout, Flex Layout, Grid Layout, Table Layout, etc. as defined in the different Layout modules.

A FC can be thought of as "way to arrange a given set of boxes". Mathematically it can be thought of as a function which takes a set of boxes and assigns them coordinates and sizes.

It needs to be defined how a FC treats nested boxes. Most certainly we want to keep the boxes in the same logical order as they are nested in the box tree. For example in an inline FC, we want the following to be laid out as `foo1 bar1 bazbaz kikkik bar2 foo2`.

```css
<span id="foo">
  foo1
    <span id="bar">
      bar1
        <span id="baz">bazbaz</span>
        <span id="kik">kikkik</span>
      bar2
    </span>
  foo2
</span>
```

How would the FC define this order? What makes "bazbaz" come before "bar2" or "foo2"?

To solve this, we let each box define a FC. An FC applies only to the immediate children. It deals only with the flat set of boxes of box tree depth `0` and leaves any subtree that might be contained in it to the FCs of the nested boxes.

So the FC of `foo` only lays out "foo1", `bar` and "foo2". Then `bar` creates a FC which lays out "bar1", `baz`, `kik` and "bar2". And so on recursively.

The layout of boxes in a given FC is confined by the box that establishes the parent FC. Essentially, a given FC doesn't see the outside world. All it knows is the position constraint within the box of the parent FC.

The FCs are nested in the same way as the box tree.

The advantage of this definition of the term "FC" is that it is compatible with the definitions of the different existing FC. For example, the [block FC](https://www.w3.org/TR/CSS22/visuren.html#block-formatting) reads

> In a block formatting context, boxes are laid out one after the other, vertically, beginning at the top of a containing block.

Similarly the inline FC says "horizontally" instead. They have no notion of nested boxes. By eliminating the need for the FC to know how to handle nested boxes. For this it was necessary that each box creates a FC for its immediate children.

Also there is no notion of "continuing an existing" FC vs. "creating a new" FC anymore. Each box creates a FC, which might or might not be the same as the parent FC.

In the above example each `foo`, `bar`, `baz` and `kik` create an inline FC. So `foo` creates a FC in which it contains first "foo1" then `bar` then "foo2". Then `bar` creates a new FC in which it contains first "bar1" then `baz` and `kik` and then "bar2". Finally `baz` and `kik` each create a new FC which contain "bazbaz" and "kikkik" respectively.

Since each FC is confined to the parent FC, this explains why nested boxes are confined by boxes from further up in the box tree. In the example, "bazbaz" can never come after "bar2" or "foo2", because the FC created by `baz` is confined to the one created by `bar` which is confined to the one created by `foo`.

Visually I like to think about the FCs being nested in the same way as the boxes.

![inlinebox](https://user-images.githubusercontent.com/33468089/82737710-48e3c100-9d33-11ea-8516-4c7871a2ac8b.png)

-- 
GitHub Notification of comment by zjopy
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5105#issuecomment-633113271 using your GitHub account

Received on Saturday, 23 May 2020 18:33:44 UTC