stacking context와 합성

이번에는 누가 위에 그려지는가를 봅니다.

디자인 에디터에서 레이어 순서는 생명입니다. 사각형 A가 B 위에 있어야 하는데 브라우저가 반대로 그리면, 사용자는 바로 알아차립니다. “어? 왜 뒤로 갔지?” 이 한마디가 나오면 레이어 모델을 다시 봐야 합니다.

CSS에서는 이 순서를 z-index만으로 다 설명할 수 없습니다. 중간에 stacking context라는 지역 규칙이 끼어듭니다.

z-index는 전역 순위표가 아니다

처음에는 이렇게 생각하기 쉽습니다.

z-index가 크면 위에 그려진다.

대체로 맞지만, 항상 맞지는 않습니다. 어떤 요소가 새로운 stacking context를 만들면 그 안의 자식들은 그 지역 안에서만 순서를 겨룹니다. 동네 대회 1등이 전국 1등은 아닌 것과 비슷합니다.

새 stacking context를 만들 수 있는 대표적인 속성은 이런 것들입니다.

그래픽 에디터는 transform을 많이 씁니다. 그러니 stacking context를 자주 만들게 됩니다. 편집기는 이 점을 알고 있어야 합니다.

stacking context는 레이어 순서를 지역 단위로 봉인합니다. 자식 z-index가 커도 부모 context 밖으로 혼자 튀어나갈 수 없습니다.

브라우저 렌더링은 대략 layout, paint, composite 단계로 이어집니다. stacking context는 어떤 단위로 paint하고 composite할지를 바꿉니다.

렌더링 순서는 tree order + stacking context + z-index의 정렬 문제다.
opacity < 1, transform, filter 등은 새 합성 단위를 만들 수 있다.
hit testing은 보통 위에서 아래 순서로 후보를 검사한다.

mix-blend-mode, opacity, filter 같은 속성은 단순히 색만 바꾸는 것이 아니라 합성 방식에도 영향을 줍니다. 그래서 편집기에서 blend mode를 지원하려면 CSS 렌더링 규칙과 모델의 레이어 순서를 같이 맞춰야 합니다.

레이어 패널에서 위에 있는 오브젝트가 화면에서도 위에 보여야 합니다. 가장 단순한 방법은 DOM 순서를 모델 순서와 맞추는 것입니다.

model.layers[0] = back
model.layers[n] = front
render DOM in same order

필요하다면 z-index를 쓰되, stacking context가 생기는 지점을 의도적으로 관리해야 합니다. 특히 selection overlay는 content layer보다 항상 위에 있어야 하므로 별도 overlay layer로 분리하는 편이 안정적입니다.

데모에서는 z-index, opacity, transform이 레이어 순서와 합성에 어떤 영향을 주는지 봅니다.

오늘의 교훈은 이겁니다. CSS 레이어는 단순한 숫자 싸움이 아닙니다. 지역 규칙이 있습니다. 편집기를 만들 때는 브라우저의 stacking 규칙을 외면하지 말고, 모델의 레이어 순서와 의도적으로 맞춰야 합니다.