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

You probably mean

  (path d M 10 10 H 90 V 90 H 10 L 10 10)

Shore up some nesting for the commands with pattern matching, returning a path struct:

  This is the TXR Lisp interactive listener of TXR 251.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  Garbage collection is on Tuesdays: bring unwanted pointers to curb by 7:30.
  1> (defstruct path () name args)
  #<struct-type path>
  2> (defun parse-path-args (args)
       (match-case args
         ((M @x @y . @rest) ^((M ,x ,y) ,*(parse-path-args rest)))
         ((L @x @y . @rest) ^((L ,x ,y) ,*(parse-path-args rest)))
         ((H @x . @rest) ^((H ,x) ,*(parse-path-args rest)))
         ((V @x . @rest) ^((V ,x) ,*(parse-path-args rest)))
         (())
         (@else (error "bad path arguments: ~s" else))))
  parse-path-args
  3> (defun-match parse-path
       (((path @(symbolp @name) . @args))
        (new path name name args (parse-path-args args)))
       ((@else) (error "bad path syntax: ~s" else)))
  parse-path
  4> (parse-path '(path d M 10 10 H 90 V 90 H 10 L 10 10))
  #S(path name d args ((M 10 10) (H 90) (V 90) (H 10) (L 10 10)))

Error cases:

  5> (parse-path '(path d M 10 10 H 90 V 90 X 10 L 10 10))
  ** bad path arguments: (X 10 L 10 10)
  ** during evaluation of form (error "bad path arguments: ~s"
                                    else)
  ** ... an expansion of (progn (error "bad path arguments: ~s"
                                     else))
  ** which is located at expr-2:2
  ** run with --backtrace to enable backtraces
  6> (parse-path '(paath d M 10 10 H 90 V 90 X 10 L 10 10))
  ** bad path syntax: paath d M 10 10 H 90 V 90 X 10 L 10 10
  ** during evaluation of form (error `bad path syntax: @else`)
  ** ... an expansion of (progn (error `bad path syntax: @else`))
  ** which is located at expr-3:1
  ** run with --backtrace to enable backtraces

I think that’s too flat. There’s no easy place to put the width and suchlike. I think you’d want something like:

  (path (M 10 10 H 90 V 90 H 10 L 10 10) :color red)

Though probably I would prefer something more nested if possible, so you have a list of instructions rather than needing to parse them out of a flattened list. And I would likely use an alist rather than a plist for attributes like colour or stroke width.

Even superior:

    path 10 10 M 90 H 90 V 10 H 10 10 L #000 stroke

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

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.

    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!

Thanks for pointing out what I expected, and making it even more delightful.

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 schema. Is there an alternative language that is better? How is it better?

> How is XML a garbage fire?

If you decided to go fully XML on "<path d="M 10 10 H 90 V 90 H 10 L 10 10"/>" it would probably look like this:

  <path>
    <point>
      <x>10</x>
      <y>10</y>
    </point>
    <point>
      <x>90</x>
      <y>10</y>
    </point>
    <point>
      <x>90</x>
      <y>90</y>
    </point>
    <point>
      <x>10</x>
      <y>90</y>
    </point>
    <point>
      <x>10</x>
      <y>10</y>
    </point>
  </path>

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 about the execution, but the idea of seamlessly mixing structured data defined by independent standards in a single document is pretty damn powerful.

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. A more realistic example would have <path> contain an ordered sequence of <move-to x="..." y="..." /> and <line-to x="..." y="..." /> elements. (In fact, SVG already contains <line /> and <circle /> which use roughly this structure.)

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

      <trkpt lat="47.644548" lon="-122.326897">
        <ele>4.46</ele>
        <time>2009-10-17T18:37:26Z</time>
      </trkpt>

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

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.

Pertinent to this specific discussion is that XML distinguishes syntactically between "elements" and "attributes", but it's often not clear what the purpose of the distinction is (search for "elements vs attributes").

JSON and YAML do not make such a distinction.

True, but the lack of a clear distinction also seems like a weakness in the specific DSLs rather than a weakness in the format. HTML has (with some exceptions) a very clear distinction between them: attributes are for metadata, elements are for visible page content. Android's XML draws a similar distinction, with attributes used to describe properties of a view and elements used to describe child views.

(I do concur with others who have noted here that the "elements" versus "attributes" distinction makes XML a poor choice for serialization, but XML as a serialization format isn't really the issue here.)

XML was based on SGML, which was originally intended for marking up text documents, so TEXT was given a special place in the Pantheon of Nodes, even above Attributes.

So using XML to represent data structures instead of marking up text can be pretty awkward, inefficient, and nuanced.

XML Attributes are second class citizens compared to TEXT nodes which can contain CDATA, because attributes undergo "Attribute-Value Normalization" -- having their line breaks, entity references, and white space normalized. Newlines are normalized, leading and trailing white space removed, repeating white space replaced with a single space.

SVG path attributes (as well as simple values like numbers, booleans, enums, etc) are impervious to Attribute Value Normalization corruption, because they don't depend on white space being perfectly preserved (by design, of course), so they are fine to put in attributes.

But if you really care about preserving the exact value of a string, like a password or arbitrary string, you should use <!CDATA[[ ]]> in a text node, not an attribute!

I Wanna Be <![CDATA[ https://donhopkins.medium.com/twenty-twenty-twenty-four-esca... ]]>

https://www.w3.org/TR/xml/#AVNormalize

3.3.3 Attribute-Value Normalization

Before the value of an attribute is passed to the application or checked for validity, the XML processor must normalize the attribute value by applying the algorithm below, or by using some other method such that the value passed to the application is the same as that produced by the algorithm.

All line breaks must have been normalized on input to #xA as described in 2.11 End-of-Line Handling, so the rest of this algorithm operates on text normalized in this way.

Begin with a normalized value consisting of the empty string.

For each character, entity reference, or character reference in the unnormalized attribute value, beginning with the first and continuing to the last, do the following:

For a character reference, append the referenced character to the normalized value.

For an entity reference, recursively apply step 3 of this algorithm to the replacement text of the entity.

For a white space character (#x20, #xD, #xA, #x9), append a space character (#x20) to the normalized value.

For another character, append the character to the normalized value.

If the attribute type is not CDATA, then the XML processor must further process the normalized attribute value by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character.

Note that if the unnormalized attribute value contains a character reference to a white space character other than space (#x20), the normalized value contains the referenced character itself (#xD, #xA or #x9). This contrasts with the case where the unnormalized value contains a white space character (not a reference), which is replaced with a space character (#x20) in the normalized value and also contrasts with the case where the unnormalized value contains an entity reference whose replacement text contains a white space character; being recursively processed, the white space character is replaced with a space character (#x20) in the normalized value.

All attributes for which no declaration has been read should be treated by a non-validating processor as if declared CDATA.

It is an error if an attribute value contains a reference to an entity for which no declaration has been read.

Some of the most incredibly awfully bad XML DSLs are official standards, themselves. COUGH XMLSchema COUGH

You should read some of James Clark's criticisms of the official XML Schema (XSD) standard, which motivated him to develop TREX (Tree Regular Expressions for Xml), which he combined with Makoto Murata's RELAX (REgular LAnguage description for XML) to create Relax/NG.

https://en.wikipedia.org/wiki/James_Clark_(programmer)

https://en.wikipedia.org/wiki/Makoto_Murata#RELAX_and_RELAX_...

>Some people, including Murata and James Clark, had critical attitudes toward XML Schema. XML Schema is a modern XML schema language designed by W3C XML Schema Working Group. W3C intended XML Schema to supersede traditional DTD (Document Type Definition). XML Schema supports so many features that its specification is large and complex. Murata, James Clark and those who criticised XML Schema, pointed out the following:

>It is difficult to implement all features of XML Schema.

>It is difficult for engineers to read and write XML Schema definitions.

>It does not permit nondeterministic content models.

>Murata and collaborators designed another modern schema language, RELAX (Regular Language description for XML), more simple and mathematically consistent. They published RELAX specification in 2000. RELAX was approved as JIS and ISO/IEC standards. At roughly the same time, James Clark also designed another schema language, TREX (Tree Regular Expressions for XML).

>Murata and James Clark designed a new schema language RELAX NG based on TREX and RELAX Core. RELAX NG syntax is the expansion of TREX. RELAX NG was approved by OASIS in December 2001. RELAX NG was also approved as Part 2 of ISO/IEC 19757: Document Schema Definition Languages (DSDL).

https://en.wikipedia.org/wiki/Regular_Language_description_f...

https://en.wikipedia.org/wiki/RELAX_NG

https://en.wikipedia.org/wiki/XML_Schema_(W3C)

Schema Wars: XML Schema vs. RELAX NG (1/2) - exploring XML

https://web.archive.org/web/20180429143242/http://webreferen...

https://web.archive.org/web/20180429145711/http://webreferen...

https://news.ycombinator.com/item?id=22756875

>James Clark used Haskell to design and implement an algorithm for validating Relax NG XML schemas (he co-designed Relax NG, and designed its predecessor TREX), to work the ideas out before re-implementing it in (many many more lines of tedious brittle) Java (JING). Haskel works wonderfully as a design and standard definition language, that way.

https://news.ycombinator.com/item?id=25435678

>James Clark's compact syntax for Relax/NG XML schema validation language is quite tastefully designed, an equivalent but more convenient alternative syntax than XML, for writing tree regular expressions matching XML documents. It's way more beautiful and coherent than the official "XML Schema" standard.

[...]

>There's a wonderful DDJ interview with James Clark called "A Triumph of Simplicity: James Clark on Markup Languages and XML" where he explains how a standard has failed if everyone just uses the reference implementation, because the point of a standard is to be crisp and simple enough that many different implementations can interoperate perfectly.

>A Triumph of Simplicity: James Clark on Markup Languages and XML:

https://web.archive.org/web/20130721072712/https://www.drdob...

"The standard has to be sufficiently simple that it makes sense to have multiple implementations." -James Clark

Fair enough. But SVG was defined by the W3C, the very same organisation that standardised XML itself. If anyone, they would know what they’re doing.

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

The boundary where the XML ends and the DSL begins is at least a little arbitrary, but it does have important ramifications. By using XML, you can use the XPath query language to index down to a `path` (the end of the XML), but not within a `path` (the beginning of the DSL). That means, at least conceptually, you can attach colors, and events, and such to a path. And the fact that you cannot do it within a path (not without introducing a query language for the DSL) is inelegant, but also might not have much bearing in 99% of applications.

Because then you’d have to define its syntax and extension points. XML and namespaces solve that problem for you, so the only thing left for you to design is the actual structure of your data.

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.

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.

Alternatively, with SGML:

  <path>
    <point x=10 y=10/>
    <point x=90 y=10/>
    <point x=90 y=90/>
    <point x=10 y=90/>
    <point x=10 y=10/>
  </path>

Same as other commenters, you removed the information about that this coordinate means. Does <point x=10 y=10/> means I will trace a line to 10,10, move to 10,10, trace a bezier curve, ...

This could be a better format, but still a lot heaver in term of bandwidth.

  <path>
    <move x=10 y=10/>
    <line x=90 y=10/>
    <curve x=90 y=90/>
    <end/>
  </path>

This is pretty clearly a more accurate "xml-ification" of a bunch of points. X/Y are un-ordered attributes of a point, not part of an ordered list of things contained within a point.

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.

This would work:

    <path>
      <m x=“10” y=“10” />
      <h dx=“90” />
      <v dy=“90” />
      <h dx=“10” />
      <l x=“10” y=“10” />
    </path>

Perfectly sane.

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.

i'd much rather have

    [ { line: [10, 10] }, { cubic: [ 5, 15, 15, 5 ] }, ... ] 

or even

    [ ["line", 10, 10], ["cubic", ...], ... ] 

- anything as long as there's a way to stream the data (which is not possible with your format as you need to receive the whole object before being able to do anything).

this makes me realize that xml maps relatively well to JSON array whose elements are object with 1 fields (or 2 fields) whose value is again a similar array.

> You clearly didn't understand how the path element in SVG works.

No, I didn't. I was working from the parent's code. I don't appreciate your attitude though. There's much nicer ways to correct people online.

While there's truth in this, it's irrelevant to their point which was:

> No need for the x and y, really

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:

   <object name="foo" />

Or:

   <object> <name>foo</name> </object>

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.

Actually it's not a pointless distinction. If you care about the integrity of your string, you'd better use text nodes with CDATA, not attributes, because of the dreaded obscure XML feature called "Attribute Value Normalization".

XML just tempts you to use attributes to represent strings, then kicks you in the ass when you least expect it by corrupting your data unexpectedly and unfairly but with full legal authority of the xml standard itself.

I wrote about it in this other comment:

https://news.ycombinator.com/item?id=26122107

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

The presentations/articles on how to unambiguously decode the XML Signature Spec are almost as long as the spec itself. When it was my turn to parse it, I found a couple of cases they missed.

In XML ID fields are supposed to be unique to the document. Nobody enforces this. Instead getByID returns the first ID. Which means if you ask a DOM element and the root element for an element by ID, you can get two different answers.

Composing multiple schemas into the same file is a wordy, confusing mess, DTDs are straight up broken, and the only time I ever saw someone generate a Grade A XML Schema was by feeding examples into XMLSpy instead of writing their own.

XML asks a question we already knew the answer to: What if we made everyone into a programming language designer? And the answer was "anarchy" because we know that many people cannot design a syntactically consistent language, and hardly anybody can design a semantically consistent one.

James Strachan, as I recall, retired from Groovy before they ever figured out an unambiguous grammar for it. There comes a point where you realize you've made a mess that you are not qualified to clean up (Kernighan's Law). You can either do the very hard work of maturing into the responsibility, or bow out. Strachan is no different than a dozen people I've worked with and countless people I've heard about second or third hand, who I'm more than a little glad moved on.

The guilt is not theirs alone. Part must fall to this shared delusion that you can do anything with software if you only put your mind to it. We have mathematical proofs that tell us that's not true, and yet we still believe in the power of belief. Unfortunately if we didn't believe it a little, then we'd probably never write anything at all, so I'm not sure there's so much a cure as a condition that has to be managed. A little bit can go a long way, and most of us take it too far, sooner or later.

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.

Exactly, in the canvas API this is written like:

    <path d="M 10 10 H 90 V 90 H 10 L 10 10"/>

    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 `<path>` element would probably need to take an idref to something like a `<draw>` element. This is how I would guess the equivalent would be:

    <draw id="my-path">
      <move-to x="10" y="10" />
      <line-to x="90" y="10" />
      <line-to x="90" y="90" />
      <line-to x="10" y="90" />
      <line-to x="10" y="10" />
    </draw>

    <path draw="my-path" />

EDIT: Come to think of it, the above is probably a lot easier to animate using CSS or SMIL. Animating the `d` attribute on `<path>`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 `<path>`s with almost identical `d` attributes. Allowing drawings to be strung together with multiple idrefs could solve that:

    <draw id=line-path><!-- ... --></draw>
    <draw id="area-box-close">
      <line-to x="100" y="100" />
      <line-to x="0" y="100" />
      <end />
    </draw>
    
    <path draw="line-path" class="line" />
    <path draw="line-path area-box-close" class="area" />

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

Yes! That's a lot better IMO, but I suspect that the reason for the custom string with single letter "operators" is because the size overhead was unbearable for SVGs with complex paths (which, being a vector format, should be considered the baseline). The overhead is already pretty massive with the current spec, gzipped you can usually divide the file size by an order of magnitude.

I SVG is pretty inelegant, but it's pragmatical.

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.

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

I wonder though why does that matter for a web format that can be served with GZIP encoding? Wouldn't GZIP eat the duplicative <move-to /> tags for breakfast? It would be so much easier to write, read, manipulate and animate.

Let's imagine for a moment that path instructions could be mapped out with more verbose instructions. Would this really get enough practical use to be worthy of standardisation?

For the most part, SVG path outlines are almost always defined in software like Illustrator and Inkscape. Bezier curves are beyond the average person's ability to create or modify without visual aids. Simple path constructs aren't all that common in practice and the examples I see posted here aren't representative of real-world use.

SVG does provide transform capabilities to move, rotate and scale paths easily, and those features can be applied within a text editor. For anything else there are plenty of visual tools to aid path modification. Personally I've modified many an SVG file manually, but when it comes to the paths I can't say that seeing them laid bare would be of a help to my workflow.

I'll reference you to a comment elsewhere in the tree, and its parents[0], which came up with this s-expression:

    (path (M 10 10 H 90 V 90 H 10 L 10 10) :color red)

It's legitimately hard to beat sexprs for the combination of compactness, generality, and ease of use. If I were to start from first principles in making a vector graphics format, I'd probably make it a schema over EDN. I bet the extra complexity of having explicit maps and vectors would pay off.

[0]: https://news.ycombinator.com/item?id=26118727

I think that's reasonable, but is syntactic sugar really going to help you modify a path when the vector points will look more like this in reality:

  (path (M 368.296, 1.514) (c -0.908, 0 -1.818, 0.011 -2.716, 0.021) 
  (c 0.053, 0, 0.106, 0, 0.159,0) (c 147.196, 0.836, 265.306, 94.672, 267.029, 183.784)
  (c 0, 0.581, 0.065, 35.087, 0.065, 35.087) (h 49.415)
  (v -33.471) (h 37.094) (v -31.376)
  (C 719.342, 77.099, 575.826, 1.514, 368.296, 1.514)
  (z))

I've used SVG pretty heavily for years, in particular for the last couple of months as I've been writing libraries/tools that render SVG output (parsing for the cli tool side, lots of hand-writing & testing, cleaning, rendering).

Yes an s-expression is imo normally the best representation (more specifically, an x-expression (see Racket) would be ideal). However, practically, it's not actually that useful. It is very useful as an intermediary step.

For example for a tool where the SVG is parsed to an x-expression and cleaned then compiled back. This is one of the [aborted] things I was working on, as the three best existing tools [in JS, Python and Rust] for this all have issues of one kind or another. Or you have a tool that allows you to write x-expressions then compile. But always with this, if that's the case, can't really directly jnterop with the host language/platform -- as you say, would have to be from first principles. And further to that, it would need HTML from first principles because one of the huge, huge benefits is that SVG drops directly into HTML with virtually the same semantics, same styling, same JS interactivity hooks. And the issue is compounded by SVG not just being XML, that it is also a DSL (NB solution is normally to restrict to a subset of features), so the clean structure breaks down pretty often. Imo SVG has to be the way it is, that the tradeoffs of the bastardised XML it uses have to have been made for it to be actually useful. Those tradeoffs also make it difficult to use, and often very difficult to parse easily. But without changing how HTML works, how web browser rendering works, I don't see how there are any alternatives that are substantially better.

I think the other desiderata mentioned in the original post are more important than choice of serialization format. SVG already exists, and we're kind of stuck with it. There are other applications where having a better-designed vector graphics format might pay off, and tying it to the browser all over again wouldn't be a win.

At that point, using an s-expression format (x-expression, EDN, I'm agnostic) should be the first choice. One of the first things that would have to be implemented, of course, is a translator to SVG.

My interest in vector graphics is such that, on the few occasions I need them, I just shrug and deal with the format we have.

> The fact that SGML-based formats managed to become as popular as they are is really proof that there's something fundamentally rotten in software engineering.

HTML is a pretty good syntax though. SGML-like syntax is just less appropriate for formats which are not text-centered, since the element/attribute distinction becomes superfluous noise in the syntax.

I agree, HTML is fine (still a bit too verbose IMO, in particular having to repeat the tag to close it always felt useless and very noisy).

But HTML is a markup language, the problem is that for some insane reason a big chunk of the industry at some point decided that XML was a reasonable serialization format. That's where it went really wrong IMO.

In HTML you can leave out the end tag in cases where they can be unambiguously inferred, like:

   <p>First paragraph<p>Second paragraph</p>

P-element can't be nested, so a <p> will automatically close the previous p-element.

But this also means it is necessary to indicate the tag name in the closing tag. For example this would be ambiguous:

   <div><p>Hello</>

It cannot be inferred if it is the div or p which is closed.

XML is of course different. Since all element have to be explicitly closed, repeating the tag-name in the close tag is in principle superfluous. I think it makes it easier to read though, at the cost of more effort to write.

> "well fuck it, we'll just jam it all into a string.

This is an almost universal disease of people trying to write XML grammars (or database schemas before that). Everyone thinks they can unambiguously decode multiple pieces of data stuffed into the same fixed-width field, and pretty much all of those people are wrong. Over, and over again.

That they never learn is a testament to the developer's ability to make fixing their Kruger-Dunning moments Someone Else's Problem. Get promoted or switch teams before the consequences are unavoidable. You can make an argument that even Tim Bray did this.

There are a lot of reasons XML was never going to succeed, and this is far from the most important, but it's a substantial contributing factor.

So one reason for XML failing is that people who nominally used XML didn’t fully use its capabilities to capture data structure and kept their habits from the days of representing all data by fixed-width records?

XML and Java both come out of the same era. Java was supposed to be Object Oriented, but what we got instead is stringly typed code.

Array literals in programming languages are pretty much as compact as you can get (start, end, one character element separator), and the type system or a little code often allows you to fix a 1:1 mistake after the fact. This attribute is now a number or an array of numbers.

In XML if you want a properly formatted list you have to use child elements, which gets expensive really quickly so people balk. Especially if you already failed the attribute/child test by mistaking the value for 1:1 when it turned out to be 1:many.

We also already have HTML class, style, and on* attributes as prior art that we use to convince ourselves that one more will be okay. Basically XML gets it from both ends. XML makes entity relationships and irreversible decision, in an era where UML existed and harped constantly on it.

I don't know if there was any fixing it at that point. What I do know is that a lot of us shot meaningful glances at each other and tried as hard as we could to find something else to do until the dust settled. But you really could not avoid XML in the 00's.

> If you need to generate basic shapes it's fairly straightforward.

You'd think so. While integrating TeX into my editor[0], using JMathTeX[1] as a starting point, I wanted to convert font glyphs to vector paths. At the time, every Java-based SVG renderer (Batik, JFreeSVG, SVG Salamander) suffered from the exact same performance problem: they all used Java's DecimalFormat class to convert floating point numbers to strings. These strings were then concatenated as paths into the output document. Sometimes the strings were re-copied numerous times because of buffer re-allocations and other reasons. (Part 5 of my series[2] on developing a TeX-oriented text editor covers this in depth.)

To get great performance---in Java, at least---even for basic shapes requires a sufficiently large, reusable buffer that doesn't incur memory re-allocations and an efficient algorithm to convert floats to strings---such as Ryu[3]. See my implementation that converts glyph paths to vector paths for details[4]. With these two changes I was able to improve upon JFreeSVG's implementation four-fold.

[0]: https://github.com/DaveJarvis/keenwrite (my editor)

[1]: https://github.com/DaveJarvis/JMathTeX/ (my fork)

[2]: https://bell-sw.com/announcements/2020/11/02/TeXnical-Writin... (my blog series)

[3]: https://github.com/ulfjack/ryu

[4]: https://github.com/DaveJarvis/JMathTeX/blob/d2d678717505765b...

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.

For the note, Sciter (https://sciter.com) and Sciter.JS support inline vector images in its CSS.

Instead of SVG and things like FontAwesome in 99% UI cases we use just these

    button {
      background-image: url(path:M 10 10 H 90 V 90 H 10 L 10 10);
      fill: red;
    }

or

    <img src="path:M 10 10 H 90 V 90 H 10 L 10 10">

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?

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.

Along those lines, I recently encountered this project that enables the use of SVG to design maps etc for games developed with the Rust language game engine Bevy: https://github.com/carrascomj/bevy_svg_map

"The properties of the lines (color, opacity, fill...) can be used to programmatically add functionality..."

Yes, but SVG is not good as a machine-focused format as well, that's kind of the point.

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. <path fill="red"> becomes <path fill="var(--base)"> 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

i like the sun rays!!

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

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

> You don't edit raw png values either

However, for when you want that there is SNG¹. It can be a surprisingly fun way to perform minor corrections or filters to an image.

¹ http://sng.sourceforge.net/

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

Also, don't forget the inconsistency of being able to use units like `px`, `ex`, ie: `<circle cx="10ex" cy="10ex" r="2ex" fill="red"/>`, but it would be invalid in `path`. The unit in path is exclusively `px` only.

I think it would be nice to have a design language:

  def port 0,0 100,100:
    L 10,10 90,0 90,70 70,70 70,90 20,90 20,70 10,70 10,10
  
  def bank 0,0 400,100:
    port 0,0 100,100
    port 100,0 200,100
    port 200,0 300,100
    port 300,0 400,100

  def router 0,0 1100,200:
    port 50,50 150,150
    bank 200,50 600,150
    bank 650,50 1050,150
    
  router 0,0 1100,200

I was thinking it would be cool to have an "about" page in openwrt showing your router with all the ports labeled in svg. Should be simple, but I couldn't figure out luci.

Those things are not equivalent.

The circle has unordered properties.

The path has ordered commands. I suppose those commands could be separated and numbered, but isn't that a lot more verbose and less readable?

Agree a vector graphics format isn't the use case for markup languages. SVG's saving grace, though, is that's designed to be embedded in HTML.

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.

> <path d="M 10 10 H 90 V 90 H 10 L 10 10"/>

And that can be optimised further (by svgo) to:

    <path d="M10 10h80v80H10V10"/>

They can get almost hilariously dense and obfuscated.

I do not see what is wrong with the path string, which btw. is the same in HTML Canvas. I am using SVG on a daily basis and encountered many issues that annoyed me, but path data was never one of them.

I don't think it's wrong per-se, it's actually probably the best solution given the set of constraints. It was more about bashing XML's impracticality than SVG really.

The idea to stuff paths into attribute strings instead of using elements came from Microsoft's VML (one of the competing vector graphics standards that influenced SVG).

https://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Devel...

Pragmatically it was a brilliant practical compromise in response to one of XML's horrible flaws as a serialization format (it's way too fluffy), saving enormous amounts of memory and fragmentation by using one string per path, instead of creating thousands of DOM objects with tens of thousands of attributes and text nodes. But you're right, that's the "original sin" of XML that SVG is doomed to suffer with.

PDF is basically just the PostScript imaging model without the Turing-complete stack based programming language.

SVG is just the latest expression of PostScript graphics model (if you ignore all the stuff about fonts), which is based on the Stencil/Paint imaging model with Porter Duff Compositing, and descendent from Interpress and Jam).

The canvas 2d api is pretty much just immediate mode SVG / PostScript graphics, with a few new features added.

JSON's a much better format for structured graphics in some ways, but has its own set of flaws and limitation, like not having comments, and being terrible for binary data. But at least JSON arrays are a bit more (but not much) memory efficient than XML elements, and JavaScript itself has typed binary arrays, although standard JSON doesn't support them (using base 64 strings sucks). So representing paths as flat strings like SVG, instead of JSON arrays of numbers, is probably still a win for JSON if you're mainly drawing static paths, but not if you want to read, process or edit those paths a lot.

Now, instead of using SVG, it's usually easier and more efficient to just use your own (or some standard) JSON format for structured graphics, and draw it with the canvas api. But there will never be one universal JSON graphics format, just many special purpose ones. For example, d3 has a lot of different JSON formats (domain specific languages) for representing different kinds of graphics and data.

More on PostScript and its history:

https://news.ycombinator.com/item?id=21968175

>Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other:

https://groups.google.com/g/fa.laser-lovers/c/H3us4h8S3Kk

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

Maybe holds for XML, but not SGML. Its features such as SHORTREF and tag inference for eg parsing Wiki and other custom syntax into canonical angle-bracket markup (aka XML) are pretty much designed to be typed ergonomically and minimalistic, as popular as ever with markdown, etc.

XML is not an ideal format for computers.

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