Table & Rounded box

어느 덧 PLS 의 결론을 내려야 될 때가 된 것 같습니다. 이 즈음에서 결론을 내리려고 하는 이유는 회수가 길어짐에 따라 보는 사람의 집중력 저하를 가져 온다는 것과 PLS Part I 에서 제시한 주제인 '웹 표준에 맞춰 page layout을 하는데 있어서 table과 div 의 비교' 라는 논지에서 벗어나지 않으려다보니 제 자신에게 생기는 '소재의 제한' 이라는 측면에서 입니다. 사실 이런 제한 때문에 재미있고 다양한 글을 써보고 싶은데도 주제에서 벗어나거나 별 관계가 없어 보이는 부분들을 Ctrl + X 로 찍어 내기를 수도 없이 하는 바람에 현재 10회가 된 PLS 의 전체의 분량 보다 오히려 찍어낸 부분의 분량이 더 많을 정도입니다...^^

따라서 이 시점에서 제 나름대로 주제에 대한 명쾌한 결론을 내리고, 그 동안 찍어내기한 부분은 이런 제한적인 주제에서 벗어나서 따로, 새로이 정리하는 편이 제 자신의 부담을 덜 수 있는 좋은 방법이리라 생각 합니다.

원래 PLS 같이 하나의 주제를 가지고 여러 회에 걸쳐 내용을 써 나가는 것은 마치 작곡가가 교향곡을 작곡하는 것 처럼, 교향곡이 악장은 나뉘어져 있어도 전체가 하나의 주제에서 벗어나는 법이 없듯이 주제에 대한 일관성을 유지해야 되는데, 저의 어줍짢은 실력으로 그런 걸 흉내 내다 보니 무리가 따르는 것은 당연하고, 그로 인해서 저의 부담도 만만치 않았습니다. 그래서 이제는 그런 부담을 덜고 일종의 소품과 같은 가볍고 재미난 주제를 다루어 보고 싶은 마음 입니다.

즉, PLS X 에서 내리게 될 '작은 결론'은 PLS의 끝이라기 보다는 web page design 에 대해 제가 다루려고하는 부분의 새로운 시작 이라고 할 수 있습니다. 그러면 지난 페이지에서 다 마치지 못한 rounded box에 대한 정리를 하면서 PLS의 종지부를 찍어 보도록 하겠습니다.

border 가 있는 rounded box

rounded border

지난 PLS 9편에서 div를 이용하여 다양한 방법으로 rounded box를 만들어 보았습니다. 최종적으로 만들어 본 rounded box 는 가로 세로 size가 모두 가변이면서 box 내부의 배경색이 가변인 경우였죠. 이번 페이지에서는 여기에 약간은 변화(variation)을 주어서 지난 번 rounded box(case '4c')에 테두리(border)가 있는 경우에 대해 알아 보도록 하겠습니다. 물론 이번 경우에도 아래와 같이 4 개의 모서리에 들어갈 border가 있는 둥근 모서리 image 를 만들어야 되겠습니다.

	1
2	border, no border	3
	4

그런데 지난 번 처럼 같은 크기의 div 4개를 같은 위치에 겹쳐서 처리 할 경우 오른쪽의 그림� 같이 div에 border를 주면 border가 들어가면 안될 모서리 부분까지도 border가 생기게 됩니다. 따라서 테두리가 있는 rounded box의 경우 모서리 부분의 둥근 테두리를 제외한 border가 필요한 4 개의 직선 구간(1, 2, 3, 4)을 따로 분리해서 생각해야 된다는 것 입니다. 그러므로 이 경우(지난 페이지 case '4c') 오른쪽과 같이 rounded box를 총 9개 구간으로 분리하도록 하겠습니다. 물론 반드시 9 개로 분리해야 되는 것은 아니며, 약간 다른 방법도 있지만 그건 여기서 제외하겠습니다.

Table & div

그렇다면 테두리가 있는 rounded box를 만드는데 지난 번과 같이 div를 쓸 경우와 table을 쓸 경우를 비교해 보도록 하겠습니다. 우선 div를 사용한다면 아래와 같은 방법을 생각할 수 있습니다.

그런데 code 중에 height:300px; button을 누르고 code를 실행하면 height가 변경된 가운데 div만 height가 늘어나고 좌우 div의 height는 따라서 변하지 않는다는 것을 알 수 있습니다. 이렇게 위와 같이 구성된 div의 경우 내용물이 늘어나서 width 나 height 가 변경되는 경우 같이 늘어나야 되는 부분(width가 늘어날 경우 1, 4. height가 늘어날 경우 2, 3.)도 같이 변경해 줘야 된다는 단점이 있습니다. 하지만 아래와 같이 table을 사용하면 아래의 1, 2, 3, 4의 width나 height가 별도의 수정이 없어도 같이 늘어난다는 것을 알 수 있습니다. *** 아래의 내용은 편집이 가능하므로 메모장에서 처럼 cursor를 넣고 아래의 내용을 삭제 또는 추가하면 전체의 table 크기가 변동 됩니다. IE only...

이와 같이 table은 div가 가지고 있지 않은 기능을 가지고 있습니다. 즉,

은 분명 table 만이 가지는 장점이라 할 수 있습니다. 위의 table과 같이 table 중 1, 2, 3, 4 부분이 같이 변동되는 이유는, 바로 table 이 auto layout 이라는 기본값을 가지고 있기 때문 입니다. Table의 auto layout 에 대해서는 이 사이트의 CSS > table > table-layout 의 property table을 보시면 table의 기본 값이 auto 로 되어 있는 것을 알 수 있는데, table-layout:fixed 로 지정하지 않은 모든 table은 바로 이 auto layout 을 사용하고 있는 것 입니다. 이 auto layout table이라는 용어가 생소하게 들릴지 모르지만 CSS의 fixed table layout 을 사용하지 않는 모든 table과 HTML의 col, colgroup, tbody 등을 사용하지 않은 모든 table이 auto layout table 입니다.

Auto layout table & fixed layout table

흔히 table을 사용하면 div에 비해 화면에 rendering 되는 속도가 느리다고 하는데 그건 사실 입니다. 그럴 수 밖에 없는 이유가 아래와 같이 table 전체를 구성하는 element 들의 구성을 보면 알 수 있습니다. 아래와 같이 table, tr, td 의 3개 element는 전체가 유기적으로 table > tr > td 의 순서로 쓰여 졌을 때 비로소 하나의 block 을 이루게 되는 것 입니다. 즉, 각자가 따로 놀 수는 없다는 말이죠. 하지만 그 덕분에 위의 테두리가 있는 rounded box를 table로 처리할 때와 같은 이점을 가질 수 있는 것 입니다.

이렇게 위와 같이 <table> 로 시작해서 </table> 로 끝나는 속에 tr, td 가 들어 있습니다. 또한 <tr> 과 </tr> 가 끝나야 비로소 tr 속에 든 td가 처리 됩니다. 모든 markup 언어가 마찬가지지만 tag의 시작을 알리는 start tag 과 그 tag의 끝을 알리는 end tag 이 있어야 비로소 하나의 markup이 끝나고 그 markup에 부여된 의미나 기능이 완료가 되는데 table의 경우 table 속의 tr, td 가 모두 처리되고 나서야 </table>로 table tag이 완료 되므로 실제적으로 화면에 table이 rendering 되는 속도는 아래의 div와 같이

처럼 시작과 끝이 독립적으로 반복되는 것과 비교했을 때 당연히 느릴 수 밖에 없습니다. 그러나 이 독립적이라는 것 때문에 table이 가지고 있는 장점인 전체가 유기적으로 변경에 대한 유연성을 갖는 반면에 div는 각각이 따로 논다는 단점이 생기는 것 입니다. 그건 그렇고 table이 div에 비해 느리면, 과연 그게 얼마나 느린 걸까요? 시험을 해 보기 위해서 fixed layout table과 auto layout table를 비교한 MSDN Library의 test page를 클릭하고 비교해 봅시다. 단, 2 번 이상 test page를 load 시킬 경우에는 브라우저 메뉴의 도구 / 인터넷 옵션 / 임시 인터넷 파일 / 삭제를 하고 load 시켜야 cache가 삭제되어 그 차이를 알 수 있습니다. 이 test page에서 양 table의 속도 차이는 test 하는 사람의 컴퓨터 환경(기종, 인터넷 회선 속도 등)에 따라 차이가 있을 수 있습니다만 왼쪽이 오른쪽에 비해 약간 빠르다는 것을 알 수 있습니다. 왼쪽이 빠른 이유는 cell의 크기를 width:20%, height:16px 로 지정하고 table tag에 table-layout:fixed로 cell size를 고정(fixed) 시켰기 때문 입니다. 이와 같이 table-layout fixed 로 고정크기를 지정하면 </table> 로 table tag이 완료 되지 않아도 parsing 된 cell 부터 우선 적으로 처리하게 됩니다. 따라서 각 cell의 rendering이 table, tr 등의 상위 tag에 종속적이지 않고 독립적으로 rendering 되므로서 다른 block level element와 마찬가지 속도로 rendering 되기 때문에 오른쪽의 table-layout:fixed 로 지정하지 않은 table 보다 빠를 수 밖에 없습니다.

