[css-transitions] Allow transitions to work at used value time

[SebastianZ]

The big issue of #626 that limits the given solutions to certain use cases seems to be that transitions are specified to happen at computed value time.

So, what if we allow authors to change at what step of the value processing transitions are working. I. e. allow to specify that transitions should be based on used values instead.
Not only would this solve the use case of interpolating between dimensional values and keywords like auto but also transitions between two keywords (even if it's the same like between auto and auto at two different times).

Obviously, this has some big side effects and issues that need to be solved, as mentioned by @tabatkins and others in the other issue.
Though obviously it is possible under certain circumstances, as Tab also noted for Anchor Positioning and Container Queries.

This issue is meant to explore the restrictions required to provide authors a general way to opt into transitions between used values instead of computed values.

Sebastian

[tabatkins]

There are many issues with doing this in general, which probably sink the idea.

For example, animating between two sizing keywords. This isn't possible with calc-size() because the layout algorithms sometimes condition their behavior on the exact sizing keyword used, so a "mixture" of two keywords wouldn't have a well-defined definition. The same applies to transitions in general - the two endpoints act like the specified keywords, so the midpoints need to somehow act like both of them too. And if you try to just calculate the px value that the keywords resolve to at layout-time and use that to transition, you get a third behavior for the midpoints that might be distinct from either of the endpoints! (For example, margin collapsing works differently if an element has a definite vs indefinite height.)

Outside of specific cases like that, all the layout engines are predicated on a certain degree of information flowing forward, not backward. Anchor Pos and CQ both do some funky stuff, and only in limited contexts, where we can define a strict ordering of value computation so that the layout-time information they depend on is guaranteed to already be available at the point where we're doing computed values on the element. (Sometimes this is explicitly a "we don't calculate the computed values on element X until later", sometimes it's "we'll just give element X some nonsense values, then recompute everything in a second pass"; the two approaches are identical in final behavior.) This is also the case for the specs themselves - there are several ways in which piping layout-time information into an arbitrary computed value would result in cyclic or undefined behavior.