HTML에서 문서 형식(Doctype) 지정의 중요성

많은 노력을 기울여서 제작한 웹 페이지(문서, page)가 제작자의 의도와 다르게 출력되는 경우가 있다. 대부분 올바르지 못한 HTML 마크업과 CSS, JavaScript 코드로 작성했기 때문에 발생한 문제이지만, 어떤 문서는 유효성 검사를 모두 통과했음에도 불구하고 제대로 출력되지 않기도 한다.

이처럼 올바른 문법으로 작성한 문서가 올바르지 않게 출력되면, 제작자는 깊은 고민의 수렁에 빠질 수 밖에 없다. 자신의 경험과 주변의 도움으로 쉽게 문제를 해결하기 어렵기 때문이다. 또한 이러한 문제는 IE, FF, Opera, Safari와 같은 다양한 웹 브라우저에서 각각 다른 모습으로 출력되는 문제도 있다.

이러한 문제는 대부분 (x)HTML 문서의 코드 첫 줄에 문서 형식이 명시되지 않았기 때문이다. 올바르지 않은 문서 형식이 선언되었기 때문이거나, 또한 문서 형식이 선언되지 않았기 때문일 수 있다. 심지어 (x)HTML 코드의 첫 줄에 공백이나 주석이 입력되어 있기 때문일 수도 있다.

문서 형식이란

HTML 문서에는 여러 종류의 형식이 존재한다. HTML 4.01 Strict, HTML 4.01 Transitional, XHTML 1.0 Strict 외에도 다양한 문서 형식이 존재한다. 이들 문서 형식은 W3C의 스펙에서 보다 자세하게 확인할 수 있다.

문서에 형식을 정의하는 것을 “Document Type Definition”이라고 하며, 줄여서 DTD라고 한다. DTD는 HTML 문서의 첫번째 줄에 위치해야 하며, XHTML 1.0 Strict 문서 형식을 선언하는 code는 아래와 같다.

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

문서 형식을 지정해야 하는 이유

문서 형식은 HTML 버전과 종류를 명시함으로써, 브라우저가 문서를 해석하고 출력하는데 직접적인 영향을 준다. 웹 브라우저는 문서형식이 지정되지 않거나, 올바르게 지정되지 않은 HTML 문서를 읽고 해석하는데 어려움을 겪는다. 때문에 화면을 출력하는데 보다 오랜 시간이 소요되며, 또한 제작자의 의도와 다른 화면을 출력할 수 있다. 이는 일반적인 시각계 브라우저 외에도 시각장애인용 음성출력 브라우저나 기타 보조기기 역시 마찬가지다.

최근 웹 브라우저는 호환(Quirks) 또는 표준(Strict)처럼 다양한 방식으로 HTML 문서를 해석한다. 브라우저는 올바르게 지정된 문서 형식의 HTML을 표준(Strict) 방식으로 해석하고 출력하지만, 그렇지 않은 HTML은 호환(Quirks) 방식으로 출력한다.

표준 방식은 HTML를 W3C 스펙에 따라 출력하는 방식이며, 호환 방식은 각각의 브라우저마다 사용하는 별도의 스펙에 따라 출력하는 방식이다. 떄문에 호환 방식으로 출력된 HTML은 각각의 브라우저마다 다르게 출력된다. 문서 형식 지정에 따른 브라우저 출력 방식은 아래 표에서 확인할 수 있다.

문서 형식 선언과 브라우저 출력 방식

Eric Meyer가 2006년 11월에 작성한 Doctype Grid에서 문서 형석과 브라우저의 출력 방식의 관계를 확인할 수 있다.

호환 출력 방식(Quirks Rendering Mode)의 특징

브라우저가 HTML을 읽는데 시간이 더 걸린다.
브라우저가 HTML을 해석하는데 시간이 더 걸린다.
브라우저가 HTML을 출력하는데 시간이 더 걸린다.
브라우저마다 HTML을 각각 다르게 출력한다.

