Behavior of clipping on SVG root elements

[Chris Harrelson]

This behavior was changed in crbug.com/231577 (via this CL) to: always clip SVG to the bounds of the root SVG element, unless the SVG element is not a standalone document and overflow: visible is specified (*).

I read through crbug.com/231577 and the relevant spec language, and can't find language which specifies this behavior. Does a spec change need to be made?

Chris

(*) The CL says it doesn't clip for overflow: auto but that doesn't seem to work; example in crbug.com/701654. I think the current behavior makes more sense, since overflow: auto is the default setting.

[Tien-Ren Chen]

crbug.com/701654 is actually an interesting example. I think we should
match the behavior of the other browsers.

My rationale is that overflow clip only applies to contents, but not
box decorations. For example <div style="border:1px dashed black;
overflow:hidden;"> the border of the box should still be visible, and
let's say we have <div style="border:1px dashed black;
overflow:hidden; filter:blur(1px);">, we shall see a blurred border
box. i.e. overflow clip of the current element doesn't apply to the
output of the grouping effect. (On the other hand, overflow clips
inherited from ancestor containing blocks do apply to the grouping
effect outputs.)

I think the language meant to say that a standalone SVG document
embedded using <img>, <iframe> or whatever, should behave like a
static image thus clipped to the bound, but for <svg> embedded as a
XHTML element it should behave more like a CSS box.

> --
> You received this message because you are subscribed to the Google Groups
> "paint-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to paint-dev+...@chromium.org.
> To post to this group, send email to pain...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAOMQ%2Bw_Cdebu%2BG9bVdnwTA8RwMaM02WO2kLWSRR%3DjdmkZp%3D3CQ%40mail.gmail.com.

[Chris Harrelson]

Here is the equivalent for a box:

http://output.jsbin.com/buxukafubo

Firefox does not clip either of them.

Like the SVG example, it clips the box shadow. So this change would be more wide-ranging than SVG.

> email to paint-dev+unsubscribe@chromium.org.

[Chris Harrelson]

Safari (unsurprisingly) matches Chrome for these.

[Chris Harrelson]

Edge matches Firefox. 2-2!

[Chris Harrelson]

In any case, this is a different question. The original question was where the spec language is that supports current overflow behavior.

I'll follow up separately about the question of whether filter output should be clipped.

[Tien-Ren Chen]

I think this involves a bug in Blink. If you add will-change:opacity
to both box to force compositing, then both shadows become visible.
(which IMO, is the right behavior.) Though yes, I agree how 'overflow'
property interact with 'filter' property is a separate matter.

