이 글은 Accessible Culture의 Programmatically Determined라는 글의 일부 발번역과 나의 견해가 포함된 글임을 알린다.

프로그래밍 방식으로 결정

"프로그래밍 방식으로 결정" 이라는 문구는 61개의 WCAG 2.0 성공 기준 중 6개에서 눈에 띄는 항목이다. 그것은 아마 처음으로 접근성과 WCAG를 접하는 사람들에게는 약간은 어려울지 모르겠지만, 사실은 그렇게 복잡하지는 않다. 사실, 당신이 이 문구 자체에 익숙하지 않더라도 당신은 이미 그것을 다루고 있을 것이다.

어쨌든, 난 "프로그래밍 방식으로 결정"이 웹 개발자들에게 WCAG에 관해 웹 접근성이란 무엇이며 왜 HTML의 적절한 사용이 중요한지 설명할 때 상당히 유용한 개념이라고 생각한다.

HTML에 포함

일반적인 웹 페이지 내용의 기반은 물론 HTML 마크업이다. 제대로 사용하면 그것은 의미론적 구조 그리고 콘텐츠 간 연관 관계 및 차이점을 식별하는 역할을 한다.

대부분의 사람들은 웹 페이지의 HTML을 보지 못한다. 그러나 웹 페이지에 액세스하는 데 사용되는 브라우저는 페이지의 콘텐츠를 이해하기 위해 HTML에 의존한다. HTML은 브라우저에게 다음과 같은 것들을 알려준다.

• 이 콘텐츠는 단락으로 이루어저 있고 2레벨 제목 아래에 제공되고 있다.
• 이것은 5개의 항목을 가진 순서 있는 항목의 3번째 항목이다.
• 이것은 텍스트 입력 필드이고 어떤 이름을 가지고 있다.
• 이것은 그 웹 사이트의 저 페이지로 이동할 수 있는 링크이다.
• 이 웹 페이지는 불어로 되어 있다. 단 이 문장은 영어 등으로 구성되어 있다.

콘텐츠 구조와 관계에 대한 정보를 제공하는 것은 어떻게 HTML이 설계 되었는지와 그것을 사용하기 위한 방법에 대한 기본적인 부분이다.

우리는 그것을 '프로그래밍 방식으로 결정'이라고 부른다.

콘텐츠가 HTML로 적절히 마크업 된 경우, 그 의미론적 구조와 관계는 마크업 자체에 포함된다. 즉, 그것들은 "프로그래밍 방식으로 결정"될 수 있다. 말하자면 이러한 정보는 코드에 포함되기 때문에 지원 기술은 프로그램을 통해 그것을 해석하여 사용자에게 다른 방식으로 제공할 수 있다. 이 정보는 "다른 감각 형식(예. 비주얼, 음성) 혹은 개인 사용자들의 요구에 맞는 표현 양식으로 변경"될 수 있다. 이것이 접근성 있는 웹 콘텐츠와 WCAG 2.0의 핵심 컨셉의 중요한 측면이다.

이러한 정보는 브라우저를 통해 다양한 디바이스 혹은 소프트웨어가 그것을 이용 가능한 형태로 전달될 수 있다. 스크린리더, 음성 인식 소프트웨어, 대체 입력 장치 등이 각각의 콘텐츠가 무엇인지 이야기하고 사용자가 적절하게 그것들과 상호 작용하도록 할 수 있다.

위의 인용문은 WCAG 등 웹 접근성 규격에서 말하는 "프로그밍 방식으로 결정"이 무엇인지를 설명하고 있다.

쉽게 말해 HTML을 의미에 맞게 작성하면 브라우저나 보조 기기에서 그 의미를 해석하여 나름대로 가공하여 사용자에게 전달할 수 있고 이것은 곧 해당 콘텐츠가 "프로그래밍 방식으로 결정"될 수 있다고 할 수 있다.

링크를 a 요소가 아닌 span 같은 요소로 구현하고 키보드 접근성을 위해 tabindex를 0으로 주고 자바스크립트로 링크처럼 구현했다고 치자. 자바스크립트 비활성화 경우는 차치하고 무슨 문제가 있을까? 결론은 해당 링크가 "프로그래밍 방식으로 결정"되지 못한 것이 문제이다. 사용자는 링크처럼 클릭해서 사용할 수 있지만 브라우저나 보조 기기는 해당 콘텐츠가 링크인지 알 수가 없다는 것이다.

이 문제는 브라우저나 보조 기기가 링크를 가공할 때 도드라진다. 가령 브라우저는 링크를 우클릭할 경우 즐겨찾기에 추가, 새 창으로 열기 등 관련 편의 기능을 제공하고 스크린리더는 링크만 모아서 제공하거나 "무슨 무슨 링크"라고 읽어주는 등의 기능을 제공하는데... 위의 경우 그것이 불가능하게 된다.

결론 요약

가능하다면, 적절한 HTML 요소와 속성을 사용하라. 내용의 구조와 관계가 표현되게끔 마크업을 작성하라.

• 그것은 어떤 종류의 콘텐츠인가?
• 주위 콘텐츠와의 관계는 무엇인가?
• 기능을 제공하는 경우 그것은 무엇을 하는가? 이름, 역할, 상태, 그리고 값이 마크업에 드러나는가?

이러한 질문에 대한 답변을 HTML과 WAI-ARIA 마크업만으로 명확하게 제공된다면, 이는 곧 이와 같은 정보가 브라우저에 의해 프로그래밍 방식으로 결정되는 것이고 이는 곧 보조 기술 및 장치를 지원한다는 것을 뜻한다.

결국 인용한 글의 결론과 같이 의미있는 웹 콘텐츠가 있을 때 해당 의미가 HTML에 포함되도록 HTML 코드를 만들면 "프로그래밍 방식으로 결정"이라는 명제를 만족할 수 있다.

Microformat이 뭐냐고? NULI 블로그에 아마티님이 좋은 소개글을 작성하신 바 있으니 참고하면 되겠다.

facebook 이벤트에 추가된 Microformat은 이벤트에 hCalendar가 추가된 것, 그리고 이벤트 장소에 hCard가 추가된 것이다. hCard도 추가되었다고 해서 액티비티나 댓글 등에 있는 모든 프로필 정보에 hCard가 추가되었나 했더니 그건 아니었다.

