'markup'에 해당되는 글 2

  1. 2009.07.28 디자인도 잘하고, 코딩도 잘하고 (3)
  2. 2009.07.27 효율적인 마크업 뼈대만들기 (1)
Design도 잘하고 markup도 잘 작성하는 사람이 있다면 더 없이 좋겠지만, 단점이 있다.
Design을 하면서 markup생각을 하게 된다. 아무래도 상상의 나래를 펼치는데 제약이 될 수밖에 없다. 웹디자이너도 사람인지라 디자인 할때는 디자인만, 마크업할때는 마크업만 생각할 수가 없다.

디자인하면서 "이런 레이아웃은 마크업 작성할때 까다롭거나 크로스브라우징에서 분명 문제가 생길꺼야" 라는 생각 안해 본사람이 있을까?

이건 그저 정신수양 말고 다른 방법이 없을것 같다.
아니면 내안에 다중이를 키우거나...

최근에 책에서 본건데...
그럴때는 컴퓨터 앞을 떠나서 연필을 들고, 종이에 스케치를 하라고 한다.
그런다고 markup 생각이 없어 질까만은.... 아예 효과가 없을것 같지는 않다. 
TAG markup
홈페이지를 만드는 일이 업이거나 혹은 지망할 경우 기본적인 디자인 실력은 물론 markup skill도 갖춰야 한다. 물론 국내 유수의 웹에이전시나 세분화가 잘 되어 있는 대규모의 업체라면 논외이지만, 우리나라 대부분의 기업에서는 디자인도 잘하고, 코딩도 잘하고, 기왕이면 자바스크립트 베껴쓰는 정도의 능력을 갖추면 금상첨화이고, 프로그래밍에 기본적인 지식까지 있다면 완전 사랑받는 디자이너라고 할 수 있을것 같다. (우리나라에서 웹관련 종사자들은 정말 슈퍼맨이다.)

markup도 visual design 못지 않게 창의적이고 체계적인 사고방식이 필요한것 같다. 오랜시간 블로그 관리자 화면과 블로그 스킨을 만들면서 하나의 markup이 모든 상황을 모두 커버할수 있는건 아니지만, 어느정도 업무의 효율성은 가져올 수 있다.... 라는 당연한 이론을 뼈저리게 깨닫기 까지는 참 오랜이 걸린것 같다.

사실 나도 수년전만 해도 table로 layout을 구성할 때가 있었다. 그러다가 웹표준, 접근성, 웹2.0등을 접했는데... 사람은 변화를 받아들이는데 참 인색한것 같다. 전에는 몇시간안에 끝났던 코딩이 두배, 세배의 시간이 걸리기 시작하고, 브라우저마다 출력을 달리해주는 통에 고생은 또 배가 되면서 무작정 회의적인 생각만 들었었다.

어느정도 코딩에 익숙해지고, Cross browsing을 당연하게 생각하게 되면서부터 생각이 달라지기 시작했다. 어떻게 하면 더 효율적으로 markup을 할 수 있을지 고민하기 시작했는데.... 그러면서 markup하는데 또 엄청난 시간이 들었다. 이렇게도 해보고 저렇게도 해보고... 뭔가 정답을 바랬던것 같다.

그러다가 효율적인 markup에는 정답이 없다며 포기하기 시작하니까 마음도 편해지고, 또 다른 시선이 생기기 시작했다. 그건 그냥 자신이 정답을 만들면 되는것 같다. 나름대로의 rule을 만들어 그 rule대로 일관성있게 작업을 하면 된다.

사설이 너무 길었는데...
자신만의 knowhow를 서로 공유하면 좋을것 같아서 몇가지만 얘기해보려고 한다.

1. 축약하지 말고 가능하면 변수에 모든 의미를 담아라

authorProf(△) → 틀렸다기보다는 별로 좋지 않음.
authorProfile(O)

축약하고나면 나중에 긴가민가 한다. 직관적이지 않아서 본인조차 헛갈리는 경우가 생긴다.

2. rule을 만들었으면 일관성있게 끌고나가는게 중요한것 같다.

1번의 rule에 따르면 두 단어 이상일 경우가 많다. 그럴경우 class name을 만들때 세가지정도의 방법이 있다. 분명 더 많은 rule들이 존재하겠지만, 일반적인것들만 예를 든다면,

하이픈 : content-header(O)
언더라인 : content_header(O)
카멜표기 : contentHeader(O)

작업할때마다 어떤때는 하이픈이 좋아보이고, 어떨때는 언더라인이 좋아보이지만, 사실 좋아보이는 어떤건 없는것 같다. 일단 일관성을 가지는게 중요한것 같다.

3. common한 요소와 unique한 요소를 찾아라.

효율적인 markup의 핵심인것 같다. unique와 common을 적절히 사용하면 css의 코드 수를 확실히 줄일 수 있으며, 유지보수가 쉬워진다.
예를 들어 블로그 사이드바를 만들경우 각 사이드바 요소들마다 unique한 class명을 각각 주고, 모든 사이드바 요소에 common 클래스명을 동일하게 부여하면, 해당 사이드바 요소들을 동일한 디자인으로도 표현이 가능하고, 사이드바 요소중 원하는 요소의 디자인을 달리 할 수도 있다.

<div id="notice" class="widget">공지사항 리스트 </div>
<div id="category" class="widget">카테고리</div>
.
.
.
<div id="recentPost" class="widget">최글 글 </div>
<div id="recentComment" class="widget">최근에 올라온 댓글 </div>
<div id="recentTrackback" class="widget">최근에 받은 트랙백 </div>

widget라는 공통된 클래스명을 사용하여 일괄적으로 style를 적용할 수도 있고, 각각의 unique한 요소로 각각 다른 style를 적용할 수도 있다. 이 부분은 나중에 다시 다뤄볼 기회가 있으면 좋겠다.

4. 너무 많은 case에 대한 상황을 고려하지는 말자.

이건 주의해야할점에 가까운데 당장 생기지도 않을 너무 많은 상황에 대해 고려를 하기 시작하면 markup은 나도 모르는 괴물로 변해간다. 나중에 그 markup을 봤을때 이 레이어는 왜 넣은거지? 하며 아리송해진다. 엄청난 중첩 레이어에 side effect 때문에 결국 재활용은 커녕 markup을 새로 해야할지도 모른다. 당시 상황에 맞는 최적화된 markup은 나중에 재활용하기도 쉽다.