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

151–160 of 228 posts

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

#151

Post by UncleEntity »

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…

> If anyone wants REAL pain, then we should go back to BNF...

Ironically, if one wants to implement a SVG reader they have to use the BNFs provided in the spec (for paths and whatnot).

Though the SVG 1.1 DTD is pretty nice to work with, I've built a SVG DOMish generator for both c++ and python (which takes forever to compile) so one, err...me, doesn't have to deal with all the underlying XML craziness. One of these days I'll get around to finishing the path parser, color parser, transform parser, &etc...

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

#152

Post by qwertay »

hctaw wrote: post #8

SVG is another chapter in the long and storied history of engineers attempting to the question, "How hard can 2D graphics be?" And if you look at the industry standard answers (from PostScript to AutoLisp to Gerber to SVG) the answer is, "pretty damn hard." I don't know if you can slim down vector graphics successfully. Every SVG renderer in existence slims down SVG to some degree. The ones that do it the most are us…

I have to wonder if the author is not understanding the hidden complexity of rendering graphics. They make the claim that svg would take over a month to implement which sounds accurate, but then they claim that it could be replaced with a new format which could be implemented in a few days.

Surely SVG does not include months of work which is entirely useless. What features are we giving up for this simplicity?

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

#153

Post by agleason »

I think this article totally misses out on the UI/UX benefits of an SVG. For example, I've been able to implement amazing animations that require little effort from me and allow designers to really show off their talents.

SVGs may not be perfect, but the pros definitely outweigh the cons. When I work on the frontend, I think there are very few use cases where I have to worry about the readability of an SVG. The author also kind of lost me at JSON-based graphics.

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

#154

Post by Groxx »

qwertay wrote: post #150
Groxx wrote: post #95

Earlier quoted context omitted.

One's a dictionary (unordered, simple unique keys), and one's a list (ordered, arbitrary contents, no uniqueness constraints). Schemas may enforce more, but those are the intrinsic qualities. I agree that use varies widely, but the difference is fairly clear. The existence of nonsense doesn't mean one can't make good decisions.

Is it more logical to have a point tag which has the attributes x and y or have x and y as their own tags and values? Its not clear to me which makes more sense and it seems the spec writes using xml didn't know either.

since x and y are simple names, have simple values, and are unique pairs that apply only once to a point: attributes.

to use anything else means relying on an arbitrarily-complex custom schema rather than the much-simpler-and-far-more-standard schema of the language itself. similar to how we use datatypes in programming languages rather than just strings everywhere. both work! one is clearly giving up a lot, and gaining little.

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

#155

Post by gugagore »

lolinder wrote: post #145
michaelt wrote: post #141

Earlier quoted context omitted.

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

These are still examples of crappy DSLs that use XML syntax, not specific problems with XML itself. Designing good DSLs is a hard problem, but is it any less hard in JSON or YAML? If so, it would be helpful for me if people could provide specific examples of why XML itself leads to poor DSLs. As it stands, I'm left wondering if there are so many bad XML DSLs simply because XML is (has been) a popular format.

Pertinent to this specific discussion is that XML distinguishes syntactically between "elements" and "attributes", but it's often not clear what the purpose of the distinction is (search for "elements vs attributes").

JSON and YAML do not make such a distinction.

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

#156

Post by gugagore »

wtetzner wrote: post #85
pwdisswordfish6 wrote: post #71

Earlier 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?"

The boundary where the XML ends and the DSL begins is at least a little arbitrary, but it does have important ramifications. By using XML, you can use the XPath query language to index down to a `path` (the end of the XML), but not within a `path` (the beginning of the DSL). That means, at least conceptually, you can attach colors, and events, and such to a path. And the fact that you cannot do it within a path (not without introducing a query language for the DSL) is inelegant, but also might not have much bearing in 99% of applications.

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

#157

Post by hnmullany »

One person's bloat is another person's feature. Most of the "bloat" and inconsistent support issues in SVG are in SVG text, filters, animation and DOM interfaces. You don't run into those if you're doing the basic drawing that the OP wants to create. Basic SVG drawing is very straightforward and honestly, quite compact with lots of shortcuts and sensible defaults. (except for markers - which are craptastic).

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

#158

Post by zzo38computer »

For writing your own graphics in text format, I think that PostScript is good; you could then make the output in whatever wanted format (which can be raster or vector formats), if you have a driver to do so. But if you want storage of vector graphics as the result, different formats will be needed, and I think that PDF and SVG aren't very good, and neither is PostScript (which is a programming language, not a vector graphics format, although it is a programming language for vector graphics).

Ghostscript does not have a SVG output driver, although you could first output to PDF, and then use another program to convert PDF to SVG. If they make SlimSVG or other vector formats, then hopefully a Ghostscript driver for that format could be provided, in order that it would be possible to produce it from PostScript programs.

You could then produce SlimSVG or whatever other format using whatever programming languages you wanted, whether PostScript, Haskell, or something else.

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

#160

Post by colejohnson66 »

SigmundA wrote: post #77
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.

Just use img tags pointing to SVG's?

JavaScript based manipulation of the SVG’s nodes doesn’t work then.
Post reply on HN