메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

한빛랩스 - 지식에 가능성을 머지하다 / 강의 콘텐츠 무료로 수강하시고 피드백을 남겨주세요. ▶︎

IT/모바일

Doctype을 올바르게 사용하자

한빛미디어

|

2002-04-22

|

by HANBIT

9,521

저자: 에릭 메이어(Eric Meyer), 역 전순재

개발을 하고 수년이 지난 지금 제작자들은 딜레마에 봉착했다. W3C 표준에 맞도록 페이지를 작성해야만 하는가? 아니면 이와는 별도로 브라우저의 버그를 고려하여 페이지를 작성해야 하는가? 이와 같은 딜레마는 앞으로 더 강력하게 대두될 것이다. 일단 W3C 표준에 맞는 페이지의 경우에는 시간이 갈수록 더욱 잘 작동할 것이다. 그리고 확실히 더 "순수할" 것이다. 그렇지만 대게 브라우저는 이러한 페이지들을 잘 표시해 주지 않았다. 브라우저의 버그를 고려하여 페이지를 작성한 경우에는 현재 브라우저에서 화면이 어떻게 표시될지 예측하기 조금 더 쉽다. 그리고 확실히 더 쉽게 팔 수 있고 관리할 수 있다. 그러나 미래에는 어떻게 될까? 만약 새로운 브라우저(강력하게 표준을 준수하는 브라우저)가 나와서 버그를 위한 호환성을 유지했다는 이유 때문에 웹 페이지의 화면을 부수면 어떻게 할 것인가?

우리들에게 이것은 쉽지 않은 선택이다. 한 번 추측해보자. 독점적인 버그와 행태라는 악순환을 빠져 나오기 위한 손쉬운 방법이 있다. 그리고 처음으로 그 방법을 선사한 사람들은 바로 다름아닌 마이크로소프트의 MacIE 팀으로 그 방법은 이른바 "문서형 전환(doctype switching)"이라고 하며 그 덕분에 삶은 더 편해질 것이다.

Doctype이란 무엇인가?

DOCTYPE 요소(element)를 처음 보는 독자들을 위해 아주 간단하게 정리하면, DOCTYPE은 한 문서가 사용하는 언어(그리고 그 수준)가 무엇인지를 선언하고 선택적으로 어떤 문서형 정의(DTD, Document Type Definition)를 사용하여 그 문서를 처리할 것인가를 선언하는데 사용되는 요소이다. 다른 말로 하면 문서 타입이라는 말이다. 예를 들어 HTML4 규격을 완벽하게 준수하는 문서는 다음과 같은 doctype을 가지고 있을 것이다.

반면에 "느슨한" 또는 일반적인 HTML4 문서라면 다음과 같은 doctype을 가질 수도 있다.

그런데 보통 이러한 요소들은 문서에서 가장 첫 번째 줄에 나타난다.

지금까지 DOCTYPE은 주로 HTML 유효성검사기(validators)가 사용해 왔으며, 그것을 보고 문서의 유효성을 검사하는데 어떤 DTD를 사용해야 하는지 알 수 있었다. 대다수의 제작자들은 DOCTYPE이 있다고 하더라도 크게 신경 쓰지 않았을 것이다. 그리고 DOCTYPE을 가진 수 많은 페이지들이 그렇게 된 원인은 물어보지 않고 자동으로 그것을 채워 넣어준 찍고-클릭하는 웹 저작 프로그램들 덕분일 것이다. 엄청나게 많은 경우에 웹 페이지들은 DOCTYPE이라는 요소를 전혀 가지지 않는다.

Doctypes 사용하기

이제 여러분은 이것이 무슨 차이가 있는지 궁금할 것이다. 순수하게 실용적인 관점에서 보면, 거의 별 차이가 없다. 웹에서는 doctypes이 있으나 없으나 겉보기에는 똑같이 문제없이 동작한다.

그러나 실제로는 브라우저가 문서의 형에 주의를 기울이고 있으며 이에 기초하여 동작을 선택한다는 사실을 기억해두기 바란다. 이 브라우저는 문서를 보고서 다음과 같이 말할 수 있다. "이 문서는 HTML을 엄격하게 준수하도록 선언되어 있군. 그러나 표준으로 문서를 다루어야겠어. 문서의 형식이 잘 구성되어 있지 않으면 표시하면 안되겠군. 구조가 유효하다면, W3C 표준을 사용해서 문서를 출력해야겠어." 똑같은 브라우저도 문서를 읽고 다음과 같이 생각할 수 있다. "이 문서는 doctype이 선언되어 있지 않군. doctype이 옛날 것이고 버그-호환성이 있다고 가정해야겠어. 그러니까 옛날에 버그투성이 브라우저가 표시하던 방식대로 표시해줄 필요가 있겠군."

이 브라우저는 매킨토시용 마이크로소프트 인터넷 익스플로러 5 이다.

이제 제작자들은 따르고 싶은 렌더링 모델을 선택하여 사용할 수 있다. 순수하다고 생각되는가? 표준을 엄격하게 준수하도록 문서를 작성하라. 그리고 문서에 엄격한 DOCTYPE을 부여하라. MacIE5는 엄격하게 규정된 문서들을 그 표준에 적절히 맞추어 표시할 것이다. 예전 브라우저의 행위를 따르고 싶은 생각이 드는가? 버그가 걱정된다면 덜 엄격한 DOCTYPE을 사용하는 것이 좋겠다. 그러면 MacIE5는 여러분이 작성한 문서를 화면에 표시해 주던 기존 행동을 모방할 것이다.

이 메커니즘의 매력은 제작자들이 표준에 맞추어 저작할 기회를 완전하게 부여하면서도 대부분 예전 문서들의 겉모습을 그대로 유지한다는 것이다. 이 메커니즘은 모든 사람에게 다시 시작할 기회를 준다. 제작자들은 브라우저의 버그를 배우는 것이 아니라 표준을 배우게 되기 때문에 더 나은 문서를 제작할 수 있다. 판매업자도 기존 페이지를 어쩔수 없이 "부수게 되지" 않고서도 표준을 구현할 수 있다. 누구에게나 이익이다.

다음에는 어떻게 doctype이 작동하는지 살펴 보겠다. 그리고 예제들을 보여 주겠다.

어떻게 작동하는가?

상당히 간단하다. 문서가 "엄격한(strict)" 모드에서 해석되기를 원하면 아래 두 가지부터 해야 한다.
  1. DOCTYPE을 삽입하여 엄격한 DTD를 문서에 요구해야 한다. 또는 URL로 지시하여 전통적인 DTD를 함께 사용한다.
  2. 확실하게 문서가 잘 형식화(well-formed)되고 유효하게 만들어라.
그게 다다. 두 번째로 쓴 말은 이것이 두 번째로 중요하다는 뜻이 아님을 명심해라. 문서가 엄격한 DTD를 사용해야 한다고 요구할 경우 문서는 확실히 그 DTD를 따라야 한다. 그렇지 않으면 그 페이지는 아주 보기 흉하게 일그러질 수 있으며, 어쩌면 화면 표시 자체를 거부할지도 모른다. 그리고 이것은 바로 여러분의 책임이 될 것이다.

HTML 문서가 표준을 준수하든 말든 별 관심이 없다면, 다음 둘 중의 하나를 선택할 수 있다.
  • DOCTYPE을 사용하지 마라.
  • 전통적인 DTD를 사용하라고 선언하되, URL은 포함시키지 마라.
문서의 유효성을 검증하기를 원하지만 그 문서가 엄격하게 표준을-준수하는 것을 원하지 않을 때 두 번째 경우를 유용하게 사용할 수 잇다. 또한 보여줄 페이지가 유효성 검사에 방해받지 않고 엄격하게 해석되지 않기를 원할 때는 첫 번째 경우를 명심하면 된다.

예제를 살펴 보자!

다음에 MacIE5에서 여러분이 겪게 될 여러 상황과 그 효과를 정리하면 다음과 같다.
MacIE5는 "strict" 모드로 들어갈 것이다.

URL 덕분에 MacIE5는 "strict" 모드로 들어갈 것이다. 그렇지만 이러한 행위는 피하는 것이 좋다. 왜냐하면 언젠가는 일시전환된 기존 문서들이 strict 모드 대신에 quirky 모드로 분류될 것이 틀림없기 때문이다.

MacIE5는 "유연한(quirky)" 모드로 들어갈 것이다.

MacIE5는 "유연한(quirky)" 모드로 들어갈 것이다. 버전 4 이전의 HTML용 DTD는 모두 "유연한(quirky)" 모드를 촉발시킬 것이다.

(전혀 DOCTYPE이 없다.)
MacIE5는 HTML 문서에 대하여 "유연한(quirky)" 모드로 들어갈 것이다.

마지막 사항에 주목하기 바란다. "엄격한(strict)" 모드를 촉발하는 것 중의 하나가 발견되지 않는 한, HTML 문서는 유연한(quirky) 모드를 디폴트로 취한다. 반면에 XML 문서는 엄격한(strict) 모드가 디폴트로 취급된다.

도대체 무슨 차이가 있는가?

엄격한 문서는 다르게 취급될 것이라는 뻔한 차이점은 제외하고라도, 엄격한 문서는 유연한(quirky) 문서와 두 가지 점에서 큰 차이가 있다. 우선 첫 번째 차이점은 모든 요소들이 테이블 요소도 포함하여 스타일을 상속받게 될 것이다. 유연한(quirky) 모드에서는 텍스트 컬러와 스타일을 상속받기가 어렵다. 두 번째 차이점은 font-size: medium 텍스트가 스타일이 지정되지 않은 텍스트와 동일한 크기가 될 것이라는 것이다. 유연한(quirky) 모드에서 스타일이 지정되지 않은 텍스트는 small과 같은 크기이다.

이 외에 다른 차이점도 있겠지만, 아마도 문서화될 것 같지는 않다. 왜 그럴까? 왜냐하면 시간이 지남에 따라, 제작자들은 버그지향적 행위에 의존하지 않게 될 것이기 때문이다. 안전한 환경이 조성된 채로 여전히 그곳에 있지만 그 안전함이 영원히 지속되리라는 것은 아무도 보장할 수 없다.

결론

마이크로소프트 MacIE 팀 덕택에 제작자들은 이제 버그 없이 저작을 할 수 있는 방법이 생겼다. 또한 예전에 작성해 두었던 문서의 겉모습에 대해서 걱정하지 않고 표준을 사용할 수 있는 기회도 생겼다. 이것이 또 다른 비호환성의 요인이 되지나 않을까 걱정하지 않도록, 넷스케이프의 개발팀은 같은 메카니즘을 Netscape 6에 적용하려고 한다. 따라서 많은 사용자를 거느리고 있는 이 두 브라우저가 제작자들에게 탈출구를 마련해 줄 경우 표준은 닻을 올리고 출범하게 될 것이다.

에릭 메이어(Eric Meyer)는 CSS&FP Working Group의 회원으로 『캐스테이딩 스타일 시트 핵심 가이드』의 저자이다.
TAG :
댓글 입력
자료실

최근 본 상품0