Re: [csswg-drafts] [css-masking?] "object bounding box" needs to be better defined for CSS boxes (#5786)

The CSS Working Group just discussed `Object Bounding Box`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Object Bounding Box<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/5786<br>
&lt;fantasai> astearns: conclusion from IRC conversation?<br>
&lt;fantasai> chrishtr: Chrome uses just the border box of the element only<br>
&lt;fantasai> chrishtr: Firefox includes descendants<br>
&lt;fantasai> chrishtr: So Chrome seems to implement what we want, which is to use border box and not bounding box of descendants<br>
&lt;fantasai> smfr: This resolution would affect Gecko; WebKit already matches<br>
&lt;fantasai> dholbert: Unsure what we're doing exactly, but proposal sounds pretty reasonable<br>
&lt;fantasai> astearns: So proposed resolution is to use the border-box for masking in SVG?<br>
&lt;TabAtkins> fantasai: Is this changing the interpretation fo the fill-box keyword? Or just the interpretation of what we do by default, and in what properties?<br>
&lt;fantasai> chrishtr: I think it's changing interpretation of "object bounding box" for clip-path<br>
&lt;chrishtr> clipPathUnits="objectBoundingBox"<br>
&lt;fantasai> astearns: Is there a way to change to use something other than object bounding box?<br>
&lt;fantasai> astearns: Is that only the default behavior or ...?<br>
&lt;fantasai> smfr: fantasai's point is valid, we need to resolve ambiguities between when object bounding box is applied to CSS<br>
&lt;fantasai> smfr: problem with fill-box and border-box being different<br>
&lt;fantasai> chrishtr: can specify various boxes<br>
&lt;fantasai> iank_: Also bug/ambiguity, when fragmented<br>
&lt;fantasai> iank_: need to clarify applying to each fragment independently<br>
&lt;fantasai> astearns: Proposed resolution as stated is not everything we need to fix?<br>
&lt;TabAtkins> fantasai: I think the fill-box keyword is mapped ot the OBB, and also to the content box<br>
&lt;TabAtkins> fantasai: So does that change, when fill-box is specified explicitly?<br>
&lt;TabAtkins> fantasai: If it does get redefined, do we do so only for clip-path or for all places?<br>
&lt;TabAtkins> fantasai: So we need to dig in and see if we were onlya ffecting clip-path:&lt;initial-value>, clip-path:fill-box, or &lt;any-property>:fill-box<br>
&lt;fantasai> heycam: for clip-path object bounding box, no way to switch to another box<br>
&lt;fantasai> heycam: so if we are changing definition of 'fill-box', would need to consider in other contexts<br>
&lt;fantasai> heycam: but at the moment, I don't think there's a way to explicitly select any of the other boxes<br>
&lt;fantasai> astearns: There is in CSS, but maybe not in SVG<br>
&lt;fantasai> heycam: I don't think those would affect how SVG clip path would be positioned<br>
&lt;fantasai> astearns: Do we have a simple resolution and then action to audit?<br>
&lt;fantasai> chrishtr: Let's resolve, and then ask editors to audit and come back to group<br>
&lt;fantasai> astearns: sgtm<br>
&lt;fantasai> astearns: what's the proposed resolution?<br>
&lt;fantasai> chrishtr: If you set 'clip-path' to use object bounding box units in an SVG-based clip-path, it refers to bounding box of the element to which clip is applied<br>
&lt;fantasai> chrishtr: border box<br>
&lt;fantasai> proposed resolution: SVG clip-path bounding box units refer to CSS border-box of element to which applied<br>
&lt;fantasai> RESOLVE: SVG clip-path bounding box units refer to CSS border-box of element to which applied<br>
&lt;fantasai> s/RESOLVE/RESOLVED/<br>
&lt;fantasai> ACTION: Editors to check if any other related amiguities<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-960228838 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 22:16:19 UTC