Page layout & table

그럼 위에서 실험한 fixed layout table의 cell 개수 만큼을 div로 만들면 그야말로 순식간에 화면에 나타 날까요? 사실 위의 table test page의 경우 cell 개수가 4000개 정도로 엄청 긴 table 입니다. 그렇다면 같은 개수의 div로 test하면 어떤 결과가 나올까요. 함 해 봅시다. Div로 4000 개의 box를 만든 div test page 와 비교해 보시죠. 눈으로 느낄 만큼 순식간에 뜨던가요? 결코 그렇지 않습니다. 적어도 4000개 정도의 div block box를 처리하려면 상당히 높은 기종에 좋은 환경을 쓰는 컼퓨터라도 약간의 처리 시간이 들게 마련 입니다. 따라서 4000 개의 cell과 4000개의 div 의 경우 어느쪽이 더 빠르다고 할 수도 없고 구태여 비교할 필요도 없습니다.

왜냐하면 table을 page layout에 사용 할 경우 4000 개나 되는 cell 이 필요 하겠습니까? 고작해야 10 개 내외 일 것 입니다. 따라서 div가 속도면에서 더 효율적이라고 하는 주장은 설득력이 없어 보입니다. 오히려 속도 보다도 통신 회선 사용시 전송량에 따라 대금을 지불하는 사업자의 경우 code의 양이 table을 사용하는 편이 많이 드니까 div로 줄이는게 경제적이라고 주장하는 편이 훨씬 설득력이 있어 보입니다.

2004년도 통계에 의하면 미국의 초고속 인터넷 보급율이 OECD 국가 중 12 위로 나와 있습니다. 그렇다면 OECD 국가 중에 초고속 인터넷 보급율 1위 국가는 어디 일까요? 바로 대한민국, 우리나라 입니다. 그럼에도 불구하고 다운로드 속도가 더 빠르지 못한 것에 대해 불만을 터뜨리고 있지는 않습니까? ^^... 미국의 경우는 땅이 워낙 넓다보니 우리나라처럼 초고속 인터넷 사업자들이 구석 구석 초고속 인터넷을 보급 하기가 쉽지 않은 모양 입니다. 수지타산이 맞지 않는다는거죠. 생각해 보시죠, 수십 킬로미터의 거리에 사용자가 낼 몇 년치 경비를 투자해서 통신선을 깔고 초고속 인터넷이 되도록 해줬는데, 한 달 정도 쓰고 '이제 그만 쓸거니까 걷어 가슈!' 라고 하면 업자 입장에서는 정말 순간적으로 살의(殺義)내지 최소한 타의(打義:때리고 싶은 마음)를 느끼지 않을까요. ^^ (이런 말 할 때는 웃는게 아닌가?) 그런데도 OECD 국가 중 초고속 인터넷 보급율 1위인 우리가 겨우 몇 개의 cell 이나 div 의 rendering 속도를 따져야 되는지... 혹시 우리나라 사이트에 접속하는 미국 사용자들을 위해서?...

헉! 그렇다면 table을 page layout에 그냥 계속 쓰라는...

말은 결코 아닙니다...^^ 제가 볼 때 page layout에서 table의 사용을 자제하라는 이유 중에 가장 중요한 것은 바로 장애인(disabled)들의 웹 페이지의 접근성(accessibility)에 대한 제고(提高) 때문인 것 입니다. 무슨 말인가 하면 하나의 예로 아래와 같이 headers attribute를 사용하여 table을 만들면

이렇게 만들어진 table을 음성 출력 장치(aural media)에서 합성해서 출력할 때는

의 순서로 출력이 된다고 합니다. 이와 같이 headers, axis, axes, scope, abbr 등을 사용하여 table의 내용을 aural media 등의 특수 장치로 출력하는 방식의 markup을 table의 구조적(structural) markup 이라고 합니다. 이런 구조적 markup을 사용할 경우 table을 구성하는 tag 들의 순서대로 출력되지 않고 위의 결과와 같이 해당 cell 들의 data가 headers로 지정한 제목과 함께 출력 된다면 시각 장애인이 귀로 들을 때 매우 편리할 것은 뻔한 사실이고, 반대로 위와 같은 구조적 markup을 하지 않았을 경우 길이가 긴 table을 aural media로 출력한다면 뒤에 가서는 각 cell의 내용이 어디에 해당되는지 인식하기 힘들 것 입니다. 사실 저의 경우도 이런 부분에 전혀 신경을 쓰지 못 했습니다. 처음 사이트 작업을 할 때 이런 사실에 대한 인식 별로 없었던 지라... 솔직히 말하면 처음에는 대충 알았다가 이 번에 PLS 를 연재하면서 자세히 알게 된 셈이죠...

W3C의 웹 접근성에 대한 지침에도 이런 이유로 table을 page layout에 사용하지 않는게 좋다고 하고 있습니다. 그렇지만 어쩔 수 없이 table을 page layout에 사용 할 경우 위의 예와 같은 구조적인 markup은 하지 말고 사용하라고 하는군요. (WAI Check point 5.4 참고) 그런 면에서 제가 아는 한 대 부분의 웹 사이트들은 아무런 걱정도 없을 것 같습니다. 이런 구조적 markup을 사용한 table은 아직 못 본 것 같으니까요.

그럼 layout에서 table 만 빼면 웹 접근성이 높아 질까?

그런데 말입니다... 장애인들의 웹 접근성에 대한 고려가 비단 table에만 국한된 것 일까요. 즉, table을 page layout에 쓰지 않는 걸로 웹 접근성이라는 문제가 해결되느냐는 말이죠. 제가 이번 기회에 경험해 보니, 웹 접근성이라는게 여간 어려운 문제가 아닙니다. 심지어 웹표준이나 장애인의 웹 접근성에 대한 홍보 사이트의 경우도 '이 사이트는 1024 X 768 에 최적화 되어 있습니다.' 라는 말을 대문짝에 달지 않아서 그렇지 800 X 600 으로 보면 가로 scroll bar가 생기는 곳도 있습니다. 이런 말을 하면 '에이~ 설마 아직도 800 X 600 쓰는 사람이 있나?' 라고 생각하시는 분은 혹시 없습니까. 800 X 600 은 커녕 800 X 600을 지원하지 못하는 모니터를 쓰기에 아직도 640 X 480을 쓰는 사람도 많습니다. Windows 98이나 2000을 설치하면 처음에 hardware driver 를 못 찾아서 뜨는 큼지막한 글씨의 화면이 바로 640 X 480 입니다. 누가 좋은 모니터 쓰기 싫어서 안 쓰겠습니까, 금전적으로 사정이 안되니 못 쓰는거죠. 어디 이런 문제 뿐 이겠습니까 WAI 지침에 맞추려면 너무 제약이 많기 때문에 초보자가 아닌 상당 수준 이상의 실력자도 이 기준에 맞추기는 실제적으로 어렵습니다.

이와 같이 웹 접근성을 실현하는데 고려해야 될 사항이 한 두가지가 아닌 만큼 현실적으로 가까운 시일내에 이 문제가 실현되기는 어려울 것 입니다. 어쩌면 완전한 목표달성은 영원히 없을 수도 있겠죠. 하지만 그렇다고 해서 포기할 문제는 아니라고 생각합니다. 왜냐하면 이런 운동을 지속적으로 해 나가므로해서 웹 접근성이라는 목표가 완벽하게 달성되지는 못 할지라도 점차 나아질 수 있는 것은 사실이기 때문입니다. 그렇다면 이제 부터 우리가 어떻게 이 문제에 접근해야 될 것인가에 대한 제 생각을 말씀드리겠습니다.

웹 접근성과 웹 표준에 대한 인식의 전환

