CSS 석조술을 위한 대안 제안

Rachel Andrew

게시일: 2024년 4월 30일, 최종 업데이트: 2026년 2월 13일

Chrome팀은 웹에서 벽돌형 레이아웃이 구현되기를 바랍니다. 하지만 최근 WebKit 게시물에 제안된 대로 CSS 그리드 사양의 일부로 구현하는 것은 실수라고 생각합니다. 또한 WebKit 게시물에서는 아무도 제안하지 않은 버전의 Masonry에 반대하는 주장을 펼친 것으로 보입니다.

따라서 이 게시물에서는 Chrome에서 CSS 그리드 레이아웃 사양의 일부로 masonry를 구현하는 데 우려하는 이유를 설명하고 대체 제안이 정확히 무엇을 지원하는지 명확히 밝히고자 합니다. 간단히 말해,

Chrome팀은 Masonry를 차단 해제하기를 매우 원합니다. 개발자가 원하는 기능이기 때문입니다.
메서너리를 그리드 사양에 추가하는 것은 메서너리가 그리드인지 아닌지와는 다른 이유로 문제가 됩니다.
그리드 사양 외부에서 masonry를 정의해도 masonry의 여러 트랙 크기나 정렬 또는 간격과 같은 속성 사용, 그리드 레이아웃에 사용되는 기타 기능이 방지되지는 않습니다.

메이슨리가 그리드의 일부여야 하나요?

Chrome팀은 masonry가 display: masonry를 사용하여 정의된 별도의 레이아웃 메서드여야 한다고 생각합니다 (더 나은 이름이 결정되면 다른 키워드 사용). 이 게시물의 뒷부분에서 코드에서 어떻게 표시되는지 몇 가지 예를 확인할 수 있습니다.

그리드 레이아웃 외부에서 메이슨리를 더 잘 정의할 수 있다고 생각하는 데는 두 가지 관련 이유가 있습니다. 레이아웃 성능 문제의 가능성과 메이슨리와 그리드 모두 한 레이아웃 메서드에서는 유용하지만 다른 레이아웃 메서드에서는 유용하지 않은 기능이 있다는 사실입니다.

성능

그리드와 메이슨리는 브라우저가 크기 조정과 배치에 대처하는 방식이 반대입니다. 그리드가 배치되면 모든 항목이 레이아웃 전에 배치되고 브라우저는 각 트랙에 무엇이 있는지 정확히 알 수 있습니다. 이렇게 하면 그리드에서 매우 유용한 복잡한 내장 크기 조절이 가능합니다. 메이슨리에서는 항목이 배치된 대로 배치되며 브라우저는 각 트랙에 항목이 몇 개 있는지 알지 못합니다. 모든 내재적 크기 트랙이나 모든 고정 크기 트랙에 문제가 있는 것은 아니지만 고정 트랙과 내재적 트랙을 혼합하면 문제가 발생합니다. 이 문제를 해결하려면 브라우저가 측정값을 얻기 위해 가능한 모든 방식으로 모든 항목을 배치하는 사전 레이아웃 단계를 실행해야 합니다. 큰 그리드의 경우 레이아웃 성능 문제에 기여합니다.

따라서 트랙 정의가 grid-template-columns: 200px auto 200px인 메이슨리 레이아웃이 있는 경우(그리드에서 매우 흔함) 문제가 발생하기 시작합니다. 하위 그리드를 추가하면 이러한 문제가 기하급수적으로 증가합니다.

대부분의 사용자는 이 문제를 겪지 않을 것이라는 주장도 있지만 이미 매우 큰 그리드를 사용하는 사용자가 있는 것으로 확인되었습니다. 대체 접근 방식이 있는 경우 사용 방식에 제한이 있는 것을 제공하고 싶지 않습니다.

각 레이아웃 메서드에서 말이 안 되는 부분은 어떻게 처리해야 할까요?

플렉스박스와 그리드가 CSS의 일부가 되었을 때 개발자들은 이러한 기능이 일관성 없는 방식으로 작동한다고 생각하는 경우가 많았습니다. 이러한 불일치는 블록 레이아웃을 기반으로 레이아웃 작동 방식에 관해 오랫동안 유지해 온 가정 때문이었습니다. 시간이 지나면서 개발자는 서식 컨텍스트를 이해하기 시작했습니다. 그리드 또는 플렉스 서식 컨텍스트로 전환하면 일부 항목의 동작이 달라집니다. 예를 들어 플렉스박스는 1차원이므로 플렉스박스에 있을 때는 일부 정렬 방법을 사용할 수 없습니다.

메이슨리를 그리드로 번들링하면 서식 컨텍스트와 정렬 속성과 같은 항목의 가용성 간의 명확한 연결이 깨집니다. 이러한 항목은 서식 컨텍스트별로 Box Alignment 사양에 정의되어 있습니다.

앞서 설명한 성능 문제를 해결하기 위해 혼합된 내장 트랙과 고정 트랙 정의를 masonry에서 불법으로 만들기로 결정한다면 그리드 레이아웃의 매우 일반적인 패턴이 masonry에서는 작동하지 않는다는 점을 기억해야 합니다.

크로스 제약 조건이 없지만 그리드에서는 유효하지 않은 상태를 유지해야 하므로 grid-template-columns: repeat(auto-fill, max-content)와 같이 석조에서 의미가 있는 패턴도 있습니다. 다음은 다르게 작동하거나 유효한 값이 다를 것으로 예상되는 속성 목록입니다.

