2008년 5월 28일 수요일

Firefox 3 다운로드 받으시겠습니까?

Spread Firefox에서 Firefox 3 정식버전 다운로드 서약서를 받고 있습니다. 현재 RC1 버전까지 출시된 Firefox의 정식버전이 조만간 선보일 것으로 예상되는데 Spread Firefox에서 조금은 색다른 방법의 캠페인을 벌이는 것 같습니다.

현재 국가별로 서약서 접수율을 보여주고 있는데 한국은 200명 정도가 참여했고, 일본은 10배가 넘는 2,000여명이 참여하고 있네요.

참여하실 분은 해당 페이지에서 Pledge Now! 를 클릭하시고 자신의 이메일 주소를 입력하시면 되구요. 정식 다운로드가 시작되면 등록한 메일로 알려주는 것 같습니다.

Firefox를 쓰시거나 관심이 있으신 분들은 한번 참여해 보시면 좋을것 같구요. 그동안 써보지 않으셨던 분들이라면 이참에 서약에 참여하시고, 제대로 사용해 보는 기회를 가져보면 좋을 것 같습니다.

Explorer라는 범국민(?)적 브라우저가 있기는 하지만 많은 분들이 사용하고 계시는 버전 6 이하의 브라우저는 웹표준이나 접근성 부분에서 여러가지 문제점을 가지고 있는 것이 사실이구요. 이후 출시된 7에서도 크게 개선되지 못했었습니다. 최근 버전 8 beta가 발표되었는데. 이같은 MS의 행보에는 다분히 Firefox라는 강력한 경쟁 상대가 나타났기 때문이었습니다. 최근 이슈가 되고 있는 웹접근성이나 웹표준화에 있어서 가장 관심을 받고 있는 브라우저가 Firefox인데 이 브라우저가 IE보다 완벽하게 좋다! 라고는 말할수는 없겠지만 충분히 좋은 브라우저이고, 써볼만한 가치가 있는 브라우저라고 생각합니다. 특히나 웹쪽에서 종사하고 계시는 분들이라면 Firefox라는 브라우저를 통해서 좀 더 넓은 시야를 키울 필요가 있지 않나 싶습니다.

사용자 삽입 이미지

2008년 5월 23일 금요일

NHN 웹표준화팀의 HTML 개발 프로세스 특강 후기

무더웠던 22일 오후. 하드코딩하는 사람들(이하 하코사)의 엽님과 함게 역삼동의 비즈델리 교육장을 찾았을 때 텅빈 교육장은 에어콘 대신 무심하게 목만 긴 선풍기들이 먼저 자리를 채우고 있었다. 잠시 후부터 하코사의 진달래님과 fooljini님 등이 자리를 채워 주셨고, 얼굴은 낯설지만 같은 의미로 비싼(?) 수업을 듣기 위해 스무명 남짓의 사람들이 자리를 하나씩 채워갔다.

이날 특강의 발표자는 NHN의 웹표준화팀장 박태준씨였고, 주제는 HTML 개발 프로세스였다. 나와 같이 웹퍼블리싱 업무를 하는 사람들에게 있어서 의미있는 마크업과 효과적인 스타일시트 작성, 웹표준과 접근성에 대한 충분한 이해와 적용은 매우 중요한 것이다. 하지만 한가지 더 덧붙이자면 HTML이 프로세스의 어정쩡한 중간단계나 단순작업으로 치부되지 않고 모든 프로세스와 동일하게 중요시되거나 그 이상의 의미를 가질 수 있도록 프로세스를 개선하는 것. 개선되도록 연구하는 것도 아주 중요하지 않을까 생각했다. 특별히 웹표준화가 이슈가 되고 과거의 웹 개발 프로세스가 가지는 워터풀 방식이 여러가지 문제들을 가진다고 느끼는 사람들이 많은데 실제로 무엇이 문제고 무엇을 고쳐야 하는지, 그 대안은 어떤것인지에 대한 고민들은 부족하지 않았나 싶다. 그런의미에서 이번 NHN의 웹표준화팀에서의 선행 사례는 아주 의미가 있는 주제를 가지고 강의를 가져주지 않았나 생각한다.

