웹표준, 디자인과 정보/데이터의 분리 필요한가?

전의 게시물에서 웹표준에 부정적인 글을 올린 바 있습니다(웹표준과 CSS, XHTML, HTML, CSS 그리고 테이블, 표준은 어디에나 존재한다. but…). 그 당시 웹표준(CSS+XHTML)에 대해서 회의적인 글이었는데, 일모리님의 좋은 포스팅으로 인해서 웹표준을 따르는 형식을 간단하게나마 구현하는 것이 좋지 않을까 라는 생각도 들었습니다.

그런데, 지금 나오는 웹표준에 대한 이야기는 조금 더 포괄적으로 접근하고 있습니다.

AJAX, XML, RDF 즉, 데이터의 표현 형식과 이동 방법까지도 얘기가 나오고 있는데, 이 부분에 대한 색다른 고찰을 해 보려 합니다.

데이터란 무엇인가

웹 초창기에는 데이터는 당연히 텍스트와 표에 한정되었습니다. 그것은 전통적인 태그들을 보면 알 수 있겠죠. 트래픽도 한정되어 있었기 때문에 추가한다면 그림 정도가 됩니다. 하지만, 현재의 데이터는 꼭 그런것은 아닙니다. 정의하자면 “디지털로 전송될 수 있는 모든 것”이라고 볼 수 있습니다. 기술적으로 말하자면, 인코딩/디코딩이 가능한 정보입니다. 이론적으로 그런 정의에 따른다면 지구상에 존재하는 모든 것이 인터넷 상의 데이터로 존재할 수 있습니다.

그럼 정보는 무엇인가?

일반적으로 데이터가 데이터 그 자체(Raw)로 의미를 갖는데 반해 정보는 받는 입장에서 봐야 합니다. 즉, 같은 데이터라도 보는(혹은 듣는) 이의 반응이 틀리다면 그것은 다른 정보를 갖는다고 볼 수 있습니다.

이 같은 것을 쉽게 쓴다면, “데이터는 정보를 싣고” 라는 말이 성립됩니다.

웹표준은 정보를 정확히 전달할 수 있는가?

정보 전달의 목적으로 나온 것이 XML이라는 것인데, 기본적으로 정보의 프리젠테이션 레이어(어떻게 보여지느냐)를 분리해서 정보 그 자체의 처리를 쉽게 하고, 공유까지 가능케 하는데 목적이 있습니다. RSS를 예로 들면 블로그의 RSS를 공개할 경우 다른 메타사이트나 RSS 리더가 쉽게 그 내용을 가져오거나 볼 수 있게 할 수 있습니다.

여기서의 문제는 정보의 의미를 XML이 제대로 전달할 수 있느냐 하는 것입니다.

독방에서만 수십년을 살아온 사람이 아니라면 “분위기”라는 것이 정보 전달에 있어서 매우 중요한 역할을 한다는 사실을 알 수 있을 것입니다. 그리고, “아는 만큼 보인다”라는 말은 지금도 흔히 통용되고 있습니다. 만약 정보(그림, 비디오, 글, 폰트, 음악, 소리, 그 밖에 돌에 쓰여진 그림, 음악과 같이 흘러나오는 시 같은 여러가지 정보의 복합체를 포함)의 제공자가 특별한 분위기를 전하기 위해서 여러가지 형태의 정보를 결합한 새로운 컨텐츠를 제공한다고 할 때, 그것을 웹표준이라는 것이 정확히 전달할 수 있을까요? 플래시로 구현된 복합 저작물이 AJAX로 구현될 수 있을까요?

이러한 복합 저작물을 영어로는 리치미디어라고 불리웁니다. 여기서 리치는 고대역 트래픽을 사용한다는 의미로 통용되는데, 보통은 동영상 플래이어나 플래시 기반의 컨텐츠를 말합니다.

웹표준은 기본적으로 “분리”를 추구합니다. 즉, 컨텐츠를 어떤 테마로 쪼개고 쪼개서 보는 이가 재조립을 해서 볼 수 있게 만들고, 그것을 표준화시켜서 많은 데이터를 다룰 수 있게 만들어 줍니다. 그것은 공학적인 접근에서 본다면 일 자체를 매우 편하게 해주는 의미가 있습니다.

