Currently there is no direct concept of depth/z-index. LayoutTree uses purely incremental IDs and a sorted list of elements and the elements are rendered in this exact order. This has the effect that the last created element is rendered on top with the indirect effect that children always render after their parents. This system currently works mostly fine, except:
We want to be able to reuse element IDs in the future.
There is no option to force rendering ealier/later.
Currently we have to use a BTreeMap both for layout computation and rendering, which can be replaced with a more efficient Arena/VecMap if we can reuse IDs.
Potential options for depth/z-index:
Add an explicit integer "z-index" to all elements. What should the default be?
Add a integer "z-index" with an explicit default of "render after parent". This mimics the current behavior for explicit values.
Add specific "Top"/"Bottom" "z-indices" while retaining the current "render after parent" behavior for other unspecified values. Is this flexible enough?
Currently there is no direct concept of depth/z-index.
LayoutTreeuses purely incremental IDs and a sorted list of elements and the elements are rendered in this exact order. This has the effect that the last created element is rendered on top with the indirect effect that children always render after their parents. This system currently works mostly fine, except:BTreeMapboth for layout computation and rendering, which can be replaced with a more efficientArena/VecMapif we can reuse IDs.Potential options for depth/z-index: