Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-position] 'front' & 'back' keywords for z-index #2444

Open
jonjohnjohnson opened this issue Mar 15, 2018 · 11 comments

Comments

@jonjohnjohnson
Copy link

commented Mar 15, 2018

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?

#2202 (comment)

@tabatkins

This comment has been minimized.

Copy link
Member

commented Mar 15, 2018

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

This comment has been minimized.

Copy link
Author

commented Mar 15, 2018

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

This comment has been minimized.

Copy link
Member

commented Mar 15, 2018

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

This comment has been minimized.

Copy link
Author

commented Mar 15, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 16, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2018

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

foo {z-index: bar;}

@layer bar {…}
@SebastianZ

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2018

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

This comment has been minimized.

Copy link
Author

commented Jul 2, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2018

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

This comment has been minimized.

Copy link
Author

commented Oct 12, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.