Bug 96163 - SVG does not respect overflow:visible
Summary: SVG does not respect overflow:visible
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://jsfiddle.net/Nu5m6/
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-07 17:05 PDT by Thomas Dybdahl Ahle
Modified: 2018-02-07 03:38 PST (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Dybdahl Ahle 2012-09-07 17:05:07 PDT
SVG acts as overflow:hidden no matter what is specified in css.

This also seams to be a bug in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=378923
Comment 1 ben 2012-11-12 17:58:50 PST
Overflow on svg elements should be specifiable in CSS. The spec is very clear on this point:

http://www.w3.org/TR/SVG/masking.html#OverflowProperty

This bug makes certain complex responsive page layouts extremely difficult. It's broken everywhere, even in Opera. It would be great to see webkit take the lead on this. Please fix.
Comment 2 Dirk Schulze 2012-11-12 20:02:57 PST
You need to see the overflow property together with the clip property. This clip property is set to the boundaries of the <SVG> element and clips all content. The root element is special anyway, but IIRC it will work for nested <SVG> elements in FF nightly, if you make the clipping region big enough or set the property to 'auto'
Comment 3 ben 2012-11-12 21:02:47 PST
Thanks, Dirk. Glad I caught your eye here. Point by point:

"You need to see the overflow property together with the clip property."

Not according to the spec. See bullet three from the above link: "If the ‘overflow’ property has a value other than hidden or scroll, the property has no effect (i.e., a clipping rectangle is not created)." In other words, when "overflow" is "auto" or "visible", there should be no clipping rectangle at all.

"This clip property is set to the boundaries of the <SVG> element and clips all content. The root element is special anyway,"

It's special in this context mainly because of bullet 7: "The initial value for ‘overflow’ as defined in [CSS2-overflow] is 'visible', and this applies also to the root ‘svg’ element." But again, this is not the current implementation in any browser.

"but IIRC it will work for nested <SVG> elements in FF nightly, if you make the clipping region big enough or set the property to 'auto'"

Not according to my experiments. In both chrome Version 25.0.1323.1 canary and FF 19.0a1 neither expanding the clipping rectangle nor setting "clip" to "auto" make overflow content visible. See:

http://jsfiddle.net/HRsvX/36/

(The red triangle should be fully visible outside the div for all three svgs.)
Comment 4 Dirk Schulze 2012-11-12 21:11:01 PST
You may got me wrong. Not the overflow property matters, but the 'clip' property:

""
The ‘clip’ property has the same parameter values as defined in CSS2 ([CSS2], section 11.1.2). Unitless values, which indicate current user coordinates, are permitted on the coordinate values on the <shape>. The value of auto defines a clipping path along the bounds of the viewport created by the given element.
""

This means the content is _always_ clipped to the view port (which is the boundaries of the <svg> element). This is independent of the overflow property value. So you need to set clip: rect(huge values) to change the clipping behavior. However, this just works on FF nightly so.
Comment 5 ben 2012-11-16 20:09:03 PST
Dirk, a couple points:

1) This does not work in Firefox nightly. Full stop. It is confirmed bug, and it has not been fixed. Read the bugzilla.mozilla thread in the original post. Out of curiosity, I've downloaded it and tested it, and it doesn't work. If you're seriously going to argue that it works in Firefox nightly, please post a working demo. 

2) Clipping paths are supposed to be mutable in CSS. So for example:

#clip1 {clip: rect(-10px,-10px,-10px,-10px)}

should expand the clipping path beyond the border edge of the element. Again, as shown in my fiddle in comment 3, this doesn't currently work for SVG. That's *in addition* to {overflow: visible} not working.

3) Sorry, but your reading of the spec is mistaken. Please look again. The passage you quote refers specifically to the meaning of an "auto" value. It is a huge inductive leap for you to say that sentence means that "content is _always_ clipped to the view port" in all cases, always. What you're describing only obtains when overflow is "hidden" and clip is "auto".

This needs to be confirmed as a clear-cut bug, and then fixed.
Comment 6 popecode 2013-07-26 10:29:13 PDT
Confirmed: still not working, as of 7/26/13, on both stable and beta versions of Chrome browser.  Accord with submitter: a fix for this bug is critical to certain forms of SVG development in browser.  Present trunk version of Firefox has provided the fix.
Comment 7 ben 2013-07-26 11:32:09 PDT
@ popecode. The blink bug for this is separate now, migrated to:

https://code.google.com/p/chromium/issues/detail?id=231577

