웹 레이아웃... table vs div

mattabu의 이미지

웹화면 디자인을 위해서 지금까지는 전체적인 레이아웃을 위해서 table 을 사용해왔었는데요. div 를 이용해서 CSS 를 적용하는 것이 더 좋다고들 하는데... 어떤 점이 좋은지 잘 모르겠습니다. 나름대로 괜찮다고 생각되는 점은 두가지가 있긴 합니다.

(1) 태그수가 줄어든다.
(2) 레이아웃 변경이 쉽다.

이 외에 다른 좋은 점이 있나요? 다른 분들의 의견을 들어보고 싶습니다.

File attachments: 
첨부파일 크기
Image icon css_xen.gif27.17 KB
Image icon w3m_xen_garden.gif26.43 KB
uriel의 이미지

ilmol님이 쓴 테이블은 이제 그만 쉬어야 할 때 라는 글입니다. http://ilmol.com/wp/2005/06/09/25/

익명 사용자의 이미지

ilmol 님의 글을 읽어보니 재미있네요.

CSS3 가 기대됩니다.

우리모두 테이블(table) 을 걷어내자!!

mattabu의 이미지

ilmol 님의 글이 상당히 일목요연하게 잘 설명이 되어 있네요...
충분히 이해가 됩니다. 앞으로는 table 보다는 div로 레이아웃을 꾸며야 하는 당위성이 느껴집니다.

그렇지만 아직은 레이아웃이 여러 브라우저에 똑같이 보이게 하기 위해서 hack 을 써야만 하는 것은 좀.. 불편하긴 해요... ^^ 아마 시간이 지나면 해결이 되겠죠...

즐겁게 살자구요. 어떻게 태어난 인생인데~!

mmx900의 이미지

요 몇년새 테이블을 버리라는 압박을 자주 받는군요. 위의 주제에 관한 제 결론은 문서(화면)의 구조를 생각하는 한 테이블 레이아웃 + DIV, P등 각종 태그와 + CSS 를 필요한 대로 써도 된다는 겁니다. 용도에 맞게 쓰는 것이 최선이긴 하지만 테이블을 표에만 쓰라니, 말도 안 됩니다. :lol: 스윙의 레이아웃 매니저를 생각해 보면, UI 디자인을 위해 이만한 녀석도 보기 드물다는 것을 인정하지 않을 수 없습니다.

보충 설명 들어갑니다.

1. 테이블 레이아웃을 모두 Div로 바꿔서 쓸 여력이 되는 사람이면 테이블 레이아웃을 정리하는 쪽이 훨씬 낫습니다.(물론 그 과정에서, CSS 사용으로 가독성의 적이라 할 수 있는 border=0, cellspacing=0 따위의 요소는 제거되고, 불필요한 단일 TD의 테이블 등은 DIV나 P로 바뀌겠지요) 겹겹이 쌓인 inner table이 문제가 되는 것도 대개는 문서 구조따위는 생각치도 않고 무작정 디자인만 맞추려다가 필요없는 테이블이 몇배나 늘어나게 되어 생기는 것입니다. Table을 억지로 CSS로 바꾸다가 삽입하게 되는 수많은 플로팅, 포지셔닝 요소들이야말로 후에 소스를 전혀 고치지 못하게 만드는 진짜 '재앙'이 될 가능성이 높습니다. 거기에 IE에서 정상 동작하도록 만드는 추가 삽질을 생각하면 으... 이 글을 읽는 분들은 경험적으로 알고 계시겠지만, 테이블을 욕하는 이유는 HTML 문서가 얼마나 구조적으로 짜여졌는가의 문제이며, 테이블이 느리고 복잡(하다고 주장)한 것은 근본적인 문제가 아닙니다. 이 문제가 해결된다면 유지보수하기 쉬운 쪽은 오히려 테이블 레이아웃 쪽입니다.

2. 위에 언급된 '테이블은 이제 그만 쉬어야 할 때'라는 글에서, 테이블 레이아웃과 DIV 레이아웃의 비교는 부적절해 보입니다. 변환(?)에서 TABLE, TR태그는 무시되었기 때문입니다. 저중 한 줄에 동일한 높이를 적용하려면 어떻게 해야 할까요? 한 행을 이루는 DIV들을 감싸거나 동일한 클래스를 부여해야 하는데 과연 테이블보다 낫다고 할 수 있을까요? DIV들이 있는 전체 영역의 너비를 조절하려면 어떻게 하죠? 메인 레이아웃이라면 HTML이나 BODY 태그에 CSS(WIDTH)를 적용하는 방법이 쉽고 논리적이지만, 예상치 못한 문제(IE에서의 전혀 다른 동작, margin 등의 발생)들이 자주 발생합니다.

