div.. 앞으로 공부할게 많아질듯 이해하기가 참 쉬웠던 글! 트랙백 클릭하세요!…

완벽한 사회라면 권고안대로 브라우저들이 빠르게 개발되고 웹개발자들이 새로운 기술을 빠르게 문제없이 적용시키는 것이겠지만 이것이 불가능한 현실에서는 이득과 손실을 따져보아야 합니다.

다시 말하면 코더의 혹은 소위 퍼블리셔 들의 역량에 따라 실력에 맞추어 개발되어야 하는 것이죠. 표준에 대한 바른 이해와 뛰어난 적응력을 갖추었다면 그 어느때 보다도 유연하며 변화가 단시간에 가능한 코딩이 나오겠지만 그렇지 못하다면, 즉 오히려 충분한 이해가 없는 상태에서의 ‘표준’ 코딩을 테이블 코딩의 대체방법으로 사용한다면 역효과를 불러올 뿐입니다.

2005년도에 이 글이 쓰여졌을 무렵에는 웹표준 이라는 단어가 생소했을 시기이니 경각심을 어느정도 불러일으키자는 목적에서 씌여졌었습니다. 이제 웹표준을 모르면 어색해지는 웹이 되어가니 어느정도 좋은 역할을 한 글 같습니다.

지금 이곳이 업글상태라 경황없이 마구 답변글을 썼으니 이해바랍니다.

테이블이나 DIV를 코딩 할 때
정규화 되지 않은(불필요하게 테이블 테그 사용)
소스가 아닌 이상

정규화 된 테이블을 쓰나 div를 쓰나 저사양을 고려 했을 때도 처리 속도상 큰 차이가 없기 때문에

소스 형상 관리를 통한 개발시 서로 잘 아는 레이아웃 코딩이 테이블 방식이면 굳이 학습 목적이 아닌 이상 div를 사용하지 않는 것이 생산성에 기여를 하겠지요.

실제 DOM를 이용한 build time으로 테그를 엄청 많이 생성하는 특수한 웹싸이트에서도 속도 향상을 위한 정규화 작업에서도 이런 부분이 고려 대상이 될 수 없었습니다.

일반적으로 테이블을 가지고 레이아웃 구성을 할 수 있는 부분은 div로 테이블을 만들 때 일반적인 사항이 특별한 노하우를 가지지 않으면 짤 수 없는 형태로 전락되는 부분도 발생하는 헤프닝도 생겼고요, DTD까지 선언하여 코딩에 고생하는 디자이너 분들도 많이 보았습니다.

즉… DIV를 통한 테이블 제작,
적용 구성과 사용자 이해 정도에 따라
전체 사용, 테이블과 적절히 사용, 테이블만 사용를 고려해 보는 것이 바람직한 것이 아닐까 합니다.

Div를 사용하여 레이아웃을 짜니, FF나 IE7에서는

멀쩡하던것이.. IE6에서는 완전 골머리네요.

우리나라 IE6공화국에서 Table없이 짠다는게

머리가 아프네요.. 아 iE6 너무 싫네요.

감사합니다~~~~

최진희// 한글폰트는 애플고딕체, 맑은 고딕체, 굴림, sans-serif 순서대로 적용되게 되어있습니다.

근데 별개로 궁금한것이 있는데요.

이 블로그의 한글 폰트는 어떻게 구현되고 있는건가요? 굴림, 돋움은 아닌것 같은데;;