[css-anchor-position] Fallback wrt scroll position

[tabatkins]

While chatting with @xiaochengh, we suddenly realized that, as far as we can tell, position fallback is actually completely worthless as specified. (Quick reminder - we lay out the element as specified, and if it overflows, swap some properties for the first fallback set and try again.)

As currently implemented (and specced, I guess), this overflow calculation is based on the element's scrollable ancestors (including the root scroller?) being at the initial scroll position. This negates the entire purpose of position fallback, which is to let you, say, have a select-like dropdown that positions below the anchor element if possible, or above if the anchor is too low in the page. As implemented it'll only concern itself with whether the anchor element is too close to the bottom of its parent element, not whether it's too close to the bottom of the screen itself, based on the current scroll position.

Are we missing something? Is this actually fine and allowed in the theoretical model, and we just need to clarify something in the spec? Or are we screwed, and need to adopt a totally different model that can just do fallback position but not change layout in any way, so it can be done in the compositor?

/cc @bfgeek @kojiishi

[bfgeek]

This negates the entire purpose of position fallback

Not the entire purpose - just for that specific use-case. Its still useful when no scrollers are present.

There are two potential solution spaces:

1) Part of the design initially was to snapshot the scroller positions (at some well defined time - previously this was when you would call the popup() method or similar), and store them on the DOM tree. With this you can apply adjustments to the anchor positions. However it will not keep in sync with any scrolls. This is akin to doing something like: top: calc(anchor(top --a1) + var(--scroll-top-passed-in-by-script)); The "well defined time" needs to be super well defined - it likely needs to be a script API. We can't do it during layout as there are too many random things that will update layout, leaving this inconsistent between browsers.

2) Remove the layout part of fallback positioning (you just get a one-shot), then a different syntax for fallback positioning which doesn't use layout properties - rather describes the position adjustments for example (e.g. can do this based on anchor-scroll , then a separate compositor time adjustments to be performed). No layout however.

Ian

[xiaochengh]

I like option 2 better because that keeps the pipeline sane -- no layout depending on scrolling.

[kojiishi]

With the option 2, we can re-position but we can't resize, can we?

[kojiishi]

If resizing is not an important scenario, the option 2 looks reasonable to me. We'll need to clarify the behavior for e.g.

#myPopup {
  position-fallback: --button-popup;
  right: anchor(--icb right);
  min-width: 6em;
}

@position-fallback --button-popup {
  @try {
    left: calc(anchor(--button right) + 1em);
  }
  @try {
    left: anchor(--button right);
  }
}

Then the 2nd try should ignore the right property?

[xiaochengh]

I just recalled that we already have a similar "pipeline violation": @scroll-timeline, which makes animation progress depend on scroll offsets.

So if involving scroll offsets in style isn't a big issue, then maybe it's not a big issue for layout, either?

@andruud

[andruud]

(Only 18 days later):

Yes, @scroll-timeline (now scroll-timeline) has/had a similar problem.

A ScrollTimeline has an internal state which contains the scroll position of the associated scroller. We generally snapshot this state once during the lifecycle (before style and layout), but also immediately after the ScrollTimeline is created.

However, snapshotting a newly created ScrollTimeline triggered by style resolution isn't effective, since we haven't done layout yet (we don't even have a layout box), and we have no useful scroll position. In other words, the scroll-animation has no effect that frame, and we get a flash of "unstyled" content. (AKA the first frame problem, also previously discussed in the context of css-toggle).

This was solved (in Blink, never specified) by doing the following:

• Newly created ScrollTimelines are put in a list of "unvalidated" timelines. (See blink::DocumentAnimations::unvalidated_timelines_).
• After the style and layout steps of the lifecycle, we re-snapshot the state of "unvalidated" timelines, and compare the new snapshot with the current snapshot. If they differ, we mark affected elements for recalc and run style/layout again (see blink::LocalFrameView::RunScrollTimelineSteps).
• We do this at most once during the lifecycle. That means if the second round manages to create new timelines still, they will remain "unvalidated" until the next frame.

But the current solution has some quirks:

• If you create new timelines as a side-effect of forced style updates (e.g. getComputedStyle), the extra passes do not happen. gCS and the like are basically incorrect until the next frame.
• I think with the introduction of container queries, it's possible for the first non-rendered style/layout pass to have permanent side-effects, like starting transitions, even though the final rendered state should not trigger such effects.

Some of that quirkiness was intentional at the time ... but I don't remember all the reasoning anymore, and now they just look like problems that should be fixed.

[xiaochengh]

Had a discussion today, and I realized that the current version (including scroll offsets in anchor() evaluation) makes it almost impossible to do composited scrolling, as elements can now arbitarily resize when scrolled. So I'm proposing a new version.

Proposal

• Revive the anchor-scroll property
• In each frame update, before style recalc, snapshot the following:
  • For each absolutely-positioned element el whose anchor-scroll resolves to element --anchor, calculate the accumulated scroll offset of all the scroll ancestors of --anchor element up to the containing block of el
  • Define the snapshotted anchor scroll offset of el as the above
• No change to style recalc
• In layout
  • The evaluation of anchor() is the same as the old version, namely, without involving scroll offsets at all
  • In the Applying Position Fallback step, we choose a fallback position by comparing the scroll-shifted margin box with the containing block, where the scroll-shifted margin box is:
  • If the element has a snapshotted anchor scroll offset, its margin box shifted by the snapshotted anchor scroll offset
  • Otherwise, same as it margin box
• In compositing, shift the element by the snapshotted anchor scroll offset, if any

This also allows composited scrolling as long as the fallback position doesn't change. The compositor needs to keep track of the scroll containers up to the containing box, same as in the current implementation.

To react to fallback position changes, we just let the main thread invalidate it, because compositor can't handle it properly.

Rationales

This proposal is what I got after soring out what I think our goals and non-goals are:

Goals:

• Make position fallback aware of scroll offsets (so that we can position a top-layer popup in the viewport properly)
• Allow different fallback positions to size the element differently (so position fallback must involve layout)
• Allow composited scrolling as much as possible

Non-goals:

• Allow elements to resize when scrolled (unless fallback position changes). We didn't allow this in the first version; we allowed this in the next version as a side effect of involving scroll offsets in anchor(), not because there are strong use cases
• Fix existing caveats of the approach scroll timeline takes

[tabatkins]

All right, revived 'anchor-scroll' along the lines that Xiaocheng listed above. Haven't put in precise timing details because I'm finishing this off while in vacation transit and don't want to go investigate that hard, but I left an issue reminding me to fix that. ^_^