Hacker News Reader

Comment by onion2k | Hacker News Reader

SVG has no support for z-index in the spec. SVG renderers draw everything from the back to the front reading the elements as they appear in the doc tree - if you want put something on top of something else you have to move it down the document.

In my previous role I worked on a React app that was essentially just a big SVG editor for lawyers to make legal step diagrams (complex maps of legal structures that define how they change over time). Our solution to the z-index issue was to make extensive use of React portals to things lower down the doc tree when they were in focus. It worked really well, but I would have killed for proper z-index support. It would have greatly simplified my code.

I don't really care about the GPU acceleration; adding layers to SVGs is an amazing change on its own. Kudos to the team behind this. I hope it gets adopted everywhere.

View on HN

> Our solution to the z-index issue was to make extensive use of React portals to things lower down the doc tree when they were in focus.

I’m curious why you went with portals? Seems to me you could use the normal render cycle to control order (keyed if you intend to just reorder siblings).

> I don't really care about the GPU acceleration; adding layers to SVGs is an amazing change on its own.

I may be mistaken but in my reading of the article, my understanding is that SVG layers are only about acceleration, and don’t change the stacking semantics of SVG elements. But maybe I missed something.

I’m curious why you went with portals

We had to move things to the front of the SVG no matter where they were in the document. If it was just siblings it'd have been much easier.

Also, these are complex SVGs. On a large diagram there can be 50,000 elements in the SVG. Portals made it simpler.

This article is just about acceleration and stacking is not introduced. WebKit's architecture ties together the concepts of stacking and acceleration. A positive effect is that it will be quite easy to support stacking in SVG with this work.

A negative of joining the concepts of stacking and acceleration is that it is difficult to get acceleration without introducing paint order bugs where the accelerated content starts painting above non-accelerated content.

The lack of z-index in SVG is such a drag. I'm working on a (relatively simple) project - think Figma in terms of interactions - and the hackery is inevitable and immediate when trying to deal with this. A hybrid approach of multiple SVG objects in a HTML tree seems to be working so far, but it's far from pretty.

It was in earlier SVG2 drafts, but was dropped due to the lack of implementation, see here: https://www.w3.org/TR/2015/WD-SVG2-20150915/render.html#ZInd...

This is a digression, but I'm really curious what you mean by a "legal step diagram". It sounds like a fascinating concept, but all I could find on Google were process flowcharts. Can you point me at more info on these? Thanks!

Step diagrams are what lawyers call flow charts, but with a design convention language that's a bit like UML, and with tons of meta data attached to each element. There's also a time dimension as you can step through to see each stage of a legal process.

I understand what they are as a dev but I'm not a lawyer so I can't point you to anything more unfortunately.

Was this company called Checkbox?

It's a subset of process mapping specific to the legal area. Since there is no agreed upon convention for process maps everyone does their own thing and calls them slightly different things. I tend to just use the six sigma convention even for non six sigma things.

AFAIK, SVG2 was supposed to bring that in line with HTML (or rather, CSS' z-index).

Is SVG2 actually coming or is it in Limbo?

It totally depends on the implementors, if no one implements it, it won't come. If nobody does the first implementation, no other vendor will follow - it's as easy as this.

For WebKit/SVG, features as z-index are easy to implement in the layer based SVG engine - it's currently disabled, but only because it's lacking dedicated tests: I'd still need to write new reftests covering that.

I remember a article already quite some years ago, expressing much frustration with that. Basically the spec is complicated - and the vendors were unwilling to integrate more complexy. And that seemed to not have changed. Most parties are just interested in making things faster and more stable. (And then one bright day, implement a better, cleaner designed 2D vector standard)

It's been a while since I've done any SVG, but it seems like you could just create a grouping element for each layer and not put any graphical elements in the doc root.

Reply on news.ycombinator.com