Re: [csswg-drafts] [css-anchor-position] Better handling of scroll position for fixpos elements on first layout (#10999)

Okay, first draft of the new spec text committed. It was a larger change than I thought it would be at first, but I think this captures the behavior we wanted (and is slightly better, in fact), while still respecting the scrolling-response constraints that Anchor Pos has to respect.

In short:

* When an anchor-pos element is first laid out, or switches to new fallback styles, it remembers the relative scroll offset of *each* of its anchor references. From then on, it pretends that all scrollers are at their initial scroll position (same as the old spec) and adds the remembered scroll offset for that reference (new). This gets reflected into anchor().
* The scroll adjustment for the default anchor element (now called the "default scroll shift") is redefined as the difference between its remembered scroll offset and its current combined scroll offset. Just a technical fix; it's otherwise treated the same, as a post-layout translation.
* Like the old spec, the default scroll shift *is* used to determine if the anchorpos element is overflowing its IMCB; as before, this can be done on the compositor by pre-calculating the ranges of scroll offsets that won't cause overflow, since neither the element's size nor its CB's size can change as a result of the shift.
* When calculating fallback, we explicitly skip whatever styles we're currently using (so nothing gets recalculated for them), and for all the other styles we're trying out, we record fresh remembered scroll offsets for all the references, which get used and persisted *if* that fallback gets chosen. Calculating fallbacks always needed to be done on the main thread since it can (and usually does) cause layout, so recapturing scroll offsets is acceptable here.
* Now that anchor references capture their current scroll offset, we don't need the text in the fallback steps about adding the default scroll shift just to the non-auto edges of the IMCB when calculating if the fallback will overflow. All the edges are just automatically correct at the moment of calculation.

I've also added some new issues to the spec; since we're now respecting the scroll offsets of anchors, even if snapshotted, can we go ahead and respect *all* the things that change their position, in particular transforms? The lack of ability to respond to transforms has been a complaint from multiple authors, but we really couldn't do anything about it before, but I think it should be amenable now? (Presumably we'd use the axis-aligned bounding box of the transformed margin box, relative to the CB's axises.)

This is in two parts, too: can we include transforms in the remembered scroll offset (the snapshots), and can we include changes to the default anchor's transforms in the default scroll shift (the live one)? I think the first is easier, since we'd be able to tree-walk to gather the combined transform effects and layer them with scrolling; I'm unsure if it's possible to do that as easily in the live case. If we can't do it *generally*, maybe we can do it just for transforms on the anchor itself, or on its nearest scroll container?

/cc @andruud @lilles 

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2430366312 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 22 October 2024 21:42:27 UTC