Live data from Hacker News

SVG: The Good, the Bad and the Ugly

eisfunke.com

11–20 of 228 posts

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

#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 me, it sounds like the tooling is actually what's lacking. The equivalent of minifying or even the option to render xml to a binary representation is probably what is actually lacking.

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

#13
post #3

Earlier quoted context omitted.

Tetris in an SVG?!? I am in awe. I'm feeling equal parts: "this is beautiful", "this is perverse", and "I want to do this too"

Cool? Take a look at this: https://www.scriptol.fr/xml/code/invaders.svg

It seems like the French have a passion for dynamic SVGs.

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

#14
post #3

Earlier quoted context omitted.

Tetris in an SVG?!? I am in awe. I'm feeling equal parts: "this is beautiful", "this is perverse", and "I want to do this too"

Cool? Take a look at this: https://www.scriptol.fr/xml/code/invaders.svg

Space Invaders! Amazing!

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

#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 the designer saying "well fuck it, we'll just jam it all into a string.

The fact that SGML-based formats managed to become as popular as they are is really proof that there's something fundamentally rotten in software engineering.

I do quite like SVG though. I mean, if the alternative is drawing with CSS, it's pretty amazing. I don't really agree that it's hard to generate programmatically either, you just have to decide what subset of the format you need, look at what inkscape generates and go from there. If you need to generate basic shapes it's fairly straightforward.

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

#16
post #9

I really appreciated this article. It would be great to see a smaller svg graphics standard. I think SlimSVG is a bad name because it implies its still SVG. It should set its self apart. Just my 2 cents.

In my opinion, what makes SVG bloated is not the fact that it's for humans or machines, this is mostly irrelevant compared to the ability to have filters, CSS animation, interactivity, advanced rendering options on different contexts...

Concerning the simple use of standard shapes, you could restrict yourself to simple shapes within SVG : thus youd already have myriads of existing implementations and tooling, it would be mostly understandable by humans, short and writable by hand/simple scripts.

You could even call them mobile SVG Tiny and Basic : it exists since 2009. https://www.w3.org/TR/2003/REC-SVGMobile-20030114/ . That would be a good start.

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

#18
I have been interested in the "low code" problem, in particular the kind of advanced parsers that were used in the 1990s to attempt things like "edit the UML diagram in a GUI and change the Ada source code the way a professional programmer would".

Dreamweaver used to do this for HTML, sometime before it got bought by Adobe. Today Dreamweaver seems like it would be usable on a 90 THz computer but I can do 10 push ups waiting for the UI to settle down after typing "Hello World".

A split-screen SVG editor would be particularly good, since so much of editing an SVG file is getting the numbers right. You'd face many interesting problems, such as exposing decimal math to the user (whatever iffy floating point is used, your git commits are going to be awful unless you "snap to grid" in factors of 1/2 and 1/5.)

What I'd particularly like to do is have control of the structure of the document so I can group elements with the discipline of a programmer.

A tool like that still might not be satisfying because Bézier curves were made to make people feel like they were bad at computer graphics and took over instead of better alternatives that were patented at the time. I was shocked to find that my favorite character designers don't know how to draw anime characters with Bézier curves.

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

#19
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.

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

#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 existing tools, such as Adobe Illustrator and Inkscape (meaning that they can open SVG Native files).

Adobe even has an open source renderer for SVG Native [2].

[1] https://svgwg.org/specs/svg-native/

[2] https://github.com/adobe/svg-native-viewer

Post reply on HN