Fast needs a mechanism for z-order management

[scomea]

A number of FAST components like tooltip need a mechanism to manage the css z-index attribute. We should define how we want to do this.

[CuddleBunny]

A passing thought I had for when I need to address this in my own design system was to have named z index layers available as design system properties and/or global css classes. Tailwind for example has classes like z-0, z-10, etc. but I imagine something like --stacking-layer-dialog: 100.

[scomea]

@CuddleBunny yeah, I was thinking along similar lines.

[nicholasrice]

The struggle I always have with absolute systems (and by that I just mean there are values like --z-index-dialog, --z-index-flyout, etc) is that it ignores the mechanics of how the stacking context really works and can quickly fall down when a new stacking context is created higher in the DOM tree. You can visualize what I mean here: https://codesandbox.io/s/serverless-worker-r2ihm?file=/index.html

I don't really have a solution to propose (this question has plagued me for years at this point) and maybe an absolute system is good enough, but I thought I would at least voice the issue.

[CuddleBunny]

@nicholasrice - I think this is acceptable behavior but most folks don't understand this so we should include a note in the docs warning against nesting the "layers"

[chrisdholt]

I'd also say, there may be some explorations (very early) that could be extracted to support a "smart utility" for certain contextual applications. Very ominous...ultimately I'd like to keep this in the "ice box" if we can a bit longer to track the underlying request and see what shakes out from those ominous explorations.

I would agree @CuddleBunny that documentation would be helpful here and likely contributing guidance as well.

[scomea]

Maybe a system where we have standard named layers that we can set defaults for a dirt simple base implementation, but allow for it to be changed contextually so that a dialog could change the values for its children.

[CuddleBunny]

@chrisdholt / @scomea - how might such a system work? As seen in the example above from @nicholasrice, it doesn't really matter if the nested stack has an explicit or contextual value. It will still never be on top. The only possible alternative I could think of is to have root level "portals" ordered by layer for such nested content to be re-parented into but that would come with its own set of caveats I'm sure.

[chrisdholt]

@chrisdholt / @scomea - how might such a system work? As seen in the example above from @nicholasrice, it doesn't really matter if the nested stack has an explicit or contextual value. It will still never be on top. The only possible alternative I could think of is to have root level "portals" ordered by layer for such nested content to be re-parented into but that would come with its own set of caveats I'm sure.

Correct - my ominous "hand-wavy" exploration language would be more related to host element z-index work.

[scomea]

The only way such a system "works" is by authors structuring their apps to make it work, taking into account constraints that Nick points out. Elements that need to be stacked over each another using z-index would need to be in the same stacking context. For example an element in the "foreground" z-index of a dialog would not necessarily be in front of other elements outside the dialog. I've had the notion that at some point we could build "container" elements like dialogs/panels that had some built in helpful stacking mechanisms. WPF panels had an "adorner layer" where authors could project foreground widgets, for example. Maybe we just live with setting arbitrary CSS z-index that authors can easily override until we want to tackle something like that. But we should at least have some convention for the default values of our components. The difficult problem of how nested elements break out of their parent container to be in the "app" foreground, like a select menu in a dialog involves more than z-index.

[KingOfTac]

I don't know if this will have any value, but I have an attempt at z-order management that tried to work around these issues. It has some issues, but it could be a starting point for a more comprehensive solution.

https://gist.github.com/KingOfTac/db62e14f1e7629343cee3cc47a6bab1d

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[chrisdholt]

closing for now given #5853