Do I keep trying to fix it, or do I throw it away?"
At some point, I think we need a redesign for vectorgraphics on the web from scratch, as I don't think SVG can really be "fixed" - it is just too complex and weird in the base.
But I guess no one is willing to spend much money on that right now, after the core of svg finally works (mostly).
And since it is there right now and working, it won't go away so fast, as there is no alternative - yet.
So I would keep working with it, but maybe start to collect and share ideas on how to do things nicely from scratch ...
I disagree. This is the classic, let's rebuild it from scratch blackhole. You'd probably end up with much the same spec.
The one thing that does need to be done to svg is to work towards simplifying it and depreciating some of the more edgy features. It's a really broad spec that's complex to implement.
Well, I have to admit, that I can't really name much.
It has been a while(around 6 years), that I researched about it. I remember that I liked the flash - text vector format much more, but it died out, when flash died.
I've done quite a bit, yeah. We make serious use of it in our product [1] so I've had to work with it fairly closely on both the front and backends (have read through the Chrome svg code, along with Skia, Cairo and others). In terms of other declarative 2D formats, I'm also increasingly familiar with PDF too.
Just this last week I fixed a bug in the way Cairo handles stroke-miterlimit (which was called by librsvg). While there I got an appreciation for how exactly the rendering has to take place.
Imagine drawing a stroked line of 2 segments (on any 2D surface), it's the simplest of operations. If you think about it, that's actually an operation in which you have to draw 2 rectangles (one for each line segment) that meet at their tip centres, and then you need to draw the fill (determined by the stroke-linejoin) at the tip (after figuring out which side of the line is the outside). The options are rounded, bevel (just a triangle to fill in the space and effectively square off the join) and miter (draw a diamond to extend off to the full extent of the line). The miterlimit then specifies a maximum ratio you will allow before saying that the miter would extend too far and you'd rather have a bevel (squared off).
Cairo does these calculations in several places for the various backends, but it has code to deal with stroke-linejoins and stroke-miterlimits. PDF has the same sorts of operations, as does Skia / all other 2D libraries.
Now, SVG2 has introduced the notion of miter-clip in which you don't just have the end of the line snap to bevel or miter and instead you can have it cut off somewhere in between.
It's an innocent enough addition, but let's stop and think about the implementation. None of the drawing canvases support it, so you'd have to add it to Skia and Cairo / everything else. Just on the image backend of Cairo, that's a big change. There's a load more calculations that need to happen. But what if the user is using the PDF or Skia backend? Do you just give inconsistent results there if they don't support it, or do you try to simulate the drawing operations to plug in the little extra line-joins to make things look right. Alternatively, librsvg for example could handle it as a special case, use bevels, and add its own calculations to glue in all the extra little caps. At least then Cairo wouldn't have to change. But I've just been down in that code and there's a lot of work in those calculations — you need to track angles of all the line segments, you need to figure out where things start and stop etc. But then Inkscape would need to do something similar, as would Chrome / the Edge renderer etc.
And this is a relatively simple case. See miter-clip in the spec [2]. It's a 1 paragraph definition that results in 1,000s and 1,000s of lines of code to be changed.
Don't get me wrong, I'm not having a go at the spec and I love SVG. It's just that over the last week I've come to appreciate how complex the seemingly simple operation of drawing a line of 2 segments is! It's worth stopping to think about how much work each feature creates.
Do I keep trying to fix it, or do I throw it away?"
At some point, I think we need a redesign for vectorgraphics on the web from scratch, as I don't think SVG can really be "fixed" - it is just too complex and weird in the base.
But I guess no one is willing to spend much money on that right now, after the core of svg finally works (mostly). And since it is there right now and working, it won't go away so fast, as there is no alternative - yet.
So I would keep working with it, but maybe start to collect and share ideas on how to do things nicely from scratch ...