Microformat은 Microformat이 사용된 웹 문서가 엄청나게 많아지기 전에는 크게 활용성이 떨어진다. 반대로 활용성이 떨어지는 Microformat을 굳이 웹 문서에 넣으려고 하는 제작자는 별로 없다. 그런 의미에서 facebook에 있는 수백만개의 이벤트가 Microformat으로 제공된다는 것은 활용성 측면이나 제작자들에게 미치는 영향이 클 것이다.

일정이나 연락처 등의 서비스들을 제공하고 있고 툴바나 브라우저 확장기능 같이 Microformat을 당장 써먹을 수 있는 제품을 갖고 있는 우리나라 포털 업체들에게는 참 ROI가 높은 맛있는 먹잇감일텐데… 누가 먼저 물라나… ㅋ

facebook에 Landmark Role이 추가된 건… 길게 쓸 건 없을 것 같고… 참 쉬운데… facebook도 넣는데… 안 넣는 게 이상한거다. 게다가 WAI-ARIA는 벌써 CR(Candidate Recommendation)! ㅋ

Landmark roles는 정적인 웹 페이지에 책갈피를 달아놓은 것이라고 설명할 수 있다. 이는 HTML을 스타일링하지 않아도 어느 부분이 메인 컨텐츠 영역인지 사이드바(부가 정보) 영역인지 메인 메뉴(내비게이션) 영역인지 명확하게 구분하도록 해준다.

Landmark roles는 현재 다음의 8종류가 있다.

• application: 웹 응용 프로그램에 선언한다. 여기서 웹 응용 프로그램이란 GMail, SVG와 같은 정적인 웹 문서와 반대되는 개념이다. 스펙에 따르면 보조 기기는 이 선언을 만나면 브라우저 탐색 키를 웹 어플리케이션에게 돌려줘야 한다고 한다. (이 개념에 대해서는 독립 주제로 다루어야 할 정도네요.)
• banner: 사이트의 로고(최초의 헤딩) 또는 내부 페이지의 제목을 포함하는 영역. 이 영역의 컨텐츠는 대체로 사이트 전체에 걸쳐 동일하다.
• complementary: 문서의 독립적이고 부가적인 컨텐츠 영역. 메인 컨텐츠에서 분리되어도 그 자체로 의미가 있는 영역이다. 보통 메인 컨텐츠의 오른쪽에(서브메뉴가 왼쪽일 경우) 포함되는 컨텐츠를 이 영역으로 분류할 수 있다. HTML5의 aside 요소와 대응된다.
• contentinfo: 상위 문서에 적용되는 메타데이터를 의미한다. (스펙의 설명은 이렇고 쉽게 말하자면 저작권, 사이트 관련 연락처 - 주소, 전화번호, ... - 등이 포함된 푸터를 이 영역으로 분류할 수 있다.) HTML5의 footer 요소와 대응된다.
• form: 폼 전송 영역(말 그대로 폼). 다만, search role에 해당되는 폼은 제외.
• main: 문서의 메인 컨텐츠. 반드시 1번만 선언되어야 한다.
• navigation: 메뉴(내비게이션 묶음) 영역. HTML5의 nav 요소와 대응된다.
• search: 문서 검색 툴을 의미하며 보통 통합 검색 영역을 지정할 수 있다. 추가로 우리나라에서 통용되는 게시판 목록의 검색 폼에도 사용하면 좋을 것이라고 생각한다.

Landmark roles 작성법은 여기까지다. 정말 쉽지 않은가?

그런데 landmark roles를 쓰면 뭐가 좋은걸까?

우선, 보조 기기의 사용성이 향상된다. Screen Readers And WAI-ARIA Landmark Roles라는 글에 따르면 현재 스크린리더 중 Jaws와 NVDA에서 landmark roles를 지원한다. Landmark roles를 지원하는 스크린리더 사용자는 landmark role간을 탐색하는 핫키를 이용하여 영역을 탐색할 수 있다. 문서를 순차적으로 읽어내려가는 스크린리더 사용자에게 이는 스킵 내비게이션과 비교했을 때 훨씬 유용한 것으로 생각된다. 스킵 내비게이션은 물리적으로 문서의 맨 처음에서만 접근 가능한 대신 landmark role은 필요할 때 핫키를 통해 문서의 주요 시작점을 자유롭게 탐색할 수 있기 때문이다.

참고한 글들 중 보조 기기의 사용성 향상 이외에 다른 장점에 대해 언급한 것은 없다. 그래서 아래에 개인적으로 생각한 장점들에 대해 나열해본다.

첫째, 사람이 HTML 코드를 이해하기 쉬워진다. 굳이 주석을 달지 않아도 어느 태그가 메인 영역을 감싸고 있고 어느 태그가 푸터 영역을 감싸고 있는지 코드로 설명된다. 쓸데없는 주석이 줄어들 수 있겠다.

둘째, 기계가 HTML 코드를 이해하기 쉬워진다. 웹 페이지의 일반적인 레이아웃 구조가 프로그래밍 방식으로 결정 되는 것이다. 예를 들어 검색엔진 입장이라면 극단적으로 main landmark의 컨텐츠만 검색하거나 아니면 main landmark의 컨텐츠의 중요도를 높게 취급한다면 검색 품질의 향상을 꾀할 수 있을 것이고 브라우저는 인쇄용 CSS를 메인 컨텐츠용으로 따로 준비하지 않았다고 하더라도 "메인 컨텐츠만 인쇄하기" 같은 메뉴를 제공할 수 있을 것이다. 또 나같이 지저분한 사이트(광고로 도배된 신문사 사이트)를 혐오하는 사람들을 위해 부가 정보(complementary role) 숨기기 같은 옵션을 제공할 수도 있을 것이다.

셋째, Landmark roles라는 약속된 규칙에 의해 이정표를 삽입하는 것이기 때문에 Landmark roles를 지원하는 웹 페이지들은 일관성 있는 탐색을 보장할 수 있게 된다.