또 해당 예제에서만 보더라도,

...
<div style="float:left;"></div>
<div style="clear:both;"></div>
...

무척 비직관적이고, 수정시 세심한 고려가 필요한 부분입니다. 이것이 테이블보다 낫다는 생각은 별로 들지 않습니다.

3. 현 시점에서 vertical-align 속성은 TD에서만 정상 동작합니다. IMG 태그와 같이 쓰는 등의 꽁수를 쓰지 않고 DIV에서 사용할 방법은 없습니다.

출근 시간에 쫓기느라 여기까지만 씁니다. 혹 문제가 있다면 지적 해주세요.

Setzer Gabbiani

returnet의 이미지

모르는 사람은 모르는 사이에 대세가 된겁니다.
제가 방문해본 국내 페이지 중 아실만한 곳 하나
링크합니다. http://scrapnote.com
요즘은 그런 일이 줄어든 듯 하지만 테이블 안닫
아주고 바디마저 안 닫아준 페이지를 로딩 할때
면 이러다 언젠가 낭패를 볼테지.. 하는 생각이
들었었습니다.
물론 테이블 기교도 멋지게 사용해야 할 곳엔 사
용해야 하겠지만.. : )

sh.의 이미지

눈물나네요.. mmx900님의 글에 동조(?)하는 장문의 글을 적었는데 순간적으로 회사 인터넷이 끊기면서 허공으로 날아가버렸습니다 T-T

기억을 되돌려보자면..
복잡한 테이블이 난무하는 이른바 table hell 상태의 웹페이지가 문제가 많은 것은 사실입니다만 (제가 다니는 회사의 다른 개발자가 작성한 페이지에서는 무려 11단계의 테이블 도 심심찮게 발견을 합니다 -_-) css를 이용하는 경우에도 무조건 쉽다고 하기는 어렵습니다. html 에서 인라인으로 사용된 style마저도 걷어내고 모두 외부 css로 뽑아내다보니 css파일도 무지하게 많아지고 css간의 의존성 -_- 마저 생기는 경우도 많이 있습니다. 이걸 잘 생각해서 css를 작성해야 하는데 이게 쉽지않은 일이고요.. css hell 이다 라고 외치고 싶어지죠 :evil:

그리고 눈 딱 감고 테이블 한개 넣는게 훨씬 도움이 되는 경우도 많이 있습니다. 그리고 레이아웃에 대한 브라우저 호환성 측면에서 볼 때 테이블이 유리한것은 사실이고요. 지금도 ie와 firefox를 둘 다 띄워놓고 레이아웃 작업을 하고 있는데 주로는 ie에 맞추고 firefox는 알아보고 사용하는데 지장이 없을 정도로만 배려하고 있습니다 8) 물론 회사에서는 firefox따위 신경도 안쓰지만 나름대로 개발자의 자존심이라고 할까요 --;

3번에 지적하신 vertical-align에 대한 것은 100% 공감합니다. 이것 때문에 작은 테이블이라도 넣지 않을 수 없었던 적이 여러번 있었거든요. 다 그린 그림에 잉크 쏟은 기분도 들고 해서 영 찜찜하지만 대안이 없더라고요...

정태영의 이미지

mmx900 wrote:
1. 테이블 레이아웃을 모두 Div로 바꿔서 쓸 여력이 되는 사람이면 테이블 레이아웃을 정리하는 쪽이 훨씬 낫습니다.(물론 그 과정에서, CSS 사용으로 가독성의 적이라 할 수 있는 border=0, cellspacing=0 따위의 요소는 제거되고, 불필요한 단일 TD의 테이블 등은 DIV나 P로 바뀌겠지요) 겹겹이 쌓인 inner table이 문제가 되는 것도 대개는 문서 구조따위는 생각치도 않고 무작정 디자인만 맞추려다가 필요없는 테이블이 몇배나 늘어나게 되어 생기는 것입니다. Table을 억지로 CSS로 바꾸다가 삽입하게 되는 수많은 플로팅, 포지셔닝 요소들이야말로 후에 소스를 전혀 고치지 못하게 만드는 진짜 '재앙'이 될 가능성이 높습니다. 거기에 IE에서 정상 동작하도록 만드는 추가 삽질을 생각하면 으... 이 글을 읽는 분들은 경험적으로 알고 계시겠지만, 테이블을 욕하는 이유는 HTML 문서가 얼마나 구조적으로 짜여졌는가의 문제이며, 테이블이 느리고 복잡(하다고 주장)한 것은 근본적인 문제가 아닙니다. 이 문제가 해결된다면 유지보수하기 쉬운 쪽은 오히려 테이블 레이아웃 쪽입니다.

