NARADESIGN

웹표준, 웹접근성, 유니버설디자인, HTML, CSS, UI, UX, UD


웹 표준 코딩의 장점. Table for Layout과 CSS Layout의 비교 실험.

본문 건너 뛰기

약 1년 전 네이버 블로그를 사용하면서 동일한 실험을 했던 적이 있습니다. 그 당시에는 Table Layout과 DIV Layout을 비교한다고 말했었지만 사실 Table Layout 이라는 말과 DIV Layout 이라는 말은 모두 잘못된 표현입니다. Table Layout 이라는 용어는 Table이 격자형의 2차원 데이터를 마크업 하는 용도를 지니고 있다는 점에서 Layout 이라는 표현과 함께 사용한 것이 잘못된 표현이며, DIV Layout 이라는 용어는 DIV가 의미를 그룹짓는 용도를 지니고 있다는 점에서 역시 Layout과 결합한 것은 잘못된 표현 입니다. 결국 Layout 이라는 것은 화면배치를 위한 표현에 해당하기 때문에 어떤 (X)HTML 요소와도 조합하여 사용하는 것은 잘못된 표현이라고 할 수 있습니다. Table Layout 이라는 말은 사실 ‘Table for Layout’ 즉, ‘레이아웃을 위하여 사용된 테이블’ 정도로 밖에 표현할 수 없습니다. 두 가지 표현이 별반 차이가 없는 것처럼 느껴지는 분들도 계실테지만 사실 엄청난 차이가 존재합니다. 전자는 Table이 Layout을 위하여 사용되고 있고 또 그럴 수도 있다는 것을 전제 하지만 후자는 Table이 Layout 용도로 사용되는 것을 확실하게 경계하였기 때문에 사용되는 표현입니다. 어쨌거나 이미 네이버에서만 162분이나 스크랩을 하셨고 저는 1년이 지난 최근에서야 해당 포스트를 수정하였는데 1년동안 여러 분들께 잘못된 정보를 제공했다는 사실 때문에 약간의 죄책감을 가지게 되었습니다. 그것을 만회할 요량으로 다시 해당 코드를 손질하고 이곳에 올려놓습니다. 이제는 자수하여 광명찾고 싶습니다.

Table for Layout 예제보기 CSS Layout 예제보기
Table for Layout CSS Layout

웹 표준 방식의 CSS Layout은 콘텐트가 논리적으로 선형화 됩니다.

상기 두 개의 이미지는 동일한 Layout을 제공하고 있지만 코드는 각각 다릅니다. 이미 짐작하고 계셨겠지만 이번에는 CSS를 제거한 상태로 한번 보여드리겠습니다. CSS를 제거하게 되면 콘텐트가 선형화 되는 모습을 시각적으로 확인할 수 있고 선형화 하였을 때 콘텐트의 나열 순서에 무리가 없다면 그것은 어떤 장치에서 보더라도 논리적으로 바르게 이해할 수 있습니다. 왼쪽은 화면배치를 위하여 Table이 사용된 페이지이며 오른쪽이 CSS를 이용하여 Layout된 페이지 입니다. Opera Mini와 같은 휴대용 웹 브라우징 장치는 웹 페이지를 렌더링 할 때 Table을 모두 걷어내고 CSS조차 제거된 상태로 표시합니다. 따라서 아래 두 가지 경우의 페이지 가운데 어떤 페이지가 논리적으로 선형화 될 것인지는 굳이 보지 않더라도 쉽게 추측이 가능합니다. 사실 이것은 CSS Layout의 영향이라기 보다는 Markup을 잘 했기 때문에 볼 수 있는 결과 입니다. 하지만 거꾸로 생각하면 표현요소가 Markup으로부터 완전히 분리되어 있기 때문에 이렇게 논리적으로 Markup 하는것이 가능해 집니다. Layout에 Table을 사용하는 경우는 마크업이 표현요소를 포함하고 있기 때문에 콘텐트를 논리적으로 배치하려고 시도하면 표현문제와 충돌하게 되고 결국 논리보다는 표현을 위한 용도로 마크업을 사용하게 되어 논리적인 배치와는 거리가 멀어지게 됩니다.

CSS가 제거된 Table for Layout 예제보기 CSS가 제거된 Web Standard Layout 예제보기
Table for Layout Without CSS CSS Layout Without CSS

보통 Table을 선형화 하더라도 콘텐트의 순서가 완전히 뒤죽박죽으로 인식되지는 않습니다. 왜냐하면 Table을 걷어내는 경우 좌측 상단으로부터 우측 하단으로 콘텐트가 선형화 되는데 그러한 순서에 맞게 페이지의 콘텐트를 배치하는 경우도 있기 때문입니다. 그러나 그것은 운이 아주 좋은 경우이며 대부분의 경우는 논리적인 순서에 문제가 생기게 됩니다.

CSS Layout은 Table for Layout에 비하여 파일의 용량을 50% 이상 절감해 줍니다.

무엇인가 원하는 위치에 표시하기 위하여 Table을 Layout에 사용하는 경우는 <table><tr><td>내용</td></tr></table> 형식으로 코딩 되지만 CSS Layout은 <div>내용</div> 형식으로 코딩 됩니다. 예제코드 전체를 보여드리겠습니다. 화면(또는 지면) 관계상 코드를 모두 담아내면 화면이 너무 커지므로 코드의 서체크기를 일부러 줄여 놓았습니다. 코드를 자세히 확인하시려면 그냥 복사해서 메모장에서 볼 것을 권합니다.

