> Do you think that they will converge on how they interpret SVG?
Not any time soon. The unfortunate truth is that nobody implements the entirety of the SVG spec. It's not even close when it comes to SVG 2. This is a good read on that topic:
> Whenever I receive bug reports for my SVG library, people often use the phrase "my SVG isn't rendering correctly". Which cracks me up every time. There is no such thing as a correctly rendered SVG. As soon as you start using "advanced" features such as text, filters, or, God forbid, animations - it would simply not work. Never. And even if you will manage to make it work, as soon as you try a different render - it will fall apart again.
> The idea behind this "book" is to answer the popular question of "how hard can it be?". A reader expected to have some prior knowledge about SVG, but it should be a fun read either way.
There's a lot of surprises in there for sure. The people crafting the spec seem to have had some peculiar goals that I don't quite understand. Especially all the implicit stuff in path data is surprising to me.
Also, a relative value of stroke-with is "relative to the diagonal length of the current viewbox". This was surprising, but makes a lot of sense when I think about it. And the default unit is %, which also makes sense after some thinking.
Seems like frustrating work, I'm glad the author can channel it into writing :)
For a user, this has been my biggest frustration.
‘300x150 is the default specified in the SVG spec if it isn't specified in the document svg element.’
In practice, this means that some SVGs appear fine in apps that calculates the size in some other manner, but in others that follow the ‘spec’ only 300x150 appears. Safari & Jupyter notebooks for example.
Seriously annoying, but at least I was able to figure out why.
I noticed this when trying to do pixel perfect previews for a client project. There are differences in simple text alignment settings. If you need product previews it might be worth considering server side render to image :-( instead.
The only thing I had problems with (only caring about current versions of Chrome, Fx and Safari) was drop-shadows. Though I guess I am not using particularly advanced SVG features. What made it feel advanced and cool for me is how much I could do with css variables and transitions blended into it.
Though, the mixing of CSS and SVG is also weird.
> In addition to setting attributes on objects, you can also use CSS to style fills and strokes. Not all attributes can be set via CSS. Attributes that deal with painting and filling are usually available, so fill, stroke, stroke-dasharray, etc. can all be set this way, in addition to the gradient and pattern versions of those shown below. Attributes like width, height, or <path> commands cannot be set through CSS. It's easiest just to test and find out what is available and what isn't.
> Note: The SVG specification decides strictly between attributes that are properties and other attributes. The former can be modified with CSS, the latter not.
Not any time soon. The unfortunate truth is that nobody implements the entirety of the SVG spec. It's not even close when it comes to SVG 2. This is a good read on that topic:
https://razrfalcon.github.io/notes-on-svg-parsing/
> Whenever I receive bug reports for my SVG library, people often use the phrase "my SVG isn't rendering correctly". Which cracks me up every time. There is no such thing as a correctly rendered SVG. As soon as you start using "advanced" features such as text, filters, or, God forbid, animations - it would simply not work. Never. And even if you will manage to make it work, as soon as you try a different render - it will fall apart again.
> The idea behind this "book" is to answer the popular question of "how hard can it be?". A reader expected to have some prior knowledge about SVG, but it should be a fun read either way.