Fastneedsamechanismforzordermanagement

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.