The ::view-transition-group pseudo-element which displays the image has bounds equal to the captured element's border-box. Since the image's natural size is equal to the element's ink overflow area but it needs to be drawn in an element which is smaller than that, we use object-view-box to ensure the correct subset paints into the element.

So for example if you have a 100x100 box with a shadow that paints 10px outside this box:

• The ink overflow rect is [-10, -10] 120X120.
• The natural size of the produced image will be 120x120.
• The ::view-transition-group for this will be sized to 100x100.
• The object-view-box set on this group will be inset (10px, 10px, 10px, 10px).

Given that script can read the object-view-box on the group, it allow authors to query the value for ink overflow rectangle computed by the UA.

There was an additional risk of fingerprinting if object-view-box was affected by where the UA decided to clip the element's painting. But with the resolution in #8561 that is not an issue. Clipping the element's painting is an internal detail, the natural size of the image and its object-view-box value is always as described above.

It came up during the discussion in here. So now authors will see a value for it based on the UA's implementation.

Questions:

• Is the above ok as-is? The value is exposed to script.
• If the value shouldn't be exposed to script, how do we set that up. We can't just elide it from getComputedStyle. An author could do object-view-box: unset and learn the value based on how it affects the size of the replaced element displaying this image.

css-view-transitions-1View Transitions; Bugs onlyView Transitions; Bugs only