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

211–220 of 228 posts

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

#211

Post by afiori »

hinkley wrote: post #78
jerf wrote: post #25

Earlier quoted context omitted.

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…

I don't see how var_float lets you detect the length of a number field from the input. It seems to be designed to take arbitrary input from another function (which has already decided how big the data is out-of-band). Am I missing something, or can I not read 2 bytes from a file and detect if that's the end of the number or I need to read the next 2 bytes?

yes, that is half of how utf8 works as an encoding: the first byte of a unit is either 0xxxxxxx or 11xxxxxx, in the first it is a single ascii byte and in the second case all the following bytes that start with 10xxxxxx are part of the same unit.

for this purpose it would be enough to revert the order of the stream.

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

#212

Post by j45 »

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…

Oddly sometimes.. XML syntax can be a bit more readable than JSON

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

#213

Post by cdrini »

michaelt wrote: post #63
cdrini wrote: post #45

Earlier quoted context omitted.

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…

> 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

Just because XML isn't perfect for everything, doesn't mean it's a garbage fire. XML is great for trees -- specifically document trees. So XML is used to manage the document-like properties of an SVG (elements/position, nested groups, etc). XML is not great for representing potentially gargantuan lists of drawing instructions. So the SVG folks smartly decided to use a more compact DSL to handle that use case. In the same way CSS was created, or JS. Could you instead have used XML for styling? Of course (XAML does this if you want an example). You could even force JS to be written in XML. The fact that in those forced applications XML is very verbose, doesn't mean XML is verbose in general.

Also just in general, SVG's d-path syntax is a fantastic example of smart meeting of and understanding of requirements and users. If they used something more verbose (like `move-to` instead of `M` or whatever), then the file becomes WAY less human readable (too much noise at the XML-level), but more novice friendly. But... will novices need to edit d-paths manually? Of course not! Will they need to edit the XML structure manually? Way more likely. So you can use a more compact expert syntax for paths, because the people who will want to use it will likely be experts. It also means that SVG files are smaller, require less memory to parse, and more human-readable. Seriously great choice on their part.

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

#214

Post by cdrini »

simias wrote: post #106
cdrini wrote: post #45

Earlier quoted context omitted.

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

Agreed; XML is best for document trees more than just generic tree data in general. I think the meaning between attributes/child nodes is pretty clear for like ~85% of use cases. Namely: attributes are for properties of the current node, child nodes are separate elements which are contained in the current node. I agree it can be complicated to parse, and don't agree it's exceptionally verbose. It is more verbose than say, a CSV or something, or than JSON (only because of the ending tags), but I wouldn't call it exceptionally verbose. That verbosity often makes things easier to read to than e.g. JSON, where you need a `type: "paragraph"` or equivalent on every element to simulate how HTML works. XML is better for document trees, JSON is better for generic tree data.

(Note: XAML does have a nice duality between attributes and nodes (sort of) which is kind of interesting. It's been a while since I've used it though, so can't quite recall the details).

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

#215

Post by cdrini »

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.

I would argue that using something like this would result in a less readable file overall. 85% of people editing SVGs by hand have 0 interest in modifying paths by hand. They likely want to move elements around, change groups, etc. If the d-path was written less compactly, these path definitions, which, again most people don't even care about, would end up taking up the vast majority of the space in the file. It would be impossible to get an idea of the nesting, and super annoying to move things around since they would be huge.

Also: Reminder SVGs goal is presentation, so paths even for a simple monochrome icon have _hundreds_ of control points. Something more intricate or a larger graphic? Thousands easily. All the examples here are toy examples, that don't scale to what SVG is actually used for.

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

#216

Post by tadfisher »

renox wrote: post #208
goto11 wrote: post #70

Earlier quoted context omitted.

Since this is HN I will point out that s-expressions are vastly superior: (path (d (M 10 10) (H 90) (V 90) (H 10) (L 10 10)))

I know you're joking but I still don't understand why (+ x y) is a good idea: clearly the first argument has a different meaning than the other, IMHO +(x y) show better the difference between the operation a d the arguments..

That significantly complicates the grammar, as now nested function calls require context from their parent to form an AST node. S-exps are the literal representation of the AST which allows for easily modifying and inspecting code, for example through macros. It's not so much "the first element is significant", it's more like "this is the convention of what a function looks like so you can pass it around and modify it as a single list".

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

#217

Post by goto11 »

renox wrote: post #208
goto11 wrote: post #70

Earlier quoted context omitted.

Since this is HN I will point out that s-expressions are vastly superior: (path (d (M 10 10) (H 90) (V 90) (H 10) (L 10 10)))

I know you're joking but I still don't understand why (+ x y) is a good idea: clearly the first argument has a different meaning than the other, IMHO +(x y) show better the difference between the operation a d the arguments..

I'm only half joking. The different notations all have pros and cons, but the benefit of s-expressions are their simplicity. A list can be either an expression (+ x y) but can also be a list of things like (red blue green) and an empty list can be written as (). It is basically the simplest possible structured notation.

+(x y) would be fine for expressions but weird for lists of things.

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

#218

Post by ROARosen »

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…

Wow I never thought of doing animations that way. Great stuff!

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

#219

Post by Mikhail_Edoshin »

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…

SVG provides elements for things you're going to individually address with XPath or JavaScript. Points are less likely to be manipulated that way, so it's OK to stop using XML to mark up the structure here. Many other data types, such as time, HTTP or email addresses also have structure, but you normally don't explicitly mark it up because they're trivial to parse.

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

#220

Post by Jestar342 »

SigmundA wrote: post #179
colejohnson66 wrote: post #160

Earlier quoted context omitted.

JavaScript based manipulation of the SVG’s nodes doesn’t work then.

But the parent said they switched to PNGs, same issue right?

I decided to switch from SVG with build time manipulation of attributes (scale, colours, rotation, etc) to an image optimisation library (and soon probably a saas like imgix).

I'd prefer to have stuck with SVG had it not been for the I'd collision thing, so with one of these tools in our chain we just might do that.

Post reply on HN