HTML 레이아웃에 테이블을 사용하지 않는 이유는 무엇입니까? [닫은]

HTML 레이아웃에 테이블을 사용해서는 안된다는 일반적인 견해 인 것 같습니다 .

왜?

나는 이것에 대한 좋은 주장을 본 적이 없다. 일반적인 답변은 다음과 같습니다.

• 컨텐츠를 레이아웃 과 분리하는 것이 좋습니다.
  그러나 이것은 잘못된 주장입니다. 진부한 생각 . 레이아웃에 테이블 요소를 사용하는 것이 테이블 형식 데이터와 거의 관련이 없다는 것이 사실입니다. 그래서 무엇? 상사가 신경 쓰나요? 내 사용자는 신경 쓰나요?
  
  아마도 웹 페이지 관리를 유지해야하는 나와 저의 동료 개발자는 ... 테이블을 관리하기가 쉽지 않습니까? div와 CSS를 사용하는 것보다 테이블을 사용하는 것이 더 쉽다고 생각합니다 .
  
  그건 그렇고 ... 왜 div 또는 span을 사용하여 레이아웃과 테이블에서 컨텐츠를 잘 분리합니까? div만으로 좋은 레이아웃을 얻으려면 종종 중첩 된 div가 많이 필요합니다.

• 코드의 가독성
  나는 다른 방법이라고 생각합니다. 대부분의 사람들은 HTML을 이해하고 소수의 사람들은 CSS를 이해합니다.

• SEO가 테이블을 사용하지 않는 것이 좋습니다.
  왜 그렇습니까? 아무도 그것이 어떤 증거를 보여줄 수 있습니까? 또는 테이블이 SEO 관점에서 권장되지 않는다는 Google의 진술?

• 테이블이 느립니다.
  여분의 tbody 요소를 삽입해야합니다. 이것은 현대 웹 브라우저를위한 땅콩입니다. 표를 사용하면 페이지 속도가 크게 저하되는 벤치 마크를 보여주세요.

• 레이아웃 점검은 테이블없이 더 쉽습니다 . css Zen Garden을 참조하십시오 .
  업그레이드가 필요한 대부분의 웹 사이트에는 새로운 콘텐츠 (HTML)도 필요합니다. 새 버전의 웹 사이트에 새 CSS 파일 만 필요한 시나리오는 거의 없습니다. Zen Garden은 훌륭한 웹 사이트이지만 약간 이론적입니다. CSS 의 오용 은 말할 것도 없습니다 .

테이블 대신 divs + CSS를 사용하는 좋은 주장에 관심이 있습니다.

나는 당신의 주장을 하나씩 차례로 살펴보고 그 안에 오류를 보여 주려고 노력할 것입니다.

컨텐츠를 레이아웃과 분리하는 것이 좋습니다. 그러나 이것은 잘못된 주장입니다. 진부한 생각.

HTML은 의도적으로 설계 되었기 때문에 전혀 실수가 아닙니다. 요소의 오용은 완전히 의문의 여지가 없지만 (이후 다른 언어로도 새로운 관용구가 개발 되었음) 가능한 부정적인 영향이 균형을 이루어야합니다. 또한 <table>오늘날 요소 를 잘못 사용하는 것에 대한 논쟁이 없었더라도 브라우저 공급 업체가 요소에 특별한 대우를 적용하는 방식으로 인해 내일이있을 수 있습니다. 결국, 그들은“ <table>요소는 테이블 형식의 데이터만을위한 것”이라는 것을 알고 있으며, 이 사실을 사용하여 렌더링 엔진을 개선하고 프로세스에서 <table>동작 방식을 미묘하게 변경 하여 이전에 잘못 사용 된 사례를 깨뜨릴 수 있습니다.

그래서 무엇? 상사가 신경 쓰나요? 내 사용자는 신경 쓰나요?

다릅니다. 당신의 상사가 뾰족한 머리입니까? 그러면 그는 신경 쓰지 않을 것입니다. 그녀가 유능하다면, 그녀는 걱정할 것입니다. 가질 것 입니다.

아마도 웹 페이지 관리를 유지해야하는 나와 저의 동료 개발자는 ... 테이블을 유지 관리하기가 쉽지 않습니까? 테이블을 사용하는 것이 div와 CSS를 사용하는 것보다 쉽다고 생각합니다.

전문 웹 개발자의 대다수는 당신을 반대하는 것 같습니다^{[ 인용 필요 ]} . 그 테이블 은 실제로 유지 보수가 덜 용이하다는 것이 분명해야합니다. 레이아웃에 테이블을 사용한다는 것은 회사 레이아웃을 변경하면 실제로는 모든 단일 페이지를 변경한다는 의미입니다. 이것은 매우 비쌀 수 있습니다 . 반면에 CSS와 결합 된 의미 적으로 의미있는 HTML을 신중하게 사용하면 이러한 변경 사항이 CSS와 사용 된 그림에 제한 될 수 있습니다 .

그건 그렇고 ... 왜 div 또는 span을 사용하여 레이아웃과 테이블에서 내용을 잘 분리하고 있습니까? div만으로 좋은 레이아웃을 얻으려면 종종 중첩 된 div가 많이 필요합니다.

깊게 중첩 된 <div>테이블 레이아웃과 마찬가지로 안티 패턴입니다. 훌륭한 웹 디자이너는 많은 것을 필요로하지 않습니다. 다른 한편으로, 깊게 중첩 된 div조차도 테이블 레이아웃의 많은 문제가 없습니다. 실제로, 그들은 논리적으로 내용을 부분적으로 나눔으로써 의미 론적 구조에 기여할 수 있습니다.