실제로 만약 모든 인터넷상의 데이터들이 XML을 정확히 따른다고 하면 검색엔진의 크롤러(컨텐츠를 가져오는 프로그램)를 제작하는 것이 더욱 용이해 질 것임에 틀림없습니다.

하지만, 표준화의 문제에서 항상 불거져나오는 문제는 표준을 따르지 않는 컨텐츠는 전달할 방법이 없다는 것입니다.

표준을 따를 수 없는 컨텐츠

만약, 어떤 컨텐츠 제작자가 배경음악을 5초 후에 나오게 만들고, 글은 처음 보여지고 10초 후에 하단으로 내려가며, 마우스가 움직일 때마다 글자가 약간씩 움직이고, 글을 다 읽은 사람은 저작자에게 메일을 보낼 수 있는 컨텐츠를 제작하고 싶어 한다고 칩니다.

이 경우 표준이고 뭐고 의미가 없어져 버립니다. 검색엔진은 텍스트 위주로 보여줄 뿐이고, 동영상 검색도 동영상만을 검색하게 됩니다.

데이터 이동에 있어서 표준의 의미

웹표준이라는 것은 원론적으로 말하자면, 만드는 이를 위한 것이 아니라 보는 이를 위하는 것입니다. 또한, 데이터 이동에 있어서의 표준화는 데이터 가공자를 위한 것이라고 볼 수 있습니다.

CSS+XHTML을 적용하는 웹2.0 기업을 유심히 보면 대부분 컨텐츠 제작보다는 남의 컨텐츠를 쓰고 있다는 사실을 알 수 있습니다. 컨텐츠 제작자는 원래가 데이터를 편하게 공유한다는 것 보다는 자신의 의도한 데로 컨텐츠가 보여지기를 원합니다. 심지어, 음악 제작자는 미디어 플래이어의 속도조절 기능도 원치 않는 경우가 있습니다.

이런 것을 생각해 본다면 컨텐츠 제작자에게 컨텐츠를 표준화 시켜서 만들어 달라는 주문을 해야할까요? 이것은 제가 보기엔 본말이 전도됐다고 밖에는 보이질 않습니다.

표준은 간단하고 일반적이어야 한다

년차가 높은 엔지니어들이 느끼는 것으로 표준이라고 하는 것은 단순(Simple)과 일반적(General)이라는 두가지 특징은 필수적입니다. 모듈과 모듈의 결합도 용이하고 업데이트도 비교적 쉽게 할 수 있습니다. 결정적으로 두가지 요건을 충족시키지 못한 기술은 표준이 될 가능성이 매우 적어지게 됩니다.

하지만, 그것은 엔지니어의 이야기고, 컨텐츠 제작자가 꼭 엔지니어일 필요는 없습니다. 같은 이야기로 모든 컨텐츠가 리더로 읽을 필요는 없습니다.

미래의 웹표준이 어떻게 바뀌건 과거의 표준처럼 간단하고 일반적이어야 할 필요가 있습니다. 그리고, 데이터를 만지는 검색엔진과 같은 시스템은 더욱 일반적인 페이지를 다룰 수 있어야 한다고 믿습니다.

그런 의미에서 RSS만을 검색하는 블로그 메타사이트 보다는 전세계 동영상만을 검색해 주는 야후의 동영상 검색(MRSS와 병행해서 사용하지만)이 미래의 주류가 되야 한다는 것에 한표를 던집니다.

에피소드

포탈들이 홈페이지 무료 서비스를 할 당시 개인 웹사이트들은 개성이 있었습니다. 스크롤되는 시도 있었고, 어설프게나마 플래시로 올려놓고, 폰드도 무지막지하지만 재미있게 꾸미던 페이지들이 많았습니다.

이런 재미있는 페이지들이 없어지고, 비슷한 폰트, 비슷한 디자인으로 전환된 데에는 W3C의 표준이 크게 작용했다고 생각합니다. 그것이 트랜드일지도 모르겠지만, 표준화의 미래가 획일적인 문자로 된 컨텐츠가 되는 모습은 보고 싶지 않습니다.

검색엔진이 잡아낼 수 없는 컨텐츠를 사용자가 자신의 웹페이지에 만들어 놓은 링크를 쫓아가서 발견할 때의 즐거움은 없애고 싶지 않은 NET만의 것이며, 기술적인 스펙 보다 인터넷의 가장 기본이 되는 연결고리인 A태그(링크)를 어떻게 활성화시키고, 해석할 수 있는지 보다 놓은 수준의 연구가 있어야 할 것으로 생각합니다.

표준은 어디에나 존재한다. but…

nmind님의 언급처럼 표준이라는 것은 기술적인 것 보다는 약간은 정치적인 면이 있습니다. 시장이 커지면 보통 미국에서부터 표준화 작업이 이루어 집니다. 비영리 단체에서 그러한 일을 하고 있으며, 웹에서는 보통 W3C에서 관련 표준화 작업을 진행합니다.

마이크로소프트에서 만드는 OS도 표준이 존재하고, 비쥬얼 스튜디오에서 지원하는 언어들도 표준이 존재합니다. 심지어는 종교도 표준이 존재합니다.

일반적으로 표준은 처음엔 많이 쓰이는 부분을 묶는 것부터 시작하고, 시간이 지나면 선도적인 권고를 내놓습니다. 지금은 쓰이지 않아도 이렇게 하면 모든 이에게 이롭다는 식입니다. W3C에서 현재의 표준으로 삼는 XHTML1.1+CSS2.0이 과연 모든 이에게 이로울까요?

CSS 레이아웃의 표준

CSS 레이아웃을 만드는 것에 가장 불리한 점은 “쉽지 않다”라는 점입니다. 무슨 이야기냐 하면 W3C에서 제공하는 레퍼런스만을 보고 디자인을 할 수가 없습니다. 즉, 브라우져에 띄우기 전까지는 어떻게 나올지 알 수 없다는 이야기입니다.

즉, 테이블 레이아웃을 적용할 때에는 IE, FireFox, Safari 등의 태그 레퍼런스를 참고하지 않아도 디자인이 가능합니다. 그 이유는 테이블이라고 하는 것은 웹이 처음 생길 때 부터 존재했던 것이기 때문이죠. 하지만, CSS는 여러가지 브라우져가 나온 이후에 생긴 것으로 브라우져마다 적용 방법이 약간씩 틀립니다.

우리는 왜 브라우져 핵을 사용해야 하는가?

저도 과거에 CSS만으로 웹페이지를 구성한 적이 있습니다. 코드와 디자인의 분리는 만드는 입장에서는 꽤나 매력적인 것이 사실입니다. 즉, 코드는 DIV로 쌓여져서 그 자체로 데이터만 넣고, 디자인은 style.css 등의 파일 안에 넣습니다. 디자인을 고칠때에는 style.css파일만 수정합니다. 정말 매력적입니다.

하지만, 오래 지나지 않아서 브라우져 별로 CSS를 적용하는 것이 쉽지 않다는 것을 알게 되었습니다. 그리고, 전혀 불필요하지만 CSS만으로 디자인 할 때 필요한 것, 즉 브라우져 핵을 써야한다는 사실도 알았습니다. 브라우져들이 CSS를 적용을 달리하는데 우리는 한개의 CSS로 둘 다 제대로 나오게 해야 합니다. 프로그래머의 경우는 보통 동일 API를 사용할 수 있는 라이브러리를 만들어서 코딩을 하는데, 하나의 프로그램 코드가 유닉스던 리눅스던 윈도우던 동일한 출력을 보장하게 하는 가장 편한 방법입니다. Google이 Picasa 리눅스 버젼을 만든 방법이 이것입니다.

하지만, CSS는 단순한 상속의 개념은 있지만, 클래스처럼 그것을 자유롭게 활용하기가 구조적으로 불가능합니다. CSS 3.0에서는 해결이 될 것 같지만, 현재는 모든 브라우져에서 동일한 출력을 보장하는 CSS 파일은 불가능합니다.

따라서, 선택은 세가지로 압축됩니다. 브라우져 핵을 이용하거나, 브라우져 별 별도의 CSS를 만들거나 아니면 디자인 자체를 핵이 필요없는 것으로 바꾸거나…

방금 검색을 해서 알아본 두가지 CSS 코드를 소개합니다.

<style type=”text/css”>
#mydiv {
color: blue;
drdoc: “;
drdoc: “”;
color: red;
background: silver;
/*”;/* IE */
font-weight: bold;
}
#nextdiv {
color: red;
}
body {
background: navy;
}
</style>Note: IE will continue parsing after /* IE */

그리고,

<style type=”text/css”>
#mydiv {
color: blue;
/*/*/
drdoc: “;
drdoc: “”;
/* NN4 */
color: red;
background: silver;
/*”;/* IE */
font-weight: bold;
}
#nextdiv {
color: red;
}
body {
background: navy;
}
</style>

이것은 라운드 박스를 구현하는 CSS입니다.

border: 2px solid gray;
-moz-border-radius: 25px;
width: 400px;
height: 200px;
padding: 15px;

브라우져 호환성을 갖게 하기 위한 노력으로 이런 코드는 레퍼런스도 없습니다. 해보고 되면 블로그등에 올려서 전파됩니다. 그러고보니 집단지성이군요.

이 글을 보시는 관계자 분들은 위의 코드를 해석하실 수 있습니까? 만약 전임자가 이런 코드를 넣었다면 수정하실 수 있겠습니까?

CSS로 잘 만든는 것은 무엇을 의미하는가?

CSS가 쉽지 않다는 것은 누구나 알고 있습니다. 보통 CSS가 레이아웃을 잡는데 “잘 만들면” 더 생산적이고 편하고 빠르다라는 말을 하는 분도 있습니다. 물론 실력이 있어서 브라우져 핵을 자유롭게 쓰는 분일 것입니다.

여기서도 문제는 있습니다. 브라우져 핵이 필요한 CSS파일을 누군가는 만들어야 합니다. 프로그래머? 디자이너? 컨텐츠 제작자? 만약 웹디자이너가 한다고 하면 기업에서 면접을 볼 때 브라우져 핵을 하지 못하면 뽑지 말아야 하나요?

XHTML은 1.1버젼에서 HTML4.0과 양립할 수 없습니다. 어떤 해결방법이 있을까요? 전 현실적인 문제로 인해 찾을 수가 없습니다.

난 XHTML1.1+CSS2.0을 반대하는 것이 아니다. 하지만 불편한걸 어쩌나?

CSS를 설명하는 블로그를 보면 보통 팁으로 설명합니다. 브라우져 핵도 마찬가지구요. w3schools.com은 CSS 초기버젼을 잘 설명해 주고 있습니다.

제가 의문을 제기하는 것은 CSS 레이아웃에 한정하는 문제입니다. 어떤 분은 가능하다, 어렵지 않다 라고 합니다. 우리는 CSS로만 레이아웃을 할 때 아래와 같은 기능을 해야 합니다.

1. 모든 브라우져에서 같은 디자인이 출력되어야 한다.
2. 디자이너가 디자인 한 것 그대로가 화면에 나와주어야 한다.
3. CSS는 화면 크기를 변경했을 때 원하지 않는 동작을 하면 안된다.
4. 가로 길이가 %로 정해졌을 때도 3번은 지켜져야 한다.

제 경험으로는 위의 것을 CSS 레이아웃만으로 구현하는 것은 가능은 할 지언정 절대 쉽지 않습니다.

이렇게 되면 하겠다.

아래의 것들이 완벽히 작동된다면 CSS 레이아웃은 사용할 가치가 충분하지 않을까 합니다.

1. 브라우져별 공통의 CSS 레퍼런스가 존재하고, 그것이 제대로 작동된다.
2. 1번이 안된다면 공통 스타일 파일이 존재하고, 파일 레퍼런스만 지키면 대부분 브라우져에서 작동한다.

이 글은 Jay G님의 글에서 반론을 제기받고 답변으로 쓴 글입니다.

XHTML, HTML, CSS 그리고 테이블

용어의 혼돈으로 단문으로 쓰는 것이 좋을 것 같아서 차분하게 정리해 봅니다.

