Skip to content

More generic inliner for other asset types (css, js, img): collaboration? #2

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

Closed
marko-knoebl opened this issue Nov 4, 2019 · 3 comments

Comments

@marko-knoebl
Copy link

I've recently created a tiny generic rehype inliner that handles svg, images, css and js:

https://github.com/marko-knoebl/rehype-inline

I'm not sure if any collaboration really makes that much sense as these two are either small or tiny projects. But I just wanted to share that the other project exists and maybe there would be some interest. The main motivation for my project was to create single HTML files that can be downloaded (so network efficiency was not really a concern I wanted to solve).

@JamesMessinger
Copy link
Member

Hi! Thanks for letting me know about your plugin. We have a few small projects where I work that could definitely use your plugin to create single-page HTML files. I'll let my coworkers know about it.

It looks like your plugin handles .svg images by simply replacing the <img> element with the contents of the .svg file. I initially tried the same technique for my plugin, but it turns out that doesn't work for many .svg images. There are several SVG attributes that produce drastically different results when used inside a .svg file versus an inline <svg> element. This is especially the case with optimized SVGs, since svgo assumes that it's optimizing an .svg file, not an inline <svg> element. I ended up having to write several tests to handle various edge cases like that.

Since your plugin isn't focused on inlining rather than optimization, I think a better approach might be to convert all <img> elements (even .jpg, .png, .gif, etc.) into data URIs instead. Data URIs work in all browsers and with all file types (even .svg), and they don't suffer from the weird inline <svg> behavior I mentioned above, because the browser still treats them as though they were external files. The downside of Data URIs is that they tend to be large and ugly, but for your use case that's no big deal. The most important thing is that everything gets inlined into a single file.

I found a few existing projects that use the data URI technique, but none for Rehype:

@marko-knoebl
Copy link
Author

@JamesMessinger thanks for the detailed input!

Based on your suggestion I've already made inlined base64 svgs the default.

I think I'm mostly done working on my generic inliner for now. But if I end up extending it some more I may rebase it on your existing inliner. But for now I suggest closing this issue again and I'll give you a heads up if there's any news on my side.

Thanks again,
Marko

@JamesMessinger
Copy link
Member

Happy to help, @marko-knoebl !

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

2 participants