Percentages in top/left/bottom/right properties are relative to the containing block

[SimonSapin]

In this code:

victor/victor/src/layout/mod.rs

Line 249 in dcdc5f6

let relative_adjustement = relative_adjustement(style, inline_size, block_size);

The size of a block box is given as a basis to resolve percentages in offset properties if that same box is position: relative. Instead, the size of the containing block should be used. However at this point in the code, the block-direction size of the containing block might not be known yet. Therefore the computation of position: relative offsets must be delayed until later, when it is known. Options include:

• When the "main layout phase" is finished for a containing block, do a another sub-tree traversal to find and adjust position: relative descendants that have this containing block. (They are not necessarily direct children in the box tree, for example for inline boxes.)

• Keep track during the main phase of a list of position: relative descendants, like we already do for postition: absolute. This has an allocation and memory cost.

• Only account for position: relative offsets during the "painting" phase. (Or eventually in Servo, during display list construction.)

The last one seems preferable to me, but requires keeping track of containing blocks in the fragment tree. (The containing block is not necessarily the direct parent fragment, again because of nested inline boxes.)

CC @nox

[emilio]

Does position: relative contribute to overflow in any way? What about position: sticky, which is quite similar?

I'd be wary of handling relative / sticky positioning during painting, I know Chrome handles part of the sticky positioning after layout and it's a pain for them:

• https://bugs.chromium.org/p/chromium/issues/detail?id=752095
• https://bugs.chromium.org/p/chromium/issues/detail?id=930327

In particular, for CSSOM and other layout queries like offsetFoo you don't really want to go into painting code, but you do need sticky / relative offsets.

[SimonSapin]

Good point. Do you mean the scrollable overflow region? I assume relpos does contribute to it since even transforms are accounted for in that spec. (Positioning is not mentioned explicitly.)

[nox]

• Keep track during the main phase of a list of position: relative descendants, like we already do for postition: absolute. This has an allocation and memory cost.

We can't really do that for relatively positioned elements IMO, that would change the order of the fragments.

[nox]

Could we just add an Option<BoxOffsets> field in BoxFragment, with the following type:

struct BoxOffsets {
    inline_start: LengthOrPercentageOrAuto,
    inline_end: LengthOrPercentageOrAuto,
    block_start: LengthOrPercentageOrAuto,
    block_end: LengthOrPercentageOrAuto,
}

[nox]

The size of a block box is given as a basis to resolve percentages in offset properties if that same box is position: relative. Instead, the size of the containing block should be used. However at this point in the code, the block-direction size of the containing block might not be known yet. Therefore the computation of position: relative offsets must be delayed until later, when it is known. Options include:

Could you provide a sample exhibiting this? I couldn't reproduce.

[nox]

AFAICT by doing some samples, if the containing block doesn't have an non-auto height, then percentages for relative vertical positioning just resolve to 0.

[SimonSapin]

Oh, wonderful. It looks like at least Firefox and Chromium have interop and disagree with the spec.

For the height property there’s:

If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'.

… but nothing similar for offset properties.

[SimonSapin]

Test case: remove the height declaration in https://codepen.io/anon/pen/OYEWXd

[emilio]

Try on quirks mode / no quirks mode for fun / sadness :)

[SimonSapin]

@emilio Do you mean in general or in this specific case? I couldn’t reproduce a behavior change when adding or removing a doctype in the test case above.

[emilio]

Not in Gecko, but without the height on the <body>, different UAs size the <body> differently in quirks mode vs. not.