emilbjorklund / svg-weirdness

A repository of bugs and plain weird behavior in SVG

SVG Weirdness

A repository for documenting bugs and other weird SVG behaviors, inspired by Scott Jehl’s “Device Bugs” repo.

This is not necessarily meant to be a full list of bugs in SVG implementations, but a the very least a list of bugs and other “gotchas” primarily in browsers that are not likely to be upgraded (older WebKit-based browsers on Android, older IE browser versions etc).

All SVG issues are welcome though, as long as they are accompanied by documentation of which browser engines and version numbers they affect.

svg-weirdness's Issues

Safari SVG filter on iframe with external iframe src and external filter w/ srcdoc

It seems that Safari 12 is unable to apply SVG filters on both relative and external to iframe HTML elements with varying src and srcdoc attributes.

The filter is either ignored or renders a blank iframe. I've put together a live preview of this behaviour here: https://adamzerella.github.io/bug-safari-iframe-svgfilter/

Tested with: Version 12.0.2 (14606.3.4)

CSS clip-path only works properly on first element in Safari 10

Using CSS clip-path on multiple elements using the same path only displays on first element and renders strange on, or doesn't display, the proceeding elements in Safari 10.0.

See CodePen for example: http://codepen.io/ryan_labar/pen/KgLNyx

Willful Internet Explorer spec violations

While IE9+ don't have perfect SVG implementations, Microsoft was kind enough to state explicitly what feature omissions were intentional and not a result of bugs.

The list, for those who don't want to click through:

• xml:space is not supported.
• A value of 0 on the viewBox height or width does not disable rendering of the element.
• IE9 does not support SVG filters.
• The normalizedPathSegList and pathLength DOM interface attributes are not supported.
• <tref> is not supported.
• The glyph-orientation-horizontal and glyph-orientation-vertical attributes are not supported.
• The dominant-baseline, alignment-baseline, and baseline-shift attributes are not supported.
• The kerning attribute is not supported.
• <altGlyph> is not supported.
• Properties of <marker> inherit at the point of reference, not from its ancestors.
• color-interpolation and color-interpolation-filters are not supported.
• color-rendering, text-rendering, and image-rendering are not supported.
• The display property affects <pattern>s and references to those pattern elements.
• The clip CSS property is not supported.
• <clipPath> allows indirect references. Indirect references are not an error.
• zoomAndPan is ignored.
• <cursor> is not supported.
• Parameters for viewBox elements in fragment specifications may be delimited by single spaces in addition to commas.
• externalResourcesRequired is not supported.
• SMIL is only supported enough to make its animVal attributes always reflect baseVal.
• <foreignObject> is not supported.
• The title attribute supports the click event even though it should not be supported.
• The currentView IDL attribute is not supported.

I think this means the inline SVG overflow bug was actually a bug. (You know, the svg:not(:root) {overflow: hidden} one.)

Firefox reader view strips styles from inline SVG

While testing issue #36 in other browsers, I found that Firefox’s reader view will display inline SVG, but it strips any CSS styling from them. Given the purpose behind “reader views,” that may make sense for typographical elements, but for SVG images, it can lead to colors or other features being removed.

IE miscalculates aspect ratio of SVG background images, unless width and height are set.

Background SVG images in IE get very weird dimensions sometimes, unless the width and height attributes are set on the <svg> element in the source graphic (and match the aspect ratio).

Fix: set width and height (as well as viewBox) on all your SVG background images, and you’re done. It doesn’t matter which measurements you use, as long as they match the aspect ratio of the graphic: if they’re there, you can always resize the background in CSS.

If width and height are missing, a few different scenarios seem to occur:

• IE 9-10 will resize the SVG canvas according to the background-size property, but the positioning/sizing of stuff inside the SVG viewport gets squashed in mysterious ways.
• IE11 is slightly better in that it doesn't squash stuff, just sizes it in unexpected ways.
• If you set background-size in just one dimension (e.g. background-size: 100% auto), all of the IE:s will pick the aspect ratio for the background from the aspect ratio of the element dimensions. Whoa.

