html 요소 id와 class 구분 : id 떡칠된 나의 html을 보면서 쓰는 글

인마헷·2023년 5월 2일
0
post-thumbnail

본 글은 (나)가 참고하기 위해 작성한 글입니다.
공부하는 과정에서 느낀 부분을 에세이처럼 정리하(려 하)고 있습니다.
하여, 제 글은 매우 주관적입니다😁
목차는 오른쪽을 참고해주세요👉👉

뭐든 그렇지만, 남들이 하는 거 볼 때나 같이 예제로 할 때는 다 아는 것 같다가도 생판 처음부터 시작하면 타자치는 법을 잊어버린 것 같다. CSS는 특히 만들어두고 뭐 하나 바꾸기 시작하면 겉잡을 수 없어지는 분야인 듯.

간단하게 자기소개 페이지 예제를 만들면서 깨달은 점은…

  • id와 class를 분명하게 사용하지 못하고 아무거나 떡칠해두었다는 점.
  • 이름 짓는 건 너무나 어려워.

id와 class는 각각 언제 사용하는 것이 좋을까?

이론적으로 id는 요소가 가질 수 있는 고유한 이름, class는 요소의 타입이자 분류하고 구분할 때 사용할 수 있는 것이라고 한다. id는 각 요소에 단 하나, 중복으로 사용할 수 없다. 고유한 식별자인 만큼, id를 통해서 참조하여 연결하게 되는 온페이지 링크와 관련하여 주의깊게 살펴볼 측면이 있다. 클래스는 요소에 여러 개 적용할 수 있으며 다른 요소에도 중복 적용할 수 있다.

그래서, ‘나는 이거 딱 한 번 쓸거니까 id로 써야지~’하고 id를 마구마구 남발하게 되면 id가 떡칠된 html과 내가 어디에 무슨 아이디를 줬는지 모르는 사태를 맞이하게 된다.

그래서 쓰임은 알겠는데…어떻게 활용하면 좋지?하는 물음은 여전히 해결되지 않는다. 일반적으로 레이아웃과 디자인을 작업하고 싶다면 class를 사용하면 되는 건가?

스택오버플로우에서는 뭐라고 하는지 보자.

"클래스는 페이지, 사이트 전체에서 여러 요소의 스타일을 일관되게 적용하려는 경우에 사용한다. 클래스는 동일한 스타일을 공유하는 요소가 두 개 이상이거나 (중략)... 또한 클래스는 시각적인 스타일 외에도 동작 스타일을 정의할 때 자주 사용된다. 예를 들어 jQuery 폼 validator 플러그인은 요소의 유효성 검사동작을 정의할 때 클래스를 많이 사용한다."

쉽게 정리하자면, class는 아이템의 타입이고 id는 아이템의 고유한 이름이다.

gpt에게도 물어봤다.

챗GPT가 생성한 설명도 결국 다른 플랫폼의 답과 비슷했다. 그러나 클래스를 사용하는 구체적인 예시를 달라고 했고, 이를 통해 클래스 활용의 특장점을 확인해볼 수 있었다. 아래 예시를 보자.

<button class="button large-button">Button 1</button>
<button class="button small-button">Button 2</button>

아래 css는 위 html에 적용할 스타일이다.

.button {
  background-color: blue;
  color: white;
  border: none;
}

.large-button {
  font-size: 24px;
}

.small-button {
  font-size: 12px;
}

버튼 태그에 일괄적으로 적용할 초기 스타일을 .button 에 넣어준다. 그리고 그 버튼이 큰 버튼인지, 작은 버튼인지 구분해주는 클래스를 또 구분해서 여러 클래스의 조합으로 재사용이 가능하게끔 css을 작성할 수 있다.

아마 나라면 class=”large-button”이라고 해두지 않았을까.

명시도 관련 문제도 있다

셀렉터에는 우선순위가 존재한다. 번역하면 가중치, 명시도라고 하는 specifity인데, 여러 스타일이 같은 요소에 적용될 때 스타일의 충돌 과정에서 그 우선순위 대로 스타일을 적용하는 것을 의미한다. 그 명시도는 inline > id > class, pseudo-class, attribute > tag(element), pseudo-element이다. 이 모든 것을 제치는 !important 키워드도 있기는 하나, 권장되지는 않는다. (명시도가 높은 셀렉터들 간의 명시도를 추가적으로 주어야 하는 경우 등, 정말 필요한 경우에만 사용하도록 함)


id와 class에 대해서 감을 익힐 때 쯤이면 "작명"이라는 또다른 난관에 봉착하게 된다. 변수 이름 짓는게 세상에서 제일 어렵…(더 나아가 커밋 메시지 작성에도 한계가 오기 시작한다)

그 작명에도 다행히 규칙이 있다.

작명에도 규칙이 있다.

가장 처음 코딩을 하기 시작한 때는 작명의 중요성을 알지 못했다. 혼자 코딩을 하기 때문이었는지, 작명의 중요성과 커밋 메시지의 중요성을 알지 못했던 것 같다. 물론 혼자 코딩하더라도 나의 무시할 수 있는 기억력을 고려했어야 하는건데…아무튼.

다양한 작명 규칙이 있다.

가장 대표적으로 찾아볼 수 있는 것이라 한다면 "Repository naming convention". 깃허브를 가입하고, 처음 프로젝트를 만들기 위해 레포지토리를 새로 생성하게 된다. 그리고 만나는 그 빈칸.
깃허브 레포지토리 생성하기 위한 작명칸

레포지토리 작명 규칙을 검색하면 의견이 여전히 그닥 통일되어있지는 않다는 것을 알 수 있다. 소문자를 사용하고, 하이픈(-)를 사용하고...이런 내용이 있는 반면에 대문자 사용하는 사람도 있고 언더바(_)를 사용하는 사람도 있다. 그래서 한참 초보인 나는 사용하는 기술 스택이 다양하지 않을 뿐더러 전부 연습들이라 내가 알기 쉬운 프로젝트 명, 혹은 강의명으로 설정하는 것이 나름의 규칙이었다.

그런데 CSS파일을 작성해나갈 때 html에서 id와 class 이름을 가지고 온다. 그리고 그제서야 내가 만들어두고도 왜 작명을 이따위로 했나 싶어진다.

아무 것도 몰랐던 처음에는(사실 지금도 습관적으로) 공백은 언더바, snake case로 작명을 주로 했었다(처음 시작한 언어가 파이썬이었기에). 특히 하이픈를 쓰는 경우 연산자로 잘못 인식할 수 있다나 뭐라나. 그래서였는지 언더바가 아닌 하이픈는 거의 나에게 금기시 되는 기호였는데 이제는 필요에 따라 이를 사용하여 작명하는 연습 중이다.
camelcase와 snakecase

작명 규칙: BEM

BEM은 block, element, modifier의 앞글자를 따서 말하는 css 작명 규칙이다. .block__element—modifier로 설명할 수 있겠다.

이렇게 작성하게 되면, 목적이나 기능, 상태, 구조를 전달할 수 있고 셀렉터의 명시도를 항상 낮은 수준(혹은 비슷하게 낮은 수준)으로 유지할 수 있다.

  • - (하이픈 한 개) : 일반적인 이름 연결
    ex) toggle-btn

  • -- (하이픈 두 개): ~의 상태
    ex) btn--success

  • __ (언더바 두 개): ~의 일부분
    ex) body__container


(내용을 더 추가해야 하지만 임시저장 글만 늘어나고 있으니 일단 퍼블리시해야지)

profile
비공개 글이 너무 많다...My code may sink, but at least I can swim🤿

0개의 댓글