Description
The steps for capturing an element's image during View Transitions involve painting the element and all its descendants in their entirety such that the produced image's bounds are equal to the element's ink overflow rectangle bounds. The spec text is here.
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 beinset (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 #8561 that its odd that the computed ink overflow rectangle is being exposed to authors. Since there are cases where it is technically infinite and left undefined, see spec text 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.