- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Mar 2023 13:55:59 +0000
- To: public-css-archive@w3.org
> They must at least capture the area currently within view. This was a bit confusing for me since the content of the old/new element is also called a view. :) I think you meant to say: "capture the area currently visible"? > What should the natural width/height of the old/new views be in these cases? Did you mean what should the natural dimensions of the old/new images be in these cases? Didn't follow what "view" was referring to here. > Can this behaviour be otherwise script-visible? Noting from offline discussion, it can be via `object-view-box`. The [spec](https://drafts.csswg.org/css-view-transitions-1/#capture-the-image-algorithm:~:text=The%20natural%20size%20of%20the%20image%20is%20equal%20to%20the%20interestRectangle%20bounds) states that the natural dimensions of the captured image, without clipping, is the element's ink overflow rectangle. And `object-view-box` takes care of using the border-box from that image as the intrinsic size for layout [here](https://drafts.csswg.org/css-view-transitions-1/#capture-the-image-algorithm:~:text=Let%20newViewBox%20be%20an%20object%2Dview%2Dbox%20value%20that%20when%20applied%20to%20new%2C%20will%20cause%20the%20view%20box%20to%20coincide%20with%20capturedElement%E2%80%99s%20new%20element%27s%20border%20box%20in%20the%20image). We could hide this by not exposing `object-view-box`'s computed value to script; and making it `!important` so authors can't change it to prevent them from learning the value by observing effects on layout. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8561#issuecomment-1470055561 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 13:56:01 UTC