[fxtf-drafts] [css-masking-1] Clarify behaviour of clipPathUnits="objectBoundingBox" when placed on a child clipPath

BigBadaboom has just created a new issue for https://github.com/w3c/fxtf-drafts:

== [css-masking-1] Clarify behaviour of clipPathUnits="objectBoundingBox" when placed on a child clipPath ==
Section 6.1 states wrt clipPathUnits:

> The coordinate system has its origin at the top left corner of the bounding box of the element to which the clipping path applies to...

But what "element" is the correct one when your clipPath itself has a clipPath?

```
<svg width="3in" height="3in" viewBox="0 0 300 300" version="1.1"
     xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

  <defs>
    <clipPath id="Clip1" clip-path="url(#Clip2)">
      <rect width="200" height="200"/>
    </clipPath>
    <clipPath id="Clip2" clipPathUnits="objectBoundingBox">
      <circle cx="0.5" cy="0.5" r="0.5"/>
    </clipPath>
  </defs>

  <rect fill="none" stroke="blue"
        x="1" y="1" width="298" height="298"/>

  <rect fill="red" x="0" y="0" width="300" height="300" clip-path="url(#Clip1)"
        transform="translate(50,50)"/>

</svg>
```

https://jsfiddle.net/xqs5rmda/

Here, the child `<clipPath>` with `id="Clip2"` has `objectBoundingBox` specified. But are we referring to the bounds of the parent clipPath, or the original `<rect>` element?  I would have assumed the former, but browsers are not consistent:

- Chrome: rect
- Firefox: rect
- IE!: clipPath
- Batik: result bugged, but is using clipPath

Behaviour of Chrome and Firefox seems like a bug to me.  But either way, the language should probably be expanded to make it clear what the correct behaviour should be.



Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/247 using your GitHub account

Received on Sunday, 14 January 2018 17:32:58 UTC