2. 위에 언급된 '테이블은 이제 그만 쉬어야 할 때'라는 글에서, 테이블 레이아웃과 DIV 레이아웃의 비교는 부적절해 보입니다. 변환(?)에서 TABLE, TR태그는 무시되었기 때문입니다. 저중 한 줄에 동일한 높이를 적용하려면 어떻게 해야 할까요? 한 행을 이루는 DIV들을 감싸거나 동일한 클래스를 부여해야 하는데 과연 테이블보다 낫다고 할 수 있을까요? DIV들이 있는 전체 영역의 너비를 조절하려면 어떻게 하죠? 메인 레이아웃이라면 HTML이나 BODY 태그에 CSS(WIDTH)를 적용하는 방법이 쉽고 논리적이지만, 예상치 못한 문제(IE에서의 전혀 다른 동작, margin 등의 발생)들이 자주 발생합니다.

또 해당 예제에서만 보더라도,

...
<div style="float:left;"></div>
<div style="clear:both;"></div>
...

무척 비직관적이고, 수정시 세심한 고려가 필요한 부분입니다. 이것이 테이블보다 낫다는 생각은 별로 들지 않습니다.

3. 현 시점에서 vertical-align 속성은 TD에서만 정상 동작합니다. IMG 태그와 같이 쓰는 등의 꽁수를 쓰지 않고 DIV에서 사용할 방법은 없습니다.

출근 시간에 쫓기느라 여기까지만 씁니다. 혹 문제가 있다면 지적 해주세요.

vertical-align 문제는 해결되야 할 문제라고 생각합니다만....

div 로 충분히 할 능력이 된다면 table 로 레이아웃을 하는게 더 낫지는 않습니다 ... 너무나도 유명한 css xen garden 같은 곳을 links 라던가 lynx 등의 텍스트 브라우져로 보신 적이 혹시 있으신 지 모르겠군요... (links 는 테이블을 지원하기도 합니다만...)

첨부화일로 css xen garden 을 links로 연 모습을 보여드리죠 ...

div , p 등으로 제목 문단 등이 정리되어 있는 잘 정리된 문서라는 게 확 들어오지 않으시나요?

모양은 css로 내용은 html 로... 이 원칙만 지켜진다면... html 이라는 매체를 통해 핸드폰에서 혹은 pda... 아니라면 인터넷 단말기 등에서 똑같은 내용의 잘 정리된 문서들을 아주 잘 열람할 수 있습니다... 물론 모양은 각 접속 장치에 따라서 다르게 보여지겠지만 말이죠...

이게 world wide web 컨소시움에서 우리가 가야할 길이라고 말하고 있는 universal access 의 한 예가 아닐까 싶습니다...

p.s) w3m 은 링크가 칼라풀하게 나와서 좀 더 보기좋군요.. w3m 으로 본 모습도 추가합니다...

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트
Image icon 0바이트

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

정태영의 이미지

http://gregshin.pe.kr/

정보통신접근성 향상 표준화 포럼
http://www.iabf.or.kr/index.asp

자료실에 재밌는 pdf가 몇가지 있음..

후지쯔에서 만든 자사의 웹사이트 접근성 향상을 위한 지침..
http://www.iabf.or.kr/standard/View.asp?seq=6&gotopage=1&gotoblock=0

관심 있으시면 한 번 읽어보세요 :)

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

HTML은 모양보다는 내용과 글의 구조를 나타내기 위한 것입니다.
그래서 저는 내용과 모양을 분리하는게 좋다고 생각합니다. :)
그게 나중에 레이아웃을 바꾸는 데에도 도움이 될 것 같네요.
아... 그리고 Inline Style (<tag style="..."></tag>)은 쓰지 않는 것이 좋습니다. 웬만하면 ID나 클래스를 사용해서 스타일을 지정합시다.

익명 사용자의 이미지

CSS도 브라우저마다 해석이 조금씩 달라서 모양이 똑같이 나오진 않더군요 하지만 CSS가 바람직한 것은 확실합니다. 모양이 달라보일 수는 있어도 어느 브라우저에서든 정보에 접근하는데는 문제가 없거든요. 모양과 내용을 완전히 분리해 기술하자는 XML 원칙에도 맞구요. 시간과 여건이 허락하는한 XHTML+CSS가 가장 좋은 방법입니다 아마 현재 KLDP 홈페이지도 XHTML+CSS 조합이죠?

