Subgrid 기능이 정말 멋지지만, 첫 번째 간단한 예제에서는 ul { display: contents }로 자식들이 그리드 레이아웃에 참여하게 할 수도 있음
Subgrid 기능이 꼭 필요하지 않다면 이 방식이 더 효율적임
그 예제에서는 맞지만, 일반적으로 display: contents는 UL 요소를 레이아웃에서 완전히 제거함
그래서 스타일을 적용하거나 해당 요소에 UI 이벤트를 받을 수 없음
UL을 하이라이트 영역이나 스크롤 가능한 섹션으로 쓰고 싶다면 subgrid가 훨씬 유용함
두 번째 예제에서는 이미지의 너비를 일정하게 유지하려면 fr 대신 다른 단위를 쓰고, 텍스트에는 fr을 써서 남은 공간을 채우게 하면 됨
예전에 가격 비교 UI를 만들 때 subgrid가 없어서 정말 고생했음
두 개의 테이블을 나란히 두고 행을 맞추는 게 불가능했음
고정 높이나 JS 계산으로 해결할 수는 있었지만, React 컴포넌트 구조에서는 너무 비효율적이었음
Container queries가 더 나은 해결책 아닌가 생각했음
하지만 전체 그리드의 일관성을 유지하려면 subgrid가 더 적합할 수도 있음
참고로 CodePen 예제를 보면 이해가 쉬움
Container queries는 형제 요소 크기에 반응하는 문제를 해결하지 못함
게다가 container를 쓰면 새로운 stacking context가 생겨서 불편함
subgrid와 container를 함께 쓸 수 없다는 게 아쉬움. subgrid 크기를 자식이 참조할 수 있다면 정말 강력할 것 같음
“결국 <table> 레이아웃으로 돌아온 건가?”라는 생각이 듦
맞기도 하고 아니기도 함. 예전 <table>은 문제 해결용 해킹이었지만 접근성과 기술적 제약이 많았음
Grid 시스템은 시각적 배치를 위한 도구이지, 데이터 구조를 표현하는 테이블과는 다름
이제는 그리드가 표준으로 자리 잡았으니, 더 이상 테이블과 비교하지 않았으면 함
25년 전에는 서버에서 자동으로 테이블을 렌더링해서 레이아웃을 만들었는데, 그땐 정말 쉽게 작동했음
하지만 반응형이나 접근성은 전혀 고려되지 않았음. 결국 우리는 테이블을 다시 발명한 셈임
<table>의 문제는 콘텐츠를 설명하는 구조였다는 점임. **그리드 자체는 문제 없음**
나도 “테이블은 표 데이터용이다”라는 말을 20년 넘게 들어왔음
결국 CSS가 그 기능을 개선된 형태로 다시 구현한 셈임
예전에 겪은 grid 버그 중 하나는 <img> 요소를 퍼센트 단위로 크기 지정하면 셀 크기가 원본 이미지 크기로 왜곡되는 현상이었음
Firefox와 Chromium 모두에서 발생했고, 관련 버그는 Mozilla Bug 1857365에 있음
이미지에 고정된 width/height 속성을 주면 이 문제가 사라지는지 궁금함
CSS가 레이아웃을 위해 문서 구조 정보를 추가해야 하는 경우가 종종 있어서 아쉬움
예를 들어 행 개수를 명시해야 하는 점이 그렇음
이상적으로는 부모가 달라도 요소를 정렬할 수 있는 방법이 있었으면 함
혹은 한 flex 컨테이너가 다른 컨테이너의 분포를 모방할 수 있다면 좋겠음
하지만 그렇게 하면 DX가 복잡해질 가능성이 큼
왜 코드 예제에서 HTML과 CSS 파일 둘 다에 스타일이 들어있는지 궁금했음
첫 번째 subgrid 예제의 CSS만 보고는 UL에 어떤 스타일이 적용됐는지 한참 찾았음
“결국 다시 grid로 돌아온 건가?”라는 생각이 듦
예전 HTML 시절에도 비슷한 걸 했었음
하지만 지금의 grid는 반응형 디자인을 훨씬 쉽게 만들어줌
물론, 이제는 스타일링 중에 버그가 더 많아지는 부작용도 있음 😅
Josh의 블로그 글은 항상 감탄스러움
글의 명료함, 디자인 감각, 인터랙티브한 웹사이트까지 모두 훌륭함
나도 그의 메일링 리스트 구독자임. 새 글이 올라올 때마다 기대됨
개인적으로 grid는 여전히 다루기 불편함
문법도 어색하고 레이아웃 감각도 잘 안 맞음. Flexbox가 훨씬 직관적이고 유연함
두 기술은 문제 접근 방식이 다름
Flexbox는 콘텐츠 중심, Grid는 컨테이너 중심으로 크기를 제어함
나도 가끔 grid를 다시 시도하지만, 여전히 원하는 기능이 부족함
콘텐츠가 여러 축에 자동으로 맞춰지지 않고, 모든 걸 수동으로 배치해야 함
아마 내가 grid의 본질을 잘 못 이해했거나, 내 작업 유형과 맞지 않는 것 같음
Hacker News 의견
Subgrid 기능이 정말 멋지지만, 첫 번째 간단한 예제에서는
ul { display: contents }로 자식들이 그리드 레이아웃에 참여하게 할 수도 있음Subgrid 기능이 꼭 필요하지 않다면 이 방식이 더 효율적임
display: contents는 UL 요소를 레이아웃에서 완전히 제거함그래서 스타일을 적용하거나 해당 요소에 UI 이벤트를 받을 수 없음
UL을 하이라이트 영역이나 스크롤 가능한 섹션으로 쓰고 싶다면 subgrid가 훨씬 유용함
fr대신 다른 단위를 쓰고, 텍스트에는fr을 써서 남은 공간을 채우게 하면 됨예전에 가격 비교 UI를 만들 때 subgrid가 없어서 정말 고생했음
두 개의 테이블을 나란히 두고 행을 맞추는 게 불가능했음
고정 높이나 JS 계산으로 해결할 수는 있었지만, React 컴포넌트 구조에서는 너무 비효율적이었음
Container queries가 더 나은 해결책 아닌가 생각했음
하지만 전체 그리드의 일관성을 유지하려면 subgrid가 더 적합할 수도 있음
참고로 CodePen 예제를 보면 이해가 쉬움
게다가 container를 쓰면 새로운 stacking context가 생겨서 불편함
subgrid와 container를 함께 쓸 수 없다는 게 아쉬움. subgrid 크기를 자식이 참조할 수 있다면 정말 강력할 것 같음
“결국 <table> 레이아웃으로 돌아온 건가?”라는 생각이 듦
Grid 시스템은 시각적 배치를 위한 도구이지, 데이터 구조를 표현하는 테이블과는 다름
이제는 그리드가 표준으로 자리 잡았으니, 더 이상 테이블과 비교하지 않았으면 함
하지만 반응형이나 접근성은 전혀 고려되지 않았음. 결국 우리는 테이블을 다시 발명한 셈임
결국 CSS가 그 기능을 개선된 형태로 다시 구현한 셈임
예전에 겪은 grid 버그 중 하나는
<img>요소를 퍼센트 단위로 크기 지정하면 셀 크기가 원본 이미지 크기로 왜곡되는 현상이었음Firefox와 Chromium 모두에서 발생했고, 관련 버그는 Mozilla Bug 1857365에 있음
CSS가 레이아웃을 위해 문서 구조 정보를 추가해야 하는 경우가 종종 있어서 아쉬움
예를 들어 행 개수를 명시해야 하는 점이 그렇음
혹은 한 flex 컨테이너가 다른 컨테이너의 분포를 모방할 수 있다면 좋겠음
하지만 그렇게 하면 DX가 복잡해질 가능성이 큼
왜 코드 예제에서 HTML과 CSS 파일 둘 다에 스타일이 들어있는지 궁금했음
첫 번째 subgrid 예제의 CSS만 보고는 UL에 어떤 스타일이 적용됐는지 한참 찾았음
“결국 다시 grid로 돌아온 건가?”라는 생각이 듦
예전 HTML 시절에도 비슷한 걸 했었음
Josh의 블로그 글은 항상 감탄스러움
글의 명료함, 디자인 감각, 인터랙티브한 웹사이트까지 모두 훌륭함
개인적으로 grid는 여전히 다루기 불편함
문법도 어색하고 레이아웃 감각도 잘 안 맞음. Flexbox가 훨씬 직관적이고 유연함
Flexbox는 콘텐츠 중심, Grid는 컨테이너 중심으로 크기를 제어함
콘텐츠가 여러 축에 자동으로 맞춰지지 않고, 모든 걸 수동으로 배치해야 함
아마 내가 grid의 본질을 잘 못 이해했거나, 내 작업 유형과 맞지 않는 것 같음