그리드가 새로운 모듈을 위해 진화하거나 제쳐두야합니까? – 스매싱 잡지

CSS에서 벽돌 스타일 레이아웃에 대한 지원을 추가하기 위해 떠 다니는 결투 제안이있었습니다. 한쪽 코너에는 기존 CSS 그리드 사양을 확장하는 제안이 있습니다. 다른 코너에는 독립형 모듈로 벽돌을 설정하는 두 번째 제안이 있습니다. 글쎄, 최근까지. 이제 Apple WebKit의 “항목 흐름”을 세 번째 옵션으로 제안한 세 가지 제안이 있습니다. 처음 두 측면은 강력한 지점을 만들고 세 번째 측면은이 기사에서 배울 것입니다.

당신은 구축 할 Pinterest 스타일 레이아웃이 있지만 JavaScript에 지쳤습니다. CSS가 마침내 답을 얻을 수 있습니까? 글쎄, 초보자에게는 Pinterest 페이지의 핀을 살펴보면 CSS 그리드 레이아웃이 충분하지만 빌드를 시작할 때까지는 알 수 없을 것입니다. display: grid 추가 조정으로 충분하지 않습니다. 실제로 Pinterest는 JavaScript로 레이아웃을 구축했지만 CSS 일 경우 얼마나 시원할까요? 추가 자바 스크립트없이 그러한 레이아웃을 제공하는 CSS 디스플레이 속성이 있다면 얼마나 멋진가요?

아마도있을 수도 있습니다. CSS 그리드 레이아웃에는 다음에 있습니다 실험 벽돌 값 ~을 위한 grid-template-rows. 벽돌 레이아웃은 불규칙하고 흐르는 그리드입니다. 짧은 조각 후에 공간이 남은 공간으로 강성 그리드 패턴을 따르지 않고 벽돌 레이아웃의 다음 행에있는 항목은 메이슨 축의 공간을 채우기 위해 상승한다는 의미에서 불규칙합니다. 포트폴리오, 이미지 갤러리 및 소셜 피드의 꿈은 유기적 흐름에 번성하는 디자인입니다. 그러나 여기에 캐치가 있습니다.이 실험적인 기능이 존재하지만 (Firefox를 깃발 활성화로 생각하십시오) 브라우저 지원이 제한되어 있고 현재 형태의 거친 가장자리 덕분에 기대할 수있는 완벽한 솔루션이 아닙니다.

어쩌면 없을 수도 있습니다. CSS에는 기본 벽돌 지원이 부족하여 개발자가 Masonry.js와 같은 해킹 또는 JavaScript 라이브러리를 사용하도록 강요했습니다. 디자인 배경이 좋은 개발자는 CSS 그리드 양식의 벽돌에 대한 비판을 표현했으며 Rachel은 다음과 같이 강조했습니다. Masonry의 유기 흐름은 그리드의 엄격한 2 차원 구조와 대조됩니다그리드와 같은 동작이나 Ahmad가 그리드 레이아웃을 어떻게 복잡하게 만드는 방법에 대해 소란스러워하는 잠재적으로 혼란스러운 개발자는 구조화 된 레이아웃에 대한 그리드의 명확성을 소중히 여기는 압도적 인 개발자에게 소란을 불러 일으 킵니다. Geoff는 또한 Rachel Andrew의 우려를 반영합니다 “벽돌 행동을 불필요하게 이해하기위한 그리드를 가르치고 학습하는 것은 두 가지 다른 형식의 컨텍스트를 하나로 묶습니다.” 명확한 정신 모델에 의존하는 디자이너와 개발자를위한 복잡한 교육.

아마도 희망이있을 것입니다. Apple Webkit 팀은 새로운 경쟁자를 생산했는데, 이는 그리드와 메이슨의 전문가를 통합 시스템 속기로 합병 할뿐만 아니라 Flexbox 개념을 포함한다고 주장합니다. 3 개의 CSS 레이아웃 시스템 중 최고를 상상해보십시오.

