다만 Dave의 예전 포트폴리오 겸 블로그인 http://www.mezzoblue.com과 Bright Creative 사이트는 사라졌음. 현재 사이트인 https://daveshea.com/으로 연결해 두지 않은 게 아쉬움.
Dave Shea, Doug Bowman, Jeffrey Zeldman 같은 이들은 작은 블로그를 꾸미며 언젠가 SXSW에 가겠다고 꿈꾸던 십 대의 나에게 큰 영향을 줬음. 잘 지내길 바람.
덧붙이자면, Shopify에서 6년을 보낸 뒤 최근 퇴사했음. https://lnkd.in/p/dcYBvQfq에서 확인 가능함.

내 글에도 이 사이트를 연결해 두었음. 지금 CSS를 배우는 사람에게도 훌륭한 자료임.

스타일과 콘텐츠의 분리가 가능하다는 걸 보여 주려고 누군가 내게 소개했던 사이트임. 이후 레이아웃을 구현하다 막히면 CSS-Tricks에서 자주 답을 찾곤 했음.

훌륭한 작업이지만, HN에서는 CSS Zen Garden이나 그 시절의 CSS를 달갑게 보지 않는 이들이 꽤 있음. 마크업과 스타일시트의 관심사 분리를 잘못된 발상으로 보고 Tailwind가 이를 해결한다고 여기지만, 내 생각은 반대임. 관심사 분리는 좋고 Tailwind는 임시방편에 가까움.
핵심은 이제 표준 웹 플랫폼만으로도 디자인 시스템에 기반한 CSS 앱 컴포넌트를 실제 서비스에서 제대로 구현할 수 있다는 점임.
HTML과 CSS는 원래 앱 SDK가 아니라, 문서 사이에 하이퍼링크가 있는 Word나 PDF 같은 디지털 문서를 표시하려고 설계된 언어임. 제목, 문단, 바닥글의 스타일을 한곳에서 바꾸면 사이트 전체에 반영된다는 꿈을 CSS Zen Garden이 보여 주려 했던 것임. 상호작용과 웹 앱은 나중에 등장했고, CSS가 따라잡기까지 오랜 시간이 걸렸음.
이제는 따라잡았으니 프런트엔드 개발이 Tailwind와 React를 벗어나 발전한 표준 웹 플랫폼으로 향하길 바람. Lit 같은 초경량 웹 컴포넌트 라이브러리를 쓰는 것도 좋음. https://lit.dev.

Tailwind를 여러 번 써 봤고 이번 프로젝트에서도 잠깐 검토했지만, 개인적으로는 와닿지 않았음. CSS의 패러다임을 이해하지 못했고 이해하고 싶어 하지도 않는 이들이 만든 접근법처럼 느껴졌음. CSS로 경력을 시작해서인지 나는 원래 방식에 더 충실한 편임.

CSS Zen Garden의 꿈과는 연결점이 전혀 보이지 않음. Zen Garden은 같은 마크업에 완전히 다른 스타일을 적용하는 작업이었음. 이 글은 사용자 지정 속성, Flex, Grid 같은 새로운 CSS 기능으로 평범한 웹사이트 하나의 스타일시트 하나를 유지보수하는 얘기임.

타당한 비판이라 관련 내용을 글에 추가했음. 완전히 다른 스타일들은 꿈을 보여 주는 수단이었지 꿈 자체의 본질은 아니었다고 봄.
본질은 CSS의 힘과 관심사 분리, 브라우저 지원이 열어 주는 가능성을 보여 주는 데 있었음. Firefox를 위해 만든 결과물도 바로 그것을 보여 준다고 생각함.

글이 작성자의 컨설팅 페이지 링크와 “팀의 프런트엔드 기반을 재검토하고 있다면 연락해 달라”는 문구로 끝나는 걸 보니, 공개하지 않았을 것 같음.

현재 firefox.com은 무척 단순한 사이트임. 데스크톱에서는 모든 요소가 너무 커서 태블릿이나 휴대전화 중심으로 보이기도 함.