(x)HTML 문서 형식 선언

W3C에 정의된 (x)HTML의 문서 형식 선언은 아래와 같다.이 외에도 W3C QA팀의 Recommended list of DTDs에서 SVG, MathML 등의 XML 문서 형식 선언도 확인할 수 있다.

HTML 2.0

<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">

HTML 3.2

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

HTML 4.01 Strict

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

HTML 4.01 Transitional

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

HTML 4.01 Frameset

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

XHTML 1.0 Strict

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

XHTML 1.0 Transitional

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

XHTML 1.0 Frameset

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

XHTML 1.1

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

XHTML Basic 1.0

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">

XHTML Basic 1.1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN">

참고 문서

XHTML의 태그들의 형식(type)

HTML에서 XHTML로 문서형식(Doctype)을 바꿀때, 반드시 지켜야 할 규칙들이 몇가지 있다. 그 중 한가지가 ‘XHTML의 모든 태그는 시작 태그와 상응하는 종료 태그를 사용해야 한다’는 것이다.

XHTML 태그들은 컨테이너 태그와 독립형 태그로 구분되는데, 컨테이너 태그에는 , <p></p> 등이 있으며, 독립형 태그는 <img />, <hr />등이 있다.

처음 XHTML을 사용하는 분들은 이런 XHTML의 컨테이너 요소와 독립형 요소를 구분하지 못함에 따라 실수를 하곤 한다. 대부분의 XHTML 요소들이 컨테이너 요소들이며, 독립형 요소들의 수는 매우 작다.

독립형 태그들 목록

– 문서의 메타 정보를 정의한다.
– XHTML에 다른 파일을 연결(관계를 정의)한다.
<br /> – 문서의 행을 분리한다.
<hr /> – 문서에 수평선을 삽입한다.
<img /> – 문서에 이미지를 삽입한다.
– 문서에 폼(라디오 버튼이나 텍스트 필드 같은 여러 종류의 폼)을 삽입한다.

독립형 태그로 혼동하는 컨테이너 태그 목록

– 문서 상단(header)에 링크로 사용하면서 한줄로 삽입할 때도 반드시 종료 태그를 사용해야 함.
– 문서에 별도의 객체를 삽입할때 사용하며, 역시 한줄로 삽입할 때도 반드시 종료 태그를 사용해야 함.
<div></div> – 장식용(내용이 빈) 태그로 사용할때도 반드시 종료 태그를 사용해야 함.

위의 독립형 태그로 혼동하는 컨테이너 태그 목록은, 내가 작업할 때 코딩을 줄이려고 독립형으로 사용했던 경험이 있는 컨테이너 태그들이다. 물론, 나만 이런 실수를 하라는 법이 없을 것 같아서 이렇게 글로 남겨본다.

태그들이 형식을 갖고 있을 줄이야.. 누가 알았겠는가?

휴가 끝. 그리고 일상.

무려 10일간의 휴가도 오늘이 마지막이다. 사실 제대로 여름 휴가를 보내본 건 올해가 첨이다. 작년까지만 해도, 휴가라기 보다는 방학을 보냈기 때문이다. 어쨓거나 첫 휴가였지만, 나름대로 알차게 보낸 것 같다.

나는 독서를 즐기려 노력(만화책만..?)하는 편이지만, 책보다 컴퓨터 앞에 앉아 있는 시간이 훨씬 많은 편이었다. 다행히 이번 휴가 기간 전에 나의 메인 컴퓨터가 고장나는 바람에, 꽤 긴 시간을 독서에 매진할 수 있었던 것 같다(기뻐해야 할지, 슬퍼해야 할지).

물론, 내 컴퓨터의 하드디스크 한켠에 ebook이라는 이름으로 여러종류의 책들을 모아놓았지만, 인터넷이 끊기지 않는 이상 컴퓨터 앞에서 이런 책들을 읽는 것이 쉽지 않았다.

