[css-anchor-position] Should scroll-margin/padding have an effect on position-visibility: anchors-visible?

[kizu]

Was playing with the position-visibility: anchors-visible (https://drafts.csswg.org/css-anchor-position-1/#position-visibility), and I think it might be useful to take the scrollable area's scroll-padding or the anchor's scroll-margin into consideration (https://drafts.csswg.org/css-scroll-snap/#propdef-scroll-padding). An example: https://codepen.io/kizu/pen/BaedPEB

Screen.Recording.2024-06-09.at.17.02.21.mov

Here we can see how if we have some fixed element reducing the effective visible area of our scrollable container, we'd want to consider it for the position-visibility. Hooking it onto scroll-margin and scroll-padding sounds logical, as this is very similar to other similar cases like scrolling or snapping to the targeted element.

[johannesodland]

Yeah, that would be useful in a lot of cases.

It might be smart to do something similar to Scroll-driven Animations, where view-timeline-inset: auto is specced to use the values of scroll-padding while it is still possible to specify a custom length-percentage value.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position] Should scroll-margin/padding have an effect on position-visibility: anchors-visible?, and agreed to the following:

• RESOLVED: the 'anchors-visible' value takes 'scroll-padding' and 'scroll-margin' into account for determining if the anchor is visible

The full IRC log of that discussion

<TabAtkins> kizu: rn when we use position-vis:anchors-visible for an anchor in a container, it hides when the anchor scrolls outside the scrollport
<TabAtkins> kizu: i think it would be useful to account for scroll-margin and scroll-padding for this
<TabAtkins> kizu: usual case for these properties is you ahvea sticky element or header floating over the scroller.
<TabAtkins> kizu: you probably want to treat the anchor as hidden when it's under that area
<TabAtkins> astearns: makes sense to me
<TabAtkins> TabAtkins: agreed
<TabAtkins> proposed: the 'anchors-visible' value takes 'scroll-padding' and 'scroll-margin' into account for determining if the anchor is visible
<TabAtkins> astearns: questions?
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: the 'anchors-visible' value takes 'scroll-padding' and 'scroll-margin' into account for determining if the anchor is visible
<TabAtkins> kizu: i'll spend some more time on scroll-padding/margin when using nested scrollers, no interop.
<TabAtkins> astearns: yeah, assume WPT woudl only be testing single scrollers for simplicity

[fantasai]

I think I'd like to re-open this issue. For things that are actually hidden this makes sense, but as long as the anchor is actually visible, we shouldn't consider it hidden. I think it would be surprising to users if a panel disappeared at some arbitrary point in its scroll passage across the screen.

The scroll-padding property has several uses, one of which is to provide some breathing room when snapping items into the viewport, and another of which which is to screen out areas where fixedpos toolbars are blocking content. Although for the first use case, we wouldn't want to take it into account, given the second use case, it could be reasonable. Maybe. But I don't think we should ever consider scroll-margin here.

[tabatkins]

Yeah, I can go either way. I agree that this is meant to handle the case when the anchor is fully hidden, so it seems somewhat reasonable to ignore scroll-margin/padding, but I'm fine either way (as expressed on the call).