이러한 불만과 비판과 게임의 새로운 사람이 주어지면 질문은 다음과 같습니다.

CSS 그리드가 벽돌 처리를 위해 확장 해야하는 경우, 또는 새로운 전용 모듈이 인수 해야하는 경우 item-flow 그냥 고삐를 가져가?

오늘 CSS의 석조 상태

몇몇 개발자는 수동 행 스팬 해킹, CSS 열 및 JavaScript 라이브러리와 함께 CSS 그리드를 사용하여 웹 애플리케이션에서 벽돌 레이아웃을 달성하기 위해 해결 방법을 작성하려고 시도했습니다. 원주민 벽돌이 없으면 개발자는 종종 다음과 같은 그리드 해킹으로 전환합니다. grid-auto-rows 트릭은 JavaScript와 짝을 이루어 흐름을 가짜입니다. 그것은 일종의 일종의 작동하지만 균열은 빠르게 나타납니다.

예를 들어, 아래의 예는 렌더링 후 각 항목의 높이를 측정하기 위해 JavaScript에 의존하고 설정 중에 항목이 걸러야하는 10px 행 수를 계산합니다. grid-row-end 동적으로, 이벤트 리스너를 사용하여 페이지로드 및 창 크기 조정시 레이아웃을 조정하십시오.

/* HTML */

  
  
  
  높이 변화를 보여주기 위해 여러 줄에 걸쳐있는 더 긴 텍스트 콘텐츠.

/* CSS */
.masonry-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); /* Responsive columns */
  grid-auto-rows: 10px; /* Small row height for precise spanning */
  grid-auto-flow: column; /* Fills columns left-to-right */
  gap: 10px; /* Spacing between items */
}

.masonry-item {
  /* Ensure content doesn’t overflow */
  overflow: hidden;
}

.masonry-item img {
  width: 100%;
  height: auto;
  display: block;
}

.masonry-item p {
  margin: 0;
  padding: 10px;
}

// JavaScript

function applyMasonry() {
  const grid = document.querySelector('.masonry-grid');
  const items = grid.querySelectorAll('.masonry-item');

  items.forEach(item => {
    // Reset any previous spans
    item.style.gridRowEnd = 'auto';

    // Calculate the number of rows to span based on item height
    const rowHeight = 10; 
    const gap = 10; 
    const itemHeight = item.getBoundingClientRect().height;
    const rowSpan = Math.ceil((itemHeight + gap) / (rowHeight + gap));

    // Apply the span
    item.style.gridRowEnd = `span ${rowSpan}`;
  });
}

// Run on load and resize
window.addEventListener('load', applyMasonry);
window.addEventListener('resize', applyMasonry);

이 그리드 해킹은 우리를 벽돌 레이아웃에 가깝게 만듭니다. 항목 스택, 갭 채우기, 충분히 괜찮아 보입니다. 그러나 진짜가되자 : 아직 거기에 없습니다. 기본과 달리 위의 코드 샘플 grid-template-rows: masonry (실험적이고 Firefox Nightly에만 존재 함), JavaScript에 의존하여 스팬을 계산하여“JavaScript No JavaScript”꿈을 물리칩니다. JavaScript 로직은 크기 조정 또는 컨텐츠 변경에 대한 스팬을 다시 계산하여 작동합니다. Chris Coyier가 비슷한 해킹에 대한 그의 비판에서 언급했듯이, 이것은 복잡한 페이지에 지연 될 수 있습니다.

또한 논리적 DOM 순서는 시각적 흐름과 일치하지 않을 수 있습니다. Rachel Andrew는 일반적으로 벽돌 레이아웃에 대해 제기 한 문제입니다. 마지막으로, 이미지가 천천히로드되거나 콘텐츠 변화 (예 : 게으른로드 미디어)가되면 스팬은 재 계산이 필요하므로 레이아웃 점프가 위험합니다. 실제로 이상적인 해킹은 아닙니다. 나는 당신이 동의 할 것이라고 확신합니다.

