Csswg-drafts: [css-position] 'front' & 'back' keywords for z-index

[jonjohnjohnson]

https://drafts.csswg.org/css-position-3/#propdef-z-index

How many times have you written things like z-index: 999999 or z-index:-999999?

If you work on the design side of the field you may be familiar with phrases like "bring to front" or "send to back" and though it doesn't take too long to understand layering in browsers (I think most of it's nuances were beat like a dead horse in articles 5 to 6 years ago, just google 'css stacking context'), I think people either know and set their sequence of z-index values meticulously OR they just want to send something to the front or back.

So why not support a simple (not as easily broken as 999 or 9999) set of the keywords front & back that explicitly accomplish the task they are named for, while still honoring their place in the local stacking context and document order?

https://github.com/w3c/csswg-drafts/issues/2202#issuecomment-368264480

[tabatkins]

We've historically rejected this, because as soon as you add front, people are going to want to put things at front + 1, etc. ^_^

A more reasonable approach is to make z-index take a space-separated list of numbers, and position is determined by comparing the lists piece-by-piece.

This way, if you want to put something in front of z-index: 1, you can write z-index: 1 1; if you want it be behind, you can write z-index: 1 -1. (z-index: 1 and z-index: 1 0 are identical; they'll sort in document order as normal for things with identical z-index values.) This way you can divide your document into layers via the first value, then sort them within each layer with the second value, without having to predict ahead-of-time how many items will be on each layer.

(And if you need to sub-divide, you can add a third value, or a fourth, as necessary.)

[jonjohnjohnson]

I understand that as a solution to when people need to shuffle around values making space for things in between, not as a solution for say a plugin to set it's place in front of the stack, without having to scrub through layers to find the highest z-index value at it's context and then set it's own to that value plus 1? Or are you thinking that the best solution to "definitely the front" is something like z-index: 999999 999999 99999? Though I can imagine people asking for "infinity + 1" features, I also think stopping at +/- infinity would still be useful for authors in accordance with the order of the document.

[tabatkins]

There's no such thing as "definitely the front"; as soon as you think you want that, you're going to immediately afterwards want to put something in front of that.

The multiple-values-in-z-index thing, tho, lets people organize their page into layers without having to do silly things like using 1000, 2000, 3000, etc.

You can also use custom properties to organize things into named layers, so that you can say z-index: var(--z-top-layer); without having to worry about precisely what value that resolves to. (And with the extended z-index, you can write z-index: var(--z-top-layer) 1; to go on top of the top layer, etc.)

[jonjohnjohnson]

And one day you may decide that you need something above what others on your project might try to put above var(--z-top-layer) with the lists, so you write z-index: calc(var(--z-top-layer) + 1);. I get what your saying about getting rid of 1000, 2000, 3000 craziness. The feature you describe sounds perfect for solving that issue. I guess I'm just putting more weight on the issue of "definitely the front", thinking that having something like a mathematical limit being more beneficial than not.

[Loirooriol]

How many times have you written things like z-index: 999999 or z-index:-999999?

Since I learnt how stacking contexts behave, (almost) never. I think such absurdly high numbers don't really make sense because the index is local.

Allowing tuples with lexicographic order may be useful indeed, but I'm afraid that since nowadays people use z-index: 999999, they may switch to z-index: 999999 999999 999999 999999 999999 999999 999999.

[Crissov]

Why not introduce explicitly named layers with their own at-rule then?

````
foo {z-index: bar;}

@layer bar {…}
````

[SebastianZ]

Why not introduce explicitly named layers with their own at-rule then?

foo {z-index: bar;}

@layer bar {…}

Sounds like a good idea, though what is the at-rule expected to contain?

The idea of having front and back keywords is also something I thought about previously, though as Tab already pointed out, there may be cases where you'd then like to put something even more in the front.

Those keywords can easily be abused, e.g. by ads you integrate into your site and then you're not able to put anything else in front of them.

Also, how to handle multiple elements having set those values?

Sebastian

[jonjohnjohnson]

@SebastianZ I'd imagine there's nothing wrong with handling it the same way we already handle multiple elements with the same z-index values in the same stacking context, we let the document order be the last defense? These keywords could at least be *some control over a need to put one element in front or behind everything.

As far as the ads example, people can always choose to run "broken" ads if they want, at least the ad might thrash the users experience a bit less this way?

Though I understand @tabatkins reservations in people misusing this, like is often already done with z-index, it would be nice to have a way to more easily find the front or back of a stacking context.

Even if we never get this in css land, it could be nice to have an api for a documents stacking contexts and their non-auto participating elements, without having to run gCS up and down.

[Crissov]

@SebastianZ Initially, the @layer rule would probably not contain much, perhaps a background and size, but it could be extended to be like layers in image editors, i.e. blend modes etc.

[SebastianZ]

Initially, the @layer rule would probably not contain much, perhaps a background and size, but it could be extended to be like layers in image editors, i.e. blend modes etc.

Thinking more about that, I believe there's no need for an @layer rule. Layers are already created via the stacking context. And the z-index property's purpose is to influence the order of the stack level, which can be seen as a layer. And background blending can already be achieved via the mix-blend-mode property.

As far as the ads example, people can always choose to run "broken" ads if they want, at least the ad might thrash the users experience a bit less this way?

Website authors often use advertising frameworks, they don't choose the ads by themselves. And there are always bad providers that try to abuse things like this.

I'd imagine there's nothing wrong with handling it the same way we already handle multiple elements with the same z-index values in the same stacking context, we let the document order be the last defense? These keywords could at least be *some control over a need to put one element in front or behind everything.

Sure, I'm personally not against adding them, it's just that they can easily be abused.

It's then up to authors to use them wisely. And if used that way, they'd avoid those arbitrary high numeric values in a nice way. @tabatkins From a spec. writer and implementer view, does there anything speak against introducing those keywords?

Sebastian

[jonjohnjohnson]

Even if...

It's then up to authors to use them wisely. And if used that way, they'd avoid those arbitrary high numeric values in a nice way.

...is decidedly not worth the effort, maybe we could swap this issue/title over to the question of lexicographic order to solve for rebalancing, which would still be immensely helpful.

[tabatkins]

Punting to the eventual Stacking Context spec, now that we've removed that section from Positioning.