Bug 299950 – Anchored elements using position-area are incorrectly shifted vertically to pull them into the viewport

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Ehren]

Created attachment 476916 [details]
Safari on left, Chrome on right.

Overview:
If an anchored element is too tall to fit within the viewport at its anchored position, it's shifted upwards in an attempt to display the entire element. This occurs even when there's enough space in the document below the anchored element.

Demo:
https://codepen.io/eharber/pen/qEbNzya?editors=1100

There is a 50vh element above the toggle which simulates content. The 80vh anchored popover element has plenty of space below it (200vh), so it should occupy that space when it's toggled.

Expectation:
The menu should be positioned below the toggle button (as in Chrome)

Result: 
In Safari 26.0, the anchored element overlaps the toggle button because it's vertical position has been altered to ensure the element is within the viewport. Screenshot attached showing comparison of Safari and Chrome.

[Radar WebKit Bug Importer]

<rdar://problem/161741583>

[Kiet Ho]

It seems like it's this behavior in the spec:

> If the box overflows its inset-modified containing block, but would still fit within its original containing block, by default it will “shift” to stay within its original containing block, even if that violates its normal alignment. See CSS Box Alignment 3 § 4.4 Overflow Alignment: the safe and unsafe keywords and scroll safety limits for details.
> This behavior makes it more likely that positioned boxes remain visible and within their intended bounds, even when their containing block ends up smaller than anticipated.
> For example, a position-area: bottom span-right value lets the positioned box stretch from its anchor’s left edge to its containing block’s right edge, and left-aligns it in that space by default. But if the positioned box is larger than that space (such as if the anchor is very close to the right edge of the screen), it will shift leftwards to stay visible.

WebKit implements this but not Chrome (yet).

[Kiet Ho]

Link to the spec (which I forgot): https://drafts.csswg.org/css-anchor-position-1/#position-area-alignment

[Ehren]

Created attachment 476934 [details]
Poor alignment of position-area:bottom element

[Ehren]

Thanks for the reply Kiet! Just to clarify, since the spec can be a little overwhelming at times (for me)..

Shifting the inline axis, as mentioned in the example above, makes sense. Safari does this correctly, ensuring the popover doesn't overflow the viewport and therefore stays accessible. After this inline shift, the anchor element is still visible/accessible.

Does the spec clarify that this shift should also occur for the block axis too? Keeping in mind that the anchor element will be obscured in this case. 

Attached above is a video demonstrating that even though there's plenty of space below the anchor, the menu still shifts vertically. This shift covers the anchor element (button) and prevents the popover="manual" element from being closed. The Codepen demo from above has been updated to show the implications of this with manual popovers.

If this is still correct according to the spec, please let me know. It just seems odd as I was under the impression that anchor elements (the button in this example) should never be obscured, and that the anchored popover element should simply reposition itself *around* the anchor, not *directly on top* of it.

Thanks again!

[fantasai]

> Does the spec clarify that this shift should also occur for the block axis too? Keeping in mind that the anchor element will be obscured in this case. 

Yes. But there is also a provision in the spec that the containing block (the rectangle in which we should be constrained) should be the entire scrollable area in this case. I think we'll need to fix that for this to work correctly.

[fantasai]

Pull request: https://github.com/WebKit/WebKit/pull/51718

[EWS]

Committed 300921@main (6d342d3c33b9): <https://commits.webkit.org/300921@main>

Reviewed commits have been landed. Closing PR #51718 and removing active labels.

[EWS]

Committed 297297.512@safari-7622-branch (adaa1a9ab8d4): <https://commits.webkit.org/297297.512@safari-7622-branch>

Reviewed commits have been landed. Closing PR #3756 and removing active labels.