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

141–150 of 228 posts

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

#141

Post by michaelt »

pwdisswordfish6 wrote: post #71
michaelt wrote: post #63

Earlier quoted context omitted.

> How is XML a garbage fire? If you decided to go fully XML on " " it would probably look like this: 10 10 90 10 90 90 10 90 10 10 Some would say the fact the designers of XML went for "M 10 10 H 90 V 90 H 10 L 10 10" instead shows they thought XML is too verbose. simias likely agrees that XML is too verbose - and wonders why they used XML at all

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…

> 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 representation of real-world XML documents.

And GPX is one of the better XML formats! You want to see nightmare XML? Go look at SAML.

[1] https://en.wikipedia.org/wiki/GPS_Exchange_Format#Sample_GPX...

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

#142

Post by jansan »

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…

2D vector graphics look easy at the beginning. There are some shapes, some paths, some affince transforms. But if you start to caclulate the length of a cubic bezier or try to find intersections between two cubic bezier curves, things start to get interesting. Then try to implement a solid and fast algorithm for boolean path operations. Next level of difficulty is to offset an arbitrary path, maybe with parametric offset for extra challenge. I have done all of these, and boy, I did not expect the rabbit hole to be that deep.

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

#143

Post by dillondoyle »

nikkwong wrote: post #114
ROARosen wrote: post #82

Earlier quoted context omitted.

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

i like the sun rays!!

I do love the mix of css vars into SVG. it makes a lot of sense to me too.

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

#144

Post by runarberg »

simias wrote: post #102
gibolt wrote: post #38

Earlier quoted context omitted.

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…

Getting your hands dirty by manually messing with SVG elements allows you so much freedom while plotting in D3, it is amazing. If you do any sort of advanced data visualization on the web, being able to read and write parts of SVGs is essential.

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

#145

Post by lolinder »

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

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

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

#146

Post by com2kid »

ChrisMarshallNY wrote: post #60
com2kid wrote: post #51

Earlier quoted context omitted.

> JSON Schema is a non-starter. No one ever seems to use it, and I don't think it ever made it out of committee. It pretty much goes against why JSON is popular. My company heavily uses JSON schema. The OpenAPI project uses JSON Schemas, and AWS also allows for their usage in places. And finally, there are a couple good projects that automatically generate JSON Schemas from Typescript definitions, which is my preferr…

This is nicely done: https://json-schema.org/specification.html But note "draft." Compare to: https://www.w3.org/standards/xml/schema

It's been "draft" for years.

Hasn't stopped tooling from being built around it.

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

#147

Post by qwertay »

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

Using D3 to draw plots and other data visualizations is really golden. Next to other good plotting libraries (such as ggplot2) having SVG as my canvas really gives me the feeling that I can do everything that I want.

Its good if you need dynamic charts in JS but if you just want a graphic or a logo I wouldn't use it. Its also a huge pain to maintain, they update the library once a year with breaking changes and then it takes me a day or 2 to work out how the old version worked, how the new one works and how to move all my graphics over.

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

#148

Post by qwertay »

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

There's nothing wrong with xml or other SGML based markups. They are meant to be written by a computer, not by hand.....

XML is not an ideal format for computers.

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

#149

Post by misnome »

progval wrote: post #124
pjmlp wrote: post #110

Earlier quoted context omitted.

path: d: M: 10, 10 H: 90 V: 90 H: 10 L: 10, 10 Just beautiful.

Nope, it should be an array. You use a hash so order isn't preserved and duplicate keys are removed. (Assuming that's Yaml)

Well clearly it'd be part of the specification to say that it's ordered and non-unique, it's obviously your fault if you expected standard yaml!

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

#150

Post by qwertay »

Groxx wrote: post #95
mywittyname wrote: post #80

Earlier quoted context omitted.

The biggest issue I have with XML is the ambiguity between attributes and child elements. The distinction makes sense in an abstract perspective, but real-world implementations rarely use them in a consistent manner.

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.
Post reply on HN