메뉴 보이기
Profile
이온디

2013.03.01

CSS

What Makes For a Semantic Class Name?

조회 수 3799 추천 수 0

What Makes For a Semantic Class Name?

- 구조와 의미를 담은 클래스명


클래스 네이밍. 과연 어떻게 하는 것이 효율적이고 옳은 것일까요. 제 기본 의견은 다음과 비슷합니다. 

http://css-tricks.com/semantic-class-names/#comment-102547 

그리고 이것은 부트스트랩의 구현 방식과도 비슷합니다. 

http://twitter.github.com/bootstrap 

디자인이나 액션 제어용 클래스는 사용해서는 안된다는 분들께 질문드립니다. 

태그가 시멘틱해야 하는 것인지, 클래스 네이밍이 시멘틱해야 하는것일까요.

그리고 스크립트는 어떻게 제어하고, 반복되는 디자인이 있을 때는 어떤식으로 관리하는가요.


HTML에서 '시멘틱'은 언제나 중요한 화제입니다. 어떤 사람들은 항상 그 것을 위해 노력하고 있습니다. 또 어떤 사람들은 시멘틱에 대한 독단적인 집착을 비판하기도 합니다.

어떤 사람들은 그게 뭔지 신경 쓰지도 않습니다.


시멘틱의 나쁜 예)

<div class="article">

  <div class="article_title">Smurf Movie Kinda Sucks</div>

  <div class="the_content">Not surprisingly, this weeks release of

     <div class="darkbold">The Smurfs</div> kinda sucks.</div>

</div>

시멘틱의 좋은 예)

<article>

  <h1>Smurf Movie Kinda Sucks</h1>

  <p>Not surprisingly, this weeks release of

     <b>The Smurfs</b> kinda sucks.</p>

</article>

시멘틱 태그를 div로 나타낼 수도 있습니다. 하지만 시멘틱 웹은 그 역할을 기계적으로도 잘 사용하자는 뜻이니깐 HTML5의 시멘틱 태그를 적절하게 활용하자는 것입니다.

  • 2012/09/12 12:15

    국내사이트에서 네이밍에 관련된 부분에 자료는 네이버쪽에 널리에 가시면 네이버에서 네이밍으로 태그의 명은 어떻게 시작하며, 스크립트 함수명에 관련된 자료를 본 적 있습니다. 그걸 보시면 좀 도움이 되지 않을까 생각합니다.. 누구나 봐도 앞에 이거니까 이건 뭐에 관련된 내용이겠다라는걸 명시하는 그런 걸로 기억납니다.

  • 2012/09/12 12:18

    말씀하신 자료는 다 보았습니다만.. 
    얘기 나눠보고자 하는바는 그에 관한 내용은 아닙니다.
    그리고 네이버라고 완벽한것은 아니니까요 -_-a

  • 2012/09/12 12:23

    쫄깃한가지 클래스 네이밍이야기라면 네이밍 이야기가 나올 내용이죠. 네이버에 예를 든건 적어도 네이버 모든 페이지에서 네이밍에 규칙이 있다는 점이죠.. id도 네이밍의 규칙을 넣을 수 있고 name도 class도 가질 수 있다고 생각합니다. 스크립트는 간결하고, 알기 쉽게가 목표로 여겨 지고, 이건 만드는 사람이 최적으로 고민하고, 함수로 따로 빼고 하는 작업이 필요하겠지요. 태그 역시 내용에 맞는걸 써야 시멘틱이라고 불리지 않을까 생각됩니다.

  • 2012/09/12 12:37

    테일즈 옳으신 말씀입니다. 그에 더해 많은 분들과 얘기나누고 싶은 주제는 디자인/액션 제어용 클래스 사용에 대한 내용입니다~

  • 2012/09/12 12:49

    제가 그동안 해온 작업에 비추어보면 디자인용(표현)관련은 CLASS를 사용하고 기능구현은 ID를 사용합니다. 부득이하게 클래스관련하여 기능구현을 할때 다중클래스로 적용하여 사용하고 있습니다. 이때 다중클래스 네이밍도 기능구현에 맞는 직관적인 네이밍을 사용하도록 하고있습니다.

    어떤 소스를 보면 다중클래스를 무분별하게 남발하는 부분이있는데 그리 선호하진않지만 최초 구축시에는 다중클래스를 자제하되 향후 오픈후에 유지보수를 위하여 pt10,mt10 이런 여백이나 간단한 표현템플릿으로 정의하여 쓰고 있습니다.


    테일즈님의 말씀대로 네이버에 코딩컨벤션을 보면 정리가 잘되어있고 규칙이 있어 저도 참고용으로 자주 봤던 기억이있네요~!! 

    다른님들은 어떻게 작업하시는지 궁금하네요~!!

  • 2012/09/12 12:52

    뭐든 문제는 모아니면 도다는 식의 흑백논리에서 시작된다고 봅니다....
    무조건 사용해서는 안된다가 아니라 가급적 디자인/액션제어만을 위한 클래스 사용은 자제하는게 좋다는게 제 의견입니다.
    http://hyeonseok.com/soojung/css/2007/11/28/418.html 글을 참고하시면 될듯 합니다.
    "셀렉터가 모든 것을 말해줄수 있게 작성된 코드가 가장 좋은 코드라고 생각합니다."에 저는 전적으로 동의하는 바입니다.

  • 2012/09/12 12:58

    동감입니다. 한줄이 모든걸 말해주네요

  • 2012/09/12 13:03

    저도 동의합니다.
    다만 '구조와 표현의 분리'를 이야기하며 'blue'나 'clr' 등의 클래스가 구조가 아닌 표현을 나타낸다고 꺼려하기도 하는데, 그럴 필요까지는 없다는 입장입니다. 셀렉터가 이야기해주는 대상은 사용자가 아니라 개발자이기 때문에..

  • 2012/09/12 13:07

    저도 동의하는 바입니다. 공감!!

  • 2012/09/12 13:13

    쫄깃한가지 음.. 
    셀렉터가 이야기해주는 대상은 사용자가 아니라 개발자이기 때문에.. 'blue'나 'clr' 를 써도 무방하다에는 동의하기 어려운데요 ^^;;;;

    class로 blue, clr 등을 줄바에는 현석님 말처럼 그냥 인라인으로 쓰고말지요...
    "표현의 분리"와 "글자수 줄이기 위한 클래스 처리" 는 동일하게 놓고 보기는 어렵다고 봐요

  • 2012/09/12 13:16

    멀더끙 아.. 단순하게 글자수 줄이기는 아니구요, 부트스트랩의 버튼 구현방식 같은거요.
    http://twitter.github.com/bootstrap/base-css.html#buttons

  • 2012/09/12 13:20

    쫄깃한가지 부트스트랩의 버튼 구현에 있어 클래스 네이밍은
    "blue", "clr" 같은 것과는 다르죠 ^^;;;

    부트스트랩의 클래스 네이밍을 뜯어보면 (버튼에 대해서만 말씀드려서)
    btn-* 식으로 접미사를 붙여서 사용합니다.
    누가봐도 버튼형태를 나타내는 클래스임을 알 수 있고,
    btn-primary, btn-info 등 뒤에 붙은 접미사를 통해서 
    더 구체적으로 primary 버튼이고 info 버튼이다 라는 것을 알 수가 있죠.

    이는 의미론적 클래스네이밍이라 볼 수 있습니다.

  • 2012/09/12 13:24

    멀더끙 부트스트랩을 더 보자면.. 테이블 등에서 .table-striped, .table-bordered를 사용하면서 구조보다는 표현을 나타낸 클래스명을 살펴볼수 있죠. (뭐 버튼도 .btn-large 이런게 있는지라.. )
    결국 컴포넌트 형태로 활용을 하려면 문서 구조상에서의 의미보다는 그 요소 자체의 역할(의미) 또는 형태를 나타내는 클래스명은 필연적이지 않나합니다.

  • 2012/09/12 12:57

    추가로 말씀드리자면 반복되는 디자인이 있을시에 유형별로 css를 미리정의하여 공통적용하여 사용하고 있습니다.
    작업시 이런경우가 빈번하게 생기므로 사전셋팅 작업시 구축사이트에 대하여 충분히 분석하여 공통 유형css를 정의하면 향후 작업이 편합니다. 마크업이나 스타일도 이런 자기만의 분석과 기획이 필요하다고 개인적으로 생각하네요~^^

  • 2012/09/12 13:05

    좋은 말씀 고맙습니다 ;)
    결구 반복되는 디자인등은 공통 컴포넌트로 사용하게 되는데, 이때는 시멘틱하게 짓는다고 지은 네이밍이 전혀 엉뚱하게 되는 경우가 있어서 퍼블릭한 네이밍을 사용하게 되고, 그렇게 되면 필연적으로 페이지 내의 다른 요소들과 결합도가 떨어지게 되는데요, 저는 그부분은 큰 문제가 되지 않는다는 입장입니다.

  • 2012/09/12 13:07

    혹시 <a href="#" class="btn small blue">링크</a> 같은 사용에 알레르기가 있는분들이 있다면 의견 듣고 싶습니다.

  • 2012/09/12 13:11

    저요// 손 번쩍!!! ㅠㅠ)/
    제가 보는 소스에는 이런게 많네요...orz
    <span class="height_line_short"></span>

    네이밍은 정말 중요하다고 생각해요~!
    접근성 작업할 때 네이밍 관련해서 참고해 보았던 사이트가 있는데 우리은행 GUI였어요.
    파일, 클래스, 아이디 네이밍도 규칙을 갖고 정의해 두었더라구요.
    개인적으로 참 잘 정리되어 있어서 좋았어요.
    의미를 담은 네이밍! 멋졌습니다~!

  • 2012/09/12 13:12

    btn 까지는 있을 수 있다지만.. small 과 blue 클래스가 반복 횟수가 적다고 보면 너무 css를 많이 쪼개서 css의 클래스가 그냥 무의미하게 늘어나는 경우만 아니면 괜찮지 않나 싶습니다 단.. 좀더 세밀하게 쓸 필요는 있다고 보여집니다.

  • 2012/09/12 13:12

    로에 혹시 빈태그 사용 말씀이신가요? +_+: 그부분도 궁금하네요.
    빈태그, 쓰면 안되나?? 실질적으로 ie7이하에서 ::before, ::after등이 지원되지 않는 현 시점에서, 저는 스프라이트된 아이콘등을 삽입할 때 빈태그에 스타일을 입혀서 사용하는데요. (백그라운드와 패딩값으로 처리하면 스프라이트를 사용할수 없기때문에..)
    이에 반박하는 분들도 계실텐데 빈태그를 사용하면 안되는 이유에 대해 들어보고 싶습니다..

  • 2012/09/12 13:14

    네이밍은 직관적이면 안된다고 배웠어요.
    여전히 네이밍은 할때마다 고민되는 부분입니다...
    의미없는 네이밍 역시 안되구요~ 간과하고 지나갈 수도 있는 부분이지만...
    시멘틱 마크업에 있어서도 연관성이 있다고 봅니다.

  • 2012/09/12 13:16

    쫄깃한가지 쫄깃한가지님의 말씀에는 웹문서를 그냥 "뷰"형태로만 본다는 의미가 기저에 깔려 있지 않나 싶습니다. 단순히 "뷰"의 형태로만 본다면 의미없는 클래스 네이밍이나 빈태그 사용에는 문제가 없다고 볼 수 있습니다.

    하지만, 시멘틱한 웹 이라는 것이 나타난데에는 "구조"라는 것 때문이며 HTML을 "문서" 더 구체적으로 말하면 "구조적 문서" 이기 때문인데요

    "뷰"의 형태로만 생각한다면 "구조"와 "표현"의 분리 자체가 의미 없는 일이 됩니다.

  • 2012/09/12 13:17

    쫄깃한가지 저도 그 부분은 참 궁금한데 의미가 없는 부분은 빈태그도 괜찮지 않나요~?
    구조에 의미있는걸 빈태그로 사용한다면 문제가 있겠지만요~
    저도 예전에 ie 하위버전을 고려할 때 작업은 따로 클래스를 만들어서 작업했던걸로 기억합니다.

    제가 작업한건 아니지만 여기 소스에는 대부분이 빈태그인데 공백기호 조차 빠져 있네요 ㅠㅠ...

  • 2012/09/12 13:28

    멀더끙 꿰뚫어 보시는거 같아서 부끄럽습니다^^;
    저는 클래스는 뷰를 꾸미는 용도로 사용해야 된다는 생각입니다. 
    시멘틱한 웹은 적절한 태그(header, aside 등)와 속성(role="navigation" 등)으로 이루어야 한다고 생각하구요. 사실 저런 태그나 속성도 그 스스로의 역할에 집중할 뿐이지 문서전체에서 해당 영역의 의미를 표현하고 있지는 않죠. 클래스명을 통해 문서내에서 해당영역의 의미를 알고싶은건 개발자와 검색엔진정도가 아닐까요. id를 시멘틱하게 짓는건 그래도 이해가 가는데.. 클래스까지 강제하는게 과연 옳은것일까? 하고 생각하고 있습니다

  • 2012/09/12 13:40

    로에 아, 갑자기 떠오른건데, 저는 빈태그 쓸때 귀여운(?) 규칙이 있습니다. 아이콘을 나타내기 위한 빈태그에는 'i'태그를 사용합니다ㅋ
    b, i등의 태그는 html5에서도 여전히 유효한 태그입니다. 간단한 단어의 강조의 의미로 사용되지만, 태그에 내용이 없다면 뭐 그 내용을 읽지 않을 것이고.. 내부에 별다른 엘리먼트가 없으니 과도한 중첩구조로 인한 사이드 이펙이나 접근성 등에도 문제가 없을 것이라고 생각하고 있습니다.

  • 2012/09/12 13:44

    쫄깃한가지 지극히 개인적인 사견입니다만, 아마 많은 분들이 동의할 수 없다 할지도 모르는 의견입니다만..

    "태그나 속성은 스스로의 역할에 집중할 뿐, 해당 영역의 의미를 표현하지 않는다" 라는 말은
    W3C 표준 권고안을 철저히 무시하는 말이라고 생각합니다.

    가령, table 의 경우, summary 속성으로 이 표 요소가 어떤 내용을 담고 있는지를 요약해 주고, 이 정보를 브라우저 혹은 단말기에 전달해줍니다.
    <p> 태그는 하나의 문장이다라는 의미를 전달해주고 이 문장에는 어떤 내용이 담겨있음을 알려줍니다.

    시멘틱은 "용도에 맞는" 이아니라 "의미론적인" 이 맞습니다. 사전적 의미도 그렇구요.

    앞서 "뷰"형태로 보시는것 같다 말씀을 드렸는데, HTML 을 브라우저가 뷰어요, HTML 자체는 뷰어에 뿌릴 "뷰"다 라 한다면 쪼깃한 가지님의 말씀이 크게 문제되지 않습니다.

    하지만, HTML은 "문서"로 인식이 되고, 앞으로 더욱 문서 구조로 나아가고 있습니다.
    HTML -> xHTML -> HTML5 가 그 증거라고 할수가 있죠.
    다만, 종이에 쓰이는 그런 문서가 아니라, 웹브라우저라에 띄워서 보는 멀티미디어 문서인거죠.

  • 2012/09/12 13:45

    쫄깃한가지 시멘틱은 문서 구조이기 때문에 나타난 용어 입니다.
    단순 "뷰"에 그친다면 시멘틱은 사실상 그다지 필요하지 앟은 개념이라고 할 수 있습니다.

  • 2012/09/12 13:47

    쫄깃한가지 아?! 듣고보니 그렇네요~! 어차피 HTML5에서는 시각적인 표현의 의미를 갖고 있으니 괜찮은 방법인듯 한데...음;;; 멀더끙님 말씀 들어보니 다시 한번 고민해봐야 되겠어요~

  • 2012/09/12 13:52

    멀더끙 아 제가 말씀드린건 태그나 속성 자체의 '네이밍'에 대한 것입니다^^; 말씀드린 예에서 보면 summary 태그만 보면 '테이블의 내용을 요약해 준다'라는 의미를 도출할 수 있지만 'summary'라는 태그이름만을 통해서 '**채소가게 상품 가격표의 테이블**에 대한 내용을 요약해준다'라는 개별 문서 자체의 구조를 표현하고 있지 않다는 겁니다. 이 예가 적절한건지 자신은 없습니다만..

    다시 강조를 하자면, '시멘틱한 웹은 적절한 태그(header, aside 등)와 속성(role="navigation" 등)으로 이루어야 한다고 생각'합니다. 
    html->단순뷰가 아니라 className->뷰 제어용이라는거고,
    html->구조화된 문서라는 의견에 동의합니다.

  • 2012/09/12 13:15

    mt10이딴 코드는 나중에 디자인바뀌면 어쩌려고 그렇게 쓰는건가요? 그럼 jsp를 열어줘야되는데요 css에 덕지덕지 쫘르르 넣어놓고

  • 2012/09/12 13:18

    사실 mt10은 극단적인 케이스고,
    <div class="box"></div>
    <div class="box center"></div>
    <div class="box"></div>

    이런식으로 클래스를 줘서 .center의 css를 변경하는거죠. 아 mt10 이거 예를 좀 수정해야겠네요

  • 2012/09/12 13:17

    음.. 저는 pt10 mb10 이런식의 네이밍을 좋아 하지 않아 안쓰려고 합니다.

    하지만, 디자이너분들이 매 페이지 마다 다르게 주는 경우가 많아 사용하게 되는 경우가 많았죠. 

    그런데 이승일님, 신현석님, 멀더끙님의 글을 보고 나서 네이밍에 대해 다시 한번 생각하게 되었네요..

    의미에 맞는 네이밍이 결국 유지보수나 css의 특징을 살린 방법 같습니다. 

    하지만 현실적인 문제도 있고.. 저는 멀더끙님의 말씀처럼 자제하는 쪽으로 결론을 내고 싶네요..

  • 2012/09/12 13:18

    아 저만 고민하는게 아니엇군여 영단어마니 안다고 좋은게 아닌거 같네요 ㅋㅋㅋㅋ 한페이지에 div 분할이 많아지면 은근 네이밍이 후달린다는 ㅋㅋㅋ

  • 2012/09/12 13:20

    mt10 같이 정확한 포인트 값이나 css속성을 나타내는 클래스 말고,
    type2, fst, bottom등 유연한 네이밍을 줘서 따로 css를 제어하면 좀 해소가 될까요?
    하지만 저 네이밍들도 '표현'에 대한 클래스이기때문에 반박할 분들이 있을꺼 같은데요.. 어떤가요?

  • 2012/09/12 13:26

    이상적으로는 의미론적인 클래스를 만들어서 사용을 하면 참 좋습니다.

    그런데 같은 테이블 요소에 대해서 css 가 줄이고 줄이고 해서 30줄짜리 table.tbl 이라는 클래스가 있다고 칩시다.

    그런데 A, B라는 테이블이 있고
    table.tbl 이라는 css 를 공통적으로 사용을 할수 있는데 top margin 이 20px, 30px 의 차이로 인해서 table.tbl 을 table.tbl1, table.tbl2 라는 css를 두가지로 만드는것이 좋은것인지,

    흔히들 많이 쓰는 mt10 이라는 클래스를 만들어서 table.tbl 에 mt20 mt30을 따로 추가해서 사용하는것이 좋은지 

    둘중에 어떤 방법을 사용하시겠습니까??

  • 2012/09/12 13:28

    인라인으로 넣거나.. 이 테이블이 다른곳에서 또 사용 될 수 있다면.. 하나 더 만들거 같네요^^;

  • 2012/09/12 13:29

    왜... 그걸 꼭 margin-top:20px, margin-top:30px 을 각각 클래스화 해야 한다고 생각하시는지요.....?
    CSS Selector 가 괜히 잇는게 아닌데요 .... ;;;

  • 2012/09/12 13:30

    멀더끙 구버전 브라우저 호환성 때문에.. 어쩔수 없는 케이스가 생깁니다. ::before를 못써서 빈태그를 쓰게 되는것도 구버전 브라우저때문에;;

  • 2012/09/12 13:33

    멀더끙 이런 상황에서는 css selector를 어떻게 처리해줘야 하는지요??

  • 2012/09/12 13:34

    아쭈 상위에서 다른 클래스를 타고 내려온다거나.. 
    .tbl {margin-top:10px;}
    .another-style .tbl {margin-top:5px;}

    한 공간에 병렬로 나열되있다면 :first-child, nth-child 등의 방법이 있을것 같네요~

  • 2012/09/12 13:38

    쫄깃한가지 뭐 이런저런 상황에서 쓰일수도있고 분명 앞페이지에서는 이런 마진을 가지고있었는데 지금 페이지에서는 다른 마진을 가지고 있다. 

    그러다보면 부득이하게 위의 상황을 경험하게 될수도있습니다.

    그리고 nth, last - child는 하위브라우저에서는 지원을 안하고있는걸로 알고있습니다. 그러니 저런 방법을 부득이하게 쓸수도있는거고요

  • 2012/09/12 13:40

    아쭈 맞는 말씀입니다 ;)

  • 2012/09/12 13:42

    아쭈 저도 이런 경우엔 고민이 됐었는데 상황에 따라서 대게 클래스를 따로 하나 더 만들어 주는 편입니다. 
    현재는 css3 선택자를 자유롭게 쓸 수 있어서 좋지만 웹에서는 ie 하위버전...orz

  • 2012/09/12 14:23

    아쭈 이야기를 이상하게 하시는데요..
    멀더님 말씀의 요점은 이겁니다.
    <table class="tbl mb30">
    </table>

    이렇게 쓸바엔 차다리...

    <table class="tbl" style="margin-bottom:30px">
    </table>

    요런식으로 쓰라는거죠.
    갑자기 왜 nth-child같은 샐랙터가 여기서 왜 나오는건지...

  • 2012/09/12 14:24

    아쭈 그리고 nth,last,first 자식 선택자가 CSS3속성이여서 구브라우저에선 지원안하는건 아는데....
    제이쿼리는 폼으로 있는게 아닙니다. -_-;;;
    그렇게 생각하는거 자채가 기술력의 부재입니다.

  • 2012/09/12 14:32

    아쭈 그럼 또 여기다가 덤으로 해서 "제이쿼리가 지원 안하면 어떻게 할꺼냐"라는 멘트를 달까봐 더 쓰자면..
    제이쿼리가 지원안하면 자바스크립트를 쓰면 됩니다. 자바스크트립트의 기본기를 이용하면 홀짝 테이블 같은건 일도 아닙니다.
    기술적인 측면가지고 물고 늘어지면 한도 끝도 없고 여기 하코사에 고수분들 많습니다.
    제일 중요한건 그 기술을 어떻게 옳바르게 사용하냐입니다.
    구차하게 mt30,pt20같은거 따로 안줘도 해결방법은 얼마든지 있습니다.

    ps. 전 현재 DOM스크립트 유저입니다.

  • 2012/09/12 14:41

    이승일 안그래도 클라이언트 성능이 안좋은 구버전 브라우저에서 스크립트를 사용한 과도한 돔탐색과 제어는 치명적인 성능이슈를 일으킬 수 있습니다.. 몰라서 안쓰는게 아니죠.

    그리고 멀더님은 셀렉터를 말씀하신게 맞는듯 한데요;

  • 2012/09/12 15:09

    쫄깃한가지 겨우 스크립트 홀짝 CSS적용이 과다하다는 측에 속한다고 보지 않습니다.
    이세상에 과도하고 말도안되는 스크립트가 얼마나 많은데요..
    그리고 저거 제이쿼리나 스크립트로 짜는데 몇줄 안됩니다.
    그리고 UI를 살짝살짝 조작해주는 스크립트 가지고 성능이슈를 논하는것 역시 오바인거 같습니다.
    이게 무슨 객체지향 프로그래밍에서 메모리 관련 퍼포먼스 내는 작업도 아닌데 말이죠.
    그냥 아주 기초적인 자바스크립트 살짝 하는겁니다. -_-;;;
    이상한 방향으로 자꾸 이야기를 끌고가려고 하시는거 같은데 그냥 몰라서 못쓰는게 맞다고 봅니다.

  • 2012/09/12 15:09

    이승일 뭐.. 말씀하신 케이스도 섭섭치않게(?) 많은게 사실이긴 합니다;;

    사실 그런건 그냥 제이쿼리로 하라는 의견에 동의합니다-_-a
    전에 있던곳이 클라이언트단 성능에 굉장히 민감하게 굴던 곳이었던지라..
    자잘한 성능이슈를 따지고 들면 이제까지 제가 한 얘기들이 다 모순이 되버리겠네요ㅎ반성합니다..

  • 2012/09/12 15:12

    쫄깃한가지 쫄깃한가지님께서 그렇게 말씀하시니...
    저도 좀 여태껏 격하게 말한감이 없지 않나 싶습니다.
    저도 죄송합니다.

  • 2012/09/12 15:12

    이승일 이런 것까지 일일히 적는것 조차 참 웃기기는 한건데

    오늘 뭔가 자신이 생각하는 재미진 것에 대하나 열띤 토론의 장이 열어져서 말을 이어나가는건 좋아보입니다.

    그런데 그게 도를 넘어가면 안되는거죠.

    뭔가 내글에 반박을 할려며는 누구한테 글을 쓴것인지 제대로 확인하고 답글을 달았으면 좋겠군요.

    그리고 셀렉터를 처음 꺼낸건 내가 아닙니다.

    그리고 밑에 스크립트얘기를 하던데 클래스 얘기하다가 스크립트까지 끌어들이는건 무슨 이유인지요. 폼으로 있는게 아니라는건 여기 하코사 들어오는 반수이상의 사람들이라면 다들 알고있는 겁니다.

    기술력의 부재라고요? 승일님이 얼마나 실력이 뛰어나고 잘나갈지는 모르겠지만 회사가 아닌 다른곳에서 누군가를 판단하고 결론을 내린다는건 참으로 오만하다는 것만은 알아뒀으면 좋겠군요.

  • 2012/09/12 16:33

    저는 이런 경우 디자이너에게 같은 스타일인데 왜 여백이 다른지 물어봅니다. 디자이너가 둘간의 차이를 의미적으로 잘 설명해주면 그 의미에 맞는 클래스를 하나 만들면 되겠죠.

    그런데 이런 경우도 있습니다. 특별한 의미가 있는 것이 아니라 그냥 그 페이지의 느낌상 여백이 조금 변경되어야 하는 경우요. 이럴때는 디자인 의도가 페이지 기준으로 변경되었기 때문에 이를 사용합니다.

    table.tbl {
    ...
    margin: 15px 20px;
    }

    ...

    #about table.tbl {
    margin: 25px 20px 15px;
    }

    이러면 table.tbl이라는 테이블 스타일이 있는데, #about 페이지에서만 예외적으로 적용했구나 라는 의도를 CSS만 보고 파악할 수 있습니다.

    물론 모든 페이지의 여백이 다를 경우가 있습니다. 보통 신입 디자이너가 스타일 가이드 없이 일 할 때죠. 그럴때는 WSG를 정해야 CSS가 작업이 가능하다는 것을 말해주고 디자이너 스스로 콘텐츠간의 관계를 분석해서 여백에 의미를 부여할 수 있게 도와줘야 합니다.

  • 2012/09/12 13:29

    토론의 주제와는 좀 어긋난 감이 있지만 어제 제글에 달린 댓글들에 대한 제 개인적인 의견을 정리한 글을 따로 게시하였습니다;;;;

    오래간만에 수다방이 후끈 달아올랐네요.^^ 뭔가 열정적이고 댓글들을 읽으면서 저도 지식이 늘어나는것 같아 기분좋습니다.

  • 2012/09/12 13:31

    저도 단순히 스타일을 축약한 클래스는 피하는 편입니다.

    하지만 스타일을 축약한 클래스가 운영면이나 유지보수면에 좋은 경우도 있습니다. 그런 경우에 한해서만 사용합니다.

    예를 들어서 css로 만들어진 버튼이 있는데, 색상케이스나 사이즈의 기준이 다양하다고 할 경우, 아래와 같이 사용합니다.

    <span class="btn_w145 btn_p"><a href="#">다운로드</a></span>
    <span class="btn_w145 btn_w"><a href="#">다운로드</a></span>

    <span class="btn_s btn_p"><a href="#">다운로드</a></span>
    <span class="btn_s btn_w"><a href="#">다운로드</a></span>

  • 2012/09/12 14:22

    메인, 로그인, 회원가입... 같은 개발 페이지는 유지보수시에 html 페이지의 수정이 힘들기 때문에 클래스명이 많아져도 되도록 모든 요소를 의미있게 네이밍 작성하고

    대량의 컨텐츠 페이지는 유지보수시에도 html 페이지의 접근이 쉽기 때문에 [켄텐츠가이드] 를 되도록 다이어트 시켜서 단순화하고 예외 상황에서는 융통성있게 mgt, mgl 등을 사용하고 있습니당.

    mgt를 쓰면 된다/안된다 의 흑백논리가 아니라 작성할 html 페이지의 컨텐츠 유형을 파악해서 작성/유지보수를 고려한 최적의 패턴으로 css를 작성하는게 퍼블리셔의 임무가 아닌가 하네영 ㅋ

  • 2012/09/12 14:36

    넵 공감합니다. 기본적인 가이드를 작성하여 작업하는게 현명하다고 생각되어지네요~!!

  • 2012/09/12 14:38

    좋은생각이네요
    저도 참고해서 가이드 삼아야겠어요~!

  • 2012/09/12 14:39

    명쾌하네영ㅋ

  • 2012/09/12 14:34

    제가 회사에서 작업도중 다른데서 개발한소스를 수정하고있는데요
    최고 5개까지 썼더군요..ㅡ_ㅡ
    <section class='player-parameter mt10 ml5 mr5'></section>

    다중클래스가 너무많이 쓰이는데 개인적으로 지저분한건 싫어서 다중클래스및 인라인은 좀 기피하고 있는데 다중클래스에 대한 의견은 어떠신지 궁금합니다.

  • 2012/09/12 14:39

    다중클래스는 딱 부트스트랩정도 활용도가 좋다고 생각합니다.

    .기본형태.(모양|색상|여백)변경2,3개

    이런식으로 가이드를 잡아놓으면 가독성에 문제가 크지 않을듯 하네요.
    위에 댓글에 잠깐 언급했지만 css속성명이나 값이 들어간 클래스는 안좋다고 생각하구요, 
    저라면 저런 상황에
    .player-parameter {...}
    .player-parameter.extra-margin {margin-top:10;margin-left:5px;margin-right:5px;}
    이런식으로 사용할 것 같네요.

  • 2012/09/12 14:44

    쫄깃한가지 네 쫄깃님 말씀대로 하면 크게 문제될것은 없을듯 보입니다.
    의견에 감사합니다.

    문제는 지금 저런소스를 보고 수정하고 있자니..속터져서..ㅋㅋ

    이런 좋은의견들이 더 많아졌으면 좋겠네요~!! 많이 배우고 갑니다.

  • 2012/09/13 18:55

    css 네이밍은 어자피 개발자들이나 본다치지만 사용자 브라우저 상단 URL 에 떡하니 뜨는 파일네이밍이 더 고민되지않나여.. 앞단 기획이나 디자이너가 스토리보드 화면설명이나 파일네이밍을 모두 한글로해놔버리고 넘겨버리면 ui개발자는 영문으로 네이밍 해줘서 개발에 넘겨야되지않습니까 ㅠㅠ

  • 2012/09/13 23:35

    영어사전을 끼고..-,-ㅋ 사실 최종 배포파일과 마크업파일이 다를경우 네이밍은 큰 문제는 안되지 않나요?
    (프로그래머에게 떠넘기기 -_-;==3)

Profile
7
Lv
이온디

이온디 홈페이지는 간결하며,

 손쉽게 수정할 수 있습니다.

0개의 댓글

에디터
번호 제목 글쓴이 날짜 조회 수
공지 [사이트 전반] CSS 및 이미지 네이밍에 관심있으신 분은 같이 참여해주세요. :) 이온디 2009.01.22 8332
13 [CSS] Get BEM profile 이온디 2018.12.01 17
12 [CSS] What’s in a name? A CSS naming convention overview profile 이온디 2018.12.01 35
11 [CSS] #tnb (Top Navigation Bar) 1 profile 이온디 2015.04.27 628
[CSS] What Makes For a Semantic Class Name? profile 이온디 2013.03.01 3799
9 [CSS] 레이아웃 네이밍 가이드 6 profile 이온디 2012.01.19 5898
8 [사이트 전반] HTML 마크업 설계 템플릿(한혜진) 이온디 2010.11.03 7584
7 SideNavigationBar (x) 이온디 2009.02.21 5479
6 [CSS] NHN Naming Guidelines (추천) profile 이온디 2009.01.20 6281
5 NHN UI(html, css) 하드코딩 기본룰 이온디 2009.01.20 6929
4 css 네이밍 규칙 7 이온디 2009.01.20 11802
3 [CSS] 모든 디자이너가 해야할 9가지 CSS 원칙 (추천) profile 이온디 2009.01.19 6870
2 CSS 네이밍 이온디 2009.01.14 5612
1 웹 개발자를 위한 네이밍 룰(Naming Rule) 가이드 (최현진, 2002년) 이온디 2003.11.14 9395