카테고리 없음

실무자가 알려주는 퍼블리싱 꿀팁!! (html, css)

jaemuu 2024. 5. 5. 21:10

과거 에이전시에서 퍼블리셔, 프론트엔드 포지션으로 수년간 많은 프로젝트를 구축하고 관리 하면서  이러한 고민들이 꾸준히 머릿속에 있었는데요.

어떻게 하면 더 좋은 html, css 코드들을 짤 수 있을까?
이 컴포넌트의 마크업 구조가 이게 맞을까?
클래스 명칭은 어떤 패턴을 적용하는게  좋을까?
어떻게 하면 반복되는 작업에 있어 생산성을 높일 수 있을까?
어떻게 하면 가독성을 높혀 다른 작업자가 내 코드를 쉽게 이해할 수 있을까?
버튼들을 재사용하려 할때 border radius, background color, padding 등의 스타일요소의 변칙성 안에서 어떤 패턴을 적용해야 확장성있게 만들 수 있을까?

정해진 답이 없는 질문들...

여러 방식들을 모두 다 허용하고 에러에도 관대하며 정해진 규칙의 엄격성이 적은 html 언어의 자유로운 특성과, 방법에 있어 답이 명확하게 떨어지지 않는 코딩의 특성 상 몇몇의 이러한 문제들에 답을 내기는 쉽지 않은데요.

그러나, 방법은 있다.

하지만 좋은 코드들의 공통된 패턴, 코드 잘짜는 개발자들이 사용하는 일반적인 방식을 기준으로 하면 답은 얼추 좁혀 집니다.

태그선택자 중첩해서 사용하지 않기

❌

.card > div > div p {
    color: blue;
}

👍

.card__title {
    color: blue;
}

  • 태그 선택자를 사용한 경우 의미전달이 직관적이지 않고 무엇을 스타일링 했는지 유추할 수 없다. 최대한 nesting 되지않는게 깔끔하다.
  • 브라우저 엔진에서 해석시(선택자의 우측에서 시작) DOM의 모든 p 태를 찾고 그 부모의 모든 div를 찾고 맞는지 확인하고 그 다음.. 그 다음.. 를 찾는 알고리즘을 사용한다. 과도하게 사용하면 성능상 미세하지만 조금의 무리를 줄 수 있습니다.
  • html 파일에서  기본스타일의 태그인지 아니면 스타일을 준 태그인지 구별을 할수가 없고 예기치 않은 태그에 스타일링이 적용되는 side effect가 발생할 수 있습니다.
  • 본인도 나중에 어떤 태그에 스타일링 했는지 파악을 할 수 없다. 다른 작업자도 해석이 어려우니 협업에 좋지 않고 이는 유지 관리에 영향을 미칩니다.

클래스 네이밍에서 컨벤션을 지켜라.

❌

.menuBar {}
.menu_bar {}
.hdr {}
.tit {}
.txt {}

👍

.menu-bar {}

.menuBar 처럼 대문자를 사용하는것이 기능에 이상은 없으나 특정 상황에서는 선호되지 않습니다. 소문자를 사용하는것이 일반적입니다.

.menu_bar 에서 언더스코어 ( _ ) 를 사용하는것 보다 ( - ) 하이픈 을 사용하는것 이 선호됩니다. (reference 1. 참조)

.hdr .tit .txt 같은 본인만 이해할수 있는 축약어를 사용하지 마라. 축약어는 css 파일 용량을 줄이는데 도움을 줄지 몰라도 가독성을 해치고 다른 작업자에게 불편함을 줄 수 있습니다.

네이밍을 잘 지어라.

프로그래밍에서 제일 어려운건 이름 짓기라는 말이 있다. 하지만 bootstrap, material ui, daisy ui, chakra ui 등... 라이브러리를 참고해보면 알겠지만 자주 사용되는 컴포넌트 네이밍은 정해져있다. 일반적으로 많이 사용되는 네이밍이 답이 될수 있다. 주어진 틀 안에서 벗어나지 않기 때문에 네이밍에 대한 고민도 하다보면 없어진다.

BEM을 활용해라.

코드를 구조적이고 읽기 쉽게 하며 재사용하기 쉽게 하고 block이라는 개념으로 스코프를 주어(지역변수 처럼) 다른 스타일과의 충돌을 막는다. 또한 디자인 시스템 작업시 컴포넌트 스타일의 확장성을 돕는다.(ex- button--primary, button--outline)
장점들이 많다.
react 환경에서의  library들 react tab, react select, chakra ui 등... 많은 라이브러리들이 bem을 채택하여 사용하고 있다. 이유가 있다.

CSS property 순서 적용하기

css property들에 일관성있는 순서를 주어라.

/*position */
position : fixed;
top: 4px;
/* display and box model */
display: flex;
width: 4px;
height: 2px;
/* font, leading, color, text */
font-size: 12px;
color: red;
/* background and border */
background-color: red;
/* border-radius and box-shadow */
border-radius: 4px;
/* 기타 */

중복하지 마라(Keep it DRY)

크롬 개발자 도구 우측에 같은 클래스 혹은 css 속성값이 중복되어져서 텍스트에 줄이 그어져 있는걸 본 경우가 있을것이다. 불필요한건 없애고 최대한 중복을 허용하지 마라.

또한,
❌

.menu__title {
  color: red;
}
.menu__text {
  color: red;
}

👍

.menu__title, .menu__text {
  color: red;
}

css 에서도 그룹핑하여 중복을 피해라.

