Bug 299950

<rdar://problem/161741583>

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).

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

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

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!

> 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.

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

Committed 300921@main (6d342d3c33b9): <https://commits.webkit.org/300921@main> Reviewed commits have been landed. Closing PR #51718 and removing active labels.

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.