Skip to content
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

removes viewBox Attribute #505

Closed
dnnsthnnr opened this issue Feb 25, 2016 · 16 comments
Closed

removes viewBox Attribute #505

dnnsthnnr opened this issue Feb 25, 2016 · 16 comments

Comments

@dnnsthnnr
Copy link

I use gulp-imagemin to optimize svg files. But everytime the viewBox gets deleted even if I explicit define that they shouldnt be removed, like seen below.

imagemin({ svgoPlugins: [{removeViewBox: false}] })

@GreLI
Copy link
Member

GreLI commented Feb 25, 2016

viewBox isn't removed by SVGO by default, so it's some sort of settings error in imagemin.

@bm2u
Copy link

bm2u commented Apr 14, 2016

@GreLI got the same issue with gulp-svgmin. My config looks like:

options : {
            plugins: [
                {
                    removeViewBox: false
                },{
                    addClassesToSVGElement: {
                        classNames: ['svgo']
                    }
                }
            ],
            js2svg: {
                pretty: true
            }
        }

@joaocunha
Copy link

joaocunha commented Nov 15, 2016

For those experiencing this issue, make sure that the viewBox property has proper camel-casing on the source SVG file, otherwise it will get stripped out by svgo.

@GreLI
Copy link
Member

GreLI commented Nov 19, 2016

Sorry, I cannot reproduce. If problem still persist try reduce to minimal test case. E.g.

svgo -s '<svg width="16" height="16" viewBox="0 0 16 16"/>' --config='{ "plugins": [{ "removeViewBox": false }] }'

doesn't remove viewBox, while changing to "removeViewBox": true removes.

@GreLI GreLI closed this as completed Nov 19, 2016
@cinatic
Copy link

cinatic commented Feb 9, 2018

i updated and experienced the same issue with at least this file:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50" width="50" height="50">
    <path d="M 25 3 C 21.7 3 19 5.7 19 9 C 19 12.3 21.7 15 25 15 C 28.3 15 31 12.3 31 9 C 31 5.7 28.3 3 25 3 z M 25 19 C 21.7 19 19 21.7 19 25 C 19 28.3 21.7 31 25 31 C 28.3 31 31 28.3 31 25 C 31 21.7 28.3 19 25 19 z M 25 35 C 21.7 35 19 37.7 19 41 C 19 44.3 21.7 47 25 47 C 28.3 47 31 44.3 31 41 C 31 37.7 28.3 35 25 35 z"/>
</svg>

@GreLI
with config parameter the attribute will not be removed

@GreLI
Copy link
Member

GreLI commented Feb 9, 2018

It is removed by default since v1.0.0, so it's normal.

@benjie
Copy link

benjie commented Oct 31, 2018

(I landed here because my viewBox was being removed. It turned out that juice (npm module) was changing case of viewBox to viewbox, then svgo was stripping it out as noted above. Sharing in case it saves someone a couple minutes head-scratching.)

@patrick-wc
Copy link

patrick-wc commented Feb 8, 2019

