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

 (matklad.github.io)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 웹페이지 스타일링은 단순한 블로그나 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로 구성됨

좋은 부분: 의미 있는 HTML과 classless CSS

  • HTML5 의미 태그

    • MDN의 Elements Reference를 훑어볼 가치가 있으며, 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부터 constraint solvers, 그 중간 영역까지 시스템마다 다른 휴리스틱을 사용함
    • “주어진 시스템에서 레이아웃을 어떻게 만들까”보다 “그 시스템이 허용하는 레이아웃은 무엇인가”를 생각하는 편이 나음

  • 브라우저 기본값과 CSS reset

    • CSS가 없는 의미 있는 HTML도 브라우저에서는 색, 글꼴, 크기, 큰 제목, 밑줄 링크 등 기본 스타일이 적용됨
    • 기본 스타일은 도움이 되지만 브라우저마다 다르며, 작성하지 않은 기본값에 의존하면 다른 브라우저에서 다른 결과가 보일 수 있음
    • 일반적인 해결책은 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을 사용하면 멀리 뻗는 선택자를 줄이고 컴포넌트 단위로 스타일링할 수 있음

박스 모델과 배치: 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는 일련의 요소를 세로 또는 가로로 배치하고, 사용 가능한 공간에 맞춰 적응시키는 레이아웃임
    • 과거에는 “이것은 왼쪽, 이것은 오른쪽” 같은 배치에도 깊은 CSS 지식이나 불투명한 CSS 프레임워크가 필요했음
    • flexbox는 꽤 복잡해 MDN을 계속 참고해야 하지만, 대체로 원하는 작업을 끝낼 수 있음

  • 반응형 디자인

    • 현대 CSS는 화면 크기를 질의하고 사용자 에이전트 제약에 따라 조건부 로직을 구현할 수 있음
    • HTML은 본질적으로 반응형이며, PostScript나 PDF와 달리 창 크기가 바뀌면 문단을 자동으로 다시 흐르게 함
    • 명시적인 반응형 규칙을 피하고 레이아웃이 합리적으로 동작하도록 맡기는 것이 좋음
    • 이 블로그는 명시적인 @media 쿼리 없이 모바일, 태블릿, 데스크톱에서 괜찮게 보임
    • 본문 텍스트의 메인 컬럼에 max-width를 무조건 설정하는 것만으로 충분함

크기와 텍스트: 픽셀, 글꼴, 줄 높이, 줄바꿈

  • 픽셀

    • 1px는 원하는 일을 하지만, 화면의 물리적 픽셀 하나라는 뜻은 아님
    • CSS의 1px는 시각각의 단위이며, 어떤 화면에서도 지각적으로 비슷하게 보이도록 설계됨
    • 화면 크기, 픽셀 밀도, 일반적인 시청 거리에 따라 서로 다른 수의 물리적 픽셀로 변환됨
    • 따라서 서로 다른 디스플레이의 픽셀 밀도를 따로 생각하지 않고도 모든 크기를 픽셀로 지정할 수 있음
    • 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에서 자세히 다룸

  • vertical rhythm

    • vertical rhythm은 제목, 이미지 등이 있어도 문단 사이의 줄 위치가 같은 상대 위치에 오도록 맞추는 아이디어임
    • 웹페이지 뒤에 보이지 않는 줄노트가 있는 것처럼 맞추는 방식으로 설명됨
    • 단일 컬럼 레이아웃에서는 유용하지 않은 것으로 판단됨
    • 2컬럼 레이아웃에서는 양쪽 줄을 맞추고 싶을 수 있음
    • 단일 컬럼에서 이를 위해 복잡한 노력을 들이는 것은 말이 되지 않음

  • word-break

    • flow 레이아웃의 장점은 창이 좁아질 때 텍스트가 줄로 깔끔하게 나뉘는 동적 동작임
    • 줄은 공백이나 하이픈 삽입 지점에서만 끊을 수 있음
    • inline code나 URL 같은 긴 구간은 끊기지 않을 수 있음
    • 이 문제는 모바일 기기에서 가로 오버플로를 일으키며, 보통 게시 후에야 알아차리게 됨
    • 이를 고치는 단일 비법은 없지만, Against Horizontal Scroll에 몇 가지 팁이 있음

실용적인 결론

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

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

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

  • “Browser defaults” 부분은 꽤 오해를 부름. 리셋 스타일시트와 정규화 스타일시트는 목적과 동작이 매우 다르고, 글에서는 이를 섞어 말하고 있음
    리셋은 브라우저 간 차이를 없애기보다 요소 간 기본 차이를 지워 ol의 padding-inline-start나 button의 기본 외형 같은 것을 없애고, 사용자 에이전트 스타일시트 위가 아니라 백지에서 스타일을 만들게 해줌
    정규화는 사용자 에이전트 스타일시트와 협력하려는 접근이고, 브라우저 간 차이를 맞추는 부분과 “더 합리적”이라고 본 기본값으로 바꾸는 부분이 섞여 있음
    요즘은 브라우저 기본값이 의미 있게 다른 경우가 많지 않아서 일반 웹 콘텐츠 작성자는 거의 무시해도 됨. 예외로 Chromium has the wrong table border-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 같은 잘못된 접근으로 이어지기 쉬움

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

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

답변달기