일모리의 이미지

Quote:
에 언급된 '테이블은 이제 그만 쉬어야 할 때'라는 글에서, 테이블 레이아웃과 DIV 레이아웃의 비교는 부적절해 보입니다. 변환(?)에서 TABLE, TR태그는 무시되었기 때문입니다. 저중 한 줄에 동일한 높이를 적용하려면 어떻게 해야 할까요? 한 행을 이루는 DIV들을 감싸거나 동일한 클래스를 부여해야 하는데 과연 테이블보다 낫다고 할 수 있을까요?

정말 그 비교가 부적절한가요? 비교가 워낙에 극단적으로 간단히 적힌것이라서 가능한 말씀입니다만, 정확하게 각각의 모든 장 단점을 비교하게 된다면 테이블은 전혀 이길수 없는 토론입니다. 테이블의 nesting 으로 다닥붙어 복잡하게 레이아웃으로 형성된것이라면 div 로 홈페이지를 제작해 본 사람이라면 어느쪽이 더 편한지는 누구라도 알만한 사실입니다. 비교가 비록 부적절할지라도 테이블보다 div가 더 좋다고 자신있게 확실히 말할수 있네요.

Quote:
DIV들이 있는 전체 영역의 너비를 조절하려면 어떻게 하죠? 메인 레이아웃이라면 HTML이나 BODY 태그에 CSS(WIDTH)를 적용하는 방법이 쉽고 논리적이지만, 예상치 못한 문제(IE에서의 전혀 다른 동작, margin 등의 발생)들이 자주 발생합니다.

예 사실입니다만, 확실한 버그로는 많아봐야 5가지 정도 될까요? 그것도 간단한 한줄, 두줄 코드들로 고칠수 있습니다. 지금 제작된 제 홈도 그러한 버그가 있다는거 조차 모르고 지낼때에 만들어진 홈입니다. 특별한 버그를 제가 발견치 못했네요. 누구라도 손쉽게 더 간편한 벙법니다. 제가 그 포스팅에서 확실치 못한 설명이 있었다면 제 잘못이겠지만 테이블이 레이아웃에서 div보다 낫다는건 약간 이기기 힘든 토론이시겠습니다.

Quote:
이 글을 읽는 분들은 경험적으로 알고 계시겠지만, 테이블을 욕하는 이유는 HTML 문서가 얼마나 구조적으로 짜여졌는가의 문제이며, 테이블이 느리고 복잡(하다고 주장)한 것은 근본적인 문제가 아닙니다. 이 문제가 해결된다면 유지보수하기 쉬운 쪽은 오히려 테이블 레이아웃 쪽입니다.

음,, 전혀 처음 듣는 이야기군요. 오히려 근본적인 테이블의 문제는 유지보수라고 생각합니다만,, xhtml, css 를 쓰면서 유지보수의 장점이 최고라고 생각해 왔습니다. 제가 직접 많은 사이트들을 제작해 보면서 겪은 일입니다,, 테이블이 복잡하지않다고 생각되신다면 xhtml은 거의 장난으로 보이실겁니다.
offree의 이미지

CSS 의 사용은 내용(html) 과 디자인(css) 분리의 의미만으로도 충분한 가치를 한다고 봅니다.

그런데, css 를 훌륭히 지원하는 WYSWYG 웹에디터는 어떤것이 좋을까요?
그냥 직접 코딩하는 것이 나은가요?

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

byung82의 이미지

mmx900 wrote:
요 몇년새 테이블을 버리라는 압박을 자주 받는군요. 위의 주제에 관한 제 결론은 문서(화면)의 구조를 생각하는 한 테이블 레이아웃 + DIV, P등 각종 태그와 + CSS 를 필요한 대로 써도 된다는 겁니다. 용도에 맞게 쓰는 것이 최선이긴 하지만 테이블을 표에만 쓰라니, 말도 안 됩니다. :lol: 스윙의 레이아웃 매니저를 생각해 보면, UI 디자인을 위해 이만한 녀석도 보기 드물다는 것을 인정하지 않을 수 없습니다.

보충 설명 들어갑니다.

