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

Development Tip

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

yourdevel 2020. 9. 30. 11:33

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

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

왜?

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

콘텐츠를 레이아웃에서 분리하는 것은 좋지만 이것은
잘못된 주장입니다. 진부한 생각 . 레이아웃에 테이블 요소를 사용하는 것이 테이블 형식 데이터와 거의 관련이 없다는 것이 사실이라고 생각합니다. 그래서 뭐? 내 상사가 신경 쓰나요? 내 사용자가 신경 쓰나요?

웹 페이지 관리를 유지해야하는 저 또는 동료 개발자 일 것입니다. 테이블을 유지 관리하기가 어렵습니까? 테이블을 사용하는 것이 div와 CSS를 사용하는 것보다 쉽다고 생각합니다 .

그건 그렇고 ... 왜 div 또는 span을 사용하여 레이아웃과 테이블에서 콘텐츠를 잘 분리하지 않습니까? div만으로 좋은 레이아웃을 얻으려면 종종 많은 중첩 div가 필요합니다.
코드의 가독성은 그
반대라고 생각합니다. 대부분의 사람들은 HTML을 이해하고 CSS를 이해하는 사람은 거의 없습니다.
SEO가 테이블을 사용하지 않는 것이 좋습니다.
왜? 아무도 그것이 사실이라는 증거를 보여줄 수 있습니까? 또는 SEO 관점에서 테이블이 권장되지 않는다는 Google의 진술?
테이블이 느립니다.
추가 tbody 요소를 삽입해야합니다. 이것은 최신 웹 브라우저의 땅콩입니다. 표를 사용하면 페이지 속도가 크게 느려지는 몇 가지 벤치 마크를 보여주세요.
테이블 없이는 레이아웃 점검이 더 쉽습니다 . css Zen Garden을 참조하십시오 .
업그레이드가 필요한 대부분의 웹 사이트에는 새 콘텐츠 (HTML)도 필요합니다. 새 버전의 웹 사이트에 새 CSS 파일 만 필요한 시나리오는 거의 없습니다. Zen Garden은 멋진 웹 사이트이지만 약간의 이론적입니다. CSS 의 오용 은 말할 것도 없습니다 .

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

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

콘텐츠를 레이아웃에서 분리하는 것은 좋지만 이것은 잘못된 주장입니다. Cliché Thinking.

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

그래서 뭐? 내 상사가 신경 쓰나요? 내 사용자가 신경 쓰나요?

의존합니다. 상사가 머리가 뾰족합니까? 그럼 그는 상관하지 않을 수도 있습니다. 그녀가 유능하다면 사용자 가 .

웹 페이지 관리를 유지해야하는 저 또는 동료 개발자 일 것입니다. 테이블을 유지 관리하기가 어렵습니까? 테이블을 사용하는 것이 div와 css를 사용하는 것보다 쉽다고 생각합니다.

~~대부분의 전문 웹 개발자는 당신을 반대하는 것 같습니다~~^{[ 인용 필요 ]} . 테이블 이 실제로 유지 관리하기 어렵다는 것은 분명합니다. 레이아웃에 테이블을 사용한다는 것은 회사 레이아웃을 변경하는 것이 실제로 모든 페이지를 변경한다는 것을 의미합니다. 이것은 매우 비쌀 수 있습니다 . 반면, 의미 상 의미있는 HTML을 CSS와 결합하여 현명하게 사용하면 이러한 변경 사항이 사용 된 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;

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

의미론 102

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

결론

방문자가 알아 차리나요? 아뇨. 상사가 신경 쓰나요? 아마도. 프로그래머로서 가끔 코너를 깎는가? 확실한. 그러나 우리는? 아니요. 의미 론적 마크 업을 사용하면 누구에게 이익이됩니까? 당신과 당신의 직업적 명성. 이제 가서 옳은 일을하십시오.

분명한 대답 : CSS Zen Garden을 참조하십시오 . 테이블 기반 레이아웃으로 쉽게 똑같이 할 수 있다고 말하면 (HTML이 변경되지 않음을 기억하십시오) 레이아웃에 테이블을 사용하십시오.

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

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

따라서 귀하의 대답은 유지 관리, 접근성 및 SEO입니다.

게으르지 마십시오. 배우기가 조금 더 어렵더라도 옳고 적절한 방식으로 일을하십시오.

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

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

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

당신이하고있는 일을 알고 있고 좋은 도구를 가지고 있다면 CSS는 실제로 레이아웃을위한 테이블에 비해 상당한 이점이 있습니다. 그리고 각 항목 자체가 테이블을 버리는 것을 정당화하지 못할 수도 있지만, 종합하면 일반적으로 그만한 가치가 있습니다.

안타깝게도 CSS Zen Garden은 더 이상 좋은 HTML / CSS 디자인의 예로 사용할 수 없습니다. 거의 모든 최근 디자인은 섹션 제목에 그래픽을 사용합니다. 이러한 그래픽 파일은 CSS에 지정되어 있습니다.

따라서 콘텐츠에서 디자인을 유지하는 이점을 보여주는 것이 목적인 웹 사이트는 이제 콘텐츠를 디자인에 넣는 명백한 죄악을 정기적으로 범합니다. (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 테이블이 레이아웃이기 때문에 잘못된 주장입니다! 내용은 테이블 의 데이터 이고 프레젠테이션은 테이블 자체입니다. 이것이 HTML에서 CSS를 분리하는 것이 때때로 매우 어려운 이유입니다. 프레젠테이션에서 콘텐츠를 분리하는 것이 아니라 프레젠테이션과 프레젠테이션을 분리하는 것입니다! 중첩 된 div 더미는 테이블과 다르지 않으며 다른 태그 집합 일뿐입니다.

CSS에서 HTML을 분리하는 또 다른 문제는 서로에 대한 친밀한 지식이 필요하다는 것입니다. 실제로 완전히 분리 할 수는 없습니다. HTML의 태그 레이아웃은 사용자가 무엇을하든 CSS 파일과 밀접하게 결합됩니다.

테이블 대 div는 애플리케이션의 요구 사항에 달려 있다고 생각합니다.

우리가 직장에서 개발하는 응용 프로그램에서는 조각이 콘텐츠에 맞게 동적으로 크기가 조정되는 페이지 레이아웃이 필요했습니다. 나는 이것을 CSS 및 DIV와 함께 브라우저 간 작동하도록 노력하는 데 며칠을 보냈고 그것은 완전한 악몽이었습니다. 우리는 테이블로 전환했고 모든 것이 작동했습니다 .

그러나 우리는 우리 제품에 대해 매우 폐쇄적 인 청중을 가지고 있으며 (우리는 웹 인터페이스가있는 하드웨어를 판매합니다) 접근성 문제는 우리에게 걱정거리가 아닙니다. 스크린 리더가 왜 테이블을 잘 다룰 수 없는지 모르겠지만, 이것이 그런식이라면 개발자가 처리해야 할 것 같습니다.

CSS / DIV-그것은 단지 디자인 소년을위한 일이 아닙니다. DIV / CSS 문제를 디버깅하고 인터넷을 검색하여 모호한 브라우저로 작업하는 마크 업의 일부를 얻는 데 수백 시간을 소비했습니다. 당신은 조금만 변경하면 전체 레이아웃이 끔찍하게 잘못됩니다. 이런 식으로 3 픽셀을 이동 한 다음 다른 2 픽셀을 이동하여 모두 정렬되도록 몇 시간을 보냅니다. 이것은 어떻게 든 나에게 명백한 잘못된 것처럼 보입니다. 당신이 순수 주의자이고 무언가가 "올바른 일이 아니다"라고해서 모든 상황에서, 특히 그것이 당신의 삶을 1000 배 더 편하게 만든다면, 그것을 n 번째로 그리고 모든 상황에서 사용해야한다는 의미는 아닙니다.

그래서 마침내 결정했습니다. 순전히 상업적인 근거로, 최소한 사용을 유지하지만 DIV를 올바르게 배치하기 위해 20 시간 작업을 할 것으로 예상하면 테이블에 붙일 것입니다. 그것은 틀렸다. 순수 주의자들을 화나게하지만 대부분의 경우 시간과 관리 비용이 더 적게 든다. 그런 다음 순수 주의자들을 기쁘게하기보다는 고객이 원하는대로 애플리케이션을 작동시키는 데 집중할 수 있습니다. 그들은 결국 청구서를 지불하고 CSS / DIV 사용을 강요하는 관리자에 대한 나의 주장을합니다. 저는 고객이 그의 급여도 지불한다는 점을 지적 할뿐입니다!

이러한 모든 CSS / DIV 인수가 발생하는 유일한 이유는 처음에는 CSS의 단점과 브라우저가 서로 호환되지 않기 때문이며 만약 그렇다면 세계 웹 디자이너의 절반이 일자리를 잃을 것입니다. .

윈도우 폼을 디자인 할 때 컨트롤을 배치 한 후에는 컨트롤을 이동하지 않기 때문에 웹 폼으로이 작업을 수행하려는 이유가 이상하다고 생각합니다. 이 논리를 이해할 수 없습니다. 시작하기에 적합한 레이아웃과 문제가 무엇인지 확인하십시오. 디자이너가 창의력을 발휘하는 것을 좋아하는 반면, 애플리케이션 개발자는 실제로 애플리케이션을 작동시키고, 비즈니스 객체를 만들고, 비즈니스 규칙을 구현하고, 고객 데이터의 비트가 서로 어떻게 관련되어 있는지 파악하고, 고객과의 만남을 보장하는 데 더 관심이 있기 때문이라고 생각합니다. 요구 사항-아시다시피-실제 상황과 같습니다.

오해하지 마십시오. 두 가지 주장이 모두 유효하지만 개발자가 양식을 디자인하는 데 더 쉽고 논리적 인 접근 방식을 선택한다고 비판하지 마십시오. 우리는 종종 div를 통해 테이블을 사용하는 올바른 의미보다 더 중요한 사항을 걱정해야합니다.

사례-이 토론을 기반으로 기존 td 및 trs를 div로 변환했습니다. 45 분 동안 모든 것을 나란히 놓으려고 애쓰다가 포기했습니다. TD는 10 초 후에 돌아옵니다. 모든 브라우저에서 즉시 작동합니다. 더 이상 할 일이 없습니다. 제발 이해하도록 해주세요-제가 다른 방법으로하기를 바라는 것에 대해 당신은 가능한 정당성을 가지고 있습니다!

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

그래도 "WTF"라고 말하지 않으면 지금 쿨 에이드를 내려 놓아야합니다.

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

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

한숨. 충분한 배출. 계속해서 머리를 모래에 다시 꽂으십시오.

508 규정에 따르면 (시각적으로 왜곡 된 스크린 리더의 경우) 테이블은 데이터를 저장하는 데만 사용해야하며 레이아웃이 아닌 경우 스크린 리더가 놀라게합니다. 또는 나는 들었다.

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

다음은 최근 프로젝트의 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>

테이블 기반 레이아웃에서 볼 수있는 유일한 청결 함은 들여 쓰기에 지나치게 열중한다는 사실입니다. 콘텐츠 섹션에는 두 개의 추가 테이블이 포함될 것이라고 확신합니다.

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

div 기반 레이아웃이 관리, 진화 및 리팩터링이 더 쉽다는 점을 추가하고 싶습니다. 요소를 재정렬하기 위해 CSS를 약간 변경하면 완료됩니다. 내 경험상 테이블을 사용하는 레이아웃을 다시 디자인하는 것은 악몽입니다 (중첩 된 테이블이있는 경우 더 많음).

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

DIV의 어떤 주장도 나에게 유리하지 않습니다.

나는 말할 것이다 : 신발이 맞으면 신 어라.

모든 브라우저에서 일관되고 여전히 내가 의도 한대로 보이는 2 개 또는 3 개의 열에서 콘텐츠를 렌더링하는 좋은 DIV + CSS 방법을 찾는 것이 불가능하지는 않지만 어렵다는 점에 주목할 가치가 있습니다.

이것은 대부분의 레이아웃에서 테이블에 대한 균형을 약간 기울이고 있지만 사용에 대한 죄책감이 있지만 (왜 사람들은 나쁘다고 말하고 들어 보려고합니다) 결국 실용적인 관점은 단지 TABLE을 사용하는 것이 더 쉽고 빠릅니다. 나는 시간당 지불하지 않으므로 테이블이 더 저렴합니다.

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 and other automated systems do care, and they're just as important in many situations. Semantic code is easier for a non-intelligent system to parse and process.

Having had to work with a website that involved 6 layers of nested tables generated by some application, and having had it generate invalid HTML, it was in fact a 3 hour job to rectify it breaking for a minor change.

This is of course the edge case, but table based design is unmaintainable. If you use css, you separate the style out so when fixing the HTML you have less to worry about breaking.

Also, try this with JavaScript. Move a single table cell from one place to another place in another table. Rather complicated to perform where div/span would just work copy-paste-wise.

"Does my boss care"

내가 당신의 상사라면. 당신은 관심을 가질 것입니다. ;) 당신이 당신의 삶을 소중하게 생각한다면.

