[css-view-transitions-1] Clarify that observable image size refers to the border-box, and observed natural size is not affected by hw constraints

[noamr]

Ink-overflow is an implementation detail, and up to the UA to apply. object-view-box doesn't directly affect the ink-overflow rect. Replaced mentioned of ink-overflow rect with border box, and added note about how ink-overflow plays into this.

Also, texture size constraints should not affect the observed natural size of the captured image. Instead, implementations
should capture at least the visible part of the element (downscaled if they must).

See resolution 1 and resolution 2.

Closes #8561
Closes #8597

[jakearchibald]

But the ink overflow does impact the texture size, so it does matter when the UA is looking to limit the texture size.

[noamr]

But the ink overflow does impact the texture size, so it does matter when the UA is looking to limit the texture size.

It's true, I want to see what we come up with for #8561. I might wait to integrate a fix for #8561 first and then revise this.

[noamr]

@jakearchibald ok clarified it for now, and will revise the whole thing about texture sizes with #8561.

[noamr]

Reading both #8561 and #8597, I see both ink-overflow and max-texture-size as implementation-defined things that shouldn't be web observable. So we'll have some notes that ink-overflow is applied to the canvas and some big elements might not be rendered as expected due to hardware constraints, but otherwise all of this is an implementation thing.

This is not different from regular CSS transforms and accelerated compositing, where sometimes you have tiling artifacts or run out of texture memory. We can also treat those as bugs, and incrementally try our best to show something legible (e.g. a blurry scaled-down version of the texture, or use tiling) and vendors can differentiate on this if they want.