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

101–110 of 228 posts

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

#101

Post by climech »

ognarb wrote: post #90
SquareWheel wrote: post #87

Earlier quoted context omitted.

Someone complained about JSON above, but I think it does a nicer job here: { "path": [ [10, 10], [90, 10], [90, 90], [10, 90], [10, 10] ] } No need for the x and y, really. And it's still quite legible on one line. {"path": [[10, 10], [90, 10], [90, 90], [10, 90], [10, 10]]}

You clearly didn't understand how the path element in SVG works. The M, L and other characters contains valuable information. M stand for move, L for trace a line, but you can also have instructions for bezier curve or Z for closing a path. Your json format by removing this information is useless.

I believe something like this would work (excuse the comments normally not allowed in JSON):

    {
      paths: [
        {
          points: [
            [10, 10],  // 0
            [90, 10],  // 1
            [90, 90],  // 2
            [10, 90]   // 3
          ],
          lines: [
            [0, 1, 2, 3, 0]  // connect point 0 to 1 to 2 to (...)
          ],
          curves: {
            0: [5, 15, 15, 5]  // bezier control points for point 0 (x1, y1, x2, y2)
          }
        }
      ]
    }
The downside (other than the bloat) would be when writing the code by hand, you'd have to keep track of the indices in the `points` array.

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

#102

Post by simias »

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 disagree, I routinely manually mess with SVG (even SVG generated with a program like inkscape) because it lets me add interactivity and animations. That's the killer feature for me: you can draw arbitrary vector shapes in a website, then hook into them using javascript the way you would any DOM element. There are a few subtleties to make it work well, but it's pretty straightforward.

Here's an example: https://svkt.org/~simias/up/20210212-185105_svg.png

All the elements and paths are SVG generated from some javascript. You can interact with the various elements, move them around and the paths are updated in real time.

Of course you could do the same thing with a raster format by using a canvas and drawing a bitmap for instance, but SVG works at a higher level and lets you do these things a lot faster and probably with better performance. You can use CSS-styling, you can register javascript event callbacks etc...

Or to put it another way: if SVG was meant as an opaque machine-to-machine format, why even bother with the insane overhead of XML instead of using some dense binary format?

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

#103

Post by prideout »

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…

While JSON is far from perfect it is a lingua franca; humans and computers all over the world are very familiar with it. I think this is one of reasons for the growing popularity of the glTF format for 3D models, which also has a binary variant.

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

#104

Post by prideout »

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?

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

#106

Post by simias »

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

SGML (and descendants) is a markup language. It's in the name really.

>XML/SGML are a very effective way of representing tree data

Completely disagree:

- It's not effective density-wise because the format is very verbose

- It's not effective parsing-wise because the format is very complicated.

- It's not effective human-wise because you have meaningless distinctions between attributes and child nodes which makes sense for a markup language but not for a serialization format. It's also very verbose which makes it annoying to read and write.

Imagine that you have an object like:

   struct Object {
        name: "foo",
   }
Should you serialize like:
Or:

    foo
And to be clear, that's a rhetorical question. My point is that this distinction doesn't make a lot of sense for a serialization format and forces the developer to make pointless decisions. Here you might say that an attribute makes more sense, but then if later you realize that you can have several names you're screwed, because you either have to come up with your own custom format to store those in an attribute (coma-separated? But what if there's a coma in the name?) or split them off into child nodes.

It makes perfect sense for a markup language though, because there's (usually) a clear distinction between the textual and metatextual content. The stuff between the tags is meant to be displayed to the user, whereas the attributes are meant to be interpreted by the machine.

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

#107

Post by tabtab »

Web "standards" are majorily screwed up. We can't build tools like interactive charts, such as an ERD editor, because the charting and drawing tools are separate from the data entry tools (INPUT tags etc.). And they still don't directly support rich GUI's. Thus, a lot of common UI idioms have to be reinvented via bloated buggy slow JavaScript libraries.

I propose web standards be refactored and split into 3 categories: A) Art, media, & entertainment. B) Documents and brochures, and C) CRUD, GUI, Data, productivity

They would overlap as much as practically possible, but could also specialize in their respective niche better.

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

#108

Post by wtetzner »

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

> SVGs are meant to be created and used like any image file.

Then why bother with the XML? And why use the embedded DSLs in strings instead of the more verbose XML-way.

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

#109

Post by hanche »

irrational wrote: post #89

>like to write it by hand I'm honestly horrified that someone out there is writing SVG by hand.

I have done it, but only for some very simple stuff like a logo constructed from a small handful of coloured circles. I certainly would not recommend it for more complicated work.

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

#110

Post by pjmlp »

colllectorof wrote: post #44
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]}}

    path:
        d:
           M: 10, 10
           H: 90
           V: 90
           H: 10
           L: 10, 10
Just beautiful.
Post reply on HN