1. 테이블 레이아웃을 모두 Div로 바꿔서 쓸 여력이 되는 사람이면 테이블 레이아웃을 정리하는 쪽이 훨씬 낫습니다.(물론 그 과정에서, CSS 사용으로 가독성의 적이라 할 수 있는 border=0, cellspacing=0 따위의 요소는 제거되고, 불필요한 단일 TD의 테이블 등은 DIV나 P로 바뀌겠지요) 겹겹이 쌓인 inner table이 문제가 되는 것도 대개는 문서 구조따위는 생각치도 않고 무작정 디자인만 맞추려다가 필요없는 테이블이 몇배나 늘어나게 되어 생기는 것입니다. Table을 억지로 CSS로 바꾸다가 삽입하게 되는 수많은 플로팅, 포지셔닝 요소들이야말로 후에 소스를 전혀 고치지 못하게 만드는 진짜 '재앙'이 될 가능성이 높습니다. 거기에 IE에서 정상 동작하도록 만드는 추가 삽질을 생각하면 으... 이 글을 읽는 분들은 경험적으로 알고 계시겠지만, 테이블을 욕하는 이유는 HTML 문서가 얼마나 구조적으로 짜여졌는가의 문제이며, 테이블이 느리고 복잡(하다고 주장)한 것은 근본적인 문제가 아닙니다. 이 문제가 해결된다면 유지보수하기 쉬운 쪽은 오히려 테이블 레이아웃 쪽입니다.

2. 위에 언급된 '테이블은 이제 그만 쉬어야 할 때'라는 글에서, 테이블 레이아웃과 DIV 레이아웃의 비교는 부적절해 보입니다. 변환(?)에서 TABLE, TR태그는 무시되었기 때문입니다. 저중 한 줄에 동일한 높이를 적용하려면 어떻게 해야 할까요? 한 행을 이루는 DIV들을 감싸거나 동일한 클래스를 부여해야 하는데 과연 테이블보다 낫다고 할 수 있을까요? DIV들이 있는 전체 영역의 너비를 조절하려면 어떻게 하죠? 메인 레이아웃이라면 HTML이나 BODY 태그에 CSS(WIDTH)를 적용하는 방법이 쉽고 논리적이지만, 예상치 못한 문제(IE에서의 전혀 다른 동작, margin 등의 발생)들이 자주 발생합니다.

또 해당 예제에서만 보더라도,

...
<div style="float:left;"></div>
<div style="clear:both;"></div>
...

무척 비직관적이고, 수정시 세심한 고려가 필요한 부분입니다. 이것이 테이블보다 낫다는 생각은 별로 들지 않습니다.

3. 현 시점에서 vertical-align 속성은 TD에서만 정상 동작합니다. IMG 태그와 같이 쓰는 등의 꽁수를 쓰지 않고 DIV에서 사용할 방법은 없습니다.

출근 시간에 쫓기느라 여기까지만 씁니다. 혹 문제가 있다면 지적 해주세요.

^^;

저건 설명하시는분이 잘못하신것 입니다.

IE까지 지원때문에 적은것 같습니다.

순수 CSS 2.0이라면

다음과 같이 하면 됩니다.

<div style="display:table-row">
<div style="display:table-cell">테스트1</div>
<div style="display:table-cell">테스트2</div>
<div style="display:table-cell">테스트3</div>
</div>
<div style="display:table-row">
<div style="display:table-cell">테스트4</div>
<div style="display:table-cell">테스트5</div>
</div>

실제 이코드는 불여우 1.04에서 동작 확인을 했습니다.

그럼

아흑 오타 수정했습니다.

익명 사용자의 이미지

언급하신 사이트에 들어가 보았습니다. 예쁘군요. 소스도 보고 lynx로도 들어가 보았지만 애용하는 수정의 템플릿이나 제가 만들어 둔 것들도 크게 다르지 않아서 놀랍거나 하지는 않습니다 :oops:

두서없는 글이었기는 했지만 제 글은

mmx900 wrote:
위의 주제에 관한 제 결론은 문서(화면)의 구조를 생각하는 한

즉 "화면(UI) 정의" 관점에서 볼 때에 DIV+CSS와 TABLE을 쓰는 것 중 어느것이 나은가 하는 것이었습니다. 좀더 정확히는 ".psd"파일을 ".html"로 변환하는 과정에서입니다.

(우스꽝스럽지만 이런 작업을 해야 하는 상황이 없지 않습니다. 저역시 웹 페이지 디자인하는 데 Fireworks의 캔버스에서 출발합니다. 종종 positioning, opacity, z-index 속성과 svg를 이용해 1:1 변환하는 프로그램이 있으면 좋겠다 생각합니다)

