W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > June 2017

Re: [fxtf-drafts] [css-masking] Support <g> element is clipping paths

From: Dirk Schulze via GitHub <sysbot+gh@w3.org>
Date: Fri, 09 Jun 2017 05:24:00 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-307298342-1496985838-sysbot+gh@w3.org>
The WG had no intention to change the general behavior of `<clipPath>` or `<mask>` in this level of the spec. That said, I would need to look for the reason for the restrictions.

**Example**
https://codepen.io/anon/pen/bREePK (code at the end of the issue.)

Example 1: Rect with `<clipPath>` with circle and grouped smaller circle
Example 2: Rect with `<clipPath>` with circle and use reference to grouped circle
Example 3: Simple rect to confirm that the document is not in error.

**Result**
The test confirms @BigBadaboom observation: 
Safari, Chrome and Edge simply ignore elements that are not part of the content model.
Firefox does not display the entire clipped element and treats the entire `clipPath`  as "in error". The rect disappears.

**Spec**
The content model of `<clipPath>` disallows groups. Safari, Chrome and Edge do follow the spec here and ignore groups. Just as we do in similar situations on other elements. (Say nesting a circle as child of a rectangle.)

In addition to that the spec states:
> A clipPath element can contain path elements, text elements, basic shapes (such as circle) or a use element. If a use element is a child of a clipPath element, it must directly reference path, text or basic shapes elements. Indirect references are an error and the clipPath element must be ignored.

Safari, Chrome and Edge handle use elements with indirect references as "not being part of the content model" and simply ignore those. This is not what the spec says which asks to **ignore** the `<clipPath>` element. Firefox lets the rect disappear in the example above which is not what the spec says either.

The behavior of Safari, Chrome and Edge are consistent with each other. And seem to follow the error handling sentiment of pathData errors in SVG 1.1: https://www.w3.org/TR/SVG/implnote.html#ErrorProcessing I personally like this but this needs to get discussed with the WGs.

**Suggestion**
1. Explicitly state in the content model section of the element definition table that `<use>` element must directly reference path, text or basic shapes elements.
2. Update prose and replace the last sentence with:
> Indirect references are not allowed and `<use>` elements with indirect references must be ignored.
Or remove it entirely.

https://codepen.io/anon/pen/bREePK
```
 <svg>
<clipPath id="clip">
  <circle cx="50" cy="50" r="50"/>
  <g id="g">
    <circle cx="50" cy="50" r="10" id="c"/>
  </g>
</clipPath>
<clipPath id="clip2">
  <circle cx="50" cy="50" r="50" id="c"/>
  <use xlink:href="#g">
</clipPath>
<rect width="100" height="100" clip-path="url(#clip)"/>
<rect width="100" height="100" clip-path="url(#clip2)" transform="translate(120,0)"/>
<!-- confirm that the document is not in error-->
<rect width="100" height="100" transform="translate(240,0)"/>
</svg>
```

-- 
GitHub Notification of comment by dirkschulze
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/17#issuecomment-307298342 using your GitHub account
Received on Friday, 9 June 2017 05:24:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 November 2018 00:45:58 UTC