개인적으로 현재 Firefox.com 디자인이 좋고, 단순함 자체가 장점이라고 봄. 어떤 화면 크기에도 대응하도록 설계했으며, 이런 디자인도 2008년 CSS 2.0으로 만들려면 무척 어려웠을 것임. 그게 이 글의 핵심임.
디자인이 지루하다면 CSS Zen Garden처럼 사용자 스타일시트를 만들어 원하는 모습으로 바꿀 수 있음. 스타일과 마크업이 깔끔하게 분리돼 있어 스타일시트 하나로 수십 개 언어의 수백 페이지를 모두 바꾸는 게 가능함.

무엇을 가리키는지 찾아보다 Firefox 웹사이트라는 걸 알게 됐는데, 직접 방문해 보니 적어도 데스크톱에서는 디자인이 별다른 감흥을 주지 못했음.

CSS Zen Garden은 모두가 하나의 마크업 파일을 사용했기에 가능했고, 현실에서는 잘 통하지 않음. 관심사 분리를 신앙처럼 받아들이기보다 HTML에서 실제로 어떤 이점을 주는지 따져 봐야 함.
마크업과 스타일을 완전히 분리하면 CSS 규칙을 DOM에 대응시키는 방법이 필요함. 특정 요소와 배치를 전제로 하므로 마크업이 어긋나면 스타일이 의도대로 적용되지 않고, CSS가 DOM 구조를 고려하지 못하면 규칙을 수정하거나 추가해야 함.
이런 대응 관계는 코드 외에 이해해야 하는 암묵적 구조임. 브라우저는 계산할 수 있지만 코드를 읽는 개발자에게 명시적으로 드러나지는 않음. 반면 Tailwind나 Tachyons는 구조 대부분이 명시적이고 덜 복잡하며 쉽게 찾아볼 수 있음.
숨겨진 구조는 코드를 깔끔해 보이게 하지만, 그 구조에 대한 이해는 오래 유지되기 어렵고 결국 갚아야 할 기술 부채가 됨. Tailwind는 보기에는 지저분해도 간단한 규칙과 최소한의 설정 파일 외에 숨겨진 추상화나 구조가 없음.
정해진 DOM 패턴을 가진 컴포넌트 라이브러리로 고도로 추상화한 CSS를 운영할 수도 있음. 하지만 그럴 거라면 복잡성을 더하기보다 Tailwind처럼 스타일을 컴포넌트에 직접 넣는 편이 낫지 않을까?

CSS Zen Garden의 꿈은 애초에 그 자체를 넘어서는 데 있지 않았음. 전혀 다르게 보이는 페이지들이 모두 같은 HTML이라는 걸 보여 주는 게 핵심이자 마법이었음.
당시에는 페이지 배치를 위해 구조를 담당하는 HTML이 여전히 필요했고, 대부분의 사이트에서 마크업이 외형을 결정했음. FrontPage와 Dreamweaver 같은 도구는 CSS를 거의 생성하지 않았고, 생성하더라도 좋은 CSS는 아니었음.
사이트 자체도 CSS의 힘을 보여 주고 참여와 영감을 끌어내는 것이 목적이라고 밝힘. 구조에서 아름다움을 만들어 낼 수 있는 이들에게 맡겼을 때 CSS가 문서의 스타일을 얼마나 완벽하게 제어할 수 있는지 보여 주려던 것임.

Tailwind는 CSS의 어셈블리어임. 구조도 의미도 추상화도 없이 시각적 표현의 세부 요소만 조작함.
이를 택한다는 건 의미 기반 클래스 같은 추상화를 활용할 제품 구조와 디자인 비전이 부족하다는 걸 인정하는 셈임. 나머지를 건드리면 무너질까 봐 서로 단절된 일부 영역만 고치는 데 그치며, 어셈블리어는 그런 땜질에 확실히 적합함.
충분한 배려 없이 담당자와 방향이 여러 차례 바뀐 오래된 대형 제품은 흔히 이런 종착점에 도달함.