우리 자신이 어떤 사물의 가치에 대한 인식을 바꾸려고해도 인식을 바꾸어야 될 만한 어떤 이유나 계기가 있어야 그게 쉽게 이루어 질 수 있습니다. 그런데 하물며 다른 사람의 인식을 바꾸는 일이야 말해 뭐 하겠습니까. 그리고 WAI 라는 것은 웹 언어를 하는 모든 사람들이 반드시 지켜야할 강제 규정이 아닌 지키면 좋은, 그야말로 '권장 사항' 입니다. 따라서 권장 사항에 대한 남의 생각을 바꾸려면 왜 그래야 되는지에 대해 납득할만한 충분한 설명도 중요하겠지만 그 보다 더 중요한 것이 있습니다. 그건 바로 어떻게 해야 웹 표준에 맞게 문서를 만들 수 있는가에 대한 구제적인 방법의 제시 입니다. 이 사이트의 첫 번째 페이지인 HTML의 사이트 소개에서도 아무리 꿈이 크고 뜻이 좋다고 해도 그걸 뒷바침해줄 기술이 없으면 요원하고 허망한 이야기라고 한 것 처럼, 웹 표준에 대한 인식이 바뀐다고해도 그걸 구체적으로 실현시킬 수 있는 기술이 없다면 한낱 이상에 불과한 것 입니다.

또 한가지는 웹 접근성에 대한 홍보의 대상이 누구냐인데, 제 생각으로는 먼 장래를 내다 보았을 때 초보자들을 주 대상으로 삼아야 된다고 봅니다. 그 이유는 기존의 웹 페이지 운영자들에게 이미 만들어진 사이트를 고치라고 하기 보다는 웹 페이지를 새로 만들 계획을 가진 초보자들에게 올바른 방법을 알려 주는 것이 훨씬 효율적일 것은 명확하기 때문이죠. 왜냐하면 그 초보자가 언젠가는 기존 웹 페이지의 관리자가 될 가능성이 많을 테니까요. 기존의 관리자가 설마 늙어 죽을 때 까지 웹 페이지 관리하고 있겠습니까. 물론 기존 사용자에 대한 홍보도 같이 이루어져야 될 것 이구요. 좀 길게 보자는 말이죠.

내가 안쓰는 것과 필요없는 것

어떤 프로그램이나 언어의 경우 그걸 사용하다 보면 많이 쓰는 spec과 잘 쓰이지 않는 spec이 생기게 됩니다. 가끔 CAD 같은 프로그램을 교육하러 가서 웬만해서는 잘 안 쓰이지만 알면 엄청 편리한 명령어들을 가르치기 전에 '이게 무엇이며 어떻게 쓰는지 아느냐?' 고 질문을 하면 반응은 크게 두 가지 입니다. 대 부분은 '안 써봐서 잘 모르겠다.' 라고 대답하지만 어떤 사람은 '에이~ 그거? 필요 없는 거예요. 그거 안써도 도면만 잘 그려지는데요 뭐.' 라고 대답하는 사람도 있습니다. 그런데 과연 program 만드는 회사에서 필요도 없는 명령을 만들었을까요? 결코 그런 일은 없습니다. 최소한 동종 프로그램들과의 경쟁에서 살아남은 프로그램이라면 말이죠.

HTML 같은 웹 언어도 마찬가집니다. 진짜 필요가 없는 element들은 실제로 도태(depredated) 됩니다. 하지만 table의 경우는 CSS level 3에도 엄연히 자리 잡고 있습니다. 요즘 유행하는 Blog와 같이 h1, p, div, a 정도가 대 부분인 일기 형식의 layout 에서 table이 무슨 필요가 있겠습니까? 자기가 안 쓴다고 다른 사람들 한테도 'table은 필요없는 것이고, 쓰면 웹 표준에 위배 되니까 쓰지 말라' 고 한다면 그건 도대체 무슨 억지인지... Table과 웹 표준이 도대체 무슨 상관이길래... Yahoo나 Daum 등이 layout에서 table을 제외 시켰다고 하지만 대문 페이지만 그렇고, 한 발짝만 들여 놓으면 table이 드글 드글 하다는 사실...

