Harugun F

지금까지 수많은 디지털 폰트가 개발되어 우리 생활속 다양한 곳에서 활용되고 있음에도 불구하고 정작 어떤 글꼴(서체)또는 폰트가 어느 회사에서 어떻게 만들어 졌으며 어떤 의미를 담고 있는지 잘 모르고 있는게 사실이다.

물론 굳이 폰트를 제작한 회사 또는 폰트 제작관련 일화나 폰트가 담고 있는 의미까지 굳이 일반인들이 알고 있어야 할 이유가 없다. 그러나 디자이너나 타이포그래피를 연구하는 경우라면 상황이 많이 달라진다. 때때로 후배 디자이너들이 "이 폰트이름이 뭔가요?"나 "브로슈어 디자인 작업을 하는데 어떤 스타일 폰트를 적용하면 좋을까요?"하고 물어올 때는 디자이너라면 어느정도 인지하고 있어야 할 사항임에도 불구하고 전공분야에 대한 관심이 부족한 듯 하여 대략난감 하면서도 답답한 마음이 앞설 때가 많다.

평소에 최소한 어느 회사에서 어떤 폰트를 제작했고, 용도별로 정리해 둔 자료들을 참고할 수 있었다면 좀 더 편하고 빠르게 디자인 컨셉을 정할 수 있지 않았나 하는 생각에 말이다. 유능한 디자이너는 타고난 감각도 좋아야 하겠지만, 자신의 업무에 관련된 탄탄한 정보 데이터베이스를 구축하고 있는것도 상당히 중요하다.

그런 이유로 폰트는 디자인과는 불가분의 관계라 많은 정보를 갖추고 있어서 나쁠것이 전혀 없다. 넘치는것은 막지 않지만 모자라는 것은 권장할 일이 아니다. 예전과 달리 폰트관련 저작권이 강화 되면서 디자인 관련 상업적인 용도로 사용되는 폰트는 필히 유상폰트를 구입해서 사용해야 한다. 그렇지 않을경우, 자칫 저작권 침해로 본의아닌 피해를 감수해야 하는 상황이 발생할 수 있으므로  틈틈히 아래 서체개발 회사의 웹사이트를 찾아보면 폰트의 성격이나 폰트 관련 정보는 익혀 두는 센스가 필요한 까닭이다.

앞으로 디자인 작업에서 기본이라고 할 수 있는 폰트에 대한 이야기를 폰트리뷰 콘텐츠에 담아가기에 앞서 먼저 국내의 서체개발 및 판매업체들을 살펴보고 참고할 수 있도록 웹사이트 링크를 다음과 같이 정리해 보았다. 조금이나마 참고가 되었으면 한다.

산돌 커뮤니케이션
https://www.sandoll.co.kr/
산돌 패키지 서체 개발.

윤디자인 시스템
http://yoonfont.co.kr/
디자인폰트, 윤소호 패키지 서체개발

아시아 소프트
http://www.asiasoft.co.kr/
아시아 서체 개발

양재 미디어
http://www.yjmedia.com/
양재 서체 개발.

C디자인
http://
가가 서체 개발

솔트웍스
http://solfont.com/
SF서체, 웹폰트, 비트맵 폰트, 모바일폰트 개발

모리스 디자인
http://pia.cc/new/
MD서체, 웹폰트 개발

디지웨이브텍
http://www.digiwavetech.co.kr/
디지 서체 개발.

초롱테크(주)
http://www.crfont.com/
CR서체 개발. 단문 캘리그라피, 무료폰트

한양 시스템
http://www.hanyang.co.kr
한양 서체 개발

폰트뱅크
http://www.fontbank.co.kr/
FB서체, 다양폰트 패키지 제공

태시스템
http://www.taesystem.com/
태-영화체, 한국일보, 한겨레 신문서체 개발

직지소프트
http://www.smfont.com
SM, 웹, 모바일, 비트맵 폰트, 신영복체, 서체개발

[출처:www.designlog.org 디자인로그]

최근에 퍼블리셔가 생겨나면서 통상 디자이너가 코딩을 하면서 "기획-디자인-개발"이 "기획-디자인-퍼블리셔-개발"로 바뀌게 되었습니다. 물론 이상적인 경우는 퍼블리셔가 적극 개입된 평형적 구조의 개발과정이지만 모든 구성원이 웹표준을 인지하지 못한 상황에서는 평형적 구조가 불가능 한 것 같습니다. 퍼블리싱을 하는 의미는 웹표준을 지킨다는 것에 국한되어 있다고 해야 할까요. 또한 아직 이러한 구조가 업계에선 활성화 되지 않았고 이렇다할 완벽한 흐름도 아직은 없는 과도기적 단계이기 때문에 아마도 다른 많은 웹표준 초보(?) 기업들에선 제가 했던 것처럼 순차적으로 밀어내는 방식으로 하지 않을까 생각됩니다.

쉽게 말하면 기존에 디자이너가 했던 테이블 코딩을 "코더"가 대신하는 것 뿐인 구조로 작업을 했습니다.

처음엔 업체의 테이블 코딩 요청에 당황을 하기도 했지만 오히려 이런 계기로 회사 내 웹표준에 대한 분위기와 인식은 조금 나아지기도 했습니다. 하지만 물론 인식에 대한 부분만 조금 더 나아졌다 뿐이지 저처럼 ①웹표준 프로젝트 경험이 부족한 채 웹표준 코딩을 적용 하는 경우나 ②프로젝트에 투입된 모든 구성원들의 퍼블리싱에 대한 인식이 없는 경우에는 퍼블리셔는 "표준코딩하는 코더"의 이상도 이하도 아닌 역할이 됩니다.

우선 저는 해당 프로젝트에 대한 플로우를 미처 파악할 여건이 되지 않았던 것 같습니다.
왜냐하면 퍼블리셔의 투입 시기가 시안이 나온 뒤가 되서 그 전의 과정을 알 수 가 없을 뿐더러 넘기는 파일과 문서를 그냥 코딩하면 된다는 인식으로 인해 퍼블리셔의 일정이 촉박하게 되었습니다. 그렇기 때문에 디자이너의 지시를 받아서 하거나, 디자이너의 psd를 전달받아서 작업을 하게 되며 작업관계는 선형관계 또는 상하(?)관계가 됩니다.

그래서 저는 이런 단순한 역할이 아쉬웠습니다.
전체 흐름을 파악한 뒤 작업해야 전체적인 틀을 구성 하기 수월할텐데 마치 숲이 아닌 나무를 더듬 더듬 작업하는 기분이였습니다. 아직까지 웹표준 코딩을 할 때에 익숙하지 않은 저는 좀 더 예민하게 전체 사이트 구조를 머릿속에 정리하고 염두하고 작업을 해야 했는데 엉성한 스토리 보드와 빠듯한 일정에 굉장히 힘들었습니다.

웹퍼블리셔는 모든 프로젝트의 중추적인 역할을 해야 합니다.
정찬명님이 없는 것은 마크업이 아닙니다" 라고 했듯이 퍼블리셔는 많은 조건 위에서 그러한 조건들을 감안하는 작업을 해야 합니다. 모든 페이지의 플로우를 이해하고 "개발"해야 하는 중요한 역할을 하는 입장입니다. 하지만 열악한 조건(order를 받는 역할과 부족한 시간)들에서 제가 중심을 잡고 진행하기는 힘들었습니다.기존 테이블 코딩은 단편적이지만 웹표준은 구조적인 작업입니다. 구조적이고 모든 마크업이 의미를 갖도록 흐름을 파악하고 중심적 역할을 해야지만 그렇지 못할 경우에는 도미노처럼 문제가 생길 수가 있습니다. 아니, 건축에 비유하는게 나을 것 같네요. 중간에 허술한 구조가 되면 건물이 무너질 수 있습니다. (결국 저는 정신줄을 놓고 싶은 지경에 이르기도 했습니다.)

전체적으로 느낀 점은 에이전시 자체의 변화가 필요하다는 것입니다.
포털 및 많은 에이전시들이 나아가고 있고 달라지고 있지만 아직 역부족인 부분이 많이 있습니다. 제가 바라는 것은 회사에서 웹표준과 웹접근성의 개념이 존재하는 것입니다. 중요하다고 말하기 때문에 중요하다 여기는게 아니라 조금은 원론적이더라도 기본 개념을 알고 계약 조건이 아닌 필수적인 요소로 인식하게 되길 바라는것입니다. 하지만 아직까지도 많은 CEO들은 이러한 일이 "money"가 되지 않는다는 생각을 가지고 있습니다. (그러다가 결국은 급할 때 비싼 비용으로 퍼블리셔를 몇개월간 고용하죠.)

또 하나는 퍼블리셔분들은 지금처럼, 지금보다 더 전문적인 능력이 필요하다는 생각입니다.
지금 시점의 퍼블리셔는 ①의미에 맞는 마크업을 잘 하는 것은 물론이고 ②타인을 설득하는 능력까지 갖춰야 하는 전도사의 역할까지 해야하는 상황의 이중고에 있습니다. 따라서 더 많은 행사 등도 필요할테고 그러한 많은 표면적 활동들을 통해 퍼블리셔가 더 큰 목소리를 내야 할 것 같습니다. 아직은 웹표준 코딩만 잘한다고해서 코더라는 낡은 명함을 버리고 퍼블리셔라는 명함을 달 수는 없을 것 같네요. 전문적인 퍼블리셔와 웹표준과 접근성에 대한 웹 산업 전반의 인지가 부족하니 말입니다.

아무튼 프로젝트를 진행하면서 개인적인 능력의 한계로 아쉽다는 부분을 느낀 점도 많지만 그래서 더 노력을 해야 겠다는 생각도 들었지만, 무엇보다도 퍼블리셔가 중심적 역할을 해야 한다는 인식을 중요성을 느꼈습니다.

[출처: 정리정돈's Blog is powered by Daum & Tistory]

웹표준으로 작업한 프로젝이 오픈이 되어서 작업을 하면서 느꼈던 내용을 조금씩 적어보려고 합니다.

여태 했던 작업은 디자인-코딩을 혼자서 하거나, 규모가 크지 않거나, 디자인 요소가 많거나 적거나 했던지라 큰 무리가 없었는데 그에 비해 이번 프로젝트는 웹사이트의 규모와 컨텐츠의 종류등 방대해서 긴장하고 진행했던 프로젝트였습니다. 게다가 작업 인력 투입도 턱없이 적었습니다. 나중에 가서는 이런 저런 상황들 때문에 스스로 타협해버린 부분도 많아서 정말 아쉬운 마음이 컸습니다.

그래서 이름하여 "웹표준 작업 후기" 라는 타이틀로 제가 느낀 많은 이야기를 하고자 합니다.
이번글은 1탄! "웹접근성 보장과 업무협업"입니다.

다른분들도 비슷하실테지만 제가 작업한 방식은 아래와 같습니다.

디자인 부분은 제외하고 코딩 부분만 따졌을 때에 작업하면서 주의해야 했던 부분은 아래와 같습니다.

우선, 클라이언트가 까다롭게 디자인을 요청하면서 단순 텍스트까지 이미지로 꾸며주길 원했습니다. 그리고 설명같은 경우 도식화 하여 내용을 한눈에 알아볼 수 있도록 '일반사용자'를 배려한 작업을 했습니다.
(우리는 모든 사용자를 배려해야 하기 때문 일반사용자의 배려라는건 참 고민스럽습니다. 사용자 경험도 마찬가지구요. 사실 고민을 하지만 잘 모르겠습니다.)

이미지로 된 텍스트 영역을 bg로 처리하기에는 무리가 있어서 alt값을 일일이 입력하여 작업을 했고, 하다보니 이미지 갯수가 너무 늘어나게 되버리더군요. 그래서 정말 많은 텍스트는 간단하게 요약을 하여 alt값을 넣기도 했습니다. 플래시의 경우는 신현석님의 플래시 오브젝트 표준으로 사용하기 페이지를 참고했는데 역시 대체 텍스트 때문에 파일 라인이 엄청 늘어나더군요. :)

그리고 정작 난감한 문제는 도식화 된 영역을 의미에 맞도록 작업하는 것이였습니다.

css를 뺐을때 의미있는 흐름을 만드는것도 쉬운건 아니지만 IE6,7과 불여우, 오페라 등의 브라우저를 맞추는게 꽤나 시간이 걸리더군요. 특히 말하면 입아플 IE6은 정말이지... 그렇지만 정말 올바른 마크업을 할 경우에는 IE6도 잘 따라와 준다는건 제 잘못이 크다는 것이겠죠? 그래서 결과적으로 더 많이 배우고 알 수 있는 계기가 되었습니다. 역시 뭐든지 해보지 않고는 모르는 일이죠. ^^

혼자 고민하고 해결하면서 배워나가는 일은 스스로 나아지고 있다는 느낌을 갖게 되었지만 다른 작업자와의 업무협업에 관해서는 즐겁지만은 않았습니다.

표준작업이든 기존의 테이블 작업이던 다른 사소한 일에서도 제가 중요하게 여기는 부분 중 하나가 바로 "네이밍" 인데요, 제가 기억력이 나빠서 바쁘게 일하다 보면 솔직히 나중에 가면 내가 지은 이름도 제 각각인 경우도 있습니다. 그래서 그런지 더 네이밍에 집착을 하고 예민하게 굴기도 합니다.

제가 네이밍을 하는 경우는 보통 세가지가 있는데
① 페이지이름 ② 이미지이름 ③ 스타일시트의 아이디/클래스명 입니다.
페이지이름은 기획자가 잡아주는 경우도 있겠으나 보통은 프로그래머와 간단한 조율만 가지고 제가 정하며 추후에 프로그래머가 일부 변경도 하기도 합니다. 그래서 온전하게 제 몫인, 그래서 제일 민감하고 중요하고 신중한 부분은 이미지명과 스타일시트입니다.

하지만 코딩에 대한 인력이 당초 저뿐이였지만 일정이 빠듯하여 잠깐 서브코더가 투입이 되었을 때 문제가 생겼습니다.

"의미에 맞게" 작업하라는 의도가 충분히 전달되지 않았던 문제였는지 서브코더는 단순히 table를 div로 대체한 수준의 작업을 하셨습니다. 미처 확인하지 못하고 지나가다 보니 작업하신 모든 페이지를 다시 코딩해야 할 지경이였고 이미지 파일명도 마찬가지였고, class명도 그랬습니다. 이미 많이 진행되어 제가 고치기도 애매한 상황인데다가 작업자분의 class명을 제가 알아먹을 수가 없었습니다.
결국은 큰소리가 나면서 서브 코더가 수정을 하기로 했지만 사이트 오픈때 까지도 제가 의도하지 않은 부분에 대해서 끝내수정되지 않은 부분이 많이 있었습니다.

제 성격이 고집도 세고 업무적으로는 제가 믿는 부분에 대해서 밀어 붙이는 성격인지라 솔직히 협업에 익숙하지 않아서 제가 배려가 없는 작업을 했던건 아닌가하는 생각이 들었습니다. 의례 저처럼 - 기존 작업물의 방식을 보고 알아서 - 작업할거라는 생각을 했었습니다.

결과적으로 이 프로젝의 경우에는

+추가글
말이 나온김에 조금 덧붙이자면 "웹표준 작업" 이라는 것은 아직도 착각하시는 분들이 계신데 table을 div로 바꾸는 것이 아니죠. 그럼 기존과 차이점이 없지 않나요? 또 혹자들은 앞으로는 드림위버든 익스프레션이든 다양하고 쉬운 소프트웨어들이 나올 것이기 때문에 공부하지 않아도 될 것 처럼 말합니다. 더 충격적인 사실은 웹표준을 swf로 포장 하려는 사람들이 많다는 것입니다. (망할!)

바른 웹사이트를 제공해야 하는 개발자들은 우리들 "사람"입니다. 또한 웹표준 사이트를 평가하거나 실제 사용하는것도 물론 "사람" 들입니다. 그냥 사람들이 아니라 조금은 불편한 조건의 사람들도 있습니다.
본질이 뭔지 파악조차 못하고 소프트웨어만 믿는 사람들이나 얄팍한 생각과 지식으로 눈가리고 아웅하는사람들은 올바른 퍼블리싱을 하겠다고 많은 노력을 하는 퍼블리셔분들과 그들의 성과를 보지 못하고 생각하지 못하는 것 같습니다.

솔직히 우리들은 바르고편한 e-세상을 만드는사람들이지 근본적으로 그것을 누리는 사람들은 아닙니다.
(안일하고 쉽게 가려는 생각을 가지고 있다면 이러한 혜택을 받을 수 있는 직업으로 바꾸시는게..)

[출처: 정리정돈's Blog is powered by Daum & Tistory ]

 

웹퍼블리셔(Web Publisher)는 웹사이트를 제작함에 있어서 어느 정도의 역량을 가져야 하며, 어디까지가 우리의 역할일까? HTML 중심의 이러한 개발 및 디자인 작업을 하면서 항상 갖게 되는 질문이고 속 시원하게 대답이 나오지 않는 질문이기도 하다.

다음은 나름의 경험과 고민을 통해서 정리한 것으로 개인마다 의견이 다를 수 있다. 조금 더 경력이 쌓이면 달라질 수도 있겠지만 우선은 다음과 같은 일곱 단계의 과정을 웹퍼블리셔가 할 수 있는 업무의 범위라고 생각하고 간략히 정리해 보겠다. (편의상 단계라는 표현을 썼지만 반드시 지켜져야 하는 순서는 아닙니다.)


1단계 - 환경분석과 시스템배치

기획 단계에서 프로젝트에 대한 환경적인 분석을 실시한다. 여기서 환경이라 함은 사이트가 운영 및 유지되는 서버와 서버 사이드 개발 인력의 수, 역량 등을 의미한다. 사용된 웹서버와 데이터베이스 서버는 무엇인가? 인코딩을 무엇을 할 것이며, HTML 문서의 가장 중요한 DTD 정의는 무엇으로 할 것인가? 스크립트를 구현함에 있어서 서버 사이드 개발자와 어디까지를 공유할 것인가? 디렉토리는 어떻게 구성하며 이미지 서버는 별도로 둘 것인가? 크로스 브라우징은 어디까지 지원할 것인가? 주요 접근성 이슈를 어떻게 확보할 것인가?와 같은 프로젝트 도입 이전에 고려될 수 있는 여러가지 시스템적 인적 환경을 조사하고 마크업 개발에 필요한 조건들을 기획자에게 제안하여 스토리보드에 반영될 수 있도록 한다. 특히 웹접근성 확보를 위한 고민은 디자이너와 서버 사이드 개발자의 역량에 따라서 적용 가능한 범위가 제한될 수 있으므로 충분히 논의가 될 필요가 있다. (논의 없이 웹퍼블리셔가 이러 이러한 웹접근성 이슈를 처리하자라고 문서화 해봤자 서버 사이드 개발자들은 웹퍼블리셔가 혼자서 다 할 수 있는 것들로 오해해 버리는 경우가 종종 있다.)


2단계 - 구조적 설계(HTML Design)

기획자로부터 기획문서(스토리보드)가 만들어지면 이를 바탕으로 HTML 문서를 작성한다. 이 때의 HTML 문서는 디자인이 적용되지 않은 상태이며 사이트의 가장 기초적인 골격의 형태(내용의 선형성을 유지하면서 접근성이 확보되어야 한다.)를 가진다. 완성된 HTML을 통해서 사이트 네비게이션과 프로세스를 체크하여 문제점을 보완한다. 이는 사이트의 가장 기본적인 프로토타입이 될 수 있으며, 이 단계에서 발견된 문제점은 보다 빠르고 쉽게 수정될 수 있다.


3단계 - 스타일시트 설계(CSS Design)

디자이너에 의해 디자인이 완료(또는 단계적 완료)되면 HTML 문서 위에 스타일을 작성하여 적용하기 시작한다. 둘 이상의 웹퍼블리셔가 함께 작업한다면 시니어가 마스터 CSS를 설계하고, 주니어가 이를 통해 작업을 진행할 수 있도록 한다.


4단계 - 스크립트 개발(Script Development)

스토리보드를 통해서 전체적인 프로세스를 확인하고 서버사이드 연동 없이 구현 가능한 '동작(behavior)'요소를 확인하여 목록화 한다. 3단계 이전에 가능한 스크립트를 구분하여 미리 작성하거나 필요한 스크립트를 준비해 두면 후반 작업의 수고를 덜어줄 수 있다. 사이트의 규모가 제법 크거나 스크립트의 사용이 많은 경우 jQuery와 같은 라이브러리를 이용하는 것도 좋다. 단, 이같은 라이브러리 사용시 서버 사이드 개발자와 합의를 해 두는 것이 좋다. 때때로 prototype과 jQuery가 함께 뒤섞인 사이트가 오픈되기도 하기 때문이다. 이는 매우 비효율적인 짓이다.


5단계 - 테스트, 유효성 검사(Test And Validation Check)

테스트는 사이트 네비게이션과 링크 요소의 값이 정상인지를 확인하는 과정으로, 서버 사이드 개발이 이루어지지 않은 환경에서도 적절한 링크를 따르고 있어야 한다. 특히 게시판의 리스트, 뷰, 쓰기 화면의 링크를 생략하거나 데드 링크를 수정하지 않고 그대로 서버 사이드 개발로 넘기는 경우가 많은데 협업간의 편의를 위해서라도 깔끔하게 처리하자. 유효성 검사는 HTML과 CSS에 대한 문법적 검사로 페이지 단위로 이루어진다. Firefox의 확장기능인 HTML Validator를 이용하거나 Dreamweaver의 유효성 체크를 이용하면 검사 시간을 절약할 수 있다. 단, HTML Validator나 Dreamweaver의 기능이 W3C의 유효성 검사와 같지 않을 수 있으므로 메인 페이지나 주요 페이지의 경우 별도의 W3C 유효성 검사를 실시한다.


6단계 - 웹접근성 검사

완성된 사이트(서버 사이드 개발 완료)가 웹접근성을 충분히 확보하고 있는지 확인한다. 서버 사이드 개발자에 의해 HTML과 CSS, Script의 문법이 표준을 따르지 않게 되거나, 접근성을 제한하는 경우가 확인된다면 피드백을 통해서 수정할 수 있도록 한다. 웹접근성 검사는 KADO의 WAH를 이용할 수 있다.


7단계 - 문서화

일련의 과정을 통해서 문서를 남기는 작업은 그 무엇보다 중요하다. 1단계 기획단계에서 시스템을 분석하고 웹접근성 확보와 표준화 레벨을 결정함에 있어서 조사하고 결정된 사항들을 문서로 만들어 기초 가이드로 설정할 수 있다. 2~6단계에 이르는 동안 협업간의 여러가지 이슈가 발생할 수 있고 이를 이슈리스트(가칭)로 정리를 해 둔다면 차후 프로젝트를 진행함에 있어서 실수와 오류를 줄일 수 있다. 최종적으로 사이트가 오픈이 되면 주요 페이지의 W3C 유효성 검사와 웹접근성 검사등을 실시한 결과를 문서화 하여 유지보수 또는 차후 리뉴얼의 참고문서가 되도록 한다.

 

[출처: 웹 뒤에 숨은 'Web'/웹퍼블리셔 잔소리 | 2008/09/30 00:46 | 봄눈 ]

Chris Coyier는 SMASHING MAGAZINE을 통해서 '12 Principles For Keeping Your Code Clean'이라는 제목의 멋진 글을 소개하고 있습니다. 그가 CSS을 사람들에게 가르칠 때부터 강조했던 원칙들로 다음과 같습니다.

얕은 영어 실력으로 제대로 번역은 어렵고, 제목 위주로 짧게 소개만 해 드리겠습니다.

1. 엄격한 DTD를 사용할 것 (Strict DOCTYPE) 
   
   어떤 레이아웃을 위한 테이블 요소도 사용하지 않는다면 Transitional Doctype 은 필요 없다.
   
   
   
2. <title> 속의 '&'를 인코딩할 것 (Character set &amp; encoding characters)
   
   <head> 섹션 안에서 문자 집합(Character set)을 가장 먼저 정의해 주도록 한다. 많은 경우 <title>을 가장 먼저 작성하면, <title> 안에 '&'와 같은 문자가 제대로 인코딩 되지 않는 문제가 생길 수 있다. 때문에 <title>과 <meta http-equiv="Content-Type" ... />의 자리를 바꿔 주는 것이 좋다.
   
   
   
3. 적당한 들여쓰기를 할 것 (Proper indentation)
   
   들여쓰기는 코드의 가독성을 높여 준다. 표준 절차에서 새로운 요소가 시작될 때 그것의 자식 요소는 한 개의 탭(또는 약간의 공백)을 띄운다.
   
   
   
4. CSS와 JavaScript는 외부에 둘 것 (Keep your CSS and JavaScript external)
   
   CSS와 JavaScript를 HTML 안에 둔 경우 단 하나의 HTML 페이지만을 위해서 사용된다. 같은 코드의 많은 HTML 페이지들을 위해서라면 HTML 페이지 밖에 두는 것이 좋다.
   
   
   
5. 태그를 바르게 감쌀 것 (Nest your tags properly)
   
   인라인 요소로 블록 요소를 감쌀 수 없다. 올바른 방법으로 태그를 감싸야 한다.
   
   
   
6. 필요 없는 div를 제거할 것 (Eliminate unnecessary divs)
   
   div를 불필요하리만치 많이 사용하는 경우가 있다. 필요하지 않다고 판단되는 div를 제거하고 최소화 하자.
   
   
   
7. 의미 있는 이름을 사용할 것 (Use better naming conventions)
   
   좋은 class와 id 속성의 이름은 "mainNav", "subNav", "sidebar", "footer", "metaData"와 같은 것들이다."red", "italic"과 같이 디자인을 기술하는 이름은 적당하지 않다.
   
   
   
8. 영문자의 대소문자화 같은 타이포그라피는 CSS를 이용할 것 (Leave typography to the CSS)
   
   CSS를 이용하면 소문자를 대문자로, 대문자를 소문자로 변환할 수 있다. 마크업을 통해서 하지 말고, CSS를 이용하자. 하지만 한글에서는 사용되지 않는 기능이다.
   
   
   
9. <body> 에 class와 id 속성을 쓸 것 (Class/id the <body>)
   
   <body>에 class와 id 속성을 지정함으로써 다양한 디자인 변화에 대한 레이아웃(대체 레이아웃)을 유지할 수 있다.
   
   
   
10. 유효한지 검증할 것 (Validate)
    
    유효성 검증을 실시하자. HTML 마크업과 CSS에 대한 W3C Validation이 있다.
    
    
    
11. 논리적인 순서를 가질 것 (Logical ordering)
    
    풋터는 논리적으로 헤더나 사이드바보다 아래에 위치한다. 마크업 안에서도 역시 마지막에 위치하는 것이 옳다.
    
    
    
12. Just do what you can
    
    중요한 것은 HTML을 제대로 작성하는 방법을 배우고, 그것을 정확히 사용하는 것이다. 그리고 다음에 새로운 프로젝트를 시작하게 되면 당신은 그렇게 할 수 있을 것이다.

원문에는 각 원칙별로 참조 문서를 링크하고 있어 12가지의 원칙을 읽으면서 여러가지 공부를 함께 해볼 수 있습니다. 시간내서 꼭 한번 살펴보세요.

 

 

[발췌:  웹 뒤에 숨은 'Web'/웹퍼블리셔 잔소리 | 2008/11/13 14:55 | 봄눈]