사실

1. XHTML1.1+CSS2.0은 현재 표준이라고 불리우지만, 영문으로는 권고라고 한다.

2. XHTML은 HTML의 확장판이며, HTML을 포함하고, XML형식의 모든 언어를 포함하는 구조를 지칭한다.

3. CSS에서 말하는 접근성은 일반적으로 시작장애자나 마우스가 없는 컴퓨터에서 쓸 수 있도록 만든다는 의미의 접근성과는 틀리다. 사람이 대상이 아닌 프로그램이나 기기(device)가 인식하기 쉽도록 한다는 의미이다. 예를 들어서 제목을 H 태그로 쓰면 다른 프로그램은 그 문단이 제목 혹은 중요한 문단이라는 것을 알고 가중치를 부여하는 등의 행위를 할 수 있게 된다.

4. CSS만으로 레이아웃을 하는 것은 어려운 작업이다. 하지만, 불가능한 것은 아니다. 일반적으로 테이블로 디자인 했을 경우 같은 디자인이라도 CSS만으로 만들면 경우에 따라서 뉴스가 된다.

주장

1. 테이블 레이아웃은 생산성 면에서 CSS 레이아웃보다 뛰어나다.

2. 유지 보수 측면에서도 CSS 레이아웃은 테이블 레이아웃보다 나은 점이 없다. 왜냐하면 테이블 레이아웃은 그 자체로 문서와 하나가 되지만, CSS는 보통 별도의 파일에 레이아웃이 스타일만으로 들어가 있기 때문에 다른 사람이 만든 디자인을 분석하는 것은 쉽지 않다. Yahoo!은 선도적으로 XHTML과 CSS만으로 첫페이지를 꾸몄는데, 그 소스를 보고 디자인을 수정하는 것을 상상해보자.

3. XHTML과 CSS레이아웃은 경우에 따라서 양립하기가 쉽지 않다. 왜냐하면 XHTML은 모듈의 결합을 추구하는데, 여기서 모듈이란 컨텐츠 만이 아니라 디자인까지 포함된다. 10가지 모듈이 DIV태그에 쌓어여 존재할 때, 디자인에 따라서 모듈간 감싸는 DIV 태그는 틀리다. 이 말은 CSS파일의 수정 만으로는 디자인 변경이 불가능하다는 의미다. 원래의 XML은 완벽하게 디자인과 문서가 분리된다. 하지만, XHTML은 그렇지 못하다.

4. 경험상 가장 편한 제작방법은 레이아웃을 테이블로 잡고, 각각의 모듈만을 DIV로 감싸는 것이다. 특별한 디자인이 필요할 경우(메뉴나 라운드가 들어간 사각형), 일부러 CSS만으로 디자인 할 필요는 없다. 보통 이런 경우 익스플로러와 사파리, 혹은 파이어폭스 간의 호환성을 맞추기 위해서 많은 시간이 투자되어야 하기 때문이다.

5. 이종기기간 호환성은 환상이다. 마치 컴퓨터를 살 때 CPU 교환이 되어 미래에도 사용할 수 있다고 홍보하는 것과 마찬가지이다. 컴퓨터가 구형이 되면 CPU와 램 확장만으로 원하는 성능을 얻는 것은 사실상 불가능하다. 마찬가지로, 어떤 웹사이트에서 모바일용 웹사이트를 런칭한다고 하면 그것은 새로 제작되어야 한다. 디자인, 프로그램 그리고 비지니스적인 면에서 봐도 마찬가지다.

6. 이종기기간 호환성과는 별개로, 브라우져간 호환성은 매우 중요하다. 특히 돈을 받고 이미지 광고 같은 것이 있을때는 더욱 그렇다. 만약 브라우져간 호환성이 없어서 페이지가 제대로 보이지 않을 때에는 세이클럽처럼 호환성이 없는 브라우져에서 아예 서비스를 하지 말아야 한다.

