What is the benefit of stripping viewBox?

[avwie]

Some libraries use SVGO for optimizing the SVG and I notice that stripping the viewBox is almost always used. However, I always disable stripping because it breaks proper scaling of the SVG. Unless I totally don't understand, what is the 'optimization' that stripping a viewBox provides?

[GreLI]

Just as any stripping—minimize number of bytes, increase informational density.

[avwie]

According to your readme:

SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result.

Removing viewBox definitely affects the rendering result, since scaling is then made almost impossible. The question is, why is it turned on by default? It isn't simple meta-data, it is critical viewport information.

[GreLI]

Why? It's removed only when width and height attributes are present and equal to, so no information is lost. Finally, one can turn it off if needed.

[robertknight]

Removing viewBox still affects the rendering output when width and height are present and viewBox is equal to 0 0 <width> <height>.

I encountered this issue when an upgrade to svgo broke rendering of some scaled inline SVGs on our website (https://github.com/hypothesis/h/issues/5656).

The SVGs in question had an outer <svg> element like this:

<svg xmlns="http://www.w3.org/2000/svg" width="120" height="120" viewBox="0 0 120 120">
…
</svg>

And were being rendered with a CSS class applied that scaled them down to a much smaller size (eg. 16px x 16px).

[GreLI]

@robertknight that's incorrect usage, nothing to do with SVGO. Of course if you rewrite width and height, you'll get an error, no matter in which way.

[robertknight]

Please excuse the stupid question, but can you explain what you mean by incorrect usage? My understanding is that viewBox specifies the user-space coordinates which are then mapped to the viewport which has a default width and height controlled by the corresponding attributes on the <svg>, but can be overridden using CSS to rescale the image.

FWIW the original SVG file was produced some time ago by a designer using Sketch.

[GreLI]

SVG is an image which may have properties like width and height. Without viewBox attribute it has value equal to 0 0 width height. So if you change size in any way, you have corresponding result. SVG highly depends on the usage way, so do optimizations. That's is why SVGO is highly configurable.

[flogy]

I have also encountered an issue with this in IE11 as described by someone else here: https://stackoverflow.com/questions/27970520/svg-with-width-height-doesnt-scale-on-ie9-10-11.

When I add the viewBox property with 0 0 width height value it worked fine.

I know we can enable/disable the related plugins to not strip viewBox ourselves but wouldn't it be worth thinking about not stripping the property by default in order to avoid those issues?

[drewbaker]

Just ran into this with SVGO defaults. Seems crazy that by default you break SVG scaling using CSS.

// This won't scale using CSS. This is the default.
<svg xmlns="http://www.w3.org/2000/svg" width="21.001" height="13">

// This will scale using CSS, this is better and should be default.
<svg xmlns="http://www.w3.org/2000/svg" width="21.001" height="13" viewBox="0 0 21.001 13">

[jdahdah]

The viewBox needs to be preserved for inline <svg> elements in HTML to properly scale. Leaving out the viewBox breaks this behavior. I don't know enough about the SVG specification to say if it's supposed to default to viewBox="0 0 width height" or not, but the fact is that this issue is present in the latest versions of Chrome, Firefox and Safari. SVGs need to be inlined for a number of common use-cases, usually for changing colors on hover states or different themes like dark mode.

The fact that SVGO is so configurable is really awesome, but many apps like Image Shrinker use the default settings and don't offer options, ultimately breaking SVGs for anyone wanting to scale them inline.

Please see this CodePen: https://codepen.io/dahdah/pen/YzyjRaw This is a very simple SVG run through Image Shrinker. I've restored the viewBox in one of the copies.

Screenshot:

Please reconsider changing the default value of removeViewBox to false. It's a few bytes more with a significant improvement for web developers on a wide range of tools. And finally, to reiterate on what @rj-coding said:

SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result.

The above example shows pretty clearly that this setting does indeed affect the rendering result, and is not in line with what the SVGO readme promises.

[drewbaker]

@GreLI are you prepared to reconsider this?

[kylirh]

Please change this. I spent a couple hours today digging around to figure out what's going on. The current default is super annoying...

[Naxit]

Same for me, the most used case is scalable svgs that doesn't broke with css. I'm here because I have to modify this weird default behavior and I needed to know how to do it, I see I'm not the only one in this case^^ @GreLI Please reconsider this <3

[mahnunchik]

The same issue...

[mahnunchik]

@GreLI Why this and https://github.com/svg/svgo/issues/505 issues are closed?

[Naxit]

I used the --icon prop that set '1em' to height and width and keep the viewbox, if this can help someone... It did the job for me but it's a weird workaround^^

My package.json command line look like this : build:svg": "svgr --icon --ignore-existing (...more stuff...)",

[woodreamz]

I also agree with you, viewBox is very important for the scaling specially for web developper. In previous versions of svgo, removeViewBox was false by default. You should reconsider setting this option to false by default.

[JohnAlbin]

Given this discussion, I created a PR to remove this plugin from the list of default plugins. #1461

In the meantime, this is the svgo.config.js I am using on my website:

const { extendDefaultPlugins } = require('svgo');

module.exports = {
  multipass: true,
  plugins: extendDefaultPlugins([
    // viewBox is required to resize SVGs with CSS.
    // @see https://github.com/svg/svgo/issues/1128
    {
      name: 'removeViewBox',
      active: false,
    },
  ]),
};

[lzl124631x]

@GreLI viewBox is such an important field needed for scaling SVG images. I'm surprised that we remove it by default just for the sake of "minimizing number of bytes". Let's get https://github.com/svg/svgo/pull/1461 in.

[JohnAlbin]

I've updated PR #1461 to fix a merge conflict.

Now that extendDefaultPlugins has been deprecated, this is the svgo.config.js I am using on my website:

module.exports = {
  multipass: true,
  plugins: [
    {
      name: 'preset-default',
      params: {
        overrides: {
          // viewBox is required to resize SVGs with CSS.
          // @see https://github.com/svg/svgo/issues/1128
          removeViewBox: false,
        },
      },
    },
  ],
};

[GreLI]

I understand the issue, sometimes 'viewBox' is really valuable, but it's not a good idea to dictate disabling default optimization by minority of users. Most users are ok with it and they just don't write here, it's totally ok for them. Probably it's a good idea to disable the plugin in some super-safe preset.

[bencresty]

Working daily with svgs intensively I agree very much with above comments: It's great that svgo is configurable and that we can decide ourselves to enable or disable the stripping of the viewBox attributes. But IMO the most logical setting for this is to NOT stip this setting by default. It just breaks the scaling for lots of svg's. I'm clearly not the only one who thinks like this.

sometimes 'viewBox' is really valuable, but it's not a good idea to dictate disabling default optimization by minority of users

I don't agree at all. The attribute is valuable most of the time, not 'sometimes'. Users who don't complain about this are probably users who either don't use svgo, don't take the time to post a message here, only work with simple svg stuff in an image tag or perhaps even don't know how svg works and that something like a viewBox exists.

[GreLI]

The attribute is valuable most of the time…

While most users

…only work with simple svg stuff…

Don't you see a contradiction here?

It's impossible to conform everyone. Unless you're doing nothing. But that will raise a question too.

[jdahdah]

I understand the issue, sometimes 'viewBox' is really valuable, but it's not a good idea to dictate disabling default optimization by minority of users. Most users are ok with it and they just don't write here, it's totally ok for them. Probably it's a good idea to disable the plugin in some super-safe preset.

With respect, @GreLI, I don't understand your conclusion. One should not need a separate preset to preserve the original behavior of the file. We continue to circle around this topic but at the end of the day, the behavior of SVGO is inconsistent with the promises made in the README. SVGs optimized with SVGO behave differently in browsers from SVGs that have not been optimized. It's destructive, as has been demonstrated in multiple comments above, code samples, PR explanations, etc.

Again, this is what the README says:

SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result.

Not affecting the rendering result is a core feature of SVGO. Removing viewBox affects the rendering result in browsers. Why is this point being ignored?

[GreLI]

Perhaps readme should be updated. SVGO mostly optimize without a visible affect on rendering result. One of the most effective optimizations is reducing float numbers precision. Usually, one will not notice a change. However, it can be seen with extreme zoom. Again, it's not a problem in most cases.

But it's an offtopic. Removing viewBox doesn't affect rendering since an image has dimensions (otherwise it's kept as is). Intervening with this dimensions affects the rendering, not removing attribute itself. So, this is pro-usage like editing tool, which is minority of SVGO usage. I'm afraid people here don't get my point, because they don't like it.

[woodreamz]

Perhaps readme should be updated. SVGO mostly optimize without a visible affect on rendering result. One of the most effective optimizations is reducing float numbers precision. Usually, one will not notice a change. However, it can be seen with extreme zoom. Again, it's not a problem in most cases.

But it's an offtopic. Removing viewBox doesn't affect rendering since an image has dimensions (otherwise it's kept as is). Intervening with this dimensions affects the rendering, not removing attribute itself. So, this is pro-usage like editing tool, which is minority of SVGO usage. I'm afraid people here don't get my point, because they don't like it.

You are wrong, removing the viewBox affects rendering. Please read the viewBox documentation on mozilla and check the example, it's the same svg used three times with three different viewBox, I let you check the result.

Another example was previously shared in the comment https://github.com/svg/svgo/issues/1128#issuecomment-628208565

That's being said, I don't understand why you don't want to reconsider the default value of viewBox, you seems to be stuck on your position but it's your choice and we will live with it :v:.

[lzl124631x]

Removing viewBox doesn't affect rendering since an image has dimensions

I think it affects a lot? If we inline an SVG file and scale it using CSS, the SVG has to have a viewBox property to get properly scaled?

Example: https://codepen.io/lzl124631x/pen/jOwbPXv

SVG = Scalable Vector Graphics and removing the viewBox makes it UNscalable. Maybe we can rename svgo to vgo?

[GreLI]

You are wrong, removing the viewBox affects rendering. Please read the viewBox documentation on mozilla and check the example, it's the same svg used three times with three different viewBox, I let you check the result.

Nope. It has nothing with the issue. Please read all I wrote carefully and thoughtfully.

[woodreamz]

You are wrong, removing the viewBox affects rendering. Please read the viewBox documentation on mozilla and check the example, it's the same svg used three times with three different viewBox, I let you check the result.

Nope. It has nothing with the issue. Please read all I wrote carefully and thoughtfully.

Haha, I read correctly 😄 And you just confirmed that you seems to be stuck on your position...

I'm giving up, no matter how we (not only me) show/explain/demonstrate you that viewBox affects the rendering, you still disagree...

[drewbaker]

@woodreamz I support you. You're correct. Anyone who's tried to actually build a website and scale an SVG knows what you're asking for is correct.