An interactive guide to SVG paths | Hacker News Reader

An interactive guide to SVG paths

nan.fyi

343 pointsnansdotio39 comments

This SVG path editor is incredibly useful if you're building or editing SVGs by hand: https://yqnn.github.io/svg-path-editor/

You can also do this in inkscape (although you have to hand-edit if you want to really optimize it)

I've built so many custom SVGs in Inkscape - I used to be an expert at it, but that information evaporates QUICKLY - and I open inkscape, and I cant even recall the mappings any longer...

But inkscape had a lot of really fast keybindings that helped me on many a huge project...

Yes but what I really like of that tool is that it "dissects" the entire d parameter into its bits and it's much easier to understand what's going on, and draw "parametrically" stuff - whereas with Inkscape the process is way more organic and you just can pretty much forget about the innards of it.

SVG is quite nice.

It would be a lot nicer if the proposal for SVG 2 was ever adopted, but that has been stuck in draft for years. https://svgwg.org/svg2-draft/

What are the key differences?

Why hasn't it been?

Here's a feature I desperately wanted a dozen years ago. Browser vendors kind of lost interest in improving their SVG support around that time.

https://dev.w3.org/SVG/modules/vectoreffects/master/SVGVecto...

It's quite perplexing when SVGs have a lot of potential in responsive UX. I don't get it.

Browser vendors seem to prefer SVG to be a somewhat dumb vector format and already hate many of the more complex parts. SVG 2 originally intended to have a bunch of more interesting features, but eventually resistance from implementors (mostly browsers) whittled it down to some clarifications of the spec along with a bit of CSS/HTML 5 harmonization.

SVG 1.1, the last widely supported standard, came out in 2003, and the web has changed a lot in 20 years.

There are a lot of changes (probably a factor in lack of support) but broadly it is to bring CSS support to SVG, that the browsers have been doing for years.

I worked on a side project to learn SVG and the two biggest features that SVG 2 has is

* support for z-index. SVG elements are currently rendered in the order they are written in markup. This is very annoying if you have common groups of things that interweave with other things visually; but you can’t put them under a single element to select.

* HTML style text rendering. Today in HTML, you can have text respect a container’s width and break to newline when needed, and you can align any corner of a text element to the general CSS box model. SVG text does not have a way to specify a width, and you can only align to the baseline of the first line of multiline text. This is very infuriating.

—-

The major reason for lack of progress is that updating the w3c standards is like herding cats; and SVG needs to include the professional authoring tools that produce it, which is the 800-pound gorilla that is Adobe Creative, and everyone else trying to eat Adobe’s lunch, so it’s hardly a cooperative bunch.

I may be talking out my butt ; but, wouldnt it be cool - if you had a slicer that made individual layers for visible elements on base elements, where, when stacked, you can hit a button and make all the sub layers for the components from such that were visible in the final image?

Does exist?

Yes!

What I was poorly articulating was the need for you to have that final stacked image with Z positioning, then be able to still have the visibly layered elements turned into their own layer for their own cutting (assume you have a partion of the model which is in background, and you want to chop that shape to its own element, such that you can cut/print on different colors/mediums, but have it still hit the image...

It should take the VISIBLE parts of an element in the final satack, then create layers for each of the components from each layer, then provide a template for printing out mass numers of each component in a zero waste model to allow for more

I'm not quite sure what you're getting at, but that's effectively what the current model forces you to do, to specify the elements in order that they go on top of each other. This is very bad.

I would rather have z-index so I can group elements how I want and use z-index to dictate the final display order.

If the z-index worked as in CSS it wouldn't actually help with that. It would have to work relative to the root SVG instead of relative to the current stacking context.

>This is very annoying if you have common groups of things that interweave with other things visually; but you can’t put them under a single element to select.

I'm not sure I really understand what you're saying, you can put a group of paths etc. under a group element and then manipulate the display of that group. You can't control their z-indexing it's true but I've achieved relatively complex and pleasing interactions with this method.

I guess I see the point that it would be nice to control it, as I normally want to be able to control everything it would be a bit hypocritical to suddenly say no you don't need to, but I would note one benefit of current SVG's approach is you don't end up with the fighting about z-index you get every now and then in HTML where suddenly things overlap and it is hard to figure out in code where or why, in SVG things overlap because one element is above another and are occupying the same x,y.

Say you have a transit map with lines, stops and labels. You always want lines below stops below labels, but that also makes it impossible to group a specific line’s stops and labels together without just totally going on top of a different line’s group. Which then makes interactivity annoying.

thanks, good use case, I tend to use it for aesthetic effects rather than data visualization.

For me, the biggest benefit of SVG 2 would be multi-line text support. Currently, if you are generating SVG with text blocks, you have to pre-calculate the bounding box of any text and add your own new lines.

Outstanding summary; thank you.

It's a shame because SVG is amazing. I came to web development from the art/design world, and I'd been using Adobe Illustrator for years. I was really excited to learn that I could program vectors, but was shocked to learn how little the average developer knew about them or SVG (at the time).

A few months ago I looked into how to do an angled gradient in SVG and was baffled that is isn't supported. Now looking at this spec, it's also not in there. Why the hell is this something nobody talks about. Photoshop has it since ages...

It's definitely supported via the `gradientTransform` attribute on e.g. linear gradients, as in this example: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/lin...

I think they’re referring to conic gradients, also known as angular gradients which SVG doesn’t support.

Love the detail and thought that has been put into this post, along with the other blog posts as well. Visualizations and animations go along way. A very ascetically pleasing site that is informative as well.

I agree on the aesthetic quality of the entire site.

Given the amount of detail included in the post, I was surprised that the author didn't mention that the primitives used in the d attribute for the <path> element allow one to synthesise most of the other SVG elements ... or did I just miss that somewhere?

Also good: https://svg-path-visualizer.netlify.app/

That one might even be better for some people.

Beatutifully made guide.

The numerical represention of Bezier curves is quite a challenge to internalize and the clean interactive canvas helps build some intuition.

Vector graphics and SVG deserve far more love.

If you are looking for solid content on Bezier curves then Freya Holmér's video on The Beauty of Bézier Curves [1] is well worth the time it takes to watch.

1. https://www.youtube.com/watch?v=aVwxzDHniEw&ab_channel=Freya...

Back when I helped out on the assembly instructions for the Shapeoko 2:

http://shapeoko.github.io/Docs/index.html

one of the things which was worked up was a way to make an SVG interactive:

http://shapeoko.github.io/Docs/content/tPictures/PS20028-100...

(click on part #11 in the list --- in retrospect the parts of the drawing itself should have highlighted the matching part entry in the list)

I like the explanations, but it's jarring to see Bézier treated with such little respect that he doesn't even get his name spelled correctly.

Specifically, the author wrote "bezier" in lowercase and without the accent.

There is https://svgbattle.andyfx.net

It has interactive editor, and introduces the available commands/shapes.

Its not really a guide but it has links to relevant parts of svg specification which honestly has pretty decent images and such for understanding the commands.

Excellent tutorial!

The hands-on practice built into each page is brilliant. I wish more tutorials were like this!

Excellent use of scroll jacking here

Amazing guide, love how "tactile" the animations feel!

Not sure if it's me, it says NaN above the title, and the button that says "Bend!" or "Straighten" doesn't actually do anything. I've tried multiple hard refreshes.

> it says NaN above the title

That is the name of the blog, the domain is nan.fyi.

NaN is the name of the blog. The animation is working for me on iOS Safari, but the text isn’t aligned perfectly.

This happened to me, too. You have to scroll down to get the Bend/Straighten button to work. Basically, the visuals on the right side of the page correspond to what part of the instructions you have scrolled top the top.

The NaN fooled me too, before I realized it was in the domain name too and must just be the name.

Reply on news.ycombinator.com