7. 브라우져간 최고의 호환성은 CSS를 쓰지 않는 것이다. 브라우져 호환성은 익스플로러나 사파리, 파이어폭스 만을 말하는 것이 아니라 각 브라우져 별 버젼 호환성을 포함한다. Google의 검색 첫화면의 소스를 보도록 하자. 테이블 레이아웃이고, XHTML이 아닌 HTML로 제작되어 있다. 현재까지 하휘 호환성은 브라우져별 호환성과 마찬가지로 중요하다.

8. 흔히 말하는 접근성은 CSS로 레이아웃을 잡느냐 테이블로 잡느냐와는 상관이 없다. 보통, 키보드만으로 사용이 가능한지 혹은 800*600의 256컬러로도 제대로 보이는지 등을 말하고, 그것은 디자인 자체와 HTML 코드의 사용에 기인한다.

9. XHTML에서 말하는 표준과 파이어폭스에서 제대로 안보인다 라고 할 때의 표준은 전혀 다른 말이다. 일반적으로 표준이 아니다라고 말 할 때에는 익스플로러에만 있는 Javascript나 태그를 사용하는 것을 지칭한다.

다음 부터는 어이없는 예측

W3C가 HTML, XHTML 그리고 CSS를 포함만 많은 부분에서 권고를 발표하는 것은 제 생각에는 웹페이지 제작자가 참고해야 될 부분이 아니라 브라우져 제작자가 참고해야 할 부분입니다. 연구&개발이 아닌 다음에야 원하는 디자인을 보여주는 것이 목적이 아닐까요?

표준을 따르는 것 자체가 목적이 되면 앞뒤가 바뀌는 것이 아닐까 합니다.

웹표준과 CSS

일모리님은 한국 웹표준의 전도사로서 정확한 지식을 전달하는데 많은 도움을 주고 계신 분입니다. 이 글은 어떤 정보가 다른 쪽으로 해석될 수도 있다는 것을 보여주기 위해서 쓰여졌으며, 모든 내용은 실전에 적용을 해 본 후 나름대로의 느낌을 적은 것임을 먼저 알려드립니다.

웹표준과 CSS은 관계가 없다.

원론적으로 이야기하자면 처음 CSS가 W3C에 권고될 때가 1996년 12월 17일로 정확한 문서의 제목은 “Recommendation: CSS level 1“입니다. 스펙을 보면 느낄 수 있겠지만, 기존 태그를 style로 대체하기 위해서 만들어진 것을 쉽게 알 수 있습니다. 그리고, 태그에 확장성을 가미해서 더 쉽게 디자인 할 수 있는 것도 중요하겠죠. 이 문서로 인해 CSS의 기본 문법이 정해졌습니다. 스타일간 그룹화가 가능하고, 상속도 가능합니다. 하지만, 이 문서에 레이아웃에 대한 것은 전혀 나와있지 않습니다.

현재는 어떨지 몰라도 처음 CSS가 나올때는 더 편하고 쉽게, 그리고 많은 기능을 구조적으로 선언하기 위해서 만들어 졌다는 사실을 알 수 있습니다.

그렇다면 웹표준 이야기가 나올때 왜 CSS라는 것이 나올까요? 일모리 님의 지적대로 정확히 말하자면 CSS가 아니라 XHTML이라고 칭해야 합니다. 즉, CSS+XHTML이 정확한 표준이 되는 것이지요.

위의 말처럼 레이아웃을 체처두고 텍스트 문단만을 HTML 태그 대신 CSS로 적용하면 많은 잇점이 생기게 됩니다. 구조화가 되었기 때문에 간단한 수정은 한줄만 바꾸어도 곧바로 적용이 됩니다.

문제의 핵심 XHTML로의 접근

XHTML은 XML형태로의 HTML을 구현하기 위해서 만들어 졌습니다. 아마도 W3C는 HTML 4를 마지막으로 그 이상은 없으며 XHTML로의 이행을 바랬을지도 모르겠습니다.