또 어떤 경우에는 page layout을 div로 짜고, voice-family 같은 CSS property를 끼워 넣는 것으로 웹 표준과 접근성을 완벽하게 해결한 것으로 착각하는 수도 있는 것 같습니다. 그렇다면 아무 음식에나 피자 치즈를 얹어서 오븐이나 그릴에서 구워내고 fusion food 라고 주장하면 그게 진짜 fusion food가 되는 건가요. 그건 Fusion 이 아니라 confusion 이겠죠.

위에서 말한 것 처럼 장애인의 웹 접근성이라는 측면에서 page layout에 table을 쓰지 말라고 한다면 충분히 납득 할 수 있습니다. 하지만 layout 이 아닌 data를 표현하기 위한 table은 그 걸 필요로 하는 사람에게는 없어서는 안될 element 입니다. 그러고 보니 아래아 한글 DOS version 이 처음 나왔을 때 table 기능이 없어서 선그리기 문자를 써서 힘들게 도표 작업하던 생각이 나는군요. 얼마 후에 table 기능이 지원되기는 했습니다만... 그런데 웹 페이지에서 table이 들어갈 자리에 div 를 쓰자고 한다면 마치 처음 나온 아래아 한글에 table 기능이 없어 불편하다고 해서 기껏 그걸 만들어 줬더니 '나는 그냥 선 그리기 문자 쓸래.' 라고 하는 것과 무엇이 다른지 모르겠습니다. W3C 에서도 처음 HTML을 접하는 사람들을 위한 안내서 (Dave Reggett's introduction to HTML)에서 table 사용의 합리성을 분명히 설명하고 어떻게 쓰는게 좋다라고 까지 말하고 있습니다.

틀린 것과 내 마음에 안 드는 것

사람이 어떤 사실에 대해 문제 제기를 하거나 비판하는 것은 쉬운 일 입니다. 하지만 적어도 어떤 사실에 대해 문제 제기를 하려면 어떻게 하면 그 문제를 개선하거나 해결 할 수 있는지에 대한 '구제적 대안' 을 뚜렷히 제시할 능력이 되어야만 그럴 자격이 있다고 생각합니다. 그러므로 구체적 대안이 없거나, 있어도 구체적인 대안에 대해 시간을 들여 지적할 의지가 없으면 자기 마음 속으로만 생각하는게 지극히 옳습니다. 왜냐하면 대안도 없는 문제 제기는 상대방에게 '대안도 없이 저런 말을 하는 걸 보니 틀린 것을 말하는게 아니라 자기가 그게 마음에 안 들어서 그러는 거 아냐?' 라는 오해를 살 수도 있을 테니까요.

만약에 table 사용이 그렇게 비합리적이어서 정말로 사용해서는 안된다면 table을 대체할 대안은 무엇 일까요. 저는 아직 그런 대안을 발견하지 못해서 table로 표현해야 될 것에는 아무런 꺼리낌도 없이 table을 사용하고 있습니다. 물론 앞에서 말한 '구조적 markup' 은 하지 못했습니다만... 여기 browser 별 CSS property 지원 상황을 표로 비교한 사이트를 보시죠. 이런 걸 서술식으로 표현하라면 못 할 거야 없겠지만 표로 표현한 것과 비교하면 어떤 것이 눈에 잘 들어 올지는 너무 뻔한 사실 입니다. 만약 그래도 이런 표 대신에 서술식 표현이 좋다고 한다면 그 사람은 시각적 디자인(Visual Communication Design)에 무지한 사람이라고 할 수 밖에 없습니다. 또한 table이 장애인의 웹 접근성을 떨어 뜨린다면 table을 구조적으로 markup 하는 방법을 가르쳐 줘야지 무턱대고 쓰지 말라고 해서는 안 될 일입니다. 방법이 분명히 있으니까요.

FireFox에 대한 생각

이 번에 PLS 를 다루면서 어쩔 수 없이 화면에는 항상 Firefox 창이 떠 있었습니다. 처음에는 IE 와 FF 에서 서로 다르게 표현되는게 없는지를 체크할 목적으로 쓰다가 나중에는 내가 사용하는 tag 들이 혹시 표준에 안 맞는게 없는지를 확인하는 수단으로 용도 변경이 되었습니다. 저도 그 동안 IE의 비표준에 너무 익숙해져 있었던 관계로... 이번 경험을 통해 'FireFox는 한 마디로 CSS Level 2를 거의 다 지원하는 몸무게가 가벼우면서도 있을 건 다 있는 브라우저'라는 것을 알게 되었습니다. 아울러 IE 도 version 7 에서는 최소한 CSS 2 라도 FF 만큼 지원해 주면 바랄게 없겠다는 생각도 들었구요. 그건 IE가 좋아서가 아니라 FF 에서는 지원되는데 IE 에서 지원하지 않아서 사용할 수 없는 CSS property 들이 너무 많기 때문 입니다. 그야말로 PLS 어디에선가 제가 말했던 '흡연을 위해서 지나친 건강을 삼가' 할 수 밖에 없는 것과 다를 바 없습니다. 현재는 IE 사용자가 절대적으로 많은게 사실이기 때문에... 따라서 만약 IE 7 에서 CSS 를 FF 만큼 지원해 준다면 제 개인적으로는 무거운 IE를 버리고 가벼운 FF 를 사용하고 싶습니다. 그리고 다른 건 몰라도 새로 나올 IE 7 에서 특히 이 것 만큼은 꼭 지원해줬으면 하는 CSS property가 뭐냐고 누가 묻는다면 저는 display property라고 대답하겠습니다. 물론 모든 형식의 selector와 float이나 width 처리에 대한 오류는 당연히 고쳐졌으면 하는 거구요. 그런데 왜 하필 display property냐고 궁금해 하신다면 아래의 '꿈의 layout'을 보시면 됩니다.

A TIVLE, The Dream Layout

TIVLE... 처음 들어 보시죠...^^ 제가 처음 만든 element이니 당연히 그럴 수 밖에요. 혹시 PLS 4 부 Layout with positioning 에서의 'IML' 처럼 허무맹랑한 장난 치는 것 아니냐구요? 절대 아닙니다. TIVLE 은 TabLE과 dIV의 합성어 입니다. 아니 당신한테 무슨 재주가 있어서 table과 div를 합쳐서 새로운 element를 만들 수 있냐고 하시겠죠? 저한테 그럴 재주는 없습니다만 table을 div 처럼, div를 table 처럼 쓸 수 있는 방법은 있습니다. 우선 table과 div의 장점을 모두 살린 아래의 layout을 보시죠.

아래의 leftCol, mainCol, rightCol 중에 아무 곳 이나 cursor를 넣고 메모장처럼 내용을 추가하거나, 귀찮으면 enter를 쳐서 줄을 여러 번 바꿔 보시죠. Height가 늘어 납니다. IE only...

가운데 column 세 곳 중에 어느 부분이든지 내용이 추가되어서 column의 길이가 늘어나면 다른 두 곳도 동시에 그 만큼의 길이가 증가하게 됩니다. 따라서 이 Layout을 사용하면 column 들 사이에 border나 background 등을 넣기 위해 mainCol 이나 다른 column 부분의 height를 의도적으로 늘여야 될 필요가 없습니다. 물론 위의 layout 은 table로 표현한 것 이고, 아래의 layout code는 제가 말한 dream layout을 사용 했습니다.

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

<html>
<head>
<title>Untitled</title>
<style type="text/css">
<!-- 
body{margin:0;background-color:#efefef}
#layout{width:500px;margin:0 auto;}
#header{height:50px;background-color:#999}

#middle_wrap{background-color:#69c;display:table-cell;}
#leftCol, #mainCol, #rightCol{padding:10px;}
#leftCol{width:130px;background-color:#ccc;}
#mainCol{width:180px;background-color:transparent;}
#rightCol{width:130px;background-color:#ccc;}

#footer{height:50px;background-color:#666;}

/*  */
.column{display:table-cell;min-height:300px;}
.clr{clear:left;}
-->
</style>
</head>
<body>
<div id="layout">
    <div id="header">
    header
    </div>
    <div id="middle_wrap" class="column">  
        <div id="leftCol" class="column">
        leftCol
        </div>
        <div id="mainCol" class="column">
        mainCol
        <br /><br /><br /><br /><br /><br /><br />
        <br /><br /><br /><br /><br /><br /><br />
        </div>
        <div id="rightCol" class="column">
        rightCol
        </div>
    </div>
    <div id="footer" class="clr">
    footer
    </div>
</div>
</body>
</html>

큰 기대를 하고 실행을 해 보셨다면 아마 실망이 크실 겁니다. 왜냐하면 가운데 column 3개가 줄바꿈이 되었을 테니까요. 하지만 누구에게나 똑같이 줄바꿈이 생긴 모습으로 나타나지는 않습니다. 만약에 위의 code를 FF에서 실행시킨다면 가운데 column 부분의 높이가 300px 로 보일 것이고, IE로 본다면 깡뚱하게 짧은 가운데 colulmn 들을 볼 것 입니다. 따라서 IE 사용자의 경우 위의 layout을 사용하려면 위의 float:left; button을 눌러서 column class 에 float:left; 를 추가하고 사용해야 되겠습니다.

그렇다면 달라진게 무엇인가.

달라진 부분을 설명하기 위해서 아래의 code를 실행시켜 봅시다. 그리고 생각해 봅시다. 아래의 code 중에 2개의 div를 감싸는 id="column_wrap" 의 background-color 인 'royalblue' 가 좌측하단에 나타나는게 맞을까요 틀릴까요. 결과적으로 background-color:royalblue; 는 IE에서는 보이고, FF에서는 보이지 않습니다. 그렇다면 어떤게 표준에 맞는 걸까요? FF에서 처럼 id="column_wrap" 의 background-color인 'royalblue' 가 보이지 않는게 맞습니다. 왜냐하면 float(사전적 의미로 '부유하다', '떠 있다.')으로 positioning 된 block box는 자신의 height가 늘어나도 상위 tag의 height에 영향을 주지 않습니다. 떠 있기 때문에 상위 block box와 따로 놀고 있으므로...

따라서 이 layout의 장점은 column class에 display:table-cell; 추가 하므로써 IE와 FF 에서 공히 'column_wrap'의 배경색이 보인다는 것 입니다. 또한 FF 에서 사용할 경우에는 float:left; 는 불필요합니다. 하지만 IE에서도 보여야 되므로 float:left;를 써 줘야 되겠죠. 그리고 누구나 바라는 사항이겠지만 장래에 IE 가 display:table-cell; 등의 CSS 들을 지원한다면 IE 또한 float:left; 를 사용하지 않아도 되겠습니다.

PLS를 맺으면서...

처음에 예상랬던 것 보다 내용이 많이 길어졌습니다. 이 문서 앞 부분에서도 말했지만 쓰다 보니 처음에 예상하지 못했던 부분까지 다루게 되었고, 주제와 크게 관련없어 보여서 제쳐 놓은 부분을 제외하고도 10 회가 되었군요. 마음은 홀가분 합니다만, 지난 글 들을 다시 보니 역시 부족한 부분이 눈에 띄고, PLS 첫 부분의 경우는 제가 써 놓고도 뭔 말인지 몰라서 다시 읽게되는 부분도 있군요^^... 말은 초보자를 대상으로 썼다고 하지만 과연 초보자가 PLS 를 보고 약간이라도 도움을 받았을지 걱정 스럽습니다.

또한 이번 기회에 제 스스로 얻은 소득도 매우 크다고 할 수 있습니다. 그 중에서도 특히 표준이라는 부분에 대한 제 자신의 인식이 달라지므로해서 웹 표준에 매우 익숙해 졌고, 그 동안 몰랐던 많은 부분을 알게 되었다는게 가장 큰 소득이라고 할 수 있습니다. 말했던 것 처럼 빠른 장래에 모든 사람들이 웹 표준에 대한 인식을 바꿀 수 있다면 좋겠지만 현실적으로 어느 정도의 시간이 필요한 것 같습니다. 하지만 저의 경우 처럼 웹 표준에 대한 인식을 바꾸는 사람들이 점점 늘어날 것은 분명하다고 믿습니다. 그리고 보니 이 사이트의 웹 표준화도 더 이상 미룰 수 없겠습니다. 하지만 언젠가 말 한 것 처럼 어디까지나 이사이트는 FF에 맞추는게 아니라 웹 표준에 맞출 것 입니다.

그러면 여기서 PLS를 종결하고, 이 사이트의 웹 표준화를 위한 정비를 마친 후, Ctrl + X 로 찍어낸 부분을 가지고 다시 만나뵙겠습니다. 그 동안 되지 않은 글들을 읽어 주시느라 수고하셨습니다. 곧 돌아오겠습니다...

cadvance.org 관리자

Table & Rounded box | Page Layout Series Part X

작은 결론