화면의 메뉴, 컨텐츠, 카피라잇 등을 구획화(div, td + id, class)하고, 그것을 웹 브라우저에 보여지는 화면상에 배치하는 데에 레이아웃 매니저처럼 table을 사용하면 구현 시간과 구조화, 소스 코드의 가독성 및 유지 보수 시간 모두에서 좋은 결과를 얻을 수 있다는 게 제 생각입니다. 이렇게 하면 lynx등에서 보여지는 데도 큰 문제가 없으므로, 접근성도 갖추고 있습니다. 반면 무작정 화면의 Table을 모두 제거하려고 들면 오히려 앞서 열거한 많은 문제에 직면할 수 있습니다.

한편으론, 사실 lynx나 시각 장애인을 위한 reader, PDA 등을 모두 고려하려면 컨텐츠를 분리하고, 페이지를 각각 생성하는 게 낫지 않겠습니까? xml + xslt 형태로 말입니다. 그리고 이런 글(CSS의 필요성에 대해 논하는)이 올라올 때마다많은 분들이 문서의 구조화를 말씀하시는데, 다른 분들은 '문서가 구조화되서 좋은점'이 뭐라고 생각하시는지 한번 듣고 싶습니다. 다른 생각이 있어서가 아니라, 그저 궁금해서 그럽니다.

정태영 wrote:

vertical-align 문제는 해결되야 할 문제라고 생각합니다만....

div 로 충분히 할 능력이 된다면 table 로 레이아웃을 하는게 더 낫지는 않습니다 ... 너무나도 유명한 css xen garden 같은 곳을 links 라던가 lynx 등의 텍스트 브라우져로 보신 적이 혹시 있으신 지 모르겠군요... (links 는 테이블을 지원하기도 합니다만...)

첨부화일로 css xen garden 을 links로 연 모습을 보여드리죠 ...

div , p 등으로 제목 문단 등이 정리되어 있는 잘 정리된 문서라는 게 확 들어오지 않으시나요?

모양은 css로 내용은 html 로... 이 원칙만 지켜진다면... html 이라는 매체를 통해 핸드폰에서 혹은 pda... 아니라면 인터넷 단말기 등에서 똑같은 내용의 잘 정리된 문서들을 아주 잘 열람할 수 있습니다... 물론 모양은 각 접속 장치에 따라서 다르게 보여지겠지만 말이죠...

이게 world wide web 컨소시움에서 우리가 가야할 길이라고 말하고 있는 universal access 의 한 예가 아닐까 싶습니다...

익명 사용자의 이미지

HTML 자체가 그렇게 이상적으로 구조화된 형태는 아니라고 봅니다. 구조화된 문서를 지향한다하는 docbook 같은 것에 비해서는 더 그렇구요. 실제로 문서의 모양으로 문서 구조를 표현하는 경우가 많은데 이상적으로 구조화된 문서라면 태그 자체가 모양을 기술하는 부분은 완전히 배제되고 단지 문서의 논리적 구조만이 태그로 구분되어 있어야죠(지향하는바는 TeX와 흡사한면도 있지만 TeX도 실제로 완전히 구조만을 기술한다고 보기는 어렵죠) 현재 HTML+CSS의 가장 큰 장점은 구조화라기 보다는 내용과 디자인의 최대한의 분리라고 봅니다 디자인을 바꿀꺼면 단지 CSS 수정만으로 전체를 바꿀 수 있으니까요.

mmx900의 이미지

일모리 wrote:
Quote:
에 언급된 '테이블은 이제 그만 쉬어야 할 때'라는 글에서, 테이블 레이아웃과 DIV 레이아웃의 비교는 부적절해 보입니다. 변환(?)에서 TABLE, TR태그는 무시되었기 때문입니다. 저중 한 줄에 동일한 높이를 적용하려면 어떻게 해야 할까요? 한 행을 이루는 DIV들을 감싸거나 동일한 클래스를 부여해야 하는데 과연 테이블보다 낫다고 할 수 있을까요?

정말 그 비교가 부적절한가요? 비교가 워낙에 극단적으로 간단히 적힌것이라서 가능한 말씀입니다만, 정확하게 각각의 모든 장 단점을 비교하게 된다면 테이블은 전혀 이길수 없는 토론입니다. 테이블의 nesting 으로 다닥붙어 복잡하게 레이아웃으로 형성된것이라면 div 로 홈페이지를 제작해 본 사람이라면 어느쪽이 더 편한지는 누구라도 알만한 사실입니다. 비교가 비록 부적절할지라도 테이블보다 div가 더 좋다고 자신있게 확실히 말할수 있네요.

