[css-view-transitions-1] Clarify that observable image size refers to the border-box, and observed natural size is not affected by hw constraints#8819
Conversation
|
But the ink overflow does impact the texture size, so it does matter when the UA is looking to limit the texture size. |
|
@jakearchibald ok clarified it for now, and will revise the whole thing about texture sizes with #8561. |
|
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. |
Ink-overflow is an implementation detail, and up to the UA to apply. object-view-box doesn't directly affect the ink-overflow rect. See [resolution](w3c#8597 (comment)). Closes w3c#8597
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 rectwithborder 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