grid-template-areas: Masonry에서는 masonry가 아닌 방향의 초기 행만 지정할 수 있습니다.
grid-template: 약어는 모든 차이점을 고려해야 합니다.
법적 값의 차이로 인해 grid-template-columns 및 grid-template-rows의 크기 값을 추적합니다.
grid-auto-flow은(는) Masonry에 적용되지 않고 masonry-auto-flow은(는) 그리드에 적용되지 않습니다. 병합하면 사용 중인 레이아웃 메서드로 인해 무효화되는 문제가 발생합니다.
그리드에는 4개의 배치 속성 (grid-column-start 등)이 있지만, 벽돌에는 2개만 있습니다.
그리드는 justify-* 및 align-* 속성 6개를 모두 사용할 수 있지만, Masonry는 Flexbox와 같은 일부 속성만 사용합니다.

또한 개발자가 grid-with-masonry 또는 grid-without-masonry에서 유효하지 않은 값을 사용하여 발생하는 모든 새로운 오류 사례에서 어떤 일이 발생하는지 지정해야 합니다. 예를 들어 grid-template-columns: masonry 또는 grid-template-rows: masonry을 사용하는 것은 유효하지만 둘 다 동시에 사용하는 것은 유효하지 않습니다. 두 가지를 한 번에 사용하면 어떻게 되나요? 모든 브라우저가 동일한 작업을 수행할 수 있도록 이러한 세부정보를 지정해야 합니다.

이 모든 것은 현재와 미래에 사양 관점에서 복잡해집니다. 모든 것이 그리드를 고려하고 그리드에서 작동하는지 여부를 확인해야 합니다. 개발자 입장에서도 혼란스럽습니다. display: grid를 사용해도 메이슨리를 사용하기 때문에 작동하지 않는 항목이 있다는 점을 기억해야 하는 이유는 무엇인가요?

대체 제안

앞서 언급했듯이 Chrome팀은 그리드 사양 외부에서 메이슨리를 정의하려고 합니다. 이것이 열 크기가 동일한 매우 간단한 레이아웃 방법으로 제한된다는 의미는 아닙니다. WebKit 게시물의 모든 데모는 여전히 가능합니다.

기본 석조 레이아웃

대부분의 사람들은 Masonry를 생각할 때 크기가 동일한 여러 열이 있는 레이아웃을 떠올립니다. 이는 다음 CSS를 사용하여 정의되며, 동등한 번들 그리드 버전보다 코드 줄이 하나 적습니다.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
}

크기가 동일한 트랙

다양한 열 너비에 그리드 유형 트랙 크기 조정 사용

앞서 언급한 내재적 트랙과 고정 트랙 크기 조정이 혼합된 문제를 제외하고 그리드에서 좋아하는 모든 트랙 크기 조정을 사용할 수 있습니다. WebKit 블로그 게시물의 예와 같이 좁은 열과 넓은 열이 반복되는 패턴

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
  gap: 1rem;
}

넓은 트랙과 좁은 트랙이 번갈아 나타나는 패턴입니다.

masonry의 추가 트랙 크기 조정

그리드는 2차원 레이아웃 메서드이므로 그리드에서 허용되지 않는 트랙 크기 조정 옵션이 추가로 있습니다. 이는 메이슨리에서는 유용하지만 그리드에서 작동하지 않으면 혼란스러울 수 있습니다.

max-content 크기의 트랙을 자동 채우기

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, max-content);
  gap: 1rem;
}

auto 크기의 트랙을 자동 채우면 가장 큰 트랙을 수용할 수 있도록 자동 크기 조정된 동일한 크기의 트랙이 생성됩니다.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
  gap: 1rem;
}

자동 크기 트랙이 있는 Masonry

콘텐츠가 열에 걸쳐 배치되고 항목이 masonry 레이아웃에 배치되도록 허용

별도의 메이슨리 사양에서 열에 걸쳐 있는 콘텐츠가 없어야 할 이유는 없습니다. 메이슨리 레이아웃에서는 확장할 수 있는 차원이 하나뿐이므로 masonry-track-start 및 masonry-track-end의 약어인 masonry-track 속성을 사용할 수 있습니다.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
}

.span-2 {
  masonry-track: span 2; /* spans two columns */
}

.placed {
  masonry-track: 2 / 5; /* covers tracks 2, 3, and 4 */
}

배치되고 확장된 항목이 있는 Masonry

masonry 트랙을 채택하는 하위 그리드 또는 하위 masonry

이는 별도의 masonry 사양으로 지원될 수 있으며, 혼합된 내재적 트랙과 고정 크기 트랙은 허용되지 않는다는 단서가 다시 적용됩니다. 정확히 어떤 모습인지 정의해야 합니다. 이 방법이 작동하지 않을 이유는 없습니다.

결론

상호 운용 가능한 사양을 제공할 수 있기를 바랍니다. 하지만 현재와 미래에 잘 작동하고 개발자가 신뢰할 수 있는 방식으로 이를 수행하고자 합니다. 설명된 성능 문제를 처리하는 유일한 방법은 두 번째 문제인 모자이크에서 그리드의 일부가 불법인 문제를 악화시키는 것입니다. 특히 서로 다른 항목을 명확하게 구분하면서 원하는 모든 그리드 기능을 사용할 수 있는 경우에는 좋은 해결책이 아닙니다.

의견이 있는 경우 문제 9041에서 토론에 참여하세요.

이 게시물을 검토하고 게시물에 반영된 논의에 참여해 주신 브라무스, 탭 앳킨스-비트너, 우나 크라베츠, 이언 킬패트릭, 크리스 해럴슨께 감사드립니다.