Wasn't XML developed for documents, i.e., text that is mostly words, like technical manuals? Isn't that why an xml file is called an XML document. Seems to me anyone that uses it to store data is using the wrong tool.
SVG: The Good, the Bad and the Ugly
81–90 of 228 posts
Re: SVG: The Good, the Bad and the Ugly
#82Earlier quoted context omitted.
You don't edit raw png values either, with rgb/index values in a list. SVGs are meant to be created and used like any image file. The fact that they are almost human-editable and can be inlined means we are bound to be disappointed when working with them in this manner
I like this kind of compromise where illustrator etc generates the SVG but you can read elements in the actual text so you can animate or transform with css or js. Fir example I recently made this 'hack' for gradient transform. even 'hacking' that was easier than maintaining and understanding complex canvas JS - at least to me. https://4degreesdigital.com
Love it! I'm just wondering, aside from the animation part do you ever need to edit an Illustrator-generated svg?
Re: SVG: The Good, the Bad and the Ugly
#83I thought about migrating Radial Menu [1] to SVG once, after 1 hour fiddling with the code I kinda gave up. What a mess. I remember reading somewhere "if you are coming from canvas programming, you might find drawing a circle counter intuitive" - yeah, I did.
Re: SVG: The Good, the Bad and the Ugly
#84>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…
> "well fuck it, we'll just jam it all into a string.
This is an almost universal disease of people trying to write XML grammars (or database schemas before that). Everyone thinks they can unambiguously decode multiple pieces of data stuffed into the same fixed-width field, and pretty much all of those people are wrong. Over, and over again.
That they never learn is a testament to the developer's ability to make fixing their Kruger-Dunning moments Someone Else's Problem. Get promoted or switch teams before the consequences are unavoidable. You can make an argument that even Tim Bray did this.
There are a lot of reasons XML was never going to succeed, and this is far from the most important, but it's a substantial contributing factor.
Re: SVG: The Good, the Bad and the Ugly
#85Earlier quoted context omitted.
> How is XML a garbage fire? If you decided to go fully XML on " " it would probably look like this: 10 10 90 10 90 90 10 90 10 10 Some would say the fact the designers of XML went for "M 10 10 H 90 V 90 H 10 L 10 10" instead shows they thought XML is too verbose. simias likely agrees that XML is too verbose - and wonders why they used XML at all
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…
> And there weren’t many open-standard extensible general-purpose structured data formats.
The thing is, just having an XML parser isn't enough to parse SVG. You also have to parse a DSL. So I think the argument is "why not just use only a DSL, that does a good job of describing the data model?"
Re: SVG: The Good, the Bad and the Ugly
#86Earlier quoted context omitted.
How is XML a garbage fire? In comparison to what? Also, representing paths succinctly as text is inherently complicated. You're trying to represent a very 2D thing in a linear 1D syntax. It's not a limitation of XML, it's a limitation of text being 1D. XML/SGML are a very effective way of representing tree data (again, non-1D data) in 1D strings. And they're wonderfully extensible, while still keeping a well defined…
> How is XML a garbage fire? If you decided to go fully XML on " " it would probably look like this: 10 10 90 10 90 90 10 90 10 10 Some would say the fact the designers of XML went for "M 10 10 H 90 V 90 H 10 L 10 10" instead shows they thought XML is too verbose. simias likely agrees that XML is too verbose - and wonders why they used XML at all
Alternatively, with SGML:
Re: SVG: The Good, the Bad and the Ugly
#87Earlier quoted context omitted.
How is XML a garbage fire? In comparison to what? Also, representing paths succinctly as text is inherently complicated. You're trying to represent a very 2D thing in a linear 1D syntax. It's not a limitation of XML, it's a limitation of text being 1D. XML/SGML are a very effective way of representing tree data (again, non-1D data) in 1D strings. And they're wonderfully extensible, while still keeping a well defined…
> How is XML a garbage fire? If you decided to go fully XML on " " it would probably look like this: 10 10 90 10 90 90 10 90 10 10 Some would say the fact the designers of XML went for "M 10 10 H 90 V 90 H 10 L 10 10" instead shows they thought XML is too verbose. simias likely agrees that XML is too verbose - and wonders why they used XML at all
Someone complained about JSON above, but I think it does a nicer job here:
{
"path": [
[10, 10],
[90, 10],
[90, 90],
[10, 90],
[10, 10]
]
}
{"path": [[10, 10], [90, 10], [90, 90], [10, 90], [10, 10]]}Re: SVG: The Good, the Bad and the Ugly
#88Earlier 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…
> And there weren’t many open-standard extensible general-purpose structured data formats. The thing is, just having an XML parser isn't enough to parse SVG. You also have to parse a DSL. So I think the argument is "why not just use only a DSL, that does a good job of describing the data model?"
Because then you’d have to define its syntax and extension points. XML and namespaces solve that problem for you, so the only thing left for you to design is the actual structure of your data.
Re: SVG: The Good, the Bad and the Ugly
#89>like to write it by hand
I'm honestly horrified that someone out there is writing SVG by hand.
Re: SVG: The Good, the Bad and the Ugly
#90Earlier quoted context omitted.
> How is XML a garbage fire? If you decided to go fully XML on " " it would probably look like this: 10 10 90 10 90 90 10 90 10 10 Some would say the fact the designers of XML went for "M 10 10 H 90 V 90 H 10 L 10 10" instead shows they thought XML is too verbose. simias likely agrees that XML is too verbose - and wonders why they used XML at all
Someone complained about JSON above, but I think it does a nicer job here: { "path": [ [10, 10], [90, 10], [90, 90], [10, 90], [10, 10] ] } No need for the x and y, really. And it's still quite legible on one line. {"path": [[10, 10], [90, 10], [90, 90], [10, 90], [10, 10]]}
You clearly didn't understand how the path element in SVG works. The M, L and other characters contains valuable information. M stand for move, L for trace a line, but you can also have instructions for bezier curve or Z for closing a path. Your json format by removing this information is useless.