페이지오프: css

레이블이 css인 게시물을 표시합니다. 모든 게시물 표시

2010년 4월 29일 목요일

CSS의 창시자 호콘 비움 리에(Opera Software CTO) 방한 세미나

Håkon Wium Lie 에게 웹 표준 기술의 과거, 현재, 미래를 묻다!

오페라 소프트웨어 CTO로 있는 호콘 리움 리에(Håkon Wium Lie)가 방한하여 세미나를 갖습니다. 그는 CSS를 창시한 사람으로도 유명한데요. 이번 방한을 통해 CSS의 창시와 최신 웹 표준이라는 주제로 발표를 합니다. 그리고 신현석님께서 '한국의 웹 표준'이라는 주제로 국내 웹 개발자, 정부에서 추진하고 있는 웹 표준 활동에 대한 이야기를 들려 주실 예정입니다.

50명 정원으로 신청을 받고 있는데 아직은 자리가 남았지만 금방 찰 것 같습니다. 꼭 참석하시고 싶으신 분들은 바로 신청하세요~!

2010년 3월 31일 수요일

클리어보스 기술 세미나#1 - 표준과 접근성의 재확인

만우절입니다. 하지만 거짓말은 아니구요. 클리어보스가 웹퍼블리셔 오리엔테이션과 함께 2010년부터 새로 준비한 세미나인 웹퍼블리셔 기술 세미나 첫번째 행사를 오는 4월 10일 마련했습니다.

이번 기술 세미나의 개요는 아래와 같습니다.

제목 : 웹퍼블리셔 기술 세미나 #1 - 표준과 접근성의 재확인
강사 : 서정민
주최 : 클리어보스
일시 : 2010년 4월 10일 토요일 오후 2시 ~ 6시 1시 40분까지 입실 부탁드립니다.
장소 : 숭실대학교 정보과학관 501호 (이인석(inska)님께서 장소 지원에 도움 주셨습니다. 감사합니다.)
대상 : 총 30명 - 경력 1년차 이상 동종 업종 전직 경력 미포함. 퍼블리셔 경력만으로
진행 및 도움 : 루트박스외 3명
참석비 : 무료
- 무작정 신청만 하시고 연락없이 불참하시면 차기 세미나 진행시 불이익이 있을 수 있습니다.
- 뒷풀이 비용은 별도 입니다. (참석 인원에 따라 변동됩니다.)
연락 : 장기웅(루트박스) master@rootbox.co.kr

웹퍼블리셔 오리엔테이션이 신입 및 입문자를 대상으로 하는 오리엔테이션 행사라면, 기술 세미나는 경력 1년 이상을 대상으로 하는 실무 중심의 세미나입니다. 이번 행사 준비는 장기웅님이 준비를 해 주셨구요. 이인석(인스카)님께서 장소에 도움을 주셨습니다.

많은 관심과 참여 부탁드립니다.

신청은 여기에서 해 주시면 됩니다.

2010년 1월 7일 목요일

2010/1-2주차 클리어보스 소식

2010년 첫번째 클리어보스 소식입니다.

최근에는 어떤 주제를 던져놓고, 투표(설문)와 의견 나눔을 통해서 글을 이끌어 가보고자 하고 있습니다. 개인 블로그에 쓰듯 단지 저만의 생각과 주장을 적다 보면, 다른 분들의 생각을 충분하게 공유하지 못하는 한계가 있었던것 같아서 이런 방법을 연습해 보고 있습니다. 클리어보스는 저 '개인'만의 공간이 아닌만큼 다양한 주제와 참여를 이끄는 공간으로 만들어볼까 합니다. 그래서 2010년 첫주와 둘째주에는 투표를 통한 설문글이 많았습니다.

주소를 address 요소로 마크업하지 말라?

- HTML5Doctor 에 올라온 글을 번역한 것입니다. address 요소를 적절하게 마크업하는 것에 대해서 고민할 기회를 주기에 번역해서 올려봤습니다.

FAQ의 의미 있는 마크업은?
- FAQ는 일반적인 웹 사이트 제작시 자주 등장하는 콘텐츠입니다. 대부분 DL 요소를 많이 사용하는데, DL 이외의 방법은 없는지 있다면 다른 사람들은 어떤 마크업을 사용하고 있는지에 대한 설문입니다. 현재 진행중입니다. 많은 참여 부탁드립니다.

웹 타이포그래피
- 오페라 웹표준 강좌중 11번째 내용입니다. 웹에서 사용되는 글꼴에 대한 주제로 웹 디자이너 분들께 특히 추천드리는 내용입니다.

어떤 직함이 좋은가?
웹퍼블리셔, UI개발자, 마크업 개발자 등 다양한 이름에 대한 선호도 조사입니다. 1월 2일 현재까지 결과는 UI개발자가 40%로 가장 많은 분들이 선호하고 있음을 알 수 있었습니다. 설문은 당분간 계속할 예정이니 아직 참여하지 않으신 분들은 한 번씩 선택해 주시고, 의견도 남겨주세요.

웹 퍼블리셔의 작업중 가장 오래 걸리는 것은?
- 역시 설문조사입니다. 마크업과 스타일시트, 자바스크립트 등 실무에서 가장 작업 시간이 긴 직무를 선택하는 설문입니다. 대체로 비슷한 결과를 보이고 있습니다. 역시 당분간 계속됩니다.

2010년 1월 6일 수요일

웹 퍼블리셔세요?

클리어보스에서는 지난해 2월과 9월 경력이 1년이 못되는 서른명 정도의 분들을 모시고 '웹 퍼블리셔 오리엔테이션'이라는 자리를 가졌었습니다. 그리고 여름과 겨울에 가볍게 오프라인 모임을 갖기도 했었구요. 그 외에도 몇 차례 술자를 통해서 인사를 나눴던 분들도 계셨습니다.

첫 인사를 나누고 나면 으레 디자인을 하시는지 개발을 하시는지 업무를 묻곤 하게 되는데요. 아무래도 자리가 자리이니 만큼 짐짓 '웹 퍼블리셔'이겠지 하면서 "웹 퍼블리셔세요?"라고 질문을 해 봅니다. 그런데 의외로 적지 않은 분들이 머뭇거리시면서 "그게요... 아직은..."이라는 식으로 말 끝을 흐리곤 하시더라구요.

왜 그러셨을까요? 조금 더 이야기를 나누다 보면 저와 하는 일이 거의 같았습니다. HTML과 CSS를 주로 다루고, 자바스크립트를 너무 어려워 하지만 조금씩 공부하면서 적용해 가고 있다구요. 그럼 저는 "아 그럼 웹 퍼블리셔네요~"라면서 "왜 어려워하세요?"라고 되 묻곤 합니다.

그 분들은 웹 퍼블리셔라는 이름에 대한 부담을 갖고 계셨어요. 그리 먼 과거도 아닌 불과 몇 해 전까지만 해도 우리들 같은 사람들을 주로 HTML 코더라고 불려졌고, 그렇게 알아 왔습니다. 하지만 신현석님께서 보다 넓고, 깊은 의미로 직업적인 사명감과 자부심을 갖고자 '웹 퍼블리셔'라는 이름을 제안하셨습니다. 그리고 여러 사람들이 호응을 했고, 지금은 적잖은 곳에서 '웹 퍼블리셔'라는 직함을 사용하고 있지요. 그런데 비슷한 일을 하는데 어떤 회사는 'UI개발자' 누구는 '마크업 개발자' 어디는 계속 '코더'라고 불리고 있다 보니 혼란스러워들 하시더라구요.

웹 퍼블리셔라는 이름은 버겁고, UI개발자나 마크업 개발자, 프론트 앤드 개발자... 같은 여러 이름은 자신의 정체성을 더욱 모호하게 만드는 것 같고... 그렇지 않나 생각해 봅니다.

일단, 왜 '웹 퍼블리셔'라는 이름이 버겁다고 느껴질까요? 제 짧은 생각으로는 직함이 요구하는 전문성의 범위가 생각보다 넓기 때문입니다. HTML을 단지 기계적으로 작성하는 것이 아니라 논리적으로 판단하고, 의미 있게 작성할 수 있어야 하고, 표준에 맞도록 마크업 해야 한다는 것. 물론 CSS도 경제적이고 효율적으로 작성하고, 브라우저간 상호 운용성을 확보할 수 있어야겠죠. 핵은 지양하면서 말이죠. 거기에 웹 접근성 향상을 위한 심리적 부담감과 쉽지 않은 법률과 가이드라인. 거기에 단기간에 상승된 회사내의 입지. 웹 표준과 웹 접근성 이슈는 모두 '우리'에게 전담되어버린 듯 한 상황은 어지간한 경력자라 하더라도 쉽게 감내하기 어려울 수 있다고 봅니다. 사람마다 차이는 있겠지만 상당한 부담감이 될 수 있을것 같습니다. 그렇다 보니 '나는 아직 웹 퍼블리셔는 아니고, 코더다.'라는 생각을 갖게 되고, 족보 없는 가계도가 그려지곤 합니다. 코더를 하다가 웹 표준 좀 하면 웹 퍼블리셔, 그리고 자바스크립트를 조금 다룰 수 있게 되면 UI개발자. 로 말이지요.

지금 클리어보스에서 'HTML, CSS, JS 등을 주로 다루면서 사용자 화면을 설계하는 당신은 어떤 직함이 가장 좋습니까'라는 간단한(?) 설문조사를 진행하고 있습니다. 한 사흘 정도 진행되었는데 UI개발자가 37명으로 가장 많은 분이 택해 주셨고, 웹 퍼블리셔는 20명이 23%, 프론트 앤드 개발자가 13명으로 15%를 차지했습니다. 전체 결과를 보고 싶으시거나 설문에 참여하고 싶으신 분들은 클리어보스를 찾아주세요.

사실 설문의 결과는 그다지 중요하지 않을 수도 있습니다. 특별히 공신력이 있는 사이트도 설문 조사 방식도 아니니까요. 1위 결과를 모두 함께 사용하자라는 캠페인을 벌일 생각은 아예 없구요. 중요한 건 두가지 정도일 것 같습니다. 하나는 지금 이런 고민을 하는 순간이 과도기적 상황이라는 것이구요. 또 하나는 어떤 이름이 중요한 것이 아니라 스스로 자신의 일을 정의하고, 자부심을 갖느냐하는 점이라고 생각합니다. 최근 몇 년 동안 여러가지 상황들이 빠르게 변하면서 '코더'라는 직군이 급 부상한 상황에서 자리를 잡아가고 있다고 생각하구요. 이것은 앞으로도 몇 년은 더 지나야 조금 더 명확한 직무 범위나 가이드라인이 만들어질 것이라고 생각합니다. 그리고 두번째에 대해서 얼마전에 신현석님도 '웹 퍼블리셔의 업무범위'라는 글을 통해서 적으셨지만 우리들이 어떤 이름으로 불리는건 그렇게 중요한 것이 아닙니다. 첫번째 이유를 들어 시간이 정리를 해 줄 것입니다.(물론 그 시간 동안에 여러 사람들의 자발적인 노력과 행동들도 있을 겁니다.) 스스로 한계를 긋고 울타리를 좁게 만드는 것이 문제지요. 어떤 직군이나 자기계발은 언제나 요구되는 덕목입니다. 개발자나 디자이너, 기획자들 모두 다 그렇게 계속 공부하고, 연습하면서 자신의 직무 범위를 넓히고, 깊게 해 나갑니다. 우리도 그래야 한다는 것이지요. 자바스크립트를 어느 정도까지 해야 하는가를 고민하기 보다 일단 시작하시고 할 수 있을 만큼 계속해서 하시는 것이 좋습니다. HTML, CSS, JS, XML, SEO, 표준, 접근성, 시멘틱, 디자인, 도구, UI, UX... 이렇게 나열된 직무 갯수에 지레 겁먹지 마시길 바랍니다. 저도 위에 나열된 것중 어느것 하나 확실하게 잘 하는 것은 없습니다. 걱정하고 계시는 여러분과 크게 다르지 않은 것이지요. 어제도 HTML 공부를 했고, 오늘도 해야 합니다.

어떻게 보면 이런 논의나 설문 자체가 소모적인 논쟁이고, 답이 나지 않는 것일 수 있습니다. 하지만 고민하지 않고 넘기다 보면 나중에는 자신의 의지와 상관없이 큰 흐름에 그저 쓸려 다니기만 하기 쉽습니다.

나 스스로 고민해 보지 않으면 내 것이 되지 않는다. 그게 제 생각입니다.

2009년 12월 21일 월요일

CSS 메타프레임워크를 사용하는가?

Less나 Sass와 같은 CSS 메타프레임워크를 사용하는가? 라는 흥미로운 투표가 진행중입니다. CSS 메타프레임워크는 CSS를 개발언어처럼 변수도 지정하고, 분기문이나 반복문을 작성하여 효율적(?)으로 작성 및 관리할 수 있도록 해 주는 프레임워크입니다. 처음 Sass를 접했을 때 그 방식에 충격도 받았고, 아주 획기적인 것이라고 생각했었는데요. 제 경우에는 그것을 익히는 것 자체가 부담이었고, 그것을 제대로 사용하려면 함께 작업하는 웹 퍼블리셔들 모두가 함께 배워야 제대로 써 먹을 수 있다는 것이었습니다. 그리고 그렇게 사용하더라도 CSS 코드를 있는 그대로 읽고 해석하는게 아니라 한 번 더 논리적인 판단과 고민을 거쳐야 하는 문제가 있었죠. 굉장한 것이기는 하지만 효용성 자체를 아직 느끼지 못한 것이었습니다.

PollDaddy.com에 올라온 이 투표는 저만 그런 생각을 가지고 있었던것은 아니라며 위로를 해 주는 것 같습니다. 아직 진행중이기는 하지만 368명이 투표에 참여를 하고 76%에 달하는 사람이 전혀 사용하지 않는다를 선택했습니다. 거의 사용하지 않는다라고 선택한 11%를 합치면 87%가 되는군요.

CSS 메타프레임워크를 사용하는가? 라는 투표가 진행중이다

2009년 12월 5일 토요일

IE6 커닝 페이퍼: IE6 버그 25+ 해결하는 방법

Virtuosi Media의 Benjamin이 만든 아주 환상적인 커닝 페이퍼였던 Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs를 기억하시는 분들이 많을 것 같습니다. 아마 대부분 즐겨찾기를 해 두셨을 겁니다. 그리고 궁금한 것이 생길 때마다 찾아보시곤 하시겠지요.

그런데 아쉽게도 이 문서는 영문이기 때문에 조금 어렵게 생각하시는 분들도 많았습니다. 저 역시 그랬구요. 하지만 다행히도 이제는 한글로 된 이 커닝 페이퍼를 읽어보실 수 있습니다.

저의 훌륭한 동료이자 형인 이석진 선임 연구원께서 제 부탁을 거절치 못하시고 번역을 해 주셨거든요! 이석진님은 훌륭한 UX기획자로 일을 하고 계십니다.

UI개발이나 웹표준쪽은 거의 알지 못하십니다. 그래서 제가 조금 문맥을 고치는 작업을 진행했습니다. 그럼에도 오타나 오역이 있을 수 있으니 혹시 발견하신다면 제 블로그나 커닝 페이페 문서(위키)의 의견란에 남겨주세요!

Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs

IE6 커닝 페이퍼: IE6 버그 25+ 해결하는 방법

2009년 12월 1일 화요일

오페라 웹표준 강좌 50. 자바스크립트 애니메이션

오랜만에 클리어보스에서 번역중인 오페라 웹표준 강좌 하나가 공개되었습니다.

50장. 자바스크립트 애니메이션이고 졸린눈이님께서 번역 작업을 진행해 주셨습니다.

번역된 다른 강좌들:

CSS Nite in Seoul 발표 자료(PDF) 공개

지난 11월 21일 서울 삼성동 한국 마이크로소프트에서 열렸던 CSS Nite in Seoul, Vol.1의 발표 자료가 CSS Nite in Seoul 공식 사이트를 통해서 공개되었습니다. 여러 분들께서 제 블로그에 문의를 남겨 주셔서 따로 공지차 포스팅을 해 봅니다.

공식사이트 발표자료 공개 글(http://cssnite-seoul.regraphy.com/archives/457)

박 태준（주식회사 NHN 웹표준1팀팀장）- 웹표준을 기반으로 한 HTML 개발 프로세스
타가노 마사히로（주식회사 스위치 대표 이사）- 일본의 웹표준 현실과 제작 프로세스
마시코 다카히로（주식회사 사이버가덴 대표 이사）- 미래의 웹표준으로써의 HTML5과 CSS3

더불어 동영상 자료는 한참 편집중에 있고, 현재는 오프닝 동영상이 공개되어 있습니다. HTML5의 VIDEO 요소를 이용해서 마크업된 웹페이지입니다. Firefox, Safari, Chrome 등 최신 브라우저를 이용하시면 보실 수 있습니다.

2009년 10월 12일 월요일

웹표준 컨퍼런스 CSS Nite 한국 첫 개최!

CSS Nite in Seoul 실행위원회와 (유)리그래피가 함께 주최하고, 한국 마이크로소프트와 태그앤브레이스가 협찬하고, 하드코딩하는 사람들, CSS Design Korea, Clearboth가 후원을 하는 웹표준 컨퍼런스 CSS Nite in Seoul Vol.1이 오는 11월 21일 토요일 삼성동 한국 마이크로소프트 세미나룸에서 개최됩니다.

CSS Nite는 나고야, 오사카, 아오모리, 후쿠오카, 오키나와, 아키타, 삿포로, 후쿠이, 센다이, 히로시마 등 일본의 여러 도시에서 지금까지 총 113회의 컨퍼런스를 통해 18,191분이 참여한 가장 규모가 큰 웹표준 컨퍼런스입니다.

이번 기회를 통해 CSS Nite는 한국과 일본 양국간의 웹제작들간의 교류와 정보 공유를 위해 자리를 마련했고, 그 시작을 서울에서 하고자 합니다.

이번 첫번째 컨퍼런스를 위해 국내에서도 웹표준 교과서의 저자로 잘 알려져 있는 마시코 다카히로씨께서 멀지 않은 미래에 표준이 될 HTML5와 CSS3에 대한 발표를 해 주시고, CSS Nite 의 주최자였던 타가노 마사히로씨께서 일본 웹환경과 제작 프로세스에 대한 강연을 해 주시기 위해 한국을 방문하시게 되었습니다. 여기에 NHN 웹표준화팀의 팀장님으로 계신 박태준 팀장님께서 오랜 경험과 노하우를 통해 얻은 HTML 개발 프로세스 방법론을 소개해 주실 것입니다.

행사내용과 프로그램

행사내용

구분	내용
일정	2009년 11월 21일 12:30-18:00
장소	삼성동 포스코센터 서관 5층 한국MS
주최	CSS Nite in Seoul 실행위원회, 유한회사 리그래피
협찬	한국 마이크로소프트, 태그앤브레이스
후원	하드코딩하는 사람들, CSS Design Korea, Clearboth
모집인원	150명 (초대 인원 포함)
등록비용	사전 등록：25,000원 / 현장 등록：30,000원
발표자	타가노 마사히로 (주식회사 스위치 대표 이사) 마시코 다카히로 (주식회사 사이바가덴 대표 이사) 박 태준 (주식회사 NHN 웹표준1팀팀장)

프로그램

시간	발표자	내용
12:30 [30min]		입장개시
13:00 [15min]	이 유미	오픈닝,행사 소개
13:15 [45min]	박 태준	웹표준을 기반으로 한 HTML개발 프로세스
14:00 [60min]	타가노 마사히로	일본의 웹표준현실과 제작 프로세스
15:00 [10min]	한국 마이크로소프트	라이트닝 토크1
15:10 [15min]		휴식
15:25 [60min]	마시코 다카히로	미래의 웹표준으로서의 HTML5과CSS3
16:25 [10min]	태그앤브레이스	라이트닝 토크2
16:35 [15min]		휴식
16:50 [60min]	박태준, 박중석, 타가노 마사히로, 마시코 다카히로, 미츠코시 유스케	패널토의와 질의응답
17:50 [10min]		경품 추첨
18:30 [60min]		교류파티(무료)

사전등록

사전등록은 온오프믹스를 통해서 실시하고 있습니다. 아울러 이번 행사는 유료로 진행되고 있습니다. 등록금은 30,000원이며, 사전 등록시 25,000원으로 등록을 하실 수 있습니다. 사전 등록이 조기에 마감되는 경우 현장 등록은 받지 않습니다.

배너 등록하기

CSS Nite in Seoul Vol.1 공식

CSS Nite in Seoul Vol.1 블로그 배너(가로 170px)

CSS Nite in Seoul Vol.1 블로그 배너(가로 200px)

CSS Nite in Seoul Vol.1 (가로 800px)

CSS Nite in Seoul Vol.1 (590x390)

CSS Nite in Seoul Vol.1 (가로 590px)

2009년 8월 31일 월요일

오페라 웹표준 강좌 48장, 동적 스타일 - 자바스크립트로 CSS 다루기

클리어보스에서 번역중인 오페라 웹표준 강좌의 48장 동적 스타일 - 자바스크립트로 CSS 다루기가 번역 되었습니다. 검은태양님께서 수고해 주셨습니다. 근래 들어 검은태양님께서 너무 열심히 번역에 참여해 주고 계셔서 한 주에 한 강좌씩 꼬박 꼬바 등록되고 있는것 같습니다. 너무 너무 감사드립니다. 저 역시도 어서 진행중인 부분을 완료해서 올리도록 해야겠습니다.

번역된 다른 강좌들:

2009년 7월 14일 화요일

자바스크립트 없이 메뉴 만들기

CSS Play에는 여러 가지 메뉴의 예제를 보여주고 있다. 각각의 예제는 대부분 IE6를 비롯한 주요 브라우저와 호환된다. 이번에 'Professional dropline / dropdown / flyout version 2 - hybrid menu'라는 예제를 추가했는데 1. IE6에서도 작동된다는 점, 2. 자바스크립트를 사용하고 있지 않다는 점. 때문에 구현 방식에 호기심을 가지고 소스를 분석해 봤다. 나는 어리석게도 아직까지 자바스크립트를 사용하지 않고서는 IE6에서 이와 같은 메뉴를 구현할 수 없다고 생각했다. 한번 들인 습관(자바스크립트를 이용해서 브라우저 호환성을 맞추는) 때문에 좀 더 나은 방법을 찾아볼 생각까지를 하지 못했던 거다. (이런 멍청한!)

2단 수평 메뉴와 드롭다운 메뉴, 플라잉 메뉴까지 총 4단계 깊이의 복합 메뉴를 구현했다

CSS Play의 이 복합 메뉴는 일반적으로 사용되는 2단계 수평 메뉴에 수직으로 떨어지는 드롭다운 메뉴를 붙이고, 다시 4단계 깊이의 메뉴를 플라잉 메뉴로 설계했다. 왠만한 복잡도의 메뉴를 처리할 수 있을만큼인데 이를 CSS만으로 처리했다는 것이 더 멋지다.

CSS Play는 자신들의 예제를 파일로 제공해 주지는 않는다. 개인 웹사이트 사용자들에게는 스타일시트 내에 CSS Play 링크를 유지해 줌으로써 사용을 허락하지만, 상업적인 경우 비용을 지불할 것을 요구하고 있다. HTML과 CSS만으로 만들어진 소스를 돈 내고 써야 하는게 맞는건지는 잘 모르겠지만 그렇게 적혀 있다. 어쨌든 CSS Play에서 다운로드를 제공해주지 않았기 때문에 그저 원본 소스를 열어놓고, 디자인 부분을 제외하고 그대로 재현해 봤다. ID 및 Class 명까지도 새로 작성했고, 스타일시트 역시 원리만 차용하고 내가 직접 다 다시 작성했다. 물론 원본을 따라가다 보니 방식은 동일하다. CSS Play도 다운로드만 제공하지 않을 뿐이지 소스 보기 까지 막아둔 것은 아니기 때문에 문제가 없을 것이라고 생각한다. (이미 출처도 밝혔고!)

아래 소스 부터는 제가 직접 코딩한 내용입니다. 원본가 다를 수 있으니 좀 더 정확히 파악해 보시고 싶으신 분들은 꼭 원본을 확인해 보세요.

기본적인 마크업은 다음과 같다:

골치 아팠던 스타일시트는 아래와 같다:

#gnb {
position:relative;
width:500px;
height:30px;
background-color:#093;
}

#gnb ul {
list-style:none;
white-space:nowrap;
margin:0;
padding:0;
}

#gnb li {
float:left;
}

#gnb a {
color:#fff;
font-size:.85em;
font-family:AppleGothic;
text-decoration:none;
}

#gnb a span {
display:block;
float:left;
cursor:pointer;
}

#gnb a:hover {
color:#FF0;
}

#gnb .main a {
display:block;
float:left;
height:30px;
line-height:30px;
white-space:nowrap;
}

#gnb .main a span {
height:30px;
padding:0 10px;
}

#gnb .sub,#gnb .sub ul {
display:none;
}

#gnb table {
border-collapse:collapse;
font-size:1.2em;
width:0;
height:0;
margin:-1px -10px;
}

#gnb .main :hover .sub {
display:block;
position:absolute;
float:left;
top:30px;
left:0;
width:500px;
height:25px;
background-color:#063;
}

#gnb .main :hover .sub li a {
display:block;
height:25px;
line-height:25px;
float:left;
background-color:#063;
}

#gnb .main :hover .sub li.has-drop a {
height:23px;
border-bottom:2px solid #3c9;
}

#gnb .main :hover .sub :hover ul {
display:block;
position:absolute;
left:0;
top:25px;
width:100px;
}

#gnb .main :hover .sub :hover ul ul {
position:absolute;
left:-9999px;
}

#gnb .main :hover .sub :hover ul li a {
height:20px;
line-height:20px;
border-bottom:0;
background-color:#3c9;
}

#gnb .main :hover .sub :hover ul :hover ul {
left:60px;
top:1px;
width:60px;
}

#gnb .main :hover .sub :hover ul :hover ul li a {
background-color:#399;
}

#gnb .main,#gnb .main li {
height:30px;
}

#gnb .main a:hover,#gnb .main li:hover a,#gnb .main :hover .sub li a:hover,#gnb .main :hover .sub li :hover a,#gnb .main :hover .sub :hover ul li a:hover,#gnb .main :hover .sub :hover ul li :hover a,#gnb .main :hover .sub :hover ul :hover ul a:hover,#gnb .main :hover .sub :hover ul :hover ul :hover a {
background-color:#000;
}

#gnb .main :hover .sub li,#gnb .main :hover .sub li a span {
height:25px;
}

#gnb .main :hover .sub li a:hover,#gnb .main :hover .sub li:hover {
position:relative;
}

#gnb .main :hover .sub :hover ul li,#gnb .main :hover .sub :hover ul li a span {
height:20px;
}

디자인이 적용되지 않은 형태이긴 하지만 거의 그대로 재현되었다.

사실 IE6를 포기한다면 CSS만을 이용해서 위와 같은 메뉴를 만드는 것은 크게 어렵지 않다. 나 역시 거기까진 원본 소스를 보지 않고도 비슷하게 맞출 수 있었다. 역시 난관은 IE6의 호환성 부분이었는데 열쇠는 HTML에 있다. HTML 소스를 확인해 보면 조건부 주석(Conditional Comments)을 이용해서 IE6과 IE7을 처리하는 부분이 있다.

<li>요소의 첫번째 자식 요소인 <a> 요소에 대해서 주건부 주석(IE7 일 때 </a>요소를 적용)이 한 번 쓰이고, 두번째 자식 요소인 <ul>요소를 IE6 이하일 때 <table> 요소로 감싸도록 하고 있다. 즉, 첫번째 자식 요소인 <a>요소의 링크 범위를 설정하기 위한 것과 두번째 자식 요소인 <ul>요소를 IE6에서도 표현하기 위해서 <table>요소를 적용한 것이다.

* 아내 내용부터 약간 보완 수정되었습니다.

하지만 IE6에서 표가 아닌 경우에 <table> 요소를 적용한 방법이 과연 정직한 것인지에 대한 고민을 해 봐야할 것 같다. 표가 아닌 경우에 <table> 요소를 적용함으로써 의미 있는 마크업으로써의 지향을 포기하게 되고, 다시 블록요소인 <ul>요소를 인라인 요소 <a>로 감싸고 있는 형국은 웹표준을 바라던 우리들 가슴을 먹먹하게 만드는 부분이 아닐 수 없다. 또, CSS만으로 처리를 하다 보니 감추어진 하위 메뉴들에 대한 키보드 접근성 문제가 발생(정찬명님께서 지적해 주셨습니다. 감사합니다.)하고 있는 것도 문제가 될 수 있다.

개인적으로는 조건부 주석도 사용하지 않고, 그래서 IE6에서라도 <table>요소를 사용하지 않고, 자바스크립트도 지원하지 않은채 사이트에 적용하는 방법도 최선책은 아니지만 차선책으로 결코 나쁘진 않다고 본다. 즉, IE6사용자들에게는 주메뉴(1단계 메뉴)만 제공하고, IE7이상의 사용자들에게는 모든 기능(4단계 깊이까지 모두 들어가지는 복합 메뉴)을 다 제공하는 것이다. 나로써는 이런 방법도 최소한의 접근성을 보장해 주는 것이라고 생각(주메뉴에서 하위메뉴가 출력되지 않는다고 해서 무조건 접근성이 없다고 보진 않는다. 단, 최종 컨텐츠까지 이동하는데 필요한 네비게이션-메뉴-는 충분히 제공되어야 한다.)하기 때문이다. 반대로 IE6 사용자들이 조금 더 편하게 사이트를 운용하기 위해 스스로 브라우저를 업그래이드 시킬 수 있도록 유도하는 기능까지도 가져볼 수 있지 않을까 싶다.

마지막에 사설이 길었는데 결론을 붙이자면 CSS Play의 이 복합 메뉴 코드는 꽤 인상적이며, 그동안 나 처럼 자바스크립트 없이 절대 IE6까지 호환되는 복합 메뉴를 만들 수 없어!라고 생각했던 사람들이 있다면 좋은 예제 코드가 될 것이라고 생각한다. 하지만 여러분들의 의견을 듣고, 좀 더 생각을 정리한 후에 내린 결론은CSS Play의 원 소스는 '학습용' 이상의 가치를 갖기는 어렵다이다. 위에서 지적된 문제들이 그 이유가 될 것이다. 그렇지만 이 소스를 아주 쓰지 못할 것은 아닌것 같다. 자바스크립트를 적당히 적용할 수 있다면 키보드 접근성 문제를 해결할 수도 있다.

HTML, CSS, JavaScript 등 다양한 Quick Reference를 모아둔 곳!

종종 HTML, CSS, JavaScript과 관련된 Quick Reference를 소개하곤 합니다. 하지만 보통은 한 번 보고 잊어버리거나 다시 생각나서 찾아보려고 해도 잘 찾아지지 않는 경우가 많죠. 그런 분들을 위해서 준비하셨는지는 모르겠지만 미남이의 웹터를 운영하고 계신 운영자님께서는 '참고 종이장들'이라는 서비스를 통해서 온 갖 레퍼런스 문서들을 수집, 정리하여 공개하고 계십니다.

미남이의 웹터

다양한 레퍼런스 문서들

다양한 언어와 제품별로 디렉토리를 구분하고 공개된 대다수의 레퍼런스들을 정리해 두셨는데요 정말 그 수고에 감사의 말씀을 전하고 싶습니다. 좀 더 많은 개발자들에게 공유가 된다면 도움이 될 듯 하여 소개해 드립니다.

2009년 7월 12일 일요일

사이트맵을 쉽게 만들어 주는 SlickMap

ASTUTEO에서 의미 있게 작성된 사이트맵(HTML)을 멋진 디자인으로 만들어 주는 간단한 CSS를 제공했습니다.

사이트맵을 의미 있게 작성한HTML

SlickMap CSS를 적용하면 위처럼 마크업한 HTML이 아래와 같이 멋진 화면으로 만들어진다.

SlickMap CSS가 적용된 화면

SlickMap CSS를 이용하면 손쉽게 미려한 디자인의 사이트맵 화면을 만들 수 있습니다. 물론 실무에서는 위와 다른 디자인을 위해 새로운 CSS를 작성해야만 할지도 모르겠지만 사이트맵 스타일시트 작성에 어려움을 느끼는 분들에게는 괜찮은 레퍼런스가 되지 않을까 하여 소개해 봅니다.

2009년 6월 21일 일요일

공짜로 얻을 수 있는 CSS 템플릿들

웹 표준 공부를 시작하는 사람들에게 다른 사람의 소스 만큼이나 좋은 교재는 없다. 그래서 네이버와 다음과 같은 누구나 아는 사이트의 소스 코드는 언제나 1순위로 '까 보는' 교재가 되었다. 하지만 막상 속을 열어 본 포털의 소스는 너무나 방대하고 어렵다. 뭔가 깔끔하게 구조만 가지고 있는 코드는 없을까? 하고 고민을 해 본 사람이 적지 않을 것 같다. 구글링을 해 본 사람이라면 CSS를 멋지게 다룬 깔끔한 웹사이트들을 어렵지 않게 찾아볼 수 있었을 것이다. 하지만 그마저도 귀찮고 어려운 일이라고 여겨진다면 Design Tech가 소개하는 35개의 웹사이트(35 Excellent Websites for Downloading Free CSS Template)를 방문해 보자. 하루 종일 둘러봐도 시간이 모자를 만큼 많은 무료 CSS 템플릿들이 소개되어 있다. (대체로 비슷한 것들이 많아 보이지만 이외로 멋진 레이아웃을 보여주는 것도 많다!)

무료 CSS 템플릿들

2009년 6월 7일 일요일

아직도 박스 모델(CSS Box Model)이 어렵다구요?

* Clearboth Blog에 올렸던 글(2009/06/08)을 이전했습니다.

CSS TRICKS 에서 심심하면 한번씩 설명되는 CSS 박스 모델에 대해서 다시 한 번 이야기를 하고 있습니다.

파이어폭스의 부가기능 '파이어버그'를 이용해서 박스 모델을 시각적으로 확인하는 방법과, 박스모델을 계산하는 공식을 소개하고 있습니다.

너비에 따른 박스 모델

또한, 박스가 static 또는 relative인 경우에 너비를 정의했을 때와 정의하지 않았을 때 어떻게 다르게 표현되는지를 설명하고 있으며, Abolute로 처리된 박스에 대한 설명과 인라인 요소에 대한 설명도 함께 하고 있습니다.

어려운 CSS? 퀴즈로 배워보자

* Clearboth Blog에 올렸던 글(2009/06/07)을 이전했습니다.

블로그 나라디자인을 운영하고 계시는 정찬명님은 일을 즐겁게 하는 방법을 아는 사람중 한 분이다. 최근 몇 달 사이 나라디자인을 통해서 어렵게 느껴지는 CSS를 좀 더 친근하고 재밌게 공부하고 알아갈 수 있도록 퀴즈를 직접 내고, '빌붙기' 선물까지 제공해 주시고 계시다.

초보에게는 다소 어려운 퀴즈일 수 있지만 현업에서 몇 개월 이상의 경험을 가진 개발자나 웹퍼블리셔들이라면 큰 부담 없이 도전해 볼 수 있지 않을까 싶다.

수평메뉴를 만들어라

지금은 실무에서 가장 많이 사용되고 있는 '수평 메뉴(Horizontal Navigation)'를 이미지 없이 마크업과 스타일시트를 작성하는 퀴즈가 나와 있다. 이번에도 역시나 '빌붙기' 상품이 제공된다니 어서 도전해 보자!

지금까지 출제된 퀴즈들:

2009년 4월 17일 금요일

이메일 클라이언트 CSS 지원 가이드(2008)

* Clearboth Blog에 올렸던 글(2009/04/18)을 이전했습니다.

CampaignMonitor에서 2008년 기준으로 제작된 이메일 클라이언트들의 CSS 지원 가이드입니다.

아웃룩, Mac 메일, 썬더버드 등 대표 데스크탑 메일 클라이언트와 Yahoo!, Gmail, Live Mail, Hotmail 등 해외 주요 이메일 클라이언트들에 대한 조사 결과이며, <style> 요소의 사용 유무를 비롯하여 CSS 선택자, 속성들에 대한 사용 유무를 상세히 보여주고 있습니다. 해외에서 조사된 결과이기 때문에 다음과 네이버, 파란과 같은 주요 웹 메일 클라이언트에 대한 결과는 나타나 있지 않습니다.

하지만 hoi 님의 블로그에 국내 웹 메일 클라이언트에 대한 조사 내용이 올라와 있어 참고하시면 도움이 될 것 같습니다.

2009년 4월 9일 목요일

웹 접근성을 위한 웹 개발자 3가지 수칙

지난 7일 행정안전부가 주최하고 한국정보문화진흥원이 주관한 2009년 상반기 웹 접근성 기술동향 및 향상방안 세미나가 있었습니다. 이날 부족한 제게도 기회가 주어져 발표를 할 수 있었고, 오늘 정보통신 접근성 향상 표준화 포럼을 통해서 발표 자료(PDF)가 공개되었습니다.

사실 이번 발표를 위해서 나름 준비를 열심히 했는데 막상 너무 큰 자리에 서다 보니 반쯤 얼어서 제대로 전달하려고 했던 내용의 반도 전달해 드리지 못한 것 같아 혼자 많이 속상해 했었습니다. 단상에서 내려오고 나니 빠뜨린 내용이 적지 않더군요. 그래서 발표용으로 작성했던 메모를 정리해서 이렇게 글로써 다시 '발표'를 하려고 합니다.

웹 개발자가 알아야할 웹 접근성이라는 주제를 받고, 한참을 고민했습니다. 지난 몇년간 있어온 여러번의 세미나를 통해서 몇번이고 반복되었던 내용들의 반복이 되고 싶지는 않았습니다.(결국은 그렇게 되었지만) 그래서 나름 고민을 거듭해서 3가지 수칙을 정하고, 그에 따라 내용을 붙여 보게 되었습니다. 첫번째 수칙은 ‘항상 공부하라’입니다. 우리가 필요로 하는 정보들이 어디에 있고, 어떻게 찾아 보면 좋을지를 알려드립니다. 두번째 수칙은 ‘습관을 버려라’입니다. 과거로부터 이어진 좋지 않은 개발 관행의 4가지 사례를 살펴보도록 하겠고, 세번째 수칙 ‘사람을 믿고, 기계를 의심하라’에서는 함께 일 하는 동료들과 에디터, 시스템 등 작업 환경에 대한 이야기를 하고자 합니다.

다음은 순서입니다:

수칙 1. 항상 공부하라

1.1 웹 표준 기술을 제대로 알고, 가까운 곳에 스펙을 둬라
1.2 새로운 정보와 이슈를 놓치지 말라

수칙 2. 습관을 버려라
수칙 3. 사람을 믿고, 기계를 의심하라

3.1 동료를 믿어라
3.2 기계를 의심하라

수칙 1. 항상 공부하라

1.1 웹 표준 기술을 제대로 알고, 가까운 곳에 스펙을 둬라

제가 생각할 때 웹 개발자에게 있어서 웹 접근성 향상을 위해서 가장 중요한 것은 웹 표준 기술을 가장 잘 이해하고 사용하는 것입니다. 따라서 첫번째 수칙으로 ‘항상 공부하라’고 했습니다. 그리고 수칙 1-1로 ‘웹 표준 기술을 제대로 알고, 항상 가까운 곳에 스펙을 둬라’고 정해 보았습니다.

어떤 분들은 기억력이 좋으셔서 한 두번 본 내용을 곧 잘 기억해 내십니다. 하지만 저는 그게 참 안되었습니다. 그래서 제 책상 위에는 W3C의 온갖 스펙이 출력되어 있고, 책 제본을 쌓여 있습니다. 그냥 아무렇게나 출력해 놓은 것들은 처음 한 번 이후에는 잘 보지 않게 되기도 하고, 쉽게 이면지함으로 들어가죠. 하지만 회사에 제본기가 한 대 있어서 스펙들을 한데 묶어 책으로 만들어 두시면 보기가 편할 뿐더러 보관에도 좋습니다. 그리고 브라우저의 즐겨찾기는 당연하겠죠. 의외로 많은 분들이 스펙과 관련된 궁금증을 풀기 위해서 커뮤니티 게시판을 이용합니다. 가장 먼저 스펙을 찾아보는 습관을 갖는 것이 좋습니다. 다음은 웹개발자들에게 필요한 주요 북마크입니다.

HTML 4.01 - http://www.w3.org/TR/html401/
XHTML 1 - http://www.w3.org/TR/xhtml1/
HTML 5 - http://www.w3.org/TR/html5/
CSS 2.1 - http://www.w3.org/TR/CSS21/
ECMA Script - http://www.ecma-international.org/publications/standards/Ecma-262.htm
MSDN - http://msdn.microsoft.com/en-us/library/aa155110.aspx
MDC Reference - https://developer.mozilla.org/en/Main_Page
Opera Community - http://dev.opera.com/
나라디자인 Wiki - http://naradesign.net/wiki/UI_개발자를_위한_북마크
웹 뒤에 숨은 Web - http://www.pageoff.net/828

W3C에 권고안으로 공개된 표준 스펙 문서들과 MS, Mozilla, Opera가 운영하고 있는 레퍼런스 사이트들입니다. 실제로 찾아보시면 이보다 훨씬 더 많은 스펙 문서들과 레퍼런스 사이트들이 있습니다. 제 블로그를 통해서도 소개드린 것들이 있고, 정찬명님의 나라디자인 위키 페이지에서 UI개발자들을 위한 북마크를 운영하고 계시기도 합니다. 웹 개발자 분들께 유용한 자료가 될 것으로 생각됩니다.

1.2 새로운 정보와 이슈를 놓치지 말라

수칙 1.2는 '새로운 정보와 이슈를 놓치지 말라'입니다. 개발 분야 만큼 빠르게 새로운 정보와 이슈가 쏟아지는 분야도 드믈 것이라고 생각됩니다. 겨우 하나의 언어와 기술을 익혔는데 어느새 또 다른 언어가 나오고 방법론이 제시됩니다. 특히 웹이 대중화된 이후는 그 속도가 더욱 더 빨라지고 있는 추세입니다. 그런 빠름을 쫓아가지 못한다면 계속해서 뒤쳐질 수 밖에 없는 것이 또한 이 분야인 것 같습니다.

RSS는 여러 사이트의 새로운 글을 아주 쉽게 읽을 수 있도록 도와줍니다. 구글 리더와 같은 피드 구독기를 적극 활용하면 수 많은 블로그와 홈페이지의 최신 정보를 쉽게 얻을 수 있습니다. 파이어폭스와 같은 최신의 브라우저는 아주 쉽게 피드를 구독할 수 있도록 기능을 지원하고 있기도 합니다. 또 다른 하나는 Delicious와 같은 SNS기반의 북마크 서비스를 이용하는 것입니다. HTML, CSS, Web Standards 등 관련 태그를 통해서 다른 사람들이 북마크한 유용한 정보와 사이트들을 쉽게 찾아볼 수 있습니다.

수칙 2. 습관을 버려라

세살 버릇 여든까지 간다고 합니다. 한번 몸에 벤 습관이 그만큼 무섭다는 뜻입니다. 초중고와 대학을 지나면서 그리고 사회 초년생일 때- 처음 개발을 배우고 이 바닥에 발을 들이기 시작해서 처음 만났던 사수로부터 배웠던 기술들. 아무것도 몰랐던 우리는 습자지처럼 새로운 기술들을 받아 들이고 배워왔습니다. 하지만 알게 모르게 잘못된 정보와 기술을 가려 내지 못하고 무분별하게 배워왔다는 사실입니다. 책이라고 해서 다르지 않습니다. 외서의 경우 오역되거나 잘못된 의미를 전달하기도 하고, 바람직하지 않은 기술을 권장하는 듯 써 놓은 것을 그대로 믿어버린 경우가 부지기수입니다.

때문에 웹 접근성과 웹 표준을 대하는 개발자에게 있어서 가장 큰 충격은 자신의 지식에 대한 확신의 흔들림입니다. 뒤에 간단한 설문 조사 결과를 통해서도 말씀 드리겠지만 자신이 알고 있는 표준에 대한 지식이 과연 옳은 것이었는가? 하는 의심을 가질 필요가 있습니다. 그래서 두번째 수칙은 ‘관성을 버려라’ 그리고 ‘항상 현재의 방법이 최선인지를 의심하라’라고 하였습니다.

그럼 웹 개발자들이 일반적으로 잘못 알고 있었던 사례들은 어떤 것들이 있는지 살펴보겠습니다.

습관 하나. 비동기 통신은 Frame으로 구현해야 하나?

첫번째 사례는 비동기 통신을 사용하기 위해서 프레임을 사용하는 경우입니다. 최근에는 Ajax를 이용한 개발이 붐을 일고 있기는 하지만 여전히 Frameset을 설정하여 무의미한 frame을 만들어 놓고, 비동기 통신을 구현하고자 하는 개발자들이 있었습니다. 조금 더 자세히 살펴보겠습니다.

Frame 요소는 Netscape 2.0에서 최초 지원된 후 Hidden Frame, DHTML로 차차 발전해 나간다

Frame 기술의 발전하다가 Ajax에게 그 자리를 내주고 있다.

Frame은 Netscape 2.0(1996)에서 최초로 지원되었고, HTML 4.0(1997)에 이르러 공식적으로 도입되었습니다. Hidden Frame 기술은 Frameset을 설정하여 하나의 Frame의 높이를 ‘0’로 만들어 서버와의 통신을 처리하는데 사용한 최초의 비동기 요청/응답 모델이었습니다. 이후 마이크로소프트사가 자바스크립트를 이용하여 동적으로 페이지의 일부를 수정할 수 있는 기술인 DHTML을 만듭니다. Hidden Frame 기술은 이 DHTML을 만나 페이지의 어느 부분이라도 서버 정보를 가지고 언제든지 새로고침할 수 있도록 해 주었습니다. 하지만 Hidden Frame 기술은 반드시 프레임셋을 설정해야만 한다는 단점이 있었는데, iframe 엘리먼트가 HTML 4.0에 포함되면서 Inline Frame 기술을 사용할 수 있게 됩니다. 이후 CSS와 결합하여 Hidden Inline Frame 기술로 발전되어 사용되기 시작합니다. 하지만 더이상 Frame을 사용하여 웹사이트의 구조를 분리할 필요성(퍼포먼스 향상을 위해)도 없으며, 비동기 통신을 위해서라면 이미 Ajax와 같은 기술이 그 자리를 대체해 나가고 있다. 그럼에도 이같은 frame의 발전은 많은 웹개발자들이 Frame기술을 이용한 잘못된 습관을 가지게 만드는데 일조를 하게 됩니다. 다음의 마크업을 보겠습니다.

경력이 적은 분들이라 하더라도 이와 같은 마크업을 한 두번쯤은 보셨을 것으로 생각됩니다. 이같은 프레임셋을 설정하는 이유에는 지금 설명드린 비동기 통신을 구현하기 위한 목적 외에도 도메인을 깔끔하게 유지하고자 하는 목적도 있습니다. 하지만 두 가지 이유 모두 접근성 측면에서 바람직하지 않습니다. 바로 이어서 설명드리겠습니다.

습관 둘. 고정 URL은 보안이 좋다?

과거에는 URL을 통한 해킹 공격이 이루어졌던 사례들이 있었습니다. Query Injection이라고도 하는 이 해킹 방법(SQL Injection이 좀 더 정확한 표현이라고 합니다)은 이와 같이 URL이나 사용자 서식 요소의 필드를 통해서 특정 SQL Query를 입력함으로써 웹사이트 가입자의 비밀번호나 주민등록번호와 같은 정보를 노출시키는 방법입니다. 또한, 꼭 Query Injection 이 아니더라도 간단히 도메인 뒤에 따라 붙는 Query String의 값을 조작하는 것만으로도 웹사이트에 비정상적인 동작을 요청할 수 있습니다. 이 때문에 많은 사람들이 URL에 Query String을 보이지 않도록 눈속임을 했었습니다. 거기에 마우스 우클릭을 막아 컨텍스트 메뉴가 뜨지 않게까지 했습니다. 이렇게 하면 사용자가 임의로 웹 페이지의 전체 URL을 알 수 없을 것이라고 생각했던 것이지요.

네이버와 같은 포털의 URL은 숨겨져 있지 않다

하지만 어느 사이트보다도 보안이 생명인 검색 사이트나 포털 사이트 어느 곳도 전체 주소를 감추거나 하지 않습니다. URL을 감추고, 컨텍스트 메뉴를 무력화 시키는 것이 결코 해커의 공격을 막는 방법이 되지 않는다는 것입니다.

그럼 이러한 프레임셋 구조가 웹접근성 측면에서는 어떨까요?

프레임셋을 사용하게 되면 일단, 개별 웹 페이지의 고유 주소를 상실하기 때문에 고유성이 상실됩니다. 이것은 결국 정보와 위치의 불일치를 가져오게 됩니다. 즉, 절대 주소가 공개되지 않은 경우 사용자는 찾고자 하는 정보를 다시 얻기 위해서 웹 사이트의 초기 페이지부터 탐색을 반복해야 하는 번거로움을 가지게 됩니다. 이는 파리를 여행하는 사람에게 세계 지도를 던져 주며 에펠탑을 찾아 가 보라는 것과 다를게 없습니다.

같은 URL을 가진 서로 다른 페이지

국가정보원 웹사이트입니다. 홈페이지와 관계규정 내용을 담고 있는 페이지의 URL이 www.kecs.go.kr로 동일함을 볼 수 있습니다. 관련 내용을 인용하기 위해서 URL이 필요한 경우에도, 다른 사람에게 해당 페이지의 내용을 소개하고 싶을 때에도 또같은 URL을 사용해야 합니다. 심지어 자신이 북마크를 해 놓고 다시 열고 싶을 때에도 국정원 사이트의 홈페이지부터 재 탐색을 해야합니다. 이것은 일반인에게도 매우 불편합니다.

그럼에도 불구하고 Frame을 사용해야 한다면 다음을 기억하십시오:

DTD(HTML 4.01 Frameset 또는, XHTML 1.0 Frameset)의 명확한 정의
title 속성을 이용한 정확한 이름을 부여
최소 사용

습관 셋. alt? title? 그런거 없어도 아무 문제 없더라

alt는 툴팁이 아닙니다

다음으로 소개드릴 것은 대체 텍스트와 제목에 관해서입니다. alt 속성은 이미지의 텍스트로 대체하기 위한 속성입니다. 시각 장애가 있는 사람은 이미지의 내용을 파악할 수 없기 때문에 alt 속성의 내용으로 대신 인지합니다. 또한, 검색 엔진 역시 인간과 같이 시각 정보를 가질 수 없기 때문에 alt 속성을 통해서 정보를 수집합니다. 그런데 IE는 alt 속성을 풍선 도움말(툴팁)로 처리해서 보여주는 기능을 하고 있습니다. 일반인들이 뜬 눈으로도 이미지의 내용을 파악하지 못한다고 생각해서였을까요?

title 속성 역시 alt 처럼 스크린리더를 통해서 음성 정보를 지원하고, 일부 엘리먼트를 제외한 거의 모든 엘리먼트의 제목으로 사용될 수 있습니다. 특히 frame 엘리먼트와 label 엘리먼트를 함께 쓸 수 없는 서식 요소의 제목으로사용되면 접근성을 높일 수 있습니다. 하지만 alt와 title 속성을 처리하는데 있어서 스크린리더마다 방식이 다를 수 있기 때문에 이에 대한 사전 조사와 테스트가 필요합니다.

미투데이는 다양한 스타일시트를 포함하고 있고, title을 부여하고 있다.

미투데이 사이트는 여러개의 테마 스타일시트를 포함하고 있습니다. 개별 스타일시트를 연결하는 link 엘리먼트에는 해당 스타일시트의 제목이 title로 정의되어 있음을 볼 수 있습니다.

Doday는 alt 속성을 잘못 처리하고 있다

반면에, 비교적 웹 표준을 잘 준수한 Doday 서비스의 경우 메인 페이지 ‘요즘 이야기’부분에서 사용자 프로필 이미지들에 대한 alt 값이 모두 ‘님의 프로필 이미지’로 똑같습니다. 사용자 아이디를 넣어줘야 하는 부분에서 개발자가 실수로 빠뜨리지 않았나 싶습니다. 결과적으로 시각 장애인 및 검색 엔진은 서로 다른 이미지들을 모두 똑같은 의미의 이미지로 파악할 우려가 있습니다. (4월 7일 오전 저의 버그 신고로 인해 바로 수정되었습니다.)

alt와 title을 이야기하면서 항상 빠지지 않는 것이 언제 alt를 쓰고, 언제 title을 써야 하는지에 대한 문제입니다. 이 문제는 네이버 카페 ‘하드코딩을 하는 사람들’이나 ‘CSS Design Korea’에서의 논의와 '한국 모질라 커뮤니티'에서 논의가 이루어졌었고, 일모리님의 블로그에 잘 설명되어 있습니다. 참고해 주시기 바랍니다.

대체 텍스트를 사용하기에 앞서 다음과 같은 고민이 있을 수 있습니다. 첫째, 의미를 가진 이미지인가 꾸밈용 이미지인가 하는 것입니다. 단지 꾸밈용이라면 불필요한 대첵 텍스트가 오히려 접근성과 사용성을 떨어 뜨릴 수 있습니다. 둘째, 이미지 자체를 대체하는 것인지 아닌지를 판단하여 alt를 사용할지 title을 사용할지 적절히 판단할 수 있어야 합니다. 셋째, 대체 텍스트의 길이가 긴 경우 longdesc 속성을 이용하거나, IR기법 등 다른 방법을 고민할 수 있어야 합니다.

습관 넷. Label? 개발자는 다 안다고?

웹 개발자들이 자주 간과하고 있는 것 들 중 또다른 하나가 바로 label 요소입니다. label요소는 input과 같은 사용자 서식 요소에 대한 정보를 첨부하며 연관을 맺습니다. 주로 서식 요소의 제목 요소로 적용되고 있으며, 서식요소와 1:1로 관계를 갖습니다. 이같은 마크업은 서식 요소에 대한 접근성을 높여줍니다. 다음은 label을 적용하는 방법입니다.

명시적 선언

암시(묵)적 선언

Title 선언

label을 마크업하는 방법에는 명시적 선언과 암시적 선언 두가지가 있습니다. 1:1로 대응되는 서식 요소에 대해서 id와 for 속성을 통해서 연결하는 방법이 명시적 선언이며, 서식 요소를 label 엘리먼트로 감싸는 것이 암시적 선언입니다. 암시적 선언인 경우에 label엘리먼트의 for 속성은 생략이 가능합니다. 하지만 전화번호와 주민등록번호와 같이 동일한 의미를 갖는 서식요소가 둘 이상의 필드로 구성된 경우 label 엘리먼트와 1:1로 대응시키는 것이 비효율적인 경우가 있습니다. 이런 경우 각 서식요소에 title 속성을 이용해서 제목을 달아 주는 것이 좋습니다.

하지만 이렇게 의미적으로 하나의 정보를 위해서 둘 이상의 필드로 구성하는 것은 사용성 입장에서도 별로 바람직하지 않은것 같습니다. 각 필드를 채우고 Tab키를 눌러서 이동해야 하는 번거로움을 차치하더라도, 필드가 채워지면 자동으로 다은 필드로 이동하는 기능의 경우에는 시각 장애인에게는 접근성을 저해하는 요소가 된다는 사실을 알아두실 필요가 있을 것 같습니다. 하나의 필드로 구성하여 자바스크립트와 서버 개발을 통해서 얼마든지 유효성 검증과 데이터 처리를 할 수 있을 것입니다.

네번째로 말씀 드릴 내용은 form 엘리먼트 처리에 관한 것으로, 자바스크립트를 이용해서 서식 요소의 값을 서버에 전달하는 경우 자바스크립트가 지원되지 않는 환경에서 ‘전달’ 자체가 이루어지지 않는 문제가 있습니다. 따라서 서식 요소의 데이터를 서버에 넘기는 작업은 form 엘리먼트의 본래 기능을 그대로 이용하는 것이 좋습니다. 실생활에서의 배달과 전달을 UPS와 같은 전문 전송 업체에게 맡기듯 서식 요소의 데이터는 form에게 믿고 맡기는 것이 좋습니다.

더불어 서식 요소에 대한 유효성 검증을 자바스크립트로만 처리하는 경우가 종종 있습니다. 이 역시 바람직하지 않은 것으로, 반드시 클라이언트와 서버 양쪽 모두에서 유효성 검증에 대한 처리를 해 주어야 사용자의 실수로 인한 문제를 막을 수 있습니다.

다음은 꼭 한번 읽어보세요: (오픈 웹은 현재 구글 그룹스로 변경되어 아래 링크를 확인할 수 없을 수 있습니다)

ActiveX? - http://ko.wikipedia.org/wiki/ActiveX
AJAX 배후 기술 - http://ggoma.isblog.net/blog_post_233.aspx
Frame: ‘보안접속’ 프로그램 - http://openweb.or.kr/?p=499
Frame: 웹페이지 주소 감추기 - http://openweb.or.kr/?p=480
대체 텍스트 - http://en.wikipedia.org/wiki/Wikipedia:Alternative_text_for_images
Alt Attribute - http://en.wikipedia.org/wiki/Alt_attribute
접근성을 해치지 않는 자바스크립트의 사용 - http://hyeonseok.com/docs/accessible-javascript/
센스리더 프로 리뷰 - http://html.nhndesign.com/accessibility_sensereader_review

수칙 3. 사람을 믿고, 기계를 의심하라

지금까지는 지식과 정보, 기술적인 부분에 대해서 두가지 수칙을 들었고, 그 안에서 몇가지 작은 이야기들을 전해 드렸습니다. 이제 세번째 수칙으로 ‘사람을 믿고, 기계를 의심하라’고 말씀을 드리면서 수칙 3.1 ‘사람을 믿어라’라고 부탁드리고 싶습니다.

3.1 동료를 믿어라

첫번째로 웹 기획자는 그 누구보다 열심히 웹 접근성와 사용성에 대해서 고민을 하는 사람입니다. 그들이 다소 거만하고 잘난 체를 할지 모르지만 그들의 머리 속에는 우리들이 걱정하는 것 이상으로 많은 것들을 고민하고 있다라는 사실을 잊지 마시길 바랍니다.

웹 에이젼시에서 일을 했던 경험을 돌이켜보면 제가 사내에서 웹 접근성과 표준에 대한 이야기를 꺼낼 때 그리고 설득하는 과정에서 디자이너를 이해시키는 일이 가장 쉽지 않았었습니다. 그러던 중 함께 스터디를 하던 디자이너 친구 한 명이 이런 질문을 하더군요. ‘과연 웹 표준을 지킬 수 없는 디자인이 있느냐? 있다면 어떤 디자인이냐?’라고 말이죠. 그날 스터디에서는 저를 비롯해서 여러명의 사람들이 한국의 비주얼이 강한 디자인 때문에 표준을 적용하기 어렵다라고 목소리를 높이고 있었거든요. 하지만 막상 그 디자이너 친구의 질문에 어떤 디자인이 절대 표준 기술만 가지고 만들 수 없다라고 대답하지 못했습니다. 물론, 실무에서 작업을 하다 보면 디자인 때문에 마크업과 css 작업에 애를 많이 겪고 있고, 종종 해결책을 찾지 못하고 CSS Hacks을 사용하기도 합니다. 하지만 돌이켜보면 정말 길이 없어서 그랬다기 보다 시간이 부족해서 차선책을 택했던 적이 더 많았음을 스스로 깨닫게 됩니다. 저는 그 날 이후로 함께 일 하는 웹디자이너를 설득하는 일을 그만 두었습니다. 그리고 까짓것 한 번 해볼테니 날 믿고 디자인을 해달라고 부탁하곤 했습니다.

이 자리에 모인 대부분의 분들이 웹 퍼블리셔 또는 UI 개발자라는 명함을 가지고 계실것으로 생각됩니다. 그만큼 그 어느 직군보다 웹 표준과 접근성에 대해서 관심이 높고, 열정이 대단하다고 생각합니다. 어떤 일이든 시작이 가장 어렵고 첫 걸음을 옮기는 것이 가장 힘듭니다. 그 큰 걸음을 지금 여러분이 떼고 있으신 겁니다. 때문에 저는 감히 여러분 모두를 웹 표준 전문가라고 말씀드립니다. ASP든 JSP든 서버단에서 개발 업무를 보고 계신 개발자님들 동료 UI개발자 분들의 실력을 믿어보시길 바라겠습니다.

문화적인 차이일 수 있겠지만 한국은 지나치게 고객을 무시하고, 의심하는 경향이 있습니다. 사이트 발주자인 클라이언트의 무지함을 욕하고, 사이트 사용자인 고객의 멍청함에 잔득 걱정을 합니다. 때문에 온갖 보안 프로그램을 깔기를 강요하고 프레임셋으로 URL을 감추고, 우클릭을 막아버리고, 온갖 문서를 보면서 동의를 강요합니다.

개발자들의 논리 중에 가장 우수운 것이 바로 ‘자신 역시 한 명의 사용자(고객)이다’라는 점입니다. 그렇게 사용자들을 무시하면서 자신을 또 한 명의 사용자로 생각한다는 것. 결국 누워서 침을 뱉은 것 아닌가요.

또 한가지 개발자들은 오로지 코딩만 잘 하면 된다고 생각합니다. 발주자건 사용자건 그들을 상대하는 건 기획자라고 생각합니다. 웹 접근성과 웹 표준에 대한 인식 제고나 설득 역시 기획자가 해야할 것이라고 생각하고, 웹 퍼블리셔니 UI개발자니 하면서 갑자기 한 자리를 차지하기 시작한 사람들이 해야 한다고 생각합니다.

만약 개발자 직군이 명확하게 클라이언트단과 서버단으로 구분되어 서버사이드개발자가 순수하게 로직만 작성한다면 반드시 틀린 말은 아닐 수 있습니다. 하지만 제가 서두에서 개발자의 범위를 포괄적 개발자로 설정한 것 처럼 현실은 그렇치 않습니다. 그리고 앞으로도 상당한 기간동안 지금의 현실이 갑자기 바뀌지도 않을 것으로 생각됩니다. 지금, 개발자인 사람들 모두가 같은 고민과 철학으로 고객을 바꾸고 변화 시킬 필요가 있는 겁니다.

3.2 기계를 의심하라

개발 경험이 오래되신 분들은 과거 핫도그 웹 에디터나 나모 웹 에디터 등을 기억하실 겁니다. 어도비의 고라이브도 있군요. 드림위버의 초기 버전도 언듯 떠오르실 분도 계실겁니다. 당시의 이런 에디터 툴은 편리하게 홈페이지를 만들어 주기는 했지만 웹 표준을 몰랐던 브라우저들 처럼 툴 역시 웹 표준을 인식하지 못했습니다. 때문에 불필요한 마크업과 CSS를 만들어 냈고, 호환성이 확보되지 않은 자바스크립트 코드를 마구 집어 넣었습니다. 지금은 드림위버등 많은 에디터들이 웹 접근성과 웹 표준 스펙을 반영하고 있지만 여전히 일부 에디터는 잘못된 코드와 DTD의 생략을 기본 값으로 설정해 놓고 있습니다.

특히 나모 웹 에디터는 저 역시 98년 당시에 많이 사용했던 에디터입니다. 이 에디터는 자바스크립트를 자동으로 생성해 주는 마법사 툴이 있었는데, 호환성이 확보되지 않은 스크립트 코드를 만들어 냈던 것으로 기억합니다. 그 코드가 IE전용이었다는 사실은 한참이나 지나서야 알게된 사실들이었습니다. 초기 드림위버가 만들어낸 코드 역시 엉망진창이었습니다. 초기 버전에서 만들어낸 엉망의 코드 때문에 많은 개발자들이 워지익 툴의 편리함에도 불구하고 나모 웹 에디터나 드림위버 등의 사용을 꺼리게 되기도 했었습니다. 다행히 최근 출시된 새로운 버전이나 에디터들은 많은 향상이 있어 과거처럼 엉망인 경우는 드믄것 같습니다. 옛 말에 장인은 연장 탓을 하지 않는다고 하죠. 훌륭한 웹 개발자라면 툴 때문에 웹 표준을 지키기 어렵다라는 말은 하지 않아야겠죠. 하지만 툴이 가져다 주는 편리함과 생산성은 역시 무시할 수 없을 것입니다. 때문에 어떤 툴을 자신의 주력 툴로 결정한 것인지는 매우 중요하고, 잘 선택되어야 합니다. 무료든 유료든 아주 다양한 에디터들이 존재하고 있습니다. 충분히 검증된 제품을 선택하시길 바랍니다.

또 한가지, 개발자들의 PC는 회사 사정에 따라 차이는 있겠지만 일반적으로 부족하지 않은 스펙을 가지고 있습니다. 하지만 인터넷에 접속하는 모든 PC가 아이온과 콜 오브 듀티같은 인기 게임을 실행시킬 수 있을 만큼 멋지진 않습니다. 학교나 관공서같은 곳의 PC는 생각보다 오래된 것이 많습니다. 이미지와 플래쉬 무비로 무겁게 제작된 사이트들 때문에 PC를 몇 번이나 리부팅해야 하는 사람들도 있을 것입니다.

Markup Validation Service

마지막으로 웹 표준을 열심히 지키고 계신 여러분들이 절대로 잊지 말아야 할 한가지를 말씀 드리겠습니다. HTML과 CSS에 대해서 충분히 의미 있게 그리고 호환성이 확보된 표준 스펙을 따랐을 경우에 우리는 W3C의 벨리데이션 서비스를 통해서 이같은 유효성 검사 통과 화면을 받아 볼 수 있습니다. 하지만 이 순간 여러분은 과연 이 결과가 타당한지에 대한 의구심을 가질 필요가 있습니다. 벨리데이션 검사는 단지 코드에 대한 문법 검사일 뿐입니다. 파란 하늘 이미지에 ‘용광로’라고 적어 넣은 alt 속성을 확인 했더라도 이 검사는 초록색 ‘성공’ 메세지를 멋지게 보여줄 것입니다. 과연 제대로 만든 페이지였을까요?

마치며

큰 수칙 3가지를 전해 드리면서 그리고 첫번째 수칙을 통해서 웹 개발자에게 있어서 웹 접근성을 향상시키는 가장 확실하고 정직한 방법은 '공부'라고 했습니다. 웹 표준 스펙을 얼마나 제대로 알고 있는지 그리고 얼마나 명확하게 적용할 수 있는지가 가장 중요하다고 생각합니다. 그래서 저는 웹 표준을 웹 개발자에게 있어서 '기술'이라고 생각하고, 웹 접근성은 다른 사람을 생각하고 타인을 배려하고자 하는 '철학'에 빗대어 의미를 전달해 드리고자 했습니다. 기본적으로 웹 접근성 역시도 여러가지 명세와 가이드로 틀을 갖춰 나가고 있지만 근본적으로 사람에 대한 마음을 담는 것이라고 생각하기 때문입니다. 개발자는 코드만 잘 짜면 된다라는 생각은 이제 버려야 합니다. 이 코드가 사람을 차별하는 칼이 될 수 있음을 아셔야 합니다. 그래서 더욱 더 왜 내가 웹 접근성을 고민해야 하는지에 대한 자기 철학이 필요한 이유입니다. 끊임 없는 자기 계발과 철학의 발견. 이 이야기를 해 드리고 싶었습니다.

2009년 4월 8일 수요일

4월 9일은 CSS Naked Day 입니다.

매년 4월 9일은 웹 사이트의 CSS를 제거하고, 순수하게 HTML 마크업만을 남겨 구조적이고 의미있는 웹을 보여주면서 웹 표준을 장려하는 전세계적인 이벤트입니다.

작년과 제작년 모두 이 이벤트에 참여했던 웹 뒤에 숨은 web 이었지만, 아쉽게도 올해는 현재의 블로그 서비스에서 HTML과 CSS에 대한 수정 권한을 제공하지 않아 CSS를 제거하기가 어려운 상황입니다. 자바스크립트 등을 이용한다면 강제로 벗겨버릴 수도 없지는 않겠으나 그런 편법 자체가 정직하지는 않다라는 판단 때문에 제가 운영하고 있는 또 다른 사이트인 Clearboth의 블로그와 위키, 포럼만 이벤트에 참여시키고, 올해 웹 뒤에 숨은 web은 이렇게 행사를 알리는 글만 포스팅 하도록 하겠습니다.

CSS Naked Day의 한국어 페이지

CSS를 제거한 Clearboth.org

2009년 3월 29일 일요일

웹 퍼블리셔들의 놀이터, CSS Playground

CSS Zengarden은 구조적으로 잘 작성된 하나의 HTML 문서에 수 많은 CSS가 결합되어 다양한 디자인을 선 보이는 아주 특별한 사이트입니다. CSS의 기술적인 능력을 뽐냈을 뿐 아니라 예술성까지 느껴지도록 만들어 준 사이트입니다. 그래서 웹 표준을 다루는 거의 모든 책과 세미나에서 젠가든을 언급합니다. 이런 젠가든을 더욱 특별하게 해 주는 이유는 누구에게나 문이 열려 있다는 점일 겁니다. 지금이라도 당장 젠가든의 멋진 마크업 위에 아름다운 디자인을 CSS로 작성하여 올릴 수 있습니다. 하지만 언어적인 장벽 때문일까요? 한국의 훌륭한 웹 퍼블리셔들의 작품은 좀 처럼 찾아볼 수 없었던 것 같습니다.

CSS Playground

그런 안타까움을 느끼셨는지 CSS Design Korea의 홍윤표님께서 아주 멋진 사이트를 하나 만들어 주셨습니다. CSS Playground는 한국의 웹 퍼블리셔나 디자이너, 개발자들이 자유롭게 자신들의 능력을 발휘하여 CSS를 다룰 수 있도록 만들어진 한국의 젠가든입니다.

CSS Playground의 규칙은 다음과 같습니다.

CSS는 표준 방식에 근거함
Cross Browsing
FAQ 숙지