Bug 236193 - [LBSE] Implement SVG2 rules to establish a stacking context
Summary: [LBSE] Implement SVG2 rules to establish a stacking context
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nikolas Zimmermann
Keywords: InRadar
Depends on:
Blocks: 90738 236194
  Show dependency treegraph
Reported: 2022-02-05 16:28 PST by Nikolas Zimmermann
Modified: 2022-02-21 11:17 PST (History)
5 users (show)

See Also:

Patch, v1 (4.71 KB, patch)
2022-02-06 03:14 PST, Nikolas Zimmermann
no flags Details | Formatted Diff | Diff
Patch, v2 (5.31 KB, patch)
2022-02-17 03:23 PST, Nikolas Zimmermann
rbuis: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolas Zimmermann 2022-02-05 16:28:42 PST
Prepare RenderLayer/RenderLayerBacking for RenderSVGModelObject support:

Follow the rules specified in https://www.w3.org/TR/SVG2/render.html#RenderingOrder, when to create a stacking context. This is necessary to enforce layer creation.
Comment 1 Nikolas Zimmermann 2022-02-06 03:14:40 PST
Created attachment 451034 [details]
Patch, v1
Comment 2 Radar WebKit Bug Importer 2022-02-12 16:29:36 PST
Comment 3 Rob Buis 2022-02-14 05:26:56 PST
Comment on attachment 451034 [details]
Patch, v1

Does this mean we get same behaviour for SVG 1.1? Are the SVG 2 rules for this just what was already happening in SVG1.1 or are there differences?
Comment 4 Nikolas Zimmermann 2022-02-17 02:14:52 PST
(In reply to Rob Buis from comment #3)
> Comment on attachment 451034 [details]
> Patch, v1
> Does this mean we get same behaviour for SVG 1.1? Are the SVG 2 rules for
> this just what was already happening in SVG1.1 or are there differences?

Thanks for asking, unfortunately I'll have to expand a bit on that to give a proper answer: Neither SVG 1.1, nor SVG 1.1 Second Edition define/use the term "stacking context" -- however it is an essential concept at the core of CSS, used throughout many CSS specifications. Specifying CSS masks or clipping operations result in the creation of a "stacking context".

SVG 1.1 on the other hand, when defining clipping/masking operations talks about "offscreen RGBA images", initialized to 'transparent black' where e.g. the <mask> content is painted to and a set of rules how to "blend" those transparent offscreen images to final accumulated buffer representing the whole document.
SVG 1.1 group opacity description: https://www.w3.org/TR/SVG11/masking.html#ObjectAndGroupOpacityProperties)
SVG 1.1 masking: https://www.w3.org/TR/SVG11/masking.html#Masking

So how does SVG2 improve the situation? SVG2 defines that SVG elements establish stacking contexts, re-using the definitions from CSS. The whole rendering model for SVG was re-written in accordance with both SVG 1.1 SE (with minor differences only in previously un-spec'ed territory) and CSS Compositing and Blending https://www.w3.org/TR/compositing-1/ (Nikos from Canon was behind the SVG integration parts in 2012).
This naturally defines how CSS/SVG interoperate, in terms of stacking context, mix-blend mode support. It also describes under which circumstances 3D transformations are flattened for SVG content, etc. bridging the gap between SVG/CSS worlds.
Now back to SVG clipping/masking: SVG2 no longer talks about offscreen RGBA images, but directly redirects to CSS Masking Module Level 1: "Both, clipping and masking, are specified in the module CSS Masking [css-masking-1]."

From https://www.w3.org/TR/css-masking-1/#the-clip-path:
"A computed value of other than none results in the creation of a stacking context [CSS21] the same way that CSS opacity [CSS3COLOR] does for values other than 1.".

Tada, a stacking context is created for masks within SVG elements :-)
The whole concepts of SVG2 were properly integrated within the CSS cousins, merged and defined in interoperable ways.

SVG 1.1 was it's own animal, SVG2 is a first-class citizen in CSS world -- that was and is the original motivation for the whole LBSE work: the same unification that was done in the specs, applied to WebKit.

I could go on for all the other criteria in that list, but you'll get the picture :-)
Exciting no, how all the terminology changed? :-) And how the spec efforts really now paint a coherent picture of HTML5/SVG2 integration -- only stuff we could dream of when you began the initial 'CDF' support in 2004 :-)
Comment 5 Nikolas Zimmermann 2022-02-17 03:23:23 PST
Created attachment 452343 [details]
Patch, v2
Comment 6 Nikolas Zimmermann 2022-02-17 03:25:09 PST
I've removed the non-ASCII quotes from the comments and expanded the ChangeLog a bit, based on your question and my answer here on the ticket.
Comment 7 Nikolas Zimmermann 2022-02-21 11:15:49 PST
Committed r290254 (?): <https://commits.webkit.org/r290254>
Comment 8 Nikolas Zimmermann 2022-02-21 11:17:30 PST
Thanks Rob!