[css-position-3] Coordinates of Containing Blocks of Positioned Boxes from Inline Boxes with Mixed Bidi Direction Text Content are Unclear

[bernhardf-ro]

"css-position-3: 2.1. Containing Blocks of Positioned Boxes" says:

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.

When taking into account bidi (see "css-writing-modes-3: 2.4.5. Reordering-induced Box Fragmentation") it is unclear whether first and last are meant logically or visually.

While we consider visual the only useful and expected interpretation in this case, we normally would assume logical when nothing is specified.

Chrome and Firefox have different interpretations:

Source:

<p dir="rtl"><span style="position: relative;">abc&#x5d0;def<span style="position: absolute; left: 0; top: 0; bottom: 0; border-left: 0.1em solid red"></span></span></p>

Chrome (visual):

Firefox (logical):

This also demonstrates how unexpected the logical version is.

Whether extending the paragraph is enough or the processes requires more detailed specification we are not sure.

[fantasai]

Thanks, this looks like an error in translating the spec from CSS2. The correct definition is this one: https://www.w3.org/TR/CSS2/visudet.html#containing-block-details

[bernhardf-ro]

Is there a specific reason to not go for the bounding box of all inline boxes of the element?
In the inline direction it would make sure exactly the full visual width is covered, no matter how the boxes are ordered, e.g. through bidi.
In the block direction it also would lead to more consistent results, again avoiding unexpected behavior due to things like bidi.

[tabatkins]

Is there a specific reason to not go for the bounding box of all inline boxes of the element?

Yes, there is. If the first fragment is a small portion at the end of a line, for example, then positioning yourself at the start/start corner of the bounding box will cause you to position in an unrelated area, not next to any fragment of the actual inline.

The edits we just pushed do clarify that when there are multiple fragments on the first/last line, you take the visually first/last one (for the reasons you gave in the original comment).

That said, it doesn't appear to be super well-defined what it means if the edges of a containing block are in the wrong order, so we're raising that as a separate issue.

[fantasai]

Filed issue about multi-line containing blocks here: #8284

[bernhardf-ro]

Thanks for elaborating.
The edit looks good to us.
We will have a look at #8284 and give feedback later.