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

61–70 of 228 posts

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

#61

Post by ChrisMarshallNY »

cpill wrote: post #47
ChrisMarshallNY wrote: post #36

Earlier quoted context omitted.

I have worked with XML since it was a wee laddie. I generally prefer using JSON, but all my SDKs emit BOTH XML and JSON (and, occasionally, CSV). XML Schema is the main reason I use XML. I hate Schema. Hates HAAATESSSS NASSSTY SSSSCHEMA..., but it is ironclad. If it is described in Schema, then it is guaranteed (or not; in which case Schema also accounts for that). JSON Schema is a non-starter. No one ever seems to u…

what's wrong with BNF? as a language descriptor it's simple and concise, isn't it?

It's a great data description language, but was NOT fun to work with, semantically.

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

#62

Post by eek04_ »

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…

Tagged interchange formats like https://en.wikipedia.org/wiki/Interchange_File_Format were IMO much better to work with than XML from a programming point of view.

If I want something free-form text based, I've been more happy with e.g. YAML based formats.

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

#63

Post by michaelt »

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…

> 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

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

#65

Post by Eisfunke »

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…

Obviously, if you just reimplement SVG in JSON it's not going to get better, there would be far more to it. And I'm a big fan of strong schemas, it's the best part of XML.

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

#66

Post by pwdisswordfish6 »

This doesn’t read as very well-argued. This post, and the human-versus-machine-readability one which precedes it, makes a number of general claims without pointing at any examples. I don’t feel like it will convince anyone who isn’t already familiar with the relevant issues.

Which is a shame, because I actually agree with a lot of it.

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

#67

Post by Snitch-Thursday »

Symbiote wrote: post #42
ChrisMarshallNY wrote: post #36

Earlier quoted context omitted.

I have worked with XML since it was a wee laddie. I generally prefer using JSON, but all my SDKs emit BOTH XML and JSON (and, occasionally, CSV). XML Schema is the main reason I use XML. I hate Schema. Hates HAAATESSSS NASSSTY SSSSCHEMA..., but it is ironclad. If it is described in Schema, then it is guaranteed (or not; in which case Schema also accounts for that). JSON Schema is a non-starter. No one ever seems to u…

I think, when developers don't like working in XML, it's because the tool forces them to do the job properly . That's work for whoever is producing the document, but wonderful for all the consumers.

> because the tool forces them to do the job properly

I'd argue the same restrictions on "setting handwave to maximum" and "XHTML doc has one missing brace, no web page at all now" are two extremes that have their parallels in the 'dynamic vs static typing', 'immutable pure vs mutable impure functions', 'XML vs JSON (oh wait!)', and 'web app vs native program' arguments that we HN readers love to debate.

The trick is finding the happy medium between both extremes. Training some 'slackers' to "do the job properly" and convincing some 'purists' to be more pragmatic to the limitations of the world around them.

After all, we need something to occupy us during this Eternal September.

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

#68

Post by mumblemumble »

> Maybe JSON-based, definitely not XML-based.

If we're going to start over, let's create a new syntax that's purpose-built from the ground up. JSON doesn't replicate all of the drawbacks of XML for this kind of purpose, but it replicates a lot of them. Like, all the forces that lead major XML formats to embed their own little mini-DSLs inside of strings are present in JSON as well.

There's this tradition in our profession, perhaps born of a reaction to the "not invented here" syndrome of the '90s, to habitually hack things together out of bits and pieces that already exist. Seemingly for no reason other than because they already exist, and they can be hacked. I've recently started calling it "Wallace and Gromit engineering."

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

#69

Post by vesinisa »

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

They have also defined SVG Tiny, which is basically SVG without CSS and scripting support. Which seems to be more or less what OP is calling for in the blog post. Why the need to reinvent the wheel? For once, we have massive industry-wide momentum behind a unified vector graphics format. It can be very hard to swim against that current.

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

#70

Post by goto11 »

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]}}

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