201–210 of 228 posts
>like to write it by hand I'm honestly horrified that someone out there is writing SVG by hand.
Inkscape made a nice initial template, but lacked finesse and precision with naming, scaling, text-wrapping and nesting. Inkscape came up with a rather messy blurp of XML. No clear IDS, rounding errors, arbitrary nesting through groups, arbitrary ordering, etc.
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.
> No need for the x and y, really
The real ugly with SVG is how frequently we request SVGs from designers or companies and they hand us an SVG file that contains nothing but a base64 encoded PNG image.
Lot of vector editing programs just cheat when things get difficult. I have seen drop shadows as bitmaps, path intersections that become polylines with zillion line segments, elements that are just missing, you name it. Doing vector graphics is hard beyond basic shapes, and I have the feeling that some developers and companies underestimate what they are trying to do at the beginning and then have to rely on workarou…
Earlier quoted context omitted.
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 ` ` element would probably need to take an idref to something like a ` ` element. This is how I would guess the equivalent would be: EDIT: Come to think of it, the above is probably a lot easier to animate using CSS or SMIL. Animating the `d` attribute on ` `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…
I SVG is pretty inelegant, but it's pragmatical.
>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…
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 have been interested in the "low code" problem, in particular the kind of advanced parsers that were used in the 1990s to attempt things like "edit the UML diagram in a GUI and change the Ada source code the way a professional programmer would". Dreamweaver used to do this for HTML, sometime before it got bought by Adobe. Today Dreamweaver seems like it would be usable on a 90 THz computer but I can do 10 push ups…
Is this what you mean by groups? "The SVG element is a container used to group other SVG elements. Transformations applied to the element are performed on its child elements, and its attributes are inherited by its children. It can also group multiple elements to be referenced later with the element." https://developer.mozilla.org/en-US/docs/Web/SVG/Element/g
That is the most prominent tool one would use to apply "programming" or "architectural" discipline to SVG.
For instance you could make a that looks like a cat paw and then it to make a track of cat paws. That's more disciplined then say, "cut-n-paste" a cat paw you drew 10 times which a real artist might do, or I might do because I can always figure out how to do it with a drawing program.
Related to that is the use of CSS, which can range from beautiful code which is easy to understand towards a complete mess.
Earlier quoted context omitted.
> 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.
First paragraph
Second paragraph
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:
Hello
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.
Earlier quoted context omitted.
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)))
Earlier quoted context omitted.
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…
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).
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?
Often what you want is instead to generate an AST, in that case you will run into ambiguosness problems.