그런 점에서 이번의 컴퓨터 고장은 오히려 좋은 결과를 이끌었던 것 같다. 오랫만에 학교도 가보고, 도서관에도 가보고, 여러 종류의 책들도 읽었다.

최근 웹표준과 CSS에 대한 관심이 늘어가면서, 많은 사람(나 포함)들이 국내에 참고할 정보가 부족하다고 말하지만, XHTML + CSS2 + DOM에 관한 정보는 2000~2002년에 발간된 책들(해외에서 발간되고, 국내에서 번역된)만으로도 충분할 듯 싶다.

시내 대형 서점에 전시된, 최근에 발간된 웹디자인/개발 관련 책들은 대부분 팁 위주로 설명된 책들임에 반해, 2000년대 초에 발간된 책들은 대부분 이론적이고 원론적인 책들이다. 아무래도 1998년 XML1.0의 발표와 1999년 말 HTML4.01의 발표 및 2000년 초 XHTML1.0의 발표가 관련 도서의 출판에 영향을 준 것 같다.

어쨓든 오늘은 휴가 마지막일이고, 내일부터 다시 일상으로 돌아간다. 그래봤자 주3일 15시간 근무에 변화는 없을테니, 대학 도서관에 일반회원으로 등록(사실 나는 휴학생임)하고 책을 빌리련다.

이번 달은 ‘Beginning XHTML’(정보문화사)을 읽는데 보내야 겠다. 다른 책도 함께 빌릴 생각이었지만, 이 책 한권이 거의 1000페이지에 육박하는 두꺼운 책이기에 가방이 가득차버렸다.

간단하게 훝어보니 이 책은 수학의 정석이라는 생각이 든다. 그렇다면, 다른 책들은 수학의 활용서가 될 것이다. 물론, 시험에서 고득점을 얻는 방법은 여러가지 다양한 문제들을 풀어보면서 경험치(겜 용어인듯)와 이해력 및 응용력을 높이는 것일 것이다. 하지만 기본원리를 이해하지 못하고 공식만 외우는 것은 수학을 공부하는 가장 나쁜 태도인 것 처럼, 기본을 모르고 팁과 활용에만 궁극적으로 내공을 쌓을 수 없을 것이다.

혹시라도 웹표준을 준수한 XHTML, CSS, DOM 작성을 하려는 분이 있다면, 꼭 ‘Beginning XHTML’(정보문화사)를 읽어BOA요~ ㅎㅎ

테터툴 1.0에 대한 바램.

웹브라우저는 문서형식(Doctype)에 따라 CSS나 DOM(Javascript)을 다르게 해석하고 있다. 즉, Strict 문서형식에서는 CSS나 DOM을 W3C의 권고안에 맞게 웹페이지를 랜더링하지만, Transitional 문서형식에서는 각 브라우저마다 제각각 랜더링하고 있다.

Transitional 문서형식이라도 파이어폭스나 오페라 또는 네스케이프 네비게이터처럼 최근에 출시된 웹브라우저는 가급적 W3C의 웹표준 권고안에 맞게 웹페이지를 랜더링하는 편이지만, 오래전에 출시된 인터넷 익스플러는 독특(IE정신?=박지호정신?)하게 랜더링하고 있다.

전세계적으로 IE의 웹브라우저 시장점유율이 높기 때문에(물론 국내처럼 IE 광신도 국가도 없지만), 이러한 IE의 랜더링 버그는 많은 웹디자이너들이 CSS의 사용을 어렵게 했다. 특히 박스모델의 padding과 border 값을 width 값으로 포함하는 IE의 독특한 랜더링이 버그가 골칫거리였다. 이 버그 때문에 웹디자이너들은 불필요한 (x)HTML 마크업을 사용해야 하거나(예:중첩 div 사용) IE 전용 CSS hack을 공부해야만 했다.