물론 NHN이 네이버라는 포털중심의 기업이라는 점에서 대부분의 웹퍼블리셔들이 포함된 환경(웹에이젼신 등)과 동일하게 적용되길 바라는 것은 어쩌면 희망사항이고 환상일지 모른다. 박태준 팀장님 역시 그 부분에 대해서는 미리 언급을 해 주셨고, 나 역시 그러한 골의 깊이를 안타까워 하며 강의를 듣을수 밖에 없었다. 하지만 우리가 앞선 사람들의 경험들을 곧이 곧대로 받아들이기만 한다면 언제까지나 수동적일수밖에 없고, 잘못된 선행 사례를 비판할 수 있는 시각조차도 키울수 없지 않을까. 박태준 팀장님이 소개하는 것은 어디까지나 NHN이 지난 시간 실패와 성공을 오가며 경험했던 소중한 자료들이고, 우리는 그것을 간접적으로 배워가며 새롭게 우리의 것을 만들고 적용해 보기를 노력하면 되리라 생각해 본다.

특별히 이번 특강을 통해서 문서화 작업의 중요성을 다시금 깨닫게 되었는데 국문과 출신이라는 점 때문인지는 몰라도 나름의 정리벽을 가지고 있기는 하지만 지식이 얕다 보니 그것에도 한계가 있고, 스스로도 체계성을 갖추지 못한 약점이 있었다. 그러던 차에 NHN의 수많은 문서들을 보고서 경악하지 않을 수가 없었는데 우리가 아무리 NHN의 서비스를 욕하고 정책에 대해서 비판을 해도, 그 안에서 일을 하는 사람들의 노력에는 박수와 격려를 보내줘야 하지 않나 싶었다. 하나의 프로젝트를 위해 만들어내는 문서의 양과 질이 가히 대단했고, 그러한 결실은 또다른 지위의 향상과 업무의 효율성을 기대케 한다. 크게는 HTML과 관련된 마크업과 표준화 작업, 접근성 이슈들의 자료들이 축적되면서 이 직군에 대한 관심과 이해의 깊이를 더욱 깊게 하여 새로운 인력들이 좀 더 쉽고 많이 유입되는 효과를 가지게 하며, 그렇게 우리들 스스로 우리들의 역사를 공고히 만들어 갈 수 있게 된다. 별수롭지 않게 만든, 차라리 귀찮다고 생각해버릴 수 있는 문서화 작업이 가까운 미래에 자신에게는 든든한 벽이 되고, 멀리는 우리 직군의 질적 깊이를 더욱 깊게 해주는 배경이 되지 않을까.

2008년 5월 18일 일요일

만렙 제품을 만들기 위한 게임!

이노베이션 게임 상세보기
루크 호만 지음 | 에이콘출판 펴냄
이노베이션 게임을 통해 고객의 숨겨진 욕구를 찾아내어 혁신적인 제품을 창조한다! 『이노베이션 게임 : 고객의 숨겨진 요구를 찾아내는 12가지 전략 게임』에서는 이노베이션 게임(Innovation Games)이라는, 깜짝 놀랄 만큼 효과적인 방법을 소개한다. 자신의 소프트웨어 제품 전략과 제품 관리 컨설팅 경험을 토대로 루크 호만은 고객의 숨겨진 진짜 욕구를 밝혀내는 12가지 게임을 내놓았다. 이 책에서는 각 게임의 목표와

"게임 하시게요?"

루크 호만의 '이노베이션 게임'이 배송되고, 포장을 뜯자마자 뒤에서 지켜보시던 팀장님이 내게 건낸 말이다. 핑크와 블루, 요란한 표지 디자인과 '게임'이라는 제목이 주는 인상은 마치 진짜 '게임'을 위한 책은 아닌가 싶을 정도였다.

"게임 맞습니다. 아주 특별한 게임입니다"

처음에는 대답하지 못했지만 책을 다 읽고 난 뒤에 난 이렇게 대답할 수 있을것 같다. '이노베이션 게임'은 제목 그대로 '혁신'을 위한 게임이며, 하나의 가이드다. 루크 호먼의 선명하고 뚜렷한 열두가지 방법들을 하나씩 익히고, 적용해 가는 자신과 회사를 생각하면 어느덧 훌륭한 제품이 내 손에 그리고 고객의 손에 들려져 있는 장면을 상상할수 있게 된다.

사실 나는 웹사이트를 개발하는 웹퍼블리셔이며 연구자다. 기획이나 분석, 영업과는 사실 거리가 멀 수도 있었고, 때문에 처음 이 책의 서너장을 넘기는 일이 아주 쉽지만은 않았다고 고백한다. 하지만 다소 (개인적으로) 지루하다고 느꼈던 서두에서 열두개의 '게임'을 다루는 본론으로 넘어가고, 각각의 게임의 의미와 방법, 결과 도출 과정을 살펴보면서(단순히 읽는 것이 아니라 머리속에서 떠올려가며 연상을 하면 훨씬 좋다.) 마지막 장을 덮을 수 있다면 당신은 (당신이 단순히 개발자이건 이 책이 꼭 필요한 분야의 임무를 가진 사람이든) 정말 좋은 지혜와 경험을 얻게 된다고 생각한다.

'이노베이션 게임' 자체는 일반적인 의미에서의 '제품'을 대상으로 하고 있다. 하지만 인터넷 위에서 만들어지는 수많은 웹서비스들 역시 고객에게는 하나의 '제품'과 같다고 생각한다. 따라서 책상머리에서 머리카락을 쥐 뜯어가며 골머리를 썩는 웹기획자들에게는 새롭거나, 또는 '혁신'적인 방법을 제공해주지 않을까 하는 생각도 해본다. 아마도 그들에게 이보다 좋은 만렙 제품(웹서비스 역시)을 만들기 위한 방법을 알려주는 책이 바로 이 책이지 않을까 싶다.

2008년 5월 14일 수요일

다음 UI DevDay 2008 참가해보세요~

다음에서 UI개발자들을 위한 특별한 자리를 마련한것 같네요.
오는 5월 30일 오후에 삼성동 섬유센터에서 위젯과 AJAX, XUL, 액션스크립트등 프론트-앤드 개발자들을 위한 다영한 발표를 준비하고 있어 관심이 가는 행사입니다.

제 직업이 웹퍼블리셔이고 사실 HTML이나 CSS, 웹표준과 관련된 내용이 없거나 부족해서 아쉽기는 하지만 아는만큼 큰다고, 당장에 내 것이 아니라고 모른척 하는 것보다는 다양한 경험과 정보수집을 통해서 배움에 살을 찌우는 것도 나쁘지는 않을것 같습니다. 250명을 추첨해서 받는다고 하니 확률이 낮지는 않겠네요^^

UI 개발 분야의 전문성을 확립하고 생태계 발전을 도모하기 위한 Daum UI DevDay 행사를 개최합니다. 이 행사는 Daum에서 주최하는 UI 기술 행사로써 재미있는 강의도 듣고 Daum UI/RIA 개발자와 만남의 자리를 통해 친목을 나눌 수 있는 자리입니다. 또한 푸짐한 경품과 기념품을 함께 증정해드릴 예정이오니 많은 참여 바랍니다.

uidevday.jpg

Daum UI DevDay

  • 일시: 2008년 5월 30일(금) 오후 1시 30분 ~ 오후 6시
  • 장소: 삼성동 섬유센터 17층
  • 인원: 250명

프로그램 안내

자세한 프로그램은 행사 안내페이지를 참고하세요!

2008년 5월 12일 월요일

form 요소 누구의 것인가?

최근에 제가 참여하고 있는 웹표준스터디모임에서 form 요소와 관련한 내용을 다룬적이 있었습니다.

form 요소가 서버사이드개발자(이하 개발자)들에 의해서 잘못 사용되는 경우와 웹퍼블리셔들이 form 요소를 쉽게 생략하는 문제에 대해서 논의가 있었습니다.

제 생각은 이렇습니다.

첫째로 form 요소는 분명 마크업 요소이고 마땅히 웹퍼블리셔가 사용해야할 태그입니다. 둘째로 내용을 제출하는 폼을 작성했을 경우 그것은 의미적으로 폼에 해당되고, 따라서 웹퍼블리셔는 form 요소를 사용해야 하는 경우에 해당됩니다. (함께 스터디를 하시면서 한 분은 웹개발자가 form 요소를 마음대로 사용하는 것은 오히려 직권남용과 같다! 라고 강하게 말씀하시기까지 했습니다.)

하지만 form 요소가 ASP, JSP, PHP와 같은 서버사이드측 언어와 맞물려 있다보니 많은 경우 웹개발자에게 form 요소를 암묵적으로 위임하여 (웹퍼블리셔는) 이를 생략하는 경우가 있습니다.

적지 않은 시간동안 이러한 관례가 이어지다 보니 요즘은 웹개발자들로부터도 form 요소는 건들지 말아달라는 이야기를 듣기까지 합니다.

이같은 상황에서 현실적인 입장을 보이자면 자연스럽게 웹개발자와의 커뮤니케이션을 강조할 수밖에 없기는 합니다.

웹퍼블리셔와 웹개발자가 프로젝트 기획 단계에서 form 요소 관련 이슈들을 한자리에서 정리하고 HTML 마크업시에는 웹퍼블리셔가 의미에 맞게 form 요소를 작성하고, 개발시에는 웹개발자가 form 요소를 용도에 맞게 사용합니다. 변경시에는 웹퍼블리셔와 다시 또다른 문제가 생기지는 않는지 등 추가적인 이슈에 대한 회의를 가져야 할 것입니다.

화두를 던져놓고 거두어가는 꼴의 글이 되어가는것 같기는 하지만 논의가 너무 깊이 들어가지 않는 범위에서 여러분이라면 어떻게 생각하십니까? 하고 여쭤보고 싶습니다. 자바스크립트를 웹퍼블리셔가 어느정도까지 해야 하는가? 에 대한 고민처럼 form 요소도 웹퍼블리셔가 굳이 작성해야 하는가라고 고민하는 분들이 없지는 않을 것이라고 생각했습니다.

여러분은 form 요소가 웹퍼블리셔의 것이라고 생각하십니까? 아니면 웹개발자에게 위임되어도 좋다고 생각하십니까?

2008년 4월 29일 화요일

웹 표준 경진대회가 열렸습니다.

사용자 삽입 이미지

일전부터 관심을 두고 있었떤 대회인데 무사히 시작될 수 있어서 다행스럽네요.
CDK관계자 분들께서 꽤나 신경쓰시고, 애쓰신 모양입니다. 웹표준이 어느 한 직군만의 책임이 아니니 만큼 웹퍼블리셔분들 뿐 아니라 웹디자이너와 개발자 분들도 많은 관심을 갖고 함께 참여해 주셨으면 합니다.

자세한 정보는 CDK 웹사이트웹표준 경진대회 공식 사이트 에서 확인해 보실 수 있습니다.

다음은 자세한 대회 내용입니다.

누군가가 시켜서 만드는 웹, 누구를 위해 만드는 것인지 알 수 없었던 웹은 이제 우리 자신과 보다 많은 사람들을 위해 개선되어 나가야 합니다. 더 많은 사람들이 더 좋은 방법을 이용하여 웹 사이트를 제작하고 사용할 수 있어야 하고, 시대가 이런 점을 이미 요구하기 시작했습니다. 이제는 가르치고 배우는 과정을 넘어 더 많은 사람이 보다 손 쉽게 이용할 수 있는 웹 표준으로 나아가야 할 것입니다. '규칙과 창조의 만남'이라는 슬로건처럼 웹 표준이라는 규칙을 지킴으로써 사이트가 얼마나 창조적으로 유연하게, 얼마나 더 편리해질 수 있는지를 많은 사람들이 알 수 있게 될 것입니다.

CSS Design Korea에서 주최하고, Hosting.kr, 에이콘출판사, 디지털미디어리서치가 후원하는 이번 대회는 2008년 5 월 1일부터 약 한달간 진행되며 2008년 6월 예정인 세번째 웹 표준의 날에 그 대미를 볼 수 있게 됩니다. 우리가 원하는, 모두를 위한 웹을 만들어가려는 이번 행사에 많은 분들의 참여를 기대합니다.

참가자격
개인 혹은 3인 이내로 구성된 팀
참가방법
제시된 콘텐츠(인터넷 웹 콘텐츠 접근성 지침)를 웹 페이지로 작성하여 소정의 페이지를 통해 접수

1. 주어진 내용 전체를 사이트의 콘텐츠로 활용해야 합니다.
2. 사이트의 형식은 자유롭게 작성할 수 있습니다. (일반적인 정보 제공 형태의 사이트, 블로그 등)
3. 최소한 1개 이상의 메뉴 형식이 포함되어야 합니다.
4. HTML, CSS, Javascript와 이미지 파일만 허용되며 각각의 고유 확장자를 사용해야 합니다. (.html, .css, .js, jpg, .gif, .png 등)
5. 최종 작업물은 로컬에서 열었을 때 정상 동작할 수 있도록 작성되어야 합니다.
6. 최종 작업물과 스크린샷을 압축하여 참가 신청서에 첨부해야 합니다.
평가방법
100점기준
Markup(35) / CSS(30) / 디자인(20) / 기타(15)
시상내역
대상(1팀) : iPod Touch 8Gb + Hosting.co.kr(도메인/호스팅 3년 이용권)
금상(1팀) : iPod Touch 8Gb + Hosting.co.kr(도메인/호스팅 1년 이용권)
은상(2팀) : 웹 표준 완전정복 세트
동상(5팀) : 웹 표준의 교과서

* 입상팀을 제외한 참가자 전원에게 Web Standards day 컵(소량으로 참가 신청순에 의하여 지급 될 수 있습니다. )과 Hosting.co.kr(웹 호스팅 1년 이용권) 지급

출품기간
2008.5.01~6.01
결과발표
2008.6.15 (입상시 개별 통보)

DTD 어떻게 읽는지 아세요?

웹표준과 관련된 글들을 올리면서 가장 많이 언급하는 것이 HTML 문서의 DTD이다. 기본적으로 HTML에는 3.2, 4.0, 4.01이 나와 있고, XHTML 1.0과 1.1이 발표되었다. 그런데 HTML 4.01이라고 다 같은 HTML 4.01이 아니고, XHTML 1.0이라고 해서 똑같은 XHTML 1.0이 아니라는데 애로가 있다. 각 버전에는 문법에 대한 엄격성에 따른 DTD가 존재하는데 다음과 같다.

more..


현재 가장 많이 사용되고 있다고 볼 수 있는 DTD를 열거했는데, 크게 보면 HTML 4.01과 XHTML 1.0에 가장 엄격한 문법 준수를 요구하는 Strict, 하위 버전과의 호환성을 보장해주는 Transitional, 프레임셋을 위한 Frameset 타입 세가지로 구성되어 있다. XHTML 1.1에 와서는 의미적으로 Strict 타입만을 지원하며 표기는 위와 같이 한다. 아울러 가까운 미래에 나오게 될 HTML 5 에서는 단순히 <!DOCTYPE html> 라고만 정의하면 그만이게 된다.

DTD는 HTML 문서가 어떠한 구조로 작성되어야 하는지를 명시적으로 정의하는 스펙으로 표준화된 방법을 제안하고 있다. 따라서 우리가 위의 7가지 DTD중 하나를 선택해서 HTML 문서를 작성했다면 해당 DTD가 명시하고 있는 문법 규칙을 올바르게 따라야 오류가 없는 무결한 HTML 문서를 만들수 있게 된다. HTML 문법과 관련된 웹사이트 강좌나 서적이 이미 많이 나와 있고, 완성된 HTML 문서의 유효성 검증(Validation)을 실시해 주는 서비스도 여럿 존재기 때문에 작업에 어려움은 없지만 기왕에 HTML을 다루는 직업을 가졌다면 자신이 사용하는 DTD의 내용을 읽고 이해할 수는 있어야 하지 않을까 하는 생각이 든다. (많은 사람들이 위 DTD를 입맛 따라 골라서 복사해서 붙여놓고 쓸 줄만 알지 어떤 내용인지는 신경쓰지 않는것 같다) 그래서 이 글은 DTD를 읽고 이해하는 방법을 설명하고자 한다.

W3C HTML 4.01 Specification3.3 How to read the HTML DTD 에서 HTML DTD를 어떻게 읽을 것인지를 간단히 설명하고 있다.

사용자 삽입 이미지

  1. 주석(Comment)
    주석은 한 줄 또는 여러 줄이 될 수 있고, 선언문 내에서 연속된 하이픈(-) 두개를 주석내용의 앞과 뒤에 위치시켜서 쓸 수 있다.
    ※ XHTML DTD는 선언부 내 하이픈(-) 주석을 사용하고 있지 않다.

  2. 파라메터 엔티티(Parameter Entity)
    어려운 용어로 정의되어 있는데 파라메터는 매개변수를 말하고, 엔티티는 대체문자를 말한다. 간단히 설명하면 미리 정의된 변수를 대체문자로써 사용하겠다라는 뜻이다. 다시 말해 %attrs;이라는 엔티티에는 이미 style, class, alt, title과 같이 거의 모든 엘리먼트에 포함되는 속성명들을 정의해 놓고 있어서 이후에 정의하는 엘리먼트에서는 단순히 %attrs;이라고만 정의하면 된다라는 의미다. 프로그래밍을 해보신 분이라면 쉽게 이해하실수 있을것 같다. x라는 변수에 숫자 '3'을 미리 기억시켜 놓고, y = x + 2 라는 프로그래밍을 하게 되면 y의 값은 미리 기억된 x의 값 '3'을 불러와 합산을 해서 '5'라는 결과를 보여주는 것과 같다.

  3. 엘리먼트(Element)
    엘리먼트는 이름과 태그, 컨텐츠 모델(Content Model)로 구성되어 있다. 엘리먼트 이름은 HTML 문서에서 실제로 사용되는 태그의 명칭이 되고, 두번째 나오는 '- O'은 시작태그와 종료태그의 형태를 기술한 것이다. 하이픈(-)일 경우에 태그는 사용되어야 하고, 'O(Omitted)'일 경우에는 생략이 가능하다. 위의 경우에는 시작태그는 필요하고, 종료태그는 생략할 수 있다고 기술한 것이다. 세번째 컨텐츠 모델은 어떤 내용을 갖을 것인가? 하는 것을 기술한다. 위에서는 파라메터 엔티티로 정의된 %inline;과 %flow;가 DT 엘리먼트와 DD 엘리먼트에 각각 기술되어 있고, 괄혹 속에 들어가 있는 것을 볼 수 있다. 또, 애스테리스크(*, 별표)가 붙어 있는 것을 볼 수 있다. 좀 더 쉬운 예를 보자.

    <!ELEMENT DL - - (DT | DD)+>

    DL 엘리먼트를 정의한 것인데 괄호안에 'DT'와 'DD'가 있고, 플러스(+)표시가 붙어 있다. 당연히 알고 있겠지만 DL 엘리먼트에는 DT 요소와 DD 요소를 자식요소로 가질 수 있고,  한 번 이상 쓰일 수 있는데 그것을 위와 같이 기술한 것이다. 정의된 엘리먼트의 괄호는 내용의 그룹이 되며, 산술 기호는 등장 횟수가 된다. 다음과 같은 기호들이 사용된다.

    ( ... ) : 그룹 제한
    A : 오직 A 하나만 나타날 경우
    A+ : A 가 무조건 한 번 이상 나타나는 경우
    A? : A 가 생략되거나 한 번 나타나는 경우
    A* : A 가 생략되거나 한 번 이상 나타나는 경우
    +(A) : A 를 포함할 수 있는 경우
    -(A) : A 를 포함할 수 없는 경우
    A | B : A 또는 B, 둘 다는 아닐 경우
    A , B : A 와 B가 순서대로 나타나는 경우
    A & B : A 와 B가 순서없이 모두 나타나는 경우


    IMG 요소나 BR 요소와 같이 내용을 포함하지 않는 요소의 경우에는 'EMPTY'라고 정의하고, 문자열 이외의 자식 요소를 포함하지 않는 경우(OPTION 요소)에는 '(#PCDATA)'와 같이 정의한다. 또한, A 엘리먼트와 같이 자식요소에 자신을 포함하지 못하는 경우는

    <!ELEMENT A - - (%inline;)* -(A)>

    와 같이 정의한다.

  4. 애트리뷰트(Attribute)
    애트리뷰트를 설명하기 위해서 IMG 요소의 정의 부분을 보겠다.
    <!ATTLIST IMG
      %attrs;                              -- %coreattrs, %i18n, %events --
      src         %URI;          #REQUIRED -- URI of image to embed --
      alt         %Text;         #REQUIRED -- short description --
      longdesc    %URI;          #IMPLIED  -- link to long description
                                              (complements alt) --
      name        CDATA          #IMPLIED  -- name of image for scripting --
      height      %Length;       #IMPLIED  -- override height --
      width       %Length;       #IMPLIED  -- override width --
      usemap      %URI;          #IMPLIED  -- use client-side image map --
      ismap       (ismap)        #IMPLIED  -- use server-side image map --
      >

    애트리뷰트의 이름과 타입, 디폴트 값을 정의한 것을 볼 수 있다. src 애트리뷰트와 longdesc 애트리뷰트는 미리 정의된 URI 타입으로 되어 있고, alt 애트리뷰트 역시 Text 엔티티로 되어 있음을 볼 수 있다. 애트리뷰트에서 중요한 것은 디폴트 값으로 지정되는 네가지 값인데 다음과 같다.

    #REQUIRED : 반드시 정의해야 하는 애트리뷰트이다.
    #IMPLIED : 디폴드 값을 사용도구(웹 브라우저 등)가 지정하며, 경우에 따라 부모 엘리먼트로부터 상속 받는다. 반드시 정의하지 않아도 된다.
    #FIXED : 값이 일정하여 변경이 없는 애트리뷰트이다. HTML 4.01 의 경우에는 없으나 XHTML의 경우에는 xmlns 애트리뷰트와 xml:space 애트리뷰트가 'http://www.w3.org/1999/xhtml' 값으로 #FIXED 되어 있다.

    애트리뷰트 가운데에는 '참'과 '거짓'의 형태로 구분되는 불린(Boolean) 애트리뷰트가 존재하는데 'selected' ,'checked' 와 같은 것들이다.

    <!ATTLIST option
      %attrs;
      selected    (selected)     #IMPLIED
      disabled    (disabled)     #IMPLIED
      label       %Text;         #IMPLIED
      value       CDATA          #IMPLIED
      >


    위와 같이 이러한 불린 애트리뷰트는 자신의 이름을 값으로 가질 수 있도록 정의되어 있다. HTML 4.01에서는 불린 애트리뷰트의 약술을 허용하고 있기는 하지만 XHTML 에서는 옮은 표현이 아니기 때문에 가급적 사용하지 않은 것을 추천한다.

나는 예전에 DL 요소의 자식요소인 DT와 DD가 순서대로 나와야 하는가? 에 대한 의문을 가진 적이 있었다. 의미적으로 DT 요소가 나온 후 DD 요소가 나타나는 것이 맞겠지만 실제로는 둘을 바꿔도 오류를 내지 않았기 때문이었고, 레이아웃을 잡기 위해서 임의적으로 포지셔닝을 하다보니 DT 요소와 DD 요소를 서로 바꾸는 것이 더 편할 때가 있었다. 그런데 잘 기억이 나지는 않지만 어떤 서적인가 사이트에서 DT 요소와 DD 요소는 순서대로 나타나야 한다고 되어 있었던 것을 본 적이 있어 혼자 고민했던 적이 있었다. 그리고는 우연히 해당 DTD 문서를 열어보게 되었는데 다음과 같다.

HTML 4.01 : <!ELEMENT DL - - (DT|DD)+ -- definition list -->

XHTML 1.0 : <!ELEMENT dl (dt|dd)+>

위에서 설명했던 내용을 토대로 이해를 해보자. DL 이라는 이름으로 엘리먼트가 정의 되었고, 시작태그와 종료태그를 모두 가져야 하며, DT 요소 또는 DD 요소가 순서에 상관 없이 한 번 이상 나타날 수 있다고 되어 있다. 순서는 문제가 되지 않았다는 것이다.

이렇게 DTD는 불확실한 정보에 대한 확신을 심어줄 수 있는 최고의 레퍼런스이다. 온전하게는 아닐지라도 대략적으로 DTD를 읽고 이해할 수 있는 능력을 키운다면 새로운 마크업 언어를 익히는 일이 두렵지만은 않을 수 있지 않을까- 그런 생각을 끝으로 DTD를 읽는 방법을 정리해 보았다.


덧붙임.

정찬명님께서 제 글을 보신 후 보다 더 자세하고 친절하게 'HTML DTD 읽기' 방법을 정리해 주셨습니다. 꼭 읽어보시길 바라겠습니다.