본문으로 건너뛰기

CSS 를 잘 쓰는 방법

무료2015-06-30#CSS#Mind#Front-End#如何写好css#css技巧#css优化#前端开发技巧#模块化css#面向对象的css

프론트엔드 엔지니어가 가장 축적해야 할 지식은 무엇인가? 답은 CSS 다. 장신욱의 블로그 글 분류를 보면 알 수 있다. CSS 의 내용은 상상보다 훨씬 많다

##1.CSS 의 class 명명 원칙

camel 규칙과 중선 구분 방식의 조합 사용을 권장하며, 밑줄 사용은 권장하지 않는다. 입력이 불편하기 때문이다

camel 규칙은 서로 다른 단어를 구분하는 데 사용하고, 중선은 종속 관계를 나타내는 데 사용한다. 예를 들어:

<ul class="xxList">
  <li></li>
  <li></li>
  <li class="xxList-lastItem"></li>
</ul>

중선은 네임스페이스와 같아서 작용 범위를 한정하는 데 사용한다. 이 관점에서 보면 모듈화 CSS, 객체 지향 CSS 라고 부를 수 있을 것이다

##2.낮은 우선순위 원칙

자식 선택자, 후손 선택자의 남용을 피한다. 우선순위가 높아지고 충돌隐患도 존재한다. 스타일을 쉽게 덮어쓸 수 있도록 하려면 선택자의 우선순위를 가능한 한 낮게 유지해야 한다

스타일 변경에 직면했을 때 너무 높은 우선순위는 매우 고민스럽다. 예를 들어:

.info .infoBody .lastItem span {
    color: red;
}

이 경우 lastItem 의 특정 span 자식을 녹색으로 변경하는 것이 매우 어렵다. 대상 span 의 span 형제에 영향을 주지 않기 위해 대상 span 에 스타일을 추가하고 이 일련의 선택자를 추가해야 한다:

.info .infoBody .lastItem span.special {
    color: green;
}

그렇지 않으면 우선순위가 부족하여 red 에 덮어씌워진다. 이 경우 후손 선택자가 더 길어지는 것을 막을 방법이 없는 것 같다

네임스페이스 방식을 채택하면 훨씬 좋아진다. 예를 들어:

.info-infoBody-lastItem span {
    color: red;
}

.info-infoBody-lastItem special {
    color: green;
}

선택자를 낮은 우선순위로 유지하면 수정이 더 쉬워지므로 CSS Lint 조차 id 선택자 사용을 권장하지 않는다. 물론 id 선택자가 확장을 지원하지 않는다는 (id 는 유일함) 것도 중요한 요인이다

##3.class 명명 충돌 회피

여러 사람이 협력할 때 충돌을 최대한 피하기 위해 스타일에 접두사를 추가할 수 있다. 예를 들어:

<!-- by zhangsan -->
<ul class="zs-xxList">
    <li></li>
    <li></li>
    <li class="zs-xxList-lastItem"></li>
</ul>

<!-- by lisi -->
<ul class="ls-xxList">
    <li></li>
    <li></li>
    <li class="ls-xxList-lastItem"></li>
</ul>

##4.가독성과 너무 긴 명명

너무 긴 명명, 예를 들어"zs-dropMenu-lastItem-img"는 확실히 파일 크기를 증가시키지만, 이러한 명명이 가져오는 가독성의 이점은 텍스트 파일 크기 증가보다 훨씬 가치가 있다. 더군다나 텍스트 파일은 gzip 압축이 가능하다

##5.조합 많이 사용하기

CSS 에도 이러한 문제가 존재한다: 여러 개의 class 를 추가해야 하는가, 새로운 class 하나를 추가해야 하는가?

객체 지향 설계 원칙 중에 "상속보다 조합을 많이 사용하라"는 것이 있다. 여기서도 동일하게 적용된다. 상속은无从谈起지만. 조합의 장점은 더 유연하고 확장하기 쉽다는 것이다. 예를 들어:

.fl {
    float: left;
}
.fr {
    float: right;
}
.bdRed {
    border: 1px solid red;
}

일반적으로 이러한 원자 class 를 조합하여 스타일을 구현하는 것이 확장하기 더 쉽다 (bdGreen, w950 등을 추가할 수 있다). base 레이어와 common 레이어는 이렇게 조직되며, page 레이어 내부도 이렇게 조직할 수 있다. 이로 인한 이점은 스타일이 변경될 때 class 값만 업데이트하면 되고 특정 스타일 규칙을 수정할 필요가 없다는 것이다. 물론 어떤 경우에는 먼저 새로운 class 를 추가한 후 적용해야 한다. class 하나만 추가하는 방식을 채택하면 매번 스타일 파일에서 특정 class 를 찾아 특정 규칙을 수정해야 한다

(bdRed 와 같은 명명은 반대받을 수 있다. class 이름이 추가적인 시맨틱을 표현하고 단순히 스타일을 나타내는 것이 아니기를 바라기 때문이다. 스타일이 변경될 때 bdRed 가 실제로는 검은색 실선 테두리를 나타낼 수 있으며, 이때 시맨틱을 유지하려면 bdRed 를 bdBlack 으로 변경하고 동시에 html 도 수정해야 한다. 조합을 채택하면 이러한 문제가 존재하지 않는다. bdRed 를 수정하는 것이 아니라 bdBlack 을 새로 추가하기 때문이다)

주의: OOP 와 마찬가지로 확장성은 구체적인 상황에 따라 취사선택해야 한다. 변경이 발생할 가능성이 낮은 부분에서 조합을 채택해도 CSS 코드 길이 증가 외에는 아무 이점이 없다

##6.hook

이는가장 중요한 점으로, class 나 id 를 hook 으로 사용할 수 있다. hook 은 공중에 떠 있는 (어떤 스타일에도 대응하지 않고 선택자에도 나타나지 않는) 고리로, 나중에 무언가를 걸 수 있다. hook 은 css hook 과 js hook 으로 나뉘며 둘 다 매우 유용하다.

css hook 은 변경을 예방하기 위한 것이다. 변경이 발생할 가능성이 있는 요소에 먼저 class 를 추가하고 스타일을 적용할 필요는 없다.将来 변경이 발생하면 스타일 규칙을 채우면 된다. 사실 이는 또 다른 문제를 보여준다:应有的한 태그를 생��하지 마라. 더 적은 태그는 확장하기 어렵다는 것을 의미한다. 예를 들어:

<h2>2 단계 제목<span class="btn">펼치기/접기</span></h2>

스타일 변경으로 2 단계 제목에 밑줄이 필요해지면"2 단계 제목"을 inline 태그로 감싼 후 스타일을 추가해야 한다. 수직 중앙 정렬 등도 영향을 받을 수 있다. 처음부터"2 단계 제목"을 태그로 감싸두면 당황하지 않아도 된다. 물론 css hook 을一堆 추가할 필요도 없다. 어떤 곳은 확실히 스타일 변경이 발생할 가능성이 적기 때문에 낭비와 절약 사이에는 정도 존재한다

js hook 은 js 에 제공하는 단서로 스타일 조작을 용이하게 한다. 일반적으로 id 를 js hook 으로 사용한다. 네이티브getElementById가 가장 효율이 높기 때문이다. 직접 요소를 찾을 수 없더라도 검색 범위를 좁히는 데 사용할 수 있다. 마찬가지로 class 를 js hook 으로 사용해도 요소 검색 효율을 높이고 비효율적인 오른쪽에서 왼쪽으로의 후손 선택자 스캔による 요소 검색을 피할 수 있다

참고 자료

  • 《고품질 코드 작성법-Web 프론트엔드 개발 수련의 길》

댓글

아직 댓글이 없습니다

댓글 작성