I just experienced this issue with an svg which had width="20px" and height="20px" attributes on the <svg> element, before the viewBox attribute (no idea why, I've never seen that before). Removing the width and height attributs meant that the viewbox was preserved. Just FYI

@jonmilner
Copy link

@GreLI using the reduced test case above, if I want to preserve the viewbox but remove the width/height attributes, I would expect this to be the correct approach:

svgo -s '<svg width=\"16\" height=\"16\" viewBox=\"0 0 16 16\"/>' --config='{ \"plugins\": [{ \"removeDimensions\": true, \"removeViewBox\": false }] }'

but the output (using svgo v1.1.1) is the following:

<svg width="16" height="16"/>

Am I doing something wrong? Or is this a bug with svgo?

@johan
Copy link

johan commented Jun 13, 2019

@jonmilner You want those as two different plugin options:

svgo -s "<svg width=\"16\" height=\"16\" viewBox=\"0 0 16 16\"/>" --config='{ "plugins": [{ "removeViewBox": false }, { "removeDimensions": true }] }' 

produces

<svg viewBox="0 0 16 16"/>

@mrwweb
Copy link

mrwweb commented Jul 18, 2019

Hopefully this explanation helps some folks:

  1. It looks like removeViewBox plugin is on by default in SVGO.
  2. Even when it's on, it only removes viewBox if it's redundant with width and height (e.g. `width="X" height="Y" viewBox="0 0 X Y"). Therefore, some viewBoxes may make it through unscathed, making this look more like a bug than intended behavior.

For me, setting it to false and making sure my attributes are camel-cased took care of it.

@iplus26
Copy link

iplus26 commented Apr 3, 2020

Hopefully this explanation helps some folks:

  1. It looks like removeViewBox plugin is on by default in SVGO.
  2. Even when it's on, it only removes viewBox if it's redundant with width and height (e.g. `width="X" height="Y" viewBox="0 0 X Y"). Therefore, some viewBoxes may make it through unscathed, making this look more like a bug than intended behavior.

For me, setting it to false and making sure my attributes are camel-cased took care of it.

mrwweb is right. I'm experiencing the same issue that I need my svg can be scaled in html, removing viewBox and keeping dimensions break the scales.

@samuelgoff
Copy link

samuelgoff commented May 8, 2021

Hello, I believe I'm seeing a regression on this issue, using [email protected], using the following options:

const optimized = optimize(svg, {
    multipass: true,
    removeViewBox: false, // <-- this setting is currently being ignored!
  });

Test case shown below. Note that the viewBox is camelCased appropriately and removeViewBox is set to false, as suggested in discussion above.

INPUT:

<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M0 8C0 3.58172 3.58172 0 8 0H16C20.4183 0 24 3.58172 24 8V16C24 20.4183 20.4183 24 16 24H8C3.58172 24 0 20.4183 0 16V8Z" fill="#3984FD"/>
<path d="M5 9C5 8.44772 5.44772 8 6 8H12C13.6569 8 15 9.34315 15 11V15C15 15.5523 14.5523 16 14 16H8C6.34315 16 5 14.6569 5 13V9Z" fill="white"/>
<path d="M15.5 11.7515C15.5 11.2671 15.6758 10.7991 15.9948 10.4345L17.6856 8.50226C18.1416 7.98108 19 8.30361 19 8.99613V15.004C19 15.6965 18.1416 16.019 17.6856 15.4978L15.9948 13.5656C15.6758 13.201 15.5 12.733 15.5 12.2486V11.7515Z" fill="white"/>
</svg>

OUTPUT:

 <svg width="24" height="24" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M0 8a8 8 0 0 1 8-8h8a8 8 0 0 1 8 8v8a8 8 0 0 1-8 8H8a8 8 0 0 1-8-8V8z" fill="#3984FD"/><path d="M5 9a1 1 0 0 1 1-1h6a3 3 0 0 1 3 3v4a1 1 0 0 1-1 1H8a3 3 0 0 1-3-3V9zm10.5 2.752a2 2 0 0 1 .495-1.318l1.69-1.932c.457-.52 1.315-.198 1.315.494v6.008c0 .693-.858 1.015-1.314.494l-1.691-1.932a2 2 0 0 1-.495-1.317v-.498z" fill="#fff"/></svg>

As suggested in #1128, the current workaround requires disabling the plugin as a default, like so:

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

As you can imagine, this is not ideal.

@TrySound
Copy link
Member

TrySound commented May 9, 2021

Hi @samuelgoff. There was never an option called "removeViewBox". All comments above suggested disabling plugin. In v2 format of plugins was changed though.

@sheremet-va
Copy link

I managed to remove it with:

{
    plugins: [
        {
            name: 'preset-default',
            params: {
                overrides: {
                    removeViewBox: false,
                },
            },
        },
    ],
},

@muesli-dev
Copy link

muesli-dev commented Mar 27, 2024

For those experiencing this issue, make sure that the viewBox property has proper camel-casing on the source SVG file, otherwise it will get stripped out by svgo.

I was banging my head for two hours straight. You saved me, I thought my whole project is cursed.

Just a reminder for everybody else: make sure that the viewBox property has proper camel-casing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests