Hacker News Reader

Comment by modeless | Hacker News Reader

The interesting thing about <dialog> is that it uses the "top layer" which always appears above everything else on the page regardless of z-index. So you can delete hacks like z-index:2147483647.

View on HN

Clarification: modal dialogs do this. Non-modal ones don’t.

How do people normally manage z-indexes? I've found it's usually a mess of a people hard coding a bunch of values all over the place.

Using CSS-in-JS we at least make constants so we can do stuff like: `const STICKY_HEADER_Z = TOOLTIP_Z + 1`.

I usually make modal position:fixed and use JavaScript to position them in the center or wherever. Same for drop-down menu’s when you click a button.

How does position:fixed help with the z-index?

Also doesn't this mean you have to listen for scroll events this way and update the XY coordinates for things like dropdowns?

"position: fixed" removes the element from the layout and positions it relative to the window. You can scroll the page any which way and the element will stay where it is on the screen, making it a good choice to handle X/Y positioning of the modal.

I asked how it helps with z-indexes not XY?

Also drop downs are "attached" to some element in the UI, and you probably want those menus to scroll with the page

"position: fixed" puts an element in a new stacking context, freeing it from the z-index of its parents.

The person you were responding to said they use "position: fixed" so they don't have to worry about z-indexes, and I was explaining why that works. See sibling reply for the more technical explanation.

You still have the issue of the z-index being relative to its parent, and not absolute. So depending on which element it is set, its effect would not be the same. It’s still a good practice to use constants, but I still often had difficulties to place elements relative to each others on the z-index.

Just use position: relative to start a new stacking context as appropriate.

I know, but it’s still hard to use on a big website where you have to manage a lot of stacking contexts.

You can use isolation: isolate to explicitly create a new stacking context now. It makes the code a bit clearer because position: relative is used for lots of different things.

In a previous life as a front-end developer using Sass, I had a single z-indexes module in which they would all be defined.

SASS/SCSS helps. CSS variables would work too, but they're a but unwieldy and using tons of calc() isn't great for performance.

Normally I just set z-index to 1. z-index is only relative to the parent so you can still have a z-index of 1 overflowing another z-index of 9000 because the parent of the latter has a lower z-index then its sibling: https://jsfiddle.net/ec5qp7n3/

Usually if I find that if I need to control more then one layer of stacking, I’m doing something that is unnecessarily complex, and the right solution is to go back and find a better design.

So no dialogs inside other dialogs?

Reply on news.ycombinator.com