[css-anchor-position] [css-position] Unclear whether `position: relative` inset should impact anchor positioning
Reading the spec, I see the following for position: relative:
The box is laid out as for static, then offset from the resulting position. This offsetting is a purely visual effect, and does not affect the size or position of any other box, except insofar as it increases the scrollable overflow area of its ancestors. This positioning scheme is called relative positioning.
My initial assumption is that this would also apply for anchor positioning, i.e. anchored elements would not move simply because we adjust the insets of a relatively positioned anchor. But Chrome seems to adjust for the relative positioning in the following markup.
Also this is more of a nitpick, but the following is not true for descendants of the relatively positioned box:
This offsetting is a purely visual effect, and does not affect the size or position of any other box
Note: Need to also make sure the behavior is clear for position: sticky.
This offsetting is a purely visual effect, and does not affect the size or position of any other box
This is kinda incorrect. relative positioning does affect things, e.g. the static-position gets shifted by the rel-pos offset as one example: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12874
Pushed some edits to css-position-3 to avoid the (potential) conflict, but I think this still needs clarification in css-anchor-position.
Right, relpos is for many purposes basically a layout-time shift (rather than a paint-time shift like transforms); the Chrome behavior is what I intended. (Basically, abspos/fixpos is clearly a "layout-time" affect, since absolute positioning is a layout mode on its own, and relpos/stickypos have always been lumped into the same boat in many ways.)
Clarifications added to the spec; the new section is structured to allow adding more details if there are further questions about what properties have an effect on anchors.
(Closing this as Editor Discretion; it's not quite an "obvious bugfix", but as Ian points out we already take relpos/stickypos into account for other layout-time effects where transforms are ignored, so this feels like a straightforward clarification.)