Xhtml과 CSS 관련 편집기의 성능 비교-2

워드프레스가 1.5에서 1.5.1을 거쳐 1.5.1.1로 업데이트 되면서 꽤 많은 변화가 있었던 것 같다. 글을 쓸때, 빠른 태그(Quick Tag) 버튼 중에서 page 버튼이 사라져버렸다. 원래 이 글은 page 기능을 이용해서 3 페이지로 분리시킬 예정이었는데, 어쩔 수 없이 글을 나눠 쓰게 된다. 아무래도 나처럼 긴글을 읽지 않는 사람들을 위한 배려랄까? ㅠ.ㅠ

좌측의 이미지는 Xin-editor의 스크린 샷으로 마치 테터툴의 카테고리 기능처럼 +, – 버튼을 이용해서 웹페이지의 구조를 파악할 수 있다. (이미지를 클릭하면 Xin-editor 공식 홈페이지로 이동) 앞 글에 이어서 내 컴퓨터에 설치되어 있는 XHTML과 CSS 관련 프로그램들의 기능들을 좀 더 세부적으로 비교해 본다.

로딩속도 :
드림위버나 고라이브와 같은 수백MB의 무거운 프로그램에 비하면, 위에 열거된 5개의 프로그램의 로딩속도는 무척 가볍다. 현재 사용하고 있는 팬티엄4 3.0에서는 로딩속도의 차이를 거의 느끼지 못할 정도다. 하지만, 파이어폭스의 플러그인인 view source with를 사용해서 웹페이지를 분석할 경우 Xin-editor가 가장 빠름을 알 수 있다.
XHTML 코드 편집 :
웹편집기에서 HTML 코드 편집 기능은 당연하다. 그럼에도 불구하고 굳이 HTML이 아닌 XHTML 코드 편집 기능에 대해서 비교한 이유는 얼마전에 일몰님이 작성한 내홈피는 웹표준. 5가지부터 시작하기. 라는 글의 영향일 것이다.
XHTML 이지윅(WYSIWYG) 편집 :
대표적인 이지윅 웹편집기인 드림위버와 고라이브를 제외하고(나모는.. 미안하다)도 굳이 이지윅 편집 기능을 거론한 이유는 핸드코딩만으로 웹페이지를 제작해야 한다는 일부 생각에 나는 반대의 입장이기 때문이다. 또한 모질라 Gecko엔진을 기반으로 한 무료 웹에디터인 Nvu를 소개하고 싶어서이다.
CSS 코드 편집 :
이미 대세는 CSS다라는 여러 관련 글들을 블로그에 써왔기에 XHTML 코드 편집과 별도로 분리했다. PHP, ASP 전문 코드 편집기가 존재하는 것처럼 CSS 전문 코드 편집기의 필요성을 제기하고 싶었다.
CSS 이지윅 편집 :
아직까진 필요성을 거의 못느끼지만, CSS를 더욱 구조화하기 위해서는 반드시 필요한 부분이라고 생각한다. 참고로 내 wp 블로그의 index.php 파일의 크기는 1.6kb이지만 style.css 파일의 크기는 무려 10배가 넘는 18.2kb이다. 이 점을 생각할때 CSS를 분리시키기 위해서 필요한 기능일 것이다.
구문강조 :
텍스트에디터에서 구문강조는 필수 기능일 것이다. 이지윅 에디터인 Nvu에서는 코드 보기를 가급적 피하는 게 좋을 듯 싶고, XHTML 전문 에디터인 Xin editor는 유일하게 XML 구문강조 기능을 지원하지만, 아쉽게도 PHP나 ASP는 지원하지 않는다.
코드힌트 :
텍스트 에디터가 이지윅 에디터만큼 편리할 수 있는 기능중에 하나가 바로 코드힌트 기능일 것이다. 내가 드림위버에서 헤어나오지 못하는 이유도 ”
태그완성 :
대부분의 웹용 텍스트 에디터에서 지원하는 기능이다. “>”만 입력하면 자동으로 태그가 닫힌다. 드림위버나 TopStly에서 지원하는 태그완성 기능보다 Xin-editor의 태그완성 기능이 좀 더 편리하다.
구조보기 :
웹페이지의 구조를 파악할 수 있는 기능으로, 프로그램마다 다양한 형식으로 지원된다. Nvu의 HTML tag 보기 형식이 있는가 하면, Xin-edtor의 펼침메뉴 형식도 있다. 물론, Xin-editor가 훨씬 편리하다. 이 필수적인 기능을 드림위버가 지원하지 않는 이유를 모르겠다.
미리보기 :
모질라 Gecko엔진을 사용한 Nvu를 제외하고 대부분의 웹에디터가 IE 기반 엔진으로 미리보기 기능을 수행한다. 그러나 TopStyle은 플러그인을 통해서 Gecko 엔진으로 미리보기를 지원하고 있다. 특히 IE, FF에서 동시에 미리보기를 할 수 있는 강력한 기능이 있다.
브라우저 미리보기 :
컴퓨터에 다양한 브라우저가 미리 설치됐을 때 유용한 기능이다. 대부분 IE, FF 기반 엔진의 2개 브라우저에서 미리보기를 할 수 있지만, StyleMaster는 IE, Opera, NN, Mozila, FF의 5개 브라우저에서 미리보기를 할 수 있다.
FTP 지원 :
별도의 Ftp 전용 프로그램을 필요로 하지 않고, 원격 Ftp에 접속하여 파일을 업로드 하거나 수정할 수 있는 기능이다. 무척 효율적인 기능임에 불구하고, 파일을 잘못 덮어씌는 실수를 유발할 수 있기에 팀작업을 할때는 지양되는 기능이다. 드림위버에서는 check in 기능으로, 고라이브에서는 version cue 기능으로 이런 문제들을 방지하고 있다.
구문 검사(Validate) 기능 :
HTML, XHTML, CSS 등의 문법을 검사해주는 기능이다. HTML-trasitonal 문서의 경우 웬만한 문법 오류들은 IE가 자동으로 해석해주지만, FF나 다른 브라우저는 그렇지 않다. W3C와 같은 여러 웹사이트들에서 구문검사를 해결해주고 있지만, 프로그램 자체적으로 오류를 검사하고 대안을 제시해주는 기능은 향후 웹에디터의 필수 기능이 될 것이다.

