Opacity, positioning type and layer stacking order



I’m trying to create a horizontal navbar with transparent background so that hero image shows through the navbar background. The problem is that the underlying image won’t show through, however I try to reorder it in Tree panel (layers). And no success, if I apply opacity to rectangle only (parent for navbar) or to entire navbar group. Putting image inside navbar below everything else shows only image - kind of makes it topmost? Playing around with Self-directed/Parent-directed won’t make it either.

Any ideas how to accomplish transparent navbar background? Or how to handle opacity-layers-layout in general?


Subform-file: opacity-test.subform (2.6 KB)

Moving Self-Directed Objects in the Workspace

Is this what you were looking to achieve? FYI the image won’t load because it isn’t bundled in the .subform file.’'opacity-test.subform (2.6 KB)

I agree the stacking order in Subform is a bit difficult to work with. I enjoy that it follows the default rendering order of markup, but there’s no way to override that with a z-index equivalent so far as I can tell.


Hi Silver,

A similar question came up in another thread: Unexpected arrangement in Layer Tree.

I posted some videos of possible solutions and covered how source order and stacking order (z-indexing) work together inside the app right now. If @alexhadik’s solution or that thread don’t help you, let me know.


There isn’t right now. I touched on a CSS-like z-indexing property over here. I’m open to implementing something along those lines—I’ve come across a couple cases where there isn’t an easy workaround (via containers or self-directed elements) to achieve a specific layout.

A few things that would help us on this front:

  • More example layouts where there’s no workaround to get the stack order / z-indexing correct without altering the source order
  • Thoughts on the CSS z-index property (Personally, my big gripe is that it’s difficult to keep track of and you quickly end up just entering ‘99999…’ as the value until the element comes to the top)
  • Any other prior art on separating source order from stack order in a usable way (other tools, etc.) that you like


I came across an example case yesterday working with drop down menus. I want a menu at the top with components that have a state which renders a dropdown. However - since the menu is at the top of the tree - so that it is stacked at the top - it is below its siblings in the z-index.

I think a z-index like property would work if the proper tools are provided to manage it. If it’s just a text property entry then the same problems with z-index in HTML arise. However if tools such as “Order Tree by Layout/Stacking”, commands to increase or decrease an element by a single bum, and collapsing the z-index so that there’s never a gap larger than 1 between sibling elements are provided - I think the problems would be mitigated.


Thanks for the example; that’s a good one.

Just to make sure I understand your ideas correctly: are you describing something like an implicit index value that can’t actually be entered (via input), but that each element can step through it sequentially?

In other words, every time you say “move this element forward,” the app is incrementing that index +1?

Right, so this is essentially how existing tools work. They’re able to sync the stack order to the layer panel order because they have no relationships or source order. But you’re suggesting that the tree be able to toggle between “source order / hierarchy” view and a “stacking order” view? Is that correct?


An implicit index value is a good way to describe it yes.

And yes - perhaps toggling the tree view will enable the best of both worlds. These are ideas that came off the top of my head. I haven’t thought them out at all.


:+1: I think they’re solid ideas. Thanks, Alex.


Alex, yes that’s it. And thanks Ryan for explaining the concept behind the Tree palette. I see now, it’s not the usual Layers. Was not so obvious for me.