2P by neo 2달전 | favorite | 댓글 1개
  • CSS Grid의 Masonry 레이아웃(벽돌 쌓기 또는 폭포수 레이아웃이라고도 함)을 CSS Grid Level 3에 추가하기 위한 제안이 진행되고 있음

    • Masonry 레이아웃은 컨텐츠를 벽돌이나 돌벽처럼 빽빽하게 채워 넣는 패턴으로, 크기가 다른 컨텐츠를 자르거나 생략하지 않고 배치할 수 있으며, 내용을 열 단위로 흘려 내림
    • 이는 JavaScript 없이 CSS만으로 구현하기 어려웠던 레이아웃임
  • CSS에서 Masonry 메커니즘을 구현하기 위해 4가지 데모를 만들어 봄

    • 고전적인 Masonry/폭포수 레이아웃 만들기
    • Grid의 다양한 열 정의 기능 활용하기
    • Grid의 열 병합 기능 활용하기
    • Subgrid와 명시적 배치 사용하기
  • Grid의 다양한 기능과 Masonry를 결합하면 훨씬 더 창의적이고 역동적인 레이아웃 구현이 가능함

    • fr 단위, max-content, min-content, minmax() 함수 등으로 유연하고 다양한 열 크기 정의
    • 열 병합으로 특정 아이템을 강조하거나 다채로운 그리드 구성
    • Subgrid로 중첩 그리드의 트랙을 부모에 맞춤
    • 명시적 배치로 헤더 등 특정 아이템의 위치 지정
  • Masonry 레이아웃을 별도의 display 타입으로 분리해야 한다는 주장도 있음

    • CSS Grid와 Masonry를 결합하면 복잡도가 높아지고 성능에 부정적일 수 있다는 우려
    • Masonry를 Grid와 분리하면 각각의 기능을 독립적으로 발전시킬 수 있음
    • 하지만 Masonry를 제한적인 동일 크기 열 레이아웃으로만 구현하자는 의견도 있음
  • CSS Grid에 Masonry 기능을 포함시키는 것이 더 많은 장점이 있다고 봄

    • CSS Grid 레벨 3 명세가 이미 작성되어 2개 브라우저 엔진에 구현됨
    • 앞으로 Grid와 Masonry에 동일한 새로운 기능을 제공할 수 있음 (예: 트랙 스타일링)
    • Masonry도 Grid의 한 종류이므로 개념적으로도 잘 어울림
  • 웹 디자이너와 개발자 여러분의 의견을 듣고 싶음

    • Masonry가 CSS Grid의 일부가 되어야 하는지?
    • 다양한 열 크기 정의, 열 병합, 배치, Subgrid 등 Grid의 모든 기능을 활용할 수 있기를 원하는지? 아니면 동일 크기 열만 지원하는 것이 나은지?
    • 이 기능을 어떻게 활용할 것인지? 어떤 레이아웃을 만들 수 있을지?
    • 직접 만든 데모가 있다면 공유해주기 바람
    • 이 모델로 구현하기 어려운 레이아웃이 있는지?
  • Masonry라는 이름은 적절치 않을 수 있음. 행을 없앤다는 의미로 grid-template-rows: off 같은 문법을 고려해볼 만함. 향후 이름이 변경될 수 있음을 염두에 두기 바람

GN⁺의 의견

  • CSS Grid에 Masonry 기능을 추가하는 것은 웹 레이아웃의 표현력을 크게 높일 수 있는 의미 있는 변화라고 생각함. 특히 열 방향으로만 배치하는 컬럼형 그리드를 손쉽게 구현할 수 있게 되는 것은 매력적임
  • 반면 Masonry를 별도의 display 타입으로 분리하고 기능을 제한하자는 주장에는 동의하기 어려움. 오히려 Grid의 강력한 기능들과 결합했을 때 Masonry 레이아웃의 활용 범위가 더욱 넓어질 것으로 보임
  • 다만 Masonry라는 이름은 직관적이지 않고 혼동을 줄 수 있으므로, 컬럼 전용 그리드를 나타내는 다른 이름을 고려해보는 것이 좋겠음. grid-template-rows: none과 같이 '행이 없는 그리드'라는 의미를 명확히 전달할 수 있는 문법이 더 나을 듯함
  • 이번 제안이 CSS Grid를 더욱 강력한 도구로 만들 수 있을 것으로 기대함. 다양한 레이아웃 사례를 실험해보고 적극적으로 의견을 개진하는 것이 중요할 것 같음
Hacker News 의견

요약:

  • CSSWG와 브라우저 벤더의 DevRel 팀이 2020년부터 Masonry 레이아웃을 CSS에 공식적으로 포함시키는 방법에 대해 논의 중임
    • WebKit 팀이 이 논의를 공개적으로 만들어 디자이너와 개발자의 의견을 구하기로 함
    • 이는 중요한 선례가 될 것이며, 모든 레이아웃 옵션을 CSS 그리드의 일부로 취급할 것인지 아니면 필요에 따라 새로운 CSS Display 프로퍼티를 계속 추가할 것인지에 대한 근본적인 논쟁임
  • Masonry 레이아웃을 벽돌 쌓기에 비유하는 것은 재미있으나 실제 벽돌을 그렇게 쌓으면 구조 공학적 재앙이 될 것임
  • Megamenu 데모는 Masonry 레이아웃을 부적절하게 사용한 사례로, 읽기 흐름을 엉망으로 만들고 기대를 심각하게 저버림
    • 시각 장애인 사용자는 항상 "잘못된" 순서로 읽게 될 것임
    • break-inside: avoid를 사용하여 컬럼으로 구현했어야 함
  • 신문 데모도 비슷한 이유로 약간 의심스러움
  • 독립적인 블록에 있는 이미지나 미디어의 경우 Masonry 레이아웃이 더 잘 작동함
  • 이 데모들은 그리드 레이아웃을 기반으로 하기 때문에 지원하지 않는 브라우저에서도 합리적인 고정 행 형식으로 나타남
  • Masonry/Waterfall 레이아웃의 전반적인 느낌이 마음에 듦
    • 그러나 기본 Masonry 정렬 방식 대신 좌우 읽기 흐름을 더 많이 보존하는 레이아웃이 있으면 좋겠음
  • CSS를 대체할 수 있는 레이아웃 시스템 설계 방법에 대한 고민
    • Qt, Tk, SwiftUI 등 실제 구현된 시스템 중 더 나은 점이 있는지 궁금함
    • 개발자에게 더 나은 인터페이스를 제공하려면 어떻게 해야 할까?
  • 자신의 사진 웹사이트에서 JS 없이 Masonry 효과를 구현한 사례 소개
    • display:inline-block을 사용하여 사진을 텍스트처럼 취급하여 새 줄로 리플로우 시킴
    • Masonry 라이브러리보다 결과가 더 만족스러움
  • 이미 Flexbox, Grid 레이아웃이 있는데 CSS에 더 많은 "레이아웃" 옵션을 추가하는 것이 맞는지 의문
    • 모든 레이아웃 사례를 다루는 복잡하더라도 최종적인 제약 기반 시스템을 만드는 것이 더 나은 솔루션일 수 있음
  • WebKit 팀이 다시 공개적으로 훌륭한 작업을 하는 모습을 보니 기분이 좋음