- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Nov 2021 21:54:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `"object bounding box" needs to be better defined for CSS boxes`. <details><summary>The full IRC log of that discussion</summary> <dholbert> topic: "object bounding box" needs to be better defined for CSS boxes<br> <dholbert> smfr: this is about css & svg<br> <dholbert> smfr: you can apply clip-path to an element<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/5786<br> <dholbert> smfr: you can use clip-path-units: object-bounding-box<br> <dholbert> smfr: in the testcase I was playing with, the element w/ clip-path was an abspos element with a positioned descendant sticking out of its bounds<br> <dholbert> smfr: the question is, what's the bounding box<br> <dholbert> smfr: letter of the svg spec says: traverse the element and whole descendant tree, compute a bounding box that encloses them all<br> <dholbert> smfr: but that seems a little crazy & isn't what 2 of the browsers do<br> <astearns> ack fantasai<br> <dholbert> fantasai: first thought: ink-overflow is theoretically infinite. so if we're doing a geometric operation where author needs to rely on a particular area of the screen, then we can't be dependent on ink-overflow<br> <dholbert> smfr: agree<br> <dholbert> smfr: if one of those descendant elements moves around, do you want to adjust clip path on every frame of animation?<br> <dholbert> TabAtkins: we have a definition of how this applies to CSS boxes elsewhere. Is that sufficient?<br> <dholbert> smfr: I would be fine if we said object bounding box matched one of those boxes, e.g. border-box<br> <dholbert> smfr: [...] that's what two of the browsers implement<br> <dholbert> smfr: I think chrome includes all the descendants<br> <dholbert> chrishtr: ok<br> <TabAtkins> https://drafts.fxtf.org/fill-stroke/#fill-origin<br> <dholbert> TabAtkins: looking for where this was defined<br> <dholbert> TabAtkins: I see the css-to-svg keyword mapping in draft fill-stroke spec<br> <dholbert> chrishtr: this demo from the issue, is that the one where Chrome behaves differently?<br> <dholbert> smfr: look at the codepen in second comment there<br> <fantasai> TabAtkins, https://www.w3.org/TR/css-box-3/#keywords ?<br> <TabAtkins> ah yes, that's it<br> <dholbert> astearns: chrishtr, do you need a little more time to look at this?<br> <dholbert> chrishtr: yeah, need to research the code. smfr's proposal sounded good but it surprises me that Chrome doesn't implement it<br> <astearns> ack fantasai<br> <dholbert> fantasai: the keyword mapping is in the box model spec<br> <fantasai> https://www.w3.org/TR/css-box-3/#keywords<br> <dholbert> fantasai: [describes box mapping]<br> <dholbert> smfr: problem there, object-bounding-box is mapped to fill-box, but that doesn't include borders, which doesn't match what browsers do<br> <dholbert> fantasai: if that's what browsers are doing then we should update the mapping<br> <dholbert> heycam: that makes it inconsistent with what SVG is doing, where object-bounding-box is defined to do the same thing as getBBox, which is the geometry of the shape excluding stroke<br> <dholbert> chrishtr: (describes observations of example)<br> <dholbert> smfr: if you compare Chrome to other engines, it looks different; I'm not entirely sure what rectangle Chrome is using<br> <dholbert> chrishtr: it would be great to take this offline and circle back next week, so I can find out what Chrome is doing. I'll comment on the issue soon<br> <dholbert> smfr: do we need to separately resolve the "object-bounding-box is fill-box" ambiguity<br> <dholbert> smfr: I think it needs more research<br> <dholbert> smfr: we need to find places that reference object-bounding-box in css specs and see if those should map to fill-box or border-box<br> <dholbert> astearns: separate issue would be good<br> <dholbert> smfr: I'll file<br> <dholbert> astearns: resolution that we'd like to take up for this one is that bounding-box for SVG masking should be the border-box?<br> <dholbert> chrishtr: that's what we'd like to aim for, after research<br> <dholbert> astearns: let's see if we can resolve on that next week or week after<br> <dholbert> astearns: break!<br> <dholbert> astearns: resume at 5 after the hour<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5786#issuecomment-960169605 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 November 2021 21:54:40 UTC