1upz

BlackJack이 주머니에 들어온 이후로 지하철이나 버스에서도 RSS를 구독할 수 있게 되었습니다. 그렇다고 제가 항상 온라인에 접속해 있다는 것은 아니고요, 집이나 회사의 Wi-fi를 이용해 최신 글들을 미리 클립해 두었다가 이동시간 중에 틈틈히 확인하는 식으로 사용하고 있습니다. 아무리 3G망으로 접속할 수 환경이 마련되었다고 한들 그 비용이 후덜덜하기 때문이죠. 약간은 원시적인 방법입니다. 큿-

나름대로 이게 어디야~ 라며 만족하면서 사용하고 있습니다만, 역시나 불편한 점을 얘기하지 않을 수가 없습니다.
플래시? 동영상? 아직 이런 것 까지는 바라지도 않습니다. 하지만 이미지라면 얘기가 달라지죠.

지금은 News Break라는 어플리케이션을 사용하고 있는데 요놈은 페이지를 직접 열어야만 이미지를 불러오는 식이라서 온라인 상태가 아닐경우에 나타나는 이미지들은 모두 엑스박스로 나타납니다. 불필요한 패킷을 줄이기 위해 이렇게 설계가 된듯하지만 저의 사용 방식과는 궁합이 맞질 않아서 문제가 생기지요.

여기서 제가 하고 싶은 얘기는 프로그램이 못났다가 절대 아닙니다. 다만 컨텐츠를 생산하는 사용자들(e.g. 블로거)이 웹 접근성을 고려치 않고 제작한다 라는 점이 아쉬울 따름 입니다. 이게 뭔 뚱딴지 같은 소리냐면,

<img src="./ybody.jpg" />

이미지는 경우에 따라서 보일 수도 있고 안보일 수도 있다고 생각합니다만 단순히 이렇게만 작성된다면 그 이미지를 볼 수 없는 사용자들은 소외를 받게 되고, 서로의 소통에 문제가 생기게 됩니다. 어쩔 수 없이 그냥 그 곳에 어떠한 이미지가 있고, 문맥상 이러이러한 이미지가 들어갈 것이라고 추측만 하게 될 뿐이죠.
이미지가 안보이는데 그걸 어쩌라고요?

이미지 태그에는 대체 텍스트를(alternative text) 지정할 수 있는 속성이 있습니다. 엘리먼트 내에 alt="대체 텍스트 내용" 과 같은 방법으로 사용할 수가 있죠.

<img src="./ybody.jpg" alt="유재석의 근육" />

이미지를 볼 수 없는 환경이라도 이미지를 대신한 대체 텍스트를 볼수가 있어 내용을 이해하는데 많은 도움이 됩니다.

하지만 대부분의 사용자가 위지윅에디터를 사용하고 있고, 코드만 보면 울렁증을 호소하는 분들이 많기 때문에 이런 배려까지는 나에게는 무리 라고 생각하시는 분들도 계실 텐데, 다행히도 텍스트큐브(태터툴즈), 티스토리에는 이미지 옵션에 대체 텍스트 입력 칸이 존재합니다.

이미지를 본문에 추가하고 선택(본문에 삽입된 이미지 클릭)하면 우측에 대체 텍스트를 입력할 수 있는 항목이 나옵니다. 이 곳에 이미지를 대체할 수 있는 설명을 달아두면 대체 택스트를 쉽게 달수 있게 되는거죠.

일전에 어떤 사람이 '뭐 하러 귀찮게 이미지에 일일이 대체 텍스트를 달고 있는가?' 라고 물었던 적이 있는데, 확실히 그것은 잘못된 생각이라고 말하고 싶습니다. 단순히 눈에 보여지는 결과를 원한다면 이러한 노력은 삽질이 되고 말겠지만 시력이 불편하여 스크린 리더에 의지하며 인터넷을 사용하는 사람들이나 저처럼 이미지가 보이지 않는 환경에서 접속해 있는 사용자들의 입장을 헤아릴 수 있다면 그것만으로도 충분히 의미가 있는 일이니까요.

올블로그 상단에 보면 '블로고스피어는 지금' 이라는 섹션이 있습니다. 지금 블로고스피어에서 떠오르는 이슈가 무엇인지 한 눈에 파악할 수 있어 제일 먼저 눈길이 가게되는 항목이죠.

그런데 가끔은 이슈와 상관없는 생뚱맞은 제목이나 썸네일 이미지가 나타나곤 합니다.

이러한 현상이 생기는 이유는 버그나 시스템의 문제라기 보다 애당초 블로거가 글을 작성할 때 본문의 내용과 연관성 없는 잘못된 태깅에서 비롯된다고 볼 수 있는데, 아니나 다를까 피켜스케이터 김연아에 대한 포스트들 사이에 끼어 있는 엉뚱한 이미지를 클릭해보니 김연아와는 전혀 관련이 없는 '혼전 동거'에 대한 내용이 나왔고 그에 대한 태그들은 아래와 같았습니다.

<a href="/tag/4억소녀" rel="tag">4억소녀</a>,
<a href="/tag/골든디스크" rel="tag">골든디스크</a>,
<a href="/tag/국세청연말정산" rel="tag">국세청연말정산</a>,
<a href="/tag/김연아" rel="tag">김연아</a>,
<a href="/tag/나는전설이다" rel="tag">나는전설이다</a>,
<a href="/tag/놀러와" rel="tag">놀러와</a>,
<a href="/tag/뉴하트" rel="tag">뉴하트</a>,
<a href="/tag/다나카레나" rel="tag">다나카레나</a>,
<a href="/tag/못된사랑" rel="tag">못된사랑</a>,
<a href="/tag/브리스톨탐험대" rel="tag">브리스톨탐험대</a>,
<a href="/tag/빅뱅" rel="tag">빅뱅</a>,
<a href="/tag/색즉시공" rel="tag">색즉시공</a>,
<a href="/tag/성매매" rel="tag">성매매</a>,
<a href="/tag/소녀시대" rel="tag">소녀시대</a>,
<a href="/tag/소양증" rel="tag">소양증</a>,
<a href="/tag/소희" rel="tag">소희</a>,
<a href="/tag/송병구" rel="tag">송병구</a>,
<a href="/tag/슈퍼주니어" rel="tag">슈퍼주니어</a>,
<a href="/tag/아이비" rel="tag">아이비</a>,
<a href="/tag/엘소드" rel="tag">엘소드</a>,
<a href="/tag/오일볼" rel="tag">오일볼</a>,
<a href="/tag/웃찾사큰형님" rel="tag">웃찾사큰형님</a>,
<a href="/tag/원더걸스" rel="tag">원더걸스</a>,
<a href="/tag/윤도현의러브레" rel="tag">윤도현의러브레</a>,
<a href="/tag/조디포스터" rel="tag">조디포스터</a>,
<a href="/tag/크리스마스" rel="tag">크리스마스</a>,
<a href="/tag/태안자원봉사" rel="tag">태안자원봉사</a>,
<a href="/tag/한예슬" rel="tag">한예슬</a>,
<a href="/tag/허그데이" rel="tag">허그데이</a>,
<a href="/tag/헬게이트런던" rel="tag">헬게이트런던</a>,
<a href="/tag/황금나침반" rel="tag">황금나침반</a>

이런걸 두고 이뭐병이라 하던가요? 열거된 태그의 모양새를 보아하니 포털의 실시간 인기 검색어를 파싱해서 태깅한 것으로 추정이 됩니다. 그 사이에 김연아도 포함되어 있으니 올블로그에 나타나게 된 것이죠.

저렇게 이기적으로 태깅하는 사용자들은 욕먹어 마땅하지만 이러한 사람들은 분야를 막론하고 어디를 가든지 질긴 생명을 갖고 존재하기 때문에 구태여 얼굴을 붉힌다거나 계몽따위에 체력을 소모를 할 필요가 없습니다. '무시'가 최선!

그래도 올블로그와 같은 메타 사이트에서 불순한 목적의 포스트를 알아서 판별 해주는 기능이 마련되길 기대할 수 밖에 없는데 개인적으로는 인위적인 블라인드쪽으로 개선되기 보다는 구글의 Page Rank같은 느낌으로 블로그의 신뢰성(절대 인기 랭크가 아닙니다)을 판별할 수 있는 정도가 되길 바라고 있습니다.
신뢰도가 떨어지는 블로그일수록 그렇지 않은 블로그에 비해 정렬 순위가 낮아지게 되어 노출 횟수가 줄어들 것이고, 그렇게 되면 결국은 그들의 낚시질도 줄어들거라는 생각이 들거든요.

현실적으로 적용이 곤란한 부분들이 있겠지만 위와 같은 사례들이 빈번한 블로고스피어가 되지 않도록 뚜렷한 방책이 나와주길 바라는 마음에 글을 씁니다.

결론은 올블로그 화이팅~ 응? ^^;

Gmail과 Cyworld의 자잘한 버그들(이라고 하기에는 개인적으로 너무나 큰 버그들)이 고쳐졌습니다.

Gmail의 IMAP을 이용할 경우에 인코딩 오류로 한글이 깨지던 문제

여러가지 이유로 웹 메일을 고집해 오다가 최근 들어서 모질라의 썬더버드로 갈아 탔습니다. 그 시기와 비슷하게 Gmail에서 IMAP 서비스를 내놓았었는데요, 어찌된 영문인지 대부분의 한글 메일이 깨진 상태로 전송이 되어 내용을 알 수가 없더군요.

사실 이쯤 되면 Email의 구실을 할 수가 없으니 IMAP이고 뭐고 때려 쳐야 정상입니다만, 별다른 불편 없이 계속해서 사용해 왔습니다. 이유인즉슨 희안하게도 광고메일들은 전부 깨지고, 개인적으로 전달되는 메일들은 말짱하더라고요. 나름대로 필터링 기능이라 받아들였었죠. 그런데 어느 순간부터 광고의 글들이 하나 둘 보이기 시작하더니 깨진 메일이 없다는 것을 인식하게 됐습니다.
아무래도 고쳐진것이 아닐까 하는 느낌이..

Cywold 클럽 게시판을 파이어폭스로 사용할 경우 브라우저의 Back 버튼이 적용되지 않았던 문제

개인적으로 Cyworld는 자주 사용하지 않아 왕래할 일이 드믈었었는데 최근 위자드웍스에서 모집한 호그와트 마법학교 대학생 마케터들의 파릇파릇한 모습(?)을 염탐하기 위해 클럽을 종종 접속해왔습니다. 큭=_=)

살짝 이성을 잃은 체 게시판의 글을 열람해보고, 뒤로가기 버튼을 누르니.. 무 반 응.
'응? 그래, 나는 파이어폭스를 쓰고 있고, 여기는 싸이월드...'
화도 안나고, 바라는 것도 없어요. 그냥 있는 그대로를 받아 들이고 있었습니다.

그런데 오늘 나도 모르게 습관적으로 뒤로가기 버튼을 눌렀는데, 뒤로 가데요? 뭐죠? 설마 업데이트 된건가요? 파이어폭스가 설치되어있지 않을텐데 설마 설마?
정말 기대하는 마음을 갖고 쪽찌 하나를 삭제 해 보기로 했습니다.

두근두근두근두근.....앗. 변함 없군요. &^%#@!%*&^%

em의 필요성

일반적으로 폰트의 크기를 지정하기 위해서 px, 혹은 pt 와 같은 단위를 습관적으로 사용 해 왔습니다만 Screen display의 경우에는 플랫폼간의 부조화나 브라우저에서 폰트 사이즈를 인위적으로 조절하는 것이 불가능한 경우가 생기기 때문에 이를 지양하고 em 과 같은 상대 단위를 사용하는 것이 좋습니다.

em의 크기는 어떻게 가늠하는가.

em은 대문자 M의 폭을 기준으로 그 사이즈가 정해지는 상대적 단위이기 때문에 원하는 크기를 지정하기 위해서는 상위 엘리먼트로 거슬러 올라가야 합니다. 마치 부모와 자식과의 관계처럼 자식은 부모에게 영향을 받는 속성을 갖고 있죠.

