Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SVG: The Good, the Bad and the Ugly

eisfunke.com

Post reply on HN
Print view View original

41–50 of 228 posts

Re: SVG: The Good, the Bad and the Ugly

#41

Post by kumarvvr »

exabrial wrote: post #11

> Maybe JSON-based, definitely not XML-based No. Strong schemas are _why_ it's supported across a multitude of platforms. JSON because "it's got JSON, what plants crave" is an absolutely dumb argument. And the see article "parsing JSON is a minefield". I can't think of a way to make the standard worse than re-implementing in JSON. There are some legit missing features from SVG as other commenters have pointed out. To…

JSON is a really poor format for anything but simple data.

XML may be verbose and not readable, but it is an excellent format for describing and storing data.

One alternative for SVG could be an SQL table like datastore, similar to sqlite. I would love yo have the ability to query data, rather than parse through XML. I do understand that transferring such data blobs over networks is an issue.

Re: SVG: The Good, the Bad and the Ugly

#42

Post by Symbiote »

ChrisMarshallNY wrote: post #36
exabrial wrote: post #11

> Maybe JSON-based, definitely not XML-based No. Strong schemas are _why_ it's supported across a multitude of platforms. JSON because "it's got JSON, what plants crave" is an absolutely dumb argument. And the see article "parsing JSON is a minefield". I can't think of a way to make the standard worse than re-implementing in JSON. There are some legit missing features from SVG as other commenters have pointed out. To…

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.

Re: SVG: The Good, the Bad and the Ugly

#43

Post by Eisfunke »

gibolt wrote: post #38
simias wrote: post #15

>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…

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

Yes, but SVG is not good as a machine-focused format as well, that's kind of the point.

Re: SVG: The Good, the Bad and the Ugly

#44

Post by colllectorof »

simias wrote: post #15

>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…

Can't wait for the improved JSON version:

   {"path": {"d": ["M", 10, 10, "H", 90, "V", 90, "H", 10, "L", 10, 10]}}

Re: SVG: The Good, the Bad and the Ugly

#45

Post by cdrini »

simias wrote: post #15

>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…

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 schema. Is there an alternative language that is better? How is it better?

Re: SVG: The Good, the Bad and the Ugly

#46

Post by dillondoyle »

gibolt wrote: post #38
simias wrote: post #15

>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…

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

Re: SVG: The Good, the Bad and the Ugly

#47

Post by cpill »

ChrisMarshallNY wrote: post #36
exabrial wrote: post #11

> Maybe JSON-based, definitely not XML-based No. Strong schemas are _why_ it's supported across a multitude of platforms. JSON because "it's got JSON, what plants crave" is an absolutely dumb argument. And the see article "parsing JSON is a minefield". I can't think of a way to make the standard worse than re-implementing in JSON. There are some legit missing features from SVG as other commenters have pointed out. To…

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…

what's wrong with BNF? as a language descriptor it's simple and concise, isn't it?

Re: SVG: The Good, the Bad and the Ugly

#49

Post by city41 »

nness wrote: post #28
Jestar342 wrote: post #22

Recently switched from SVGs to PNGs because the toolset the designers are using means every SVG has the same HTML ID attribute value. So when rendering >1 SVG on a page, they all render the same as the last one in the dom.

Magnifying the SVG as part of the workflow, svgo for instance, is a life-saver for all these edge-cases.

Especially considering the svg that a design tool produces is often gigantic. FWIW I have found svgcleaner to be better than svgo. svgo seems to have more bugs and chokes on svgs more often in my experience.
Post reply on HN