센스리더에서는 지원하지 않지만 이미 iPhone에 내장된 스크린리더인 VoiceOver에서 지원중이다. 게다가 적용하는게 망설일 필요도 없을 만큼 쉬운 것이 landmark roles다! 이미 만들어져 있는 사이트도 5분만 투자하면 바로 적용할 수 있을 것이다!

<link rel="canonical" href="http://example.com/page.html" />

위의 코드를 넣어주면 끝입니다. 간단하죠? 단어 그대로 표준 혹은 대표 링크를 선언해주는 것입니다. 이미 많은 발표자료, 동영상 등이 공개되어 있네요. 보시죠~ 참고로 첫 링크만 보시면 정리가 다 됩니다. :)

• Learn about the Canonical Link Element in 5 minutes
• Specify your canonical – Google Webmaster Central Blog
• Fighting Duplication: Adding more arrows to your quiver – Yahoo! Search Blog
• Partnering to help solve duplicate content issues – MS Live Search Webmaster Center Blog

쬐금 공부해본 결과물을 공유합니다. 이미지의 모서리를 둥글게 하는 스크립트 예제입니다. 사용한 이미지가 조금 거시기하니 뭐 드시는 중이시거나 비위가 약한 분들은 조심하세요. -_-;;

원래 animated gif 파일인데 canvas를 사용하면 안되네요. 안되는건지, 제가 방법을 못 찾은건지… 원본이 궁금하신 분들은 원본 이미지를 보셔요. ㅋㅋ

기능 소개

Wrap Selection, Wrap Selection Each Line은 리스트 마크업 – <ul>, <ol> – 을 작성할 수 있게 해주는 TextMate의 기능이다. 텍스트를 복사해넣은 후 각 줄의 시작과 끝에 <li> 태그를 넣는 수고를 크게 덜어주는 편리한 기능이다.

Aptana에 기능 추가

1. 운영체제에 맞는 스크립트 압축파일을 다운로드 받는다.

   • 윈도우(Windows), 유닉스 계열(Unix, Linux, …)용 Aptana Wrap Selection 스크립트
   • 맥(Mac)용 Aptana Wrap Selection 스크립트
2. scripts 혹은 monkey라는 이름으로 존재하는 프로젝트 중 하나의 최상위에 폴더를 만들고 다운 받은 스크립트 파일들을 이동시킨다.

기능 시험해보기

맥의 경우 Command + Ctrl + W 키 조합이 선택한 텍스트 전체를 하나의 태그로 감싸는 기능이고, Command + Ctrl + Shift + W 키 조합이 선택한 텍스트의 각 줄을 지정한 태그로 감싸는 기능이다. 맥이 아닐 경우 Command 키 대신 Alt 키를 조합하면 된다.

1. 
   몇 줄의 텍스트를 준비한다.

2. 
   Command(or Alt) + Ctrl + Shift + W 키 – Wrap Selection Each Line – 를 누른다.

3. 
   기본으로 설정되어 있는 li 태그를 확인 후 엔터를 누른 후 각 줄이 li 태그로 쌓인 것을 확인

4. 
   Command(or Alt) + Ctrl + W 키 – Wrap Selection – 를 누른다.

5. 
   기본으로 설정되어 있는 ul 태그를 확인 후 엔터를 누른 후 전체가 ul 태그로 쌓인 것을 확인

스크립트 추가하기

Aptana를 좀 더 강력하게 해주는 Eclipse Monkey Script는 간단하게 작성하고 추가할 수 있다. Aptana 홈페이지의 Eclipse Monkey 관련 페이지 혹은 필자가 작성한 스크립트를 보면 자바 스크립트를 조금 다뤄본 사람이면 어렵지 않게 자신이 원하는 기능을 추가할 수 있을 것이다.

정보를 꾸며주기 위한 <img> 태그

<img> 태그는 사전적으로는 정보를 지닌 – 의미 있는 – 시각 요소를 문서에 삽입하기 위한 태그이지만, 앞서 언급한 표현의 제약으로 인해 폰트 등을 원하는 대로 표현하기 위한 용도로 사용하기도 하다. 예전부터 – 대다수의 웹 제작자들이 마크업을 표현을 위한 용도로 사용하던 시절부터 – 국내의 거의 모든 사이트들이 사용하는 방법이기도 하다.

문제점

우선 <img> 태그의 남용이 마크업의 의미를 떨어뜨린다. 단순 텍스트와 <img> 태그는 기본적으로 의미하는 바가 다르다. 이미지 검색엔진의 결과물로 나타나는 수많은 텍스트 꾸밈용 이미지들을 보면 <img> 태그의 남용이 잘못된 마크업이라는 생각을 할 수 있다.

또, 남용된 <img> 태그는 구조와 표현의 분리라는 CSS의 목적을 달성하는 데 장애물이 된다. 마크업에 박혀있는 특정 시각 디자인 결과물을 위한 <img> 태그들은 다양한 표현의 걸림돌이다. <img> 태그가 남용된 사이트에서 프린트를 위한 CSS를 제작한다면 그 결과물은 어쩔 수 없이 스크린의 그것에서 크게 달라질 수 없을 것이다. 스크린 디자인을 위해 사용된 <img> 태그의 모양새는 바꾸기가 어렵기 때문이다.

CSS를 이용한 이미지 대치법(Image Replacement)

문제점

앞서 언급한것처럼 <img> 태그는 많은 문제점이 있지만 CSS를 이용한 이미지 대치법 역시 많은 문제를 가지고 있다. 가장 대표적으로 대다수의 이미지 대치법이 텍스트를 숨기거나(display: none;) 화면 밖으로 위치시키는 방법(text-indent: -999em;)을 사용하기 때문에 CSS 활성화·이미지 비활성화 상태에서 화면 상에 아무것도 출력하지 못하며 이 방법을 프린트용 CSS에 동일하게 적용하였을 때 보통의 웹 브라우저들이 기본적으로 배경 이미지를 출력하지 않기 때문에 백지 상태의 인쇄물을 보게되는 경우가 생긴다. (<img> 태그 사용시에는 사용자가 의도하지 않은 사이에 프린터의 잉크나 토너가 낭비된다!)

약간의 해결책

CSS 활성화·이미지 비활성화 상태의 경우 Gilder/Levin의 방법이나 Gilder Levin Ryznar Jacoubsen의 방법을 통해 해결할 수 있다. 하지만 이 방법은 이미지 뒤에 가려진 텍스트가 표시될 수 있는 충분한 공간이 확보되지 않으면 무용지물이 될 수 있다. z-index를 이용한 이미지 대치법도 하나의 방법인데 대치할 요소의 부모 요소에 배경색이 들어가있거나 한 경우에 문제가 생길 수 있다. 그리고 앞의 방법들과 마찬가지로 텍스트의 공간에 대한 문제가 있다. 그리고 이 모든 방법들은 의미없는 추가적인 마크업을 필요로 한다.

프린트 시의 문제는? 프린트용 CSS를 별도로 제작하면 바로 해결된다. 설마 로고와 메뉴가 덕지덕지 붙은 화면을 사용자에게 그대로 출력시키게 하는 것을 그냥 지켜보고 있다면 바로 당신이 관리하는 사이트에 프린트용 CSS를 추가하라.

어떤 것을 선택하느냐?

<img> 태그, 이미지 대치법(Image Replace). 이 방법들 중 어떤 것도 완벽하지 않다. 다만 각 방법들이 서로 다른 문제를 가지고 있고 어떤 것을 선택하느냐에 앞서 이 방법들의 문제점들에 대해 이해한 후에 선택하는 것이 필요하다.

자바스크립트를 통한 IE의 <button> 태그 버그 극복

<button> 태그가 IE에서만 문제가 되고 있고 IE는 특별한 조치 없이는 자바스크립트를 기본적으로 사용하기 때문에 자바스크립트를 통해 IE의 버그를 극복할 수 있다고 생각되었다. 그래서 찾아보니 Multiple Buttons IE Workaround라는 글이 있었다. 이 글이 제시하는 방법은 버튼을 클릭할 때 value 속성(값)을 IE의 버그로 인한 값에서 정상적인 값으로 돌려주는 것이었는데 이것은 폼의 제출 시에는 정상적으로 작동할 수 있으나 onsubmit 이벤트에서 폼 제출을 중지하는 경우 등의 상황에서 얘기치 않은 결과를 가져왔다.

IE Button Fix

그래서 위의 단점들을 해결하고 여전히 문제를 가지고 있던 IE5까지 해결한 IE Button Fix를 만들었다. 문제를 해결하면서 새로운 제약사항이 생겼는데 이는 사용시에 사용할 웹 사이트의 성격과 제약사항을 잘 파악하여 사용여부를 판단할 수 있을 것이다.

<button> 태그는 <input> 태그에 비해 많은 장점을 갖는다. IE의 버그는 그 동안 이래저래 <button> 태그의 장점을 사용할 수 없도록 제한해왔지만 IE Button Fix가 이를 어느정도 보완해줄 수 있으리라 생각한다.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That’s actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 still, more than ten years later, hasn’t reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren’t interoperable, and the spec has hundreds if not thousands of known errors that haven’t been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

HTML5가 W3C 권고안(Recommendation)이 되는 시점은 2022년 혹은 그 이후가 될 것으로 추정됩니다. 이것은 2004년 중반에 시작하여 대략 18~20년의 개발 기간이 되는 것입니다. 그것은 사실 그렇게 황당한 게 아닙니다. HTML4의 작업은 90년대 중반에 시작하여 10년이 넘었지만 아직 우리가 HTML5를 통해 도달하고 하는 레벨에 이르지 못했습니다. 실제 테스트 슈트가 없고, 많은 부분의 스펙이 현실에 충족하기에 부족하고, 수백·수천의 알려지지 않은 오류가 수정되지 않았습니다. HTML4가 나왔을 때, 권고안은 현재의 그것보다 훨씬 흥미가 작아졌습니다.

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

현재 어떤 스펙이 권고안이 되기 위해서는, 100%의 완성도와 완벽한 상호 작용이 필요합니다. 이 말은 각각의 요소가 수천번의 테스트 케이스를 완전하게 통과함을 뜻합니다(대략적으로 20,000개의 테스트가 필요할 것으로 추정됩니다). 당신이 그런 많은 테스트 케이스를 작성하는 데에 걸리는 시간을 고려한다면 각 기능을 구현하는 시간이 얼마나 걸릴지 이해할 수 있을 것입니다.

(In the interests of full disclosure, the W3C’s official line is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, as of December 2007 the W3C had already missed the first milestone on that same timetable, First Public Working Draft, by 6 months, with no reason to believe publication would come soon. You can make your own judgements regarding the W3C timetable’s credibility.)

(완전한 공개를 위하여 W3C의 공식적인 라인은 HTML5 스펙이 2010년 말에 상호 운용성을 보장하며 완료될 것이라고 합니다. 그러나 2007년 12월 현재 W3C는 이미 같은 스케줄에 표시된 공개 초안 초판(First Public Working Draft)이라는 첫번째 마일스톤을 6개월이나 놓치고 있습니다. 게다가 이 마일스톤은 곧 출시될 것이라고 믿을만한 이유가 없습니다. 여러분은 W3C 스케줄의 신뢰성에 대한 심판을 스스로 할 수 있을 것입니다.)

FAQ의 When will HTML5 be finished(HTML5는 언제 완료되나?)

위의 번역은 정확하지 않을 수 있음.

생각해보면 이전에도 W3C의 스케줄은 그다지 신뢰를 주지 못했던 것 같다. CSS3의 스케줄만 해도 예정이 1년이상 지난 것들이 많다. HTML5의 Milestone – 2008년에는 W3C에서 초안으로 라는 글을 얼마전에 썼었는데 W3C HTML Working Group의 마일스톤은 수정되어 있다. 그것도 꽤나 큰 기간 차이를 가지고 – 마무리 시점은 동일하지만.

그러나 위에 언급한 2022년이라는 숫자에 놀랄 필요는 없다. 글 내용에도 나왔듯 HTML4 조차 아직도 부족함이 있고 – 정확히 무엇이 부족한지는 잘 모르겠다 – 실제로 2010년 정도가 되면 어느정도 기기나 브라우저들이 지원해 줄 것으로 생각된다. 물론 그 때도 거의 대다수가 HTML4 혹은 Invalid HTML을 사용할 것으로 생각되지만.

• 2007-05 HTML5 and Web Forms 2.0 specs adopted as basis for review
• 2007-11 HTML Design Principles First Public Working Draft
• 2008-03 HTML5 공개 초안 초판 (First Public Working Draft)
• 2008-06 HTML5 최종 초안 (Last Call Working Draft)
• 2008-09 HTML5 권고안 (Candidate Recommendation)
• 2010-06 HTML5 권고 후보 (Proposed Recommendation)
• 2010-09 HTML5 권고 (Recommendation)

현시점에 HTML5는 W3C에 있어 Editor’s Draft입니다만, 내년부터 초안(Working Draft)가 되어, 2010년에는 권고(Recommendation)이 되는 일정을 예상하고 있습니다.

현단계의 W3C의 HTML5 Editor’s Draft (WHATWG에서는 Working Draft)에는, 아직 완성되지 않은 목차가 많이 있어, 나날이 눈에 띄일 정도로 업데이트 되고 있습니다만, 내년이래, Working Draft로서 일단 완성된 모습이 될 듯 합니다.

웹 페이지를 제작하면서 자바스크립트를 어떤 부분에 사용해야겠다라고 마음 먹으면 우리는 자바스크립트를 표시하는 <script> 태그를 쓴다. 앞서 얘기한 설계대로 <script> 태그의 사용 가능하지 않은 경우를 위해 <noscript> 태그를 쓸 수 있다. 어플리케이션 레벨이 아닌 마크업이 잘 되어 정상적인 기능을 하는 HTML 문서에 부가적인 사용자 편의성의 증대를 목적으로 사용하는 자바스크립트라면 <script> 태그가 동작하지 않을 경우 자바스크립트가 없는 HTML 문서와 같이 작동하게 되므로 굳이 <noscript> 태그가 필요하지 않을 것이다.

<form action="insert" id="f">
    <fieldset>
        <label for="yourjob">당신의 직업</label>
        <input type="text" name="job" id="yourjob" />
        <a href="javascript:checkForm();">전송</a>
    </fieldset>
</form>

