출처 : http://www.jakartaproject.com/article/javascripttip/119862980352206
XHTML과 HTML의 차이
XHTML과 HTML은 현재 가장 널리 사용되는 웹 문서 규격입니다. 이름에서도 알 수 있듯이 XHTML은 기존에 사용되던 HTML 규격이 가진 문제점을 극복하고, 보다 다양한 분야에 응용될 수 있도록 해주는 여러가지 확장된 기능을 포함하고 있습니다.
HTML을 XML 바탕으로 새롭게 구성(reformulation)한 XHTML은 CSS와 함께 최근에 많은 관심을 받고 있는 ‘웹 표준’의 중요한 요소가 되었습니다. 하지만 XHTML이 XML을 기반으로 만들어졌고, 이 XML을 모든 브라우저가 지원하지 않는다는 현실적인 문제 때문에 XHTML과 HTML이 사실상 큰 차이 없이 사용된다고 주장하는 사람들도 많습니다.
이런 시각을 다루는 좋은 글이 있어서 번역해서 소개합니다. 내용이 많아서 세 번으로 나눠서 포스팅하려고 하는데 글의 전문성에 비해 제 이해가 많이 부족하고, 원문을 요약한 것이어서 그 내용을 완벽하게 전달하는데 한계가 있으니 감안해서 보시기 바랍니다.
Tommy Olsson이 쓴 원문은 Site Point 포럼에 올라온 FAQ About XHTML vs HTML이니 참고하시고, dagger 마크(†)로 시작하는 단락은 원문에는 없는 보충 설명입니다. 이 글의 저작권은 원문의 저작자인 Tommy Olsson과 Site Point에 있으며, 블로그 전체에 적용되는 CCL보다 우선적으로 적용됩니다.
XHTML과 HTML의 차이점
- XHTML이 XML 문법을 따르므로 HTML과 문법 규칙이 약간 다르다.
- XHTML을 사용하면 할 수 있으나, HTML로는 불가능한 일이 있다.
- HTML을 사용하면 할 수 있으나, XHTML로는 불가능한 일이 있다.
- CSS를 이해하는 방식에 차이가 있다.
- 클라이언트 쪽의 스크립트(예: 자바 스크립트)를 다루는 방식에 차이가 있다.
첫 번째로 언급한 문법적인 차이를 다루는 문서는 많기 때문에 자세한 설명을 하지 않겠습니다.
XHTML을 사용하면 할 수 있으나, HTML로는 불가능한 일
- CDATA 섹션(
<![CDATA[ … ]]>) 사용.
이 섹션 안의 문자들은 태그로 처리되지 않기 때문에 따로 이스케이프(escape) 해 줄 필요가 없다. - processing-instruction 사용. 예를 들어 XML 문서에 스타일시트를 연결시킬 수 있다.
<?xml-stylesheet type="text/css" href="style.css" media="screen"?> - 다른 XML 이름 영역(namespace)에 있는 요소(element)들을 포함시킬 수 있다.
'캐릭터 엔티티(character entity)를 사용할 수 있다.
HTML을 사용하면 할 수 있으나, XHTML로는 불가능한 일
- 기존 HTML에서 사용하던
<!-- … -->코멘트로 스타일이나 스크립트의 일부를 주석 처리할 수 없다. - 문서를 읽고 있는 도중에는 페이지의 일부를 동적으로 생성할 수 없다(예:
document.write()사용). 같은 named entity를 사용할 수 없다. 미리 정의된<, >, &, "는 사용 가능.- 자바 스크립트에서
.innerHTML속성을 사용할 수 없다.
CSS를 이해하는 방식의 차이
- CSS의 Element type 선택자가 대문자와 소문자를 구별한다(case-sensitive).
- HTML에서는 BODY 요소의 background-color, background-image, overflow 속성이 최상위 요소(HTML)에도 적용되지만 XHTML에서는 적용되지 않는다.
HTML의 일부 시작 태그는 명시적으로 지정하지 않아도 CSS가 적용된다. 예를 들어서 표(table) body 태그의 헤더 셀(header cell)에 스타일을 적용하려고 할 때 다음과 같이 CSS 규칙을 지정할 수 있다.
tbody th { text-align: left }
HTML 문서에서는 <tbody>와 </tbody> 태그를 마크업하지 않아도 이 CSS 스타일이 적용되지만 XHTML에서는 태그를 마크업하지 않으면 적용되지 않는다.
클라이언트 쪽의 스크립트(예: 자바 스크립트)를 다루는 방식의 차이
document.write()메소드가 적용되지 않는다.createElement()같은 DOM 메소드는 반드시 이름 영역(namespace)에 대응되는 메소드로 바꿔줘야 한다(예:createElementNS()사용).- 표준이 아닌
.innerHTML속성을 사용할 수 없다. - CSS에서와 마찬가지로 명시적이지 않은 요소(element)에 관한 문제가 자바 스크립트에도 적용된다.
XHTML이 HTML보다 더 엄격한가(strict)?
그렇지 않다. XHTML을 포함하는 XML의 문법 규칙이 HTML에 비해 더 단순하고, 일관적이지만 마크업이 유효(valid)하다면 XHTML과 HTML은 동일하게 해석(parsed)된다.
† 이 질문에서 말하는 엄격함은 문법 규칙만을 고려한 것으로 보입니다. 단순히 문법적인 면을 따져봤을 때에는 XHTML이 HTML보다 엄격한 것이 분명합니다. 하지만 원문에서 그렇지 않다고 말한 것은 브라우저가 XHTML을 HTML과 동일하게 해석하기 때문이라고 생각되네요.
그는 문단 태그(<p>)를 예로 들었는데 HTML에서는 문단을 </p> 태그로 닫지 않아도 어느 곳에서 그 태그가 닫혀야 하는지 명백하게 판단이 가능합니다. XHTML에서 </p> 태그를 생략하면 검증기(validator)는 에러를 찾아내지만 실제로 브라우저는 아무런 문제 없이 HTML과 동일한 결과를 출력하지요. 왜냐하면 거의 대부분의 XHTML 문서가 실제로는 HTML로 브라우저에게 인식되기 때문입니다. 이것은 브라우저의 XML 지원과 Content-Type에 관련된 문제인데 이 부분에 대해서는 추후에 다루겠습니다.
또한, ‘strict’라는 단어에는 ‘엄밀(정밀)하다’는 뜻도 있습니다. 이런 의미로 해석할 경우에는 HTML이 XHTML보다 정밀하다는 표현이 맞습니다. HTML을 해석하려면 생략된 태그를 판단하는 추가적인 로직이 필요하니까요. 원문에는 HTML의 문법 규칙이 XHTML보다 복잡(more complicated)하다고 표현하고 있습니다. 이 부분에 관한 자세한 내용은 원문에 달린 댓글을 참고하시기 바랍니다.
XHTML이 HTML보다 더 의미 있는 마크업인가(semantic)?
그렇지 않다. XHTML 1.0 규격은 HTML 4.01 규격을 새롭게 구성한 것이므로 두 규격은 똑같은 요소(element)와 속성(attribute)을 가지며 세 가지 문서 타입(DTD)도 동일하다. 의미론적으로는 두 규격에 아무 차이도 없다.
† 이 글을 쓰게 된 동기 중의 하나가 이 문제 때문입니다. 많은 사람들이 XHTML이 HTML보다 더 ‘의미 있는’ 규격이라고 생각하는데 실제로는 차이가 없습니다. 오히려 XHTML Transitional 규격과 HTML Strict 규격을 비교해보면 HTML Strict 규격이 ‘구조’와 ‘표현’을 훨씬 엄격하게 구분하므로 보다 의미 있는 규격입니다. 따라서 HTML Strict DTD로 작성된 문서가 XHTML Transitional 문서보다 ‘웹 표준’을 보다 잘 준수한다고 말할 수 있습니다.
CSS는 XHTML과 HTML에 모두 다 적용되는가?
그렇다. CSS를 XHTML에서만 사용할 수 있다고 생각하는 사람들이 있는데 이것은 분명히 잘못된 정보이다. 최초의 CSS 규격은 1996년에 만들어졌고, XHTML은 그 후 사 년 후에야 만들어졌다.
DOCTYPE 선언은 어떻게 사용되는가?
문서 맨 앞에 선언되는 DOCTYPE이 브라우저 같은 클라이언트 프로그램(user agent)에게 해당 문서가 XHTML이라는 것을 알려주는 역할을 한다고 생각하는 사람들이 있지만 이것 역시 사실이 아니다. DOCTYPE 선언이 만들어진 원래의 유일한 목적은 마크업을 검증하기 위한 것이며, 브라우저는 마크업을 검증할 필요가 없으므로 이 선언을 무시하고 마크업을 해석한 다음 화면에 출력했다.
하지만 매킨토시 버전의 인터넷 익스플로러 5.0(IE5/Mac)이 발표되면서 처음으로 DOCTYPE 선언을 브라우저가 이용하게 되었는데, IE5/Mac 브라우저는 구 버전이나 형제 격인 윈도우즈 버전의 브라우저보다 웹 표준을 지원하는 면에서 큰 향상을 가져왔다.
웹 표준을 보다 잘 지키면서 정확하지 않은 IE의 CSS 렌더링에 맞춰서 개발된 많은 웹 문서들에 대한 호환성을 유지하기 위해서 DOCTYPE이 사용되기 시작했다. 이 기능은 이후 인터넷 익스플로러 6.0 버전에 도입되었고, 최근에 사용되는 대부분의 브라우저에는 이 기능이 포함되어 있다.
현재 DOCTYPE 선언은 두 가지 기능을 한다. 첫 번째는 검증기(validator)가 어떤 기준으로 마크업의 유효성을 확인해야 하는지에 관한 정보를 제공하는 것이고, 두 번째는 브라우저에게 어떤 렌더링 모드를 사용할지 알려주는 기능이다. 이것은 XHTML과 HTML의 차이와는 근본적으로 아무 관련이 없다. 하지만 XHTML을 올바르게 지원하는 브라우저는 XHTML을 엄격한 표준(strict standard) 모드로 렌더링하는데 그러기 위해서는 XHTML을 올바르게 브라우저에게 인식시켜야 한다.
XHTML과 HTML의 차이에 관해서는 이것으로 마치겠습니다. 원문의 정보가 100% 옳다고 확신할 수는 없지만 100개 이상 달린 댓글을 보면 어느 정도 검증된 문서라고 판단할 수 있으리라 생각합니다.
다음 글에서는 브라우저가 왜 대부분의 XHTML 문서를 HTML과 동일하게 받아들이지는 알아보도록 하지요. 앞서 언급했던 브라우저의 XML 지원과 Content-Type에 관한 문제입니다.
from
http://blog.wystan.net/2007/05/24/xhtml-vs-html
브라우저가 XHTML을 해석하는 방식
일반적인 환경에서는 XHTML 규격에 맞게 적성된 모든 문서가 실질적으로 HTML과 동일하게 처리됩니다. 이번 글에서는 왜 그런 결과가 생기는지 그 이유를 알아보겠습니다.
이 글은 앞선 글과 마찬가지로 Tommy Olsson이 Site Point 포럼에 쓴 글을 번역한 것으로 부분적으로 dagger 마크(†)로 시작하는 보충 설명을 넣었습니다. 따라서 이 글의 저작권은 원문의 저작자인 Tommy Olsson과 Site Point에 있으며, 블로그 전체에 적용되는 CCL보다 우선적으로 적용됩니다.
MIME 타입은 어떻게 적용되는가?
웹에 있는 문서나 자원(resource)을 HTTP 프로토콜을 통해서 요청하면 웹 서버는 요청에 맞는 결과(response)를 보내주게 된다. 요청에 대한 답변은 하나 이상의 헤더와 빈 행(CR+LR), 그리고 문서의 내용(body)으로 구성되는데, HTML이나 XHTML 문서에서는 우리가 작성한 마크업이 그 내용이 된다.
HTTP 헤더는 전송할 문서에 대한 메타 정보를 제공하게 되는데, 그 중에서 가장 중요한 헤더가 Content-Type 헤더이다. 이것은 브라우저와 같은 사용자 에이전트(user agent)에게 전송할 문서가 어떤 내용을 담고 있는 문서인지 알려주는 역할을 한다. 또한 이 헤더는 문서가 어떤 문자 인코딩을 사용하는지에 관한 정보도 포함할 수 있다. 일반적인 HTML 헤더는 아래와 같이 표현된다.
Content-Type: text/html; charset=iso-8859-1
여기에서 text/html 부분을 MIME 타입이라고 부르는데 이메일 전송에서 사용되던 문서의 내용을 정의하는 규격으로 HTTP 전송에도 동일하게 적용된다.
예로 든 MIME 타입은 미디어 타입 이름(text)과 서브타입 이름(html)으로 구성되며, 문자 인코딩 정보는 생략이 가능하다.
RFC 2854 규약에 따라서 이 MIME 타입은 문서의 내용이 HTML임을 나타낸다. 그러므로 브라우저는 해당하는 문서가 마이크로소프트의 워드 문서나 GIF 이미지, 또는 XHTML 문서라 해도 무조건 HTML로 인식하고 해석한다. 다시 말해서 MIME 타입이 text/html일 경우에 그 문서는 XHTML이 아닌 HTML 문서가 된다.
XHTML이 HTML로 해석된다는 것은 XML에서만 가능한 기능들을 전혀 사용할 수 없고, 반대로 HTML에서만 가능한 기능들은 사용할 수 있다는 의미이다. 하지만 그렇게 HTML의 기능을 사용하는 것은 XHTML로 마크업한 원래의 목적에 위배되는 일이 된다.
그러면 XHTML은 어떤 MIME 타입을 사용해야 하는가?
브라우저가 XHTML을 XML 문서로 인식하고 해석하려면 아래의 세 가지 MIME 타입 중의 하나를 사용해야 한다.
- application/xhtml+xml (추천함)
- application/xml
- text/xml (추천하지 않음)
W3C가 추천하는 MIME 타입은 RFC 3236 규약에 정의된 application/xhtml+xml 타입이다. 하지만 인터넷 익스플로러는 2006년 6월 현재까지 이 MIME 타입을 지원하지 않는다.
text/xml 타입도 사용할 수 있지만 기본 문자 인코딩을 처리하는 방식의 문제 때문에 추천하지 않는다. 이 타입에서는 HTTP 헤더에 인코딩 정보가 반드시 포함시켜야 하는데, 이것은 XML 선언에서 변경할 수 없다. 게다가 이 타입의 기본 인코딩은 도움이 되지 않는 US-ASCII 방식이다.
브라우저는 XHTML을 제대로 지원하는가?
아니다. 오페라, 파이어폭스, 사파리 같은 일부 브라우저는 XHTML을 지원하지만, 가장 많은 사용자를 확보하고 있는 인터넷 익스플로러가 XHTML을 제대로 지원하지 않는다.
호환성을 위해서 W3C는 XHTML 1.0 규격에 포함시킨 HTML 호환성 가이드라인에서 text/html MIME 타입을 사용하는 방법을 제시하고 있다. 하지만 이 MIME 타입을 사용하면 모든 브라우저는 해당 문서를 HTML 문서로 인식하고 해석한다.
실질적으로 모든 브라우저가 self-closing 태그(예: <br />)의 슬래시 기호를 무시하는 해석상의 버그를 갖고 있으므로 XHTML은 HTML과 동일하게 해석된다.
† XML 문법에서는 self-closing 태그의 슬래시 기호 앞에 공백을 넣지 않아도 문법적으로 아무 문제가 없으며, <br /> 태그를 <br></br> 태그처럼 사용할 수도 있습니다. 하지만 XHTML에서는 호환성을 위해서 이런 문법을 허용하지 않습니다.
<meta/> 태그에 지정한 MIME 타입도 적용되는가?
그렇지 않다. 브라우저는 HTTP 요청에 대한 답변으로 전송받는 내용(body)을 해석하기 전에 그 문서가 어떤 문서인지를 알아야 한다. 브라우저가 아래와 같은 메타 태그를 발견했을 때에는 이미 늦은것이다.
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8"/>
MIME 타입은 반드시 HTTP 헤더로 보내야 한다. 문자 인코딩에 대한 정보는 메타 태그가 아닌 XML 선언에서 명시되어야 한다.
† Lachlan Hunt의 블로그에 실린 Content-Type에 관한 글을 참고해서 내용을 보충하자면 이렇습니다. 메타 태그의 Content-Type은 브라우저 같은 사용자 에이전트(user agent)를 위해 만들어진 것이 아니라 서버가 HTTP 헤더에 실어 보낼 Content-Type을 동적으로 변경하기 위한 목적으로 고안되었지만, 실제로는 그 역할을 못하고 있습니다. 이 메타 태그가 수행하는 유일한 역할은 W3C가 제안한 바와 같이 문서의 인코딩 정보를 알려주는 것입니다.
그러면 HTTP 헤더가 없는 로컬 문서는 브라우저가 어떻게 해석하는가?
오페라와 파이어폭스는 로컬 문서의 확장자를 보고 어떻게 해석해야 할지 판단한다. 예를 들어서 xhtml, .xht, .xml. 확장자를 인식할 수 있다. 인터넷 익스플로러는 XHTML을 전혀 지원하지 않으므로 이런 방법이 적용되지 않는다.
그러면 어떻게 해야 XHTML에 맞는 MIME 타입을 지정할 수 있는가?
서버 환경에 따라서 방법에 차이가 있지만, 아파치 서버의 경우 다음과 같은 AddType 지시문을 사용할 수 있다.
AddType application/xhtml+xml .xhtml .xht
이 지시문은 .xhtml과 .xht 확장자를 갖는 문서를 application/xhtml+xml MIME 타입으로 전송하도록 서버에 지시한다. 이 명령은 아파치 서버의 전역 설정(/etc/httpd.conf)이나 웹 디렉토리의 .htaccess 파일에 적용된다.
이런 설정 파일에 접근할 수 없는 경우에는 서버-사이드 스크립트 언어를 사용해서 같은 결과를 얻을 수 있다. 예를 들어서 PHP 언어를 사용한 다음 코드를 이용할 수 있다.
header('Content-Type: application/xhtml+xml; charset=utf-8');
이 헤더가 문서의 내용이 전송되기 전에 브라우저에게 전해져야 한다는 것을 명심하라.
XHTML을 application/xhtml+xml 타입으로 전송하면 어떤 장점이 있는가?
말 그대로 브라우저가 XHTML을 XHTML로 인식한다. XHTML을 사용할 경우에만 얻을 수 있는 장점 때문에 XHTML 문서를 작성했다면 그 장점을 그대로 누릴 수 있다.
Content Negotiation 방식을 사용하면 해결되지 않는가?
Content Negotiation은 하나의 HTTP 요청에 대해서 두 가지 이상의 자원(문서, 이미지 등)을 준비해서 사용자 에이전트(user agent)에 따라 선택적으로 제공하는 방법이다. 예를 들어서 application/xtml+xml을 지원하는 오페라, 파이어폭스, 사파리 브라우저는 XHTML 문서를 application/xtml+xml 형태로 제공하고 인터넷 익스플로러가 요청할 때에는 HTML 마크업으로 작성된 HTML 문서를 text/html 형태로 보낼 수 있다.
하지만 이런 방법으로 얻을 수 있는 이점은 다른 컴퓨터 광(geeks)들에게 자신의 능력을 보여주는 것 외에는 전혀 없다. HTML로 변환시킬 수 있는 문서라면 XML만이 지원하는 기능을 전혀 사용하지 않았을 것이기 때문이다. 그렇다면 이름만 다른 두 개의 문서(XHTML, HTML)를 준비하는 것보다 HTML 4.01 스팩을 따르거나 XHTML을 text/html로 제공하는 것이 훨씬 쉬운 방법이다.
Content Type Negotiation은 더 의미가 없다. 같은 문서를 브라우저에 따라 서로 다른 Content-Type으로 보내서 얻을 수 있는 이점은 전혀 없다.
† Content Negotiation을 쉽게 이해하려면 GIF 이미지와 PNG 이미지를 생각하면 됩니다. 동일한 두 가지 이미지를 준비해서 PNG를 제대로 지원하지 않는 인터넷 익스플로러 6.0에게만 GIF 이미지를 전송하는 방법이지요. 자세한 설명은 Content Negotiation에 관한 위키피디아 문서를 참고하세요.
Content Type Negotiation은 모든 요청에 대해 동일한 내용(content)을 전송하면서 HTTP 헤더 정보만 달리하는 것을 말합니다. 동일한 문서가 XHTML도 되고, HTML도 되는 방식입니다.
인터넷 익스플로러에서 XHTML을 사용할 수 있는가?
불가능하다. 익스플로러가 application/xhtml+xml MIME 타입을 지원하지 않으므로 이런 헤더 정보를 받게 되면 해당 페이지를 다운로드하려고 한다. 레지스트리를 변경해서(hack) 이 MIME 타입을 인식하도록 할 수는 있지만 그렇다고 해도 해당 문서는 여전히 HTML로 취급된다.
XHTML의 XML 기능이 필요하다면 문서를 application/xml로 제공할 수 있다. 인터넷 익스플로러도 이 MIME 타입을 지원하지만 XHTML의 이름 영역(namespace)를 사용할 수 없으므로 해당 문서는 보통의 XML 문서로 인식된다. 따라서 스타일시트가 기본적으로 적용되지 않으므로, 모든 요소에 대한 스타일을 전부 지정해줘야 한다. 예를 들어서 모든 블록 레벨의 요소들에 display: block 속성을 지정해야 한다.
물론 XHTML을 text/html로 제공할 수 있다. 하지만 앞서 길게 설명했던 것처럼 브라우저는 그 XHTML 문서를 문법 오류가 있는 HTML 문서로 인식한다.
† 여기서 말하는 문법 오류는 닫는 태그 앞에 공백과 슬래시 기호가 있는 것을 의미합니다. 예를 들어서 <br /> 태그 같은 것이지요.
인터넷 익스플로러 7은 XHTML을 제대로 지원하는가?
그렇지 않다.
마지막 질문에 대한 짧은 답이 인상적입니다.
간단하게 요약하자면 브라우저가 XHTML을 제대로 지원하지 않고, XHTML과 HTML의 기능이 완벽하게 호환되지 않으므로 대부분의 XHTML 문서는 HTML과의 하위 호환성을 고려해서 작성된다는 얘기입니다. 그렇게 작성된 문서에 XML을 지원하는 브라우저에서만 해석 가능한 마크업이 들어갈 리 없으니 겉모습은 XHTML이라도 실제로는 HTML과 다를 바 없다는 것이 원문의 주장입니다.
다음 글에서는 그럼에도 불구하고 XHTML이 널리 사용되는 이유와 마지막으로 발표된 W3C의 XHTML 규격인 XHTML 1.1에 대해서 알아보도록 하겠습니다.
마지막으로 사용자가 자신의 웹 페이지를 요청했을 때 서버가 어떻게 답하는지 궁금한 분들은 W3C의 HTTP Head 서비스를 이용해 보시기 바랍니다. 제 블로그를 확인해 보니 아래 결과가 나오더군요.
200 OK
X-Powered-By: PHP/4.4.2AnNyung
Server: Apache -OOPS Development Organization-
Connection: close
Date: Thu, 24 May 2007 11:56:37 GMT
P3p: CP='CAO PSA CONi OTR OUR DEM ONL'
Content-Type: text/html; charset=utf-8
마지막 줄에 있는 Content-Type: text/html; charset=utf-8은 제가 이용하고 있는 비누넷 호스팅 서버의 기본 설정입니다. XHTML 문서의 메타 태그로는 바꿀 수 없다는 것에 주의하세요.
from
http://blog.wystan.net/2007/05/24/xhtml-mime-type
XHTML 1.1 규격의 용도와 호환성
W3C가 2001년 5월에 발표한 최종 XHTML 권고안이 XHTML 1.1 규격입니다. 하지만 XHTML을 소개하는 문서들의 대부분은 2000년 1월에 발표된 XHTML 1.0 규격에 관한 정보를 담고 있고, 현재 사용되는 XHTML 웹 문서들도 대부분 XHTML 1.0 규격을 따르고 있습니다.
그렇다면 최신 규격이라고 말할 수 있는 XHTML 1.1이 XHTML 1.0 규격에 비해 상대적으로 훨씬 덜 알려지고 덜 사용되는 이유는 무엇일까요? 해답을 찾기 위해서 먼저 두 규격의 차이점을 알아보겠습니다.
이 글은 앞서 작성한 글과는 달리 Tommy Olsson이 Site Point 포럼에 올린 글의 일부만을 인용해서 설명하도록 하겠습니다. 원문에는 XHTML 1.1 규격에 관한 부분이 상당히 간략하게 설명되어 있거든요.
XHTML 1.1과 XHTML 1.0의 차이는 무엇인가?
크게 두 가지 차이점이 있습니다. 첫 번째는 기존의 XHTML 1.0 규격에 모듈화를 도입했다는 것이고, 두 번째는 루비 주석(Ruby annotation)을 지원하기 위한 태그가 있다는 것이지요.
사실 XHTML 1.1은 실질적으로 기존의 XHTML 1.0, 그중에서도 XHTML 1.0 Strict 규격과 큰 차이가 없습니다. 왜냐하면 이 규격을 기반으로 모듈화를 도입했기 때문이지요. 그래서 XHTML 1.0 Strict 규격에 맞게 작성된 페이지는 DOCTYPE만 1.1로 바꿔주면 거의 대부분 아무 문제없이 마크업 검증기(validator)를 통과합니다. 문법적으로 달라진 차이점은 정확하게 세 가지입니다.
- 모든 요소에 적용되던
lang속성이 사라지고, 대신xml:lang속성이 도입되었다. a와map요소에 적용되던name속성 대신id속성을 사용해야 한다.- 루비(Ruby)를 지원하기 위한 요소가 추가되었다.
모듈화는 무엇을 의미하는가?
XHTML 1.1에 도입된 모듈화는 기존에 평등한 관계에 있던 태그 요소(element)들을 수행하는 기능에 따라 몇 개의 분류로 나눈 것입니다. 이렇게 나뉘어진 모듈들을 조합해서 XHTML 문서를 작성할 수 있고, 사용자에게 필요한 추가적인 모듈을 사용해서 문서의 기능을 확장할 수 있도록 한 것이지요.
W3C는 모듈화로 얻을 수 있는 이점을 다음과 같이 밝히고 있습니다.
“단순히 웹 문서에만 사용되던 HTML이 다양한 분야와 기기(모바일 기기, 디지탈 TV 등)에 점점 더 많이 적용되고 있는데 이들 각각은 서로 요구하는 조건이나 구현상의 한계가 다르므로 기존의 규격을 일괄적으로 적용시키기가 어렵다.”
“이런 문제를 해결하기 위해 도입된 모듈화를 통해서 서비스나 기기를 디자인할 때 표준에 맞게 만들어진 블록을 사용하고, 표준에 맞는 방법으로 어떤 블럭을 사용했는지 알려주는 방식으로 해당 기기가 어떤 모듈을 지원하는지 컨텐츠 커뮤니티(content community)에 명확하게 알려줄 수 있다. 그러면 컨텐츠 커뮤니티는 필요한 특정 모듈을 지원하는 이미 만들어진 기반(installed base)에만 신경을 써서 컨텐츠를 만들어낼 수 있다.”
“표준화된 방식을 사용함으로써 소프트웨어는 기기에 맞게 컨텐츠를 처리할 수 있고, 기기는 필요한 모듈을 처리하기 위한 소프트웨어를 자동으로 불러올(load) 수 있게 된다.”
“또한, 모듈화와 XML의 확장성을 이용해서 XHTML 표준을 어기지 않고도 XHTML 문서의 레이아웃과 디자인의 확장성을 높일 수 있다.”
† 원문을 의역하고 요약하는 과정에서 원래 의미를 잘못 전달할 수 있습니다. 언제나 오역을 염두에 두시고 봐주세요. ^^;
루비 주석(Ruby annotation)은 무엇인가?
루비는 특정한 텍스트와 관련 있는 다른 텍스트를 함께 표기하는 방법을 의미하며 중국어나 일본어 표기에 사용됩니다(프로그래밍 언어 ‘루비’와는 아무 관련 없음). XHTML 1.1 규격에는 루비 표기를 지원하는 모듈이 포함되어 있는데, W3C가 모듈화의 예를 들기 위해서 넣지 않았나 하는 생각이 드네요. 루비가 어떻게 사용되는지 알려드리기 위해서 W3C의 루비 주석 규격에서 가져온 이미지를 보여드리겠습니다.
설명하지 않아도 어떻게 사용되는지 아시겠지요? 다른 예를 이미지와 XHTML 1.1 코드로 알아보겠습니다.
<ruby>
<rb>WWW</rb>
<rt>World Wide Web</rt>
</ruby>
루비 주석에 관한 자세한 설명은 생략하겠습니다. ^^
XHTML 1.1을 브라우저가 지원하는가?
일단 인터넷 익스플러러는 XHTML을 제대로 지원하지 않습니다. 앞선 글에서 Content-Type에 관해 설명했듯이 XHTML의 XML 기능을 사용하기 위한 필수 요구 조건인 application/xhtml+xml MIME 타입을 인식하지 못하지요.
인터넷 익스플로러를 제외한 일부 브라우저, 예를 들어서 파이어폭스는 XHTML을 지원합니다. 하지만 그렇다고 해서 위에서 설명한 루비 주석을 작성하기 위한 마크업을 인식할 수 있을까요?
현재까지는 그렇지 않습니다. 파이어폭스에서 위에서 예로 들었던 루비 주석 마크업의 결과물을 보려면 플러그인을 따로 설치해야 합니다.
† 인터넷 익스플러로 5.0 이후의 브라우저는 제한적으로 루비 주석 표기를 지원합니다. 하지만 인터넷 익스플로러 5.0이 1999년에 발표되었다는 사실에서 짐작할 수 있듯이 W3C가 XHTML 1.1 규격에서 제안한 방식으로 구현된 것은 아닙니다. 비 표준적인 태그 지원이라는 얘기지요. 그러므로 XHTML이 아닌 HTML에서도 루비 주석을 표현할 수 있으며 XHTML의 MIME 타입과도 무관합니다.
XHTML 1.1은 XHTML 1.0과 마찬가지로 하위 호환성을 유지하는가?
이 중요한 문제의 답으로 Tommy Olsson의 글을 인용하겠습니다.
“XHTML 문서를
text/htmlMIME 타입으로 제공할 때에는 절대로 XHTML 1.1 규격을 사용하지 말아야 한다. 왜냐하면 XHTML 1.1에서lang속성이 금지(deprecate)되었기 때문에 HTML과의 하위 호환성을 유지할 수 없기 때문이다.”
XHTML 1.0에서는 HTML과의 호환성을 위해서 해당 문서가 어떤 언어로 작성되었는지 lang 속성과 xml:lang 속성 두 가지를 모두 지정할 것을 권장합니다. XHTML을 지원하는 브라우저는 xml:lang 속성을 이해할 수 있고, 그렇지 않은 브라우저는 lang 속성을 이해할 수 있으니까요.
하지만 XHTML 1.1을 text/html MIME 타입으로 제공하면 브라우저가 해당 문서를 HTML로 취급하게 됩니다. 당연히 xml:lang 속성을 해석할 수 없겠지요. 그 문서가 어떤 언어로 작성되었는지 알려줄 방법이 없다는 얘기입니다.
물론 사용한 언어를 지정하지 않아도 대부분의 브라우저는 지금 보시는 이 페이지 처럼 알아서 문서를 해석합니다. ^^; W3C의 XML 규격에는 이렇게 나와있네요.
“XML 문서를 처리할 때 문서가 어떤 언어로 작성되었는지 아는 것이 유용할 때가 많다(often useful). 어떤 언어로 작성되었는지 알려주기 위해서
xml:lang속성을 사용할(may) 수 있다.”
하지만 DTD 선언을 한 상태에서 xml:lang 속성을 지정하지 않으면 XML 검증기(validator)가 마크업이 유효하지 않다고 불평한다고 하네요. 결국 선언해야 한다는 얘기지요.
또한, 당장 브라우저가 아무 문제없이 문서를 해석한다고 해도 다른 기기에서 문제를 일으킬 가능성이 있으므로 Tommy Olsson의 주장이 옳다고 생각합니다.
그러면 XHTML 1.1 규격을 사용하지 말라는 것인가?
역시 Tommy Olsson의 글을 인용하겠습니다.
“루비 주석을 표기할 필요가 있고, 그 문서를 이용하는 사용자가 루비 주석에 관한 마크업을 해석할 수 있는 플러그인을 설치했을 경우가 아니라면 XHTML 1.1을 사용해서 얻을 수 있는 것은 아무 것도 없다.”
한 마디로 불필요하다는 얘기지요. 사용자가 가장 많은 인터넷 익스플로러는 XHTML을 아예 지원하지 않고, 그나마 지원하는 브라우저에서도 XHTML 1.1의 새로운 기능인 루비 주석을 표현하려면 플러그인을 설치해야 합니다. 게다가 HTML과의 하위 호환성도 보장할 수 없으니 그렇게 주장하는 것이 당연하지 않을까요?
대부분의 XHTML 문서가 왜 최신 규격이 아닌 XHTML 1.0 규격을 따르는지 알아봤습니다. 원래는 이번 글을 끝으로 XHTML과 HTML의 차이에 관한 글을 마치려고 했는데 아직 설명해야 할 것들이 남아있네요. 다음 글에서는 여러가지 문제점에도 불구하고 많은 사람들이 XHTML에 관심을 갖고 사용하려는 이유에 대해서 알아보겠습니다.
from
http://blog.wystan.net/2007/05/26/xhtml11-usage-and-compatibility
XHTML을 사용하는 이유
XHTML이 어떤 마크업 언어이고, 어떤 한계를 가지고 있는지를 앞선 글에서 알아봤습니다. 그렇다면 HTML 대신 XHTML을 사용하는 것은 과연 옳은 선택일까요? 이 주제에 관해서 포스팅하게 된 동기가 되었던 Tommy Olsson의 글에서는 이 문제에 대해서 부정적인 입장을 취하고 있습니다. XHTML이 실제로는 HTML과 거의 동일하게 취급되므로 구태여 XHTML을 사용할 필요가 없다는 주장이지요.
하지만 XHTML을 이용한 홈페이지와 블로그를 만들고 운영하는 제 생각은 그와는 다릅니다. XHTML이 HTML 대신 사용되는 것을 굳이 말릴 필요는 없다고 생각하거든요.
물론 이 문제에는 정답이 없습니다. 각자가 생각하고 판단해야 할 문제니까요. 그 판단을 돕기 위해서 각각의 주장에 대해서 자세히 설명하려는 것이 이 글의 목적입니다.
그리고 이 글은 XHTML 1.0과 HTML 4.01 규격을 비교하는데 중점을 두겠습니다. 하위 호환성을 보장할 수 없는 XHTML 1.1 규격을 특별한 목적 없이 사용해서 얻을 수 있는 것은 최신 규격을 지켰다는 심리적 만족 외에는 없다고 생각하므로 이 규격에 대해서는 언급하지 않겠습니다. 많은 사람들이 W3C의 권고안, 즉 표준을 완전무결한 기준으로 받아들이는데 그런 생각은 W3C의 권위가 불러오는 함정이 될 수 있습니다.
XHTML을 권장하지 않는 이유
먼저 Tommy Olsson의 글을 일부 인용하겠습니다.
“XHTML과 HTML 중에서 어느 것을 선택해야 하는지에 관한 절대적 기준은 없으며, 이 문제에 관한 여러가지 기술적인 문제들을 생각했을때 간단히 답할 수 있는 문제가 아니다. 하지만 현실적으로 가장 호환성이 높은 W3C의 마지막 표준은 HTML 4.01이라 말할 수 있다. 당신이 실제로 HTML로는 불가능한 XHTML의 기능을 사용해야 하는 경우를 제외하면 기술적인 면에서 XHTML을 사용해야 할 이유는 전혀 없다.”
“XHTML을 사용해서 실익을 얻으려면 XHTML과 HTML의 근본적인 차이점을 이해해야 한다. 하지만 XHTML을 제대로 사용하는 사이트를 이용할 수 있는 것은 전체 웹 사용자들의 일부일 뿐이다.”
“일부 웹 디자이너와 개발자들은 XHTML의 문법 규칙을 선호한다. 특정한 지침을 따른다면, XHTML의 기술적인 면을 전혀 사용하지 않고서도 XHTML의 문법을 사용할 수 있다. 이런 접근 방식에는 잠재적인 문제점이 있지만,
<br>태그 대신 반드시<br />태그를 사용하기를 원한다면 그 방식을 따르면 된다.”“당신의 문서가 미래의 환경에서도 유효하려면(future-proofing) XHTML과 HTML에서 어느 것을 선택하느냐 보다 Transitional 대신 Strict DOCTYPE을 사용하는 것이 훨씬 중요하다.”
그의 주장의 바탕이 되는 이유는 앞선 글에서 설명했던 브라우저의 XHTML 호환성 문제 때문인데 이에 관한 설명은 브라우저가 XHTML을 해석하는 방식을 참고하시기 바랍니다.
마지막 문장에 대해서는 XHTML과 HTML의 차이에서 이미 다루었지만, 중요한 의미가 있어서 다시 한번 짚고 넘어가겠습니다.
많은 사람들이 XHTML을 사용하면 문서의 ‘구조’와 ‘표현’을 HTML보다 잘 분리해서 보다 ‘의미 있는’ 마크업을 할 수 있다고 생각하지만 이것은 사실이 아닙니다. 이런 면에서 두 규격은 서로 대등하니까요. 동일한 Strict DTD로 정의된 XHTML 1.0과 HTML 4.01 문서는 사용할 수 있는 요소(element)와 속성(attribute)에 차이가 거의 없습니다. 단지 <br> 태그 대신 <br /> 태그를 사용하는 것처럼 문법 규칙이 다를 뿐이지요.
CSS를 사용하는 것도 마찬가지입니다. XHTML과 HTML 모두 동일하게 적용되지요. 그러므로 XHTML로 가능한 문서의 ‘구조’와 ‘표현’의 분리는 HTML로도 똑같이 할 수 있습니다.
하지만 점점 더 많은 사람들이 HTML대신 XHTML을 사용해야 한다고 주장합니다. Tommy Olsson은 그 이유를 다음과 같이 밝히고 있지요.
“많은 웹 디자이너와 개발자들이 XHTML 1.0의 발표에 환호했다. XHTML은 당시에 크게 유행했던 XML이었고 HTML처럼 쉽게 사용할 수 있었으며 모든 브라우저에서 잘 동작했다. 사람들은 XHTML의 확장성에서 많은 가능성을 발견했고, W3C가 더 이상의 HTML 규격은 아마도 없을 것이라고 발표하면서 XHTML이 미래 환경을 위한 유일한 대안이라고 생각하게 되었다.”
“시간이 흐르면서 XHTML 사용의 문제점과 확장성의 한계가 밝혀졌지만 XHTML에 대한 장밋빛 환상만큼 널리 알려지지는 않았다. 이 사실을 알지 못하거나 개인적인 선호 때문에 많은 사람들은 여전히 HTML보다는 XHTML을 사용해야 한다고 주장하고 있다.”
여기서 말하는 XHTML은 XML의 기능이 사용되지 않아서 HTML로도 충분히 처리가 가능한 마크업을 말합니다. XML의 기능이 꼭 필요하다면 당연히 XHTML을 사용해야겠지요. 하지만 이 글을 읽으시는 분들 중에서 XML을 사용했기 때문에 인터넷 익스플로러로는 접근할 수 없는 그런 페이지를 단 한번이라도 보신 적이 있는지요?
† 인용한 문장에서는 HTML 4.01이 W3C의 마지막 HTML 표준이 될 것이라 생각하는데, 이것은 Tommy Olsson의 원문이 2006년 6월에 씌여졌기 때문입니다. 현재 W3C에서는 HTML 5와 XHTML 5를 위한 워킹 그룹이 새로운 표준의 밑그림을 그리고 있습니다. HTML 5는 애플, 모질라, 오페라 진영의 사람들이 모여서 설립한 WHATWG에서 자신들이 개발중인 규격을 W3C의 새로운 HTML 규격을 위한 초안으로 채택해줄 것을 제안했고, W3C가 이 제안을 받아들이면서 세상에 그 이름을 알리게 되었습니다(2007년 5월). 현재 이 워킹 그룹의 편집 책임자는 구글의 Ian Hickson과 애플의 David Hyatt입니다.
그럼에도 불구하고 XHTML을 사용하는 이유
Tommy Olsson은 XHTML이 HTML과 다를 바 없으므로 HTML을 사용하는 것이 더 나은 선택이라고 주장합니다. 하지만 역설적으로 그렇기 때문에 XHTML을 사용하는 것이 아닐까요? 다시 말해서 HTML 대신 XHTML을 사용해서 얻을 수 있는 이점은 없지만, 그렇다고 해서 특별히 단점이 있는 것도 아니니까요.
XHTML을 HTML처럼 사용하는 것이 잠재적인 문제점(potential pitfall)을 안고 있다고 하지만 그것은 어디까지나 브라우저 같은 사용자 에이전트(user agent)의 내부적인 처리 방식의 문제입니다. 결과적으로 XHTML은 HTML과의 호환성을 유지하고, XHTML 문법 규칙은 혼란을 일으키지 않을 만큼 충분히 명확하기 때문에 사용자에게는 아무런 문제가 되지 않습니다.
또한 XHTML을 사용하면 HTML보다 양식화된(well-formed) 문서를 작성할 수 있는데 이것은 브라우저가 아닌 사용자 입장에서 특히 유익합니다. 브라우저는 </p> 태그가 없어도 문단이 어디서 끝나는지 명확하게 알 수 있지만, 사용자는 그것을 알기가 어려우니까요.
물론 HTML을 사용해도 동일하게 양식화(well-formed)된 문서를 작성할 수 있습니다. </p> 태그는 생략할 수 있는 것이지 생략해야 하는 것이 아니기 때문입니다. 하지만 XHTML을 사용하면 마크업 검증기(validator)가 문서의 양식을 더 꼼꼼하게 확인합니다. 따라서 XHTML 마크업을 작성하고 검증해보는 것이 양식화된 마크업을 익히는데 유리합니다.
미래의 웹 환경이 어떻게 달라질지 예상하는 것은 어렵습니다. 하지만 단시일 내에 모든 브라우저들이 완벽하게 XML을 지원하리라고는 믿지 않습니다. 개인적으로는 XHTML 문서를 나타내는 .xhtml 확장자가 지금의 .html 확장자 만큼 익숙해져야 XHTML 문서가 그 힘을 발휘할 수 있다고 생각하는데 그 때를 대비해서 XHTML을 써야한다고 주장하는 것이 아닙니다. 앞서 말씀드렸듯이 지금 작성되는 대부분의 XHTML 문서에는 XML 만의 기능이 들어가 있지 않으니까요. XHTML의 하위 호환성을 고려했을 때 HTML 대신 사용해도 무방하다는 것이 제 의견의 요지입니다.
마치면서
XHTML과 HTML 규격의 차이점을 다루는 글을 쓰게 된 동기는 ‘웹 표준’과 XHTML 사용을 동일하게 받아들이는 일부의 시각 때문입니다. HTML 4.01 규격도 엄연히 W3C가 제정한 표준 권고안임에도 불구하고 XHTML과 CSS를 사용해야만 웹 표준을 지킬 수 있고, 그것이 무조건 더 좋은 방법이라고 생각하는 분들이 있는데 절대적으로 틀린 생각입니다.
웹 표준을 잘 지키고 그 장점을 누리기 위해서는 XHTML과 HTML의 차이가 아니라 Strict와 Transitional DTD의 차이를 아는 것이 훨씬 더 중요합니다. 이 주제에 관해서는 나중에 다루도록 하고, XHTML과 HTML 규격의 차이점에 관한 글은 이것으로 모두 마칩니다.
from