개발자는 원활한 경험이 필요하며 인체 공학적으로 말하면 스크립트와 함께 그리드를 해킹하는 것은 정신 저글링 행위입니다. CSS와 JavaScript 사이를 전환하여 레이아웃을 조정해야합니다. 그리드 전원이든 새로운 모듈이든 기본 솔루션은 도구를 깨뜨리지 않는 손을 떼지 않은 응답 성, 깔끔한 렌더링 및 워크 플로우를 필요로합니다.

그렇기 때문에이 논쟁이 중요합니다. 우리의 매일 갈기가 요구합니다.

옵션 1 : 벽돌의 CSS 그리드 확장

앞으로의 한 가지 방법은 벽돌 전력으로 CSS 그리드를 강화하는 것입니다. 이 글을 쓰는 시점에서 CSS 그리드는 벽돌을 수용하기 위해 확장되었습니다. grid-template-rows: masonry 현재 Firefox Nightly에서 실험적인 CSS 그리드 레벨 3의 초안입니다. 이 레이아웃의 열은 그리드 축으로 유지되는 동안 행은 벽돌을 사용합니다. 그런 다음 그리드 레이아웃의 자동 배치와 마찬가지로 하위 요소는 행을 따라 항목별로 배치됩니다. 이 레이아웃을 사용하면 항목이 수직으로 흐르고 열 트랙을 존중하지만 행 제약 조건은 아닙니다.

이 옵션은 그리드를 레이아웃 시스템으로 남겨 두지 만 우리가 갈망하는 흐르는 틈새 스택을 처리 할 수 있습니다.

.masonry-grid {
  display: grid;
  gap: 10px;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
  grid-template-rows: masonry;
}

먼저, 그리드 메이슨 스타일은 CSS 그리드의 친숙 함과 강력한 툴링 (예 : DevTools 지원)을 구축합니다. 프론트 엔드 개발자로서 당신이 함께 플레이 한 기회가 있습니다. grid-template-columns 또는 grid-area그래서 당신은 학습 매트릭스의 중간에 있습니다. Masonry는 기존 기능 만 확장하여 완전히 새로운 구문을 처음부터 배울 필요가 없습니다. 또한 Grid의 강력한 툴링은 Chrome Devtools의 그리드 오버레이 또는 Firefox의 레이아웃 검사관과 함께 제공되어 JavaScript 해킹이 필요합니다.

그렇게 빠르지 않습니다 : 제한이 있습니다. 그리드의 사양에는 이미 속성이 포함되어 있습니다 align-content 그리고 grid-auto-flow. 목록에 벽돌을 쌓으면 미로로 전환 할 위험이 있습니다.

그런 다음 있습니다 가장자리 케이스. 품목이 여러 열에 걸쳐 있고 벽돌 스타일을 흐르는 경우 어떻게됩니까? 아니면 항목 간의 간격이 열에 따라 정렬되지 않으면? 사양은 여전히 안개가 큽니다. 콘텐츠가 동적으로로드되면 예측할 수없는 항목과 같은 버그를 초기 테스트합니다. 이 문제는 특히 반응 형 디자인에서 레이아웃을 깨뜨릴 수 있습니다. 브라우저 호환성 문제 또한 존재합니다. 여전히 실험적이며 폴리 필드에서도 Firefox를 제외한 다른 브라우저에서는 작동하지 않습니다. 다음 고객의 프로젝트에서 시도하고 싶은 것이 아닙니다.

옵션 2 : 독립형 벽돌 모듈

만약 우리가 가지고 있다면? display: masonry 대신 접근합니까? 몇 분 동안 나를 탐닉하십시오. 이것은 단지 희망적인 생각이 아닙니다. 초기 CSS 작업 그룹 채팅이 아이디어를 떠 올랐으며 레이아웃을 개선 할 수있는 방법을 묘사 할 가치가 있습니다. 비전에 뛰어 들자 어떻게 작동 할 수 있습니다 무엇 프로세스에서 얻거나 잃습니다.