테이블을 몇겹으로 nesting 해서 써야만 원하는 디자인을 만들 수 있는 사람이라면 css는 정말 최악으로 만들어 내겠지요. 그래서 '재앙'이란 표현을 썼고, Table을 먼저 고치란 말을 했습니다. 설마 table안에 tr, td를 넣는 것만으로 '다닥 붙어 복잡하게'라고 하시는 건 아니겠지요?

좋은 HTML 소스 만드는 사람 != TABLE 안쓰고 DIV,CSS만 쓰는 사람 이런 생각입니다.

일모리 wrote:
Quote:
DIV들이 있는 전체 영역의 너비를 조절하려면 어떻게 하죠? 메인 레이아웃이라면 HTML이나 BODY 태그에 CSS(WIDTH)를 적용하는 방법이 쉽고 논리적이지만, 예상치 못한 문제(IE에서의 전혀 다른 동작, margin 등의 발생)들이 자주 발생합니다.

예 사실입니다만, 확실한 버그로는 많아봐야 5가지 정도 될까요? 그것도 간단한 한줄, 두줄 코드들로 고칠수 있습니다. 지금 제작된 제 홈도 그러한 버그가 있다는거 조차 모르고 지낼때에 만들어진 홈입니다. 특별한 버그를 제가 발견치 못했네요. 누구라도 손쉽게 더 간편한 벙법니다. 제가 그 포스팅에서 확실치 못한 설명이 있었다면 제 잘못이겠지만 테이블이 레이아웃에서 div보다 낫다는건 약간 이기기 힘든 토론이시겠습니다.

아, 그 포스팅 쓰신 분이었군요. 반갑습니다. :-)

제 경우 HTML이나 BODY 태그에 WIDTH를 먹이는 것들까지는 제 수준에서 해결이 가능한데, 그렇게 가로 너비가 지정된 BODY를 몇 % 단위로 쪼개려니 너비가 IE와 Moz에서 너무 다르게 찍혀 버리더군요. Table을 딱 1단계만 쓰면 완전하게 해결 되는 문제였는데 말입니다. 제 경우 표 형태를 염두에 두고 페이지를 디자인 하고 있으니 표에 표 쓰는게 뭐 이상하냐 싶어서, 결국 그냥 Table 태그를 썼습니다. IE7처럼 컴포넌트로 박지 않는 이상 IE와 Moz의 간극을 메우는 데 너무 많은 코드를 쓰고 싶지도 않았구요. (나중에 CSS를 볼때 논리적으로 이해가 가지 않아서, 지워버렸다가 낭패를 본다거나, 알게 모르게 다른 레이아웃에도 영향을 미치고 있어서 지우지 못하게 된다거나, 등.)

언제 기회가 나면 IE와 Moz를 동일 선상에 맞춰놓고 페이지를 짤 수 있는 CSS 프레임웍(?)을 만들어보고 싶군요.

일모리 wrote:
Quote:
이 글을 읽는 분들은 경험적으로 알고 계시겠지만, 테이블을 욕하는 이유는 HTML 문서가 얼마나 구조적으로 짜여졌는가의 문제이며, 테이블이 느리고 복잡(하다고 주장)한 것은 근본적인 문제가 아닙니다. 이 문제가 해결된다면 유지보수하기 쉬운 쪽은 오히려 테이블 레이아웃 쪽입니다.

음,, 전혀 처음 듣는 이야기군요. 오히려 근본적인 테이블의 문제는 유지보수라고 생각합니다만,, xhtml, css 를 쓰면서 유지보수의 장점이 최고라고 생각해 왔습니다. 제가 직접 많은 사이트들을 제작해 보면서 겪은 일입니다,, 테이블이 복잡하지않다고 생각되신다면 xhtml은 거의 장난으로 보이실겁니다.

어떻게 짜여진 테이블인가의 문제지요. 1번 답변으로 충분하다 여겨집니다.

덧. 2칸 위에 '언급하신 사이트에...'로 시작하는 글 제가 쓴 겁니다. kldp 와서 처음 로그인 풀림을 경험하는군요. ~_~

Setzer Gabbiani

익명 사용자의 이미지

테이블 레이아웃의 가장 큰 문제는 웹문서의 근간을 흩트려 놓는 것이지요.

세계 모든 곳에서 쉽고 빠르게 접근할 수 있는 웹과 웹문서에 취지를 생각해볼때, 테이블 레이아웃은 웹브라우저 이외에 문서접근을 힘들게 합니다.