레이아웃 유연성
많은 수의 축소판이있는 페이지를 만들고 있다고 가정 해보십시오.
DIV :
각 썸네일을 DIV에 넣으면 왼쪽으로 떠서 10 개가 한 행에 들어갑니다. 창을 더 좁히고 BAM-연속 6 또는 2 또는 여러 적합합니다.
표 :
행에있는 셀 수를 명시 적으로 말해야합니다. 창이 너무 좁 으면 사용자가 가로로 스크롤해야합니다.

Maintainability
Same situation as above. Now you want to add three thumbnails to the third row.
DIVs:
Add them in. The layout will automatically adjust.
TABLE: Paste the new cells into the third row. Oops! Now there are too many items there. Cut some from that row and put them on the fourth row. Now there are too many items there. Cut some from that row... (etc)
(Of course, if you're generating the rows and cells with server-side scripting, this probably won't be an issue.)

I think that boat has sailed. If you look at the direction the industry has taken you will notice that CSS and Open Standards are the winners of that discussion. Which in turn means for most html work, with the exception of forms, the designers will use divs instead of tables. I have a hard time with that because I am not a CSS guru but thats the way it is.

Also, don't forget, tables don't quite render well on mobile browsers. Sure, the iPhone has a kick-ass browser but everyone doesn't have an iPhone. Table rendering can be peanuts for modern browsers, but it's a bunch of watermelons for mobile browsers.

