[css-anchor-position-1] Define scroll interaction better.

[emilio]

In https://github.com/w3c/csswg-drafts/issues/9598 it was resolved that anchor() computed to a pixel value, which ended up in edits in https://drafts.csswg.org/css-anchor-position-1/#scroll and elsewhere such that some scroll adjustment is snapshotted every frame (at an undefined time).

That timing should be defined. The spec says:

Define the precise timing of the snapshot: updated each frame, before style recalc.

But before style recalc seems wrong? The scroll position there depends on whether somebody had updated layout before, or otherwise it flickers... Or something like that?

• What should be the timing of that operation?
• Also, presumably we should also change the used value definition of the inset properties to add that offset, so that div.style.left = getComputedStyle(div).left round-trips? But it is super-weird that the position getComputedStyle() returns depends on whether you're before or after style recalc... wat?

I still think it'd be easier if we just didn't do the interleaving dance but... ;)

cc @dshin-moz, @andruud, @tabatkins, @fantasai

[emilio]

It's also unclear what:

At least one anchor() function on query el’s used inset properties in the axis refers...

Really means, since anchor() is supposed to go away at computed-value time? So if interpreted naively, that condition would never match...

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] Define scroll interaction better..

The full IRC log of that discussion

<kbabbitt> emilio: the timing of the operation was already discussed
<kbabbitt> ..seems we should put it somewhere in HTML, not talk about it here
<kbabbitt> ...other problem is that the whole anchor element doesn't resolve
<kbabbitt> ...depends on whether there's an anchor function which means that gCS doesn't round trip anymore
<kbabbitt> ...feels quite unfortunate
<kbabbitt> ...setting the inset to a fixed value would remove the anchor ness and that would just break positioning
<kbabbitt> ... that seems kind of bad
<kbabbitt> TabAtkins: that is the case, I agree it's bad, we have a case or two of that already with the shadow related things we were talking about before
<kbabbitt> ...agree they're not great
<kbabbitt> ...don't know how to get around it unless we add a syntax to let it reflect the fact that there was an anchor
<kbabbitt> ...indicate that it was anchored even though you're using an explicit value
<kbabbitt> emilio: could also include scroll offset in resolved value but that might be weird too
<kbabbitt> TabAtkins: I'd have to think about that, might work
<kbabbitt> emilio: we can think about it and figure out a solution
<kbabbitt> TabAtkins: would not mind coming up with something that addresses this problem, let's see what we can do in the issue