New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
BigBadaboom opened this Issue Aug 3, 2016 · 4 comments

Comments

Projects
None yet
5 participants
@BigBadaboom

BigBadaboom commented Aug 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

AmeliaBR May 19, 2017

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>

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

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Jun 9, 2017

Contributor

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>
Contributor

dirkschulze commented Jun 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Feb 26, 2018

Member

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/w3c/fxtf-drafts/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
Member

css-meeting-bot commented Feb 26, 2018

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/w3c/fxtf-drafts/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

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze May 22, 2018

Contributor

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.

Contributor

dirkschulze commented May 22, 2018

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.

@BigBadaboom BigBadaboom changed the title from [css-masking] Support <g> element is clipping paths to [css-masking] Support <g> element in clipping paths May 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment