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]

@Lucienest I'm disappointed too, that my valid comments are ignored. And that the minority demand changes at the cost of (silent) majority. All that because they can't tune the tool in the way they want. width and height are crucial too, but why you abruptly change them and then cry, the image changed? Remove them and that is not a case anymore. Why are you so stubborn?

[avwie]

@GreLI The problem is not that you are ignored. Your comments are completely invalid. And don’t come with that silent majority and loud minority crap. That is always the case when people file issues and especially for a not well understood feature, as you so elegantly show.

View box is CRUCIAL for rendering accurately. I challenge you to remove ViewBox from the basic example on MDN and try to scale it and say it works. It DOESN'T!

I can't believe that 3 years after I filed this issue I still have to reiterate it, and your own statement:

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.

Why are you so stubborn? You have no valid comments at all. You miss the fundamental understanding of how SVG's and viewboxes work. The fact that we PROVE with examples that it breaks the rendering should be more than sufficient.

@mangelozzi you missed the point. If you change size of SVG, you are essentially editing it. Remove sizes then, in that case viewBox will be preserved. Or configure SVGO to do whatever you want, since you want something different that most people do.

No, this is just not true! It is also impacted by scaling via CSS. Have you even tried it or just assuming?

[JohnAlbin]

@GreLI said:

If you change size of SVG, you are essentially editing it.

and:

width and height are crucial too, but why you abruptly change them and then cry, the image changed?

No one is changing the width and height attributes. You are misunderstanding what we are doing. We are leaving the SVG source exactly as-is after running it through SVGO. We are then taking that SVG source unmodified and adding to a HTML page. The CSS from that HTML page applies to the SVG markup (again, not modified) and the CSS changes the size of the svg DOM element via CSS properties. No source attributes of the svg element are changed at any time.

Please look at the HTML source in the codepen example I posted in March 2021. https://codepen.io/johnalbin/pen/yLggyXv It compares the rendering of one SVG with a viewbox to an identical SVG without a viewbox.

SVG with viewbox:

<div class="shrink">
  <svg width="50" height="50" viewBox="0 0 50 50" xmlns="http://www.w3.org/2000/svg">
    <path d="M25 10C30.263 0 40.789 0 46.053 5c5.263 5 5.263 15 0 25C42.368 37.5 32.895 45 25 50 17.105 45 7.632 37.5 3.947 30c-5.263-10-5.263-20 0-25C9.211 0 19.737 0 25 10z" fill="currentColor"/>
  </svg>
</div>

SVG without viewbox:

<div class="shrink">
  <svg width="50" height="50" xmlns="http://www.w3.org/2000/svg">
    <path d="M25 10C30.263 0 40.789 0 46.053 5c5.263 5 5.263 15 0 25C42.368 37.5 32.895 45 25 50 17.105 45 7.632 37.5 3.947 30c-5.263-10-5.263-20 0-25C9.211 0 19.737 0 25 10z" fill="currentColor"/>
  </svg>
</div>

As you can see, the SVG source is identical in the two examples and all the attributes (including width and height) are the same except for the missing viewBox attribute. But the two examples render differently. The one with a viewBox attribute scales correctly; the one without a viewBox does not scale at all and the image defined by the path is affixed to the top left corner of the svg containing element regardless the rendered size of the svg containing element. In the codepen, I applied a light grey background (with CSS) to the svg elements to make the rendered dimensions of the svg clear.

Specifically, this is the CSS properties that are being applied via rulesets defined in the HTML document:

  width: 25px;
  height: auto;

With a svg viewbox attribute, the browser knows how to scale the image from its attribute-defined 50px width down to the CSS-requested 25px width.

For argument completeness sake, I'll add that we cannot just edit the svg for different sizes because we need to be able to use SVG's ability to scale on the fly. You'll see that the codepen example shows an animation that absolutely requires the SVG viewbox attribute.

[JohnAlbin]

One last thing…

@GreLI said on Jul 18, 2019:

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.

That is incorrect according to the SVG spec.

The SVG 1.1 spec implies there is no default value for the viewBox attribute, but the SVG v2 spec is very clear. The initial value of the viewBox attribute is not 0 0 [width attribute] [height attribute]; the initial value is “As if not specified”.

So removing the viewBox attribute, removes the SVG's ability to “stretch to fit a particular container element”. (SVG 1.1 specification, section 7.7: The ‘viewBox’ attribute)

[GreLI]

@JohnAlbin you missed the point. It doesn't matter whether you change width and height through SVG or CSS. You essentially change the image.

CSS is a part of SVG, especially now. E.g. you can use rgba() colors and many other modern features, despite it's not described in SVG spec. Though it will probably work only in browsers and maybe partially in Inkscape. It was a deliberate choice by spec authors.

Funnily, your second comment proves my point.

[JohnAlbin]

@GreLI You essentially change the image.

No, we are not changing the SVG image. It is literally the SVG markup as it comes out of the svgo tool (depending on which plugins are enabled). You assertion that we are changing the image is false. Applying CSS affects the rendering, but doesn't "modify" the SVG source. You keep repeating yourself without explaining yourself any better. Please try using a different explanation of your argument. I can't follow your logic.

Funnily, your second comment proves my point.

How so? I was simply pointing out that you misunderstood the spec about what the initial value is for the viewBox attribute.

SVGs can only “stretch to fit a particular container element” when they include the viewBox. By removing that attribute, you are removing that feature from SVGs. And many, many web developers use that feature.

[jdahdah]

@GreLI Wait, are you arguing that displaying an SVG at different sizes is changing the image?

What we are asking for: preserve the viewBox by default so an SVG can fulfill its role of being a scalable vector image. This is a requirement for responsive websites, which is nowadays all websites (and not at all a minority).

[mahnunchik]

SVG stands for Scalable Vector Graphics

[avwie]

@GreLI Are you really not aware that scaling the SVG outside of the SVG with CSS is not affecting the base source code of the SVG? How is that changing the image?

[GreLI]

2All. If you change width and height of a usual raster image, it will change. CSS can handle it with various options. Same with SVG. I don't know why you can't comprehend that simple idea. If you use wrong methods you get wrong results. Just use it right. One doesn't use microscope like a hummer, but why you demand such a change?

[jdahdah]

If you use wrong methods you get wrong results. Just use it right.

@GreLI Can you please provide a working example of what you consider to be the correct implementation of an SVG (SVGO default output) on a responsive website where the size needs to change based on different factors like the device viewport or usage context? Ideally based on one of the real-world examples @JohnAlbin or I have provided you with above.

[GreLI]

@jdahdah what do you mean? I don't get the question. Regarding the topic, as I said before, viewBox by default is removed when and only when it equals to "0 0 width height". So, just removing width/height, since the size already get overwritten, will solve the issue. Of course, one can also set their config to configure SVGO plugins.

[mahnunchik]

@GreLI removing 0 0 width height breaks 99% of web use cases.

According to the spec width="width" height="height" viewBox="0 0 width height" is not equal width="width" height="height". Therefore, it should not be removed in favor of size.

[GreLI]

@mahnunchik Of course, that's why I disabled the plugin that did so several years ago (exact opposite to removeViewBox).

In fact it is equal, unless you change width or height some way or another. That thought is hard to get for the most who comments here.

[mahnunchik]

But the plugin is enabled by default.

[avwie]

@jdahdah what do you mean? I don't get the question. Regarding the topic, as I said before, viewBox by default is removed when and only when it equals to "0 0 width height". So, just removing width/height, since the size already get overwritten, will solve the issue. Of course, one can also set their config to configure SVGO plugins.

But sometimes we don't have control over the SVG's in all cases. They are uploaded by clients for instance. I can't just remove width and height. Aside from that, it makes absolutely no sense at all.

Just disable the plugin by default. Is that so hard? It is still enabled.

[GreLI]

@avwie you do have control over SVGO. Just make a config. Is that so hard?

Why do you think you can decide for all users? Most of them want maximum optimisation SVGO can provide.

[GreLI]

@mahnunchik I was talking about removeDimensions plugin. It's not in a default preset. Do you follow?

[wavebeem]

I would argue that optimizations must have a degree of safety. If SVGO "optimized" your SVG by removing half of it, that would not be OK. Users understand that optimizations generally do not perceptibly change the input, at least not with default settings.

I think most people in this thread realize that you can change the configuration. The discussion is around the default setting. Consider that for every 1 person who has shown up here to suggest that this default value is unsafe for the majority of web SVG use cases, probably 1000 other developers saw this thread and decided it was a waste of their time to argue in here.

I don't understand how you can insist that "most" users want to have critical information for web SVG usage removed from their SVGs. It's been demonstrated that this default setting is unsuitable for web development. I've also pointed out that "just" making a config isn't as easy as you make it sound.

That being said, I'm not sure what would change your mind at this point. I feel like we either have to accept as a community that the defaults you want to ship don't make sense for our use case, or start a fork of svgo (a huge undertaking).

I've held out hope for the last 3 years that perhaps you would eventually change your mind, but I think this is just turning into a big waste of everyone's time.

[GreLI]

Yep, the idea about different presets with different levels of safety is floating here for years. E.g. “supersafe”, “average”, and “squeeze it as much as you can”

[wavebeem]

Yeah, C compilers ship with various optimization levels you can enable. It could totally work here too!

[julpat]

This is insane :) Few bytes vs critical attribute. Is it possible at least put this "switch it off" in the readme in examples, so a lot of devs will save some working time when searching why the critical attribute has disappeared? Thanks

[GreLI]

@julpat every byte matters. It's right in the readme under “Configuration” section.

[JohnAlbin]

@GreLI So if we were to have different presets… We need to agree how the removeViewBox affects the SVG so we can determine which preset that plugin can go into. “supersafe”, “average”, and “squeeze it as much as you can”, etc. Right?

Do you agree that the removing the viewBox attribute (even when the SVG has width/height that match the viewBox values) DOES change the rendering of the SVG file? See my comment above on October 24 for an example. If you have a counter example, please provide it.

[GreLI]

@JohnAlbin to be more precise it does change rendering if and only if you are changing image size props (i.e. width or height). Some people make excuse that they doing it via CSS, but that doesn't matter. When you change the image no matter how, its rendering changes. It happens so even with raster image, so disputes here are unproductive. It's like to dispute law of physics. It just works that way.

[mangelozzi]

@JohnAlbin to be more precise it does change rendering if and only if you are changing image size props (i.e. width or height). Some people make excuse that they doing it via CSS, but that doesn't matter. When you change the image no matter how, its rendering changes. It happens so even with raster image, so disputes here are unproductive. It's like to dispute law of physics. It just works that way.

What does the S stand for in SVG?

[JohnAlbin]

it does change rendering

So, your answer is yes. Removing the viewBox SVG property prevents CSS from being able to scale the rendering of the SVG so that it can be resized to fit the SVG's HTML container. As described by SVG 1.1 specification, section 7.7: The ‘viewBox’ attribute

Great. Glad we agree.

Now, can we agree that the removeViewBox plugin cannot be put into a "supersafe" preset?

I would also assert that cannot be put into any web-compatible preset, if one were to be created because the viewBox attribute is absolutely required by standard CSS practices in frontend development.

I don't see any problem with the removeViewBox plugin being put into a “squeeze it as much as you can” preset either. I won't use it, but "squeeze things until they break the web" isn't for me.

Now the question remains of what goes in a "default" preset. I would prefer one that is web-compatible, but that is up for discussion.

[GreLI]

No, you get me incorrect, my answer is no. However, I understand specific cases in which the plugin could be undesirable, but they are not generic ones. Yes, “safe” preset IMO could have it off.

[MoritzLost]

@GreLI If I understand you correctly, you're strongly opposed to using CSS to resize an SVG. So if an SVG has native dimensions of width="800" height="400", the SVG should be displayed at exactly those dimensions on the page. If I want to display this SVG at 600x300, instead of using the existing SVG and changing the size using CSS, I should export the SVG at this exact size. So in your view, putting the SVG with the native 800x400 resolution in my HTML and then using CSS to resize it to 600x300 is bad practice and not supported by SVGO because you consider it an antipattern. Is this correct so far?

In this case, I would ask you how you would handle responsiveness. Let's say the SVG is the site logo that's placed at the top of the page. On large enough viewports, the logo is displayed at the native resolution (800x400) and everything is fine, it works without the viewBox. But on smaller screens, I don't want overflow, so I'll limit the logo to the width of the container (e.g. max-width: 100%).

Without the viewBox, this will result in the logo being cropped instead of having it scale down. This is demonstrated nicely by the examples provided by @JohnAlbin.

Now, you have said multiple times that this is usage is unusual and/or somehow incorrect. But I would argue that this is pretty much the standard usage of an SVG. I can't think of a single example of having a large SVG that should not be responsive, but instead cause overflow or be cropped on smaller screens. And I can't imagine that there's a silent majority that prefers this behaviour over having the SVG scale to the size defined by CSS.

I don't think this is a fringe use-case, either. Almost all sites have some sort of logo. Most logos are simple enough that an SVG will be much smaller than a PNG file. They're small enough that they should be embedded in the HTML instead of loaded externally (by using an <img> tag) – and embedding the SVG is necessary if you want to do any sort of animation with the logo, like changing a fill colour on hover or animating a part of the logo. So almost all sites that have a logo they want to optimize with SVGO will run into this issue.

If I have understood your viewpoint correctly – and please correct me if I got it wrong – how would you solve this issue if not by including the viewBox in the SVG? And if including the viewBox is your preferred solution, wouldn't this make sense to have as a default?

[Lucienest]

@GreLI it's just a simple change that we're asking u to make, this will make SVG's 100% compliant and have no more issues. Happy ending :)

[mahnunchik]

Any news about safe config? What should be the default config according to many people in this discussion.

[woodreamz]

@GreLI it's just a simple change that we're asking u to make, this will make SVG's 100% compliant and have no more issues. Happy ending :)

And the PR is ready since more than one year #1461

Several people have demonstrated the importance of the viewBox, but I think he went too far to admit he is wrong...

[Lucienest]

@GreLI it's just a simple change that we're asking u to make, this will make SVG's 100% compliant and have no more issues. Happy ending :)

And the PR is ready since more than one year #1461

Several people have demonstrated the importance of the viewBox, but I think he went too far to admit he is wrong... 8/

well, unfortunately, that's how open-source project works. if the owner ignores all valid points and sticks with his bias, it won't ever proceed.

we might consider a fork but that's not much preferred. @woodreamz

[GreLI]

@Lucienest Is it really easier to fork than just make a config that will fit you well? Also, the level of discussion here seem like people aren't really involved into open source.

[mahnunchik]

@GreLI just accept the PR https://github.com/svg/svgo/pull/1461/ it makes working with SVG for many developers much easer 😉

[MoritzLost]

@GreLI Did you have a chance to look at my question from a couple of weeks ago?

It feels a bit like you're purposefully ignoring it since you don't have an answer for it. In this case, maybe you could consider if everyone's arguments in here have some merit after all. This discussion seems to be pretty stuck because you don't listen to any arguments. But there's no shame in changing your position if the arguments are in favour of that. In fact, that's all that discussions are about – not winning or defeating everyone else, but finding the best solution. Nobody would think less of you if you decided to change your position and implement the requested change. In fact, everybody here would probably be very grateful since it will make a small aspect of our everyday work much easier. I know I would greatly appreciate it.

[Lucienest]

@GreLI If I understand you correctly, you're strongly opposed to using CSS to resize an SVG. So if an SVG has native dimensions of width="800" height="400", the SVG should be displayed at exactly those dimensions on the page. If I want to display this SVG at 600x300, instead of using the existing SVG and changing the size using CSS, I should export the SVG at this exact size. So in your view, putting the SVG with the native 800x400 resolution in my HTML and then using CSS to resize it to 600x300 is bad practice and not supported by SVGO because you consider it an antipattern. Is this correct so far?

In this case, I would ask you how you would handle responsiveness. Let's say the SVG is the site logo that's placed at the top of the page. On large enough viewports, the logo is displayed at the native resolution (800x400) and everything is fine, it works without the viewBox. But on smaller screens, I don't want overflow, so I'll limit the logo to the width of the container (e.g. max-width: 100%).

Without the viewBox, this will result in the logo being cropped instead of having it scale down. This is demonstrated nicely by the examples provided by @JohnAlbin.

Now, you have said multiple times that this is usage is unusual and/or somehow incorrect. But I would argue that this is pretty much the standard usage of an SVG. I can't think of a single example of having a large SVG that should not be responsive, but instead cause overflow or be cropped on smaller screens. And I can't imagine that there's a silent majority that prefers this behaviour over having the SVG scale to the size defined by CSS.

I don't think this is a fringe use-case, either. Almost all sites have some sort of logo. Most logos are simple enough that an SVG will be much smaller than a PNG file. They're small enough that they should be embedded in the HTML instead of loaded externally (by using an <img> tag) – and embedding the SVG is necessary if you want to do any sort of animation with the logo, like changing a fill colour on hover or animating a part of the logo. So almost all sites that have a logo they want to optimize with SVGO will run into this issue.

If I have understood your viewpoint correctly – and please correct me if I got it wrong – how would you solve this issue if not by including the viewBox in the SVG? And if including the viewBox is your preferred solution, wouldn't this make sense to have as a default?

I think there seems to be a misunderstanding here, SVGO is a tool that is supposed to optimize the SVG by removing the unnecessary metadata/comments that don't affect the SVG rendering.

So, the input and output rendering is expected to be 1:1 but removing the viewBox breaks this promise. If an SVG already has viewBox it means the developer knows what he's doing and well aware of the usage or nuances of the following attribute.

SVGO shouldn't be opinionated here. @GreLI

[GreLI]

@mahnunchik that's what I talked about. People here are not really involved.

@MoritzLost It was discussed several times. If you are breaking image by changing it sizes (by any means: attributes, css properties or whatever), it'd be broken. Just don't do it. Or make a special config for these cases. What makes you think that you can decide for everyone?

[mdmoreau]

@GreLI isn't a primary feature of SVG files their ability to scale? I'm guessing that's where a lot of people's confusion comes from here, as the default viewBox optimizations break that core functionality. Fantastic tool, but I've always wondered why a separate config was necessary to support one of the main features of SVG files.

[MoritzLost]

@GreLI You haven't answered my question though. I have a logo that I want to place on a page as an SVG. Here's a minimal example: https://codepen.io/MoritzLost/pen/wvxvbdV

I've optimized the SVG with SVGO. The first test case is the default SVGO output, for the second one I've added the viewBox attribute again. Observe what happens if you make the window smaller. Without the viewBox, the logo is cropped. With the viewBox, it scales nicely with the window size.

Have you ever put a logo in the form of an SVG on a web page? If so, was your client fine with the behaviour in the first example?

This is a super simple usage, not a special niche use-case or edge-case. Please example to me what I'm missing here.

• Are you saying that putting a logo on a page is a special case for SVGO and should require a custom config to work properly?
• If not, how would you solve the issue regarding the cropped logo with the default output generated by SVGO?
• Or are you saying that the cropping is the correct behaviour?

Are you really sure that SVGs, Scalable Vector Graphics, shouldn't be allowed to scale?

[GreLI]

@MoritzLost ignoring my answers and spamming “You haven't answered” wouldn't get you anywhere. Don't be lazy to think it through. Please, follow GitHub Community Code of Conduct.

[Lucienest]

@MoritzLost ignoring my answers and spamming “You haven't answered” wouldn't get you anywhere. Don't be lazy to think it through. Please, follow GitHub Community Code of Conduct.

You aren't answering our queries properly and saying others to follow the Code of Conduct? I don't see their comments violating CoC either.

[nnmrts]

Whoops, I think this is an upstream issue with the SVG specification. What do you think @GreLI, should we fork https://github.com/w3c/svgwg/ and rename it to NSVG (Not Scalable Vector Graphics) so we finally have a format that matches the goal you apparently have with (n)svgo?

Here is a fork I made, I renamed everything to the newer, more fitting name: https://github.com/nnmrts/nsvgwg

Also feel free to take a look at the latest commit I pushed, changing the behavior of the viewBox attribute so it is in line with (n)svgo's philosophy and your totally acceptable way of acting like this attribute doesn't affect rendering and if it affects rendering it's the user's fault because they are using it wrong _{or in your setup you just don't have access to neither the affected svg files, nor the svgo config used, so you would have to fork or monkeypatch parts of your dependencies to fix "broken" svg files you naively surrounded with CSS styles to make it responsive, thinking the maintainer of a repo with 18k+ stars probably made reasonable decisions to mitigate issues with optimizing and displaying a 20+ year old format in conjunction with even older markup and stylesheet formats - oh my sweet summer child:} https://github.com/nnmrts/nsvgwg/commit/f862750f42410fd3c96c8465e13b45d8ee0f8a72

[wavebeem]

this is a 3.5 year old thread, everyone. i think your effort would be better spent making a fork of svgo and trying to popularize it than posting in here.

posting snarky comments or trying to explain the situation 10 times isn't helping.

[edarioq]

For the sane developer, have your SVGO config ready, create a file that looks like:

module.exports = {
  js2svg: {
    indent: 2,
    pretty: true
  },
  plugins: [
    {
      name: 'preset-default',
      params: {
        overrides: {
          removeViewBox: false
        },
      },
    },
  ],
};

To test, In the CLI run:

svgo --config svgo.config.js *.svg

Customize this file to suite your needs.

[julpat]

@julpat every byte matters. It's right in the readme under “Configuration” section.

I thought to point out in the readme exactly this option removeViewBox which is ruining SVG.

[avwie]

@julpat every byte matters. It's right in the readme under “Configuration” section.

Maybe you should read your own readme file then:

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.

This has been my first issue filed ever on GitHub and boy.... does it keep giving.

[Lucienest]

@julpat every byte matters. It's right in the readme under “Configuration” section.

Maybe you should read your own readme file then:

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.

This has been my first issue filed ever on GitHub and boy.... does it keep giving.

The README is hypocritical, I've pointed this out before but the owner would simply ignore those. I'm so fed up with these, it's not even a breaking change.

[MoritzLost]

@MoritzLost ignoring my answers and spamming “You haven't answered” wouldn't get you anywhere. Don't be lazy to think it through. Please, follow GitHub Community Code of Conduct.

@GreLI You haven't answered, though. I have asked some questions regarding your stance on this issue and some problems I'm seeing with it. You haven't answered a single one of those, but just repeated the same non sequitur about 'changing the rendering' you have used multiple times. I'm not too lazy to think it through. I have written multiple paragraphs to try to understand your reasoning, explain why I disagree and kindly where my reasoning is wrong. You're the one who is not willing to engage at all, instead resorting to short, intellectually dishonest replies. Pointing to the code of conduct because someone disagrees with you is laughable. Why is it so difficult for you to accept that you're wrong?

[Lucienest]

@MoritzLost ignoring my answers and spamming “You haven't answered” wouldn't get you anywhere. Don't be lazy to think it through. Please, follow GitHub Community Code of Conduct.

@GreLI You haven't answered, though. I have asked some questions regarding your stance on this issue and some problems I'm seeing with it. You haven't answered a single one of those, but just repeated the same non sequitur about 'changing the rendering' you have used multiple times. I'm not too lazy to think it through. I have written multiple paragraphs to try to understand your reasoning, explain why I disagree and kindly where my reasoning is wrong. You're the one who is not willing to engage at all, instead resorting to short, intellectually dishonest replies. Pointing to the code of conduct because someone disagrees with you is laughable. Why is it so difficult for you to accept that you're wrong?

he's doubling down instead of acknowledging it.