Table for Layout CSS Layout
89 line 39 line
2,661 byte 1,027 byte
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=euc-kr” />
<title>Table for Layout</title>
<link href=”TableForLayout.css” rel=”stylesheet” type=”text/css” />
</head>
<body style=”margin:0″>
<p id=”moveTo”><a href=”CSSLayout.html”>Go to CSS Layout</a></p>
<table width=”100%” border=”0″ cellspacing=”0″ cellpadding=”20″>
<tr>
<td colspan=”3″ valign=”top” id=”header”>Table for Layout</td>
</tr>
<tr>
<td width=”20%” height=”300″ valign=”top” style=”background:#666″><table width=”100%” border=”0″ cellspacing=”0″ cellpadding=”5″ id=”menu”>
<tr>
<th style=”height:30px; background:#999″>2Depth Title </th>
</tr>
<tr>
<td>Menu1</td>
</tr>
<tr>
<td class=”line”></td>
</tr>
<tr>
<td>Menu2</td>
</tr>
<tr>
<td class=”line”></td>
</tr>
<tr>
<td>Menu3</td>
</tr>
<tr>
<td class=”line”></td>
</tr>
<tr>
<td>Menu4</td>
</tr>
<tr>
<td class=”line”></td>
</tr>
<tr>
<td>Menu5</td>
</tr>
<tr>
<td class=”line”></td>
</tr>
</table></td>
<td width=”60%” height=”300″ valign=”top” style=”background:#999″><table width=”100%” border=”0″ cellspacing=”0″ cellpadding=”5″ id=”pageTitle”>
<tr>
<th style=”height:30px”>3Depth Title </th>
</tr>
</table>
<table width=”100%” cellspacing=”0″>
<tr>
<td id=”text”>Content </td>
</tr>
</table></td>
<td width=”20%” height=”300″ valign=”top” style=”background:#CCC”><table width=”100%” border=”0″ cellspacing=”0″ cellpadding=”5″ id=”links”>
<tr>
<th style=”height:30px; background:#666″>Links </th>
</tr>
<tr>
<td>Link List 1</td>
</tr>
<tr>
<td class=”line”></td>
</tr>
<tr>
<td>Link List 2 </td>
</tr>
<tr>
<td class=”line”></td>
</tr>
<tr>
<td>Link List 1</td>
</tr>
<tr>
<td class=”line”></td>
</tr>
</table></td>
</tr>
<tr>
<td colspan=”3″ valign=”top” id=”footer” style=”background:#333″><a href=”http://naradesign.net/”>naradesign.net</a></td>
</tr>
</table>
</body>
</html>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=euc-kr” />
<title>CSS Layout</title>
<link href=”CSSLayout.css” rel=”stylesheet” type=”text/css” />
</head>
<body>
<p id=”moveTo”><a href=”TableForLayout.html”>Go to Table for Layout</a></p>
<h1>CSS Layout</h1>
<div id=”center”>
<div id=”menu”>
<h2>2Depth Title </h2>
<ul>
<li>Menu1</li>
<li>Menu2</li>
<li>Menu3</li>
<li>Menu4</li>
<li>Menu5</li>
</ul>
</div>
<div id=”content”>
<h3>3Depth Title </h3>
<div id=”text”> Content </div>
</div>
<div id=”links”>
<h3>Links</h3>
<ul>
<li>Link List 1</li>
<li>Link List 2</li>
<li>Link List 3 </li>
</ul>
</div>
</div>
<address id=”footer”>
<a href=”http://naradesign.net/”>naradesign.net</a>
</address>
</body>
</html>
Table for Layout CSS Layout
17 line 23 line
1,030 byte 1,771 byte
* { font-size:small; font-family:Arial}
a { font:inherit; color:#FFF; text-decoration:none}
a:hover { text-decoration:underline}
#moveTo { position:absolute; top:4em; right:2em}
#header { font-size:5em; color:#FFF; font-weight:bold; background:#000}
#menu th { border-bottom:3px solid #FFF; font-size:x-large; font-weight:bold; color: #FF0; text-align:left}
#menu td { font-size:small; font-weight:bold; color:#FFF}
#menu td.line { height:1px; padding:0; background:#FFF}
#pageTitle { margin-bottom:1em; background:#999}
#pageTitle th,
#link th {border-bottom:3px solid #FFF; font-size:x-large; font-weight:bold; color: #FF0; text-align:left; background:#666}
#text { color:#FFF;}
#links { margin-bottom:1em}
#links th {border-bottom:3px solid #FFF; font-size:x-large; font-weight:bold; color: #FF0; text-align:left; background:#666}
#links td { color:#FFF}
#links td.line { height:1px; padding:0; background:#FFF}
#footer { font-family: Verdana; font-size:x-large; font-weight:bold; font-style:italic; color:#FFF}
* { margin:0; padding:0; font-size:small; font-family:Arial}
h1 { font-size:5em; color:#FFF; font-weight:bold; background:#000; padding:20px}
h2 { padding:5px; font-size:x-large; font-weight:bold; color:#FF0; background:#999; border-bottom:3px solid #FFF; margin:20px; margin-bottom:0}
h3 { padding:5px; font-size:x-large; font-weight:bold; color:#FF0; background:#666; border-bottom:3px solid #FFF; margin:20px; margin-bottom:0}
a { font:inherit; color:#FFF; text-decoration:none}
a:hover { text-decoration:underline}
#moveTo { position:absolute; top:4em; right:2em}
#center { position:relative; overflow:hidden}
#menu { position:relative; width:20%; background:#666; float:left; height:300px}
#menu ul { margin:20px; margin-top:0; padding:0}
#menu li { padding:5px; border-bottom:1px solid #FFF; font-weight:bold; color:#FFF; list-style:none}
#content { position:relative; background: #999; font-size:small; font-family:Verdana; color:#FFF; width:60%; float:left; height:300px}
#content h3 { margin-bottom:1em}
#text { margin:20px; margin-top:0; line-height:150%; font-family:Verdana}
#text table { border-left:1px solid #CCC; border-top:1px solid #CCC}
#text table caption { font-weight:bold; text-align:left}
#text table th { background:#666}
#text table th,
#text table td { padding:.5em; border-right:1px solid #CCC; border-bottom:1px solid #CCC; text-align:center}
#links { position:relative; float:left; background:#CCCCCC; width:20%; clear:right; height:300px}
#links ul { margin:20px; margin-top:0; padding:0}
#links li { padding:5px; border-bottom:1px solid #FFF; color:#FFF; list-style:none}
#footer { position:relative; clear:both; background: #333; font-family: Verdana; font-size:x-large; font-weight:bold; color:#FFF; padding:20px }

CSS Layout의 경우 HTML 파일의 용량은 50% 이상 절감됩니다. CSS파일의 용량은 약 70% 정도 증가하였지만 CSS파일은 웹 사이트 접속시 딱 한번 로드되고 로컬 PC의 캐시메모리에서 재활용 되므로 전송량에 미치는 부하는 무시해도 좋은 수준입니다. 이 실험에서는 비록 하나의 웹 페이지를 단순 비교하였지만 웹 페이지의 수가 증가하면 증가할 수록 웹 표준 방식의 CSS Layout Code는 경제적인 효과가 배가됩니다.

사람이나 로봇(컴퓨터)이 이해하기 쉬운 구조가 됩니다.

코드가 줄어들기 때문에 개발자들이 코드보기가 수월해 진다는 것은 쉽게 추측할 수 있습니다. 즉, 삽질을 줄여주죠. 하지만 그런 점은 겨우 부가적인 이점에 불과합니다. 웹 표준 방식의 HTML 코드는 모바일 장치를 포함한 어떤 종류의 웹 브라우저 장치에서 출력 되더라도 그것을 이해할 수 있는 수준으로 렌더링 됩니다. 또한 검색엔진으로부터 높은 점수를 받습니다. 특히 Title 태그와 h1~h6 등의 제목태그 및 alt 텍스트를 사용할 때 그렇습니다. 검색엔진의 접근성이 높아져서 피검색 될 확률이 높아집니다.

유지보수가 쉬워지고 유지보수 비용을 절감시켜 줍니다.

웹 사이트의 디자인만 개편한다고 가정할 때 Table 기반으로 Layout된 페이지들은 Layout을 변경하기 위하여 수천 페이지의 HTML 문서를 모두 열어서 수정해야 하는 고통이 따릅니다. 하지만 CSS 기반으로 Layout된 웹사이트는 HTML 파일은 열어볼 필요조차 없어집니다. 불과 몇개의 CSS파일을 수정하는 것으로 매우 간단하게 수천개의 웹 페이지 디자인을 개편할 수 있습니다. 표현요소를 CSS로 완벽하게 분리했다면 HTML파일을 수정해야 하는 상황은 오직 데이터가 업데이트 될 때 뿐입니다.

웹 접근성 문제는 웹 표준만 지키면 90% 이상 해결 됩니다.

웹은 태어날 때부터 보편성을 전제하였습니다. 즉, 웹 표준만 지키면 누구나 접근할 수 있도록 이미 그렇게 설계 되어 있다는 의미 입니다. 가장 짧은 시간에 접근성을 크게 증진시킬 수 있는 방법으로서 image 요소에 대한 alt 텍스트를 강조하고 있는데 이것은 WCAG 지침이기 이전에 XHTML 표준 문법입니다. 실제로 WCAG 지침은 XHTML의 표준 문법 가운데 접근성 이슈만 추려내 놓고 그것을 지키라고 말하는 문장이 많습니다.

분류: CSS,웹 디자인,웹 접근성,웹 표준 | 2007년 2월 3일, 3:25 | 정찬명 | 댓글: 80개 |
트랙백URI - http://naradesign.net/wp/2007/02/03/113/trackback/

80개의 댓글이 있습니다.

  1. miriya 댓글:

    웹표준을 지키면 뭐가 좋은지 알기 쉽게 잘 설명하셨네요^^
    전 요즘 테이블 배제하고 DIV 익히는중인데, DIV가 얼마나 심플한지느낄 수 있었습니다.
    CSS가 얼마나 좋은놈인지는 수십개의 비슷한 웹페이지를 만들때 실감할 수 있더군요.
    개개의 태그에 마킹하는 대신 CSS로 묶어놓고 파일 한부분만 수정하면 다른 페이지가 동시에 수정되는 그 효율성이란~~

  2. eouia 댓글:

    이 글에 나온 자료는 찬명님의 허락을 얻어 다음주 블로터닷넷에서 열리는 포럼에 발표(?) 교육(?)자료로 사용됩니다. 흔쾌히 사용을 허락해주시고, 친절하게 블로그 포스팅까지 남겨주신 찬명님께 감사드립니다.

  3. 정찬명 댓글:

    뜨억~ 이시간까지 안주무시고 ㅡㅜ; 자꾸 이러시면 우리 후배들이 IT업종에 뛰어든걸 두려워 하지 않을까요? ㅎㅎㅎ. 늦은시간, 아니 이렇게 이른 시간에 댓글 주셔서 정말 반갑고 감사드립니다.^___^ 사무실에 혼자 있었는데 댓글 확인하고 외로움을 싹 잊었습니다.

  4. 일모리 댓글:

    유지보수에 관한 부분이 참 민감한 곳이 한국 입니다. 그런만큼 이 부분에 대해서 테이블을 걷어내면 $$이 절약된다는 전제를 내걸면 열띈 공방이 몇일째 이어질수도 있다고 생각이 되네요.

    일단 비용 절감에 있어서 중요한 부분이 시멘틱 하게 짜여 졌느냐 입니다. 그리고 그걸 받혀줄만한 디자인도 함께 말이죠. 그저 1px의 차이를 매꾸기 위해 div 를 한개 더 넣고, span 넣고 짜여지는 페이지는 나중에 css를 바꿀때에도 테이블 만큼은 아닐지라도 고생하게 되죠.

    그것이 두번째 문제를 부르는데 시멘틱하게 태그를 완성하며 css를 알맞게 사용할만한 소위 말하는 퍼블리셔들이 그리 많지 않다는 것입니다. 그만큼 비용절감을 예상하고 했건만 인원이 적은만큼 $$도 들겠죠.

    이 외에도 여러 이유들이 있는지라 비용절감에 참 어려움을 느낍니다. 아 물론 해외에는 오히려 비용절감이 상당한 메리트 입니다. 자유 자제의 디자인 변화는 espn.com 에서도 잘 볼수 있죠. 아무튼 쉽지 않은 주제 같네요… ㅠㅠ

  5. 최용진 댓글:

    찬명아, 전에 얘기한 것처럼 우리회사에 이 게시물 게재 좀 할께…
    개발자에게 널리 알리고 싶은 내용이지만, 얼마나 공감할 지는 시간이 지나봐야 알 듯 싶다.
    (원체 나를 포함해 개발자들이 텍스트를 진지하게 읽는 것에 게으른 지라.. )

    언제든 한 잔 그리우면 연락줘.. ^^

  6. 정찬명 댓글:

    즐거운 주말들 보내셨나요? 주말동안 PC를 멀리하다보니 답변이 좀 늦었습니다 ^^

    일모리님께서 민감한 이슈를 잘 끌어내 주신것 같습니다. 말씀하신대로 웹 표준을 바르게 소화할 수 있는 웹 퍼블리셔들이 많지 않은것이 문제라면 문제인데 이는 차차 개선이 되어질 것으로 전망합니다. 또한 현재로서는 희소가치를 지니고 있는 웹 퍼블리셔들이 그만한 처우를 받아야 할 것으로 생각 되기도 하구요.

    용진이형, 얼마든지 가능합니다. 하단에 CC(Creative Commons) 표시가 되어있는 저작물들은 일정 조건만 지켜주면 형 뿐만이 아니라 누구라도 별도의 허락 없이 사용할 수 있습니다. SI 업계에서도 이런 분야에 관심을 가지고 있는것을 보면 정말 웹 표준이 대세는 대세인가 봅니다.^^ 설이 지나기 전에 제가 한턱 쏠께요. 지난번엔 너무 죄송했어요ㅡㅡ;(그 다음날 다른 곳에서 사용하니 카드결제 잘 되더라구요ㅎㅎㅎ)

  7. 최병훈 댓글:

    많은 도움됬습니다.
    정말 그동안 CSS란걸 안썼던게 정말 바보같은 짓이란걸 느끼게됫네요.
    어쩌피 몇페이지 안되는거라고 생각했었는데…
    저렇게 코딩이 간단 간단해질수 있는군요.

  8. StarLight 댓글:

    웹 표준을 지켰을 때의 장점을 일목요연하게 잘 설명해 주셨네요! 좋은 글 잘 읽였습니다.

  9. 정찬명 댓글:

    진작에 썼더라면 더 좋았을뻔 했다는 생각이 듭니다.^^ 도움이 되셨다니 기쁘고 좋은 글이라고 평해주셔서 감사합니다.

  10. blaer 댓글:

    와아..
    정말 명료하고 시원하게 설명해주셨네요..

    간단하지만 이런 것들은 이해하지도 않고..
    (아니.. 이해하려 하지도 않는 사람들도 더러 봤습니다..)
    크로스 브라우징이니..
    요즘 추세가 이렇다느니..
    표준이 이렇다느니 떠들며 웹표준.. 웹표준 하는 사람들이 좀 봤으면 좋겠네요..

  11. blaer 댓글:

    여태 테이블로만 작업해오던 사람들이 좀 알게되었다고 요지도 모른체..
    격한 반응 보이는 사람들을.. 많이 봐와서 조금 비뚫은 댓글이 되버렸네요.. ^^;;

  12. 정찬명 댓글:

    워워~ 흥분하시면 곤란합니다 ㅡㅡ; 웹 표준에 대하여 관심을 두는 분위기 자체를 저는 긍정적으로 보고 있습니다. 단지 이것을 Cross Browsing을 위한 하나의 수단이나 Trend 쯤으로 밖에 인식하지 않는 것은 저도 문제가 있다고 생각합니다. 웹 표준의 진짜 목적은 보다 큰 가치인 ‘인류 평등, 보편성, 서비스’ 라고 생각하기 때문입니다. 방문과 함께 이렇게 좋은 댓글 주셔서 감사합니다 ^^;

  13. RONIA.net 댓글:

    웹 표준을 준수하면 좋은 점…

    웹 표준을 준수할 경우 생기는 장점 중 하나,naradesign.net 의 글 읽으러 가기드림카카오 팀원은 꼭 읽어보세요 ;)…

  14. 김요한 댓글:

    마침 phpschool에 관련된 글이 있어 링크를 걸었던건데..ㅎㅎ
    (홍보해드렸으니, 상주세요~!)

  15. 정찬명 댓글:

    김요한님께, 감사해요!
    빌붙기 1회 허용권 발급 대상자 입니다!

    대전광역시 서구 탄방동 636번지 스위트빌2차 1109호 에 오셔서 2007년 2월 11(일) 까지 빌붙기 1회 허용권을 찾아가세요. 오실 때 다음 서류를 지참하시기 바랍니다.

    1. 2006년 근로소득원천징수영수증(연소득 1,800만원 이상인자 해당없음)
    2. 주민등록초본(본인확인용, 주말에는 전자정부에서 발급가능)

    축하드립니다!

  16. 김요한 댓글:

    허걱;;; ㅠ,.ㅠ
    분당오시면 그때 쓸려고 했는데..

    1번 조건에서 이미 탈락되는군요 ㅠ,.ㅠ

  17. 정찬명 댓글:

    저런.. 안타깝게 되었네요. 그럼 다음 기회에~ ㅋㅋㅋ ^^;

  18. 김요한 댓글:

    뷁!! ㅠ,.ㅠ

  19. 허웅 댓글:

    퍼갑니다.

  20. CN 댓글:

    멋진 정리입니다. :0)

  21. 정찬명 댓글:

    감사합니다 (__)

  22. 장헤원 댓글:

    왜 방명록에 올리니까 밑에부분이 잘리나요 –? 설마 이것도 짤리낭 ㅡㅡ; 짤리면 지워주세여 ㅜㅜ
    다른분은 안봤으면 하는데요… 쪽팔려서리. 다름이 아니라… 저는 23살이고요 학교를그만두고 제 웹서버구축해서 작업해보고 싶어서요 ㅎㅎ 지금 html책이랑css

  23. 이선주 댓글:

    좋은 글을 잘 봤습니다.
    저는 윈도우 2000에 익스플로러 6.0을 쓰는데요.
    [동일 디자인의 Table for Layout과 CSS Layout 비교] 부분에서
    Table for Layout 페이지와 CSS Layout 페이지가 동일하게 보이지 않습니다.
    이렇게 되는 경우는 어떤 경우죠? 제 경우에는 CSS Layout 부분의 목록이랑 내용이
    있어야될 부분이 하얗게 보입니다.
    어찌된거죠???

    꼭 메일을 좀 보내주세요.

    네이버에서 블로그2.0 리뉴얼 한 걸 보고 적잖이 충격을 받았습니다.
    이제는 HTML 코딩하는것도 변화해야 하는 시기인것 같구요…
    드림위버같은 툴의 활용법도 다시 배워야 할 듯 싶습니다.

  24. 정찬명 댓글:

    이선주님께, 저도 방금 IE6 에서 화면을 확인하고는 깜짝 놀랐습니다. 예제를 만들 때 IE6에서 테스트 해보지 못했습니다. 시간이 되는대로 IE6 문제를 해결하고 그 원인을 이곳에 댓글로 공개하겠습니다. 지적해 주셔서 정말 감사합니다.

  25. 정찬명 댓글:

    위 예제의 IE6 렌더링 호환성 문제 확인결과 입니다. #menu, #content, #links 라는 영역을 감싸고 있는 #center 라는 영역에 width 가 설정되어 있지 않아서 IE6이 그것을 0 으로 잘못 렌더링 하였습니다. IE6은 width 값을 0 으로 판단하였고 overflow:hidden 이라는 코드 때문에 해당 영역에 출력될 콘텐트를 출력하지 않았던 것입니다. 이 문제를 해결하기 위하여 #center 영역에 width:100% 라는 코드를 추가하였습니다. 의외로 간단하게 해결되었네요 ^^;

  26. 최윤영 댓글:

    와우~ 멋진 홈피네요. 좋은정보네요^^

  27. 정찬명 댓글:

    최윤영님, 감사합니다. 요즈음엔 제가 칭찬으로 먹고 사는것 같습니다. 절로 힘이 나네요.^^

  28. 이선주 댓글:

    아…. CSS 관련해서 궁금한게 있는데 어디다가 질문을 할 수 있을까요.
    요즘 테이블을 버리고 CSS2 로 위치를 잡는데.

    position, float, display, text-align의 차이와 권한을 잘 모르겠습니다.

    아주 골치아프네요.

  29. 정찬명 댓글:

    이선주님, 제가 이것에 대하여 답변을 드리려면 무척이나 많은 타이핑이 필요할 것 같아서 일단 참조가 될만한 링크를 소개해 드리겠습니다. CSS와 관련하여 예전에 저도 많은 도움을 받았던 곳입니다. http://www.cadvance.org/ 예제와 함께 쉽고 재미있게 설명되어 있습니다. 그리고 저런 질문은 너무 포괄적입니다. 한번에 하나씩 구체적으로 질문해주시고 예제코드가 있다면 링크하거나 함께 올려주시는 것이 좋습니다. http://standardmag.org/ 이곳 물론 아시겠죠? CSS와 밥말아먹는 사람들이 많은 곳입니다. 이곳에서도 많은 도움을 받으실 수 있을껍니다. 골치 아프지 마시구요 ^^; CSS 재미있잖아요!

  30. 이선주 댓글:

    아 감사합니다. 저도 그런 사이트를 알려주셨으면 했습니다.
    그런데 이거 하다보니까. 심각한 문제가 있는데요.
    익스플로러에서 말하는 마진이랑 패딩이. CSS2에 나와있는 기준이랑 다르더군요!

    다음부터 질문은 가려서 하겠습니다.
    그래도 현명한 답변을 주시니 감사힙니다,

  31. 정찬명 댓글:

    그것은 항상 그런것이 아닙니다. IE가 Quirk Mode 상태로 렌더링 될 때만 그렇습니다. IE6이든 IE7이든 DTD만 바르게 적어주면 Quirk Mode 상태로 렌더링 되지 않고 표준모드로 렌더링 됩니다. DTD를 바르게 적어주세요.

  32. 이선주 댓글:

    음 CSS 작업을 하다보니까 알게된건데요. 위의 예제에서도 같은 문제가 있네요.
    문제가 되는 부분은 CSS 레이아웃의 경우 창의 크기를 줄이게 되면. DIV 박스들이 가로 한줄로 정리되어 있다가 자기 자리를 못지키고. 밀려서 세로로 내려가버리네요.

    테이블로 만든 레이아웃의 경우는 제자리를 지키구요.

    전체크기의 윈도우로 볼때는 이상이 없는데. 전체크기에서 크기를 줄여보시면 바로 아실 듯.

  33. 정찬명 댓글:

    앗, 어떤 브라우저에서 그렇죠? 화면비례형 레이아웃을 사용했고 IE, FF, OP 에서 확인했지만 밀려 내려가지는 않는데요?

  34. 이선주 댓글:

    지금처럼 각 객체가 상위 containing block의 크기(Width)가 정해져있지 않으면, 브라우져의 폭을 줄여버리면 밀려나네요.
    세로 스크롤바만 생기고 가로 스크롤바만 생기죠.

    의도된 경우는 상관 없는데. 의도되지 않은 경우는 낭패네요.

    그리고 크기 조절에서 IE7.0하고 6.0의 차이가 심하게 나네요.
    익스플로러에서도 의도된 마진이나 크기를 내려면 별도 처리를 해야 하는게 약점이네요.

  35. 정찬명 댓글:

    이선주님, 저는 왜 이해가 안되는거죠? ㅡㅡ; 밀려내려간다는 의미를 잘 모르겠어요. 제가 보기에 밀려내려가는 박스는 없거든요. 그리고 레이아웃도 IE 6~7간 차이는 없어요. 혹시 이해 되시는 분은 제게 설명을 좀 해주실래요? 제가 예제로 드린 저 페이지 말씀하시는거 분명히 맞죠? 의도된 마진이나 크기를 내려면 무엇을 별도처리를 해야한다는 것인지도 모르겠구요. 참, 난감하네요.

  36. 이선주 댓글:

    이메일 주소를 하나 알려주시겠어요?

    보시면 금방 아실듯 합니다.
    별로 난해한 내용은 아니예요.

  37. 정찬명 댓글:

    네, 감사합니다. dece24앳gmail.com 입니다.

  38. jucke 댓글:

    테스트…

    테스트 more.. ㅎㅎ…

  39. 정찬명 댓글:

    테스트 감사합니다.(__) 이런거라도 있어야 사람좀 들락거리는것 같죠. ㅋㅋㅋ

  40. 코딩쟁이 댓글:

    퍼갑니다. 좋은글이네요 ^^

  41. 정찬명 댓글:

    코딩쟁이님, 감사합니다. 널리 널리 퍼지면 좋겠습니다. 단 한 가지, 저작자 표시를 부탁드립니다. 제 블로그에 있는 모든 글은 복제가 가능 하지만 “저작자표시, 비영리, 변경금지” 조건을 지켜주셔야 합니다. 이것은 공유를 제한하려는 것이 아니라 저작권이 보호된 상태로 널리 공유하기 위한 규칙이니 지켜주시면 감사드리겠습니다.

  42. 곰돌이푸 댓글:

    좋은글 감사합니다 =)
    퍼갑니다. praisethegod.cafe24.com

  43. 배달맥 댓글:

    찬명님, 일목요연하게 잘 정리된 강좌에 감사드립니다.

    주욱 이 내용에 관심깊게 지켜보다가 .. 위의 댓글 중 이선주님과 같은 현상에 대해 ..
    저도 의문점이 드는군요. 분명히 제 IE6 브라우저에서도 이선주님이 지적하신 바와 같이 ..
    전체 화면과 같을 때는 관계없지만 임의적으로 브라우저자체의 크기를 마우스로 잡아서 줄여보면 ..

    역시나 이선주님이 지적한 바와 같이 가로로 일직선으로 배치되어 있어야 할 내용들이 세로로 밀려나 버리는 현상이 있네요. CSSLayout.html 에서 말입니다.

    물론 TableForLayout.html에서는 이선주님의 의견과 같이 .. 내용들이 제 자리를 잘 지키고 있습니다.
    이게 이유가 뭘까요?? 이젠 제가 궁금해지기까지 합니다.

    흐음 … 웹표준, CSS 아직까지는 쉽게 와 닿지는 않네요.
    꼬옥, 결과를 알려주시면 감사하겠습니다. ^^*

    수고요.

  44. 정찬명 댓글:

    배달맥님 반갑습니다. IE6 에서 가로로 flaot 된 박스들이 세로로 밀리는 현상은 IE6의 버그 때문입니다. 다른 브라우저에서는 그러한 현상이 없습니다. 그리고 IE6의 버그 현상이 제 글을 부연설명 하는데 있어서 치명적인 문제라고 생각하지 않았기 때문에 수정하지는 않았습니다. 수정하려면 MS가 IE6을 수정해야죠. ^^;

  45. 문병구 댓글:

    html 탄생자체가 table과 함께 존재했습니다.. table이 div보다 먼저 존재했던 표준태그입니다..
    그리고 표준이라고 해서 더 코딩을 짧게 해 준다는 논리는 잘 못된 논리라고 생각합니다..
    표준은 이용자의 번거로움을 줄이고자 모든 플랫폼에서 호환할 수 있도록 개발방향을 지침해 둔겁니다.
    표준이 아니지만 표준보다 뛰어난 기술구현은 얼마든지 나올수 있고 현재도 MS의 제품중에 비표준으로 자신만을 기술구현해 둔게 많습니다..

    또한 div와 table은 서로의 장단점이 있는것이지 한쪽 방향만 비교해서 이것이 더 좋지 않느냐 하는 것도 문제가 됩니다..

    DIV는 일괄적인 적용이 뛰어나서 코딩을 줄여주지만 반대로 table처럼 필드 하나 하나 여러가지 옵션으로 처리하지는 못합니다.. 물론 처리하려면 div도 노가다 태그가 들어갑니다..
    반면 table도 css를 통해서 모든 폰트와 색,선,tr,td의 모든 옵션들까지 하나하나 지정할 필요없이 일괄처리 할 수 있습니다.
    오히려 그렇게 볼때 table이 훨신유연한 결과가 나오게 됩니다..
    그리고 밀리는 현상을 막연히 버그가 있다고 말씀하시는데 그건 버그가 아니라 기본테두리가 형성되어 있지 않기때문에 나타나는 증상입니다..
    즉 기본테두리를 유지하지 못하기 때문에 테이블을 완전고정시킬수도 없습니다.
    제로보드같은 경우 게시판제목부분을 완전 픽스시켜버립니다..
    그렇게 되면 글이 테이블을 넘어간다고 해서 밑으로 내려가는게 아니라 그냥 넘어 가는 글이나 이미지 심지어 테이블들까지 정확한 픽셀위치에서 침범하지 못하게 잘라버립니다.. 절대 테이블의 흐트러짐이 없죠..
    테이블의 옵션이 다양하기 때문에 테이블안에 테이블들도 전부 다양하게 옵션을 주고 필드 하나 하나까지 서로 다르게 처리할 수 있는겁니다..
    상대적으로 div는 그렇게 많은 옵션이 없기 때문에 디테일한 처리는 table과 비교가 불가능합니다..
    table이 옵션이 많다고 그런 옵션들을 지리지리 전부 넣어준후 코딩이 많지 않느냐 하는식의 비교는 잘 못됬다는겁니다… 위에서처럼 일괄처리 자체가 의미가 없을정도로 필드하나 하나의 변화가 되는 테이블안에 어떤 내용들이 들어 간다면 div도 역시 노가다 테그가 들어가야 함은 당연한 지사고 옵션이 table코드 만큼 따라오지 못하기 때문에 처리할 수 없는 부분도 생깁니다..

    말하다 보니 정리가 안됬는데 대략 무슨 말씀을 전하려고 했는지는 이해하셨으리라 생각합니다.

  46. 정찬명 댓글:

    >html 탄생자체가 table과 함께 존재했습니다.. table이 div보다 먼저 존재했던 표준태그입니다.

    어떤 태그가 먼저 존재했는지 저는 잘 모르겠군요. 하지만 그것은 전혀 중요하지 않습니다.

    >표준이라고 해서 더 코딩을 짧게 해 준다는 논리는 잘 못된 논리라고 생각합니다.

    웹 표준 코딩이 실제로 코드를 줄여준다는 것을 제가 충분히 보여드렸다고 생각합니다.

    >표준은 이용자의 번거로움을 줄이고자 모든 플랫폼에서 호환할 수 있도록 개발방향을 지침해 둔겁니다.

    네 맞는 말씀이죠 ^^

    >표준이 아니지만 표준보다 뛰어난 기술구현은 얼마든지 나올수 있고 현재도 MS의 제품중에 비표준으로 자신만을 기술구현해 둔게 많습니다.

    뛰어난 기술이라도 그것이 보편성을 갖지 못한다면 표준기술이라 할 수 없고 그것을 사용하는 것은 독점의 폐해만 가져옵니다. MS의 비 표준 기술은 암적인 존재에 불과합니다. 뛰어나다고 하여 MS 종속적인 기술을 쫓는것은 바람직하지 않습니다. 우리나라와 같이 MS종속적인 기술개발이 국제적으로 얼마나 창피한 일인지 모르시나요?

    >div와 table은 서로의 장단점이 있는것이지 한쪽 방향만 비교해서 이것이 더 좋지 않느냐 하는 것도 문제가 됩니다.

    저는 지금 table을 이용한 레이아웃이 잘못되었다는 것을 말하고 있습니다. table은 2차원의 격자형 구조를 갖는 데이터를 마크업하는 태그로서 이것이 레이아웃에 사용될 때 접근성은 치명적으로 훼손됩니다. 제 글이 그것을 설명하는데 부족했다면 좀 더 많은 자료를 찾아봐주시기 바랍니다. W3C에서 말하는 table의 기본 스팩도 참조하시구요.

    >DIV는 일괄적인 적용이 뛰어나서 코딩을 줄여주지만 반대로 table처럼 필드 하나 하나 여러가지 옵션으로 처리하지는 못합니다. 물론 처리하려면 div도 노가다 태그가 들어갑니다. 반면 table도 css를 통해서 모든 폰트와 색,선,tr,td의 모든 옵션들까지 하나하나 지정할 필요없이 일괄처리 할 수 있습니다. 오히려 그렇게 볼때 table이 훨신유연한 결과가 나오게 됩니다.

    저는 문병구님이 table 과 div 태그를 언제 사용해야 하는지 잘 모르고 있다고 생각합니다.

    >그리고 밀리는 현상을 막연히 버그가 있다고 말씀하시는데 그건 버그가 아니라 기본테두리가 형성되어 있지 않기때문에 나타나는 증상입니다. 즉 기본테두리를 유지하지 못하기 때문에 테이블을 완전고정시킬수도 없습니다. 제로보드같은 경우 게시판제목부분을 완전 픽스시켜버립니다. 그렇게 되면 글이 테이블을 넘어간다고 해서 밑으로 내려가는게 아니라 그냥 넘어 가는 글이나 이미지 심지어 테이블들까지 정확한 픽셀위치에서 침범하지 못하게 잘라버립니다. 절대 테이블의 흐트러짐이 없죠.

    밀려서 넘치는 현상은 Table for Layout 이 아닌 CSS Layout 을 IE6 에서 볼 때 생기는 현상입니다. 버그 맞습니다. 그리고 데이터가 셀을 넘쳐 흐를때 글자가 잘리는 현상은 바람직 하지 않습니다. 넘치는 데이터는 셀이 유연하게 늘어나서 그것을 출력할 수 있도록 해주어야 합니다. 저는 제로보드 차기 버전의 XHTML/CSS 웹 표준화를 담당하고 있습니다. 제로보드는 더이상 그런 방식을 사용하지 않을 것입니다.

    >테이블의 옵션이 다양하기 때문에 테이블안에 테이블들도 전부 다양하게 옵션을 주고 필드 하나 하나까지 서로 다르게 처리할 수 있는겁니다. 상대적으로 div는 그렇게 많은 옵션이 없기 때문에 디테일한 처리는 table과 비교가 불가능합니다. table이 옵션이 많다고 그런 옵션들을 지리지리 전부 넣어준후 코딩이 많지 않느냐 하는식의 비교는 잘 못됬다는겁니다. 위에서처럼 일괄처리 자체가 의미가 없을정도로 필드하나 하나의 변화가 되는 테이블안에 어떤 내용들이 들어 간다면 div도 역시 노가다 테그가 들어가야 함은 당연한 지사고 옵션이 table코드 만큼 따라오지 못하기 때문에 처리할 수 없는 부분도 생깁니다. 말하다 보니 정리가 안됬는데 대략 무슨 말씀을 전하려고 했는지는 이해하셨으리라 생각합니다.

    문명구님의 말씀 전체적으로 이해하거나 동의하기 어렵습니다. 올바른 마크업 규칙과 웹 표준 방식의 코딩 그리고 CSS의 표준 스펙에 대한 이해가 필요하다고 생각합니다.

  47. Study Hard 댓글:

    문병구님의 말씀에 조금 힘을 실어 보고자 합니다.

    저는 HTML 기반으로 Contents도 작성해 보고 애플리케이션(Ajax 기반의)도 작성해 본 경험이 있습니다. 여러 상황에 따라

    Layout 설계 방식이 조금씩 틀려질 수 밖에 없게 되더군요. 저는 여러 상황을 크게 세 가지로 정리하고 있습니다.

    1. Java Script 기반 애플리케이션, 또는 그러한 기능이 다수 구현된 페이지
    2. 디자인 요소가 강한 일반 웹 페이지
    3. 순수 Contents로서의 웹 페이지 혹은 그런 Contents 들이 조합된 페이지

    그럼 첫째,

    Ajax 기반(JavaScript 기반)의 애플리케이션을 제작할 경우, 처음에는 Table을 이용한 Layout 설계는 지.양. 해야 한다는 대세에

    공감하여 DIV를 이용하여 Layout을 설계, 작성해 보았으나 문병구 님이 말씀하신 것처럼 특정 기능을 제작할 때(Grid 같은

    부분이 되겠습니다. Drag에 의한 Column Resizing도 되는. 그리고 각종 화면 Control 관련 기능 구현 시)는 거의 불가능에 가까운 경우도

    있습니다. (이는 제 실력 탓일 수도 있지만, 이미 잘 구현되어 사용하고있는수많은 JavaScript 기반의 애플리케이션들,

    구글의 Ajax 기반 애플리케이션들 등도 모두 Table과 DIV를 적절히 이용합니다.)

    따라서 DIV와 Table을 적절히 사용할 경우 기능 구현과 성능 측면에서 일단 Ajax 기반(JavaScript 기반)의 애플리케이션을

    최적으로 개발할 수 있다는 결론입니다..

    그럼 둘째,

    일반 웹 페이지를 보면, 즉 위에 있는 “동일 디자인의 Table for Layout과 CSS Layout 비교” 부분의 예를 빌어 보자면

    CSS를 걷어 냈을 때의 원래 정보의 의미 전달에 문제가 없다고 하셨는데, 애초에 저 페이지를 작성한 목적을 분명히 해야 할 것 같습니다.

    위의 예는 데이터를 “표현” 한다기 보다는 메뉴 구조를 “디자인” 한다고 보는 것이 맞다고 봅니다. 분명 위의 예처럼 DIV를 사용하는 경우는

    CSS를 걷어 내어도 이해 가능한 메뉴 구조를 출력할 수 있어서 분명 유용합니다만 실제 서비스되는 페이지를 보면 수많은 정보가 한 페이지에서

    표현될 경우 저 구조 자체도 결국 인식하기 어려워 질 수도 있습니다. 물론 Table을 이용한 Layout보다는 매우 양호합니다만, 그렇다고 CSS를

    걷어내고 서비스하려는 경우는 없겠지요.

    하고 싶은 말이 잘 표현이 안되었네요 ^^. 즉, 말하고자 하는 바는! 올바른 마크업 규칙이라 하는 것은 정보의 표현에 있어서 그 필요성이 극대화되는

    것이지 화면의 디자인에 있어서는 그다지 중요한 부분이 아니라고 봅니다. 망치를 들면 모든 것이 못으로 보인다는 얘기가 있습니다. 어차피

    목적이 메뉴 구조를 디자인하는 것이지 정보의 전달이 아니라고 한다면 DIV for Layout 이건 Table for Layout이건 더 효율적인 방법으로 (남용하지

    않고 ^^) 사용되면 맞다고 생각합니다.

    그럼 세 번째,

    Contents를 제작하는 경우 이 비교 실험 글에서 제시하는 바는 모두 옳다고 생각합니다.

    현재 이 페이지에는 많은 Contents가 있습니다. 자체 글과 수맣은 댓글들이 각각 Contents가 되겠지요. 그리고 자체 글과 댓글들이 하나의 Contents

    가 될 수 있습니다. 지금 제가 쓰고 있는 댓글은 전혀 마크업을 하지 않고 있습니다. 그냥 제가 임의대로 단락 등을 나누고 있지요. 만약 이 댓글에서

    마크업을 수행하였다면 제가 쓰는 이 글(시간을 들여서 제 생각을 하나하나 정리한 소중한 글 ^^)은 재사용 가능한 Contents로서 다른

    CSS를 입혀서 다르게 표현될 수도 있었겠지요. 일반 신문기사, 교육 자료, 블로그 등도 올바르게 마크업 된다면 스크랩 해온 Contents를 자신의

    웹 페이지에 맞도록 CSS 디자인을 할 수도 있습니다. 뭐 일반적인 장점을 얘기하는 것이죠.

    ! —- 결론

    제 글이 이해가 되도록 잘 쓰여졌는지 모르겠습니다. 신경은 썼는데 ^^

    결론을 말씀드리자면, 지금까지 마구잡이 식 웹 코딩에 대한 경조을 울리면서 정찬명 님과 같은 많은 전문가 분들이 주장하시는 바는 그 의미가

    바르고 훌륭하다고 생각합니다. 단, 조금 Case by Case 에 대한 고려도 있었으면 합니다. 최초에 HTML이 순수하게 정보를 Markup하기

    위함이었다면 (SGML을 살펴보면 잘 알 수 있습니다) 현재는 Ajax다, RUI다 하는 시대에서 DIV for Layout이 맞다, Table for Layout이 맞다라는

    흑백논리보다는 각각의 경우에 맞는 적용 방안을 수립, 적용하는 것이 맞다고 봅니다. 하나의 방법론으로만 웹 프로그래밍을 하기에는 이제는

    너무 다양한 색깔을 가지고 있는 것이 지금의 웹이 아닌가 싶습니다.

  48. Study Hard 댓글:

    앗! 댓글에 수정 기능이 없네요. ㅋ~

    한 마디 더 덧붙이자면

    제 주변에 아는 분이 Ajax 기반으로 웹 프로그래밍을 하시는데, Widget 방식으로 구현하시는 것을 DIV로만 표현하시려다가

    매우 고생하시는 것을 보았습니다. 제가 그것을 봐드렸을 때 DIV로 안되는 것은 아니었지만 Table로 처리하는 것보다

    엄청난 Effort가 드는 것이었습니다. 어차피 Widget은 정보를 표현하는 것보다는 기능을 가지는 Component 역할인데 굳이

    그것을 단편적인 시각으로만 바라보아 웹 표준 코딩 방법이라는 DIV를 이용한 Layout으로만 구현하려고 하여(PM이 그렇게 지시하였답니만 -.-)

    프로젝트 일정에도 차질을 빚고 기능 구현에도 실패하는 사례가 있더군요.

    웹 표준 코딩을 말씀하시는 분들께서도 이러한 점을 잘 유념하셔서 글을 써 주신다면 저희처럼 후발주자들이 남용하는 일도 없어질 수 있겠지요. ^^

    저도 더욱 정진하여 제가 생각하는 바에 대한 근거 자료를 확보, 이에 대한 글도 한번 써볼까 생각 중입니다. ^^

  49. 정찬명 댓글:

    화면 구성을 위하여 HTML을 사용하는 것은 분명 잘못된 방법입니다. 제가 CSS를 자주 걷어내는 이유는 CSS가 제거된 상태로 논리적인 구조가 유지되는 화면이라면 모든 디바이스에서 그것을 지원할 수 있기 때문입니다. 즉, 가장 원시적인 HTML 마크업만으로도 문서를 이해하거나 상호작용하는데 문제가 없도록 만들어 놓고 그 다음 CSS를 입히고 Javascript를 입혀야 합니다. 만약 RIA를 위하여 HTML의 접근성 규칙(웹 표준)을 희생하여야 한다면 그것은 십중팔구 웹의 구조가 허용하지 않는것을 웹에 억지로 집어 넣으려는 시도라고 생각되며 저는 그러한 방침에는 반대합니다. Table 은 표를 마크업하기 위하여 최적화된 마크업이며 Layout 을 위하여 사용하는 것은 문법에도 맞지 않고 문서의 접근성을 훼손 시킵니다. 그리고 웹 표준과 접근성의 궁극적인 목적은 보편적인(누구나 어떤 장치를 이용해도 볼 수 있는..) 웹 문서를 만들고 사용자를 이롭게 하자는 것이지 개발자들의 노고를 줄이자는 목적은 아닙니다. 물론 웹 표준이 개발공수를 줄여주는 측면(CSS로 디자인을 분리하는 것)도 분명히 있지만 그것이 목적은 아니라는 말입니다. UI개발자로서 지금 하고 있는 일이 누구를 위한 일인지 생각해 주셨으면 합니다. 웹 표준 방식의 UI개발이 처음부터 쉽지는 않습니다. 그리고 웹 표준 UI개발이 개발 공수가 많이 들어간다는 것은 아직 숙련되지 않은 개발자를 투입한 것과 기존에는 고려사항에 넣지 않았던 크로스브라우징 이슈를 구현조건에 포함시켰기 때문입니다. IE6의 버그를 해결하는데 무수히 많은 시간을 소비하는 일 때문에 웹 표준에는 더 많은 시간이 걸린다는 오해를 받고있는 것입니다. 정확하게 말하면 우리는 IE와 같은 비 표준 브라우저의 뒷치닥거리(버그 해결)를 하느라고 늦는 것입니다. Ajax 나 Flash 등의 RIA 기술로 하여금 웹이 확장되는 것을 반대하지는 않습니다. 하지만 한 가지 분명히 해 두어야 할 것은 웹이 지향하고 있는 보편성을 훼손하지 않아야 한다는 점입니다.

    PS : 댓글 수정하기 기능이 없는것은 유감입니다. 제가 워드프레스를 뜯어고칠 능력이 안됩니다 ㅡㅡ;

  50. 정찬명 댓글:

    첨언합니다. 그리드 형식의 데이터는 Table로 구현하는 것이 맞습니다. 간혹 처음 웹 표준에 입문하시는 분들 가운데 표는 절대로 쓰면 안되는 것으로 오인하여 표 형식의 데이터 조차 div 태그로 마크업하는 사례가 많은데 이것은 잘못된 것입니다. 그리드(2차원의 격자형 데이터)는 Table로 마크업하는 것이 맞습니다.

  51. Study Hard 댓글:

    댓글 감사합니다. 반대 의견과 동의 의견 모두 저에게는 도움이 되었습니다. ^^

    넵, 말씀하신바 맞습니다. 웹 표준 UI 개발이 말씀하신대로 숙련된 개발자가 개발을 하면 당연히 개발 공수는 예상외로 발생하지 않습니다. 제가 말씀드리고자 한 바는 처음 웹 표준에 입문하시는 분들이 Table 과 DIV 이슈에 대해서 민감해하는 사례와 같은 경우를 해소하기 위한 Best Practice가 제시되면 어떨까 하는 의견이었습니다. 책이나 Article 등을 보아도 대부분 간단한 예로만 나와서 실무에 적용 시 어려움이 많은 것이 사실입니다. 여러 문제점들을 패턴화하여 공략법을 제시하면 새로 입문하시는 분들도 웹 표준 UI 구축을 더 쉽게 하실 수 있으리라 봅니다. 여러 분들이 이렇게 노력하시는 지금이 바로 그런 단계라 생각됩니다. ^^

    한가지, Device관련하여 말씀을 드리겠습니다. Opera Mini의 예를 들어주셨는데, 사실 우리가 모르는 수많은 디바이스가 있습니다. Unix의 Linx 또한 브라우저이지요. Java의 Hot Browser도 있습니다. 이 모두가 표준을 모두 준수할 수도, 또는 지원이 미비할 수도, 혹은 자신들만의 구현체를 만들 수도 있습니다. 어떤 사람은 Opera의 Mini만 쓸 지도, 어떤 사람은 Java의 Hot Browser만 쓸지도 모릅니다. 그것이 0.1%일지라도요. 말씀하신대로 웹 표준 프로그래밍을 하게 되면 이러한 모든 Browser에서도 잘 보일 수 있겠지요.

    하지만, 사실은 우리는 몇 가지 알려진 브라우저(IE6, IE7, Safari, Netscape, Firefox, Opera 등)에 맞추어만 작업을 합니다. 이 글을 보시는 다른 어떤 분들도 IE6 이전 버전에 맞추어 프로그래밍 하시는 분들은 없겠지요(흠… 있을지도 모르겠습니다만). 하지만 정작 Opera Mini에서도 잘 보여야 할 수 있을 정도로 Down Sizing하는 것은 결국 반대급부를 일으킵니다. 향상된 혹은 미려한 웹 페이지를 제공하느냐 아니면 누구라도 문제없이 볼 수 있는 웹 페이지를 제공하느냐? 우리는 이 사이에서 결정합니다.

    모바일 디바이스의 예를 들어보겠습니다. XHTML 기반으로 Contents를 작성 후 이것에 CSS를 적용하여 웹 브라우저에서도 모바일 브라우저에서도 보일 수 있도록 구현해 보았습니다.(XSLT를 써서 구조까지 바꾸어도 보는 일이었습니다.) 물론 웹 표준 UI 작성법등에 기초해서 (제 수준은 높지 않습니다만) 100% 보일 수 있도록 해 보았지만 결국 테스트 수준의 간단한 데이터만 가능하였고 조금만 복잡해지면 아무리 체계적, 효율적으로 설계해도 원하는 대로 표현하기가 힘들어졌습니다. 결국 모바일 디바이스에 맞추어 따로 구현을 하였습니다. 구글의 예를 들어보겠습니다. 구글 페이지~ 정말 단순합니다. 모 이미지하고 텍스트 딸랑 몇 개이지요. 이 간단한 것도 구글 모바일 검색 서비스에서는 별도로 구현하였습니다. 그것을 구현하지 못할리 없었겠지만 0.1%라도 해당 디바이스에 최적화 할 수 있도록 노력하는 것이지요.

    모바일 디바이스의 예가 좀 주제와 벗어날 수도 있었겠지만, 웹 표준 관련된 각종 Article 등에서 빠짐없이 나왔던 것이 잘 정제된 웹 페이지 하나로 여러 디바이스에서 표현이 가능하다라는 언급이 많았기 때문입니다. 실제로 그렇게 하려면 위에서 말씀드린 반대급부가 생길 수 밖에 없는데도요. 모든 디바이스(웹 브라우저도 포함해서)는 아니겠지만 수많은 디바이스에서도 잘 보이는 Contents를 작성하기 위해서 이러한 점들에 기준을 마련, 작업을 수행하는 것이 옳다고 생각합니다.

    전반적으로 말씀하시는 바에 공감합니다.

    단, 제가 말씀드리고 싶은 것은 진정 필드에서 그것들을 수행할 때 일어나는 일들에 대해서 입니다. 적용해보고 찾아보고 바꾸어보고~ 이러는 과장에서 나오는 경험들은 대원칙과 반하게 될 경우가 발생하며 이러한 경우 억지로 맞추어 나가기 보다는 새로운 원칙으로 발전해 나가는 쪽으로 가야한다고 생각합니다. 물론 웹 표준에 크게(?) 어긋나지 않은 형태로여야 겠지요.

  52. 정찬명 댓글:

    모바일 디바이스에 대한 예는 저희가 생각하고 있는 구체적이고 동일한 지향점이 아닌가 생각됩니다. 가장 적절한 예를 잘 들어주셨다고 생각합니다.

    말씀하시는 논의의 핵심은 웹 표준의 이론과 실제 사이의 괴리에 대한 내용이라고 생각되며 저도 그점에 대하여는 아직 경험이 많지 않아서 마찬가지로 고민중입니다. 웹 표준은 병렬개발(하나의 프로젝트를 진행하면서 디자인, 코딩, 개발이 동시다발적으로 이루어지는 형태)이 가능하며, 하나의 잘 된 소스를 이용하여 다양한 디바이스에서도 문제없이 사용이 가능하다고 하는데 많은 분들은 이러한 이론에 대하여 물음표를 던집니다.

    Y포털과 같은 경우 병렬형태의 개발을 진행해 보았지만 사실상 실패했다고 말하기도 하고 대부분의 사람들은 모바일 장치를 위한 별도의 소스가 필요하다고 합니다. 하지만 저는 Y포털이 너무 쉽게 병렬개발에 실패했다고 고백한 것은 아닌지 다시 의문을 던집니다.(아직 그런말을 하기에는 이르다는 겁니다. 더 많은 경험과 시도가 필요했다고 생각합니다) 그리고 정말 모바일을 위한 별도의 소스가 필요한지에 대하여도 의심합니다. 사실 병렬개발 안해도 웹 표준은 가능하고 모바일을 위하여 별도의 소스를 개발하는 것도 사용자를 위하여 그다지 나쁜 선택이라고는 생각하지 않기 때문에 저는 그다지 반대하고 싶지는 않습니다.

    하지만 사람들이 이론에 불과하다고 말하는 그것은 우리가 개척해야할 지향점으로서 필요하다고 생각합니다. 지금은 실패했을지 몰라도 누군가는 그것을 실현해 내고야 말 것입니다. 또 그 과정에서 발생하는 노하우를 공유하고 새로운 대안과 이론을 만들어 내는 일도 분명히 이 계통에 도움이 됩니다.

    그리고 그 이론이 실현되지 않더라도 저는 회의적인 생각으로 돌아서지는 않을 것입니다. 저는 웹 표준의 기술적, 상업적 가치보다는 웹 표준이 지향하는 인본주의적 가치와 철학에 매료된 사람인것 같습니다.(많은 분들이 웹 표준의 경제학을 증명하라고 말할 때 저는 웹 표준의 철학 이야기를 하고 싶어합니다. 그래서 우스겟소리로 저같은 사람들을 만나면 같은 빨갱이라고 부르면서 즐거워한답니다 ㅡㅡ;)

    결론 : 아직 저희나라는 전체적으로 웹 표준에 대한 개발경험이 부족하다고 생각합니다. 따라서 실패의 경험을 나누는 것도 중요하고 이것이 더욱 무르익을 만한 시간이 필요하며 너무 성급하게 달고 쓰다고 말하는 것은 경계해야 하지 않을까 생각합니다.

    첨언 : 말씀주신 웹 표준의 문제점, 패턴, 공략법은 좋은 의견입니다. 늘 생각하고는 있는데 그것을 ‘검증하고-글로 옮기는’ 등의 과정이 짧은 순간에 이루어지는 것이 아니다 보니 아직 많은 정보가 공유되지 못한 모양입니다. 조금 기다리시면 더욱 많은 자료가 나오겠죠. (사실 이미 훌륭한 자료들이 많지만 HTML 형태의 문서로 되어있지 않아서 읽혀지지 않은 측면도 있습니다.) Study Hard님께서도 실무하시면서 얻은 지식들을 함께 나누는데 동참해 주시면 참 좋겠네요 ^^

    좋은 의견 감사합니다. 좋은밤 되세요! (__)

  53. happyness 댓글:

    Table for Layout vs CSS Layout…

    웹에 종사하는 많은 사람들이 이미 웹표준에 대해 경험하고 실무에 적용하고 있다.본인의 경우 웹표준에 대해 접하기 시작한 것은 작년 말부터 이며, 실제 실무에 적용하기 시작한 것은 그리…

  54. kang 댓글:

    유익한 사이트 군요. 자주 찾아오겠습니다.
    저는 웹표준 부터 시작을 해서, 처음부터 div 를 이용한 lay out 으로 사용해서 project 를 완성했는데. CSS ( cascading style sheet ) 라는것이 폭포 처럼 위에서 아래로 물떨어지듯이
    문서가 정렬해서 내려오는데, 이것을 조작해서 마음데로 바꾸어 주는것이지요. 객체지향적 이기도 하구요. Div를 사용해서 작업을 해면, 화면구성이 어떻건 간에 팀원들한테 각자 자기맡은일 던저 주고, 일시키고 모아서 붙이면 되더군요. 이런식으로 하니까 어떤것을 먼저 만들던지 전혀 상관도 없고, 여려명이 작업을 하는데, 참 편한 구조 입니다. 그리고 하나의 html 파일을 가지고, CSS 만 바꾸면 마음데로 모양을 바꿀수 있는데. (위치요…) 작업을 줄여주는데 최고의 조건이구요.

    * 기획자 들을 만나서 말들을 들어보면, 불만이..웹디자이너 , 개발자 들이 잘하기는 하는데, 자기들이 원하는것은 기술을 보는게 아니고, 자기들이 써넣은 내용을 잘 표현을 하는것 이랍니다. 그걸 멋데로 하니까 문제라고 합니다.

    *기존의 웹 개발이, 디자이너 위주로 이루어 졌다면, 웹표준으로 넘어가면서 문서 작성을 기반으로 넘어가게 됩니다. 완전히 일하는 구조가 다른것 이지요. 웹표준 을 기점으로 작업의 흐름 자체가 변하게 될것입니다.

  55. 정낙훈 댓글:

    [table]로 된 레이아웃을 [div]로 바꾸다가 도저히 안되는 부분이 있어 다시 [table] 코딩으로 작업 방향을 바꾸었습니다. 코멘트까지 포함해서 위의 글을 참고해서 다시 한 번 더 읽고 어떤 부분에서 그러한 문제점이 발생했는지 다시 한 번 더 찬찬히 돌이켜봐야겠네요. 역시 이런 좋은 글은 두고 두고 또 읽고 또 읽고 할 수 있어서 참 좋네요. 완벽하게 옳은 것이고 그대로 따라야 한다는 것은 아니지만 이렇게 잘 정리된 글을 통해서 모자란 부분은 또 더 덧붙여 나갈 수 있으니깐요~

  56. 바람냄새 댓글:

    누가 웹표준을 꼭해야하냐라고 태클걸면, 이모든걸 마스터해서 꼭 알려줘야 겠군요. ㅎㅎ
    저에게도 다시한번 정리가 되는 글이라 너무 고맙게 읽고갑니다. 앞으로도 자주 들를게요^^

  57. 정찬명 댓글:

    감사합니다. 저도 아직 완전하지 않기 때문에 피드백을 통해서 많이 배우고 있습니다. 부족한 내용 보이시면 보충도 해주세요. ^^

  58. 임태희 댓글:

    아 미치겠다!!
    이런 분들 때문에 웹표준이 TABLE을 쓰면 안된다라고 인식이 되고 있군요
    하나의 글을 올릴때 좀더 심도 있게 갑시다
    국가적인 망신 입니다.
    Table 는 쓰지말라는게 아닙니다.
    STYLE 태그를 불필요하게 쓰지말라는데 근본적인 문제가 있는 것 입니다.

    좀 기본에 충실 합시다!!

    Mlang

  59. 황준상 댓글:

    멋진글.. 저를 움직이신 글..

  60. 코끼리붕붕 댓글:

    웹표준, 웹접근성.. 어렵기만하고 뭐가뭔지 하나도 몰라서 조금씩 알아가는 중입니다. 여기 글이 이해하는데 많은 도움이 되어 넘 감사합니다^^ 잊어먹지 않으려고 제 블로그에 복사해놨어요. 궁금한 점이 있을때마다 들리겠습니다~ 좋은 하루 되세요!!

  61. 윤성준 댓글:

    아무리설명을 이해하려 해보았지만 결국 파악을 못했는데 이렇게 좋은 설명으로 인해 글을 본지 10분만에 개념을 이해해버린 취업준비생입니다!
    윗분들의 의견 또한 도움이 되어 모든분들에게 고마움을 전합니다
    자주 놀러와 종종 흔적음 남기겠습니다
    감사합니다^^

  62. 정찬명 댓글:

    저의 기쁨 입니다. ^^ 감사합니다.

  63. 마약 댓글:

    “자수해서 광명”
    …에서 빵 터졌습니다 ㅋㅋ 에고~ 웃어서 죄송합니다…;;

    그냥 단어자체가 재밌었을 뿐입니다 ㅋㅋ

  64. k2five 댓글:

    “현실적으로 어렵다” 라고 말씀하시는 분들도 일부 공감은 합니다만
    웹표준에 대한 관련업체(웹에이전시 등…)의 생각이 바뀌지 않는 이상은
    쉽지만은 않은 것 같습니다.
    웹표준화,접근성에 시큰둥한 반응을 보이는 내지는 아무 반응이 없는 업체들을
    보며 이제 한걸음뗀 저로서는 어떤생각을 들게 만드는지 말씀드리기가 참 곤란하군요.
    하지만 수고하시는 분들을 보며 나름 꿈을 키우며 열심히 전진하고 있습니다.
    좋은 정보 감사드립니다.

  65. 정찬명 댓글:

    k2five님을 응원 합니다! ^^

  66. 정찬명 댓글:

    마약님, 즐거우셨다니 저도 ㅎㅎㅎ.

  67. 홍창수 댓글:

    좋은글 많이 보고 갑니다.
    감사합니다. =)

  68. 아놔~ 댓글:

    잘보고 갑니다.

    웹표준! 웹표준하길래 공부를 하게 되었습니다.
    실무작업하면서.. 살짝 짜증이 나는 부분은..
    css 작업하면서 6,7,8 별로 만들어야한다는거조 ㅡㅡa
    그게 어딜 봐서 웹표준이라고 하는건지; 당췌 이해 안갑니다.
    테이블로했을때 보다 버그 찾아서 고치는 시간이 많이 걸리네요 ㅡㅡa

    * 6버전에서 해결안되는 점이 있어 여기서 짜증 내고 가네요~ ㅈㅅ

  69. 정찬명 댓글:

    아놔~ 님 힘내세요! 웹 표준은 상호운용성을 확보하는 주요한 수단이고 크로스브라우징이라는 개념과는 다른 개념인데 많은 분들이 동일시 해서 혼동하는 개념이죠. 웹 표준을 완벽하게 지킨다고 해서 크로스브라우징이 완전히 확보되는 것은 아닌데 말이죠. ^^ (그러나 여전히 웹 표준은 기본으로 지켜야 크로스브라우징을 할 수가 있다는 사실은 변함이 없겠구요) 화이팅 입니다!

  70. 익명 댓글:

    가끔, 웹에 관련된 다양한 시각을 알고 싶을 때 찾아 읽어 보지만
    늘… 현실의 벽에 부딪히는 것은 어쩔 수 없더라구요.
    저도 웹 개발자이지만 항상 5대 브라우져는 테스트 합니다만 저만 그럽니다.
    그렇다고 일정을 못 맞추는 것도 아니고 얘기를 해도 다들 귀담아 듣지 않습니다.
    이 사태를 바꿀 수 있는 것은 다른 직종은 모르겠지만 SI에 있어서만은 “고객”뿐이 없다고 생각이 되더군요. 고객왈 “왜.. FF, OP, SF에서는 안되요? 이상하게 나와요?” 라고 해준다면..전 가끔 그런 날을 생각합니다..
    다른건 몰라도 드림위버로 Table 태그들로 이뤄진 html을 받으면 짜증이 밀려옵니다.

  71. 정찬명 댓글:

    @익명
    익명님 같은 분들이 점점 많아져야 한다고 생각합니다. 힘내세요. ^^

  72. 익명 댓글:

    웹 접근성 문제는 웹 표준만 지키면 90% 이상 해결 됩니다. 이부분… 아무리 생각해도 이부분에 대해서는 긍정을 못하겠네요 ㅜㅜ 결국 핵을 쓰는 것 자체가 웹표준에서도 벗어나는 부분 아닌가 싶네요 ;;

  73. 정찬명 댓글:

    @익명
    웹 표준만 지키면 웹 접근성 문제의 90% 이상 해결된다는 것은 사실 정확한 근거가 없는 이야기라서 틀린 말이라고 해도 할 말은 없습니다. 하지만 저는 경험으로 미루어 그렇게 믿고 있습니다. 대체 텍스트를 사용하는 것. 레이아웃을 위한 테이블을 사용하지 않는 것, 의미에 맞는 태그를 사용하는 것 모두 표준에 해당하는 지침이지만 이 세 가지만 지켜도 웹 접근성의 주요한 문제들을 획기적으로 개선할 수 있기 때문입니다.

    핵을 사용하는 것과 웹 접근성은 관계가 없다고 생각합니다. 웹 접근성은 장애인이 웹을 이용할 수 있는지 없는지를 측정하는 개념인데 핵을 사용함으로써 장애인이 격을 수 있는 문제는 없기 때문입니다. 핵의 사용과 웹 접근성 문제는 별개의 문제로써 분리해서 생각해야 한다고 봅니다.

  74. […] 웹 표준 코딩의 장점. Table for Layout과 CSS Layout의 비교 실험. […]

  75. 익명 댓글:

    ㅇㅇㅇ

  76. 이민주 댓글:

    덕분에 정리가 되네요

    감사합니다!

  77. 지웅 댓글:

    후아..2007년도 부터 웹표준화가 이루어졌었군요..

    저는 지금에서야 웹표준화를 공부 합니다..

    이런 저런글을 많이 읽다보니 이제 준비를 어떻게 해야 될지도

    감이 오네요 좋은글 잘 읽고 갑니다.

  78. 익명 댓글:

    정말 잘 읽었습니다.
    감사 감사합니다^^

  79. http://Www.probirka.org/forum/go/?http://grimaldilines7.wordpress.com/2017/06/08/grimaldi-lines

    » 웹 표준 코딩의 장점. Table for Layout과 CSS Layout의 비교 실험. – NARADESIGN

댓글 쓰기

전송된 글이 나타나지 않는다면 필터링 된 것입니다. dece24앳gmail.com 으로 메일 주세요.
(X)HTML 코드 사용이 가능하지만 소스 코드 출력을 원하시면 <꺽쇠>는 [괄호]로 변환하여 작성해 주세요.

필수 아님

필수 아님