I have personally found that many people use too many <div> tags, but in moderation, it can be extremely clean and easy to read. You mention that folks have a harder time reading CSS than tables; in terms of 'code' that maybe true; but in terms of reading content (view > source) it is a heck of a lot easier to understand the structure with stylesheets than with tables.

Looks like you are just used to tables and that's it. Putting layout in a table limits you for just that layout. With CSS you can move bits around, take a look at http://csszengarden.com/ And no, layout does not usally require a lot of nested divs.

With no tables for layout and proper semantics HTML is much cleaner, hence easier to read. Why should someone who cannot understand CSS try to read it? And if someone considers himself to be webdeveloper then the good grasp of CSS is a must.

SEO benefits come from the ability to have most important content higher up the page and having better content-to-markup ratio.

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

508 Compliance - the ability for a screenreader to make sense of your markup.
Waiting for render - tables don't render in the browser until it gets to the end of the </table> element.

The whole idea around semantic markup is the separation of markup and presentation, which includes layout.

Div's aren't replacing tables, they have their own use in separating content into blocks of related content (, ). When you don't have the skills and are relying on tables, you'll often have to separate your content in to cells in order to get the desired layout, but you wont need to touch the markup to achieve presentation when using semantic markup. This is really important when the markup is being generated rather than static pages.

