If you build websites, you inevitably run into problems. Maybe there’s no way to achieve an aspect of your design using CSS. Or maybe there’s a device feature you really wish you could tap into using JavaScript. Or perhaps the in-browser DevTools don’t give you a key insight you need to do your job. We want to hear about it!
title: A CSS based way to move elements to specific z heights / layers
date: 2022-03-01T21:17:50.173Z
submitter: Andrew Trefethen
number: 621e8d7eeaf4cd00af7b438b
tags: [ ]
discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/
status: [ discussing || in-progress || complete ]
related:
Currently in CSS, we have stacking contexts, z-index, and composite properties. These features interact in often unpredicted ways.
What I would like to see is a CSS property that can specify an absolute, or relative z height for stacking purposes. Importantly, unless a z-height is present, the elements z-height is inherited from it's parent. The Body tag would have a z-height of 0. Items which have the same z-height would stack according to the normal context stacking rules. So on sites that are unmaintained, nothing would change. In newer, maintained sites, z-height can be used to get more predictable overlapping between elements. Importantly, this allows overriding of the default z-index behavior of an element. This is specifically useful for situations where stacking context make setting z-index irrelevant as no z-index will bring the element in question on top of the overlying element.
Examples would be specifying z-height on modals regardless of where they may appear in the markup. Currently, modals are best put at the END of the markup as that allows them to overlay all other content thanks to stacking context rules and judicial use of z-index. This keeps certain use cases from being developed, such as a modal packaged with a custom component that is useful everywhere because said modal may be unable to get to the top of the stack if later elements have a higher stacking context.
This becomes even more useful once you consider that use of certain composite properties automatically create a new stacking context regardless of developer intention. The usual way to create a new stacking context is the give an element a position other than static (the default) and then specifying a z-index. However, using a Composite property on an element will ALSO create a new stacking context. Composite properties include: opacity, transform, and more recently any property marked as "Will Change".
Stacking Contexts and z-index have created an implied vertical stacking of elements to increase site usability, performance, and use-cases. It is time that we formalize a explicit vertical stack that we can use to better manage our applications UI.
The proposed syntax could be:
z-height: (Number)
The Number could have a prefix of + or - changing the declaration into a unit relative to the element's parent. A Number lacking said prefix would move to the specific z-height specified. Elements sharing a z-height would stack according to the preexisting stacking rules / implementation. Use of z-height should likely be limited to avoid excessive GPU calls (I am not an engine maintainer, so the details of HOW or IF these calls could be batched would be left to them to determine).
title: A CSS based way to move elements to specific z heights / layers date: 2022-03-01T21:17:50.173Z submitter: Andrew Trefethen number: 621e8d7eeaf4cd00af7b438b tags: [ ] discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/ status: [ discussing || in-progress || complete ] related:
title: url: type: [ article || explainer || draft || spec || note || discussion ]
Currently in CSS, we have stacking contexts, z-index, and composite properties. These features interact in often unpredicted ways.
What I would like to see is a CSS property that can specify an absolute, or relative z height for stacking purposes. Importantly, unless a z-height is present, the elements z-height is inherited from it's parent. The Body tag would have a z-height of 0. Items which have the same z-height would stack according to the normal context stacking rules. So on sites that are unmaintained, nothing would change. In newer, maintained sites, z-height can be used to get more predictable overlapping between elements. Importantly, this allows overriding of the default z-index behavior of an element. This is specifically useful for situations where stacking context make setting z-index irrelevant as no z-index will bring the element in question on top of the overlying element.
Examples would be specifying z-height on modals regardless of where they may appear in the markup. Currently, modals are best put at the END of the markup as that allows them to overlay all other content thanks to stacking context rules and judicial use of z-index. This keeps certain use cases from being developed, such as a modal packaged with a custom component that is useful everywhere because said modal may be unable to get to the top of the stack if later elements have a higher stacking context.
This becomes even more useful once you consider that use of certain composite properties automatically create a new stacking context regardless of developer intention. The usual way to create a new stacking context is the give an element a position other than static (the default) and then specifying a z-index. However, using a Composite property on an element will ALSO create a new stacking context. Composite properties include: opacity, transform, and more recently any property marked as "Will Change".
Stacking Contexts and z-index have created an implied vertical stacking of elements to increase site usability, performance, and use-cases. It is time that we formalize a explicit vertical stack that we can use to better manage our applications UI.
The proposed syntax could be: z-height: (Number)
The Number could have a prefix of + or - changing the declaration into a unit relative to the element's parent. A Number lacking said prefix would move to the specific z-height specified. Elements sharing a z-height would stack according to the preexisting stacking rules / implementation. Use of z-height should likely be limited to avoid excessive GPU calls (I am not an engine maintainer, so the details of HOW or IF these calls could be batched would be left to them to determine).
If posted, this will appear at https://webwewant.fyi/wants/621e8d7eeaf4cd00af7b438b/