Hacker News Reader

Comment by bobthepanda | Hacker News Reader

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/

View on HN

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

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.

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.

Reply on news.ycombinator.com