이 페이지는 Cloud Translation API를 통해 번역되었습니다.

CSS 석조술을 위한 대안 제안

Rachel Andrew

Chrome팀은 웹에서 석조물 유형 레이아웃을 구현하고자 합니다. 하지만 최근 WebKit 게시물에서 제안한 대로 CSS 그리드 사양의 일부로 구현하는 것은 잘못된 것이라고 생각합니다. 또한 WebKit 게시물에서 아무도 제안하지 않는 석조물에 대해 이의를 제기했다고 생각합니다.

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

Chrome팀은 석조물에 대한 차단 해제를 매우 열심히 하고 있습니다. 개발자들이 바라는 점도 잘 알고 있습니다.
그리드 사양에 석조물을 추가하면 석조물이 그리드라고 생각하는지 아닌지 아닌지 등의 이유로 문제가 됩니다.
그리드 사양 외부에 석조물을 정의해도 석조물의 여러 트랙 크기, 정렬 또는 간격과 같은 속성 또는 그리드 레이아웃에 사용되는 기타 지형지물의 사용을 방지하지 않습니다.

석조물이 그리드의 일부여야 하나요?

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

석조물이 그리드 레이아웃 외부에서 더 잘 정의된다고 생각되는 두 가지 이유가 있습니다. 레이아웃 성능 문제의 잠재력과 석조물과 그리드 모두 한 레이아웃 메서드에서는 의미가 있지만 다른 레이아웃 메서드에서는 의미가 없는 특징이 있다는 점입니다.

성능

그리드와 석조물은 브라우저가 크기 및 배치를 처리하는 방식에서 반대입니다. 그리드가 배치되면 모든 항목이 레이아웃 앞에 배치되고 브라우저는 각 트랙의 내용을 정확히 인식합니다. 이렇게 하면 그리드에서 매우 유용한 복잡한 내장 크기를 조정할 수 있습니다 석재를 사용하면 항목이 배치될 때 배치되며 브라우저는 각 트랙에 몇 개가 있는지 알 수 없습니다. 이는 모든 내장 크기 트랙 또는 모든 고정된 크기의 트랙에는 문제가 되지 않지만 고정 및 내장 트랙을 혼합하는 경우에는 문제가 됩니다. 문제를 반올림하려면 브라우저에서 측정을 위해 가능한 모든 방법으로 모든 항목을 배치하는 사전 레이아웃 단계를 실행해야 하며, 큰 그리드를 사용하면 레이아웃 성능 문제가 발생할 수 있습니다.

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

대부분의 사람들은 이런 상황에 처하지 않겠다는 논쟁이 있지만, 우리는 사람들에게 매우 큰 그리드가 있다는 점을 이미 알고 있습니다. Google은 다른 접근 방식이 있는 경우 사용 방법에 제한이 있는 것을 출시하지 않습니다.

각 레이아웃 메서드에 맞지 않는 요소에 대해서는 어떻게 해야 할까요?

Flexbox 및 그리드가 CSS의 일부가 되었을 때 개발자는 종종 일관성이 없는 방식으로 동작한다고 느꼈습니다. 이러한 상황에서 발생한 비일관성은 블록 레이아웃에 따라 레이아웃의 작동 방식에 관한 오랜 가정이 있었기 때문입니다. 시간이 지남에 따라 개발자는 서식 지정 컨텍스트를 이해하기 시작했습니다. 그리드 또는 Flex 서식 지정 컨텍스트로 전환하면 몇 가지가 다르게 동작합니다. 예를 들어 Flexbox에서는 Flexbox가 1차원이므로 일부 정렬 메서드를 사용할 수 없습니다.

석재를 그리드로 묶으면 서식 컨텍스트와 형식 지정 컨텍스트별로 상자 정렬 사양에 정의된 정렬 속성과 같은 항목의 사용 가능 여부 사이의 명확한 연결이 끊어집니다.

혼합된 고유 및 고정 트랙 정의를 석조물에서 불법으로 만들어 이전에 설명한 성능 문제를 처리하기로 결정했다면 그리드 레이아웃의 매우 일반적인 패턴이 석조물에 적합하지 않다는 점을 기억해야 합니다.

또한 석조물에서 적합한 패턴도 있습니다(예: grid-template-columns: repeat(auto-fill, max-content)). 교차 제약 조건은 없지만 그리드에서 유효하지 않은 상태를 유지해야 하기 때문입니다. 다음은 다르게 동작할 것으로 예상되거나 유효한 값이 서로 다른 속성 목록입니다.

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

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

현재는 물론 미래에도 사양의 관점에서 이 모든 것이 복잡해집니다. 모든 것이 석조물을 고려하고 석조물에서 작동하는지 여부를 확인해야 합니다. 또한 개발자의 관점에서 혼동하기 쉽습니다. display: grid를 사용하더라도 석조물 사용으로 인해 일부 기능이 작동하지 않는다는 점을 머릿속에 떠올려야 하는 이유는 무엇인가요?

대체 제안

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

클래식한 석조 구조

대부분의 사람들은 석조물이라고 하면 크기가 같은 여러 개의 기둥이 있는 레이아웃을 떠올립니다. 이는 다음 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;
}

넓고 좁은 트랙의 패턴입니다.

석조물을 위한 추가 트랙 크기 조정

그리드가 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-track 속성을 사용할 수도 있습니다. masonry-track-start 및 masonry-track-end의 약식 표현입니다. 석조물 레이아웃에서는 차원이 하나만 존재하기 때문입니다.

.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 */
}

배치된 항목과 스팬이 있는 석조물입니다.

석조 트랙을 채택하는 하위 석조물 또는 하위 그리드

이는 별도의 석조물 사양으로 지원될 수 있으며, 내장 및 고정 크기의 혼합 트랙은 허용되지 않는다는 조건에서도 다시 언급됩니다. 정확히 어떻게 보이는지 정의해야 합니다. 이렇게 해도 효과가 없을 이유는 없습니다.

결론

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

의견이 있으면 문제 9041의 토론에 참여하세요.

이 게시물을 검토하고 이에 대한 토론을 해 주신 Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick, Chris Harrelson에게 감사드립니다.