[css-view-transitions-1] A lot of the definitions should use ink-overflow rather than border box sizes

[emilio]

https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm and so on have sections like:

Set capture’s old transform to a that would map element’s border box from the snapshot containing block origin to its current visual position.

And so on. But the captures capture shadows and so on, so that seems wrong, it should account for the potentially negative offsets that outlines and shadows create. Tests like https://wpt.live/css/css-view-transitions/new-content-ancestor-clipped.html where an element with a shadow gets captured depend on it to get the correct rendering.

[emilio]

cc @noamr @vmpstr

[noamr]

This is described in detail in https://drafts.csswg.org/css-view-transitions-1/#capture-rendering-characteristics-algorithm.
The ink overflow is captured in the snapshot, however it doesn't affect sizing and geometry. The transform is what would map the originating border box to its visual position, and the mapping between that and the actual snapshot coordinates which include the overflowing descendants and the ink overflow is internal.

[emilio]

@noamr so I guess the idea is that the ::-old(..) and ::-new(..) pseudos also render overflow... Is it well defined how properties like object-fit / object-position behave in such a case?

[noamr]

@noamr so I guess the idea is that the ::-old(..) and ::-new(..) pseudos also render overflow... Is it well defined how properties like object-fit / object-position behave in such a case?

Yea, they affect the rect that ends up being mapped to the border box, and the overflow is derived from that. IIRC there are lots of tests for this, @vmpstr should recall all the detail.