I recently had to decide between using Canvas or SVG on a project involving animation in the browser. I wanted to use a reactive framework (VueJS to be specific) and went with SVG for that reason. Pieces of the overall image are stored as Vue components. Animations become as simple as vue bindings in an element. A comparative Canvas build out would have been considerably more complex making it more difficult to manage. The trade off was performance loss. You can only manipulate so many pieces of an SVG before you get a drop in framerate. But, for my project, the reduction in code complexity seemed worth it.
SVG: The Good, the Bad and the Ugly
161–170 of 228 posts
Re: SVG: The Good, the Bad and the Ugly
#162Earlier quoted context omitted.
I have worked with XML since it was a wee laddie. I generally prefer using JSON, but all my SDKs emit BOTH XML and JSON (and, occasionally, CSV). XML Schema is the main reason I use XML. I hate Schema. Hates HAAATESSSS NASSSTY SSSSCHEMA..., but it is ironclad. If it is described in Schema, then it is guaranteed (or not; in which case Schema also accounts for that). JSON Schema is a non-starter. No one ever seems to u…
I think, when developers don't like working in XML, it's because the tool forces them to do the job properly . That's work for whoever is producing the document, but wonderful for all the consumers.
> I think, when developers don't like working in XML, it's because the tool forces them to do the job properly.
The flip side is that you will never find a JSON with the structure "{ "zoom": "startZoomMarkup" }5{ "zoom": "endZoomMarkUp" }".
Re: SVG: The Good, the Bad and the Ugly
#163> A good idea would be to develop a simple vector graphics exchange format
Ah yes, good ol' https://xkcd.com/927/
Re: SVG: The Good, the Bad and the Ugly
#164Article mentions svg supports tag... Coolest use of it: https://www.xul.fr/svgtetris.svg
Oh man. Way back in the long long ago I worked at Adobe. I was a test engineer on the SVG tag, mostly making sure that the DOM methods all worked properly. Lots and lots of interesting micro-projects there.
The one I was proudest of was a 3d chemical viewer where you could grab the molecule and spin it. SVG was only used because it was convenient to do the visualization. All of the 3d transforms were done in Javascript. But to have Javascript that could fluidly spin a 3d model was pretty amazing in 2000.
Re: SVG: The Good, the Bad and the Ugly
#165>Furthermore the XML-based syntax is pretty ugly and needlessly verbose. It’s tiring to write by hand and just as tiring to parse or generate automatically. What's even worse is that because XML is a garbage fire of a format, SVG actually builds its own micro-DSL to work around limitations. So for instance you have something like: Ok, fair enough. Readable, self-describing. But then you have: Oh. You can almost hear…
> Oh. You can almost hear the designer saying "well fuck it, we'll just jam it all into a string. I'll throw in my 2 cents here because the responses aren't addressing why the path descriptors are stylised in this way. Whether SVG's underlying document format was XML, JSON, SGML, CSS or whatever is irrelevant. However else you did it, any alternative would be more verbose because the 'd' tag already offers the most c…
I'll reference you to a comment elsewhere in the tree, and its parents[0], which came up with this s-expression:
(path (M 10 10 H 90 V 90 H 10 L 10 10) :color red)
Re: SVG: The Good, the Bad and the Ugly
#166Earlier quoted context omitted.
> Oh. You can almost hear the designer saying "well fuck it, we'll just jam it all into a string. I'll throw in my 2 cents here because the responses aren't addressing why the path descriptors are stylised in this way. Whether SVG's underlying document format was XML, JSON, SGML, CSS or whatever is irrelevant. However else you did it, any alternative would be more verbose because the 'd' tag already offers the most c…
I wonder though why does that matter for a web format that can be served with GZIP encoding? Wouldn't GZIP eat the duplicative tags for breakfast? It would be so much easier to write, read, manipulate and animate.
Let's imagine for a moment that path instructions could be mapped out with more verbose instructions. Would this really get enough practical use to be worthy of standardisation?
For the most part, SVG path outlines are almost always defined in software like Illustrator and Inkscape. Bezier curves are beyond the average person's ability to create or modify without visual aids. Simple path constructs aren't all that common in practice and the examples I see posted here aren't representative of real-world use.
SVG does provide transform capabilities to move, rotate and scale paths easily, and those features can be applied within a text editor. For anything else there are plenty of visual tools to aid path modification. Personally I've modified many an SVG file manually, but when it comes to the paths I can't say that seeing them laid bare would be of a help to my workflow.
Re: SVG: The Good, the Bad and the Ugly
#167Earlier quoted context omitted.
Because it was popular, especially in web-development-adjacent circles back then. And there weren’t many open-standard extensible general-purpose structured data formats. (There are a few more now, but still not that many.) JSON technically did exist (as a subset of JavaScript), but it wasn’t until Crockford named it that it became widely known. And it’s not like XML has no good ideas in it either. You may disagree a…
> Also, your example is rather strawman-ish: there is no point in using separate elements for individual coordinates, and anyone designing the format would know this. You say that - but here's some real world XML from the widely used 'GPX' file format[1] 4.46 2009-10-17T18:37:26Z The truth is I could have put the X coordinate as an attribute and the Y coordinate as a child element and it would still have been a fair…
Fair enough. But SVG was defined by the W3C, the very same organisation that standardised XML itself. If anyone, they would know what they’re doing.
Re: SVG: The Good, the Bad and the Ugly
#168W3C is defining SVG Native [1], which is a subset of the full SVG spec. The plan is to use it in font files and it should be a nice format for native apps. It removes support for CSS, the style attribute and lots of extra syntax. Even the XML parsing is made simpler by not requiring support for XML entities. Compression with gzip should create fairly small files. By reusing the SVG format, it is still compatible with…
> W3C is defining SVG Native [1], which is a subset of the full SVG spec. Cool, that's only the third time they do that (after Tiny and Basic).
It's even less than Tiny (= no CSS). I wrote some SVG manually recently and in my opinion SVG is quite fine for that purpose.
Re: SVG: The Good, the Bad and the Ugly
#169Earlier quoted context omitted.
> Oh. You can almost hear the designer saying "well fuck it, we'll just jam it all into a string. I'll throw in my 2 cents here because the responses aren't addressing why the path descriptors are stylised in this way. Whether SVG's underlying document format was XML, JSON, SGML, CSS or whatever is irrelevant. However else you did it, any alternative would be more verbose because the 'd' tag already offers the most c…
I'll reference you to a comment elsewhere in the tree, and its parents[0], which came up with this s-expression: (path (M 10 10 H 90 V 90 H 10 L 10 10) :color red) It's legitimately hard to beat sexprs for the combination of compactness, generality, and ease of use. If I were to start from first principles in making a vector graphics format, I'd probably make it a schema over EDN. I bet the extra complexity of having…
I think that's reasonable, but is syntactic sugar really going to help you modify a path when the vector points will look more like this in reality:
(path (M 368.296, 1.514) (c -0.908, 0 -1.818, 0.011 -2.716, 0.021)
(c 0.053, 0, 0.106, 0, 0.159,0) (c 147.196, 0.836, 265.306, 94.672, 267.029, 183.784)
(c 0, 0.581, 0.065, 35.087, 0.065, 35.087) (h 49.415)
(v -33.471) (h 37.094) (v -31.376)
(C 719.342, 77.099, 575.826, 1.514, 368.296, 1.514)
(z))Re: SVG: The Good, the Bad and the Ugly
#170These are all things I’ve been thinking about, as I am currently writing an svg-like language specifically for UI designers. What he said about languages for humans vs machines is so true; it’s a difficult question to answer.