그리드의 강성 트랙이나 Flexbox의 선형 흐름에 의지하지 않고 수평 트위스트로 수직 스태킹에 번성하는 레이아웃 시스템을 상상해보십시오. 목표? Masonry의 시그니처 룩을위한 깨끗한 슬레이트 : 열을 계단식으로 내려 가고, 자연스럽게 간격을 채우고, 해킹이 필요하지 않습니다. CSSWG 토론과 Chrome 팀의 대안 제안에서 불평에서 영감을 얻은이 모듈은 구조보다 유동성 우선 순위를 정합니다디자이너에게 쫓는 레이아웃만큼 직관적 인 느낌의 도구를 제공합니다. Pinterest를 생각하지만 JavaScript 스캐 폴딩이 없습니다.

여기에 피치가 있습니다 : a display 이름이 지정된 가치 masonry 품목이 기본적으로 수직으로 쌓이는 흐름 기반 시스템을 시작하여 컨테이너에 맞게 수평으로 조정합니다. 다음과 같은 간단한 속성으로 방향과 간격을 제어합니다.

.masonry {
  display: masonry;
  masonry-direction: column;
  gap: 1rem;
}

더 많은 제어를 원하십니까? 가상의 엑스트라와 같은 masonry-columns: auto 그리드를 모방 할 수 있습니다 repeat(auto-fill, minmax())~하는 동안 masonry-align: balance 세련된 외관을 위해 열 길이가 나올 수도 있습니다. 정확한 배치 (그리드의 강도)와 콘텐츠가 호흡과 흐름을 돕는 것에 관한 것이 아닙니다. 여기서 큰 승리는 그리드의 엄격한 주문에서 깨끗한 휴식입니다. 독립형 모듈은 다음을 구별합니다. 주문 그리드, 흐름을위한 벽돌. 더 이상 맞지 않는 그리드 특성으로 더 이상 레슬링이 없습니다. 작업에 맞게 시스템을 얻습니다.

물론, 그것은 모두 매끄러운 항해가 아닙니다. 새로운 사양은 0부터 시작하는 것을 의미합니다. 브라우저 공급 업체는 그 뒤에 랠리해야합니다. 또한, 그것은 이어질 수 있습니다 선택의 혼란개발자가 다음과 같은 질문을하는 것과 함께 “이 갤러리에 그리드 나 벽돌을 사용합니까?” 그러나 내 말을 들으십시오 :이 제안 된 모듈은 물이 깨끗해지기 전에 물을 뿌릴 수 있지만, 물이 깨끗 해지면 모든 사람이 사용하기에 안전합니다.

항목 흐름 : 통합 레이아웃 해상도

2025 년 3 월, Apple의 Webkit 팀은 Flexbox, Grid 및 Masonry의 개념을 단일 속성 세트로 통합하는 새로운 시스템 인 항목 흐름을 제안했습니다. 그리드 향상 또는 새 벽돌 모듈 생성 중에서 선택하는 대신 항목 흐름은 강점을 통합하여 교체합니다. flex-flow 그리고 grid-auto-flow 속기로 전화를 걸었습니다 item-flow. 이 시스템은 4 가지 외부 특성을 소개합니다.

item-direction
흐름 방향을 제어합니다 (예 : row,,, column,,, row-reverse).
item-wrap
포장 동작을 관리합니다 (예 : wrap,,, nowrap,,, wrap-reverse).
item-pack
포장 밀도를 결정합니다 (예 : sparse,,, dense,,, balance).
item-slack
레이아웃 조정에 대한 공차를 조정하여 항목이 수축하거나 적합하게 이동할 수 있습니다.

