Is your feature request related to a problem? Please describe.

There are many occasions where it's not possible to see what a glyph/SVG asset actually looks like because its contents are the same color as the background color (as seen above).

Describe the solution you'd like
It would be useful to be able to toggle light/dark background modes.

Describe alternatives you've considered
I've tried to change the background-color style of the boxes using Inspect Element, but that's pretty inefficient.

Additional context
Here's the source of the page where I used the SVG Grabber: https://www.diffordsguide.com/

Tricky feature. Could default to the size it is in the DOM.

As an exercise mainly.

Style the button so they don't look ugly.

Grab the SVGs from a href content on this page: https://commons.wikimedia.org/w/index.php?sort=relevance&search=amazon+.svg&title=Special:Search&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns6=1

Allow users to export PNG images at various sizes from SVG content

I think it would be a better experience to open SVG Gobbler in a new tab instead of in the same one on top of content. I'm conflicted. I believe in keeping people on the page, but it would make it much easier to implement future functionality and I wouldn't have to compete against CSS styling.

Via some type of button that gets surfaced on the page. Right now the page has to be refreshed to start using the site again. It's annoying.

Unoptomized versions of svgs should be available in case they contain stuff the user doesn't want optimized out.

• Export as PNG, JPG
• Rename file before export
• Bring back optimization of SVG and make it an option
• Resize png or jpg before export

I'm going to cover how to work with two types of SVGs:

https://vecta.io/blog/best-way-to-embed-svg/

• Inline
• External (added using , or <iframe> tag)

  it's also possible to add SVGs using the tag and as a background-image in CSS, but neither of these methods allow you to manipulate the SVG with JS (or CSS).

  Inside the SVG itself
  External to the SVG (within the HTML document or as a separate file altogether)

Is your feature request related to a problem? Please describe.
Rarely, but sometimes sites use Base64 to encode the SVGs. SVG Gobbler currently can't grab those.

Here's example of site using Base64 SVGs: https://parsecgaming.com/ (logo at top left and bottom left)

Describe the solution you'd like
Decode Base64 SVGs and show them in SVG Gobbler.

For sites with a ton of icons, loading the promises can take a second. Could be cool to have a loading indicator. Gobble gobble....

Since the last update, many SVGs are listed as 0x0 and don't generate correct previews in the interface despite working correctly previously.

An easy example of this is the charts generated by Google Data Studio, which can be tested against a public dashboard like this:
https://datastudio.google.com/u/0/reporting/1vqvDNQ1bqXhY5awvsW1OOQbjYpTliKAg/page/bnFIB?s=oh1ENMEdT04

In the previous version, output for the main line chart looked like this:

In the current version, it looks like this:

The preview isn't actually blank, but rather just getting the top-left of the chart which happens to be all transparent. This makes it impossible to know which chart you're downloading.

I'm guessing this is probably all related to invalid detection of the size, but definitely a regression from the previous behavior. I've seen this on other sites too, but I'm not sure what the commonality is related to sizing. As you test, you'll see that number of the other elements on the page preview and calculate sizes just fine.

(I was originally hoping to get the time to fix this myself, but it's been seeming like that isn't very realistic with my current work schedule—so here's hoping someone else has the time!)

I mistake font icons for SVGs all the time and might be cool to see a numbered account for how many are on the page.

Would be nice to be able to copy svg to clipboard instead of downloading.

Even though there is a click outside the panels to close, I think it's not implied and a sticky close button will help give users something to aim for and not feel stuck if they miss it when scrolling.

Need a screen to ask why it was uninstalled

Should automatically run the chosen SVG through SVGO minify/cleanup process before exporting.

Might be fun to surface the number of duplicate icons the page contains on the card.

Seems like it would be smarter to filter the SVG array for duplicate icons before making the ajax calls. Need to find the method of determining how the SVGs are identical as the parsed string is being compared atm after the AJAX call.

Describe the bug
Img are not being rendered in sprite instances for exporting PNGs.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://www.reliablesite.net/
2. Try to export PNGs of sprites

Expected behavior
Should be able to see and export the SVGs

Getting asynchronous data between tabs in Chrome extensions is proving incredibly difficult for me. I've resorted to doing a half-second timeout in interim to make sure any fetches can complete before resolving in the new tab, but I'd love to get this hooked up correctly with a promise.

This is a StackOverflow covering how "simple" it is, but I haven't been able to get it to wait.

https://stackoverflow.com/questions/20077487/chrome-extension-message-passing-response-not-sent

There is a generic try catch but it would be a lot more helpful to provide accessible reasons for why the extension isn't working.

SVGO dependency is adding 5mb to the webpack bundle file size. It's too much for Firefox and it's just too much in general. I don't know how to get it down. If I omit the import in download-svgs.js it immediately takes 5mb off the bundle size though. Need help here.

Not currently going into iFrames on webpages and only scanning the outer DOM elements. Should dive into iFrames as well.

Needs UI direction.

Could be fun to assign tags to cards that give insight into attributes that make up the svg. For instance, how it's placed on the page, or if it has a viewbox or width/height.

no idea how to do this

Describe the bug
Refreshing the page using ⌘-R clears the source of SVGs and doesn't rerun the extraction process.

To Reproduce
Steps to reproduce the behavior:

1. Launch SVG Grabber to open a new page with extracted SVG assets
2. Hit ⌘-R
3. See empty page

Expected behavior

1. Launch SVG Grabber to open a new page with extracted SVG assets
2. Hit ⌘-R
3. See page of refreshed assets (including any newly detected assets)

Screenshots
First load:

After refresh:

Desktop (please complete the following information):

• OS: macOS 11.1 (20C69)
• Browser: Chrome
• Version 87.0.4280.88 (Official Build) (x86_64)

Lookin weird:

Surfacing alert icons and messaging for Cors, sprite and symbols. Could be beneficial to separate the style of error at the card level.

Right now SVG that are generated via sprites using the xlink id method is rendering correctly but aren't being exported correctly. The SVG XML is within a closed shadow root and I'm unsure how to get to it.

Could be fun to institute filtering functionality of some kind by:

• Size
• Color
• Animation
• Viewbox
• Hidden

This is an interesting question in particular because if filtering was instituted in this way it would free up a lot of card space. For instance, if cards were filtered by whether or not they are in view then it is implied by one global switch as opposed to individual notation on each card. This actually seems like a better usability approach in general.

Looks bad. Fix it with a border radius.

Need an alert or some type of notification for when no SVGs are found.

The closing mechanism whether by clicking on the x or by clicking on the webpage is too sudden.

There is a more attractive/performant way to load the icon cards into the dom. Would be really cool to facilitate a sequential load with a slight delay.

The SVGO dependency is currently bringing the bundle size from 200kb to over 4mb. Optimizing the SVGs during export is awesome but really need to figure out a way to bring down the bundle size. That's more than 20x the size for one dependency.

Relevant code is currently commented out here: https://github.com/rossmoody/svg-gobbler/blob/master/src/scripts/download-svgs.js

Could be really fun to have a view toggle for different types of views.

• With attributes
• Without attributes
• Large card
• Small card

If an SVG is white, it isn't visible on .gob__card

For reference, this is the SVG that should be shown above:

Happens on this site: https://habitica.com/static/home. Looks like it's inheriting H1 styling.

Set margin-bottom: 0; on .gob__title and .gob__count--title

Would be nice to surface some feedback when errors happen for whatever reason.

Need to bring the accessibility up

It would be nice to have some tests in place to make sure regressions don't happen with functionality.

right now we clean svg xml so it fits better in the container for display but the animated svg could be fun to try to retain

I think this has something to do with not being able to hook onto a body tag in the dom and so Gobbler doesn't fire at all. Could be fun to have a unique experience when a single SVG icon is on the page.

There's a better way to do this than svg-gobbler (1). Could dynamically try to use descriptive parts of the svg