/* CSS */
#parent {
  font-size:20px;
  }

<!-- HTML -->
<div id="parent">
  <div id="child">Who Am I?</div>
</div>

위의 예(이해를 돕기 위해 px 단위를 사용 했습니다)를 보면, Who Am I? 의 기본 크기는 별다른 지정이 없으므로 20px로 표현이 됩니다. 만약 child 엘리먼트의 폰트 사이즈를 1em으로 지정 했을 경우 Who Am I?는 parent의 100% 크기인 20px로 나타나고, child가 2em 라면 40px, 0.5em 라면 10px로 나타나게 되는 형식이 em의 원리 입니다.

처음 크기는 무엇으로 결정 되나?

앞서 얘기 한데로 em은 상대적 단위 이기 때문에 상위 엘리먼트의 값을 참조하게 됩니다. body 그리고 html까지 올라가서 그 값을 참조하게 되는 것이죠. 그렇다면 최상위 엘리먼트는 무엇을 참조하게 될까요? 네, 브라우저의 설정 값을 참조하게 됩니다. 바꿔 얘기하자면 브라우저의 설정 값을 변경하면 페이지의 폰트 크기들을 조절할 수 있게 되는 겁니다. (참고로 Opera나 IE7의 경우에는 줌 브라우징이 가능하고 Fire Fox는 절대 단위 폰트들도 resizing이 가능하므로 em은 IE6를 위한 선택이라 해도 과언이 아닙니다.)

일반적으로 브라우저의 기본 크기는 12pt (16px)로 설정 되어 있기 때문에 12pt를 기준으로 페이지 전체를 디자인 해야 하고, 또한 기본 설정의 변경에 따라 변화되는 모습을 융통성 있게 제작하는 것이 무엇보다 중요 합니다.

Resizing bug in IE6

em을 사용하여 텍스트 크기 조절이 가능토록 디자인 해야 하는 주된 이유는 사용자 편의성에 있습니다. 만일 시력이 좋지 않은 사용자라면 작은 글씨로 된 텍스트는 읽을 수가 없으므로 이를 적당히 키워 읽기 편하도록 만들자는 것이 그 목적 이죠. 그런데 단순히 em의 사용만으로는 IE6 에서 확대/축소율의 문제점이 발생합니다. 폰트가 지나치게 커지거나 지나치게 작아져서 오히려 더욱 불편해 지는 문제 입니다.
파이어폭스의 모습과 비교한 아래 이미지를 보시면 그 차이를 느끼실 수 있을 겁니다.

이 문제는 최상위 엘리먼트의 폰트 사이즈 단위를 %로 지정하여 간단히 해결할 수 있습니다. 만약 font-size를 body부터 시작 했다면 html을 추가해 % 값을 지정해 주십시오.

html {
  font-size:100%;
  }

폰트의 크기를 브라우저 기본값의 100%로 보여주라는 코드라 이론상으로는 아무런 의미가 없지만 사이즈의 근본을 em이 아닌 %로 우회하여 IE에서도 확대, 축소의 비율을 적당하게 적용 시킬 수 있도록 한다는 원리 입니다.

만일 html 에 이미 폰트 사이즈를 지정했거나 html이 아닌 다른 곳에 %를 지정하고 싶다면 폰트가 지정된 최 상위 엘리먼트(보통은 body가 되겠죠)의 수치와 단위를 em 에서 %로 변경 해 주시면 됩니다.

body {
  font:75%/1.6 'Trebuchet MS', Helvetica, sans-serif;
  }

그 밖의 문제

IE에서 하이퍼링크를 클릭할 경우 본문의 텍스트 크기가 순식간에 줄어들거나 커지는 증상도 앞서 얘기한 것처럼 최상위 단위를 %로 지정해 줌으로써 해결이 가능할 것 같습니다. 그렇지만 확실한 것은 아니고, 어디까지나 추측일 뿐인데, 일단은 제 환경에서는 재현이 되지 않기 때문에 혹시라도 이런 증상이 나타나시는 분은 테스트를 부탁 드립니다.

블로그를 사용하지 않는 사람들로부터 가끔씩 듣는 얘기 중에 하나가 ‘어렵다’ 라는 말 입니다. 그 이유를 가만히 생각 해 보니 블로그의 낯선 용어도 한 몫을 하고 있을 거라 판단 하여 블로그 웹사이트들을 둘러 보기로 했습니다.
재밌게도 Comment 와 Trackback 을 표기하는 명칭이 각기 다르더군요.

Comment

Comment는 본문(Post)를 읽고 그에 대한 의견을 남기는 기능 입니다.
이에 대한 번역은 주로 '덧글' 과 '댓글'이라는 명칭으로 나뉘는데, 덧글은 '본문에 덧붙이는 글' 이라는 의미, 댓글은 '본문에 대는 글' 이라는 의미를 갖고 있습니다. 댓글은 짧은 의견을 달아 둘 때 사용된다고 얘기 하거나 Reply로 해석하하며 덧글과 댓글을 분류하는 사람도 있지만 이 둘은 의미상으로는 비슷합니다. (국립국어원 2004년 신어로 수록 되면서 덧글과 댓글은 동의어라고 지정 해 두긴 했네요.)

여기서 문제가 되는 명칭은 다름 아닌 '답(答)글' 입니다.
답글은 Reply 즉, '응답, 대답하다' 라는 의미 입니다. 본문에 대한 응답을 남기는 것이므로 틀린 명칭이 아니라고 지적할 수 있겠지만 답글은 E-mail 이나, 흔히 사용하는 인터넷 게시판의 답글처럼 기능적으로 원본 글과 동등한 위치를 가질 수 있어야 합니다. 더욱이 'Comment 에 대한 답변' 기능과 의미가 겹쳐 혼란을 발생 시키는 요인이 되므로 '덧글'이나 '댓글'로 고쳐 사용하는 것이 좋다고 생각 합니다.

Trackback

Trackback은 Comment의 확장개념으로써 원본 Post에 대한 의견을 자신의 블로그에 등록하고 이를 원본 Post에 ping으로 남기는 기능으로, '엮인글', '참조글', '관련글', '먼댓글' 등으로 해석하여 불려지고 있습니다. Trackback 이란 의미를 우리 말로 해석하기에는 난해한 부분이 없지 않지만 엮인글이나 먼댓글과 같이 단어의 의미를 보고 어느정도 추론이 가능하도록 잘 지어진 명칭이 있는 반면에 참조글, 관련글 처럼 그 의미를 잘못 해석 할 수 있는 단어들은 다시 한번 생각 해 봐야 합니다.
참조글은 '참조한 글' 이라는 의미로 마치 논문의 참고문헌처럼 리스트에 열거된 블로그들의 내용을 인용하거나 도움을 받았다는 느낌이 강해 Trackback의 의미와는 사뭇 다르게 받아 드릴 수 있고, 관련글의 경우에는 본문의 내용와 비슷한 성격의 포스트들을 뽑아 포스트 하단에 출력하는 '관련 포스트' 기능과 의미가 겹치기 때문에 사용자로 하여금 혼란스러움을 유발시키는 요인이 될 수 있으므로 이 둘의 명칭을 '엮인글' 정도로 바꾸는 것이 좋습니다.

한글의 사용도 중요 하지만 이처럼 소통에 문제가 생기는 명칭의 사용은 오히려 사용하지 아니 한 것만 못할 수 있있으니. 올바른 의미와 용어의 통일로 블로그를 처음 접하는 사람들에게도 보다 쉽게 접근할 수 있도록 만드는게 중요할 것입니다.

이제는 이런 얘기를 하는 것 자체가 지겹기도 하지만 하도 답답해서 글을 남깁니다. 파이어폭스를 통해 야후 코리아 10주년 To You 캠페인 사이트를 접속해보면 오도방정 난리를 치는 모습을 확인 하실 수 있습니다. 사이트 전체가 비트에 맞춰 쿵 짝짝 들썩이니 캡춰조차 염두가 나질 않는군요. 물론 오페라, 사파리 등 에서도 요동을 치고 있고, 오로지 인터넷 익스플로러에서만 무슨 일이 있냐는 듯이 태연하게 돌아가고 있을 뿐 입니다. 확인을 해 보니 Flash 9 미만의 버전에서 스톱 액션이 오동작을 일으키는 것 같습니다. 이건 뭐 천리안 로그인 폼이 승천하는 모습보다 더욱 심각한 증상 이네요.

파이어폭스를 다운받고 설치하는데 오래 걸려봤자 5분이 체 걸리지 않을텐데 이 모습을 보고 있으니 야후 코리아에는 QA팀이란게 아예 없는 것은 아닐까 생각이 들기도 하고, 아니면 비 주류 브라우저 이용자들의 점유율이 7%도 안된다고 이를 무시 하는 것은 아닐까 생각이 들기도 하고, 그것도 아니라면 알고 있으면서 게으름을 피우고 있을지도 모른다는 생각을 정확히 2분 동안, 아주 심각하게 생각을 해 봤습니다.

DTD은 왜 작성해야 하나

DTD은 브라우저의 랜더링 모드를 지정해주고 유효성 검증기(Validator)의 기준이 되므로 (X)HTML 문서의 상단에 반드시 선언 해 주어야 합니다. 만일 DTD를 생략하거나 형식이 잘못된 문서일 경우에는 웹 브라우저마다 코드의 해석 방식이 다른 Quirks mode로 랜더링이 되기 때문에 엉뚱한 결과물로 출력되는 문제에 직면하게 됩니다.

DTD의 종류

웹 페이지에서 주로 사용하는 HTML 4.01 과 XHTML 1.0에는(2007년 기준) 각각 Strict, Transitional, Frameset 의 3가지 DTD가 있습니다. (XHTML1.1에서는 Transitional 과 Frameset은 파기되고 Strict 기반으로 재구성 되었습니다.)

HTML 4.01

HTML 4.01 Strict DTD

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01 Transitional DTD

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01 Frameset DTD

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" 
http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0

XHTML 1.0 Strict DTD

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Transitional DTD

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Frameset DTD

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1

XHTML 1.1 DTD

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

어떤 DTD를 선택해야 하는가?

XHTML은 데이터의 표현(Presentation)에 초점이 맞춰져 있는 HTML의 문제점을 개선하기 위해서 XML방식으로 구현한 언어이기 때문에 약간의 문법적인 차이를 제외하고는 HTML과 크게 다르지 않습니다. 하지만 XML 을 기반으로 만들어 졌으므로 이 둘의 차이점을 이해하지 못헸거나 기존의 웹사이트가 HTML 기반으로 제작되어 있다면 무리하게 XHTML을 고집할 필요는 없겠죠.

무엇보다 중요한 것은 Transitional DTD와 Strict DTD 타입의 선택 입니다. W3C는 CSS를 장려하기 위해 표현을 위한 태그를 엄격히 배제한 Strict DTD를 권고하고 있습니다만 기존의 수많은 웹사이트들을 한 순간에 변화 시킬 수는 없으므로 호환성 유지를 위해 과도기적 성질인 Transitional DTD를 사용할 수도 있도록 배려했습니다. 다시 말해서 (X)HTML과 CSS의 분리가 완벽히 이뤄 지느냐 그렇지 않느냐에 따라서 DTD를 정할 수 있다는 것이죠. 만약 (X)HTML 내에 표현을 위한 요소를 CSS로 분리가 된다면 Strict DTD를, 그럴 수 없는 환경이라면 Transitional DTD를 지정하시면 됩니다.

웹 표준은 XHTML?

웹 표준과 시멘틱한 웹사이트를 위해서는 XHTML 사용을 해야 한다는 말이 있지만 그 말은 사실이 아닙니다. XHTML 1.0 Transitional 보다는 HTML4.01 Strict의 규격이 구조와 표현을 더욱 엄격하게 구분 짓고 있으므로 무조건 XHTML이라는 말은 잘못 되었다고 볼 수가 있는 거죠. 고로 HTML이냐 XHTML이냐의 선택 보다는 제작하려는 사이트의 방향과 목적을 제대로 파악하고 그에 걸맞은 DTD 선택이 더욱 중요할 것입니다.

이번 학기에 수강하고 있는 웹 디자인 수업은 테크니컬 적인 내용은 배제하고 인터렉티브를 기반으로 한 디자인을 다루고 있습니다.

Interact는 '상호적인(Inter)' 이라는 단어와 '활동, 작용(Act)'을 뜻하는 단어의 합성어로 '상호 작용하다', '서로 영향을 끼치다' 라고 풀이되는데, 상호적으로 작용한다는 의미는 일방적인 활동으로 그치는 것이 아니고 작용에 대한 반응(React)과, 또 반응으로 인해 새로운 행동 반응이 연거푸 일어나는 작용이라 할 수 있습니다. 이해를 돕기 위해 한가지 예를 들자면, 앞에 있는 놈을 한대 쥐어 박았을 경우 그것으로 끝나는 것이 아니라 그 놈의 머리에서 혹이 나고, 눈물을 흘리며 나에게 주먹질을 해오는 이러한 작용과 반응이 인터렉티브라 할 수 있겠죠.

그렇다면 웹사이트에서 가장 기본적인 인터렉티브는 무엇이 있을까요?

a {text-decoration:underline;}
a:link {color:#09c;}
a:visited {color:#906;}
a:hover {font-weight:bold; color:#0c3;}
a:active {color:#c00;}
a:focus {background-color:#eee;}

네, 저는 a 태그의 가상 클래스 라고 생각 합니다. 링크를 확인하고, 마우스를 올리고, 클릭하는 행위가 이뤄지는 부분이죠.

위와 같은 평범한 링크 스타일로도 충분히 상호작용이 일어나지만 일반적으로 mouse over 에 대한 반응에만 신경을 쓰고 있지, 클릭에 대한 반응은 생략하는 경우가 많아 클릭했을 경우의 스타일을 생각 해 봤습니다.

a 태그를 간단하게 버튼 모양으로 만들어 보도록 하겠습니다. 예제 보기

a {
    display:block;
    width:8em;
    padding:.5em 0;
    background-color:#eee;
    font-size:1em;
    text-align:center;
    text-decoration:none;
    border:1px solid #ddd;
    border-width:0 1px 1px 0;
    }

a:link, a:visited {
    color:#000;
    }

a:hover {
    color:#c06;
    }

a:active {
    position:relative;
    top:1px;
    left:1px;
    background-color:#e3e3e3;
    color:#f39;
    }

active 클래스에 position을 relative로 설정하고 위치를 위쪽, 왼쪽에서 각각 1px씩 이동하라고 지정해 뒀습니다. 링크를 클릭하는 순간 마치 버튼을 클릭 한 것과 같은 시각적 효과를 보여줌으로써 자신이 클릭했다는 사실을 눈으로 확인 할 수 있게 되는 것이죠. 클릭과 그 작용에 대한 시각적인 반응, 즉 인터렉트가 일어나는 것입니다.

물론 페이지 이동은 짧은 순간에 이뤄지고 마우스의 커서도 자동으로 바뀌거나 시스템에 따라서는 효과음도 출력되기 때문에 굳이 이러한 노력을 들이지 않더라도 클릭에 대한 반응을 인지할 수는 있습니다만 CSS를 응용하여 좀 더 멋지고 쉬운 인터렉티브 디자인을 만들어내는 것은 디자이너로서 상당히 매력있고 의미있는 일 이라 생각 합니다.

웹디자인 수업시간에 플래시를 간단하게 사용하여 나를 표현 하라는 과제를 내주었습니다. 재미있는 주제 입니다만, 굳어버린 머리로는 나를 표현할 수 있는 소제가 슈퍼마리오의 1UP버섯 밖에 생각이 나지 않더라고요.

만들고 보니 재미도 없고, '버섯 이라도 다 똑같은 버섯은 아니다', '1UP은 유일하다' 라는 다소 거만한 메시지를 갖고 있어서 이번 주 수업시간에 뭇매를 맞는 사태가 벌어질지도 모르겠습니다. 컹-