2009년 1월 31일 토요일

Copyright를 Address 요소에 넣어야 할까?

많은 웹 사이트들이 저작권(Copyright)을 표시하고 있습니다. 작은 로고와 주소, 운영자 아이디 등과 함께 위치합니다. 일반적으로 화면의 하단 부분, 논리적으로 끝에 나타나고 바닥글(풋터 / Footer)라고 부릅니다.

HTML 이 문서의 모든 요소들을 의미있게 정의하도록 충분한 요소들을 제공하고 있지 못하지만 특히 바닥글에 포함되는 여러가지 정보들에 대해서 인심이 빈약하지 않나 싶을 때가 종종 있습니다.

주소를 위한 요소로 <address>를 사용합니다만 종종 저작권 정보를 함께 담고 있는 웹사이트도 볼 수 있습니다. 국내 일부 사이트를 살펴보니 네이버 등이 그렇게 하고 있네요. 다음과 미투데이, 오픈마루 등 많은 사이트들은 <p>요소에 'copyright'와 같은 의미 있는 이름을 id나 class 속성에 지정하여 사용하고 있었습니다.

W3C의 HTML 명세서에서 살펴본 내용 중에는 특별히 '저작권' 정보를 담는데 사용한다라는 것은 나와 있지 않았습니다. 반면에 MSDN 라이브러리에서는 'such as address, signature, and authorship'라고 적고 있어 저작권에 대한 부분까지 의미가 확대되어 있습니다. 또한,  국내의 일부 서적 등에서 'HTML 문서의 마지막에 문서로 작성한 사람의 전자우편 주소나 서명, 저작권 등을 나타내기 위하여'사용한다라고 기술되어 있었습니다.

이렇게만 보면 특별히 문제가 될 것은 없어 보입니다만 정작 MSDN의 하단 저작권 부분에서 <address> 요소를 사용하지는 않았네요.

저작권을 <address> 요소에 삽입하는 것이 정말 의미적으로 올바른가? 하는 궁금증이 생길 것도 같습니다.

사실 저는 예전부터 저작권 정보는 주소나 연락처, 이메일 처럼 웹사이트 또는 해당 기업, 단체와의 접근 정보로써 제공될 수 있는 정보는 아니다라고 판단했고, 때문에 많은 사이트에서와 같이 ID나 Class에 'Copyright'라는 이름을 부여한 <p> 요소를 사용해 왔었습니다. 이 방법이 조금 더 낫지 않을까 싶지만 저와 다른 생각을 하시는 분들도 계시겠죠? 어떻게 생각하세요? Copyright를 Address 요소에 넣어야 할까요?




2009년 1월 21일 수요일

웹브라우저, 코끼리와 장님들 카툰

웹브라우저, 코끼리와 장님들

'웹브라우저, 코끼리와 장님들'에 등장한 브라우저들


블로거 이정희님의 '해바라기 C' 블로그에 올라온 카툰입니다. '코끼리와 장님들'이라는 인도의 우화를 비유한 제목의 이 카툰은 Firefox, Internet Explorer의 싸움과 브라우저들간의 호환성 문제를 쉽고 재미있게 잘 그려주신 것 같습니다.

열번 듣는 것 보다 한 번 보는 것이 낫다고 역시 그림으로 보니 이해가 더 쉬운 것 같습니다.

카툰이 인용한 '코끼리와 장님들'은 인도의 장님 여섯명이 코끼가 어떻게 생겼는지 알아보기 위해 각자 코끼리를 만져보고, 각자의 생각대로 "코끼리는 이렇게 생겼어!"라고 주장하는 이야기입니다. 첫번째 장님은 코끼리의 옆구리를 만져 보고 나서 벽처럼 생겼다고 하고, 뾰족한 상아를 만진 만진 장님은 창처럼 생겼다 합니다. 코를 만진 장님은 뱀같아고 하고, 다리를 만진 장님은 나무 같다고 하죠. 또, 귀를 만진 장님은 넓은 귀 모양의 팬이라고 주장하고, 꼬리를 만지고서 줄 같다고 합니다.

이렇게 여섯 장님은 자기가 만지고 느낀 것만으로 판단한 것이 전부인양 그것이 옳다고 주장하며 싸우게 됩니다. 하나의 웹을 놓고 다양한 웹 브라우저들이 서로 자기가 제대로 보여준다고 주장하고 있는 이 상황과 너무나 일맥상통한다고 느껴집니다.

그래서인지 카툰의 마지막 장면은 참으로 인상적입니다. Firefox와 Explorer, Safari와 Opera, Chrome이 나란히 손을 잡고, 희야(카툰의 주인공)가 집(홈페이지)을 제대로 짓도록 하나씩 맞춰줍니다.

웹 표준을 지켜달라는 대사 한 마디 없는 카툰이지만 그 이상으로 웹 표준의 필요성을 확실하게 느껴주게 하는 카툰이었다고 생각합니다.


2009년 1월 19일 월요일

[책] Everything You Know About CSS is Wrong!

Rachel Andrew와 Kevin Yank의 eBook 'Everything You Know About CSS is Wrong!'을 소개해 드립니다.

Everything You Know About CSS is Wrong!

Everything You Know About CSS is Wrong!

이 책은 CSS의 문제점들과 Floats과 Position을 이용한 CSS 레이아웃 설계의 문제점 등을 지적하면서 'CSS Tables'를 사용해서 색다른 대안을 제시(CSS tables solve all the layout issues we’ve explored here regarding positioning and backgrounds in modern browsers.)하고 있습니다.

처음에 'CSS Tables'이 뭔가 했는데 table, table-row, table-cell... 과 같은 display 속성을 이용한 방법론이었습니다. Digital Web Magazine 에서 책의 요약본이 소개되고 있으니 참고해 보시면 될 것 같습니다.

저도 아직 서두와 목차만 살펴본 상태라 자세한 내용 언급은 어렵네요. 최근 관련 eBook들을 소개하고 있던 참에 IE8까지 다루는 신간(?)으로 나온 것이라 바로 소개해 드립니다.

책의 배포는 Sitepoint에서 유로로 하고 있습니다. 1,2챕터를 담고 있는 샘플 PDF를 내려 받아 보실 수 있습니다. 책 제본 형태와 PDF 형태로 판매되고 있기는 한데, Net Books 에서는 무료로 내려받을 수 있도록 하고 있네요. 두 가지의 내용 차이는 1,2챕터만 비교해 봤을 때는 없었습니다. 분량이 132쪽으로 2쪽 모아찍기로 간단히 제본을 해 두면 분량이 그렇게 많지 않으니 괜찮은 책 한권을 얻게 된 셈이지 않겠습니까 하하

웹표준교과서 찾아보기 업그래이드

웹표준 교과서가 1년 7개월만에 3쇄를 찍었다고 하네요. 웹 표준을 공부하는 사람들에게 제목처럼 '교과서'가 되어 버린 이 책이 꾸준히 사랑을 받고 있다는 소식은 개인적으로 기분 좋은 소식이었습니다.

개인적으로도 1쇄판을 구입해서 지난 한 해 스터디 그룹의 교재로 활용을 했었는데 당시에 아쉬웠던 오타 등이 3쇄를 통해서 많이 정리되었다고 하니 조금 더 퀄리티를 높였을 것으로 기대를 해 봅니다.

특히 3쇄를 통해서 찾아보기를 많이 강화하고, 별도로 블로그에 포스팅까지 해 주셨네요. 1쇄나 2쇄본을 가지고 계신 분들께도 도움이 되리라 생각되네요.

찾아보기 전체보기..


ps/ 중복된 항목과 몇가지 거슬리는 것들이 있어서 몇가지 수정을 하고 인쇄를 편하게 해 보려고 Clearboth Wiki(제가 참여하고 있는 스터디 그룹 위키) 페이지에 등록한 조금 다른 버전도 있습니다.

2009년 1월 17일 토요일

IE6에게 작별 인사를 하세요

IE6에게 작별 인사를 건낼 수 있는 사이트가 오픈했다.

Dear IE 6

지금까지 IE6때문에 고생했던 것을 생각하면 온갖 욕을 다 퍼부어주고 싶었으나... 영어가 매우 짧기 때문에 몇 자 못 적었다. 한글이 지원되었더라면 마음껏 썼을 테지만 아쉽게도 영어를 제외한 언어는 지원되지 않는 것 같다.

DearIE6 사이트에 글을 올리는 방법은 트위터에서 @DearIE6 로 댓글을 남기면 된다.
트위터 가입자가 아니라면 이 이벤트에 참여하기가 어려운 것이 단점이다. 트랙백을 걸게 하거나 자체 댓글 시스템이 있었더라면 좀 더 좋았을 것 같은데 아쉽긴 하다.

자바스크립트 긴 매서드 짧게 만들어서 쓰자구요

자바스크립트를 작성하다 보면 긴 매서드명을 불편하 하는 경우가 많습니다. getElementById나 getElementsByTagName이 대표적이죠. 거기다 단어의 첫 글자를 대문자로 표기하는 카멜케이스 방식 역시 스크립트 작성을 더디게 하죠.

물론 어느정도 숙달이 되면 크게 게의치 않고 사용하게 되긴 하지만 Prototype.js나 jQuery와 같은 프레임워크를 사용해보면 $ 매서드의 편리함에 도저히 getElementById와 getElementsByTagName 를 고지식하게 타이핑 하기가 싫어집니다. (이래서 사람은 편해지면 안되나 봅니다 ㅠ ㅠ)

그래서인가요 Martin Ivanov가 이런 팁 하나를 소개해줬습니다.
가장 타이핑 하기 귀찮은 매서드중 하나인 getElementsByTagName을 단 4자로 줄여주는 방법입니다.

function $tag(tagName)
{
  return document.getElementsByTagName(tagName);
}

$tag라는 함수를 작성했습니다. 함수의 내용은 전달 받은 인자를 getElementsByTagName 매서드에 전달해서 값을 리턴하는 방식입니다. 아주 간단합니다. 이렇게 하면 앞으로 getElementsByTagName(div) 대신 $tag("div")로 사용할 수 있습니다! 원한다면 함수명을 1~2자로 더 줄일 수도 있습니다. 같은 방법으로 getElementById도 별도의 짧은 이름의 함수로 만들어서 사용할 수 있습니다.

자바스크립트 프레임워크는 여러모로 편리하고 다양한 기능을 쉽게 구현하게 해 주지만 일반적인 웹 사이트 개발에 절대적으로 필요한 경우는 많지 않다고 생각합니다. 그런 경우 위와 같은 방식으로 이름이 긴 매서드들을 축약 함수명으로 작성하여 이용한다면 개발의 편리함을 누려볼 수 있지 않을까 생각됩니다.

웹 표준 뭐라고 생각하세요?

세번째 웹 표준의 날에 앞서 CDK에서 웹 표준이 무엇이라고 생각하는지에 대한 질문을 던지고 있습니다. 저는 아래와 같이 답했는데요

  • 웹 표준 뭐라고 생각하세요?
    웹 표준은 교양 필수 과목이다.
  • 웹 표준 어떻게 생각하세요?
    누구에게나 따분할 수 있는 과목이지만 꼭 한번은 들어야 하는 교양 필수 과목이다.
  • 웹 표준의 장점은 뭘까요?
    좁게는 졸업(성공)을 위해서 넓게는 전공(꿈)을 위한 가장 기본이 되고, 기초가 되는 수업이다.
  • 웹 표준의 단점은 뭘까요?
    꼭 들어야 하는 수업이니 만큼 자체 휴강이 어렵다. 듣기 싫어도 꾸준히 그리고 열심히 공부해야 한다.

질문을 받고 한참 고민을 했습니다. 나름 웹 표준에 대한 고민이 많았지만 정작 답을 쓰기가 쉽지 않았습니다. 몇번이나 적었다가 지우기를 했습니다. 그러다 문득 대학교 1학년 시절 햇볕이 책상 머리까지 길게 뻗쳐 내리 쬐는 초여름 어느날의 교양 수업이 생각났습니다. 어찌나 듣기 싫고 졸립기만 했던지 교수님의 강의는 마냥 자장가와 같았던 것 같습니다. 하지만 그 수업은 휴강도 별로 없었을 뿐더러 대리 출석도 어려웠고, 자체 휴강은 수업 자체를 포기하는 것과 같았었죠. 과제도 많았던 것 같습니다. 수업 내내 졸다가 집에 가서는 밤새 레포트를 써야만 했던 그런 수업이었죠. 성적도 짰습니다. 재수강을 겨우 피했던것 같습니다.

웹 표준 중요하죠. 웹 퍼블리셔뿐 아니라 웹 기획자, 웹 디자이너, 개발자든 꼭 이해하고 있어야 합니다. 직군마다 깊이와 범위는 다를 수 있겠지만 누구라도 예외가 되어서는 안 될 것입니다. 그런 의미에서 대학 시절 꼭 들어야만 하는 교양 필수 과목과 같다고 생각했습니다. 웹 표준을 공부하는 당장에는 이것이 왜 필요한지 모르겠다고 생각 드는 것도 똑같습니다. 우리가 교양 수업을 들으면서 이 수업을 왜 들어야 하는지 몰랐으니까요. (대부분 말이죠) 내용도 참 따분합니다. 그 소리가 그 소리 같고, 파고 들수록 알아야 할 건 또 엄청 많죠. 강의를 맡은 대부분의 교수님들이 그러 하듯이 웹 표준을 이야기하는 사람들, 세미나, 강좌, 컨퍼런스 역시 하품으로 시간을 때우기가 일쑤입니다.

하지만 대학을 졸업하고 사회에 나오면 깨닫게 되는 순간이 옵니다. 왜 들어야 했는지 몰랐던 그 강의가 지금의 내 지식을 보다 깊게 하고, 태도를 바꿨다는 것을 알게 되거든요. 웹 표준 역시 시작할 때는 잘 모릅니다. 저 역시 아직 잘 모르겠습니다. 하지만 섣부른 생각일지 모르겠지만 꼭 들어야 하는 수업이라는 겁니다. 1년 후에 지금보다 훨씬 더 지식적으로 깊고, 이 일(직업)에 대해서 나름의 태도(생각과 철학 등)를 확실히 가질 수 있다고 생각합니다.

웹 표준, 꼭 필요한 수업입니다. 모두들 너무 늦지 않게 수강하세요^^

2009년 1월 14일 수요일

세번째 '웹 표준의 날' 합니다.

국내 최고의 웹 표준 커뮤니티 CSS Design Korea 에서 주최하는 '웹 표준의 날' 행사가 두 해를 건너 뛰고 세번째 만남을 갖게 되었습니다.

2006년 두번의 행사를 통해서 많은 웹 개발자와 디자이너, 퍼블리셔들에게 웹 표준의 의미와 역활을 전파했던 CDK는 지난해에 '웹 표준 경진 대회'와 'CDK 미니 워크샵'으로 실무자들에게 조금 더 필요한 지식과 정보를 나누는데 집중했고, 다시 올 해 미뤄 두었던 '웹 표준의 날'을 준비했습니다.

다음은 온오프믹스에 올라온 행사 개요입니다.

세번째 웹 표준의 날 (부제: 웹표준을 넘어서)

일시 : 2월 7일 토요일 12시 30분 ~ 18시
장소 : 한국정보문화진흥원 2층 세미나실 (정보문화진흥원 오시는길)

주최 : CDK, ClearBoth
후원 : 한국정보문화진흥원

발표순서
  1. 12:30 ~ 13:00 시작
  2. 13:00 ~ 13:30 웹 표준을 넘어서 - 정찬명(http://naradesign.net/wp/)
  3. 13:30 ~ 14:00 웹 표준, 기술의 진정성 - 추지호(http://www.pageoff.net/)
  4. 14:00 ~ 14:30 장차법 시대의 웹 표준 - 장성민(http://www.jangkunblog.com/wp/)
  5. 14:30 ~ 14:50 20분간 휴식
  6. 14:50 ~ 15:10 브라우저 업그레이드 캠페인 - 조현진(http://resistan.com/)
  7. 15:10 ~ 15:30 웹 표준 경진대회 & CSS PLAYGROUND  - 홍윤표(http://mydeute.com)
  8. 15:30 ~ 15:50 웹 접근성 품질 마크 인증제도 - 한정기(KADO)
  9. 15:50 ~ 16:10 20분간 휴식
  10. 16:10 ~ 16:30 웹 접근성 평가툴에 대한 의견 - 현준호(KADO, http://jhyun.wordpress.com/)
  11. 16:30 ~ 18:00 웹 표준... 선배에게 질문하세요.[발표자 + 조훈(http://hooney.net/), 신현석(http://hyeonseok.com), 윤좌진(http://www.boochim.net/)]
참가비 : 없음

이번 웹 표준의 날 행사의 주제는 '웹 표준을 넘어서'로, 정찬명님께서 주제 발표를 맡아 주셨습니다. 그리고 어쩌다가 부족한 제게도 한 자리가 주어져서 짧은 시간 동안 여러분들께 제 경험과 고민을 전달하는 기회가 있을 것 같습니다. 장성민님께서는 바로 코 앞에 닥친 장차법과 관련된 이야기를 다뤄 주시고, 최근 IE6 업그래이드 캠페인으로 다양한 의견들이이 나와서 술렁이기도 했는데 조현진님이 다뤄 주실 것 같습니다. 홍윤표님께는 행사 준비일로 무척이나 고생을 하셨는데 지난 해 있었던 웹 표준 경진대회에 대한 발표까지 준비하셨네요. 이어서 KADO에서 웹 접근성 관련된 주제 두가지를 발표하고, 마지막 시간에 행사에 참여한 모든 사람들이 의견을 나눌 수 있는 시간이 준비되어 있습니다.

가장 중요한 참가비는 없군요!

아래 참가 신청판을 통해서 지금 바로 신청하실 수 있습니다.


Firefox 3 캠퍼스 프로모션

한국 모질라 커뮤니티에서 Firefox 3 캠퍼스 프로모션을 진행하기 위한 지원자를 모집하고 있습니다.

Daum 과 Mozilla 재단이 제휴하여 곧 Firefox 3 Daum Edition을 발표하면서 동시에 국내 각 대학을 순회하며 홍보를 벌이는 프로모션을 계획중이라고 합니다.

새학기가 시작되는 3월 또는 축제 기간인 5월 중 진행될 것으로 보이며, 각 학교별로 지원자를 모집하고 있습니다.

자원봉사에 참여하고 싶으신 분들은 한국 모질라 커뮤니티를 방문해 주시면 됩니다.


캠퍼스 프로모션 사례들 (출처-한국 모질라 커뮤니티) :

Image
Image
Image
Image
Image

입체로 보는 CSS Box Model

Douglas Livingstone의 웹사이트 Tstme에는 입체로 보는 CSS Box Model이 있습니다.
예전에 스터디 그룹 내에서는 공유가 된 적이 있는 곳인데, 블로그를 통해서는 소개되지 않은 것 같아서 포스팅 해 봅니다.


CSS Box Model은 CSS를 공부하기 시작할 때 꼭 한번은 이해를 해야 하는데 생각만큼 쉽게 이해하지 못하는 경우가 많습니다. 특히나 Quirks Mode로 작동되는 브라우저마다 CSS Box Model을 다르게 계산하는 경우가 있어서 더욱 혼란스럽게들 생각하는 것 같습니다.

위 플래시 데모는 슬라이드바를 움직여 CSS Box Model을 입체 상태로 변환시켜 보여주고 있어, 조금 더 쉽게 이해를 할 수 있게 해주고 있습니다.




2009년 1월 13일 화요일

IE 6/7에서의 Select 옵션 잘림 현상

IE 6/7에서 Select 요소의 Option 목록이 지정된 너비(Width)보다 클 때 잘리는 현상이 나타납니다.

Firefox 에서는 옵션의 내용만큼 자동으로 커집니다

Chris Coyier는 CSS Tricks에 올린 글 Select Cuts Off Options In IE (Fix)을 통해서 jQuery를 이용한 방법을 개선책으로 제시하고 있습니다.
$(function() {

$(".ProductAttributesSelect")

.mouseover(function(){
$(this)
.data("origWidth", $(this).css("width"))
.css("width", "auto");
})

.mouseout(function(){
$(this).css("width", $(this).data("origWidth"));
});

});
.ProductAttributesSelect 는 Select 요소에 지정된 클래스 이름이며, 마우스 오버시 본래의 너비(Width)를 기억 시킨 후 'auto'값으로 변경합니다. 마우스가 아웃 되면 기억된 너비 값을 다시 CSS의 width 속성에 대입시켜서 복귀 시키도록 합니다.

특별히 IE 6/7에서만 작동하도록 작성하면 조금 더 나은 코드가 될 것입니다.

이렇게 작성된 스크립트는 사용자가 셀렉트 박스 위에 마우스를 위치 시켰을 때 옵션의 내용만큼 자동으로 길어지게 됩니다. 반대로 마우스가 벗어나면 원래의 크기를 갖습니다.

간단하게 적용시킬 수 있는 방법이며, jQuery가 아닌 다른 자바스크립트 프레임워크를 사용해도 됩니다. 또는 표준 스크립트 문법만을 가지고도 작성할 수 있습니다.

다음은 다른 방법으로 해결된 경우입니다.

2009년 1월 12일 월요일

파이어폭스 부가기능 Web Developer에 한글 Validation Service 등록하기

파이어폭스의 강력한 웹 개발 도구 중 하나인 Web Developer에는 Markup과 CSS를 Validation Service를 연결하여 클릭 한번으로 사용할 수 있습니다. 그리고 아주 간단하게 한글로 된 Validation Service고 변경할 수도 있습니다.

1. Web Developer 를 설치합니다.

2. Web Devloper 메뉴에서 Tools > Edit Tools... 를 선택합니다.

Tools > Edit Tools...


3. Tools 화면에서 Validation CSS와 Validation Markup을 각각 편집(Edit) 합니다. 이때 한글화가 된 Validation Service의 URL을 다음과 같이 입력(수정) 합니다.

  • 한글 CSS Validation Service 로 변경할 URL : http://qa-dev.w3.org:8001/css-validator
  • 한글 Markup Validation Service 로 변경할 URL : http://validator.kldp.org/

한글 CSS Validation Service 로 변경

한글 Markup Validation Service 로 변경


4. 변경이 완료되었다면 Tools 메뉴에서 Validate CSS 나 Validate Markup를 선택합니다.


5. 다음과 같이 한글화된 Validation Service를 보실 수 있습니다.

어렵지 않은 방법입니다. 하지만 의외로 잘 모르셔서 본래 기능(설정)만을 그대로 사용하시는 분들이 많아서 간단히 팁처럼 작성해 보았습니다.

[책] 웹디자이너와 웹개발자(UI개발)를 위해서 블로그를 책으로 만든 Woork Handbook

Woork HandbookAntonio Lupetti가 우리에게 선물한 아주 멋진 책(eBook)입니다. 이 책은 CSS, HTML, Ajax, Mootools, Scriptaculous, Font 등 그의 블로그에서 꾸준히 소개한 글들을 한데 모아서 만든 훌륭한 참고서입니다. 그는 그의 노력의 결과물을 아래와 같이 멋진 PDF 문서로 만들었고, 그것을 무료로 배포하고 있습니다. 그저 그의 노력과 마음에 감사할 따름입니다.

The Woork Handbook

2009년 1월 11일 일요일

파이어폭스의 귀여운 폭스케 달력

웹표준
금방이라도 눈물을 쏟을 것 같은 커다란 눈동자를 반짝이며 "제발 웹을 아프게 하지 말아 주세요. (Please don't hurt the web)"라고 하소연 하던 모질라의 불여우(포스터)를 기억하시는 분들이 많을 것입니다. 운이 좋게도 저는 제 사무실에 포스터가 붙어 있어 매일같이 마주 보고 있습니다만 모질라나 웹표준 관련 행사장이 아니면 쉽게 볼 수 없는 아이템이죠. 물론 모질라의 프로모션 사이트에서 내려받을실 수는 있습니다.


Foxkeh's Blog

그리고 모질라 일본(Mozilla Japan)에서 운영중인 폭스케의 블로그(Foxkeh's Blog)를 통해서 매달 귀여운 불여우 폭스케의 달력(바탕화면용)을 내려 받을 실 수 있습니다.


폭스케 달력 이외에도 파이어폭스의 역사를 비롯한 웹브라우저 전반의 역사를 살펴볼 수 있는 Learn the History of Firefox와 폭스케의 다양한 동작을 캐릭터화 시킨 이미지들, 폭스케 몸의 일부분만을 잘라내어 다양하게 편집 또는 합성할 수 있게끔 제공하고 있습니다.

폭스케 캐릭터 이미지

폭스케 캐릭터 이미지


파이어폭스와 폭스캐를 사랑하시는 분이라면 즐겨찾기 사이트로 추천해 드립니다.

2009년 1월 10일 토요일

개발자와 주석으로 대화하자

협업에 대한 두번째 글입니다. 1년이 넘는 시간 동안 함께 스터디를 해 온 동생이 하나 있습니다. 그 동생은 성품도 착하고 유쾌한데 웹표준에 대한 열정과 노력도 참 대단합니다. 그 동생이 스터디 활동을 처음 시작하고 얼마 되지 않아서 한달여간 계약직으로 프로젝트에 참여했던 적이 있었습니다. 웹표준에 대한 인식이나 지식은 왠만한 경력자 못지 않았는데 실무 경험이 처음이었다는 점은 웹디자이너나 웹개발자와의 협업 부분에 있어서 적잖이 스트레스가 되는 일이었을 것입니다. 그런데 이 동생이 아주 재치있는 발상으로 개발자와 협업할 수 있는 방법을 나나 함께 스터디 했던 사람들에게 알려주었습니다. 정확히 기억이 나지는 않지만 동생은 당시에 자신의 마크업 사이에 다음과 같은 주석을 남겼습니다.

<!-- 정말 열심히 웹표준으로 코딩했습니다. 제가 봐도 잘 한 것 같습니다. 개발 잘 부탁드립니다 -->

어떤 생각이 드나요? 겸손하지 못하다고 생각하셨나요? 유치하셨나요? 저는 멋지다고 생각했습니다. 주석이 얼마나 중요한 것인지는 새삼 이야기를 꺼낼 필요도 없겠지만 의외로 많은 사람들이 주석을 작성하는데 큰 신경을 쓰지 않거나 아예 작성하지 않기도 합니다. 그것은 자신의 HTML 문서를 건네 받을 개발자에게 마크업에 대한 거의 아무런 정보도 제공하지 않겠다는 굳은 의지(?)라고 밖에는 생각되지 않는 것입니다. 주석 한 줄 없는 HTML 문서를 받아든 개발자는 한참이나 마크업을 분석해야 했을 것이니깐요.

동생과 함께 일했던 스터디의 또 다른 회원 한 분의 입을 통해서 전해들은 이 일화는 웹퍼블리셔가 개발자와 조금 더 친해질 수 있고, 확실하게 커뮤니케이션 할 수 있는 방법을 일깨워 줍니다. 분명 그 개발자는 이 주석을 읽기 전까지 업무에 지쳐 있었을 것이고, 새로 받은 업무에 짜증이 나 있었을 것입니다. 하지만 동생의 주석 한 줄에 웃음이 났을 것이고, 썩 기분이 나쁘지만은 않았을 거라고 생각합니다. 어쩌면 웹표준에 대한 자신의 편견 내지는 오해에 대해서 미안해 했을수도 있었을테고, 신입으로 들어온 웹퍼블리셔(스터디 동생)의 열정에 깜짝 놀랐을 수도 있었을 것입니다.

물론 사이트를 오픈하면서 저 주석은 지워졌겠지만 적어도 그 개발자와 신입 웹퍼블리셔(스터디 동생)은 꽤나 친해졌고, 트러블 없이 프로젝트를 마쳤다는 이야기를 전해 들었습니다. 우리 옛 말에도 웃는 얼굴에 침 못 뱉는다고 했습니다. 매일 같이 야근과 철야를 반복하는 생활 속에서 주석 한 줄이 꽤나 중요한 협업 관계(더 나아가서 대인관계까지)를 유지해 주는 연결 고리가 될 수 있음을 알 수 있었습니다.



다음은 덧붙임 대신 팁 두가지를 적습니다.

1. 사이즈를 적어 주세요.
위 마크업에서 Map 과 GNB 영역에서 모두 자바스크립트를 이용해서 플래시 무비를 삽입하고 있는 것을 보실 수 있습니다. 그런데 Map 영역에서 기술된 주석은 사이즈를 함께 적어 주었고, GNB 영역에서는 그러지 않았습니다. 단번에 어떤 형태가 좀 더 주석 다운지 알 수 있습니다.

2. 영어로 쓰자.
종종 인코딩 문제로 인해 마크업 내의 한글이 깨져 보일 때가 있습니다. 에디터에서 인코딩을 맞춰주면 해결될 수 있습니다만 만약 당신의 에디터가 지원하지 한글을 제대로 지원하지 못한다면 마크업을 쉽게 분석하거나 수정할 수 없을 것입니다. 하지만 주석이 영문이었다면 큰 도움이 되지 않을까요?


며칠전에도 웹퍼블리셔에게 가장 필요한 능력으로 협업을 이야기했습니다. 신현석님의 의견 처럼 협업은 단순히 웹퍼블리셔들에게만 필요한 능력은 아닙니다. 어느 직업이든 둘 이상의 작업자가 함께 일하는 곳이라면 모두에게 필요한 능력입니다. 하지만 기왕에 (웹표준과 웹퍼블리셔에 대한 이야기를 담는) 이 블로그를 운영하면서 웹퍼블리셔들에게 협업적인 마인드와 능력을 조금 더 강조하고 싶습니다. 웹기획자나 웹디자이너 웹개발자들보다도 확실히 현재의 업무적인 위치에서 협업적인 능력이 크게 요구되는 직군이라고 생각하기 때문입니다. 또 한가지 최근에 웹퍼블리셔들에 대한 수요가 많이 높아지면서 웹표준 기술만 알면 몸 값을 올릴 수 있다라는 거품 섞인 분위기가 만들어지고 있는 것 같아서 환기를 시켜 보고자 협업에 대한 이야기를 강조해 봤습니다. 기술로써 몸 값을 올릴 수 있다면 협업을 잘 해내는 것도 아주 중요한 기술임을 말입니다.

끝으로 당신이 만약 웹퍼블리셔이고, 한참 프로젝트를 진행중이라면 다음과 같은 동료를 위한 주석 한 줄을 고민했으면 하고 바라겠습니다.

2009년 1월 9일 금요일

다음과 네이버의 파이어폭스 테마 은근히 다르네

지난해 10월 네이버가 파이어폭스용 테마(네이버 0.2.11.2)를 발표한 뒤 3개월 지난 며칠 전(09. 1. 6) 다음 역시도 테마(Daum Blue 0.1)를 발표했습니다. 각각의 테마가 녹색과 파란색으로 각사의 대표 색깔을 이용해서 제작되었고, 전체적인 느낌은 크게 다르지 않아 보입니다.

모질라 애드온 사이트에 등록된 양사의 테마 정보를 살펴보면 네이버는 "전문 디자이너들에 의해 가독성과 가시성을 고려하여 세심하게 디자인되었"고, "거의 모든 아이콘이 새롭게 그려졌"다고 소개하고 있습니다. 다음은 "간결하고 심플하고 시원한 색상과 아이콘을 가지고 있"다고 소개하고 있습니다.

실제로 캡쳐 화면을 비교해 보면 다음과 같습니다.
전체적인 느낌은 두 테마가 비슷합니다. 크게 네이버는 녹색으로 다음은 파란색으로 양사의 색깔을 모티브로 삼았다는 차이가 있는데 조금더 세세히 살펴보면 은근한 차이가 나타납니다.

네이버 테마는 녹색이 생각보다 강하게 드러나 보이는 경향이 있어 보입니다. 우측 상단에 검색창이(구글로 선택되어 있음에도) 네이버 검색이 연상되는 녹색 테두리가 선명하게 보입니다. 반면에 다음의 테마는 파란색으로 드러나게 하지 않았습니다. 네이버 따라하기라는 오해를 살 여지가 있기 때문이기도 했겠지만 다음 테마 발표 이전에 네이버 테마를 사용해 보면서도 영 눈에 거슬렸던 부분이었는데 다음 테마처럼 강조되지 않는 것이 웹페이지에 집중할 수 있는데 조금더 좋은것 같습니다. 마찬가지로 탭에 대한 강조도 네이버 테마는 녹색으로 강하게 나탑니다. 심지어 탭 하단의 라인에까지 녹색을 칠해 놨는데 확연히 '네이버'를 연상시키는 효과는 있지만 상대적으로 웹페이지(컨텐츠)로 집중되는 시선을 분산시키곤 했었습니다. 작지만 북마크릿 아이콘 역시 본래(일반적인)의 노란색이 좀 더 좋습니다.

뒤로가기, 앞으로가기 버튼은 반대로 다음의 테마가 네이버보다 더 강렬하게 표현을 하고 있습니다. 크기도 조금 더 큽니다. 하지만 이 부분에 대해서는 약간 입장이 다른데 파이어 폭스의 기본 테마 역시도 이 버튼들에 대해서는 다른 아이콘들에 비해서 상대적으로 크고 잘 보이도록 디자인했습니다. 이는 사용자들이 웹브라우저의 기능 중 가장 많이 사용하기 때문인데 저 역시도 좀 더 크고 선명하게 보이는 것이 마음에 들었습니다. 네이버 테마의 경우 둥근 디자인이 미려해 보이기는 하지만 크기가 타 아이콘들과 큰 차이가 없고, 녹색의 배색 영역도 다른 디자인 요소들에 비해 적어 눈에 덜 띄입니다.

설정 화면입니다. 아이콘과 버튼 디자인을 비교해 볼 수 있는데, 여기서는 다음 테마의 아이콘이 조금 더 작게 그려졌고, 네이버의 아이콘 디자인이 더 미려해 보인다고 느껴졌습니다. 버튼 역시 다음보다 네이버 테마의 버튼이 좀 더 가독성이 좋습니다.

웹브라우저는 웹 사이트를 접속하고 웹 컨텐츠를 읽기 위해서 만들어진 도구입니다. 그래서 제 생각에 테마는 사용자로 하여금 웹 컨텐츠에 집중할 수 있도록 도와주면서 스타일을 살려주는것이 가장 좋다는 생각입니다. 물론 정말 화려하고 심지어는 정신없는 테마도 많고 그런 테마를 좋아서 사용하는 사람도 많습니다. 테마는 어디까지나 자신의 취향에 따라 선택할 수 있는 것이니까 그것이 그르다고 볼 수는 없을 것입니다.

하지만 네이버와 다음 두 테마만 놓고 봤을 때 두 테마 모두 화려함 보다는 심플하면서도 현대적인 감각의 스타일을 살리기 위해서 디자인 되었고, 사용자 가독성 등을 최대한 고민하면서 만들어졌다고 여겨집니다. 그런 면에서 다음의 테마가 제 입장에서는 조금 더 웹브라우징 측면에서 성실해 보이며, 네이버 테마는 너무나 네이버같다는 인상을 조금은 줄여 주었으면 하는 아쉬움을 가져봤습니다.

2009년 1월 8일 목요일

PSD를 난도질해라

NETTUTSPSD를 난도질해라(Slice and Dice that PSD)라는 재밌는 동영상 강좌가 있어서 소개합니다.

단순히 이미지를 잘라내서 HTML을 만들고, CSS를 작성하는 과정이 아니라, PSD를 보면서 어떤 앨리먼트가 의미에 맞는지를 설명하면서 HTML을 마크업하고, 그에 맞는 CSS를 작성하는 과정을 차분하게 설명해 주고 있는 동영상입니다. 백문이불여일견이라고 웹표준에 대한 공부를 시작하는 입문자들에게는 참 괜찮은 예제가 될 것 같고, 중급자 이상이라도 외국의 경우 또는 다른 사람들은 어떻게 작업할까? 하고 궁금해 했던 분들에게는 좋은 자료가 될 수 있을것 같습니다.

Step 1: Writing the Markup

Step 2: Coding the CSS


스크린 캐스트 사이트 Viddyou에 가보면 NETTUTS의 여러가지 동영상 강좌를 추가로 보실 수 있습니다.


개인적으로 이런 동영상 강좌를 만들어보고 싶은 생각을 가지고 있었는데, 누가 고급 마이크를 선물해 주면 한번 고려해 봐야겠습니다^^;

드림위버에서 jQuery를 쉽게 쓰자

드림위버에서 jQuery를 쉽고, 빠르게 코딩할 수 있는 확장기능이 있어 소개해 드립니다. 코드 컬러링, 스니핏, 코드 힌트 등을 제공하고 있습니다.


지원하는 드림위버 버전은 다음과 같습니다.
- Dreamweaver CS3, 8, MX2004, and MX. Windows and Mac seem to work fine.

2009년 1월 7일 수요일

웹퍼블리셔에게 가장 중요한 것은 무엇일까?

그동안 본 블로그를 통해서 어떤 사람들이 웹퍼블리셔가 되는지, 웹퍼블리셔들은 어떤 일을 해야 하는지, 문서화의 중요성, 웹퍼블리셔들에게 필요한 가이드라인커뮤니티 사이트 소개, 어떻게 표준화를 지켜갈 것인지, UI개발자와 웹퍼블리셔라는 명명의 문제, 개발 프로세스(웹 개발 프로세스) 등 적지 않은 이야기들을 나름대로 풀어 놓았던 것 같다. 하지만 아직도 뭔가 부족한 것이 있다는 생각을 갖고 있었는데 며칠전 가까운 지인들을 만난 자리에서 한 친구가 중요한 사실 하나를 깨닫게 해주는 이야기를 들려 주었다.

협업은 함께 완성해 나가는 작업이다

어떤 분야든 사람은 혼자서 모든 일을 온전히 다 해내기란 쉽지 않다. 특히나 우리가 업으로 삼고 있는 IT. 그 중에서도 웹과 관련된 직종은 기술이 점차 발전하고 사용자의 욕구가 높아질 수록 디테일해지고, 세분화 되는 경향을 보인다. 웹퍼블리셔라는 직군만 해도 최근 몇년 사이에 새롭게 등장한 것이며, 근래에는 UI개발자, 마크업개발자, 자바스크립터, 웹퍼블리셔 등 업무의 범위에 따른 구분이 보다 심화되고 있는 실정이다. 하지만 여전히 큰 틀에서 바라보면 웹은 웹기획자와 웹디자이너, 웹개잘자 그리고 웹퍼블리셔(UI개발자)의 협업으로 완성된다. 내가 친구로부터 새삼 깨달은 것이 바로 이것이고, 지금 말하고 싶은 것이 바로 이것- 협업에 관한 것이다.

업계에서는 흔히 Co-work 이라고 부르는 이것은 사실 새삼스러울 것도 없고, 특별한 설명이 덧붙여지는 것도 아니다. 하나의 프로젝트를 위해서 각기 기술을 가진 이들이 서로 의견과 생각을 나누고, 업무를 나누며, 일사분란하게 일을 처리해서 완성해 나간다는 것인데 웹퍼블리셔에게 있어 이 협업이 다른 직군보다도 더 중요한 요소일 수 있다고 본다.

웹퍼블리셔 중심의 웹 표준 개발 프로세스

웹퍼블리셔 중심의 웹 표준 개발 프로세스

웹 개발 프로세스 에서도 언급했던 내용인데 웹 표준으로 진행되는 프로젝트의 경우 점차로 웹퍼블리셔의 역활이 중요해진다. 기획 단계에서부터 사이트 오픈과 이후의 유지보수까지 전 단계에 걸쳐 웹퍼블리셔는 빈 자리를 찾아 볼 수 없다. 기획자와 함께 스토리보드를 대신하는 구조적 HTML 문서(마크업)를 만들고, 웹디자이너와 웹접근성 관련 이슈들을 논의하면서 최적의 디자인 가이드라인을 만들어야 하며, 이에 맞는 적절한 CSS를 작성한다. 개발자와는 오픈 이후에도 웹표준을 준수하는 사이트를 위한 표준화 가이드라인을 제작하면서 검증 작업을 수행해야 한다. 오픈 이후의 유지보수를 통해서도 사이트의 웹표준 준수를 유지시켜야 할 책임도 가진다. 꽤나 부담스러울 수 있기는 하지만 그만큼 웹퍼블리셔에게 있어 다른 직군들과의 협업 문제가 중요함을 집어낼 수 있다.

그래서 웹퍼블리셔들에게는 대인 관계가 좋고 업무적으로 마찰을 줄이면서 효과적으로 협업을 이끌어 갈 수 있는  마음가짐 내지는 자세가 요구되고, 때때로 훌륭한 PM이나 팀장, 기획자들로부터 배울 수 있기도 하다.

경험적으로도 내부든 외부든 개발자들과의 소통이 원할하지 않아(대체로 개발자가 멍청하거나 무능력하다고 생각하면서- 또는 알면서도 게을러서 해주지 않는다고 생각하는-) 마무리 단계의 프로젝트가 산으로 가 버리는 경우가 많았다. 자신의 디자인에 자부심이 지나친 디자이너와 의견이 맞지 않아서 감정적으로 화가 나서 제대로 일을 처리해 주지 않았던 적도 있었다. 기획자는 또 어떤가! 훌륭한 기획자도 많지만 그렇지 않은 경우도 적지 않다. 그들과 일을 함께 할 때는 차라리 내가 기획을 하고 말겠다! 라는 전직의 희망(?)까지도 꿈틀대곤 했다. 이런 프로젝트는 분명히 엉망이 되어 버리곤 했다.

과거에는 기획자만이 디자이너와 개발자 그리고 클라이언트 사이를 오가며 온갖 원망과 모욕을 받아내며 버티곤 했다. 굳이 지금에 와서 웹퍼블리셔가 그 역활을 해야 한다는 것은 아니다. 앞으로의 웹퍼블리셔들에게 확실히 요구되는 것은 내 경험이나 지금 바로 현업에서 일을 하고 있는 웹퍼블리셔들이 이미 느끼고 있을 그것을 자신이 풀어야 한다는 것이다. 웹기획자와 웹디자이너 그리고 웹개발자. 조금 더 깊게는 클라이언트까지 충분한 지식과 경험으로 설득하고, 제안하며, 때로는 현실적으로 타협해 가면서 서로간의 업무가 단순히 기계적이지 않고 인간적으로 손을 맞잡고 함께 풀어가야 한다는 인식을 가져야 한다는 점이다.

HTML, CSS, JavaScript, DOM, Web Accessiblity 등 웹표준과 관련된 다양한 기술과 이론들을 충분히 배우고 알고 있더라도 협업에 대한 현실적인 마음가짐이 부족하다면 웹퍼블리셔로서의 당신은 충분한 자격이 없다고 봐야 할지도 모르겠다.




2009년 1월 5일 월요일

커뮤니티 사이트 질의답 게시판에 대한 고민

하드코딩하는 사람들(이하 하코사)이나 CSS Design Korea(이하 CDK), Mozilla Community는 한국 내에서 웹표준과 웹접근성을 비롯한 UX/UI를 중점으로 개설된 대표 커뮤니티 사이트다. 세 곳 모두 수천명이나 되는 회원수를 보유하고 있고, 하루에도 수십명씩 새로 가입을 하기도 한다. 인터넷 커뮤니티 사이트에 사람들이 이처럼 몰리는 이유는 정보를 얻기 위함도 있지만 모르는 것을 질문하고 해답을 찾기 위한 목적도 크다. 특히 이 분야의 입문자는 그 목적이 더더욱 크다고 할 수 있다. 하지만 하나의 커뮤니티를 몇개월 정도 지내다 보면 과거에 이미 올라왔던 질문과 대답이 재차 반복되는 경향을 쉽게 목격할 수 있고, 그런 글에는 제발 검색을 먼저 해달라는 당부의 댓글도 볼 수 있다.

하코사의 묻고답하기



필자의 경우에도 왜 검색을 먼저 해보지 않을까? 하고 의구심을 품었던 적이 있었다. 나 스스로는 질문을 올리기 전에 두번 세번 고민도 해보고 검색도 해보고 답을 찾기 어려운 경우에만 올려왔기 때문이다. 하지만 최근에 들어서 이런 생각에 약간 변화를 가지게 되었다.

커뮤니티는 두가지 측면에서 중요한 요소를 갖는데 규모와 깊이다. 규모는 얼마나 많은 회원수를 확보하는가 하는 것이고, 얼마나 많은 컨텐츠를 가지고 있는가이다. 깊이는 얼마나 많은 단골 회원(지속 가능한 회원)을 유지하고 있는가와 컨텐츠의 질적 깊이다.

이 두가지 측면을 확보하기 위해서 가장 중요한 서비스(게시판)이 바로 질문답 게시판이 될 수 있는데 여기에 딜레마가 있다. 검색을 통해서 이미 등록된 컨텐츠를 찾아 간다면 새로운 글은 그만큼 줄어들며 업데이트가 드믄 게시판은 새로운 컨텐츠의 등록에 심리적 장애 요소를 만들기 시작한다. 반면에 고민 없이 올린 글(컨텐츠)은 불필요하게 컨텐츠의 양만 늘릴 뿐 질적 향상은 크게 가져오지 못한다. 답변자들이 대부분 검색을 추천하는등 충실한 댓글을 달지 않는 경우가 많기 때문이다. 하지만 바꿔 생각하면 이미 몇차례 질문으로 올라왔던 글(컨텐츠)에 대해서 항상 같은 댓글이 달리지 않는 경우도 종종 볼 수 있다. 이것은 일종의 환기다. 자신이 이미 알고 있던 지식 또는 문제에 대해서 새로운 해결책이나 대안을 제시할 수 있는 기회가 생기는 것이다. 즉, 기 등록된 글 또는 컨텐츠라 하더라도 수개월이 지난 이후에 새로운 가입자(입문자)가 비슷한 글이나 질문을 올리더라도 거기에는 새로운 경험이나 노하우가 붙을 수 있는 것이고, 이것은 기존 회원들에게 새롭게 환기를 시켜주는 순기능을 보여줄 수 있다고 본다.

특히 하코사와 같이 게시판 형태의 까페의 경우 과거의 글은 순서대로 묻혀버리고 말기 때문에 검색 기능이 강력하다고 하더라도 일반적으로 새로운 글을 추가하는 것이 좀 더 쉽다고 느낀다. 때문에 일부러 검색을 추천(또는 종용)하지 않고 같은 내용의 글이라 하더라도 자연스럽게 올려지도록 유도하는 것이 더 나은 커뮤니티의 활성화 방법이 될 수 있을것 같다. 물론 CDK나 모질라 커뮤니티와 같이 과거 글에 새로운 댓글(의견)이 달리면 최근 글로 올라오는 구조라면 검색 기능을 이용하는 편이 훨씬 좋다고 본다.

하코사를 1년 넘게 활동하면서 묻고답하기 게시판이 몇개월에 한번씩 반복되는 글들로 채워지는 것을 보면서 느꼈전 부정적 시각에서 다소 발전적인 방법론으로 고쳐갈 수 있겠다라는 생각이 들어서 딱히 웹표준에 관련된 포스팅은 아니지만 적어 보았다. 특별히 국내에는 앞서 소개한 사이트 외에는 UX/UI와 관련된 커뮤니티가 적은데 앞으로 비슷하지만 나름의 색깔을 지닌 커뮤니티가 조금더 생겨서 더 많은 사람들에게 다양한 정보를 제공해 주었으면 하고 바란다.

2009년 1월 3일 토요일

em 계산을 쉽게 하세요

em은 폰트 크기의 상대적인 단위로 % 단위와 함께 많이 사용되고 있습니다. 하지만 px 단위와 달리 적용하기가 쉽지 않은데 px 단위를 em 단위로 쉽게 변화해 주는 사이트가 있어 소개해 드립니다.

PXtoEM.com 은 px 단위를 em 단위로 쉽게 계산해 줄 뿐 아니라 바로 사용할 수 있는 css로도 만들어 주고 있습니다. 아울러 Learn 메뉴를 통해서 em 단위에 대한 메뉴얼을 함께 제공하고 있어 em 단위에 대한 학습을 필요로 하는 사용자들에게 매우 유용한 사이트가 될 것 같습니다.

Body 폰트 크기를 고르거나, 직접 입력할 수 있습니다.

사용자가 설정한 크기로 CSS를 작성해줍니다.

em 단위에 대한 메뉴얼을 제공하고 있습니다.

[책] 실전 웹 표준 가이드(2005)

웹표준과 접근성에 대한 이슈가 커져가면서 다양한 가이드와 서적이 나오고 있습니다. 앞으로 몇차례에 걸처 추천할만한 책들을 소개해 볼까 합니다.

실전 웹 표준 가이드 다운로드 사이트

실전 웹 표준 가이드 다운로드 사이트


UI개발 업무를 시작하는 웹퍼블리셔나 개발자들이 커뮤니티에서 가장 많이 묻는 질문이 바로 입문서입니다. 파란책, 노란책, 초록책으로 불리는 에이콘 출판사의 웹표준 완전정복 세트도 굉장히 좋고, 추천 후보중 하나이지만 특별히 공짜로 구할 수 있는 '실전 웹 표준 가이드(2005)'를 가장 먼저 추천합니다.

실전 웹 표준 가이드는 국내에 웹표준에 대한 이슈가 막 일어나기 시작한 2005년에 한국소프트웨어진흥원을 통해서 발행된 PDF 형태의 공개 문서로 윤석찬, 신현석, 이성노, 신정식님 네 분이 공동 저술했습니다.

출판사를 통해 정식으로 발행된 것이 아니라 다소 오타와 문맥이 매끄럽지 못한 점이 흠이지만 번역서만 난무하는 국내 실정에 웹표준에 대한 배경과 필요성. 최소한의 기술 가이드와 참고 자료등을 두루 담아낸 문서가 나왔다는 것은 공동 저자 네 분의 노력과 열정이 아니었다면 쉽지 않은 일이라고 생각됩니다.

차례는 다음과 같습니다.
  • 웹 표준이란 무엇인가?
  • 실전 XHTML 가이드
    • XTHML 소개
    • XHTML 일반 문법 준수
    • 구조적 XHTML 사용 방법
  • 실전 CSS 레이아웃
    • CSS 개념 및 소개
    • CSS 레이아웃(LAYOUT) 기초
    • 실전 예제를 통한 CSS 레이아웃
    • 고급 CSS 레이 아웃
  • 실전 DOM/Script 가이드
    • W3C DOM vs. MS DOM
    • 표준 JAVASCRIPT 사용 방법
    • 올바른 플러그인(PLUGIN) 사용
  • 실전 표준 웹 프로그래밍
    • 표준 MIME 타입 설정
    • 표준 문자 인코딩 지정
  • 실전 웹 표준 개발 프로세스
    • 현재 프로세스 소개(Waterfall 방식)
    • 개선된 모델(퍼블리셔 중심)
    • 새로운 개발 프로세스
  • 맺음말
  • 부록 : 웹 표준 사양-브라우저 호환차트

여전히 주요 커뮤니티 Q&A 게시판에서 다뤄지는 다양한 이슈들에 대한 정리가 잘 되어 있습니다. 입문자에게 이 책을 추천하는 이유이기도 합니다. 게시판을 통해서도 알아낼 수 있는 지식들이긴 하지만 잘 정리된 문서는 불필요한 검색과 되풀이되는 질답을 피할 수 있는 길이기도 하며, 자신의 지식으로 습득하는데도 책(문서) 만한 것이 없다고 봅니다.

모질라 커뮤니티에는 실전 웹 표준 가이드외에도 Cross Browsing 가이드(2003), 웹 표준 기반 홈페이지 구축 가이드(2004)가 역시 PDF 문서로 무료 배포중에 있습니다.

1년 전에 처음 이 가이드를 읽은 뒤에 최근에 다시 한번 살펴보았는데 일부 최근의 경향이 반영되지 않은 것을 제외하면 모자람이 없는 문서이자 책입니다. PDF로 제공되고 있어 화면으로 읽기가 불편할 수 있지만, 두쪽 모아찍기로 출력을 한 뒤에 스프링 제본을 한다면 2,3만원짜리 책 못지 않습니다. 필자는 회사의 제본 서비스를 받아서 사진처럼 책으로 만들어서 보고 있습니다. 1년 전에 스프링 제본으로 만들어 둔 것도 있는데 그 역시 나쁘지 않아서 함께 두고 있습니다.

입문자라면 결코 싸지 않은 최근의 신간 도서들을 놓고 고민하지 말고 실전 웹 표준 가이드를 지금 바로 내려받아서 차근히 읽어보기를 추천해 봅니다.

덧붙임/ 공동 저자 네 분께서 여유가 되신다면 다시 한번 뭉치셔서 2판을 만들어 주셨으면 좋겠습니다. 오타와 문맥을 다듬고, 최근의 경향과 이슈들을 조금 더 붙인다면 좋지 않을까 하는 생각이 들었습니다.