올바른 (x)html로 마크업하고 css로 모양을 꾸민다면, 그 자체만으로도 웹문서의 접근성이 향상됩니다.

pda나 핸드폰에서 웹페이지를 볼 수 있으며, 스크린리더기를 사용하는 시각장애인도 웹페이지를 알아볼(들을) 수 있게됩니다.

xhtml과 css의 정신을 생각해야 한다고 생각합니다.

테이블 레이아웃은 90년대 중후반의 침체된 웹디자인 시장을 구원했다는 것으로 목적을 다했습니다. W3C의 CSS2 공표와 함께 수많은 최근 웹브라우저(IE6은 2001년판 구식이죠)들의 지원은 웹문서를 테이블 레이아웃으로 만들어야 할 의미를 없앴습니다.

이제 테이블 태그는 본연의 목적인 자료의 정리(db형식으로 나열)에 사용돼야 합니다.

khris의 이미지

전, 테이블 태그는 테이블이란 이름만으로도 레이아웃에는 쓰이지 말아야 한다고 생각합니다.

테이블은 어디까지나 자료정리용이지 않습니까?

레이아웃을 목적으로 만들어진것이 있음에도 불구하고 쓰지 않는것은 별로 바람직하다고 생각치 않습니다.

mmx900 wrote:

제 경우 HTML이나 BODY 태그에 WIDTH를 먹이는 것들까지는 제 수준에서 해결이 가능한데, 그렇게 가로 너비가 지정된 BODY를 몇 % 단위로 쪼개려니 너비가 IE와 Moz에서 너무 다르게 찍혀 버리더군요. Table을 딱 1단계만 쓰면 완전하게 해결 되는 문제였는데 말입니다. 제 경우 표 형태를 염두에 두고 페이지를 디자인 하고 있으니 표에 표 쓰는게 뭐 이상하냐 싶어서, 결국 그냥 Table 태그를 썼습니다. IE7처럼 컴포넌트로 박지 않는 이상 IE와 Moz의 간극을 메우는 데 너무 많은 코드를 쓰고 싶지도 않았구요.

%단위로 쪼개거나 기타 다른 수치를 적용하여 레이아웃이 달리 보이는것은 테이블도 동일합니다.

오히려 테이블쪽이 문제가 크지 않나요?

mmx900 wrote:
(나중에 CSS를 볼때 논리적으로 이해가 가지 않아서, 지워버렸다가 낭패를 본다거나, 알게 모르게 다른 레이아웃에도 영향을 미치고 있어서 지우지 못하게 된다거나, 등.)

CSS를 제대로 사용한 페이지에서는 그런 mmx900님께서 말씀하시는 논리오류 (?) 나 다른 레이아웃에 영향을 미쳐서 지울수없다거나 하는 일은 일어나지 않습니다.

앞으로 CSS는 권장되어야하고, 테이블 레이아웃은 지양되어야된다고 생각합니다.

───────────────────────
yaourt -S gothick elegant
khris'log

지리즈의 이미지

이 문제는 본질적으로 개체지형적 프로그래밍이 나은가 아니면,
절차적 프로그래밍이 나은가와 같은 맹락입니다.

XML,CSS 모두 상속과 유연성확보이라는 특성때문에,
개체지향적인 면을 갖지요.

하지만, 역시 개체지향이 가지는 문제점도 가집니다.
즉 좋은 분석과 설계가 필요하다는 것이지요.
만약 초반에 분석과 설계에 문제가 있다면,
수반되는 문제점이 매우 크다는 점입니다.

물론 좋은 구현이라는 것은 분명 존재합니다.
하지만, 디자인이라는 것은 역시 비용이 따르기 때문에 쉽지 않고,
오히려 구현보다 그 느낌에 가치를 두는 부분이지요.

자자..
디자인을 누가 하는지를 주변을 한번 돌아봐주시길 바라고,
(혹시 눈이 마주친 디자이너 아가씨에게 가볍게 미소를 지어주시고)
누가 그 디자인을 보는지도 한번 더 생각해주시길 바랍니다.

사실상, 공은 디자이너나 프로그래머가 아닌,
드림위버를 만드는 매크로미디어사를 막 인수한 adobe사에게
넘어갔다는 생각이 드는군요.

There is no spoon. Neo from the Matrix 1999.

clagh의 이미지

글쓴이 님이 멀리 내다보고 어느정도 맞았다는게 느껴지네요.

요즘 웹표준으로 기정사실화 되고 있는 HTML5를 보면 테이블이 더 이상 레이아웃에 설 자리는 없지요.