W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > March 2019

Re: [fxtf-drafts] [css-masking-1] Clarify behaviour of clipPathUnits="objectBoundingBox" when placed on a child clipPath (#247)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Mon, 04 Mar 2019 21:37:25 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-469431499-1551735444-sysbot+gh@w3.org>
The SVG Working Group just discussed `what to do on clip-path on a clip-path with unit calculation.`, and agreed to the following:

* `RESOLUTION: When clipping a clipPath you use the bounding box of the originally clipped shape or its user space for the 2nd clip as well.`

<details><summary>The full IRC log of that discussion</summary>
&lt;krit> topic: what to do on clip-path on a clip-path with unit calculation.<br>
&lt;AmeliaBR> github: https://github.com/w3c/fxtf-drafts/issues/247<br>
&lt;krit> AmeliaBR: what happens on clip-path on &lt;clipPath> since it does not have a bounding box. So what happens for clipPathUnits="objectBoundingBox"<br>
&lt;krit> AmeliaBR: The spec does say that clip paths would be intersecting. That should have implications on the space they operate.<br>
&lt;krit> krit: don't see the implication.<br>
&lt;krit> AmeliaBR: Using a mask as example: a mask on a mask would use the mask elements bounding box instead of the original shape that gets masked. clipPath does not even have a bounding box.<br>
&lt;krit> myles: seems like it should be implemented widely already. Can we just do what UAs do?<br>
&lt;krit> AmeliaBR: it is implemented but with different results.<br>
&lt;krit> AmeliaBR: Edge does it differently than Chrome and FF<br>
&lt;krit> myles: but Edge would not matter in the long term<br>
&lt;krit> AmeliaBR: yes, weakens the argument.<br>
&lt;myles> s/Edge would not matter in the long time/Edge will shortly match Chrome's behavior<br>
&lt;myles> s/Edge would not matter in the long term/Edge will shortly match Chrome's behavior/<br>
&lt;krit> krit: could the results that we see depend on other issues where referenced elements are on different viewports? IIRC there were differences across UAs.<br>
&lt;krit> AmeliaBR: might depend on implementations<br>
&lt;krit> AmeliaBR: FF does it differently when the 2nd clip path is on a child of the original clip path ...<br>
&lt;AmeliaBR> The firefox but is that it treats &lt;cP>&lt;rect c-p="...">&lt;/cP> the same as &lt;cP c-p="...">&lt;rect />&lt;/cP><br>
&lt;krit> krit: want more testing or should we do a tentative resolution.<br>
&lt;krit> AmeliaBR: When clipping a clipPath you use the bounding box of the originally clipped shape in its user space for the 2nd clip as well.<br>
&lt;AmeliaBR> s/in its user/or its user/<br>
&lt;krit> krit: I'd just not confident counting WebKit and Blink as 2 implementation just yet. WebKit's implementation was before fork of Blink. We need to check if they are independent now.<br>
&lt;krit> AmeliaBR: and need more testing.<br>
&lt;krit> RESOLUTION: When clipping a clipPath you use the bounding box of the originally clipped shape or its user space for the 2nd clip as well.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/247#issuecomment-469431499 using your GitHub account
Received on Monday, 4 March 2019 21:37:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 4 March 2019 21:37:27 UTC