[csswg-drafts] [css-view-transitions-1] Exposing ink overflow rect bounds to script (#8597)

khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-view-transitions-1] Exposing ink overflow rect bounds to script ==
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](https://www.w3.org/TR/css-overflow-3/#ink-overflow-rectangle) bounds. The spec text is [here](https://drafts.csswg.org/css-view-transitions-1/#capture-the-image-algorithm).

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 #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](https://www.w3.org/TR/css-overflow-3/#ink-overflow:~:text=Since%20some%20effects%20in%20CSS%20(for%20example%2C%20the%20blurs%20in%20text%2Dshadow%20%5BCSS%2DTEXT%2D3%5D%20and%20box%2Dshadow%20%5BCSS%2DBACKGROUNDS%2D3%5D%2C%20which%20are%20theoretically%20infinite)%20do%20not%20define%20what%20visual%20extent%20they%20cover%2C%20the%20extent%20of%20the%20ink%20overflow%20is%20undefined.). 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.

@chrishtr @fantasai FYI.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8597 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 March 2023 19:02:06 UTC