FWIW I also think both these bugs should be renamed "CSS initial value for SVG overflow should be visible, not hidden". Because it's not just that browser don't respect "visible", it's that both webkit and blink are setting the initial value incorrectly.
Comment 8 Florin Malita 2013-07-26 11:50:05 PDT
(In reply to comment #7)
> @ popecode. The blink bug for this is separate now, migrated to:
> 
> https://code.google.com/p/chromium/issues/detail?id=231577
> 
> FWIW I also think both these bugs should be renamed "CSS initial value for SVG overflow should be visible, not hidden". Because it's not just that browser don't respect "visible", it's that both webkit and blink are setting the initial value incorrectly.

Why do you think that the default value is incorrect?

"As a result of the above, the default behavior of SVG user agents is to establish a clipping path to the bounds of the initial viewport and to establish a new clipping path for each element which establishes a new viewport and each ‘pattern’ and ‘marker’ element."

http://www.w3.org/TR/SVG/masking.html#OverflowAndClipProperties
Comment 9 Florin Malita 2013-07-26 11:55:38 PDT
Also: "overflow: hidden" is pretty much spelled out in the SVG UA style sheet.

http://www.w3.org/TR/SVG/styling.html#UAStyleSheet
Comment 10 ben 2013-07-26 12:21:58 PDT
This part of the 1.1 spec is pretty contradictory. For "initial value" it says "see prose". Down in yonder prose:

1) "If the ‘overflow’ property has a value other than hidden or scroll, the property has no effect (i.e., a clipping rectangle is not created)."

That seems pretty clear. "Visible" declaration = no clipping rectangle.

2) "The initial value for ‘overflow’ as defined in [CSS2-overflow] is 'visible', and this applies also to the root ‘svg’ element;"

Again, seems crystal clear. "Visible" is the initial value for root-level. Plain as day. I would like to take this at face value...

...but then the sentence you quote from just underneath rolls that all back (!):

"As a result of the above, the default behavior of SVG user agents is to establish a clipping path to the bounds of the initial viewport and to establish a new clipping path for each element which establishes a new viewport and each ‘pattern’ and ‘marker’ element."

So where does that leave things? Maybe the compromise reading we could live with for now is that on root-level svgs, there is a clipping rectangle created, but that clipping rectangle isn't actually clipping anything initially, because "visible" is the initial value.

But then you're totally right that the UA stylesheet flatly contradicts the Clipping & Masking spec, recommending "hidden". Also, the Clipping spec makes a fine distinction between root-level and not-root svg, and the UA stylesheet makes no such distinction. This could really use clarification and consistency in SVG2.

[Reading this as "prose", as suggested, it's hard not to infer that "visible" was originally written as the initial value, for consistency across CSS (a beautiful thing), but that the last sentence got tacked on by implementers who understandably didn't want to deal with the arduous complexities of overflow :) ]
Comment 11 ben 2013-07-29 17:47:44 PDT
The SVG2 draft spec is unequivocal on the initial value of overflow. It's 'visible':

http://www.w3.org/TR/SVG2/masking.html#OverflowAndClipProperties
Comment 12 popecode 2013-08-02 09:21:26 PDT
My practice benefits greatly from Webkit technology.  I am grateful for it. 

Unless the spec clearly states to the contrary, it should be read to be consistent with its context.  And I think that means that the "overflow" attribute in an SVG tag should work in symmetry with how the overflow attribute works elsewhere, e.g., in a DIV tag.

The fiddle on this, to my mind, plainly illustrates the problem. Has anyone looked at this?  Try it with a Webkit browser and then with Firefox nightly.  Hopefully the stark difference there illustrated will see this matter through the pettifogging and toward a fix.

...nearly one year outstanding?
Comment 13 Alex Zhu 2014-03-31 03:54:46 PDT
I am not going to join the argue about css standard. Could any one gives a svg overflow:visible workaround solution.
Comment 14 Dirk Schulze 2014-05-12 07:29:09 PDT
We changed the behavior in CSS Masking and Firefox follows this already. WebKit and Blink have been fixed recently.
Comment 15 deanbugzilla 2016-08-19 21:42:14 PDT
This doesn't seem to work when using <symbol> and <use>:

http://jsfiddle.net/HRsvX/146/

But it works correctly for Firefox. Is this a bug?
Comment 16 deanbugzilla 2016-08-19 21:48:55 PDT
Nevermind, I think it was the UA stylesheet setting symbol overflow to hidden:

http://jsfiddle.net/HRsvX/147/
Comment 17 Daniel Caine 2017-07-20 08:09:40 PDT
This still appears to be a problem. Latest Safari on MacOS and iOS doesn't honour the display: visible rule, as seen in this Codepen: https://codepen.io/A7DC/pen/bRJrBN

Has anyone figured out a workaround for this besides manually changing the size of the SVG to have more spacing around the edges?
Comment 18 Sriram R 2018-02-07 03:38:45 PST
This still appears to be a problem on Safari(jan 2018). May I know if there is any plan to fix this?