[css-masking-2] Support <g> element in clipping paths

[BigBadaboom]

See the following thread in www-svg: https://lists.w3.org/Archives/Public/www-svg/2016Aug/0000.html

I asked there why groups were not allowed in <clipPath> elements.

Currently browser behaviour is mixed (see test https://jsfiddle.net/g9p82y7c/):

Chrome: clip path succeeds but any groups are ignored
Edge: clip path succeeds but any groups are ignored
Safari (7.1): clip path succeeds but any groups are ignored
IE 11: clip path works including groups
Firefox: clip path fails

Firefox originally allowed groups, but that was "fixed" to bring it in line with the spec.

There are useful use cases for allowing groups:

1. Allow existing content to easily be converted to a clipPath without having to be rearranged
2. Easily convert a userSpaceOnUse clippath to an objectBoundingBox one.

The original reason for the restriction is unclear, but if there are no strong technical reasons to prevent it, it would be desirable to ease this restriction.

I offer no opinion on whether <svg> etc should be also be allowed.

[AmeliaBR]

In addition to <g>, the following elements are disallowed inside of <clipPath> without a clear justification:

• <use> elements that reference a <g> or another <use> (instead of a shape or text element directly)
• <svg> elements and <use> elements that reference <symbol>

[dirkschulze]

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>

[css-meeting-bot]

The Working Group just discussed Support <g> element is clipping paths.

The full IRC log of that discussion

<AmeliaBR> Topic: Support <g> element is clipping paths
<AmeliaBR> Github: https://github.com//issues/17
<AmeliaBR> Amelia: I definitely support this as something I'd like to see in the future, but can be deferred for now.
<AmeliaBR> ... I don't think there is any real implementation reason for not allowing it, I think it was just a DTD convenience. Didn't want to allow <g>, because then it would automatically allow anything that is allowed in <g>.
<AmeliaBR> Dirk: There would still always be implementation complexities. I'm in favour of deferring to a future spec, if only because it's not implemented anywhere.
<AmeliaBR> Bogdan: Is that one of the suggestions you mention in the discussion, you've got some suggested edits there.
<AmeliaBR> Amelia: Looks like that's a slightly different issue, about indirect <use> references. Edge supports them, other browsers don't.
<AmeliaBR> Dirk: At this point, I don't expect to get any implementation changes in time for this level of the spec.
<AmeliaBR> ... I think that's what the spec says.
<AmeliaBR> Amelia: I think the other issue is error handling. We don't know whether we really have cross-browser consistency in how they handle error states.
<AmeliaBR> Dirk: That should maybe be another issue.
<AmeliaBR> Bogdan: Even there, according to the notes in the issue, it looks like we have almost consistency, across 3 browsers.
<AmeliaBR> Amelia: Sounds like a good resolution, for all the details, is to run tests & then try to make the spec match browser behavior.
<AmeliaBR> Dirk: Sounds good to me.
<BogdanBrinza> resolution: develop the tests to find the interoperable core of the error handling and match the specification to that
<AmeliaBR> Bogdan: If that's the last issue, let's wrap up early. Thank you very much for a productive call.
<AmeliaBR> trackbot, end telcon

[dirkschulze]

The remaining bits for this bug depend on Issue #130 about invalid resources and error handling. What ever gets decided for #130 applies to this issue.

[css-meeting-bot]

The SVG Working Group just discussed Support <g> element in clipping paths, and agreed to the following:

• RESOLVED: Expand the clipPath content model in CSS Masking Level 2; no change for Level 1. Exact details to be determined.

The full IRC log of that discussion

<AmeliaBR> Topic: Support <g> element in clipping paths
<AmeliaBR> github: https://github.com//issues/17
<AmeliaBR> Dirk: As background, clipPath currently only allows shapes, text, or use elements that directly reference shape or text.
<AmeliaBR> ... Proposal is to allow the <g> element and possibly other elements.
<AmeliaBR> ... Given that CSS Masking is in CR & there are no implementations, I want to resolve that we're not changing this for Level 1. But we could do it in Level 2.
<AmeliaBR> Chris: That makes sense.
<AmeliaBR> Dirk: Any objections to moving to Level 2?
<AmeliaBR> Amelia: No, it's new functionality, should go in the next spec.
<AmeliaBR> Dirk: OK, I have no problem with the idea for Level 2. But we need to figure out the details.
<AmeliaBR> Chris: I think those details may be why it wasn't allowed in the first place.
<AmeliaBR> Dirk: Any other comments?
<AmeliaBR> Amelia: Worth mentioning that is much-requested feature from authors. Current restrictions can make re-using content difficult.
<AmeliaBR> RESOLVED: Expand the clipPath content model in CSS Masking Level 2; no change for Level 1. Exact details to be determined.

[dirkschulze]

As per WG resolution, moving the issue to CSS Masking 2 and plan to add the proposal in an initial editors draft for better visibility.