<sub> and <sup> stick in front of modal

[mokhosh]

I have a sub element on my page, and when I create a modal that is a relative div with z-50 the sub still sticks in front of it. I even tried z-index: 99999999999; in the dev tools, no luck.

When I remove position: relative from sub styles it goes behind.

I know you're hard resetting browser styles, but this is a problem.

[tlgreg]

Stacking context can be hard to deal with, for modals usually it's best if they are used at the end of the document.

Tailwindcss uses the fairly widely adopted normalize.css as a base (+SUIT and some of its own).

This rule is also part of normalize.css from pretty much the beginning (8+ years ago), not sure tailwindcss should change this behavior.

[mokhosh]

Thanks @tlgreg for the answer

Well my modal is part of a component that has to be put before the sub element.

Whoever is putting position on simple static elements that should not be positioned is wrong, no matter who they are and for how long they have been doing it. Bad hack.

[adamwathan]

Can you share a demo that reproduces the issue? It sounds like it would be fixable by adding a position and a z-index so want to understand why that's not working.

Either way not going to change this rule in Tailwind because we don't want to deviate from normalize.

[mokhosh]

@adamwathan sure thing:
https://codepen.io/mokhosh/pen/JjdQGPx

I don't understand why you're making a god out of normalize here. If they're doing the right thing and I'm doing something wrong, I'll learn it and be grateful, but if they're doing something wrong, why should we just keep doing it because normalize has done it?!

[tlgreg]

In this case, a z-10 on the fixed element should raise it above the following elements.

The issue here is that the elements are on separate stacking context and z-index has an effect inside the same context. In this example, the fixed position creates that stacking context, so anything inside it will appear below the positioned elements that come after. The z-index inside just changes the order inside.
The fix is to raise the z-index of the wrapper itself so that appears above the following elements.

---

Honestly stacking context and what creates one and what doesn't can confuse me sometimes, but in most cases, it can be worked around.

If you want to read some about z-index and stacking context:

• MDN page has a good list what creates a stacking context (and explanation):
  https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
• Might be a quicker explanation by Philip Walton in this article (what creates a stacking context is outdated though):
  https://philipwalton.com/articles/what-no-one-told-you-about-z-index/
• A chrome extension to inspect stacking context/order:
  https://chrome.google.com/webstore/detail/z-context/jigamimbjojkdgnlldajknogfgncplbh

---

About normalize.css. Positioning sub and sup was added with a reason to it. sub and sup by default is done with vertical-align, but that affects the height of that line which causes a break in the vertical rhythm.

This was fixed by normalize with resetting back the vertical-alignment of the elements and position them instead. This change has its pros and cons and can be considered a more opinionated one, but definitely not straight wrong.

If there is a better solution which doesn't have such a drawback but does the same job it definitely can be considered. Though I'd add it to normalize.css itself.

[mokhosh]

In this case, a z-10 on the fixed element should raise it above the following elements.

That did cover the sub but created a dozen other stacking problems and I had to fix them by sprinkling more positions and z-indexes, which is exactly what is so frustrating about normalize.css's approach.

This change has its pros and cons and can be considered a more opinionated one, but definitely not straight wrong.

I understand that we have to make compromises here, and I think the idea is, wanting a pixel perfect line alignment is a more common scenario than a sub sticking in front of a modal.
But I think we can also agree that this is a very hacky solution that can introduce very unexpected results and create many cotchas that have to be fixed with even more hacks.

Thank you for taking the time @tlgreg