b64: Add svg to list of supported extensions

[mtdcr]

Tested and works fine.

[facelessuser]

It's not really the ideal way to embed SVG, but I guess it does work. You'd almost be better off embedding the SVG raw as it would be smaller in size than being converted to base64. There are other ways to minimize SVG and embed them.

[facelessuser]

We'd probably need tests for this if we were to accept it, but I'm honestly not sure how I feel about embedding SVG with Base64 as it just increases the size even more. Especially when you don't need to base64 SVG.

[mtdcr]

Of course size increases with base64, but it does increase for png, too. It's surprising for a user if some formats get inlined and others don't. There's no other plugin that inlines svg img tags currently, AFAICS. I don't have control over the types of images used in my application or how they get embedded. I'd just like to inline them.

There already are tests for png covering the blob-to-base64 aspect, and none for the other supported file types. I don't expect any difference at all. Which aspect would you like to get covered?

[mtdcr]

See also https://stackoverflow.com/a/21626701 for funny problems arising when trying to avoid base64-encoding svg in data uris.

[facelessuser]

but it does increase for png, too.

Yeah, but you can't embed a PNG directly without base64, that's why it's a fine option. For this reason, I considered a general-purpose extension to replace them, a general-purpose image embedding extension: #862.

With that said, less desirable doesn't mean undesirable 🤷🏻.

There already are tests for png covering the blob-to-base64 aspect, and none for the other supported file types. I don't expect any difference at all. Which aspect would you like to get covered?

I guess that's a fair argument 🙂.

[facelessuser]

I'll probably let it go in. Even if we do this better in a future extension, there isn't really a reason to not allow it here.

[facelessuser]

@gir-bot lgtm