!important 를 과도하게 사용하지 마라.

!important가 필요한 경우는 극히 드물다. 과도하게 사용하게 될 경우 css의 우선순위 적용을 무시하게 되고 사용할수록 더 많은 !important 사용을 초래하며 이는 유지보수를 어렵게 만든다.

Google Html/CSS 스타일 가이드를 참조하라.

nhn도 있고 다른 국내기업의 스타일 가이드도 있지만
개인적으로는 좀 old 하다고 느껴진다. 좀 더 영향력있는 Google을 추천한다.

예를들어,
google style guide에는 이런 규칙들이 있다.

  • css 선택자로는 Id를 사용하지 않는다.
  • color code 값 은 소문자 (#ddd)로 사용한다.
  • 단위에서 0px -> 0으로 표기 한다.

등...

기본적이고 상세한 가이드를 제공한다. 참조하면 좋다.
https://google.github.io/styleguide/htmlcssguide.html

Utility class를 활용하라. (tailwind)

2021 css trend 통계에 따르면 tailwind가 개발경험(만족도)부분에서 css library 중 1등을 차지하였고 가파르게 상승하고 있다.
next js 의 기본 example template에서도 tailwind 를 default 셋팅으로 넣어주는것을 보면 확실히 세계적으로 핫하다. 사용해본 사람은 안다. 정말.. 장점이 많고 생산성을 부스팅 해준다. (물론 단점도 있다. 단점을 상쇄시키기 위해 utility class와 기존의 class를 적절히 혼합하여 사용하여야 한다. - 이 부분은 daisy ui를 참조하면 좋다)

기존의 css 방식은 변수명을 지어줘야 하고 css 파일에서 선택자로 선택해야하고 속성 타이핑 해야하고.. css파일이 커지면 폴더 구조 세워야하고..
반면에 tailwind는 그러한 절차 없이 바로 class에
스타일 속성을 atomic 하게 inline style로 직접 태그에 적용하는 방식이다.(클래스명칭 중복으로 예기치 않은 컴포넌트에 스타일 적용 되는것을 피할수  있다)
flutter도 react native도 코틀린도 스타일링에 있어 inline style로 컴포넌트에 직접 적용하는 방식이고 react 진영의 인기있는 라이브러리 chakra ui, native base, 또 styled system에서 영감을 받은 많은  라이브러리도 atomic styling 개념이 기반이 되어있다.

요즘에는 원티드 공고에도 tailwind  를 요구하는 공고가 심심치 않게 보인다.

Scss 아키텍처 구조를 세워라.

만약 scss로 순수하게 작업해야 할 경우, css 코드들이 커지면 각각 특성에 맞게 분리 시켜야한다.
공통으로 사용되는 스타일 코드, 해당 페이지에만 종속되는 일회성 코드를 나누어 관리해야 하고 이렇게 구조를 세웠을때 프로젝트 규모가 커지더라도 관리에 대한 부담이 적어진다.

https://pjmcdermott92.medium.com/the-7-1-scss-architecture-430c50b1f35a

Astro나 Gulp를 활용해라

화사에서 react를 사용하지 않고 아웃풋을 html, css, js로 나와야한다면 astro를 활용하면 좋다.
문법도 react와 상당히 유사하고 template engine을 사용할 수 있으며 컴포넌트식의 개발이 가능하며 minify, 이미지 최적화 등 많은 기능이 있다.

astro와 디자인 시스템을 활용하여 반복되는 구축작업에 본인 혹은 회사만의 template를 만들면
작업 효율성과 생산성이 많이 높아진다.

Ui Library를 사용해 보라

bootstrap, material Ui 등의 라이브러리는 디자이너에게 받은 디자인에 맞추기 좀 어려운 부분이 있다. (커스텀에 최적화되어 있지 않다. 물론 많이 개선 되었지만..) 어떠한 디자인에도 커스텀 스타일링으로 쉽게 적용할수 있도록 headless한 라이브러리들 tailwind기반 - daisy ui, flowbite, react환경에서 - chakra ui, glustack ui
..등을 사용한다면 개발이 편해질수 있다.

물론 모달, tabs 등.. 한땀한땀 시간들여 만드는게 좋긴 할수도 있지만 대부분의 회사에서는 디자인 시스템 만들 시간을 따로 주기 힘든 상황일 수 있고, 만약 직접 만들더라도 이러한 ui library를 참고한다면 퀄리티 있게 만들 수 있을것이다.
또한 직접 ui 컴포넌들을 구축한다면 다른 작업자와 협업하기 위해 문서도 작성해야 하고 에러 발생시 유지관리도 해야하며 확장성도 고려해야 하야 한다. ui library를 활용하면 시간적인 면에서나 관리의 측면에서나 유리한 부분이 있으니 고려해볼만 하다.

그게 아니더라도 이러한 라이브러리들을 경험해보고 안에 있는 오픈소스들을 까서 커스텀하고 이해하다 보면 실력이 정말 많이 늘고 시야가 넓어진다.


Reference

  1. class명칭 하이픈 (-) 사용하기 https://stackoverflow.com/questions/7560813/why-are-dashes-preferred-for-css-selectors-html-attributes
  2. css 순서 적용하기 https://markdotto.com/2011/11/29/css-property-order/
  3. Google html css style guide https://google.github.io/styleguide/htmlcssguide.html
  4. A guide to writing better css https://www.creativebloq.com/advice/a-guide-to-writing-better-css


반응형