Developers need to stop providing markup that implies layout so that those of us who do have the skills to present content can get on with our jobs, and developers don't have to come back to their code to make changes when presentation needs change.

This isn't really about whether 'divs are better than tables for layout'. Someone who understands CSS can duplicate any design using 'layout tables' pretty straightforwardly. The real win is using HTML elements for what they are there for. The reason you would not use tables for non-tablular data is the same reason you don't store integers as character strings - technology works much more easily when you use it for the purpose for which it is desgined. If it was ever necessary to use tables for layout (because of browser shortcomings in the early 1990s) it certainly isn't now.

Tools that use table layouts can become extraordinarily heavy due to the amount of code required to create the layout. SAP's Netweaver Portal by default uses TABLE to layout their pages.

The production SAP portal at my current gig has a home page whose HTML weighs over 60K and goes seven tables deep, three times within the page. Add in the Javascript, the misuse of 16 iframes with similar table issues inside of them, overly heavy CSS etc, and the page weighs over 5MB.

Taking the time to lower the page weight so you can use your bandwidth to do engaging activities with users is worth the effort.

It's worth figuring out CSS and divs so the central content column loads and renders before the sidebar in a page layout. But if you are struggling to use floating divs to vertically align a logo with some sponsorship text, just use the table and move on with life. The Zen garden religion just doesn't give much bang for the buck.

The idea of separating content from presentation is to partition the application so different kinds of work affect different blocks of code. This is actually about change management. But coding standards can only examine the present state of code in a superficial manner.

The change log for an application that depends on coding standards to "separate content from presentation" will show a pattern of parallel changes across vertical silos. If a change to "content" is always accompanied by a change to "presentation", how successful is the partitioning?

If you really want to partition your code productively, use Subversion and review your change logs. Then use the simplest coding techniques -- divs, tables, JavaScript, includes, functions, objects, continuations, whatever -- to structure the application so that the changes fit in a simple and comfortable manner.

Because it's HELL to maintain a site that uses tables, and takes a LOT longer to code. If you're scared of floating divs, go take a course in them. They're not difficult to understand and they're approximately 100 times more efficient and a million times less a pain in the ass (unless you don't understand them -- but hey, welcome to the world of computers).

Anyone considering doing their layout with a table better not expect me to maintain it. It's the most ass-backwards way to render a website. Thank god we have a much better alternative now. I would NEVER go back.

It's scary that some folks might not be aware of the time and energy benefits from creating a site using modern tools.

Tables are not in general easier or more maintainable than CSS. However, there are a few specific layout-problems where tables are indeed the simplest and most flexible solution.

CSS is clearly preferable in cases where presentational markup and CSS support the same kind of design, no one in their right mind would argue that font-tags are better than specifying typography in CSS, since CSS gives you the same power than font-tags, but in a much cleaner way.

The issue with tables, however, is basically that the table-layout model in CSS is not supported in Microsoft Internet Explorer. Tables and CSS are therefore not equivalent in power. The missing part is the grid-like behavior of tables, where the edges of cells align both vertically and horizontally, while cells still expand to contain their content. This behavior is not easy to achieve in pure CSS without hardcoding some dimensions, which makes the design rigid and brittle (as long as we have to support Internet Explorer - in other browsers this is easliy achieved by using display:table-cell).

So it's not really a question of whether tables or CSS is preferable, but it is a question of recognizing the specific cases where use of tables may make the layout more flexible.

The most important reason for not using tables is accessibility. The Web Content Accessibility Guidelines http://www.w3.org/TR/WCAG10/ advice againt using tables for layout. If you are concerned about accessibility (and in some cases you may be legally obliged to), you should use CSS even if tables are simpler. Note that you can always create the same layout with CSS as with tables, it might just require more work.

I was surprised to see some issues were not already covered, so here are my 2 cents, in addition to all the very valid points made earlier:

.1. CSS & SEO:

a) CSS used to have a very significant impact on SEO by allowing to position the content in the page wherever you want. A few years ago, Search Engines were giving a significant emphasis to "on-page" factors. Something at the top of the page was deemed more relevant to the page than something located at the bottom. "Top of the page" for a spider meant "at the beginning of the code". Using CSS, you could organize your keyword-rich content at the beginning of the code, and still position it wherever you liked in the page. This is still somewhat relevant, but on page factors are less and less important for page ranking.

