Add macro to inline SVG files

[wout]

Purpose

Adds a macro to inline SVG files at compile time.

Description

SVG logos and icons can be inlined with the inline_svg macro in pages and components:

button
  inline_svg("buttons/round.svg")
end

This will:

• inline the SVG file from src/svgs at compile-time (path configurable with an annotation)
• strip the XML declaration, comments newlines and superfluous whitespace
• optionally (and by default) strip styling attributes so the icons can be styled with CSS (also configurable with an annotation)
• raise a compile-time exception when an SVG file is missing
• add a data-inline-svg attribute with the path of the icon (e.g. <svg data-inline-svg="buttons/round.svg">)

Icons can then be styled with:

[data-inline-svg] {
  fill: none;
  stroke: #222;
  stroke-width: 2px;
}

Or:

[data-inline-svg="buttons/round.svg"] {
  fill: #f03;
}

I realise Lucky does not use annotations a lot, but I think they are helpful in this case. The settings defined by the annotations are reasonable defaults, I think, but if necessary, users can jump in and override the defaults.

This PR implements #1760.

Checklist

• - An issue already exists detailing the issue/or feature request that this PR fixes
• - All specs are formatted with crystal tool format spec src
• - Inline documentation has been added and/or updated
• - Lucky builds on docker with ./script/setup
• - All builds and specs pass on docker with ./script/test

[wout]

Forgot to mention I'll add the necessary documentation on the website as well when this is approved.

[robacarp]

I love this idea. I use a lot of SVGs and have lamented that I can't easily inline them as part of compilation.

[robacarp]

I like that this strips out un-needed stuff from the XML. Should these should_not cases be broken out into an it "strips out comments" and it "strips out the xml header" set of tests? As it is, if something comes up and someone needs to modify the filter, they don't have a test which directly correlates to that feature.

[wout]

Good point. I'll add separate specs for those cases separately.

[robacarp]

Can you help me understand what's going on with these annotations? It seems like a roundabout way to accomplish arguments to the macro.

[wout]

Sure. I think having those parameters passed as arguments would be tedious. Let's say the user wants to use a different directory for the SVG files, then it suffices to override the annotation in an initializer:

# config/svg_inliner.cr
@[Lucky::SvgInliner::Path("src/icons")]
module Lucky::SvgInliner
end

As opposed to (for every single SVG):

inline_svg("menu-social/twitter.svg", false, "src/icons")
inline_svg("menu-social/discord.svg", false, "src/icons")

Does that answer your question? Or am I missing the point?

[robacarp]

Oh interesting, I hadn't considered that. I'm not opposed. Another possibility for this would be to have a Habitat config parameter. @jwoertink @stephendolan thoughts?

[wout]

Tried that first, but settings from Habitat are not available at compile-time. As far as I know, the only way to allow compile-time configuration is by using annotations or constants. And using constants is not favourable because it's impossible to override them.

I think these are sensible defaults, so in 99% of the cases, it wouldn't be necessary to change them. The annotations are just an escape hatch.

[jwoertink]

It's different for sure, but I'm willing to give it a shot. I don't have a strong opinion on it vs just using Habitat.

[robacarp]

@wout yeah, you present a use case I can't argue with. Thank you for walking me through it. Let's go!

[jwoertink]

I think it looks good 👍