[css-masking-1] Let SVGClipPathElement and SVGMaskElement inherit from SVGGraphicsElement

[SebastianZ]

As <clipPath> and <mask> are grouping graphics elements similarily to <g>, their SVGClipPathElement and SVGMaskElement interfaces should also inherit from SVGGraphicsElement like SVGGElement does.

Sebastian

[AmeliaBR]

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 clipPath or mask?

[SebastianZ]

Yes, I thought getBBox() would be useful to have available on them. One use case for it would be to have the highlighter of browser developer tools available for <clipPath> and <mask> elements.

Sebastian

[AmeliaBR]

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.

getBBox() could work because it doesn't actually depend on a parent coordinate system, only on the child content. But the other methods currently defined for graphics elements (cumulative transform matrices) don't make sense.

[SebastianZ]

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).

getBBox() could work because it doesn't actually depend on a parent coordinate system, only on the child content. But the other methods currently defined for graphics elements (cumulative transform matrices) don't make sense.

Agree. So I see three solutions:

1. Add getBBox() to SVGClipPathElement and SVGMaskElement rather than letting them inherit from SVGGraphicsElement
2. Let SVGClipPathElement and SVGMaskElement inherit from SVGGraphicsElement and define that the cumulative transform matrice methods return an invalid value for them.
3. Move getBBox() to a new interface and let SVGGraphicsElement, SVGClipPathElement and SVGMaskElement inherit from it.

I'd be fine with all three of them, but I think number 3 would be the cleanest.

Sebastian

[dirkschulze]

@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.

[dirkschulze]

@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 <mask> or <clipPath>.

@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.

[SebastianZ]

@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

[bzbarsky]

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.

[css-meeting-bot]

The Working Group just discussed Let SVGClipPathElement and SVGMaskElement inherit from SVGGraphicsElement.

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