이 외에도 다양한 기능들이 있지만, 주로 사용하거나 눈에 띄는 기능들 위주로 비교해 봤다. 생각보다 비교하는데 시간이 많이 걸렸지만, 꽤 재미있는 결과가 나왔다. 해석하기 나름이겠지만, 내 생각에 XHTML 편집기로는 Xin-Editor가 가장 편리하고, CSS 편집기로는 TopStyle가 가장 편리한 것 같다.

나는 TopStyle 예찬론에 대한 몇몇 글들을 블로그에 작성했었다. 한글 입력 문제만 해결된다면(제작사 측에선 검토한 적 없다고 함), 드림위버나 고라이브에 비교해도 손색이 없는 걸작 프로그램이다. 또한, Xin-editor가 보여주는 구조보기의 기능은 동급대비 프로그램 중에서 최강의 기능인 것 같다. (고라이브에도 있는 기능이지만, 효율성이 떨어진다.)

여러개의 작은 프로그램을 동시에 구동시키는 것과 한개의 커다란 프로그램에서 한꺼번에 구동시키는 부분에 대해서는 좀 더 고민해 봐야 겠다. 인간의 사고가 하나에 일에 집중할 때와 여러개로 분산시키는 부분에 대해서 효율성이야 두말할 필요가 없겠지만, 나날이 발전해가는 컴퓨터의 성능을 생각해보면 쉽게 결론을 내리기 어렵다. 또한 웹페이지 개발을 전문가만이 아닌 많은 사람들이 쉽게 할 수 있어야 한다는 주관적인 생각이 있기에 이지윅 에디터의 필요성도 간과할 수 만은 없다.

1달 반이란 블로거 생활중에 가장 긴 글을 썼다. 사실, 이 글을 쓰게 된 motive는 얼마전에 일몰님과 MSN 대화 중에 주로 사용하는 웹에디터에 대한 대화내용이었다. 일몰님은 주로 에디트 플러스를 이용해서 웹페이지를 제작한다고 하는데, 나의 경우는 텍스트에디터를 metadata 작성이나 javascript 삽입과 같은 극히 제한적인 범위에서만 사용하기 때문이다.

최근 XHTML과 CSS 전문 프로그램들을 사용하게 되면서 그동안 드림위버가 최고다라는 믿음에 조금씩 금이 가고 있다. Macromedia사의 Studio MX 2005 시리즈가 늦어도 올 가을에는 출시될거라는 소문이 무성하기에 일단은 기다려 보련다. 어도베에서 매크로미디어사를 인수한 점을 고려해서 드림위버 MX 2005가 나에게 아무런 흥미를 주지 못할 점도 염두해야 겠다.

Xhtml과 CSS 관련 편집기의 성능 비교-1

드림위버가 긴장할 프로그램을 기대합니다. 나는 오랫동안 웹페이지를 제작할 때 이지윅(WYSIWYG)에디터인 드림위버를 주 편집기로, 텍스트에디터인 에디트플러스를 보조 편집기로 사용해 왔다. 올해 들어서야 XHTML과 CSS에 관심을 갖게 되면서 CSS 전용 에디터인 Top Style, Style Master와 XHTML 전용 에디터인 Xin editor 등을 사용하고 있다. 이러한 전용 에디터들의 경우 사용도 쉽고, 때때로 이지윅에디터보다 강력한 기능들을 보여주기도 한다.

현재 내가 사용중인 XHTML과 CSS 관련 편집기들의 각 성능들을 비교해봤다. 드림위버는 세계에서 가장 많은 사랑을 받는 웹에디터이기에 자칫 나의 주관적인 평가가 잘못된 인식을 심어 줄 수 있기에 비교 대상에서 제외했으며, 고라이브는 이번에 CS2로 버전업 전까지 악평을 너무 많이 받았고 나의 테스트 기간이 짧았기에 비교 대상에서 제외했다. 또한 쿠키님이 소개해준 CSSedit는 맥 전용이라 테스트할 수 없었다. ㅜ.ㅜ

	EditPlus	X-Editor	Nvu	TopStyle	StlyeMaster
로딩 속도	★★★	★★★	☆★★	☆☆★	☆★★
XHTML 코드 편집	☆☆★	★★★	☆☆☆	★★★	☆☆☆
XHTML 이지윅 편집	☆☆☆	☆☆☆	★★★	☆☆☆	☆☆☆
CSS 코드 편집	☆☆★	☆☆★	☆☆☆	★★★	★★★
CSS 이지윅 편집	☆☆☆	☆☆☆	☆☆☆	★★★	★★★
구문 강조	★★★	★★★	☆☆★	★★★	★★★
코드 힌트	☆☆☆	☆☆☆	☆☆☆	★★★	☆★★
태그 완성	☆☆☆	★★★	☆☆☆	☆★★	☆☆☆
구조 보기	☆☆☆	★★★	☆★★	☆☆★	☆☆★
미리 보기	☆☆★	☆☆★	☆★★	★★★	★★★
브라우저 보기	☆★★	☆★★	☆★★	★★★	★★★
Ftp 지원	★★★	☆☆☆	☆☆☆	☆★★	★★★
Validate 지원	☆☆☆	★★★	☆★★	★★★	★★★

좀 더 자세한 설명은 2편에서 이어집니다. ^o^