-
Notifications
You must be signed in to change notification settings - Fork 50
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-2] Support <g> element in clipping paths #17
Comments
In addition to
|
The WG had no intention to change the general behavior of Example Example 1: Rect with Result Spec In addition to that the spec states:
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 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
Or remove it entirely. https://codepen.io/anon/pen/bREePK
|
The Working Group just discussed 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 |
The SVG Working Group just discussed
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. |
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. |
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:
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.The text was updated successfully, but these errors were encountered: