- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Mar 2023 16:48:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Exposing ink overflow rect bounds to script`, and agreed to the following: * `RESOLVED: Snapshot raster is theoretically infinite. Snapshot has a "natural view box" of the snapshot element's border box (giving the natural size). Object-view-box can change this view box.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> khush: We touched on defining the bounds of the element you capture at the f2f<br> <TabAtkins> khush: One aspect is the natural size of the image is the ink overflow rectangle.<br> <TabAtkins> khush: This can be larger than the border box, so you use object-view-box to size it<br> <TabAtkins> khush: This means the ink overflow rectangle is exposed to authors<br> <TabAtkins> khush: But this is currently undefined, what to do?<br> <TabAtkins> khush: Two options. One questions whether we expose this at all.<br> <TabAtkins> khush: We can censor it in getComputedStyle() and make it !important in UA styles here.<br> <TabAtkins> khush: This can be bad if authors want to customize the size<br> <TabAtkins> khush: I haven't seen good use-cases for customizing it tho.<br> <TabAtkins> khush: Suggestion from fantasai is to use the scrollable overflow rect instead<br> <TabAtkins> khush: So the natural size authors see is scrollable overflow, but the browser can actually draw a larger ink overflow<br> <TabAtkins> khush: I'm fine with either option from impl.<br> <TabAtkins> khush: If scrollable overflow makes more sense as an author-exposed concept, that's fine<br> <TabAtkins> khush: But if ink overflow would be useful we shoudln't shy away from using it<br> <TabAtkins> q+<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: One, I don't think authors want to control layout of stuff using ink overflow rect. Kinda unpredictable.<br> <TabAtkins> fantasai: And not what they're actually measuring. It's excess stuff, you don't really notice it's there. Serifs on font, blur on box-shadow, etc<br> <TabAtkins> fantasai: So I don't think this is something authors will want to use.<br> <TabAtkins> ack TabAtkins<br> <florian> q+<br> <TabAtkins> fantasai: I think we either want the scrollable overflow or the box fragments, and allow image to overflow the rect in some way<br> <flackr> q+<br> <TabAtkins> fantasai: Even if we expose ink overflow in IntersectionObserve for security reasons, I don't think it's something people want to measure against<br> <TabAtkins> +1 to fantasai's points<br> <Rossen_> ack florian<br> <TabAtkins> florian: Might be confsued, but thought in the gneeral case the ink overflow was not only underspecified, it wasn't necessarily finite.<br> <TabAtkins> florian: With blurs it can technically be infinite.<br> <TabAtkins> fantasai: You're right, tho we'd have a proposal to define the bounds that it clips. Tehcnically what impls do today anyway.<br> <Rossen_> ack flackr<br> <fantasai> s/we'd have/there was<br> <TabAtkins> flackr: I think hiding the ink overflow rect is one of my proposals<br> <TabAtkins> flackr: But my proposal was more that if authors set an ink overflow, we'd combine it with intrinsic ink overflow from the image, and they'd always work wrt the border box of the item.<br> <TabAtkins> fantasai: Not sure I'm following, more concrete example?<br> <TabAtkins> flackr: Say you ahve 100x100 box, there's 50px of shadow around it<br> <TabAtkins> flackr: The thing presented to the dev is no ink overflow.<br> <TabAtkins> flackr: But when we calculate the ink overflow, we'd add the 50px to whatever we got from the author's ink overflow rect<br> <TabAtkins> Rossen_: what do you mean by "presented to the dev"<br> <TabAtkins> flackr: The value of object-overflow won't expose that shadow size.<br> <Rossen_> q?<br> <TabAtkins> khush: I'm also having toruble understanding this - is this similar to what fantasai is suggesting, where you see the scorllable overflow as the exposed size?<br> <TabAtkins> flackr: Basically the same, probably just an impl detail about how it works.<br> <Rossen_> ack fantasai<br> <chrishtr> q+<br> <khush> q+<br> <TabAtkins> fantasai: I wasn't sure if the box we shoudl use is scrollable overflow or the border box, just pretty sure it shouldn't be the ink overflow rect<br> <TabAtkins> fantasai: If we have the property controlling the clipping, we could have an "auto" value that computes to itself and works from the ink overflow<br> <Rossen_> ack chrishtr<br> <TabAtkins> chrishtr: I think what elika and rob are saying makes sense<br> <TabAtkins> chrishtr: But khushal, is there any case you've seen where authors need to know the ink overflow to position correctly?<br> <TabAtkins> khush: No, it is handled automatically.<br> <TabAtkins> khush: But if authors can set the object-view-box, they get information about the natural size.<br> <TabAtkins> khush: Like if you say "none", then measure the box, you'll get the size out.<br> <TabAtkins> khush: So I'm fine with saying the natural size is the border box or scrollable overflow, and what authors see is based on that size.<br> <Rossen_> ack khush<br> <TabAtkins> khush: From what i've heard so far, I think I like the proposal of scrollable overflow. If we decide not to expose it and there's a use-case later, it'll be hard to change.<br> <TabAtkins> khush: So inclined to exposing it, using the scrollable overflow.<br> <TabAtkins> +1<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: So we have a replaced element. It contains an image which is snapshot.<br> <flackr> q+<br> <TabAtkins> fantasai: The size of that replaced element is the size of the snapshot element's border box.<br> <TabAtkins> fantasai: But like an SVG image, that extends past its viewbox.<br> <TabAtkins> fantasai: and we're setting a property that cause th estuff outside the stuff to actually paint<br> <fantasai> s/outside the stuff/outside its declared size/<br> <fantasai> s/declared/nominal<br> <TabAtkins> khush: Yes, using object-view-box to make the sizing align, and then anything outside paints as ink overflow, is clipped based on 'overflow'.<br> <TabAtkins> fantasai: So on an SVG currently, say I draw a bunch of circles then set viewbox to 50x50<br> <TabAtkins> fantasai: I'll get a 50x50 image, stuff can get drawn outside of that. If I put this in an <img> they'll get clipped by default.<br> <TabAtkins> fantasai: But they're still there - if I use object-position we're moving that 50x50 square.<br> <TabAtkins> fantasai: object-view-box refers to that viewbox declaration - I could change it and it would change what portion of the SVG is "the displayed image"<br> <TabAtkins> fantasai: So we're creating a snapshot whose viewbox is the border box of the snapshot element<br> <TabAtkins> fantasai: I think we can conceptually say the top left corner of the border box is the 0 coord for the image, for th epurpose of object-view-box?<br> <TabAtkins> fantasai: Then I think we ahve an analogous situation<br> <TabAtkins> [i don't quite understand this]<br> <flackr> +1 that is how i was thinking object-view-box modifications should work<br> <TabAtkins> fantasai: I think this gets us a mental model and an API consistent with SVG<br> <TabAtkins> khush: So you're right about the viewbox descriptions.<br> <TabAtkins> khush: But the origin is based on the natural size<br> <TabAtkins> khush: object-view-box says to inset from those natural bounds<br> <TabAtkins> khush: We have an option to say what amount of overflow is exposed to authors<br> <Rossen_> ack flackr<br> <TabAtkins> flackr: I agree with elika's thinking about how this should work, that matches what i'm imagining<br> <TabAtkins> flackr: the ink overflow isn't dev-exposed, just part of the object we've captured<br> <TabAtkins> flackr: so 0,0 is at the border box corner<br> <TabAtkins> flackr: Do we capture scrollable overflow even if the source element clipped it?<br> <TabAtkins> flackr: Is it only for overflow:visible we capture?<br> <TabAtkins> fantasai: No, we capture what you actually see.<br> <khush> q+<br> <TabAtkins> fantasai: I want to change what I'm proposing from what was in th eissue<br> <TabAtkins> q=<br> <TabAtkins> q+<br> <TabAtkins> fantasai: The natural image should be the full size of stuff we see.<br> <TabAtkins> fantasai: But the origin of the image should be the border box corner.<br> <TabAtkins> fantasai: Similar to SVG with its viewport<br> <TabAtkins> fantasai: In SVG you can draw into negative coords<br> <TabAtkins> fantasai: So I'm proposing the origin of the image is the border box corner. Anything that overflows that is captured for the snapshot still gets captured.<br> <flackr> +1<br> <TabAtkins> fantasai: So we create a raster image whose origin is not the top-left corner of the image<br> <TabAtkins> fantasai: So that lets us say the natural size is the border box. If they want to change that, they can do that (so long as it's captured)<br> <TabAtkins> fantasai: and if they extend past what's captured they get transparent pixels<br> <TabAtkins> fantasai: so we don't need to define the boundary of the raster, just that it captures at least the visible scrollable overflow<br> <TabAtkins> fantasai: everything outside is on an infinite transparent canvas<br> <TabAtkins> fantasai: I think that gets us a model where author can do whatever they want to do<br> <Rossen_> ack fantasai<br> <TabAtkins> khush: +1 elika's suggestion<br> <TabAtkins> khush: It's funny we added object-viewbox because what is proposed now is what we thought about implementing internally, so we thought a cSS property is a better way to do it<br> <TabAtkins> khush: So it sounds now we conceptually do what object-view-box is doing but expose it to the author<br> <TabAtkins> khush: So +1<br> <fantasai> TabAtkins: basically what khush said<br> <Rossen_> ack TabAtkins<br> <Rossen_> ack khush<br> <fantasai> TabAtkins: original purpose of ovb was to have natural size image and cutout the border box part<br> <fantasai> TabAtkins: but if we're dealing withi ink ...<br> <fantasai> TabAtkins: So default case doesn't need 'object-view-box' at all, its natural viewbox matches border-box, sounds find to me<br> <fantasai> TabAtkins: requires minor spec edits, but good change overal<br> <fantasai> TabAtkins: and if you want the image to look larger, then you would use negative coords<br> <fantasai> TabAtkins: rather than smaller positive coords<br> <fantasai> TabAtkins: so sounds fine, good overall<br> <TabAtkins> Rossen_: Can you summarize resolution?<br> <TabAtkins> fantasai: proposed resolution is snapshot rasterization is theoretically infinite. Origin corresponds to top-left of border box of snapshotted element, natural size is width+height of border box. Author can use object-view-box to shift this "natural view box"<br> <flackr> +1<br> <ydaniv> +1<br> <TabAtkins> Rossen_: comments or objections?<br> <TabAtkins> RESOLVED: Snapshot raster is theoretically infinite. Snapshot has a "natural view box" of the snapshot element's border box (giving the natural size). Object-view-box can change this view box.<br> <chrishtr> https://github.com/w3c/csswg-drafts/issues/8637<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8597#issuecomment-1488952275 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 March 2023 16:48:47 UTC