SVG: The Good, the Bad and the Ugly • Hacker News Board

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

#111

Post by kevincox » Fri, Feb 12, 2021, 7:17 PM UTC

hinkley wrote: post #76

Someone wrote: post #32

Earlier quoted context omitted.

Binary formats need not use fixed-length fields. You could use a format that stores small integers in 8 bits, yet allows for larger ones. See for example https://developers.google.com/protocol-buffers/docs/encoding... . You don’t even have to use byte-sized fields, but doing that makes encoding and decoding harder, and the overhead of also storing the actual lengths in bits of variable sized fields may be too much to…

I think you missed my point. SVG coordinates are effectively arbitrary precision. 3.5 bits per byte of arbitrary precision, but arbitrary precision nonetheless. There are no small integers, only scalar or vector values.

varint style encoding is also arbitrary precision (although protobuf doesn't support arbitrary precision) It is trivial to get 7 bits per byte and you can do even better for large values by encoding the length upfront (this also makes decoding faster).

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

#112

Post by wrnr » Fri, Feb 12, 2021, 7:17 PM UTC

There is already ivg https://github.com/reactivego/ivg

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

#113

Post by wtetzner » Fri, Feb 12, 2021, 7:24 PM UTC

pwdisswordfish6 wrote: post #100

wtetzner wrote: post #96

Earlier quoted context omitted.

Except that's not what happened. They also had to define new syntax for the DSLs they embed in strings.

True. But it would have been much harder if they had to define a syntax for the entire document. I imagine they thought that the path DSL is simple enough to parse (and I seem to vaguely recall PostScript has something similar), while the overhead of representing path nodes as XML elements would be too high.

I'm not arguing against using an existing format, BTW, just seems like a weird mixture here.

I can't help but think s-expressions would have been a better choice.

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

#114

Post by nikkwong » Fri, Feb 12, 2021, 7:26 PM UTC

ROARosen wrote: post #82

dillondoyle wrote: post #46

Earlier quoted context omitted.

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?

I do personally for color control. You can see my heavy use of SVGs here at a site I'm in the middle of implementing [0]. For example, if you look in the :root {} you will see a lot of CSS variables that are declared and which manipulate their HSL value based on base variables like --hue. The SVGs implement these. So you can change the global --hue, and the hue of all the SVG elements on the page will change. I've modified output SVGs from figma/illustrator to reference a variable rather than a hardcoded fill i.e. becomes That's a simple example, you can go further to change relative saturation and lightness as well, which I also do with CSS calc(). It's fun!

[0] www.holysnacks.us

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

#115

Post by sjbrown » Fri, Feb 12, 2021, 7:27 PM UTC

marcodiego wrote: post #2

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

Here's a full-on dice roller / Virtual Tabletop that takes advantage of this: https://github.com/sjbrown/togetherness

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

#116

Post by paul_manias » Fri, Feb 12, 2021, 7:29 PM UTC

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…

> Oh. You can almost hear the designer saying "well fuck it, we'll just jam it all into a string.

I'll throw in my 2 cents here because the responses aren't addressing why the path descriptors are stylised in this way. Whether SVG's underlying document format was XML, JSON, SGML, CSS or whatever is irrelevant. However else you did it, any alternative would be more verbose because the 'd' tag already offers the most compact way of describing vector paths in text form.

And that's the point - it's small. Even in this compact form, it's not unusual for path strings to reach kilobytes in length when floating point numbers are catered for. Thus we need the path descriptions to be as small as possible for optimal parsing of the file and keeping the file size down.

As a side-note I disagree with the author's conjecture that SVG doesn't succeed as a machine-focused language or a human-focused language. I think it serves both sides of the coin quite well in practice (certainly more-so than HTML) and a pared back version already exists in the form of SVG Tiny.

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

#117

Post by foolmeonce » Fri, Feb 12, 2021, 7:32 PM UTC

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

I think its relationship with HTML, JavaScript and CSS would be a lot worse if it didn't reuse XML to the extent that it did.

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

#118

Post by kstenerud » Fri, Feb 12, 2021, 7:40 PM UTC

prideout wrote: post #104

kstenerud wrote: post #6

SVG was actually one of the first topics I'd planned to tackle once https://concise-encoding.org/ and the reference implementation is finished. You definitely don't want to solve SVG's bloat problem by moving to another text-based format.

Do you still plan on tackling it?

Yup! It's just that CE spec has taken much longer than I'd anticipated ;-)

The CE spec is for all intents and purposes done (I don't anticipate any more changes), and the reference implementation is in the final stages. After that comes the schema format, then the official V1 release, and then I can move on to technologies built upon it.

From some back-of-the-envelope calculations I made recently, I should be able to represent the same vector graphics in the same basic structure (such that you could convert between them), but in about 1/3 the space (not including the crazy stuff like CSS and JS).

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

#119

Post by ahartman00 » Fri, Feb 12, 2021, 7:44 PM UTC

PaulHoule wrote: post #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…

Is this what you mean by groups?

"The SVG element is a container used to group other SVG elements.

Transformations applied to the element are performed on its child elements, and its attributes are inherited by its children. It can also group multiple elements to be referenced later with the element."

https://developer.mozilla.org/en-US/docs/Web/SVG/Element/g

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

#120

Post by runarberg » Fri, Feb 12, 2021, 7:46 PM UTC

simias wrote: post #97

runarberg wrote: post #59

Earlier quoted context omitted.

Exactly, in the canvas API this is written like: ctx.moveTo(10, 10); ctx.lineTo(90, 10); ctx.lineTo(90, 90); ctx.lineTo(10, 90); ctx.lineTo(10, 10); Not much better.

I disagree, the JS code is immediately understandable without having to lookup anything. You could do it in pure XML but the result would probably be much more verbose.

To be equivalent the SVG `` element would probably need to take an idref to something like a `` element. This is how I would guess the equivalent would be:

EDIT: Come to think of it, the above is probably a lot easier to animate using CSS or SMIL. Animating the `d` attribute on ``s is theoretically possible but in practice weird at best or browser inconsistent or simply impossible at worst.

EDIT 2: In D3 it is not uncommon to draw area graphs with a thick border on top. The only way to do this is with two ``s with almost identical `d` attributes. Allowing drawings to be strung together with multiple idrefs could solve that:

Maybe this isn’t such a bad idea after all.