New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internet Explorer/Edge discards part of the decimal precision #142

adgoncal opened this Issue Feb 9, 2016 · 9 comments


5 participants

adgoncal commented Feb 9, 2016

IE/Edge seem to ignore anything after the second decimal place on a percentage background position. Is there an option in svg-sprite to use pixel units instead of percentage?

I just noticed that IE and Edge do not display the sprites correctly. I noticed it when I had a button that changed the sprite icon on hover.

Searching the web I found an issue on stackoverflow that explains the problem:

it seems IE ignores anything after the second decimal place.

So percentage background position does not work well in IE. Using percentage units is one of the best features in svg-sprite, but if IE/Edge need to be supported, it seems necessary to use pixel units instead. Is there an option in svg-sprite to use 'px' instead?

Note: I searched for similar issues, but did not find any so I created this one. If this is a duplicate of an existing issue, I apologize.


This comment has been minimized.


jkphl commented Feb 9, 2016

@adgoncal Thanks for reporting — but that's a real bummer. :(

svg-sprite used to use absolute positions (i.e. pixels), but there's no such option anymore. Of course one could use an alternative rendering template making use of the absolute values (they are still available as variables in the templates), but it's going to be a major PITA.

If I understood the problem correctly, an alternative approach would be to create the sprite such that all positions are full percentage value, right? This would possibly increase the sprites overall dimension a little, but that wouldn't matter as long as it's only SVG (it would matter a little for node-iconizr, but support for IE / Edge is probably more important).

In any case, really solving this issue will require some time — which I currently don't have, unfortunately. I'll keep this open and try to work on it as soon as I can. Thanks again for reporting.

@jkphl jkphl added the bug label Feb 9, 2016

@jkphl jkphl self-assigned this Feb 9, 2016


This comment has been minimized.

aarondail commented May 16, 2016

FWIW you can supply a custom template to use pixels rather than percentages.

Here is my config:

var svgSpriterConfig = {
  mode: {
    css: {
      dimensions: true, // This causes the library to emit a single css class per sprite rather than two
      render: {
        css: {  template: path.join(__dirname, 'sprite.css.custom.tmpl') }

And the custom template file (sprite.css.custom.tmpl) I created:

This is a mustache template file.

It is a COPY of the css mustache template that is part of svg-sprite.  With a tweak :)

Specifically, it is a copy of this file: node_modules/svg-sprite/tmpl/css/sprite.css

The only tweak is:

* The original uses position.relative.xy, we have changed it to be position.absolute.xy.
  This causes the generated CSS to use pixles instead of %s for background positions.
  E.g. "10px 32px" vs "6.6371681415929205% 39.647577092511014%"

  We want to do this for two reasons:
    * Not a huge deal, but (IMHO) its easier to understand the pixel coordinates.
    * It seems like there are less two-almost-identical-sprites-rendered-differently-by-one-pixel-at-various-zooms
      issues between browsers if we use pixels.
{{#hasCommon}}.{{commonName}} {
    background: url("{{{sprite}}}") no-repeat;

{{/last}}{{/selector.shape}} {
    {{#hasCommon}}background-position: {{position.absolute.xy}};{{/hasCommon}}{{^hasCommon}}background: url("{{{sprite}}}") {{position.absolute.xy}} no-repeat;{{/hasCommon}}{{#dimensions.inline}}
    width: {{width.outer}}px;
    height: {{height.outer}}px;{{/dimensions.inline}}

{{/last}}{{/selector.dimensions}} {
    width: {{width.outer}}px;
    height: {{height.outer}}px;


This comment has been minimized.


jkphl commented May 16, 2016

Thanks for sharing your custom template, @aarondail. This might help others quite a lot!

However, please bear in mind that using pixels instead of percent will make your sprite shapes "non-responsive" — they will be tied to their original dimensions (respectively the generated ones) and you won't be able to style them via CSS to have different dimensions (e.g. background-size: 100% auto isn't possible anymore without all shapes shifting ...). In fact, switching to relative positioning was the improvement between svg-sprite < 1.0 and > 1.0. Just wanted to add this as a kind of reminder — you won't be affected if you use the shapes in only one dimension.

I will try to cater for the precision problem in a later release.


This comment has been minimized.

aarondail commented May 18, 2016

Ahh, good to know! I hadn't realized that.


This comment has been minimized.

Chehow commented Nov 21, 2016


Any news with this issue?


This comment has been minimized.


jkphl commented Nov 25, 2016

@Chehow Sorry, no news yet. Due to massive overload I won't be able to work on svg-sprite at least until the end of the year. Thanks for your understanding.


This comment has been minimized.

eugef commented Mar 2, 2017

Hi @jkphl, any chance that this story would have a higher priority?


This comment has been minimized.


jkphl commented Mar 2, 2017

@eugef I'm planning to do a major rewrite (including a fix for this bug) for a long time now, but unfortunately im swamped with tasks and completely overloaded these days which won't change at least until end of March. With a bit of luck I might work on svg-sprite then again. On another note, please feel free to send in a PR with a solution!


This comment has been minimized.

eugef commented Mar 2, 2017

@jkphl I'd like to, but don't feel confident to dig into.

BTW, the workaround that we are using - is to add 1-2px padding around each icon in the sprite. Then effects of the issue are not so visible - the icons can be still shifted, but at least they are not truncated or part of next icon is not shown.

@jkphl jkphl referenced this issue May 30, 2017


Retina problem? #225

@jkphl jkphl added this to the 2.x milestone May 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment