Vite doesn't inline SVG assets

[andylizi]

vite/src/node/build/buildPluginAsset.ts

Lines 60 to 63 in 480367b

	if (!id.endsWith(`.svg`) && content.length < Number(inlineLimit)) {
	url = `data:${mime.lookup(id)};base64,${content.toString('base64')}`
	content = undefined
	}

Hi. I noticed that svg files is explicitly excluded in the assetsInlineLimit feature, and I'm wondering why that is so. Renaming the extension to .SVG (thus bypassing the .endsWith check) works fine in my project.

This limit exists since the first time the feature was added, and I'm unable to find any kind of comments or documentation about it. Could someone shed some light on this please? Thanks!

[underfin]

Look like !id.endsWith(.svg) should be removed.. @antfu @aleclarson what do you think?

[aleclarson]

We don't want to use base64 with svg files. See here: https://css-tricks.com/probably-dont-base64-svg/

Basically, base64 is larger in size, and svg files don't need it to be inlined. In fact, svg files even compress better without base64, because there's more repetition.

If svg files aren't inlined currently, they should be. Just without base64.

[underfin]

@aleclarson Thanks for yor clarify.

[andylizi]

Are there plans to support inlining svg without base64?

[underfin]

Are there plans to support inlining svg without base64?

Can you open a new issus to discuss it?

[polarathene]

Basically, base64 is larger in size, and svg files don't need it to be inlined. In fact, svg files even compress better without base64, because there's more repetition.

"compress better without base64", everything does.... base64 is an encoding useful for content like binary which can't be represented in ASCII/UTF-8 text content, but has a drawback of 6 bits for every 8-bits, roughly 1.33x increase in weight.

Inlining content via a base64 data URI still has it's benefits despite this.

---

What you're referring to is inline SVG element, which isn't always appropriate (eg favicon).

In some cases you need more accurate / crisp rendering and need the SVG content to be the src of an <img> element instead. As img is a replaced element, it has some drawbacks vs inlining SVG into the DOM, however if you're scaling the content, it will be properly buffered into pixel width/height even if it'd otherwise be a floating point value. I've had this with logos that involve some vectorized text which suffer aliasing issues at certain scales on low DPI displays as there is no shape hinting.

You can workaround that by providing an integer width/height, but you must know that in advance and it comes with some other disadvantages if you want responsive content. Additionally the img element allows providing the alt attribute which has value beyond screen readers (more so if the file isn't inlined/embedded but remains an external file reference).