2003850 - alignment of abspos element uses placeholder's writing mode

Status: NEW

(Core :: Layout: Positioned, enhancement)

Description

[David Shin[:dshin]]

Attachment: Minimum Reproducible Case

As per spec, writing mode of the alignment container:

[...] assumes the writing mode of the box establishing the containing block.

For abspos, the containing block should be the absolute containing block. Maybe the term is ambiguous, but we clearly align against it.

OTOH, We seem to use the placeholder's writing mode by calling alignment keyword resolution using the placeholder frame, here. This seems incorrect.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (same as testcase 1, but moved `writing-mode: vertical-lr;` decl to the abspos element)

OTOH, We seem to use the placeholder's writing mode by calling alignment keyword resolution using the placeholder frame, here.

It appears we're using the writing-mode of the placeholder's in-flow containing block (not the writing-mode of the placeholder itself).

In this attached testcase, I've moved the writing-mode decl from the in-flow containing block to the abspos element itself (directly targeting the placeholder), and that changes the rendering, which demonstrates that it's probably not the placeholder's WM that's influencing our rendering here.

Comment 2

[Daniel Holbert [:dholbert]]

Relevant code-comment here:
https://searchfox.org/firefox-main/rev/965f7176dd09e26daca9efbfdf23dce16da43e97/layout/generic/AbsoluteContainingBlock.cpp#647-652

// NOTE: Our alignment container is aPlaceholderContainer's content-box
// (or an area within it, if aPlaceholderContainer is a grid). So, we'll
// perform most of our arithmetic/alignment in aPlaceholderContainer's
// WritingMode. For brevity, we use the abbreviation "pc" for "placeholder
// container" in variables below.
WritingMode pcWM = aPlaceholderContainer->GetWritingMode();

That's the bit that describes what we're currently doing (though it does seem to disagree with Chrome in this case).

We also allude to the placeholder's parent being the thing to use to reason about (with respect to writing-mode & what axis "justify-"/"align-" refer to) here:
https://searchfox.org/firefox-main/rev/965f7176dd09e26daca9efbfdf23dce16da43e97/layout/generic/AbsoluteContainingBlock.cpp#618-621

* @param aPlaceholderContainer The parent of the child frame's corresponding
*                              placeholder frame, cast to a nsContainerFrame.
*                              (This will help us choose which alignment enum
*                              we should use for the child.)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (comparing no-WM-specified, vs. vertical WM on in-flow container, vs. vertical WM on abspos element)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (no insets specifiied, and trying a variety of {align,justify}-self values

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 5 (same as testcase 4 but now with "inset: 0" on abspos)

Comment 6

[Daniel Holbert [:dholbert]]

testcase 4 doesn't render anything special in Firefox or Safari; all of the black boxes are at the top-left of their CB (with the static position not being influenced by the alignment keywords at all), which is interesting...

But Chromium handles testcase 4 by aligning the black boxes using axes determined by the writing-mode of the in-flow containing block (which matches our documentation that I quoted in comment 2). i.e. the left half of the second line, the 'justify-self' values are influencing the vertical alignment of the black box (which corresponds to the inline axis of the in-flow containing block).

Whereas in testcase 5, Chromium uses axes determined by the abspos containing block, I think -- they treat all three lines the same (ignoring the writing-mode of the in-flow containing block and the writing-mode of the abspos element itself for alignment-axes-determinatino purposes).

That discrepancy between testcase 4 and testcase 5 seems like a bug in Chromium... And before we take action here, I think we need to figure out which of those Chromium behaviors is correct.

The original testcase here is sort of a version of testcase 5. And if Chromium's rendering of testcase 4 is correct and testcase 5 is incorrect, then our rendering of the original testcase and testcase 5 is correct (I think).