진짜 갈림길은 관심사 분리나 암묵적·명시적 구조의 차이가 아님. 마크업을 도메인 개체를 표현하는 데이터 형식으로, 또는 표현상의 관심사를 일반화하는 수단으로 고민하려는 인력이 있는지가 핵심임.
대부분의 개발자와 조직은 그런 고민도, 그 이유와 이점을 따지는 일도 원하지 않음. Tailwind가 제공하는 국소 최적점에 적당히 만족하며 여기서처럼 익숙한 구호를 되풀이할 수 있음. 가장 흔한 유형인, 깊은 성찰 없는 제품 관리와 특히 잘 어울림.

CSS Zen Garden은 하나의 마크업 파일로 만든 개념 증명이었음. 그 개념을 수백 개의 동적 페이지와 잘 설계된 CSS 디자인 시스템으로 확장하면 CSS의 진짜 힘이 드러남.
현실에서도 아주 잘 작동하며, Firefox에 이 개념을 적용해 입증했음. 캐스케이드와 명시도를 이해하고 스타일시트를 작성한다면 마크업 구조 때문에 규칙이 의도대로 적용되지 않는다는 비판도 들어맞지 않음.

HTML과 스타일은 본래 서로 결합돼 있음. 기술적으로 분리할 수는 있지만, 실제로는 디자인과 HTML·CSS의 표현력을 제한하게 됨. Zen Garden도 대부분의 경우 CSS 3 이상을 금지함.
HTML 구조는 스타일을 제약하므로 HTML을 작성할 때도 스타일을 알아야 함. 폭넓은 스타일 교체가 꼭 필요하다면 분리할 수 있지만, 디자인 가능성을 크게 줄이고 대개 불필요한 복잡성을 더하게 됨. 현지화만 봐도 문서와 스타일의 상호 의존성이 드러남. 언어마다 텍스트 길이가 달라 간격, 안쪽 여백, 반응형 전환점을 조정해야 할 수 있음.
Qt, GTK, SwiftUI, Flutter 등 UI 체계가 스타일과 구조를 긴밀히 결합하는 이유도 여기에 있음. CSS와 HTML도 마찬가지인데, 원래 느슨하게 결합돼야 한다고 착각하는 이들이 있을 뿐임.

@import 성능 문제를 해결하려고 후처리기를 남겨 둔 건가? 가져오는 내용을 인라인으로 넣으면 어떻게 해결되나? 페이지를 열 때 글꼴이 깜빡였음.
글꼴 가져오기에 관한 글은 아닐 수도 있지만, 글꼴은 HTML 헤더에서 불러오거나 그냥 시스템 글꼴을 쓰는 편이 나음.

CSS 가져오기는 스타일시트 의존성 트리를 만듦. 모든 스타일을 불러오고 파싱하기 전까지 렌더링할 수 없으므로, 처리를 막는 순차적 의존성이 생김.

Zen Garden처럼 동일한 콘텐츠에 서로 다른 디자인을 둘 이상 제공하는 실제 웹사이트가 있나?

2000년대 초 웹사이트 개발을 시작했을 때, 개인별로 테마를 적용한 사이트를 빠르게 개설해 주는 사이트 네트워크를 만들었음. 모두 같은 백엔드와 컴포넌트를 사용하면서 디자인과 사용자 지정 스타일시트는 각기 달랐음.
아주 흔한 패턴이며, 테마를 지원하는 웹사이트 제작 플랫폼 상당수가 이 방식에 기반함.

전통적인 예로 테마를 지원하는 소프트웨어가 있음. 사이트 운영자는 테마를 처음부터 새로 만들지 않고 기존 CSS를 복제해 대폭 수정하는 방식으로 외형을 바꾸곤 함. 오래 사용하는 애플리케이션에서는 사용자가 직접 테마를 선택하기도 함.
다만 기본 테마가 지원한다면, 단순한 색상 변경 같은 용도는 이제 CSS 사용자 지정 속성이 상당 부분 대체함.