Not sure if this is a bug or I'm just not using the Layer Tree correctly.
But basically, I wanted to create two seperate boxes, one being the status bar and the other being a header container. The header container has a slight drop shadow on it, but its overlaying onto the status bar box element.
Here's a screen recording of the problem on Subform: dropbox link
And here's how I would expect it to behave, recorded on figma: dropbox link
Btw: I'm on the latest release of Subform for Windows 10.
Hey Ryan, good question. There are a couple things going on here: z-indexing and source order.
Z-indexing
The z-indexing in Subform's tree is the opposite from how layers work in Photoshop, Figma, Sketch, etc. In those tools, the closer an element is to the top of the layers list, the higher its z-index. So a "bring to front" operation would move the element to the very top of the layers list.
Subform's tree works more like the default behavior of HTML, where elements lower in the tree are z-indexed above elements higher in the tree. So in your example, if the top element had the drop shadow, the bottom element would overlay it:
Source order
Your issue is a little trickier, though. If you move the box with the shadow above the other box in the tree, the z-index isn't the only thing that changes... the shadow box will also end up being the first thing in the vertical stack.
This is because the tree also controls source order: the order that elements are drawn in a stack.
This isn't an issue in Photoshop, Sketch, et al because they don't have layout engines. Elements don't have relationships to each other or orders, as everything is positioned absolutely. (Similar to how self-directed elements work in Subform)
Short term solution
As you've found, sometimes z-indexing needs to be independent of source order. Subform doesn't explicitly have a way to do that right now, but here's a couple workarounds for your example.
Make the status bar a self-directed element. A self-directed elements is out of the stack source order, so it can be z-indexed higher than the header container:
Another option would be to wrap the header element in another container. That container will have "clip children to parent" enabled by default, which will clip the header element's shadow:
Possible longer-term solution
It may be that—at some point—we want to provide a way for you to set z-indexing separately from source order.
This can be tricky to keep track of—if you've ever worked with CSS, you've probably found yourself giving up and setting z-index: 999999; because you can't figure out why an element isn't appearing on top. Over time, this cruft builds up and it can be tough to understand the z-indexing in your design.
I like to use a central map for z-indexing when I'm writing Sass. All z-index values go into that map and I can then reference a key that makes sense to me, e.g. z(header). It's easy to see what the layers are and change them in one central place to avoid conflicts. We could do something like this in Subform.
It's a bit similar to keeping track of a typography scale. Ideally, all the type in your design would draw from that predefined scale, so it's easy to make universal changes and describe the typography to the engineering team.
Thank you for such a detailed response!
I tried out the first option you suggested but then reverted to containing everything at the top into one container and threw the shadow on that.
Pretty cool how you related it to how html is structure, I didn't even think that could be the case but now I totally understand.
And yes, z-index always had me jammin' the keyboard in confusion/frustration!
I had the same impression. When boxes are placed one next to another, it is not so important, but, for example I put an image and a rectangle in a box and tried to figure out why I can not see the rectangle (which was above the image in the menu tree). I understand the idea of the source order but I think it would be misleading for those who are used to Adobe or Sketch interfaces.
Maybe should you consider letting the user to choose the order he/she prefers?
Just an update—we’ve resolved the z-order and source-order issues discussed in this topic in Subform Beta 4358.