-
Notifications
You must be signed in to change notification settings - Fork 49
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-1] Let SVGClipPathElement and SVGMaskElement inherit from SVGGraphicsElement #28
Comments
SVGGraphicsElement is used for elements that are directly part of the rendering tree. None of the other SVG graphics effects elements (filters, patterns, gradients) inherit from SVGGraphicsElement. Was there a particular method defined for SVGGraphicsElement that you wanted to have available on |
Yes, I thought Sebastian |
I'm not sure how the highlighter would work, since you never know what coordinate system the elements are in; it depends on the element using the effect.
|
There could actually be two highlighters, one for the mask or clip path itself without being applied and one for when they are used (which may then highlight all usages).
Agree. So I see three solutions:
I'd be fine with all three of them, but I think number 3 would be the cleanest. Sebastian |
@SebastianZ This would not fit into Firefox's internal rendering model. I would suggest to just create a union of the content elements of a clipping path but realised that this might not work either in Firefox. Point 2 would most definitely not work as @AmeliaBR said. |
@bzbarsky Do you have some input from Geckos point of view? I know that in the past it was not possible for Firefox to get bounds of content that does not get directly rendered. Like content from @SebastianZ At this point I am hesitating to add this to CSS Masking 1 and would rather defer the request to CSS Masking 2. I'd like CSS Masking 1 to consolidate with current implementations. |
Fair enough. Sebastian |
I believe the issue is that getBBox in Gecko uses the rendering tree. That's partly because getBBox relies on styles and until recently those were very much tied to the rendering tree in Gecko. And even in the new style system, we optimize out style computation in various cases (like display:none)... All of which is to say that I have no idea when Gecko will have a getBBox that does not rely on the rendering tree. |
The Working Group just discussed The full IRC log of that discussion<AmeliaBR> Topic: Let SVGClipPathElement and SVGMaskElement inherit from SVGGraphicsElement<krit> GitHub: https://github.com//issues/28 <AmeliaBR> Github: https://github.com//issues/28 <AmeliaBR> Dirk: Sebastien proposed that clipPath and mask should inherit from SVGGraphicsElement, since they are grouping elements <AmeliaBR> https://svgwg.org/svg2-draft/types.html#InterfaceSVGGraphicsElement <AmeliaBR> Dirk: This adds interfaces like getBBox. <AmeliaBR> ... The question is, how does that interact with things like objectBoundingBox units and so on? <AmeliaBR> ... I definitely don't want to add it to level one, because no implementations yet, I'm not sure whether it's a good idea even in a future level. <AmeliaBR> Bogdan: Again, this is something where it would add a lot of implementation complexity. It's also not clear what the real use case is, beyond it would be nice to have. <AmeliaBR> Amelia: Other methods on the interface, like getScreenCTM, wouldn't make sense on never-rendered elements. So there would need to be a significant reorganization of what these interfaces mean. <AmeliaBR> Dirk: I propose resolving not to add to level 1, with no comment about defferring. <AmeliaBR> s/defferring/deferring/ <BogdanBrinza> resolution: Do not add SVGClipPathElement and SVGMaskElement inheritance from SVGGraphicsElement to level 1 |
As
<clipPath>
and<mask>
are grouping graphics elements similarily to<g>
, theirSVGClipPathElement
andSVGMaskElement
interfaces should also inherit fromSVGGraphicsElement
likeSVGGElement
does.Sebastian
The text was updated successfully, but these errors were encountered: