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

21–30 of 228 posts

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

#21

Post by intrepidhero »

> Decide whether a language is for humans or for machines and do one of those things. And do the one thing well instead of both, but badly.

The thing is all these languages (ASM, C, XML, JSON, Python, etc) are fundamentally about communication between a human and a machine. We make tradeoffs between making them easy to parse (for the machine) or easy to read and write (for the human) but they all must address both needs. And when you have a problem domain as large as "2D Vector Graphics" or worse, "The Web", complexity is unavoidable.

I'm not saying we can't do better than SVG. I agree with many of the author's points and would love to see a minimal subset of SVG that is easy to write by hand. The tradeoffs are engineering decisions and important. But don't pretend that you can pick a goal such as, "easy for humans" and ignore all the other dimensions of the language design problem.

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

#23

Post by tannhaeuser »

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…

Agree a vector graphics format isn't the use case for markup languages. SVG's saving grace, though, is that's designed to be embedded in HTML.

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

#24

Post by kgwxd »

marcodiego wrote: post #2

Article mentions svg supports tag... Coolest use of it: https://www.xul.fr/svgtetris.svg

Is that an example of SVG including a script tag or just manipulating the SVG DOM through javascript? I think that's 2 separate concerns. Browsers already understand both, I think the article puts it under "The Bad" category because if you're building a renderer from scratch, you'd need to also handle javascript and DOM stuff.

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

#25

Post by jerf »

hinkley wrote: post #19
jerf wrote: post #4

Even JSON is going to be "bloated". This cries out for a well-done, well-thought out binary format. While binary formats have certain disadvantages that never go away, a lot of the worst ones that we associate with them are the result of older standards that failed to contain enough extensibility. But there's a lot of good prior art to look at now. Heck, nowadays you could probably just define something as Protobuf (…

There are tools for shrinking SVG that do some of what you say. One advantage of the text format is that you can reduce precision of the path data to a couple of significant figures. That would be hard to do with a binary format. You'd have to decide up front on 8 bytes or 16 bytes per coordinate pair.

There's existing variable-length binary number formats [1] that already exist. SVG already has so many variable-length things in it that the downsides would probably be insignificant.

I don't know if any of the existing Protobuf-like things have these built in, though. I know some of them have variable integers in them but I don't know about variable floats.

This is kind of what I was getting at in that we have a lot of prior art now. Someone putting variable ints or floats into SVG no longer has to create their own bespoke format, and proceed to fall into the various traps themselves and accidentally write it forever into the spec; there's a lot more of these sorts of pieces that you can pick up off the shelf than there used to be.

[1] https://github.com/regexident/var_float

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

#26

Post by Grimm1 »

I wanted to just write a page of screaming sounds but I figured that wouldn't go over well here.

"Why am I still struggling with browsers having different SVG implementations 18 years after the initial implementation?" is something I had to ask my self two days ago when the comma in our logo magically shifted to the left only on Firefox.

It looks like the spec here is partially to blame because 800 pages is something that even the most meticulous team of devs would have a hard time implementing without some divergence from other implementations.

I decided to switch to a high quality PNG and call it a day since we had other more important things to be focusing on.

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

#28

Post by nness »

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.

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

#29

Post by masklinn »

gardaani wrote: post #20

W3C 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).

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

#30

Post by Jestar342 »

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.

Noted, thanks.
Post reply on HN