The bug is fixed in MS Edge.

(As a sidenote, I believe a lot of people miss this bug when they first try out SVG backgrounds, because they use square SVG graphics for square elements, e.g. icons)

Writeup on my blog, demos at JSbin

feSpotlight positioning does not work in Safari

I'm using a spotlight effect that seems to only work perfectly in chrome, ok in firefox, but will not position (x,y,z) at all in Safari. (Other browsers not tested)

I've tried different filter and primitive units, and while this makes a difference, Safari still cannot seem to position the lighting effect in any case.

In pursuit of understanding what is going on, I've tried lots of workarounds (including #22/#27), different userSpaceOnUse/objectBoundingBox combos, and different svg structure but have never been able to find one that works on Safari.

Examples

Default filter/primitive units (Safari positions it off-canvas to the right):
https://jsfiddle.net/localnerve/y470d52v/

objectBoundingBox units (easier to see Safari's positioning trouble):
https://jsfiddle.net/localnerve/uyc7o52k/

Pretty weird.

I have pictures on this stackoverflow issue to further demonstrate:
https://stackoverflow.com/questions/44891524/safari-trouble-positioning-svg-fespotlight-filter

Safari 10 breaks focus when an <use /> element with xlink:href sits in SVG in document

See this tweet and this react bug for discussion.

It appears that this is a regression from Safari 9 to Safari 10.

Older browsers don't calculate intrinsic dimensions from the viewBox attribute

The viewBox attribute makes can be used instead of explicit width and height to define an SVG element's aspect ratio so that they act just like images do when styled with CSS (height is scaled proportionally when you only declare width, etc.). According to the spec regarding "Intrinsic sizing properties of the viewport of SVG content" (emphasis mine):

If either/both of the ‘width’ and ‘height’ of the outermost svg element are in percentage units (or omitted) (used value is auto), the aspect ratio is calculated from the width and height values of the ‘viewBox’ specified for the current SVG document fragment. If the ‘viewBox’ is not correctly specified, the intrinsic aspect ratio cannot be calculated and is considered unspecified.

Unfortunately, most of the major browsers haven't followed this part of the spec until relatively recently. Chrome 36 introduced support for intrinsic sizing by viewBox in July, 2014; Safari didn't do it until recently, but I haven't been able to hunt down the changelog to see when; Firefox was a late adopter too, but I don't know exactly when they fixed it. iOS and Android browser support should probably be listed separately, too.

ground-size

Firefox does not like missing leading zeros in animation duration

When doing a SMIL animation, I noticed that it did not work in Firefox when using a dur=".75s".

Doing dur="0.75s"works, however.

Demo here:
Broken: http://jsbin.com/qogefo/2/edit?html,css,output
Fixed: http://jsbin.com/qogefo/3/edit?html,css,output

If I'm reading the SVG spec correctly, the <number> data type allows zero or more digits before the decimal separator, and <time> consists of <number> and a unit, so this appears to be a bug from that perspective. However, the SMIL section of the spec lists a specific and different syntax for time values in animations. Makes me wonder, when else is <time> used in SVG?

Bug report and discussion here.

Almost no browsers support `enable-background` for SVG filters

Due to spec issues and Adobe Illustrator putting enable-background on everything by default, the only browsers that support it are the old Opera Presto engine, and Internet Explorer 10+.

Usage of SVG filters therefore requires some additional considerations since the spec examples don't work. Usually one has to mess with <feImage>.

Firefox may not render svg if xlink:href value has trailing whitespace

When including svgs via <use xlink:href="#someSymbolId"/>, Firefox (v103.0.2 on macOS 12.3.1) seems to be more sensitive to whitespaces in the value of xlink:href. I observed a case where <use xlink:href="#someSymbolId "/> (note the trailing whitespace) would not show the icon. In this case the Firefox devtools simply showed an empty #shadow-root. This did not occur in Chrome (v104.0.5112.79).

Using calc() with viewport units on SVG paths crashes Edge 14

Using viewport units (vw, vh) in a calc function on an SVG path element causes the browser to crash. IE11 works fine. Haven't tested Edge 13 & 15.

Reported issue

Pen

Safari can only use symbols above the use in the DOM

In Safari, all SVG symbols must be added to the DOM before the <use /> tag referencing them. All other browsers seem to be fine having the symbols added to the end of the body.

One work around is to modify the symbol content once the page has finished loading. For example adding a loaded class to the SVG will force Safari to re-render the symbol.

Image elements pointing to SVG src might not read correctly in VoiceOver

Not an SVG bug in itself, but rather a browser/a11y bug that pertains to using SVG images.

This markup:

<img src="image.svg" alt="hi">

...will not get read properly in VoiceOver/Safari.
From the excellent post on image accessibility by Scott O'Hara:

Desktop Safari and VoiceOver will announce “hi, group” with no announcement of the element being an “image”. However, what’s more problematic is that iOS Safari and VoiceOver will skip over the element all together, as if it were decorative.

The fix is to add a role="img" attribute to the markup. More from Scott:

Proving an image element with a role="img" will announce the “image” role as intended with macOS Safari, and fix it from being ignored on iOS. You’ll get some automated testing tools throwing warnings for the redundant role, but that’s better than it being incorrectly announced or ignored, in my opinion.

Link to WebKit issue

Safari 9 < 9.1.1 / Mobile Safari 9 < 9.3.2 download external svg sprite file for every <use> xlinks:href instance

This was originally posted by @codecandies on the svg4everybody repo. Copying it to here for posterity.

In this testcase http://phpscripts.zeit.de/svg-use-testcase/ you can see the problem, by loading and examining it with Chrome and a Safari greater 9 (exact version mentioned on the testcase). The problem is also seen in iOs safari, since 9.2 i guess (inspected with Charles proxy).

The problem

For every combination of the code

<svg class="svg-symbol" role="img" aria-labelledby="title">
    <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="icons.svg#svg-search"></use>
</svg>

the svg file icons.svg is (re-)downloaded by safari/mobile safari browsers. Additionally the file is not cached in the browser or ever served from cache, and the developer tools see this file not as image/svg+xm but as other.

This leads to extreme high content downloads, which, especially on mobile, is not good.

A bug has been logged to webkit: https://bugs.webkit.org/show_bug.cgi?id=156368

@martinwolf has documented the issue in detail here: https://www.youtube.com/watch?v=OAbmDlnq1UE

Screenshots from the network panel from Chrome v50 compared with Safari v9.1:

Fluid SVG Height Trouble

When making SVG fluid, you might find some issues where the height is randomly assigned in Safari on older versions of iOS or IE. You have to set the height to 100% because it’s not readjusting to the viewport width. You can’t use height: auto; because it’s not part of the SVG spec.

Android (stock WebKit browser) before 4.4 doesn't support masking

The stock WebKit that comes with Android 3 – 4.4 does not support the <mask> element and related attributes.

Workaround: use clipping with <clipPath> instead, where possible.

Safari: SVG filter are not apply on a moving element.

Safari Version 10.0.1

SVG filter does not apply on a moving Dom's element.

Chrome: apply the filter and animates the Dom's element smoothly.

filter: url("#goo");
transform: translateX(10px);

http://codepen.io/thierryc/pen/amgzLY

Unexpected Behavior for Animating Transforms for <use>

There are some very strange gotchas of behavior if you try to use groups or symbols and and then animate them. Explained here: http://codepen.io/sdras/pen/qEVPjm

Gradients in <use> are invisible if symbol svg is display: none

If you have an SVG with symbols in it that also contain gradients, and you set this SVG to display: none; then anytime you use the symbols with <use>, the gradients will not show up.

SVG Sprite is not hidden and gradient is therefore visible
http://codepen.io/jakobud/pen/jPpboq

SVG Sprite is set to display: none….. gradients do not show up!
http://codepen.io/jakobud/pen/ZGjbde

The work-around:
SVG Sprite is set to display: block, width: 0, height: 0… gradients work again
http://codepen.io/jakobud/pen/KpBdjM

This also occurs if any parent of the symbol SVG is display: none.

Safari filter and html base tag

When using a html <base href="" /> tag svg filter attribute makes element invisible:

example code:

<html>
  <head>
    <base href="test"/> <!-- ######### remove this base tag to make it work ######  -->
  </head>
  <body>
<svg>
  <defs>
    <filter x="0" y="0" width="1" height="1" id="solid">
      <feFlood flood-color="white"/>
      <feComposite in="SourceGraphic"/>
    </filter>
  </defs>
  <path d="m20 20h150v10h-150" stroke="#000" stroke-miterlimit="10"/>
  <text filter="url(#solid)" fill="#c45" x="50" y="30" font-size="50px">tesst</text>
</svg>
  </body>
</html>

Probably related to #22

The tabindex attribute is camelCased tabIndex in SVG documents in Edge

From tweet:

The tabindex attribute for SVG is implemented as tabIndex (capital I), and does not work when the (correct) all-lowercase form is used in XML markup or in DOM methods. (It only works in HTML markup because the parser is changing the case.)

Edge tracking bug: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/16496551/

Fractional offset of inline SVG box shifts pixel grid

Affects: IE 9 to Edge (ex-Spartan), Firefox

While the top-left corner of <svg> bounding box coordinates are rounded, the svg contents are rendered as if there was no rounding.

Demo: https://jsfiddle.net/subzey/8a3wa5nv/1/embedded/result/
Notice how grid becomes blurry when offset is fractional. At the same time the border is rendered sharply all the time.

It's relatively easy to avoid fractional absolute coordinates when setting via JS. But the fractional part may appear if anything in the document flow before the svg element had fractional size, for example, inline-block with text.

Maybe the described behavior is spec compliant, but it's hard to reach pixel-perfect rendering.

IE may render symbols as sticking out of iframe/object/embed etc

Demo of the bug here: http://jsbin.com/soyuka/5

IE (versions 9-11, i.e. all that support SVG) have a bug where SVG content can be rendered as sticking out of an iframe, object or embed element.

I’m not a 100% sure of exactly which conditions trigger the bug, but in the examples, a few things seem to be necessary:

• A nested symbol element, i.e. a symbol inside of a symbol, being used.
• A transform applied to that symbol, so that the rendered shape ends up off-canvas.

A few conditions also seem to remedy the behavior:

• Setting symbol { overflow: visible; } with CSS. Note: visible makes the overflow hidden, which I thought was kind of funny.
• Using transform on another symbol sometimes seem to correct the rendering. (Uncomment the other markup in the SVG example to see this behavior)

The bug seems somewhat intermittent – sometimes, it renders fine, but on the next reload shows up again.

I initially saw the bug only when the same SVG-file was requested into multiple iframe elements, but not when a single instance was loaded, so I mistakenly thought that there was some form of ”ID collision” going on cross-documents, but that does not seem to be the case.

The bug does not appear in Edge.

IE9/10/11 do not support the dominant-baseline attribute

dominant-baseline is not supported. You must rely on other methods for vertical positioning.

Microsoft documentation stating non-support: https://msdn.microsoft.com/en-us/library/gg558060(v=vs.85).aspx

No update on direct HTML editing in all browsers but chrome

Only chrome updates the drawn SVG when editing the innerHTML and outerHTML values of an element inside the SVG.

Safari 6 doesn't display self-closing <use>-elements.

There was a bug in the WebKit engine for a short while where elements like <use xlink:href="#foo" /> would simply disappear from the page.

Fix: add a closing tag to <use>-elements, e.g. <use xlink:href="#foo"></use>.

This was a short-lived regression that also affected Chrome (20?) but sadly it was released as part of Safari 6.0 (it worked fine in Safari 5.X). It was fixed again in Safari 6.1.

Transform-Origin Bugs in Almost Every Browser

Most people know about this, and Firefox should have a fix in a few versions, but it's so big and bad that it's worth mentioning: there are tons of cross-browser bugs for Transform-Origin, detailed here https://css-tricks.com/svg-animation-on-css-transforms/

You can avoid them by using the GreenSock API or by using matrix calculations.

CSS filter on <svg> makes it disappear in Safari

Adding a CSS filter property onto an element makes the element disappear. A workaround is to move the CSS filter to a wrapping element.

Linear gradient applied to stroke doesn't appear in Firefox

Pretty annoying.

Safari feColorMatrix doesn't work with external a files

This issue was found in Safari 11.1 and Mac OS Sierra 10.2.6

This example shows a red box three times:

• Box one adds a SVG filter using css to embedd a svg
• Box two adds a SVG filter using an external svg file with css pointing to file and ID
• Box three is the default state

When using a file ( filters.svg ) with the ID's of the filters you cannot do this CSS in safari:

.filter {
  filter: url( "filters.svg#deuteranopia" );
}

You have to embed the svg into the HTML and use this in CSS:

.filter {
  filter: url( "#deuteranopia" );
}

IE renders SVG backgrounds as blurry when computed size has fractional pixel values

All SVG-supporting versions of IE seems to have an issue where SVG as background images become slightly blurry when the size computes to fractional pixel values. It seems IE does some kludgy anti-aliasing.

Example: if the background-size (in either axis) is 1.333333em and the font-size is 15px, the background size computes to 19.9999px, and is rendered blurry. If the font size is 16px and the background-size is 1.25em (background-size computes to 20px), the SVG is rendered crisply.

All other browsers I've tested renders the SVG crisply in both cases.

Last I checked, the issue is still present in Edge, but a bug report has been submitted.

Safari 7 set SVG to height of window when no height set

In Safari 7 (iOS 7) When an SVG has no height set (either explicitly or through CSS), the SVG assumes the height of the window.

Demo: http://codepen.io/justrhysism/full/KpJQEg/
Code: http://codepen.io/justrhysism/pen/KpJQEg/

Injecting SVG spritesheet via ajax in Internet Explorer 11 displays jagged.

Here is a spritesheet: http://codepen.io/anon/pen/zGJJYZ

Looks fine in all browsers with SVG support.

Here is another codepen ajaxing that same spritesheet into the dom: http://codepen.io/anon/pen/MwqBOg

In IE9 and 10 it looks... okay. It seems slightly off the pixel grid and there seems to be some clipping. In IE11 it looks very aliased - almost as if the svgs are being rendered twice on top of one another - just really strong aliasing.

The issue also happens with the ajax demo at css-tricks: https://css-tricks.com/examples/svg-fallbacks/

id="Layer_1"

Hopefully this helps someone:
http://s10wen.com/blog/2014/07/09/illustrator-svg-id-issue/
http://s10wen.com/blog/2014/07/29/illustrator-svg-layer-1-id-issue-take-2/

At the time of writing this still appears to be an issue e.g. https://github.com/WordPress/WordPress/search?utf8=%E2%9C%93&q=layer_1

CSS transitions do not work on IE11

You cannot directly transition styles on an element via CSS in IE11.

Discussion on the issue: https://connect.microsoft.com/IE/feedback/details/920928/ie-11-css-transition-property-not-working-for-svg-elements

Safari reader view doesn’t display inline SVG

Inline SVG seems to always get removed from the content in Safari’s “reader view.” SVG inserted with an <img> tag always works fine, however.

Base tag kills your xlink:href, but only in Firefox

Bug or feature?
When using a base tag in your document you might encounter a special behavior in Firefox. It doesn't render the SVG when implemented via a use tag, because it simply can't find the definition. The use tag references the SVG symbol by using a xlink:href="#svg-id". FF prepends the link with the base tag, other major browsers don't. That's kind of tricky when debugging... ;)