의도가 무엇이던간에 XHTML 1.0버젼은 그 자체로 HTML보다 엄격한 규칙이 존재하지만, HTML 4의 재구성버젼이고, 따라서 기존 HTML을 렌더링하는 브라우져에 보여지게 됩니다. 문제가 되는 것은 XHTML 1.1버젼입니다.(XHTML 2.0도 있으나 이 부분은 컴퓨터만이 아닌 많은 디바이스에서 대용량 문서를 구현하는 것도 포함하는 매우 광범위한 문서 기준이므로 생략합니다.) W3C의 행보를 보면 HTML을 XHTML로 흡수하고, 다른 MathML과 같은 태그기반도 흡수하려는 생각으로 보입니다. 당연한 것이 XML의 기본 생각이 모든 데이터에 구조화된 태그를 붙여 상호 연동이 수월하도록 하는데 있습니다. 사실 이 얘기는 매우 오래전부터 논의되어 왔습니다.

XHTML의 실체가 무엇인가?

W3C 인용:

XHTML document type that is based upon the module framework and modules defined in Modularization of XHTML [XHTMLMOD]. The purpose of this document type is to serve as the basis for future extended XHTML ‘family’ document types, and to provide a consistent, forward-looking document type cleanly separated from the deprecated, legacy functionality of HTML 4 [HTML4] that was brought forward into the XHTML 1.0 [XHTML1] document types.

위 내용에서도 알 수 있듯이 XHTML 1.1은 현재 그리고 미래의 모듈 프레임웍을 구현하기 위한 스팩입니다. 즉, CSS는 디자인의 구조화를 위해서 생겨난 것에 비해서 XHTML은 HTML을 XML형식의 프레임웍으로 구현하고, 웹이 아닌 다른 디바이스까지 포함하기 위한 광범위한 스펙이 됩니다.

그렇다면 CSS로 레이아웃을 잡는 것은 갑자기 왜 나온 얘기인가?

CSS와 XHTML 스펙에는 레이아웃에 대한 이야기는 없습니다. 그렇다면 테이블 레이아웃이 표준이 아니라는 이야기는 어디서 나온 이야기일까요?

W3C의 문서 중 “Web Content Accessibility Guidelines 1.0“를 보면 그 답을 알 수 있습니다. 이 문서는 CSS나 XHTML의 권고(사실상 표준이라고 쓰입니다.)와는 틀린 가이드라인입니다. 이 문서에서 테이블 레이아웃에 대해서 다음과 같이 기술하고 있습니다.

W3C 인용:

Using markup improperly — not according to specification — hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it. Furthermore, using presentation markup rather than structural markup to convey structure (e.g., constructing what looks like a table of data with an HTML PRE element) makes it difficult to render a page intelligibly to other devices (refer to the description of difference between content, structure, and presentation).

즉, 테이블 레이아웃은 디자인의 쉽고 어려움과는 전혀 상관없이 프로그램에서 데이터를 알기가 힘들고, PC 이외의 다른 기기에서 렌더(HTML을 실제 이미지로 변환하는 것)의 어려움이 있다는 것입니다. 즉, 코드의 확장성을 염두에 둔 가이드라인이라는 것입니다. XHTML로 디자인을 하면 코드 변경없이 모바일에서도 서비스가 된다고 생각하면 쉽습니다. Google은 모바일용 웹사이트에서 XHTML을 지원하고 있습니다.

실전을 이야기 할 때

위의 글에서 CSS라는 것은 웹표준과는 그다지 상관없고, XHTML과 합쳐질 때 표준이 된다는 사실을 알았습니다. 이제 실전에 적응해 봅시다.

어떤 회사가 웹사이트를 CSS2.0+XHTML1.1 스펙에 맞게 디자인을 했다고 칩니다. 그 회사는 모바일용 웹사이트를 따로 제작하지 않고, 같은 문서에 CSS 파일의 변경만으로 모바일용 웹문서 디자인을 끝냈습니다. 또한, CSS만의 변경으로 시작장애인용 웹사이트를 글씨가 크고, 네비게이션도 크게 디자인했습니다.

위의 이야기는 실제로 일리가 있어 보입니다. 하지만, 실전에서 이렇게 사용되는 경우가 관리가 부담되는 개인 웹사이트 외에 있을까요?

우선 나누어 생각해 보면 모바일은 기본적으로 매우 작은 화면을 갖습니다. 따라서, 한 페이지에 나오는 정보의 양도 매우 적습니다. 웹사이트의 로직 부분도 당연히 틀려져야 합니다. 모바일의 한정적인 정보를 보여주기 위해 웹용으로 제작된 코드를 그대로 사용할 이유가 전혀 없는 것입니다. 즉, 모바일용 웹사이트는 다시 제작되어야 합니다.

