2021/09/25 : z-index 에 관한 고찰

z-index를 사용하면 요소들의 쌓임처리를 하는것이 유용하다. 마치 치트키처럼 느껴질 때가 있다.

다른 사람들이 z-index를 지양하는게 좋다고 했어도, 애니매이션을 주려고 혹은 직관적으로 쌓임맥락을 확인할 수 있어서 사용했다.

 

그러나, z-index의 예상치 못한 동작은 나에게 유지보수의 어려움을 한층 더해주었다.

 

일단 z-index가 아무리 낮아도 position: relative를 가진 엘리먼트는,

z-index: 100이고 position: relative속성이 없는 요소보다 상위에 노출된다.

 

나는 position: fixed인 엘리먼트 뒤로 위치하게 의도했는데, 전혀 다른 동작이 나타난것이다.

처음에는 봐줄만했으나, 이러한 요소가 많아질수록 z-index를 상수로 관리하여도 코드가 더러워지는 현상이 발생하였다.

 

그래서 과감한 결단을 내렸다.

꼭 필요한 z-index만 놔두고, z-index가 없어도 리팩터링을 통해 정상동작시킬 수 있는 부분은 z-index를 제거하기로 했다.

 

z-index가 없어지면, position: relative가 가장 최상단에 노출되므로, relative속성도 최대한 줄이려고 했다.

실제로 필요없는 relative가 꽤 있었다.

 

하지만, position: relative를 포기할 수 없는 요소들도 있었는데, 하위 항목이 부모의 relative 좌표에 의존하고 있는 경우였다.

현재 모달같은 큰범위의 요소들은 position: fixed로 관리하고 있었는데, relative와 fixed가 겹치면 relative가 상단으로 나오기 때문에 z-index를 사용해야만 했다.

 

여기서 또 과감한 결단을 내렸다. position: fixed의 사용을 지양하는 것이다. fixed는 absolute로 최대한 대체할 수 있을 것이고 그렇게 되면 순차적으로 쌓임맥락이 쌓일 것이라는 판단에서였다.

 

이러한 문제를 해결하기 위해, 나만의 원칙을 설정했었다.

 

fullscreen용의 modal을 만들때를 제외하고는 fixed를 쓰지 않으며,
fixed를 사용했을 경우, 최대한 relative 속성과 겹치는 경우를 피하되,
어쩔 수 없이 겹치는 경우 z-index를 1까지 허용하여 사용한다.
z-index가 2 이상으로 필요한 경우, 설계가 잘못되었을 수 있으니, 재검토한다.

 

하지만 이 원칙은 나중에또 수정되었다.

왜냐하면 쌓임맥락이 예상치 못하게 동작하는 경우가 많았기 때문이다.

relative도 그렇고, opacity, transition, transform도 그렇다.

 

생각해보니, z-index는 나쁜게 아닐지도 모르겠다.

무조건 지양하자니, 불가피한 상황에서는 사용해야할것이고, 다라쓰같은 범용적인 삽입형 서비스는 어떠한 웹사이트에서도 정상적으로 동작해야하기 때문에 z-index가 필요하다.

(어떤 사이트의 모든 요소가 z-index: 999이면 동작안할수도 있는 버그가 있을 수도 있기에)

예시로, Disqus는 z-index로 2147483647를 주고 있다.

 

때문에, z-index를 너무 남용하지 않으면서도 z-index를 적절히 사용하여 유지보수하기쉽고, 범용적으로 동작할 수 있는 코드를 조금 더 고민해보아야겠다.

 

 

https://github.com/woowacourse-teams/2021-darass/commit/7b3847ca43461753eb7c1545036c38365a5f8b29