항목 흐름은 벽돌을 별도의 특징이 아니라 이러한 특성의 자연스러운 결과로 만드는 것을 목표로합니다. 예를 들어, 벽돌 레이아웃은 다음과 같이 달성 할 수 있습니다.

.container {
  display: grid; /* or flex */
  item-flow: column wrap dense;

  /* long hand version */
  item-direction: column;
  item-wrap: wrap;
  item-pack: dense;

  gap: 1rem;
}

이 설정을 통해 품목은 수직으로 흐르고, 열로 포장하고, 단단히 포장하여 Masonry의 유기적 배열을 모방 할 수 있습니다. 그리드에서 영감을 얻은 밀도가 높은 포장 옵션 auto-flow: dense갭을 최소화하기 위해 항목을 다시 작성합니다 item-slack 시각적 균형을 위해 간격을 미세 조정할 수 있습니다.

항목 흐름의 약속은 그것에 있습니다 넓은 사용 사례. 기능과 같은 기능으로 그리드 및 Flexbox를 향상시킵니다 nowrap 그리드 또는 balance Flexbox 용 포장, 오랜 개발자 위시리스트를 해결합니다. 그러나 제안은 여전히 논의 중이며 item-slack 비 네이티브 영어 사용자의 명확성 문제로 인해 명명 토론에 직면하십시오.

단점? 항목 흐름은 a입니다 미래를 향한 개념또한 2025 년 4 월 현재 브라우저에서 구현되지 않았습니다. 개발자는 표준화 및 채택을 기다려야하며 CSS 실무 그룹은 여전히 피드백을 수집하고 있습니다.

올바른 길은 무엇입니까?

이 질문에 대한 직접적인 답은 없지만, 벽돌 토론은 단순성, 성능 및 유연성의 균형을 맞추는 것에 달려 있습니다. 벽돌로 그리드를 확장하는 것은 유혹적이지만 위험이 있습니다 과도하게 복잡합니다 이미 강력한 시스템. 독립형 display: masonry 모듈은 명확성을 제공하지만 CSS의 학습 곡선에 추가됩니다. 최신 경쟁자 인 항목 흐름은 석조를 자연스럽게 그리드와 플렉스 박스의 확장으로 만들 수있는 통합 시스템을 제안하여 마침내 논쟁을 일으킬 수 있습니다.

각 접근 방식에는 트레이드 오프가 있습니다.

벽돌과 그리드: 접근성과 사양 문제가있는 친숙하지만 잠재적으로 어리석은.
새로운 모듈: 깨끗하고 목적으로 제작되었지만 새로운 구문을 배우는 것이 필요합니다.
항목 흐름: 이름 지정 및 구현에 대한 지속적인 토론으로 우아하고 다재다능하지만 아직 사용할 수는 없습니다.

메이슨을 지원하는 동안 기존 레이아웃을 향상시키는 항목 흐름의 기능은 매력적인 옵션이지만 성공은 브라우저 채택 및 커뮤니티 지원에 달려 있습니다.

결론

그렇다면이 모든 후에 우리는 어디에 착륙합니까? Masonry Showdown은 3 가지 경로로 요약됩니다. Masonry가 CSS 그리드로의 확장, Masonry 용 독립형 모듈 또는 항목 흐름으로 확장됩니다. 이제 문제는 CSS는 마침내 Masonry의 JavaScript에서 우리를 자유롭게합니다아니면 우리는 여전히 꿈을 꾸고 있습니까?

그리드는 취향과 독립형 모듈의 속삭임 약속으로 우리를 괴롭 힙니다. 그러나 결승선은 불분명하고 Webkit은 킬러와 함께 속기를 합치고 항목 흐름을 병합합니다. 브라우저 바이 인, 커뮤니티 푸시 및 몇 가지 사양 개정이 우리에게 알려줄 수 있습니다. 지금은 테스트, 조정 및 무게의 움직임입니다. 한 번에 한 번의 레이아웃이 다가오고 있습니다.