<script type="text/javascript">
// <![CDATA[
function checkForm() {
    var form = document.getElementById("f");
    if (form.elements["job"].value == "") {
        alert("직업을 입력해주세요.&quot);
    } else {
        form.submit();
    };
};
// ]]>
</script>

<form action="insert" id="f">
    <fieldset>
        <label for="yourjob">당신의 직업</label>
        <input type="text" name="job" id="yourjob" />
        <input type="submit" value="전송" />
    </fieldset>
</form>

<script type="text/javascript">
// <![CDATA[
if (document.getElementById && document.getElementById("f")) {
    var form = document.getElementById("f");
    form.onsubmit = function() {
        if (this.elements["job"].value == "") {
            alert("직업을 입력해주세요.&quot);
            return false;
        };
    };
};
// ]]>
</script>

모든 사용자가 당신의 자바스크립트 코드를 실행할 수 있을 것이라고 기대하지 말아야 한다. 또, 어떤 사용자는 당신의 자바스크립트 코드 중 어떤 부분을 제대로 해석하지 못한다는 것을 알아야 한다.

자바스크립트는 플래시, ActiveX와 같은 외부 플러그인과 개념 상 다르지 않다. 오히려 언급한 것처럼 사용자에 따라 불완전하게 실행될 가능성이 있기 때문에 더 다루기 어려운 기술임을 인식하여야 한다.

참고 링크

• Unobtrusive JavaScript – wikipedia
• Behavior Seperation – A List Apart
• 자바스크립트를 올바르게 사용하기 – Sangini World
• 접근성을 해치지 않는 자바스크립트의 사용 – 신현석

마지막 업데이트: 2008년 4월 25일 04시 30분

그럼 실제로 각 글에 체크박스가 있어서 체크 후 삭제 혹은 이동하는 기능이 있는 게시판 목록을 만들어보자. 결과물은 다음의 그림과 같을 것이다.

그림을 보고 HTML 페이지를 만들어보자.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ko">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>여러개의 폼 제출 버튼 예제</title>
</head>
<body>
    <form action="test.html">
        <h1>여러개의 폼 제출 버튼 예제</h1>
        <table summary="게시판 목록">
            <thead>
                <tr>
                    <th>선택</th>
                    <th>제목</th>
                    <th>작성자</th>
                    <th>작성일</th>
                    <th>조회수</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                    <td><input type="checkbox" title="1번글 선택"
                         name="check1" value="Y" /></td>
                    <td>게시판 제목1</td>
                    <td>아무개</td>
                    <td>2007년 10월 13일</td>
                    <td>4</td>
                </tr>
                <tr>
                    <td><input type="checkbox" title="2번글 선택"
                         name="check2" value="Y" /></td>
                    <td>게시판 제목2</td>
                    <td>아무개</td>
                    <td>2007년 10월 13일</td>
                    <td>4</td>
                </tr>
                <tr>
                    <td><input type="checkbox" title="3번글 선택"
                         name="check3" value="Y" /></td>
                    <td>게시판 제목3</td>
                    <td>아무개</td>
                    <td>2007년 10월 13일</td>
                    <td>4</td>
                </tr>
                <tr>
                    <td><input type="checkbox" title="4번글 선택"
                         name="check4" value="Y" /></td>
                    <td>게시판 제목4</td>
                    <td>아무개</td>
                    <td>2007년 10월 13일</td>
                    <td>4</td>
                </tr>
            </tbody>
        </table>
        <p>
            <input type="submit" name="delete_selected"
                value="선택된 글 삭제" />
            <input type="submit" name="move_selected"
                value="선택된 글 이동" />
        </p>
    </form>
</body>
</html>

선택된 글 삭제와 선택된 글 이동 버튼을 submit 타입의 input 태그로 주고 각각에 name 속성을 부여하였다. 여기에서 1번글을 선택하고 선택된 글 삭제 버튼을 누른다면 제출된 값은 다음과 같을 것이다.

check1 = "Y"
delete_selected = "선택된 글 삭제"

마찬가지로 이동 버튼을 누른다면,

check1 = "Y"
move_selected = "선택된 글 이동"

위와 같은 값이 제출될 것이다.

"선택된 글 삭제"와 같은 값을 다른 원하는 임의의 값으로 줄 수 없을까? 답은 불가능하다. 화면에 보여지는 값을 그대로 사용해야 한다. 이 것이 필자가 설명한 방식의 한계이다. 개발자들은 보통 "Y" 혹은 "delete"와 같은 명확한 코드 형식의 단어를 사용하고 싶어할 것이다. 하지만 자바스크립트를 사용할 수 없는 사용자들의 불평을 듣고 싶지 않다면 현재로서는 어쩔 수 없다. IE(IE7 포함) 사용자는 submit 타입의 input 태그 외에 submit 타입의 button 태그나 image 타입의 input 혹은 button 태그에 name 속성을 통해 제출 값을 구분할 수 없기 때문이다.

이미지 버튼일 경우는 어떻게 하나? image 타입의 input 태그를 사용할 수 없다면? 답은 Image Replacement이다. Image Replacement를 사용할 수 없는 상황이라면 폼 제출 버튼을 이미지 – 배경 이미지 제외 – 로 하지 않는 디자인을 고려해보아야 할 것이다.

<style type="text/css">
input.delete-selected {
    width: 100px;
    height: 20px;
    background: url(delete_selected.gif) no-repeat;
    text-indent: -5000px;
}
input.delete-selected {
    width: 100px;
    height: 20px;
    background: url(move_selected.gif) no-repeat;
    text-indent: -5000px;
}
</style>
<!-- 중략 -->
<p>
    <input type="submit" class="delete-selected"
        name="delete_selected" value="선택된 글 삭제" />
    <input type="submit" class="move-selected"
        name="move_selected" value="선택된 글 이동" />
</p>

글의 코드는 아래의 첨부파일을 다운로드를 통해 실행해볼 수 있다.

select.html

출처: Methisto: HTML5 trailer – Find your Hero

HTML5의 등장의 예고편이라고 할까요? 웹의 90%를 지배하고 있다는 그의 정체 부분이 압권입니다. ㅎㅎ

2010년 12월… 더 늦지 않았으면 좋겠군요! :)

Developing with HTML5.ppt

관련 링크

• WHATWG (Web Hypertext Application Technology Working Group)
• Lachlan Hunt 인터뷰

그림1은 현재 게시판의 분류나 바로가기 메뉴 등에서 선택 시 바로 폼을 전송시키거나 자바스크립트를 이용하여 페이지 전환을 하는 용도로 쓰이고 있다. 그러나 키보드 사용자나 자바스크립트를 사용할 수 없는 사용자를 고려하였을 때 위와 같은 사용은 불가하다. 자바스크립트가 불가능한 사용자를 위해 <noscript> 태그를 이용하여 서브밋 버튼을 추가하면 되지 않느냐? 그것은 반쪽짜리 접근성이다. 마우스 기능을 사용할 수 없는 사용자의 접근성이 상당히 저하되기 때문이다. 키보드 사용자는 select 태그의 목록을 활성화 시킨 후 아래 방향키를 한 번 누르는 순간 select 태그의 자바스크립트가 활성화되어 마치 목록 두 번째 요소를 선택한 듯한 결과를 보게 될 것이다.

(그림2. 전송 버튼이 적용된 select 태그)

전송 버튼을 넣고 select 태그의 onchange 이벤트를 제거하여 모든 사용자에 대한 접근성을 확보할 수 있다. 마우스 사용자들의 편의성 문제는 어떻게 하는가? 결국 판단은 제작하는 사람의 몫이지만 누군가의 접근성을 저해하면서 얻는 편의는 기능에 대한 남용이다.

일단 전역설정이다. 이 작업은 브라우저마다의 차이를 극소화하고, 사용할 tag의 기본적인 속성을 부여하는 작업이다. 갖가지 태그의 padding과 margin을 0으로 지정! tag마다 기본적으로 padding과 margin값이 틀리다. 쉬운 디자인 작업을 위한 설정이기도 하다. 가로줄(hr tag)은 디자인에서 (대개) 불필요하므로 보이지 않도록 처리한다. hr tag를 생략할수도 있겠지만, 디자인이 배제된 페이지에서의 head, body, foot의 구분을 위한 용도로 유용하므로 사용을 권한다!

html,body,img,form,div,span,h1,h2,h3,h4,hr,ul,li,table,tr,th,td {
    padding: 0;
    margin: 0;
}

hr {
    display: none;
}

위의 작업 외에도 기본적인 링크(a tag) 설정, 링크걸린 이미지를 위한 border 설정 등 작업내용에 맞는 기본설정을 한다!

<

p>자, 이제 페이지에 디자인을 입히는 작업 시작! 첫번째, 전체적인 레이아웃을 보자. 검은 테두리가 모든 정보를 덮고 있고, 그 안에 배경색이 있고, 중앙으로 정렬이 되어 있고, 위로부터 10px 떨어져 있다.

여기서 전체를 담당하는 container와 body tag의 선언을 하자. 브라우저 틀에 해당하는 body tag, 다음과 같이 선언해보자.

body {
    margin-top: 10px; /* 상단의 마진을 10px로 설정 /
    background-color: #fff; / 배경색을 흰색으로 설정(=#ffffff) */
}

검은 테두리와 그에 해당하는 부분은 container에 선언한다.

#container {
    margin: auto; /* 중앙정렬! 상하 마진에는 관여되지 않는다. /
    width: 700px;
    border: 1px solid #000; / 테두리를 1px 검은색으로 설정 */
    background-color: #f9f9fe;
}

이제 전체적인 틀을 만들었다. 다음으로는 실제 내용 하나하나에 디자인을 입혀보겠다. 로고, 상, 하, 좌에 각각 20px의 마진, font의 크기는 h1의 그것으로 결정하기로 했다고 하자. 또 로고의 폰트를 두껍게, 2차 로고(div 레이아웃 첫번째 페이지)는 표시하지 않기로 하자. (이미지에서 로고가 두껍게 나오지 않는건 내 컴의 문제 -_-+)

#logo {
    padding: 20px;
    border-bottom: 1px solid #000; /* 로고 아래의 검은줄 */
}
logo h1 { /* 폰트에 대한 내용이므로 해당 tag에 직접 써준다 */
font-weight: bold;

}
logo span { /* 2차 로고를 숨긴다 */
display: none; /* visible 속성은 보이지 않지만, 레이아웃에 해당영역을 차지 한다. */

}

좌측 메뉴, 다음으로 나올 뉴스 내용이 오른쪽에, 좌측 메뉴가 왼쪽에 배치되어 있다. top과 left의 border는 있으니, right, bottom에만 border를 적용시켜주면 되겠다. 배경색이 다르다. text가 중앙정렬이며, 상하도 중앙정렬이다 – 이럴 땐, 높이를 지정하지 않은 padding 옵션이 적당하다.

#menu { /* 메뉴 전체의 틀을 지정 /
    width: 150px;
    float: left; / 왼쪽으로 정렬시킨다. 뿐만 아니라, 다음의 나올 컨텐츠의 위치를 이것도 동일선상(?)으로 위치시키는 기능도 있다. 자세한 내용은 http://www.w3.org/TR/CSS21/visuren.html#floats를 보도록 하자. /
    text-align: center; / 좌우 중앙정렬 */
    background-color: #e0e0ef;
}
menu li {
list-style-type: none; /* 앞 딴의 미려하지 않은 동그랑땡을 제거! */
padding: 8px; /* 중앙정렬을 위해. */
border-right: 1px solid #000;
border-bottom: 1px solid #000;

}

자, 이제 내용을 메뉴의 오른쪽으로 위치시킬 차례이다. 전체의 가로 size에서 메뉴의 가로 size를 제외한만큼의 영역을 차지한다. 행의 높이를 20px로 한다.

#contents { /* 내용 전체의 틀 /
    float: right; / 오른쪽으로 띄운다. /
    width: 550px;
}

.news { / 여러개의 뉴스가 한 페이지에서 보일 개연성을 부여한다(?) */
    padding: 10px;
}

.news-body p { /* 행의 높이는 전역설정을 하지 않는다!! */
    line-height: 20px;
}

행의 높이는 레이아웃에 뜻하지 않은 악영향을 끼치는 경우가 많다. 필요한 경우에만 사용한다. 여러군데에서 같은 행의 높이가 사용된다면, 따로 class를 부여하여 사용하면 좋다.

자, 이제 copyright를 만들고 전체적인 레이아웃을 마무리한다! float 상태를 취소하고 아랫쪽으로 배치! 좌우 중앙, 상하 중앙(padding 사용!), 상단에 1px의 border!

#copyright {
    clear: both; /* float 상태를 취소 (both = left + right) */
    text-align: center;
    border-top: 1px solid #000;
    padding: 20px;
}

페이지가 완성되었다. 결과물을 눈으로 확인하자! 예제 – divcss2.html

다음 공략에서는 좀더 실제상황가 가깝게 이미지, 링크 등이 들어간 디자인을 입혀보겠다!

덧) 모자란 실력으로 공략같은걸 씁니다. ^^ 많이 부족한 부분이 있고, 간혹 틀린 부분이 있을 수도 있습니다. 이런 부분에 대해선 미리 죄송하다는 말씀 드립니다! 많은 정보 얻고있는 forums.mozilla.or.kr에게는 언제나 감사하다는 말씀.. 덧붙입니다!

<a href="http://tenshi.pe.kr/" onclick="window.open(this.href); return false;">tenshi.pe.kr</a>

자바스크립트 parser가 없는 경우는 대개 text 브라우저 같은 녀석들이니 상황에 따른 새 창 혹은 자기자신의 선택이 되는 장점도 아울러 가질 수 있다!

modified at 2005-03-17 16:10:20 – 죄송합니다. return false를 빼먹었네요. -_-;;

타이틀
    멋져부러 뉴스
서브타이틀
    div 레이아웃 첫번째 페이지!

메뉴
    home
    뉴스
    방명록
    링크

뉴스
    박지성, 에인트호벤과 계약연장 합의

네덜란드 프로축구에서 활약하는 박지성(24.에인트호벤)이 소속팀에 3년 더 남을 전망이다.

PSV 에인트호벤은 내년 시즌을 끝으로 계약이 만료되는 박지성과 3년 재계약을 맺기로
원칙적으로 합의했다고 현지 신문 알게메네 다흐 블라드가 12일(한국시간) 보도했다.

구단 웹사이트(www.psv.nl)도 "PSV는 박지성이 오랫동안 에인트호벤에 남아주기를
바라고 있고 그와 협상을 시작했다"고 밝혔다.

이번 계약 연장은 구단 측이 적극적으로 요구한 것으로 이에 따라 박지성은 오는
2008년까지 에인트호벤 유니폼을 입게 된다.

거스 히딩크 에인트호벤 감독은 "박지성도 이곳에 남기를 바라고 있다. 2002년
한일월드컵 이후 많은 한국 선수들이 유럽에 진출했지만 박지성과 이영표가 유일하게
성공한 예"라면서 "두 선수는 우리팀의 엔진과도 같다. 나머지 구체적인 사항도
잘 성사될 것으로 믿는다"고 기대를 나타냈다.

copyright
    2005 blahblah.com. All rights reserved.[/code]

자, 위의 재료로 div 레이아웃 페이지를 만들어보자! 일단 디자인이 배제된 html 페이지를 구성하는 단계이다. 내 생각엔 이 단계가 div 레이아웃 공략에서 제일 중요한 단계가 아닐까 생각한다. 그만큼 중요하다는 말씀!!!

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>박지성, 에인트호벤과 계약연장 합의 - 멋져부려 뉴스</title>
    <style type="text/css">
    </style>
</head>
<body>
<div id="container">
    <div id="logo">
        <h1>멋져부러 뉴스</h1>
        <span>div 레이아웃 첫번째 페이지</span>
    </div>
    <hr />
    <div id="menu">
        <ul>
            <li>home</li>
            <li>뉴스</li>
            <li>방명록</li>
            <li>링크</li>
        </ul>
    </div>
    <hr />
    <div id="contents">
        <div class="news">
            <h3>박지성, 에인트호벤과 계약연장 합의</h3>
            <div class="news-body">
                <p>네덜란드 프로축구에서 활약하는 박지성(24.에인트호벤)이 소속팀에 3년 더 남을 전망이다.</p>
                <p>PSV 에인트호벤은 내년 시즌을 끝으로 계약이 만료되는 박지성과 3년 재계약을 맺기로 원칙적으로 합의했다고 현지 신문 알게메네 다흐 블라드가 12일(한국시간) 보도했다.</p>
                <p>구단 웹사이트(www.psv.nl)도 "PSV는 박지성이 오랫동안 에인트호벤에 남아주기를 바라고 있고 그와 협상을 시작했다"고 밝혔다.</p>
                <p>이번 계약 연장은 구단 측이 적극적으로 요구한 것으로 이에 따라 박지성은 오는 2008년까지 에인트호벤 유니폼을 입게 된다.</p>
                <p>거스 히딩크 에인트호벤 감독은 "박지성도 이곳에 남기를 바라고 있다. 2002년 한일월드컵 이후 많은 한국 선수들이 유럽에 진출했지만 박지성과 이영표가 유일하게 성공한 예"라면서 "두 선수는 우리팀의 엔진과도 같다. 나머지 구체적인 사항도 잘 성사될 것으로 믿는다"고 기대를 나타냈다.</p>
            </div>
        </div>
    </div>
    <hr />
    <div id="copyright">
        2005 blahblah.com All rights reserved.
    </div>
</div>
</body>
</html>

예제 - divcss.html

간단히 html 페이지를 구성해보았다. 이제 이 html 페이지를 뜯어가며 살펴보자!

일단 body 안쪽에 전체를 포괄하는 div tag( id="container" )를 선언한다. 이는 디자인을 입힐 때의 전체적인 레이아웃(가로길이, background 등..) 지정을 담당하는 역할을 주로 한다.

이제 재료의 구분(타이틀, 메뉴, 뉴스..)별로 다시 div tag를 감싸준다. 타이틀이나 메뉴처럼 한번만 나오는 녀석은 id로, 뉴스처럼 중복된 내용이 나올 수 있을만한 녀석은 class로 css를 위한 선언을 하여준다.

다음으로는, 타이틀의 로고나 뉴스의 제목 등 다른 내용들보다 중요한 text는 headings(<h1> ~ <h6>)로 강조됨을 표시한다. 로고 같은 제일 중요한 녀석은 h1 tag로, 본문(뉴스)의 제목은 h2나 h3 tag 정도로 배정해주면 적당하겠다.

메뉴와 같은 몇 개의 간단한 text의 묶음은.. lists( <ul>, <ol>, <li> )로 묶어주기를 추천한다. 그 외 문단나눔(p tag), 표(table tag) 등은 용도에 맞게 쓰자!

이 정도면 기본적인 html 코딩의 기초를 다 적지 않았나 싶다. 부족한 부분이 있겠지만 그런 것들은 이런 저런 상황들을 통해 내공을 쌓을 수 있을 것이다! 원래 이번 공략에서 CSS까지 입혀보기로 했으나, 이미 긴 작문에 기력을 소진한 상태라..-_-; 다음 시간에 CSS를 입혀보기로 하겠다!!

W3C(World Wide Web Consortium)에서는 여러가지 버전별 html 표준 규약을 제공하고 있는데, DTD는 그 여러가지 버전중에 한가지 규약을 사용하겠다 하는 선언이다.

우리의 공략의 표준 규약으로 사용할 html의 버전은 XHTML 1.0으로 해당 DTD들은 XHTML1 DTDs에서 볼 수 있다.

보면 3가지 DTD가 있는데, 엄격한 규약(strict), strict보다 약간 느슨한 규약(transitional), frameset 페이지에서의 규약(frameset)이 있다. 앞으로 예제에서는 엄격한 녀석(strict)을 쓰겠다.

아래는 strict DTD를 적용한 XHTML 1.0 페이지의 기본이다. 우리의 공략은 이 페이지를 바탕으로 출발하겠다!

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Hello, tenshi!</title>
</head>
<body>
<p>
  contents...
</p>
</body>
</html>

기본적으로 DOCTYPE(Document Type)을 최상단에 선언하고, html tag(이하 html)가 처음과 끝에 나오고, html안에 head tag(이하 head), body tag(이하 body)가 반드시 포함, head안에 title tag, 문서의 encoding( , [url=http://www.w3.org/TR/xhtml1/#C_9]다른 방법[/url]도 있지만 여기선 다루지 않겠음!)을 반드시 선언…

암튼, XHTML 1.0의 규약을 지키기 위해서는 여러가지 제약조건들이 있다. 처음부터 힘들게 외우기 보다는 손 가는대로 페이지를 만들고 유효성 검사를 하면서 고치면 훨씬 쉽게 코딩할 수 있다~ 유효성 검사에 대해서는 추후에 다시 설명하도록 하겠다.

이제 XHTML 1.0 strict 규약을 적용한 기본 페이지도 만들어봤고, 다음엔 실제로 예제 페이지를 하나 맹글어보자~ 또, CSS로 디자인을 입히는 요령에 대해서도 하나하나 배워보자!

"td tag(이하 td)를 하나 안닫았다!"

"table 10단 콤보에 들여쓰기를 하려니 온통 공백밖에 없다 OTL"

그렇게 table 중첩 코딩을 하면서 위와같은 문제를 많이 겪었으리라 싶다.

이제 저런 문제들을 좀 벗어나보자, 바로 div+css 레이아웃(이하 div 레이아웃)으로! 그냥 위와 같은 문제들만이라면 div 레이아웃을 뭐 굳이 배우겠냐 싶지 않은가? 그렇다! 궁극적으로 div 레이아웃을 공략해야만 하는 이유는 따로 있는 것이다.

• "컨텐츠에 html, 디자인에 css! 전달하고자 하는 정보와 그 정보를 꾸며주는 디자인의 완벽한 분리!"
• "위에 따른 동일한 컨텐츠(html)에 여러 디자인의 구성!"
• "가벼워진 페이지, 날아다니는 서버! (좀 과장이 심하죠? -ㅛ-)"

그 외에도 많은 장점들이 있다! 굳이 알고 싶다면 한글 모질라 포럼 – Web Standard Evangelism을 한번 둘러보시라!

자 이제 div 레이아웃으로 옮겨갈 마음이 생겼다면 본격적으로 공략을 시작해보자!