b) When the layout is moved over to CSS, the HTML page is lighter and therefore loads faster for a search engine spider. (spiders don't bother downloading external css files). Fast loading pages is an important ranking consideration for several search engines, including Google

c) SEO work often requires testing and changing things, which is much more convenient with a CSS based layout

.2. Generated content:

A table is considerably easier to generate programmically than the equivalent CSS layout.

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

Generating a table is simple and safe. It is self-contained and integrates well within any template. To do the same with CSS is considerably harder and may be of no benefit at all: hard to edit the CSS stylesheet on the flight, and adding the style inline is no different from using a table (content is not separated from layout).

Further, when a table is generated, the content (in variables) is already separated from the layout (in code), making it as easy to modify.

This is one reason why some very well designed websites (SO for instance) still use table layouts.

Of course, if the results need to be acted upon through JavaScript, divs are worth the trouble.

.3. Quick conversion testing

When figuring out what works for a specific audience, it is useful to be able to change the layout in various ways to figure out what gets the best results. A CSS based layout makes things considerably easier

.4. Different solutions for different problems

Layout tables are usually dissed because "everybody knows divs & CSS" are the way to go.

However the fact remains that tables are faster to create, easier to understand and are more robust than most CSS layouts. (Yes, CSS can be as robust, but a quick look through the net on different browsers and screen resolutions shows it's not often the case)

There are a lot of downsides to tables, including maintenance, lack of flexibility... but let's not throw the baby with the bath water. There are plenty of professional uses for a solution which is both quick and reliable.

Some time ago, I had to rewrite a clean and simple CSS layout using tables because a significant portion of the users would be using an older version of IE with really bad support for CSS

I, for one, am sick and tired of the knee-jerk reaction "Oh noes! Tables for layout!"

As for the "it wasn't intended for that purpose and therefore you shouldn't use it this way" crowd, isn't that hypocrisy? What do you think of all the CSS tricks you have to use to get the darn thing working in most browsers? Were they meant for that purpose?

참고URL : https://stackoverflow.com/questions/83073/why-not-use-tables-for-layout-in-html

'Development Tip' 카테고리의 다른 글

TypeScript 문자열을 숫자로 변환 (0)	2020.09.30
공백 문자를 인코딩하는 URL : + 또는 % 20? (0)	2020.09.30
JavaScript에서 Switch 문 여러 사례 (0)	2020.09.30
강제 메이븐 업데이트 (0)	2020.09.30
Git에서 로컬 작업 디렉토리를 지우려면 어떻게해야합니까? (0)	2020.09.30

현재글HTML의 레이아웃에 테이블을 사용하지 않는 이유는 무엇입니까?

yourdevel

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

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

'Development Tip' 카테고리의 다른 글

'Development Tip'의 다른글

티스토리툴바

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

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

'Development Tip' 카테고리의 다른 글

'Development Tip'의 다른글

관련글

티스토리툴바