시작장애인용 웹사이트도 마찬가지입니다. 시작장애인용 웹사이트를 CSS의 교체만으로 당연히 디자인이 가능합니다. 하지만, HTML 문서를 새로 만드는 것이 훨씬 빠를 것입니다.

위의 글에서 CSS+XHTML 문서를 이용해야 되는 이유는 콘텐츠의 재활용(확장성)에 있다는 것을 W3C문서에서 알 수 있었습니다. 그 말은 내가 만드는 페이지가 다른 디바이스에 나오거나 같은 디바이스라도 다른 디자인이 보여져야 할 때에만 의미가 있다는 말입니다.

XHTML이 디자인과 컨텐츠를 분리해준다?

이 분야의 가장 유명한 모델 중 하나는 MVC(모델,뷰,컨트롤러)패턴입니다. 여기서 디자인과 관계되어있는 뷰, 즉 프리젠테이션 영역에 속합니다. 프리젠테이션은 단순히 어떻게 디자인되느냐가 아니라 사용자에게 어떻게 보여주느냐 하는 것으로 그 둘은 많은 차이를 가지고 있습니다.

비지니스 로직에서 원화로 1000원을 프리젠테이션으로 넘겨주었다고 합시다. 프리젠테이션 영역에서는 1000원을 1,000원으로 표시할 수도 있고, KRW 1000이라고 표시할 수도 있습니다. 즉, 프로젠테이션에는 “조건이 있는 코드”가 들어가야 한다는 의미입니다.

이 이야기는 비지니스 로직과 프리젠테이션 로직의 분리 문제는 개발 정책상의 문제이고, 실제 이런 것들이 필요할 때, CSS의 교체로 리뉴얼을 하는 것 보다는 템플릿을 이용한 리뉴얼이 훨씬 유연한 환경을 제공합니다.

그럼 여기서 주장하는 것은 도대체 무엇?

처음 글을 작성할 때의 의도는 무엇이 올바른 것이냐 하는데 부터 시작했습니다. 그리고, 이런 부분은 정책의 문제이고, 웹표준이라는 것의 실체가 무엇인지 알아야 되는 당위성을 포함합니다. 쉽게 말하면 웹표준을 왜 따라야 하느냐 하는것이죠.

현실적으로 XHTML이 추구하는 방향에 가장 확실하게 부합하는 것은 디바이스 별 디자인이 별도로 들어가는 것입니다. 모바일용 웹페이지 따로, PC용 따로, PDA용 따로… 템플릿을 이용하면 이런 것은 매우 수월하게 만들 수 있습니다. 반면 CSS를 이용해서 제작한다고 하면 대부분 사람이 인정하듯이 쉽지 않은 일이 되어 버립니다. 그리고, 테이블 레이아웃에 중간중간 CSS를 적용하면 가장 빠르고 대부분의 브라우져에서 보여지는 웹사이트 제작이 가능합니다.

부연

일모리님이 지적하신 오페라로 제대로 보여지는 웹사이트 제작이 실질적으로 불가능하다는 이야기는 예전 저의 경험에서 나온 것입니다. 테이블을 쓸 때 전 보통 IE, 파이어폭스, 그리고 오페라에서 테스트를 하곤 했는데, CSS만으로 제작할 때 오페라에서 디자인을 같게 만드는 것이 불가능하게 생각되었기 때문입니다. 이 것은 개인적인 경험입니다.

nmind님이 지적하신 디자인과 컨텐츠의 분리는 그 자체가 중요한 것은 아니라고 생각됩니다. 여러가지 개발 모델들이 있기 때문에 개발팀의 선택에 따라 틀려질 것 같네요. 일반화 시키는 것은 약간 무리가 있어 보이네요.

다만, 테이블 레이아웃을 기술이 없어서 그렇다는 식은 좀 곤란하지 않나 싶습니다. 쉬운 길이 있으면 쉬운 길로 가는 것이 좋아 보이거든요.