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.
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.
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.
I understand what they are as a dev but I'm not a lawyer so I can't point you to anything more unfortunately.
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.
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.