# CSS: 피할 수 없는 나쁜 부분들

> Clean Markdown view of GeekNews topic #30335. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30335](https://news.hada.io/topic?id=30335)
- GeekNews Markdown: [https://news.hada.io/topic/30335.md](https://news.hada.io/topic/30335.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-10T09:15:54+09:00
- Updated: 2026-06-10T09:15:54+09:00
- Original source: [matklad.github.io](https://matklad.github.io/2026/06/04/css-unavoidable-bad-parts.html)
- Points: 2
- Comments: 1

## Topic Body

- 웹페이지 스타일링은 단순한 블로그나 GUI에는 배울 수 있는 작은 하위 집합으로 충분하지만, **브라우저 기본값**과 레이아웃 같은 함정이 며칠짜리 디버깅으로 이어질 수 있음
- 의미 있는 HTML5 태그를 먼저 쓰고 래퍼를 줄이면, CSS가 기존 마크업에 맞춰 작동하도록 만들기 쉬워짐
- CSS 레이아웃에는 보편적인 단일 알고리듬이 없으며, 각 시스템이 허용하는 배치 방식을 이해하는 접근이 필요함
- `box-sizing`, `margin`, `font-size`, `line-height`, `word-break`는 직관과 다르게 작동해 작은 변경이 전체 배치나 가독성 문제로 번질 수 있음
- 단순한 페이지에는 **CSS reset**, classless CSS, flexbox, 과도하지 않은 반응형 규칙이 실용적인 출발점이 될 수 있음

---

### CSS 학습의 범위와 기본 관점
- CSS, HTML, Web API는 매우 방대해 전문성이 필요하지만, 프로그래밍 블로그나 단순 GUI 같은 작업에는 현대 웹의 적당한 하위 집합으로 충분함
- 단순 작업에 필요한 하위 집합만 가르치는 자료는 보지 못했지만, MDN을 따라가며 어느 정도 파악할 수 있음
- 문제는 존재를 예상하지 못한 함정이 페이지를 망가뜨리고, 원인을 찾는 데 며칠이 걸릴 수 있음
- 이 사이트의 스타일링은 약 [200줄의 읽을 수 있는 CSS](https://matklad.github.io/css/main.css)로 구성됨

### 좋은 부분: 의미 있는 HTML과 classless CSS
- ## HTML5 의미 태그
  - MDN의 [Elements Reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements)를 훑어볼 가치가 있으며, HTML 요소 수가 아주 많지는 않음
  - `main`, `article`, `nav`, `kbd` 같은 태그는 페이지 구조를 더 쉽게 만들 수 있음
  - `ul`은 `header > nav` 안의 사이트 섹션처럼 모든 종류의 목록에 쓸 수 있음
  - `details`는 목차에 쓸 수 있으며, MDN 소스를 확인할 수 있음
  - `dl`과 `dt`는 쌍으로 된 목록에 사용할 수 있음
- ## 래퍼를 줄이는 접근
  - 실제 웹사이트의 소스를 보면 여러 겹의 래퍼 요소가 많아 레이아웃 문제를 래퍼로 푸는 방식처럼 보일 수 있음
  - 프로덕션 CSS 경험에 대한 판단은 유보되지만, 의미 있는 시맨틱 태그만 쓰도록 제한한 뒤 그 마크업에 맞는 CSS를 찾는 방식이 더 이해하기 쉬웠음
- ## Classless CSS
  - 스타일을 완전히 중립적인 “아무것도 없음” 상태로 초기화할 수는 없으며, 흰색이나 투명 텍스트도 여전히 스타일임
  - 초기화 뒤에는 공통 HTML 요소를 직접 스타일링하는 방식이 가능함
  - `main`, `header`, `footer`, `nav` 태그를 쓰면 CSS 선택자를 많이 쓰지 않고도 전체 페이지 레이아웃을 설정할 수 있음
  - 이 방식은 CSS가 HTML 구조를 가정하게 만들지만, 자신의 HTML과 CSS라면 결과가 마음에 들지 않을 때 바꿀 수 있음

### 나쁜 부분: 레이아웃, 브라우저 기본값, 선택자
- ## 레이아웃
  - 레이아웃 문제는 웹만의 문제가 아니며, 여러 GUI 프레임워크에서 어려운 문제임
  - 고정 크기 래스터 이미지와 이를 설명하는 텍스트 문단을 화면 사각형에 배치하는 방식은 여러 가지임
  - 일반적인 GUI는 많은 “레이아웃 자유도”를 가진 박스들의 계층 구조임
  - 각 박스의 레이아웃은 다른 모든 박스의 레이아웃에 영향을 주며, 보통 간격과 겹침 없이 모든 박스가 정확히 맞닿아야 함
  - 보편적인 단일 레이아웃 알고리듬은 없으며, [RectCut](https://web.archive.org/web/20210306102303/https://halt.software/dead-simple-layouts/)부터 [constraint solvers](https://github.com/inamiy/Cassowary), 그 [중간 영역](https://www.youtube.com/watch?v=UUfXWzp0-DU)까지 시스템마다 다른 휴리스틱을 사용함
  - “주어진 시스템에서 레이아웃을 어떻게 만들까”보다 “그 시스템이 허용하는 레이아웃은 무엇인가”를 생각하는 편이 나음
- ## 브라우저 기본값과 CSS reset
  - CSS가 없는 의미 있는 HTML도 브라우저에서는 색, 글꼴, 크기, 큰 제목, 밑줄 링크 등 기본 스타일이 적용됨
  - 기본 스타일은 도움이 되지만 브라우저마다 다르며, 작성하지 않은 기본값에 의존하면 다른 브라우저에서 다른 결과가 보일 수 있음
  - 일반적인 해결책은 [CSS reset](https://www.joshwcomeau.com/css/custom-css-reset/) 또는 정규화로, CSS 시작 부분에서 명시적인 규칙으로 기본값을 덮어쓰는 방식임
  - 기본값 자체가 나쁜 것이 아니라 서로 일관되지 않은 것이 문제임
  - 실제로 어떤 규칙을 덮어써야 하는지는 여러 기존 CSS reset을 비교하는 편이 좋음
- ## 웹페이지를 스타일링해야 하는가
  - 웹 플랫폼에는 유연하고 적응적인 시각 매체로 보는 관점과, 콘텐츠 전달에 집중하고 사용자가 표현을 커스터마이즈해야 한다는 관점이 함께 존재함
  - 기본적으로 스타일이 없는 페이지는 사용성이 낮고 보기 좋지 않음
  - CSS 없는 페이지가 그대로 읽기 쉬운 세계가 더 낫겠지만, 현재 환경에서는 콘텐츠에 스타일을 적용하는 일이 도움이 됨
  - 고급 사용자가 자신의 CSS를 가져올 수 있도록 허용하는 것이 좋음
  - HTML 마크업은 합리적이어야 하고, HTML을 CSS에 과적합하지 않아야 하며, 페이지가 reader mode에서 작동해야 함
- ## CSS 선택자
  - 기본 CSS는 강력한 상속처럼 작동하며, 웹페이지의 각 디자인 요소가 여러 규칙의 영향을 받음
  - CSS 파일에 덧붙이는 방식으로 기존 요소를 언제든 “monkey patch”할 수 있음
  - CSS 선택자가 잘못된 축으로 추상화 능력을 더한다고 보고, classless CSS와 inline style을 쓰는 접근이 가능함
  - Tailwind 같은 도구로 inline 작성의 불편함을 줄이고, JSX나 조합을 지원하는 템플릿 엔진으로 HTML 반복을 줄일 수 있음
  - [CSS nesting](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Nesting)을 사용하면 멀리 뻗는 선택자를 줄이고 컴포넌트 단위로 스타일링할 수 있음

### 박스 모델과 배치: `box-sizing`, margin, 기본 flow, flexbox
- ## `box-sizing`
  - UI는 재귀적인 사각형이며, 레이아웃은 각 사각형이 어디에 놓이는지 정하는 과정임
  - HTML 기본값에서 요소의 `width`와 `height`는 border와 padding을 포함하지 않아 직관적이지 않음
  - 어느 한 곳의 padding을 늘리면 처음에는 완벽해 보이던 전체 레이아웃이 예기치 않게 밀릴 수 있음
  - `* { box-sizing: border-box; }`는 CSS reset의 첫 줄이 될 만하며, border 추가를 지역적인 변경으로 만들 수 있음
- ## margin collapsing
  - 어떤 요소 주변에 `8px` 간격을 원한다고 해서 padding을 쓰면, 인접한 두 요소 사이 간격이 `16px`가 될 수 있음
  - `margin`은 두 이웃 margin을 합산이 아니라 `max`로 결합하는 방식으로 작동함
  - margin collapsing은 매우 유용하지만 놀라운 동작을 만들 수 있음
  - 자식 margin이 부모 밖으로 튀어나올 수 있다고 보지만, margin에 대한 직관적 이해는 충분하지 않음
  - Julia Evans의 글 *Moving away from Tailwind, and learning to structure my CSS*는 일반적으로 요소 자체에 margin을 주기보다 부모가 자식 사이 margin을 제어하는 owl selector 방식을 다룸
  - `section`의 첫 번째 자식을 제외한 모든 자식에 margin을 추가하는 방식은 margin 문제를 줄이는 아이디어로 이해됨
  - 이런 지식은 전문 웹 개발자가 되거나 다른 CSS 프레임워크를 역공학하지 않으면 배우기 어렵다는 점이 불편함
- ## 기본 flow 레이아웃
  - 기본 레이아웃 알고리듬은 문서 언어로서의 HTML 기원과 관련이 있으며, 텍스트와 그림 중심의 종이 문서 생성 사례에 맞춰진 것으로 보임
  - 본문 텍스트에는 기본 flow가 실제로 원하는 동작에 가깝게 작동함
  - 페이지 요소의 공간 배치를 직접 제어하려면 기본 flow와 다른 방식이 필요함
- ## flexbox
  - [flexbox](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Flexbox)는 일련의 요소를 세로 또는 가로로 배치하고, 사용 가능한 공간에 맞춰 적응시키는 레이아웃임
  - 과거에는 “이것은 왼쪽, 이것은 오른쪽” 같은 배치에도 깊은 CSS 지식이나 불투명한 CSS 프레임워크가 필요했음
  - flexbox는 꽤 복잡해 MDN을 계속 참고해야 하지만, 대체로 원하는 작업을 끝낼 수 있음
- ## 반응형 디자인
  - 현대 CSS는 화면 크기를 질의하고 사용자 에이전트 제약에 따라 조건부 로직을 구현할 수 있음
  - HTML은 본질적으로 반응형이며, PostScript나 PDF와 달리 창 크기가 바뀌면 문단을 자동으로 다시 흐르게 함
  - 명시적인 반응형 규칙을 피하고 레이아웃이 합리적으로 동작하도록 맡기는 것이 좋음
  - 이 블로그는 명시적인 `@media` 쿼리 없이 모바일, 태블릿, 데스크톱에서 괜찮게 보임
  - 본문 텍스트의 메인 컬럼에 `max-width`를 무조건 설정하는 것만으로 충분함

### 크기와 텍스트: 픽셀, 글꼴, 줄 높이, 줄바꿈
- ## 픽셀
  - `1px`는 원하는 일을 하지만, 화면의 물리적 픽셀 하나라는 뜻은 아님
  - CSS의 `1px`는 [시각각](http://inamidst.com/stuff/notes/csspx)의 단위이며, 어떤 화면에서도 지각적으로 비슷하게 보이도록 설계됨
  - 화면 크기, 픽셀 밀도, 일반적인 시청 거리에 따라 서로 다른 수의 물리적 픽셀로 변환됨
  - 따라서 서로 다른 디스플레이의 픽셀 밀도를 따로 생각하지 않고도 모든 크기를 픽셀로 지정할 수 있음
  - CSS의 센티미터와 인치 같은 “실제” 단위도 픽셀을 기준으로 정의되므로 각도처럼 작동함
- ## `font-size`
  - `font-size: 16px`에서 `16px`는 특정 글리프 크기가 아니라 글리프 주변의 가상 박스 크기임
  - 이 박스는 글리프에 딱 맞지 않으며, 실제 글리프 크기는 글꼴에 따라 달라짐
  - `font-size-adjust`는 글꼴 간 `font-size`를 더 일관되게 만들 수 있음
  - 현재 `font-size-adjust`는 매우 틈새 기능처럼 보이며, 개인적으로는 `box-sizing` 옆에 `font-size-adjust: ex-height 0.53;`을 두고 싶지만 그렇게 하는 페이지는 적음
  - `font-size` 기본값은 브라우저 사이에서 비교적 일관되며, `16px`가 압도적인 기본값임
  - 글꼴에 따라 `16px`가 작게 보일 수 있고, 일부 기본 글꼴은 특히 작음
  - Apple에서 `font-family: serif`는 `sans-serif`보다 훨씬 작게 보이며, `16px`에서는 거의 읽기 불편함
  - CSS에서 `font-size`를 설정하면 브라우저의 기본 글꼴 크기 변경 방식을 비활성화함
  - 텍스트가 기본적으로 읽기 쉬울 것이라고 가정하지 말고 다른 설정에서 확인해야 함
  - `font-size-adjust`로 자유도를 줄이고 `font-size`의 의미를 고정한 뒤, `16px` 기본 글꼴 크기에서 괜찮으면 완료됨
  - 그렇지 않으면 `font-size`를 더 큰 숫자로 설정하고, 이후 reader mode에서도 읽기 쉬운지 확인해야 함
- ## `line-height`
  - 이름과 달리 `line-height`는 한 줄의 높이를 설정하지 않음
  - `line-height`는 같은 글꼴로 설정된 글리프 묶음의 높이임
  - 모든 텍스트가 같은 글꼴일 때는 줄 높이와 글리프 묶음 높이가 일치함
  - 일부 단어가 `monospace` 글꼴로 설정되면 예상과 다른 결과가 생길 수 있음
  - `font-size-adjust`는 박스 안의 글리프 크기를 고치지만, 상대적 위치까지 지정하지는 않음
  - 서로 다른 글꼴의 텍스트 묶음이 baseline을 공유하도록 수직 정렬되면, 각자의 line-height line-box가 서로 어긋남
  - 전체 줄 높이는 합집합처럼 구성되어 예상보다 커질 수 있음
  - 이 효과는 [Deep dive CSS: font metrics, line-height and vertical-align](https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align)에서 자세히 다룸
- ## vertical rhythm
  - vertical rhythm은 제목, 이미지 등이 있어도 문단 사이의 줄 위치가 같은 상대 위치에 오도록 맞추는 아이디어임
  - 웹페이지 뒤에 보이지 않는 줄노트가 있는 것처럼 맞추는 방식으로 설명됨
  - 단일 컬럼 레이아웃에서는 유용하지 않은 것으로 판단됨
  - 2컬럼 레이아웃에서는 양쪽 줄을 맞추고 싶을 수 있음
  - 단일 컬럼에서 이를 위해 복잡한 노력을 들이는 것은 말이 되지 않음
- ## `word-break`
  - flow 레이아웃의 장점은 창이 좁아질 때 텍스트가 줄로 깔끔하게 나뉘는 동적 동작임
  - 줄은 공백이나 하이픈 삽입 지점에서만 끊을 수 있음
  - `inline code`나 URL 같은 긴 구간은 끊기지 않을 수 있음
  - 이 문제는 모바일 기기에서 가로 오버플로를 일으키며, 보통 게시 후에야 알아차리게 됨
  - 이를 고치는 단일 비법은 없지만, [Against Horizontal Scroll](https://matklad.github.io/2025/04/22/horizontal-scroll.html)에 몇 가지 팁이 있음

### 실용적인 결론
- 단순한 블로그를 만들기 위해서는 HTML과 CSS의 충분한 부분만 짧게 설명하는 자료가 필요함
- margin collapsing 같은 문제에 무너지지 않고 단순 블로그를 만들 정도의 HTML과 CSS를 설명하는 100쪽짜리 짧은 책에 대한 요청으로 마무리됨

## Comments



### Comment 59299

- Author: neo
- Created: 2026-06-10T09:15:55+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/pwmlvz/css_unavoidable_bad_parts) 
- 사소한 지적이지만, **[responsive design](https://en.wikipedia.org/wiki/Responsive_web_design)** 의 정의는 “다양한 기기와 창/화면 크기에서 잘 렌더링되게 해 사용성과 만족도를 보장하는 것”임  
  미디어 쿼리나 컨테이너 쿼리는 이를 구현하는 도구 중 하나일 뿐이고, 반응형 디자인은 “모든 것에 미디어 쿼리를 쓰자”보다 사고방식에 가까움  
  그래서 “나쁜 것”은 반응형 디자인 자체가 아니라, 미디어 쿼리나 **중단점 남용**이라고 보는 게 맞아 보임

- “Browser defaults” 부분은 꽤 오해를 부름. **리셋 스타일시트**와 **정규화 스타일시트**는 목적과 동작이 매우 다르고, 글에서는 이를 섞어 말하고 있음  
  리셋은 브라우저 간 차이를 없애기보다 요소 간 기본 차이를 지워 `ol`의 `padding-inline-start`나 `button`의 기본 외형 같은 것을 없애고, 사용자 에이전트 스타일시트 위가 아니라 백지에서 스타일을 만들게 해줌  
  정규화는 사용자 에이전트 스타일시트와 협력하려는 접근이고, 브라우저 간 차이를 맞추는 부분과 “더 합리적”이라고 본 기본값으로 바꾸는 부분이 섞여 있음  
  요즘은 브라우저 기본값이 의미 있게 다른 경우가 많지 않아서 일반 웹 콘텐츠 작성자는 거의 무시해도 됨. 예외로 [Chromium has the wrong `table` `border-color`](https://issues.chromium.org/issues/40615503), [WebKit fixed theirs 1½ years ago](https://bugs.webkit.org/show_bug.cgi?id=195016), 일부 폼 요소의 여백/크기 차이, `appearance`, WebKit의 `<summary>` `::marker` 스타일링 정도가 남아 있음  
  `box-sizing: border-box`에도 반대하는 쪽임. `border-box`는 **레이아웃** 중심이고 `content-box`는 **콘텐츠** 중심이라, 부모가 레이아웃을 맡고 콘텐츠 기준으로 설계하는 편이 낫다고 봄. 비율을 다룰 때는 `content-box`가 필요하고, `border-box`가 실제로 유용한 경우는 `body`를 뷰포트에 채우는 정도임  
  `font-size-adjust`에 대해서도 회의적임. 널리 알려진 문제를 덜 검증된 문제로 바꾸며, 어떤 사람에게는 조금 낫고 다른 사람에게는 조금 나빠질 수 있음. 근본 문제는 풀 수 없고, 사용자의 폰트 비율과 메트릭에 근거 없는 가정을 하게 됨  
  `line-height`와 “같은 폰트로 설정”이라는 표현도 엄밀하지 않음. 실제로는 폰트 크기, 언어 전환, `font-family: monospace`, `vertical-align`, `<sup>`, `<sub>`, 폰트 메트릭이 얽혀 있어서 단순히 같은 폰트 문제라고 보기 어려움  
  **마진 병합**은 글보다 더 복잡하지만 꽤 실용적이기도 함. 일반 콘텐츠에 `flex`나 `grid`를 쓰면 `gap`이나 마진을 계속 만져야 해서 취약해지기 쉬움. `display: flow-root`를 쓰면 자식 마진이 부모 마진과 병합되는 것을 막을 수 있음  
  반응형 디자인에 대한 큰 틀에는 동의하지 않지만, 불필요한 미디어 쿼리를 줄이고 브라우저와 싸우지 않는 방향은 맞음. 콘텐츠 기준으로 레이아웃 변화를 표현할 수 있다면 대체로 그쪽이 더 낫다  
  최근에는 뷰포트 단위를 이용한 **clamp 선형 보간**을 많이 씀: `margin-inline: --vw-lerp(1rem at 20rem, 2.5rem at 60rem);`를 `margin-inline: clamp(1rem,1rem + ((2.5 - 1)/(60 - 20)*(100vw - 20rem)),2.5rem);`로 확장하는 식임  
  작년에 [implemented this as a LightningCSS visitor](https://temp.chrismorgan.info/2026-06-09.--vw-lerp.lightningcss.js)로 구현했고, 뷰포트가 20rem 이하일 때 1rem, 60rem에서 2.5rem까지 부드럽게 증가한 뒤 멈추게 되어 중단점 없이 사용자 폰트 크기에도 대응돼 느낌이 좋음
  - `font-size-adjust`가 그렇게 동작하는지는 잘 모르겠음. 이름 때문에 헷갈리지만 `font-size`는 em 박스 크기를, `font-size-adjust`는 em 박스 안의 **글리프 크기**를 바꾸는 것으로 이해하고 있음  
    그래서 `em`과 `rem`은 그대로이고, `ch`는 바뀜. 그런데 `ch`는 원래 폰트 의존적이니 바뀌는 게 맞음  
    `font-size-adjust`에 대해 글을 써줬으면 함. 전문가는 아니어서 확신은 낮지만, 지금까지는 거의 알려지지 않았으면서도 **엄청난 개선**처럼 보임. 어떤 두 폰트든 모든 맥락에서 자동으로 맞출 수는 없지만, em 박스가 아니라 `x`의 크기를 맞추는 것만으로도 폰트/맥락의 90%는 커버한다고 봄

- 글의 취지는 좋고, HTML/CSS에 완전히 몰입하지 않은 사람들의 관점도 중요하지만, “나쁜 것” 중 상당수는 맥락에 따라 좋을 수 있음  
  **CSS 선택자**는 남용하기 쉽지만 본질적으로 나쁜 건 아님. A 또는 B로 결론내리기보다 일반 규칙/선택자를 두고 필요할 때 예외 기반 클래스나 유틸리티 클래스를 뿌릴 수 있음  
  글 안에도 괜찮은 선택자 예제가 있음:  
  ```css  
  section > *+* {  
    margin-top: 1rem;  
  }  
  ```  
  미디어 쿼리도 [container queries](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Containment/Container_queries)로 해결 가능하다면 필요 없을 수 있음  
  CSS는 표면적이 엄청 넓게 느껴질 수 있지만, 널리 쓰이고 많은 일을 할 수 있는 만큼 의견 충돌도 잦음. 그래도 CSS가 얼마나 발전했는지, 개념을 받아들이면 비교적 적은 코드로 무엇을 할 수 있는지도 봐야 함  
  더 배우고 싶다면 https://every-layout.dev/ 가 CSS에서 여러 요소가 어떻게 맞물리는지 이해하는 데 꽤 도움이 됐음
  - **Every Layout** 추천에 한 표 더함. 아직도 CSS를 좋아하진 않고, 개인적으로는 캐스케이드가 레이아웃 모델로 근본적으로 별로라고 생각하지만, 이제는 데스크톱과 모바일에서 대체로 그럴듯하고 반응형으로 보이게 만들 수 있음  
    웹 레이아웃이 이해되기 시작한 계기는 좋은 웹사이트가 기본적으로 **세로형 설계**라는 걸 깨달았을 때였음. 요소는 기본적으로 위아래로 쌓여야 하고, 모바일 화면을 먼저 설계한 뒤 큰 화면에서는 보너스로 펼치면 됨

- 이 주장에는 동의하기 어려움. **CSS 중첩**은 문법적 설탕일 뿐이고, 지나치게 구체적인 선택자 문제를 의미 있게 피하게 해주지는 않음  
  15년 전에도 Sass로 선택자 중첩을 많이 썼고, 결국 CSS 선택자를 HTML 구조에 너무 단단히 묶어 스스로 발목을 묶었다는 결론에 하나씩 도달했음  
  중첩의 함정은 프로젝트 초반에는 잘 드러나지 않음. 새 기능을 주로 만드는 그린필드 단계에서는 이런 식으로 CSS를 쓰는 게 아주 좋아 보임  
  몇 달 뒤 큰 레이아웃 수정과 디자인 개편을 시작하면 HTML에서 래퍼 요소들이 자리를 바꾸고, CSS를 거기에 맞추는 일이 LSD를 먹고 **루빅스 큐브**를 푸는 느낌이 됨  
  선택자 구체성 관리는 대부분을 단순 선택자, 즉 클래스 하나로 낮게 유지하고, 소수의 복합 선택자와 `a:hover` 같은 결합 선택자만 쓰는 방식이 정점이었다고 봄. BEM, OOCSS 같은 계열이고, 이후에는 관심이 JS 중심 도구로 급격히 이동했음

- 흥미로운 글이지만, 작성자가 중첩 선택자를 **아무 효과 없는 위치**에서 쓰는 것 같음  
  ```css  
  header { /* Site Header */  
    margin-bottom: 2rem;  
    & nav { /* ampersand redundant here? */  
      /* Styles, specific to nav in the Header. */  
    }  
  }  
  ```
  - `&`를 생략할 수 있게 한 것이 실수라고 보고 항상 `&`를 쓰는 사람들도 있음. 꽤 합리적인 입장이라고 봄  
    개인적으로는 아직 반반임. 처음에는 실수라고 생각했지만, 스타일을 잔뜩 쓴 뒤 `header { … }`로 감싸기만 하면 범위가 좁혀지는 상황에서는 꽤 편리함. `@keyframes` 같은 선택자 기반이 아닌 at-규칙도 그 안에 쓸 수 있으면 좋겠음

- 이건 솔직히 정말 안 좋은 조언임. Maklad 글을 좋아하지만, 이건 **전문적으로 CSS를 써본 적 없는 사람**이 쓴 게 분명해 보임  
  거의 전부가 프로 CSS 작성에서는 피하는 아마추어식 나쁜 관행임
  - 좀 더 구체적으로 말하면, 아마추어에게 주된 설계 대상은 **콘텐츠 박스**임. CMS가 문단, 강조, 링크, 목록을 뱉어내고, 대부분의 시간을 그걸 스타일링하는 데 씀  
    선택자 없이 그걸 스타일링하다 보니 `<main>`이나 `<nav>`도 선택자 없이 꾸미게 됨  
    반면 전문 환경에서는 콘텐츠 박스를 설계하는 시간은 아주 적음. 프로젝트 초기에 한 번 만들고, 이후에는 작은 버그를 천천히 고치는 정도임  
    대부분의 시간은 커스텀 컴포넌트나 재사용 컴포넌트를 만드는 데 들어감. 재사용 컴포넌트는 더 어렵고 사실상 사이트 전용 Bootstrap 클론을 만들게 됨  
    커스텀 컴포넌트는 쉽지만 코드가 많아지고, 다른 컴포넌트와 의도치 않게 간섭하지 않도록 BEM, OOCSS, Tailwind 같은 유틸리티 클래스 등 전략이 필요함  
    결론은 기법마다 맞는 **규모**가 다르다는 것임. 전문적인 CSS 작성 방식이 쓸모없어 보인다면, 아마 다른 규모의 문제를 풀고 있기 때문임
  - 글에서도 명시적으로 “production CSS를 써본 적 없다”고 말함  
    그래도 `Bad: Wrappers`에는 동의함. CSS 전문가가 사이트 전체를 한두 파일로 작성하는 것도 봤고, CSS를 아주 많이 쓰는 사람들도 봤음  
    후자의 길은 결국 많은 CSS를 관리하기 위해 BEM 같은 **잘못된 접근**으로 이어지기 쉬움

- 글 안에는 서로 충돌하는 조언이 있어 보임  
  `Good: Classless CSS`와 `Bad: CSS selectors`가 같이 나오는데, 클래스 없는 CSS를 쓰려면 오히려 CSS 선택자에 더 의존해야 함  
  참고: https://www.keithcirkel.co.uk/css-classes-considered-harmful/

- “보이지 않는 줄공책이 웹페이지 뒤에 있는 것처럼”이라는 **vertical rhythm**은 EM 값을 쓰면 충분히 가능함  
  서로 다른 폰트를 섞으면 메트릭 차이 때문에 약간 흔들릴 수 있지만, 그때도 flex의 `align-items: baseline`을 쓸 수 있음