It has a bunch of @font-face definitions at the end of the file. Each font face has an .svg file in its list of sources, referenced using an #id.
For example:
What did I expect?
That postcss-url, which was placed after postcss-svg in my postcss pipeline, to stop complaining about having to inline an entire SVG file (it can't handle SVG fragments).
What happened instead?postcss-url kept complaining. postcss-svg apparently silently failed? (I'm not sure if there's a way to get it to report errors, but I resorted to some good old console.logging to nail this one down).
What do I think happened?
These FontAwesome SVG fonts do not define any viewBox attributes.
What did I do? I was trying to run
postcss-svg
over a FontAwesome.css
file (see https://use.fontawesome.com/releases/v5.8.1/css/all.css for an example).It has a bunch of
@font-face
definitions at the end of the file. Each font face has an.svg
file in its list of sources, referenced using an#id
. For example:What did I expect? That
postcss-url
, which was placed afterpostcss-svg
in mypostcss
pipeline, to stop complaining about having to inline an entire SVG file (it can't handle SVG fragments).What happened instead?
postcss-url
kept complaining.postcss-svg
apparently silently failed? (I'm not sure if there's a way to get it to report errors, but I resorted to some good oldconsole.log
ging to nail this one down).What do I think happened? These FontAwesome SVG fonts do not define any
viewBox
attributes.When rebuilding the SVG fragment, there is an attempt to copy the viewBox to the new SVG document: https://github.com/Pavliko/postcss-svg/blob/ad46505e3b20a84734ff6ed786341f2019a0c596/src/lib/element-as-data-uri-svg.js#L16
I think in this case the
viewBox
is then ending upundefined
, which means a later attempt to calltoString
on the attribute falls over.I was able to validate this by appending
|| ""
to the line above, which caused everything to then work as I expected.