[csswg-drafts] [css-position-3] Containing block formed by fragmented inlines (#8284)

fantasai has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-position-3] Containing block formed by fragmented inlines ==
CSS2.1 defines the containing block formed by an inline box like this:
> In the case that the ancestor is an inline element, the containing block is the bounding box around the padding boxes of the first and the last inline boxes generated for that element.
> In CSS 2.1, if the inline element is split across multiple lines, the containing block is undefined. 

In CSS Positioning Level 3, we tried to generalize the definition in a way that would handle multiple lines:

> If the ancestor is an inline box, the containing block is formed by the block-start and inline-start content edges of the first box fragment of the ancestor, and the block-end and inline-end content edges of the last box fragment of the ancestor.

This basically takes (for LTR text) the top/left edges of the first fragment and the bottom/right edges of the last fragment and makes a rectangle of them. The “left” box edge might end up as the “right” containing block edge, but in any case there's a rectangle.

What browsers actually do is demonstrated in [this testcase](https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%3Cdiv%20style%3D%22background%3A%20gray%3B%20width%3A%20100px%3B%20height%3A%201em%3B%20display%3A%20inline-block%22%3E%3C%2Fdiv%3E%3Cspan%20style%3D%22position%3A%20relative%3B%20border%3A%20solid%20blue%22%3E%3Cspan%20style%3D%22position%3A%20absolute%3B%20inset%3A%200%3B%20border%3A%20orange%20solid%22%3E%3C%2Fspan%3Efirst%20and%3Cbr%3Esecond%20line%20that%27s%20very%20long%20and%3Cbr%3Ethird%3C%2Fspan%3E%0A%3Cp%3E%3Cspan%20style%3D%22position%3A%20relative%3B%20border%3A%20solid%20blue%22%3E%3Cspan%20style%3D%22position%3A%20absolute%3B%20inset%3A%200%3B%20border%3A%20orange%20solid%22%3E%3C%2Fspan%3Efirst%20and%3Cbr%3Esecond%20line%20that%27s%20very%20long%20and%3Cbr%3Ethird%3C%2Fspan%3E):
* Firefox takes the padding area of the first line's fragment only.
* WebKit/Blink start at the top/left corner of the first line's fragment, then extend to the bottom edge of the last line's fragment, and extend it *rightwards only* as far as the right edge of the last line's fragment. If the last line's fragment's right edge is to the left, the containing block is zero-width.

The question here is, what actually is the most useful thing to do?
* Use the first line's fragments only (so the entire containing block is contained by its generating box).
* Anchor at the start/start corner of the first line box and extend to the end/end corner of the last line box, but clamp the inline size at zero (so the end/end corner might not overlap with a fragment).
* Anchor at the start/start corner of the first line box and extend to the end/end corner of the last line box, and allow inversions (so the corners are pinned to actual fragment corners, but the containing block might end up between fragments).
* Anchor at the start/start corner of the first line box and extend to the end/end corner of either the last line box (if that's endward of the start line) or of the first line box (otherwise).
* Something else?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8284 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 6 January 2023 21:35:03 UTC