Svgo: What is the benefit of stripping viewBox?

[rj-coding]

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.

[rj-coding]

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...)",