코드의 가독성 나는 다른 방법이라고 생각합니다. 대부분의 사람들은 HTML을 이해하고 CSS는 거의 이해하지 못합니다. 더 간단합니다.

“대부분의 사람들”은 중요하지 않습니다. 전문가가 중요합니다. 전문가에게는 테이블 레이아웃이 HTML + CSS보다 더 많은 문제를 만듭니다. 메모장은 대부분의 사람들에게 더 간단하기 때문에 GVim 또는 Emacs를 사용해서는 안된다는 것과 같습니다. 또는 MS Word가 대부분의 사람들에게 더 단순하기 때문에 LaTeX를 사용해서는 안됩니다.

SEO가 테이블을 사용하지 않는 것이 좋습니다.

이것이 사실인지 모르겠으며 이것을 인수로 사용하지 않을 것이지만 논리적입니다. 검색 엔진은 관련 데이터를 검색 합니다. 테이블 형식 데이터는 물론 관련성이 있지만 사용자가 검색하는 것은 거의 없습니다. 사용자는 페이지 제목 또는 유사하게 눈에 띄는 위치에 사용 된 용어를 검색합니다. 따라서 테이블 형식 컨텐츠를 필터링에서 제외하여 처리 시간 (및 비용)을 크게 줄이는 것이 논리적입니다.

테이블이 느립니다. 여분의 tbody 요소를 삽입해야합니다. 이것은 현대 웹 브라우저를위한 땅콩입니다.

추가 요소는 테이블이 느려지는 것과 관련이 없습니다. 반면에 테이블의 레이아웃 알고리즘은 훨씬 어렵습니다. 브라우저는 종종 컨텐트 레이아웃을 시작하기 전에 전체 테이블이로드 될 때까지 기다려야합니다. 또한 레이아웃 캐싱이 작동하지 않습니다 (CSS를 쉽게 캐시 할 수 있음). 이 모든 것은 이전에 언급되었습니다.

표를 사용하면 페이지 속도가 크게 저하되는 벤치 마크를 보여주세요.

불행히도 벤치 마크 데이터가 없습니다. 이 논증에 과학적 근거가 부족하다는 것이 옳기 때문에 나는 그것에 관심을 가질 것이다.

업그레이드가 필요한 대부분의 웹 사이트에는 새로운 콘텐츠 (html)도 필요합니다. 새 버전의 웹 사이트에 새 CSS 파일 만 필요한 시나리오는 거의 없습니다.

전혀. 콘텐츠와 디자인을 분리하여 디자인 변경을 단순화 한 몇 가지 사례를 연구했습니다. 여전히 일부 HTML 코드를 변경해야하는 경우가 종종 있지만 변경 사항은 항상 훨씬 더 제한적입니다. 또한 때때로 설계 변경이 동적으로 이루어져야합니다. WordPress 블로그 시스템에서 사용하는 것과 같은 템플릿 엔진을 고려하십시오. 테이블 레이아웃은 문자 그대로이 시스템을 죽입니다. 상용 소프트웨어와 비슷한 경우를 연구했습니다. HTML 코드를 변경하지 않고 디자인을 변경할 수 있다는 것은 비즈니스 요구 사항 중 하나였습니다.

또 다른 한가지. 테이블 레이아웃은 웹 사이트의 자동 구문 분석 (화면 스크래핑)을 훨씬 어렵게 만듭니다. 결국 누가 그것을하기 때문에 사소한 것처럼 들릴 수 있습니다. 나는 놀랐다. 문제의 서비스가 데이터에 액세스 할 수있는 WebService 대안을 제공하지 않으면 화면 스크래핑이 많은 도움이 될 수 있습니다. 나는 이것이 슬픈 현실 인 생물 정보학에서 일하고 있습니다. 최신 웹 기술과 웹 서비스는 대부분의 개발자에게 도달하지 않았으며 종종 화면 스크래핑이 데이터 가져 오기 프로세스를 자동화하는 유일한 방법입니다. 많은 생물 학자들이 여전히 그러한 작업을 수동으로 수행한다는 것은 놀라운 일이 아닙니다. 수천 개의 데이터 세트

다음 은 비슷한 스레드 에서 프로그래머의 답변 입니다.

시맨틱 스 101

먼저이 코드를보고 여기서 무엇이 잘못되었는지 생각해보십시오.

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

물론 문제는 자전거가 자동차가 아니라는 것입니다. 자동차 클래스는 자전거 인스턴스에 부적절한 클래스입니다. 코드에 오류가 없지만 의미 상 올바르지 않습니다. 프로그래머에게 잘 반영되지 않습니다.

시맨틱 스 102

이제 이것을 문서 마크 업에 적용하십시오. 문서에 테이블 형식의 데이터가 필요한 경우 적절한 태그는입니다 <table>. 그러나 테이블에 탐색을 배치하면 의도 한 <table>요소의 목적을 잘못 사용하고있는 것 입니다. 두 번째 경우에는 테이블 형식의 데이터가 표시되지 않습니다 <table>. 프레젠테이션 목표를 달성하기 위해 요소를 사용하고 있습니다.

결론

방문자가 알 수 있습니까? 아뇨, 상사가 신경 쓰나요? 아마도. 프로그래머로서 코너를 자르는가? 확실한. 그러나 우리는해야합니까? 의미 적 마크 업을 사용하면 누구에게 도움이됩니까? 당신과 당신의 전문적인 명성. 이제 가서 옳은 일을하십시오.

명백한 답변 : CSS Zen Garden을 참조하십시오 . 테이블 기반 레이아웃으로 쉽게 동일한 작업을 수행 할 수 있다고 말하면 (HTML은 변경되지 않음을 기억하십시오) 반드시 레이아웃을 위해 테이블을 사용하십시오.

또 다른 중요한 두 가지는 접근성과 SEO입니다.

둘 다 어떤 순서로 정보가 표시되는지에 관심이 있습니다. 테이블 기반 레이아웃이 페이지에서 두 번째 중첩 테이블의 두 번째 행에있는 세 번째 셀에 배치되면 탐색을 페이지 상단에 쉽게 표시 할 수 없습니다.

따라서 귀하의 답변은 유지 보수성, 접근성 및 SEO입니다.

게으르지 마십시오. 배우기가 조금 더 어려워도 옳고 적절한 방법으로 행동하십시오.

이 중복 질문을 참조하십시오.

당신이 잊고있는 한 가지 항목은 접근성입니다. 예를 들어 스크린 리더를 사용해야하는 경우 테이블 기반 레이아웃도 변환되지 않습니다. 당신이 정부를 위해 일을한다면, 스크린 리더와 같은 지원 접근의 브라우저는 할 수있다 필요합니다 .

또한 귀하가 질문에서 언급 한 것 중 일부의 영향을 과소 평가한다고 생각합니다. 예를 들어, 디자이너와 프로그래머 모두 프레젠테이션과 컨텐츠를 얼마나 잘 구분하는지 완전히 인식하지 못할 수 있습니다. 그러나 일단 두 가지 역할을하는 상점에 들어 서면 장점이 더 분명해지기 시작합니다.

당신이하고있는 일을 알고 좋은 도구를 가지고 있다면 CSS는 실제로 레이아웃 테이블보다 큰 이점을 가지고 있습니다. 그리고 각 항목 자체가 포기한 테이블을 정당화 할 수는 없지만 일반적으로 가치가 있습니다.

불행히도 CSS Zen Garden은 더 이상 좋은 HTML / CSS 디자인의 예로 사용될 수 없습니다. 최근의 모든 디자인은 단면 제목에 그래픽을 사용합니다. 이 그래픽 파일은 CSS에 지정되어 있습니다.

따라서 디자인을 컨텐츠에서 제외시키는 이점을 보여주는 웹 사이트는 이제 컨텐츠를 디자인에 넣는 UNSPEAKABLE SIN을 정기적으로 수행합니다. HTML 파일의 섹션 제목이 변경되면 표시된 섹션 제목이 변경되지 않습니다.

엄격한 DIV 및 CSS 종교를 옹호하는 사람들조차도 자신의 규칙을 따를 수 없다는 것을 보여줄뿐입니다. 그것들을 얼마나 밀접하게 따르는 지에 대한 지침으로 사용할 수 있습니다.

이것은 확실한 결정은 아니지만 CSS를 사용하면 매체에 따라 동일한 마크 업을 사용하고 레이아웃을 변경할 수 있습니다. 이는 좋은 이점입니다. 예를 들어 인쇄 페이지의 경우 프린터 친화적 인 페이지를 만들지 않고도 탐색을 조용히 억제 할 수 있습니다.

레이아웃을위한 하나의 테이블은 그렇게 나쁘지 않을 것입니다. 그러나 대부분의 경우 하나의 테이블로 필요한 레이아웃을 얻을 수 없습니다. 머지 않아 2 ~ 3 개의 중첩 테이블이 있습니다. 이것은 매우 번거로워집니다.

• 읽기가 더 어렵다. 그것은 의견에 달려 있지 않습니다. 식별 표시가없는 중첩 된 태그가 더 있습니다.

• 프리젠 테이션에서 컨텐츠를 분리하는 것은 현재하고있는 일에 집중할 수 있기 때문에 좋은 것입니다. 두 가지를 혼합하면 읽기 어려운 부풀린 페이지가 나타납니다.

• 스타일 용 CSS를 사용하면 브라우저에서 파일을 캐시 할 수 있으며 후속 요청이 훨씬 빠릅니다. 이것은 거대하다.

• 테이블은 디자인에 당신을 고정시킵니다. 물론 모든 사람이 CSS Zen Garden의 유연성을 필요로하는 것은 아니지만 디자인을 조금이라도 변경할 필요가없는 사이트에서 작업 한 적이 없습니다. CSS를 사용하면 훨씬 쉽습니다.

• 테이블은 스타일을 지정하기가 어렵습니다. 유연성이별로 없습니다 (예 : 테이블 스타일을 완전히 제어하려면 HTML 속성을 추가해야합니다)

아마도 4 년 동안 비표 형식 데이터에 테이블을 사용하지 않았습니다. 나는 뒤돌아 보지 않았다.

Andy Budd의 CSS Mastery 를 읽는 것이 좋습니다 . 환상적이야.

ecx.images-amazon.com의 이미지 http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg

컨텐츠를 레이아웃과 분리하는 것이 좋습니다.
그러나 이것은 잘못된 주장입니다. 진부한 생각

HTML 테이블이 레이아웃이기 때문에 잘못된 주장입니다! 내용은 테이블 의 데이터 이고 프리젠 테이션은 테이블 자체입니다. 그렇기 때문에 CSS를 HTML에서 분리하는 것이 때때로 어려울 수 있습니다. 프리젠 테이션에서 컨텐츠를 분리하지 않고 프리젠 테이션에서 프리젠 테이션을 분리합니다! 중첩 된 div 더미는 테이블과 다르지 않습니다. 태그가 다릅니다.

HTML과 CSS를 분리하는 데 따른 다른 문제는 서로에 대한 친밀한 지식이 필요하다는 것입니다. 실제로 완전히 분리 할 수는 없습니다. HTML의 태그 레이아웃은 CSS 파일과 밀접하게 연결되어 있습니다.

테이블 대 div는 응용 프로그램의 요구에 달려 있다고 생각합니다.

우리가 직장에서 개발하는 응용 프로그램에서는 조각의 크기가 내용에 맞게 페이지 레이아웃이 필요했습니다. CSS와 DIV에서 크로스 브라우저를 작동시키기 위해 며칠을 보냈는데 그것은 악몽이었습니다. 우리는 테이블로 전환했고 모두 작동했습니다 .

그러나, 우리는 우리 제품 (웹 인터페이스를 가진 하드웨어를 판매)에 대해 매우 청중을 가지고 있으며 접근성 문제는 우리에게 문제가되지 않습니다. 스크린 리더가 왜 테이블을 잘 처리 할 수 ​​없는지 잘 모르겠지만, 이것이 개발자가 처리해야하는 방식 일지 모르겠습니다.

CSS / DIV-디자인 소년을위한 직업 일뿐입니다. DIV / CSS 문제를 디버깅하고 인터넷을 검색하여 모호한 브라우저를 사용하여 마크 업의 일부를 가져 오는 데 수백 시간이 걸렸습니다. 하나의 작은 변화를 주면 전체 레이아웃이 끔찍하게 잘못됩니다. 이 방법으로 3 픽셀을 이동시킨 다음 다른 2 픽셀을 이동하여 시간을 보내면 모두 정렬됩니다. 이것은 어떻게 든 나에게 명백한 잘못 인 것 같습니다. 당신이 순수 주의자이고 무언가가 "올바른 일이 아니다"고해서, 그것이 당신의 인생을 1000 배나 더 쉽게 만드는 경우, 모든 단계에서 n도까지 사용해야한다는 것을 의미하지는 않습니다.

그래서 나는 최소한 상업적으로 만 사용하기로 결정했지만, DIV를 올바르게 배치하기 위해 20 시간의 작업을 예상한다면, 나는 테이블을 고수 할 것입니다. 잘못 되었기 때문에 순수 주의자들을 화나게하지만 대부분의 경우 시간이 덜 들고 관리 비용이 저렴합니다. 그런 다음 순수 주의자를 기쁘게하는 대신 고객이 원하는대로 애플리케이션을 작동시키는 데 집중할 수 있습니다. 그들은 결국 청구서를 지불하고 CSS / DIV의 사용을 강요하는 관리자에 대한 나의 주장을 내립니다. 나는 단지 고객이 자신의 월급을 지불한다고 지적합니다!

이 모든 CSS / DIV 인수가 발생하는 유일한 이유는 처음에 CSS가 부족하고 브라우저가 서로 호환되지 않기 때문에 브라우저가 서로 호환되지 않기 때문에 전 세계 웹 디자이너의 절반이 일을하지 않기 때문입니다. .

Windows 폼을 디자인 할 때 컨트롤을 배치 한 후에는 컨트롤을 이동하려고 시도하지 않으므로 웹 폼 으로이 작업을 수행하려는 이유가 이상하다고 생각합니다. 나는 단순히이 논리를 이해할 수 없다. 레이아웃을 시작하여 문제가 무엇인지 확인하십시오. 디자이너가 창의력을 발휘하기를 원하기 때문에 응용 프로그램 개발자가 실제로 응용 프로그램 작동, 비즈니스 객체 생성, 비즈니스 규칙 구현, 비트 간의 고객 데이터와의 관계, 작업이 고객을 충족시키는 방법에 대해 더 관심이 있기 때문입니다. 요구 사항-당신은 알고-실제 물건처럼.

틀리지 말고 두 가지 주장이 모두 유효하지만 개발자가 양식 설계에 대한보다 쉽고 논리적 인 접근 방식을 선택했다고 비난하지 마십시오. 우리는 종종 div 위에 테이블을 사용하는 올바른 의미보다 걱정할 것이 더 중요합니다.

적절한 경우-이 토론을 바탕으로 몇 가지 기존 td 및 trs를 div로 변환했습니다. 45 분 동안 모든 것이 서로 옆에 정렬되도록 노력하면서 나는 혼란 스러웠습니다. 10 초 후 TD는 모든 브라우저에서 바로 작동합니다. 더 이상 할 일이 없습니다. 나를 이해 시키려고 노력하십시오-다른 방법으로하고 싶을 때 어떤 정당화가 가능합니까!

레이아웃이 쉬워야합니다. CSS에서 머리글과 바닥 글을 사용하여 동적 3 열 레이아웃을 얻는 방법에 대한 기사가 있다는 사실은 레이아웃 시스템이 좋지 않다는 것을 보여줍니다. 물론 당신은 그것을 작동시킬 수 있지만, 그것을하는 방법에 대한 말 그대로 온라인에 수백 개의 기사가 있습니다. 특허가 분명하기 때문에 테이블과 유사한 레이아웃에 대한 기사는 거의 없습니다. CSS에 찬성하여 표에 대해 무엇을 말하든,이 사실은 모든 것을 취소합니다. CSS의 기본 3 열 레이아웃은 종종 "성배"라고합니다.

그것이 "WTF"라고 말하지 않는다면, 당신은 정말로 kool-aid를 내려 놓아야합니다.

나는 CSS를 좋아한다. 놀라운 스타일 옵션과 멋진 포지셔닝 도구를 제공하지만 레이아웃 엔진으로는 부족합니다. 동적 그리드 포지셔닝 시스템에는 어떤 유형이 필요합니다. 크기를 먼저 몰라도 여러 축에서 상자를 정렬하는 간단한 방법입니다. <table> 또는 <gridlayout> 또는 무엇이든 호출하면 망설이지 않지만 CSS에서 누락 된 기본 레이아웃 기능입니다.

더 큰 문제는 누락 된 기능이 있다는 사실을 인정하지 않음으로써 CSS 열성 자들이 CSS를 가능한 한 억제하고 있다는 것입니다. CSS가 기본적으로 세계의 다른 모든 레이아웃 엔진과 같이 적절한 다축 그리드 위치 지정을 제공 한 경우 테이블 사용을 중단하게되어 기쁩니다. (W3C를 제외한 모든 사람이이 문제를 여러 언어로 이미 여러 번 해결했다는 것을 알고 있습니까? 다른 누구도 그러한 기능이 유용하다는 것을 부인하지 않았습니다.)

한숨. 충분한 환기. 계속해서 머리를 모래에 다시 붙입니다.

508 규정 준수 (시각적으로 잘못 인식 된 화면 판독기의 경우)에 따르면, 테이블은 화면 판독기가 기절하게 만들므로 레이아웃이 아닌 데이터를 보유하는 데만 사용해야합니다. 또는 나는 들었다.

각 div에 이름을 지정하면 CSS를 사용하여 함께 div를 모두 스킨 할 수 있습니다. 그들은 당신이 필요로하는 방식으로 앉기 위해 조금 더 고통 스럽습니다.

최근 프로젝트의 html 섹션은 다음과 같습니다.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

그리고 여기 테이블 기반 레이아웃과 동일한 코드가 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

그 테이블 기반 레이아웃에서 볼 수있는 유일한 청결은 들여 쓰기에 지나치게 열중하다는 사실입니다. 콘텐츠 섹션에 추가로 2 개의 임베디드 테이블이있을 것이라고 확신합니다.

고려해야 할 또 다른 사항 : filesizes . 테이블 기반 레이아웃이 일반적으로 CSS에 비해 두 배 크기라는 것을 알았습니다. 우리의 고속 광대역에서는 큰 문제가 아니지만 전화 접속 모뎀을 사용하는 사람들에게 있습니다.

div 기반 레이아웃이 관리, 발전 및 리팩터링하기가 더 쉽다고 덧붙이고 싶습니다. CSS를 변경하여 요소의 순서를 변경하면 완료됩니다. 내 경험상 테이블을 사용하는 레이아웃을 다시 디자인하는 것은 악몽입니다 (중첩 테이블이있는 경우 더).

코드는 의미 적 관점에서도 의미 가 있습니다.

DIV의 어떤 주장도 나에게 호의를 베풀지 않습니다.

하고 싶습니다 : 신발이 맞으면 착용하십시오.

모든 브라우저에서 일관되며 여전히 의도 한 방식으로 보이는 두세 열로 컨텐츠를 렌더링하는 훌륭한 DIV + CSS 방법을 찾는 것이 불가능하지는 않지만 어렵다는 점은 주목할 가치가 있습니다.

이것은 대부분의 레이아웃에서 테이블에 대한 균형을 약간 유지하고, 나는 그것들을 사용하는 것에 대해 죄책감을 느낍니다. TABLEs를 사용하는 것이 더 쉽고 빠릅니다. 나는 시간당 지불되지 않으므로 테이블이 저렴합니다.

CSS 레이아웃은 내용이 자연스러운 순서로 제공되고 스타일 시트가없는 경우에는 일반적으로 내게 필요한 옵션에 훨씬 적합합니다. 또한 테이블 기반 레이아웃으로 어려움을 겪는 것은 스크린 리더뿐만 아니라 모바일 브라우저가 페이지를 올바르게 렌더링하는 것을 훨씬 어렵게 만듭니다.

또한 div 기반 레이아웃을 사용하면 인쇄 된 페이지에서 머리글, 바닥 글 및 탐색을 제외하는 것과 같은 인쇄 스타일 시트를 사용하여 멋진 작업을 쉽게 수행 할 수 있습니다. 테이블 기반 레이아웃.

div를 사용하여 테이블보다 컨텐츠를 레이아웃에서 분리하는 것이 더 쉽다고 의심되는 경우 CSS Zen Garden 의 div 기반 HTML을 살펴보십시오. 스타일 시트를 변경하여 레이아웃을 크게 변경하는 방법을 살펴보고 가능한지 여부를 생각하십시오. HTML이 테이블 기반 인 경우 동일한 다양한 레이아웃을 얻을 수 있습니다. 테이블 기반 레이아웃을 수행하는 경우 CSS를 사용하여 셀의 모든 간격과 패딩을 제어하지 않을 것입니다. 플로팅 div 등을 사용하는 것이 가장 쉽다는 것을 거의 확실하게 발견했습니다). CSS를 사용하여 모든 것을 제어하지 않고 테이블이 HTML에서 왼쪽에서 오른쪽으로, 위에서 아래로 순서를 지정한다는 사실 때문에 테이블은 레이아웃이 HTML에서 매우 고정되어 있음을 의미합니다.

현실적으로 div를 조금 변경하지 않고 div 및 CSS 기반 디자인의 레이아웃을 완전히 변경하는 것이 매우 어렵다고 생각합니다. 그러나 div 및 CSS 기반 레이아웃을 사용하면 다양한 블록 사이의 간격 및 상대 크기와 같은 항목을 훨씬 쉽게 조정할 수 있습니다.

이것이 논쟁의 여지가 많다는 사실은 W3C가 시도 할 레이아웃 디자인의 다양성을 예상하지 못한 것에 대한 증거이다. 의미 론적으로 친숙한 레이아웃에 divs + css를 사용하는 것은 훌륭한 개념이지만 구현의 세부 사항이 너무 복잡하여 실제로 창의적 자유를 제한합니다.

회사의 사이트 중 하나를 테이블에서 div로 전환하려고 시도한 결과, 작업 시간을 완전히 없애고 다시 테이블로 돌아가는 것은 매우 어려웠습니다. 수직 정렬을 제어하기 위해 내 div와 씨름하려고하면이 논쟁이 계속되는 한 결코 흔들리지 않을 주요 심리적 문제로 저를 저주했습니다.

사람들이 단순한 설계 목표 (수직 정렬과 같은)를 달성하기 위해 복잡하고 추악한 해결 방법을 자주 찾아야한다는 사실은 규칙이 거의 유연하지 않다는 것을 강력하게 시사합니다. 사양이 충분하면 왜 SO와 같은 유명 사이트가 테이블과 다른 해결 방법을 사용하여 규칙을 구부려 야합니까?

레이아웃에 테이블 요소를 사용하는 것이 테이블 형식 데이터와 거의 관련이 없다는 것이 사실입니다. 그래서 무엇? 상사가 신경 쓰나요? 내 사용자는 신경 쓰나요?

Google 및 기타 자동화 시스템 은 주의를 기울여야하며 여러 상황에서 마찬가지로 중요합니다. 비 지능적 시스템이 시맨틱 코드를 ​​분석하고 처리하기가 더 쉽습니다.

일부 응용 프로그램에서 생성 된 6 개의 중첩 테이블 계층이 포함 된 웹 사이트에서 작업해야하고 유효하지 않은 HTML을 생성 한 경우 사소한 변경으로 인해 문제를 해결하는 데 실제로 3 시간이 걸렸습니다.

이것은 물론 엣지 케이스이지만 테이블 기반 디자인은 유지할 수 없습니다. CSS를 사용하는 경우 스타일을 분리하여 HTML을 수정할 때 중단에 대해 걱정할 필요가 없습니다.

또한 JavaScript로 시도하십시오. 한 테이블 셀을 한 테이블에서 다른 테이블의 다른 곳으로 옮깁니다. div / span이 복사-붙여 넣기 방식으로 작동하는 곳에서는 수행하기가 다소 복잡합니다.

"내 상사가 돌봐"

내가 네 상사라면 당신은 걱정할 것입니다. ;) 당신이 당신의 인생을 소중히 생각합니다.

레이아웃 유연성
많은 썸네일이있는 페이지를 만들고 있다고 가정합니다.
DIV :
각 썸네일을 DIV에 넣고 왼쪽으로 띄우면 그 중 10 개가 행에 맞을 수 있습니다. 창을 더 좁히고 BAM-6 행 또는 2 또는 그 이상으로 적합합니다.
표:
행에 몇 개의 셀이 있는지 명시 적으로 말해야합니다. 창이 너무 좁 으면 사용자가 가로로 스크롤해야합니다.

유지 보수성
위와 동일한 상황. 이제 세 번째 줄에 세 개의 축소판을 추가하려고합니다.
DIV :
추가합니다. 레이아웃이 자동으로 조정됩니다.
표 : 새 셀을 세 번째 행에 붙여 넣습니다. 죄송합니다! 이제 항목이 너무 많습니다. 그 줄에서 일부를 잘라 네 번째 줄에 놓습니다. 이제 항목이 너무 많습니다. 해당 행에서 일부를 잘라 내십시오 ... (etc)
( 물론 서버 측 스크립팅으로 행과 셀을 생성하는 경우 문제가되지 않습니다. )

보트가 항해했다고 생각합니다. 업계가 취한 방향을 살펴보면 CSS와 Open Standards가 그 토론의 승자임을 알 수 있습니다. 결과적으로 양식을 제외한 대부분의 HTML 작업에는 디자이너가 테이블 대신 div를 사용합니다. 나는 CSS 전문가가 아니지만 그 방식대로 어렵습니다.

또한 표는 모바일 브라우저에서 제대로 렌더링되지 않습니다. 물론, 아이폰에는 킥 브라우저가 있지만 모든 사람이 아이폰을 가지고 있지는 않습니다. 테이블 렌더링은 최신 브라우저의 땅콩이 될 수 있지만 모바일 브라우저의 수박입니다.

나는 개인적으로 많은 사람들이 너무 많은 <div>태그를 사용한다는 것을 알았지 만 적당히 사용하면 매우 깨끗하고 읽기 쉽습니다. 사람들은 테이블보다 CSS를 읽는 데 어려움을 겪습니다. 아마도 '코드'의 관점에서; 그러나 내용을 읽는 관점에서 (보기> 소스) 테이블보다 스타일 시트로 구조를 이해하는 것이 훨씬 쉽습니다.

테이블에 익숙한 것 같습니다. 레이아웃을 표에 넣으면 해당 레이아웃으로 제한됩니다. CSS를 사용하면 비트를 움직일 수 있습니다 .http : //csszengarden.com/ 아니요, 레이아웃에는 중첩 된 div가 많이 필요하지 않습니다.

레이아웃과 적절한 의미 체계를위한 테이블이 없으면 HTML이 훨씬 깔끔 해져 읽기 쉽습니다. 왜 CSS를 이해할 수없는 사람이 CSS를 읽으려고합니까? 그리고 누군가 자신이 웹 개발자라고 생각하면 CSS를 잘 이해해야합니다.

SEO의 이점은 가장 중요한 콘텐츠를 페이지보다 높이고 콘텐츠 대 마크 업 비율을 높이는 기능에서 비롯됩니다.

http://www.hotdesign.com/seybold/

• 규정 준수-스크린 리더가 마크 업을 이해할 수있는 기능.
• 렌더링 대기-테이블이 </table>요소 의 끝에 도달 할 때까지 브라우저에서 렌더링되지 않습니다 .

시맨틱 마크 업에 대한 전체 아이디어는 레이아웃을 포함하는 마크 업과 프리젠 테이션의 분리입니다.

Div는 테이블을 대체하지 않고 컨텐츠를 관련 컨텐츠 블록 (,)으로 분리하는 데 자체적으로 사용합니다. 기술이없고 테이블에 의존하는 경우 원하는 레이아웃을 얻기 위해 내용을 셀로 분리해야하는 경우가 있지만 의미 적 마크 업을 사용할 때 프리젠 테이션을 달성하기 위해 마크 업을 터치 할 필요는 없습니다. 이는 정적 페이지가 아닌 마크 업이 생성 될 때 매우 중요합니다.

개발자는 레이아웃을 의미하는 마크 업 제공을 중단해야 콘텐츠를 표현할 수있는 기술을 보유한 직원이 업무를 수행 할 수 있으며 개발자는 프레젠테이션이 변경 될 때 코드를 다시 변경하지 않아도됩니다.

이것은 실제로 'div가 테이블 레이아웃보다 나은지'에 관한 것이 아닙니다. CSS를 이해하는 사람은 '레이아웃 테이블'을 사용하여 모든 디자인을 매우 간단하게 복제 할 수 있습니다. 진정한 승리는 HTML 요소를 사용하는 것입니다. 표가 아닌 데이터에 테이블을 사용하지 않는 이유는 정수를 문자열로 저장하지 않는 것과 같은 이유입니다. 기술을 목적에 맞게 사용할 때 기술이 훨씬 쉽게 작동합니다. 레이아웃을 위해 테이블을 사용해야 할 필요가 있다면 (1990 년대 초의 브라우저 단점으로 인해) 지금은 그렇지 않습니다.

테이블 레이아웃을 사용하는 도구는 레이아웃을 만드는 데 필요한 코드의 양으로 인해 엄청나게 무거워 질 수 있습니다. SAP의 Netweaver Portal은 기본적으로 TABLE을 사용하여 페이지를 레이아웃합니다.

내 현재 공연의 프로덕션 SAP 포털에는 HTML의 무게가 60K 이상이고 페이지 내에서 세 번 7 테이블 깊이가있는 홈 페이지가 있습니다. Javascript에 비슷한 테이블 문제가있는 16 개의 iframe을 잘못 사용하고 CSS가 과도하게 무거운 페이지를 추가하면 페이지 크기가 5MB 이상입니다.

대역폭을 사용하여 사용자와의 활동을 수행 할 수 있도록 시간을내어 페이지 가중치를 낮추는 것이 좋습니다.

CSS와 div를 알아낼 가치가 있으므로 중앙 콘텐츠 열이 페이지 레이아웃에서 사이드 바보다 먼저로드되고 렌더링됩니다. 그러나 떠 다니는 div를 사용하여 로고를 일부 스폰서 텍스트와 수직으로 정렬하는 데 어려움을 겪고 있다면 테이블을 사용하고 삶을 계속하십시오. 젠 가든 종교는 단지 돈을 많이 쓰지 않습니다.

컨텐츠를 프리젠 테이션에서 분리한다는 아이디어는 애플리케이션을 분할하여 다른 종류의 작업이 다른 코드 블록에 영향을 미치도록하는 것입니다. 이것은 실제로 변경 관리에 관한 것입니다. 그러나 코딩 표준은 현재 코드 상태를 피상적 인 방식으로 만 검사 할 수 있습니다.

"프레젠테이션에서 컨텐츠를 분리"하기 위해 코딩 표준에 의존하는 애플리케이션의 변경 로그는 수직 사일로에서 병렬 변경 패턴을 보여줍니다. "content"에 대한 변경에 항상 "presentation"에 대한 변경이 수반되는 경우 분할은 얼마나 성공적입니까?

코드를 생산적으로 분할하려면 Subversion을 사용하고 변경 로그를 검토하십시오. 그런 다음 가장 간단한 코딩 기술 (div, 테이블, JavaScript, 포함, 함수, 객체, 연속체 등)을 사용하여 변경 내용이 간단하고 편안한 방식으로 맞도록 응용 프로그램을 구성하십시오.

테이블을 사용하고 코딩하는 데 많은 시간이 걸리는 사이트를 유지 관리하는 것이 좋습니다. 떠 다니는 div가 두려운 경우 코스로 이동하십시오. 그것들은 이해하기 어렵지 않으며, 약 100 배 더 효율적이고 엉덩이 통증이 백만 배나 줄어 듭니다.

테이블로 레이아웃을 고려하는 사람은 테이블을 유지하는 것이 더 나을 것으로 기대하지 않습니다. 웹 사이트를 렌더링하는 가장 좋은 방법입니다. 지금 우리에게 훨씬 더 나은 대안이 있다는 것을 하나님 께 감사하십시오. 나는 다시는 가지 않을 것이다.

일부 사람들은 현대적인 도구를 사용하여 사이트를 만들면 시간과 에너지 이점을 알지 못할 수도 있습니다.

CSS보다 일반적으로 테이블을 유지하기 가 쉽지 않습니다 . 그러나 몇 가지 구체적인 내용이 있습니다. 테이블이 실제로 가장 단순하고 가장 유연한 솔루션 인 레이아웃 문제가 있습니다.

CSS는 프리젠 테이션 마크 업과 CSS가 동일한 종류의 디자인을 지원하는 경우에 바람직합니다. CSS에서 font타이포그래피를 지정하는 것보다 -tags가 낫다고 주장하는 사람은 아무도 없습니다. CSS는font 없습니다. 훨씬 더 깨끗한 방법.

그러나 테이블 문제는 기본적으로 CSS의 테이블 레이아웃 모델이 Microsoft Internet Explorer에서 지원되지 않는다는 것입니다. 따라서 테이블과 CSS는 그다지 강력 하지 않습니다 . 누락 된 부분은 셀의 가장자리가 세로 및 가로로 정렬되는 반면 셀은 내용을 포함하도록 확장되는 표의 표 와 같은 동작 입니다. 이 동작은 일부 크기를 하드 코딩하지 않고 순수 CSS에서 달성하기 쉽지 않으므로, Internet Explorer를 지원해야하는 한 다른 설계에서는 튼튼하고 부서지기 쉽습니다 (다른 브라우저에서는을 사용하여 쉽게 수행 할 수 있음 display:table-cell).

따라서 실제로 테이블 또는 CSS가 바람직한 지 여부는 문제가 아니지만 테이블을 사용하여 레이아웃을보다 유연하게 만들 수있는 특정 사례를 인식하는 문제입니다.

테이블을 사용 하지 않는 가장 중요한 이유 는 접근성입니다. 웹 컨텐츠 접근성 지침 http://www.w3.org/TR/WCAG10/ 권고는 레이아웃을 위해 테이블을 사용하는 것입니다. 내게 필요한 옵션 (어떤 경우에는 법적으로 의무가있을 수 있음)이 염려되는 경우 테이블이 더 단순하더라도 CSS를 사용해야합니다. 당신이 할 수있는 참고 항상 , 그냥 더 많은 작업이 필요할 수 있습니다 테이블로 CSS와 같은 레이아웃을 만들 수 있습니다.

몇 가지 문제가 아직 다루어지지 않은 것에 놀랐습니다. 여기에 2 센트가 있습니다.

.1. CSS 및 SEO :

a) CSS는 콘텐츠를 페이지의 원하는 위치에 배치 할 수있어 SEO에 매우 큰 영향을 미쳤습니다. 몇 년 전, 검색 엔진은 "온 페이지"요소에 중점을 두었습니다. 페이지 상단에있는 것이 하단에있는 것보다 페이지와 관련이있는 것으로 간주되었습니다. 스파이더의 "페이지 상단"은 "코드의 시작 부분"을 의미합니다. CSS를 사용하면 코드 시작 부분에 키워드가 많은 콘텐츠를 구성하고 페이지에서 원하는 위치에 배치 할 수 있습니다. 이것은 여전히 ​​다소 관련이 있지만 페이지 순위에 대해서는 페이지 요소가 덜 중요합니다.

b) 레이아웃을 CSS로 옮길 때 HTML 페이지가 더 가벼워서 검색 엔진 스파이더에 더 빠르게로드됩니다. (스파이더는 외부 CSS 파일 다운로드를 방해하지 않습니다). 빠른 로딩 페이지는 Google을 비롯한 여러 검색 엔진에서 중요한 순위 고려 사항입니다.

c) SEO 작업에는 종종 테스트 및 변경이 필요하며 이는 CSS 기반 레이아웃으로 훨씬 편리합니다.

.2. 생성 된 컨텐츠 :

테이블은 동등한 CSS 레이아웃보다 프로그래밍 방식으로 생성하기가 훨씬 쉽습니다.

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

테이블을 생성하는 것은 간단하고 안전합니다. 자체 포함되어 있으며 모든 템플릿에 잘 통합됩니다. CSS와 동일한 작업을 수행하는 것은 상당히 어렵고 전혀 도움이되지 않을 수 있습니다. CSS 스타일 시트를 편집하는 것이 어렵고 인라인 스타일을 추가하는 것은 테이블을 사용하는 것과 다르지 않습니다 (컨텐츠는 레이아웃과 분리되지 않음).

또한 테이블이 생성 될 때 내용 (변수)이 이미 레이아웃 (코드)과 분리되어있어 쉽게 수정할 수 있습니다.

이것이 잘 설계된 웹 사이트 (예 : SO)가 여전히 테이블 레이아웃을 사용하는 이유 중 하나입니다.

물론 결과가 JavaScript를 통해 수행되어야하는 경우 div는 문제가됩니다.

.삼. 빠른 변환 테스트

특정 잠재 고객에게 적합한 것이 무엇인지 파악할 때 다양한 방법으로 레이아웃을 변경하여 최상의 결과를 얻는 방법을 알아내는 것이 유용합니다. CSS 기반 레이아웃으로 작업이 훨씬 쉬워집니다.

.4. 다른 문제에 대한 다른 솔루션

레이아웃 테이블은 일반적으로 "모두가 div 및 CSS를 알고있다"는 방식이므로 분석됩니다.

그러나 대부분의 CSS 레이아웃보다 테이블을 작성하는 것이 빠르고 이해하기 쉬우 며 더욱 강력하다는 사실이 남아 있습니다. (예, CSS는 강력 할 수 있지만 다른 브라우저와 화면 해상도에서 인터넷을 빠르게 살펴보면 종종 그렇지 않다는 것을 보여줍니다)

유지 관리, 유연성 부족 등 테이블에 많은 단점이 있지만 목욕물로 아기를 버리지 마십시오. 빠르고 신뢰할 수있는 솔루션에 대한 전문적인 용도가 많이 있습니다.

얼마 전에 사용자가 상당 부분 CSS를 지원하지 않는 이전 버전의 IE를 사용하기 때문에 테이블을 사용하여 깨끗하고 간단한 CSS 레이아웃을 다시 작성해야했습니다.

나는 하나의 경우, 무릎 통증 반응에 아프고 피곤하다. "오, 아냐! 레이아웃을위한 테이블!"

"그것은 그 목적을 위해 의도 된 것이 아니므로 이런 식으로 사용해서는 안됩니다"군중에 관해서는 위선이 아닙니까? 대부분의 브라우저에서 과감한 작업을 수행하기 위해 사용해야하는 모든 CSS 트릭에 대해 어떻게 생각하십니까? 그들은 그 목적을위한 것이 었습니까?