사소한 지적이지만, responsive design 의 정의는 “다양한 기기와 창/화면 크기에서 잘 렌더링되게 해 사용성과 만족도를 보장하는 것”임
미디어 쿼리나 컨테이너 쿼리는 이를 구현하는 도구 중 하나일 뿐이고, 반응형 디자인은 “모든 것에 미디어 쿼리를 쓰자”보다 사고방식에 가까움
그래서 “나쁜 것”은 반응형 디자인 자체가 아니라, 미디어 쿼리나 중단점 남용이라고 보는 게 맞아 보임

“Browser defaults” 부분은 꽤 오해를 부름. 리셋 스타일시트와 정규화 스타일시트는 목적과 동작이 매우 다르고, 글에서는 이를 섞어 말하고 있음
리셋은 브라우저 간 차이를 없애기보다 요소 간 기본 차이를 지워 ol의 padding-inline-start나 button의 기본 외형 같은 것을 없애고, 사용자 에이전트 스타일시트 위가 아니라 백지에서 스타일을 만들게 해줌
정규화는 사용자 에이전트 스타일시트와 협력하려는 접근이고, 브라우저 간 차이를 맞추는 부분과 “더 합리적”이라고 본 기본값으로 바꾸는 부분이 섞여 있음
요즘은 브라우저 기본값이 의미 있게 다른 경우가 많지 않아서 일반 웹 콘텐츠 작성자는 거의 무시해도 됨. 예외로 Chromium has the wrong tableborder-color, WebKit fixed theirs 1½ years ago, 일부 폼 요소의 여백/크기 차이, 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로 구현했고, 뷰포트가 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로 결론내리기보다 일반 규칙/선택자를 두고 필요할 때 예외 기반 클래스나 유틸리티 클래스를 뿌릴 수 있음
글 안에도 괜찮은 선택자 예제가 있음:

section > + {
margin-top: 1rem;
}

미디어 쿼리도 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 중심 도구로 급격히 이동했음

흥미로운 글이지만, 작성자가 중첩 선택자를 아무 효과 없는 위치에서 쓰는 것 같음

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 같은 잘못된 접근으로 이어지기 쉬움