Should SVG contents be visible outside an embedded <svg> by default? [closed]
Asked Answered
D

2

9

In the past I answered a question about "who was wrong" in regards to SVG images not being "cropped" (overflow: hidden) in IE9, where all other supporting browsers did so. The answer is here.

Today, while reviewing HTML5 Boilerplate again, I noticed that they claim they "[correct] overflow not being hidden in IE9" with this bit of code:

svg:not(:root) { overflow: hidden; }

I'm looking for someone to confirm or deny my original research by pointing to some other note in either the HTML5 or SVG specs. I cannot find anything, but I want to be sure I am not missing something.

The best I can find is that they are trying to apply rule 7 here, but that should only apply to an SVG Document, like via an img tag or when loaded directly.

Dairy answered 9/4, 2012 at 17:41 Comment(5)
Thanks for the title edit @Phrogz. I was having some trouble with how exactly to summarize the question.Dairy
@casperOne How is asking for clarification on a specification not a real question? I can see the wording being poor, but I don't see how it fits the category you've labeled it. Is it too localized?Dairy
You want someone to clarify whether or not someone was right or wrong. I could reopen it, but then I'd just close it again as "Not Constructive".Spilt
@Spilt I get where you are coming from, but I'm actually asking for help in understanding their interpretation (most browsers and boilerplate) vs. mine. Specifically, where I went wrong in my research. The only reference as to "who is right" is where I quoted myself (poorly) from a previous answer for context to why I was asking in the first place. Thanks for the info though, I'll keep it in mind for the future.Dairy
Question is both valid and constructive. He's asking for clarification on a spec that's implemented differently by different browsers, which is relevant to browser development if nothing else..Marismarisa
S
4

The SVG specification has this to say: http://www.w3.org/TR/SVG/styling.html#UAStyleSheet

Seems similar to what Firefox and Chrome do no?

Scutcheon answered 9/4, 2012 at 18:52 Comment(4)
Nice one, though (per my answer) both Chrome and FF use the same slightly modified version. (Perhaps there's errata around this?) This thus implies that IE was wrong to not have this UA sheet. However, it does not fully clarify for me why overflow:visible does not cause the overflowing path to appear in Chrome/FF. It's perhaps a separate question, but what are the expectations on the 'bounds` of the SVG to be rendered? When would the bounds ever exceed explicit height and width?Bullyrag
This discussion is relevant.Bullyrag
Thanks for pointing that out. It seems that perhaps a conflict in the default required stylesheet for SVG namespace elements conflicts with rule 7 above + w3.org/TR/SVG/styling.html#Scope ?Dairy
After reading the above discussion link, the link in your answer, and re-reading the spec, it makes sense now that the UA Stylesheet required by the spec makes IE9 invalid now. Thanks for the help!Dairy
B
4

Your original answer seems sound to me, using the grounds you specified (specifically the fifth and seventh bullet points of the spec).

It seems incredibly unlikely that IE is correct and Webkit and Firefox are not. However, as you suspect the seventh bullet point is the differentiating factor.

If you load this test case in Chrome and use the Developer Tools to inspect the SVG, you will see:

(user agent stylesheet)

svg:not(:root), symbol, image, marker, pattern, foreignObject {
  overflow: hidden;
}

If you enable "Show User Agent CSS" in Firebug you see this rule in Firefox:

svg.css (line 49) <System>

svg:not(:root), symbol, image, marker, pattern, foreignObject {
  overflow: hidden;
} 

Finally, if you edit the test case to add svg { overflow:hidden } then IE visually matches the other browsers.

Thus, it would seem to me that all three browsers are behaving according to the spec, but Chrome/Safari/FF all have UA rules that more closely match what most users would expect.

If I could leave well-enough alone, this is where I'd stop this answer.

However, if you edit the test case to add svg { overflow:visible }, both Chrome and Firefox do not 'properly' show the overflowed contents. I'm not sure how to resolve this data point with the rest of this answer. :/

Bullyrag answered 9/4, 2012 at 18:18 Comment(3)
Opinion (not answer): without the behavior of Chrome and Firefox, there is the implication that <svg width="4" height="4" viewBox="0 0 1 1" style="overflow:visible"> would need to find the bounding box of the entire contents and render the full contents of the SVG at 4px per world unit. This is so contrary to what I would ever want from an SVG I think there must be a spec defining the extents of the SVG contents to render. And I suspect that IE9 has missed or misinterpreted this spec (that I cannot find).Bullyrag
Thanks for the detailed answer. (Also opinion) I do agree that most people, especially those more familiar with binary images and image tags, would not expect an SVG image to overflow by default. @Robert's link above brings an interesting conflict in ruling to light when comparing the default UA that must be implemented vs. rule 7 (keyword SVG Document) + w3.org/TR/SVG/styling.html#ScopeDairy
After putting it all together with your discussion link and the UA stylesheet link above I see where IE9 is in error. Rule 7 does apply, not as a separate rule, but in combination with all rules in overflow as a warning to UAs that the default style for viewports is overflow: hidden.Dairy
S
4

The SVG specification has this to say: http://www.w3.org/TR/SVG/styling.html#UAStyleSheet

Seems similar to what Firefox and Chrome do no?

Scutcheon answered 9/4, 2012 at 18:52 Comment(4)
Nice one, though (per my answer) both Chrome and FF use the same slightly modified version. (Perhaps there's errata around this?) This thus implies that IE was wrong to not have this UA sheet. However, it does not fully clarify for me why overflow:visible does not cause the overflowing path to appear in Chrome/FF. It's perhaps a separate question, but what are the expectations on the 'bounds` of the SVG to be rendered? When would the bounds ever exceed explicit height and width?Bullyrag
This discussion is relevant.Bullyrag
Thanks for pointing that out. It seems that perhaps a conflict in the default required stylesheet for SVG namespace elements conflicts with rule 7 above + w3.org/TR/SVG/styling.html#Scope ?Dairy
After reading the above discussion link, the link in your answer, and re-reading the spec, it makes sense now that the UA Stylesheet required by the spec makes IE9 invalid now. Thanks for the help!Dairy

© 2022 - 2024 — McMap. All rights reserved.