As for the spec language, I think it is pretty consistent with the
description of crbug.com/231577 ? (at least that's my interpretation)

"When an outermost svg element is stand-alone or embedded inline
within a parent XML grammar which does not use CSS layout or XSL
formatting, the ‘overflow’ property on the outermost svg element is
ignored for the purposes of visual rendering and the initial clipping
path is set to the bounds of the initial viewport." ---> If SVG is
standalone, ignore 'overflow' property, always clip to the bounds.

"When an outermost svg element is embedded inline within a parent XML
grammar which uses CSS layout ([CSS2], chapter 9) or XSL formatting
[XSL], if the ‘overflow’ property has the value hidden or scroll, then
the user agent will establish an initial clipping path equal to the
bounds of the initial viewport; otherwise, the initial clipping path
is set according to the clipping rules as defined in CSS2 ([CSS2],
section 11.1.1)." ---> If SVG is embedded as a XHTML tag, use CSS
rules for overflow clipping.

>> > email to paint-dev+...@chromium.org.

[Stephen Chenney]

My understanding, because it was surprising to me, is that filters and shadows escape overflow clips. I don't recall where I learned that.

Stephen.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAOMQ%2Bw-LPLoOqLO-CHfUtEVn4%2BV2WMbP0W%3DyJ9eWH9WtbtfLGg%40mail.gmail.com.

[Chris Harrelson]

On Thu, Mar 16, 2017 at 5:06 PM, Tien-Ren Chen <trc...@chromium.org> wrote:

I think this involves a bug in Blink. If you add will-change:opacity
to both box to force compositing, then both shadows become visible.
(which IMO, is the right behavior.) Though yes, I agree how 'overflow'
property interact with 'filter' property is a separate matter.

As for the spec language, I think it is pretty consistent with the
description of crbug.com/231577 ? (at least that's my interpretation)

"When an outermost svg element is stand-alone or embedded inline
within a parent XML grammar which does not use CSS layout or XSL
formatting, the ‘overflow’ property on the outermost svg element is
ignored for the purposes of visual rendering and the initial clipping
path is set to the bounds of the initial viewport." ---> If SVG is
standalone, ignore 'overflow' property, always clip to the bounds.

"When an outermost svg element is embedded inline within a parent XML
grammar which uses CSS layout ([CSS2], chapter 9) or XSL formatting
[XSL], if the ‘overflow’ property has the value hidden or scroll, then
the user agent will establish an initial clipping path equal to the
bounds of the initial viewport; otherwise, the initial clipping path
is set according to the clipping rules as defined in CSS2 ([CSS2],
section 11.1.1)." ---> If SVG is embedded as a XHTML tag, use CSS
rules for overflow clipping.

Why is the default not overflow: visible though? In the bug, one person said his interpretation is that the "clip" property is the one that implies the clip, not overflow.

 

>> > email to paint-dev+unsubscribe@chromium.org.

[Philip Rogers]

Chris,

Are you asking why overflow: hidden is the default for the outermost svg? In other words, why inspecting the second circle in http://jsbin.com/tokufu shows overflow: hidden?

If so, it is due to the user agent stylesheet:

https://svgwg.org/svg2-draft/single-page.html#render-OverflowAndClipProperties

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/svg.css

[Chris Harrelson]

On Thu, Mar 16, 2017 at 8:11 PM, Philip Rogers <p...@chromium.org> wrote:

Chris,

Are you asking why overflow: hidden is the default for the outermost svg? In other words, why inspecting the second circle in http://jsbin.com/tokufu shows overflow: hidden?

Yes, this is my question.

 

If so, it is due to the user agent stylesheet:

https://svgwg.org/svg2-draft/single-page.html#render-OverflowAndClipProperties

Ok. It does seem to say that in the table there.

 

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/svg.css

Where in here is it though? The only overflow:hidden rule I see is

svg:not(:root), symbol, image, marker, pattern, foreignObject

which is not for SVG root.  Also the comment on line 42 sounds like the opposite of overflow:hidden. ?

[Fredrik Söderquist]

On Fri, Mar 17, 2017 at 4:54 AM, Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Mar 16, 2017 at 8:11 PM, Philip Rogers <p...@chromium.org> wrote:

Chris,

Are you asking why overflow: hidden is the default for the outermost svg? In other words, why inspecting the second circle in http://jsbin.com/tokufu shows overflow: hidden?

Yes, this is my question.

 

If so, it is due to the user agent stylesheet:

https://svgwg.org/svg2-draft/single-page.html#render-OverflowAndClipProperties

Ok. It does seem to say that in the table there.

 

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/svg.css

Where in here is it though? The only overflow:hidden rule I see is

svg:not(:root), symbol, image, marker, pattern, foreignObject

which is not for SVG root.  Also the comment on line 42 sounds like the opposite of overflow:hidden. ?

svg:not(:root) means it is for <svg> that are not the root of the document (the documentElement; "other svg" in the spec table), which matches what the table in the spec say.

/fs

[Chris Harrelson]

On Fri, Mar 17, 2017 at 3:29 AM, Fredrik Söderquist <f...@opera.com> wrote:

On Fri, Mar 17, 2017 at 4:54 AM, Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Mar 16, 2017 at 8:11 PM, Philip Rogers <p...@chromium.org> wrote:

Chris,

Are you asking why overflow: hidden is the default for the outermost svg? In other words, why inspecting the second circle in http://jsbin.com/tokufu shows overflow: hidden?

Yes, this is my question.

 

If so, it is due to the user agent stylesheet:

https://svgwg.org/svg2-draft/single-page.html#render-OverflowAndClipProperties

Ok. It does seem to say that in the table there.

 

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/svg.css

Where in here is it though? The only overflow:hidden rule I see is

svg:not(:root), symbol, image, marker, pattern, foreignObject

which is not for SVG root.  Also the comment on line 42 sounds like the opposite of overflow:hidden. ?

svg:not(:root) means it is for <svg> that are not the root of the document (the documentElement; "other svg" in the spec table), which matches what the table in the spec say.

Ah, ok thanks. Does the comment on line 42 need to be updated also, or am I also misreading that? 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAHediLRwfOMTbiQcFfOqRaBTorMjpr70hp58tBe94YziOPJRUQ%40mail.gmail.com.

[Fredrik Söderquist]

On Fri, Mar 17, 2017 at 4:09 PM, Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Mar 17, 2017 at 3:29 AM, Fredrik Söderquist <f...@opera.com> wrote:

On Fri, Mar 17, 2017 at 4:54 AM, Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Mar 16, 2017 at 8:11 PM, Philip Rogers <p...@chromium.org> wrote:

Chris,

Are you asking why overflow: hidden is the default for the outermost svg? In other words, why inspecting the second circle in http://jsbin.com/tokufu shows overflow: hidden?

Yes, this is my question.

 

If so, it is due to the user agent stylesheet:

https://svgwg.org/svg2-draft/single-page.html#render-OverflowAndClipProperties

Ok. It does seem to say that in the table there.

 

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/svg.css

Where in here is it though? The only overflow:hidden rule I see is

svg:not(:root), symbol, image, marker, pattern, foreignObject

which is not for SVG root.  Also the comment on line 42 sounds like the opposite of overflow:hidden. ?

svg:not(:root) means it is for <svg> that are not the root of the document (the documentElement; "other svg" in the spec table), which matches what the table in the spec say.

Ah, ok thanks. Does the comment on line 42 need to be updated also, or am I also misreading that?

It should probably be clarified at least. (It's accurate if you insert 'standalone' or 'document root' or something similar it might make more sense. I suspect this comment is roughly as old as the mail thread it references, and at that point in time "outermost svg root" pretty much equated to standalone. I don't quite remember when the HTML5 parsing algorithm had been implemented wide-spread enough, but before that you only had SVG-in-XHTML, and for some reason you tended to forget about that quite easily... ;-))

/fs

[Chris Harrelson]

Update: I don't think the problem is actually a fundamental issue of clipping after filter. I think it's a relatively

simple bug in PaintLayerClipper where we fail to expand the visual overflow rect to include filtered output bounds. This is ok because the clip applied here is for the "background rect", which is a cull rect and not a

strict clipping rect.

https://codereview.chromium.org/2781863005

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAHediLTUETaMHDaHAVZZJcqj9rHg4P%2BG6sbY-TpjG%2BLoSK7jaA%40mail.gmail.com.