it-swarm-ko.tech

HTML 레이아웃으로 테이블을 사용 하시겠습니까?

테이블의 HTML 레이아웃에 사용해서는 안되는 general opinion 인 것 같습니다.

왜?

나는 결코 이것을 (또는 솔직히 말하면) 드러내지 않았다. 일반적인 대답은 다음과 같습니다.

  • 레이아웃과 콘텐츠 분리
    그러나 이것은 잘못된 주장이다. 진부한 생각 . 레이아웃 용 테이블 요소를 사용하면 테이블 형식 데이터와 관련이 거의 없다는 것은 사실입니다. 그래서? 내 상사가 신경 써? 내 사용자가 신경 써야합니까?

    아마도 웹 페이지 관리를 유지해야하는 나 또는 동료 개발자들 ... 테이블 유지 관리가 덜합니까? 나는 테이블을 사용하는 것이 div와 CSS를 사용하는 것보다 더 쉽다 라고 생각한다.

    그런데 ... 왜 레이아웃이나 테이블에서 내용을 구분하는 데 div 나 span을 사용합니까? div만으로 좋은 레이아웃을 얻으려면 종종 중첩 된 div가 많이 필요합니다.

  • 코드의 가독성
    나는 그것이 다른 방향이라고 생각한다. 대부분의 사람들은 HTML을 이해하고 CSS를 이해하는 사람은 거의 없습니다.

  • SEO가 테이블을 사용하지 않는 것이 좋습니다.
    왜? 누군가가 그 증거를 보여줄 수 있습니까? 또는 Google의 진술은 검색 엔진 최적화 (SEO) 관점에서 낙심합니까?

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

  • 레이아웃 정비는 테이블이없는 편 더 쉽습니다. css Zen Garden .
    업그레이드가 필요한 대부분의 웹 사이트는 새로운 컨텐트 (HTML)도 필요합니다. 웹 사이트의 새 버전이 새로운 CSS 파일 만 필요로하는 시나리오는 그럴 가능성이 적습니다. 선 가든 (Zen Garden)은 좋은 웹 사이트이지만 약간 이론적입니다. CSS의 오용 은 말할 것도 없습니다.

나는 테이블 대신 divs + CSS를 사용하는 것에 대해 좋은 논쟁에 정말로 관심이 있습니다.

665
Benno Richters

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

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

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

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

다릅니다. 당신의 상사가 뾰족한 머리입니까? 그러면 그는 신경 쓰지 않을 것입니다. 그녀가 유능하다면, 사용자 will 이기 때문에 그녀는 관심을 가질 것입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

496
Konrad Rudolph

여기 내 프로그래머의 대답 simliar thread

시맨틱 101

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

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

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

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

의미론 102

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

결론

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

290
Carl Camera

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

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

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

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

게으르지 마라. 배울 것이 조금 더 어렵더라도 권리와 적당한 방법을하십시오.

104
erlando

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

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

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

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

91
Joel Coehoorn

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

따라서 콘텐츠를 디자인에서 지켜주는 이점을 보여주는 것이 목적 인 웹 사이트는 이제 콘텐츠를 디자인에 넣을 때 명확하지 않은 죄를 범합니다. HTML 파일의 섹션 제목이 변경되면 표시된 섹션 제목은 변경되지 않습니다.

어느 누구도 엄격한 DIV & CSS 종교를 옹호하고 자신의 규칙을 지킬 수 없다는 것을 보여 주기만하면됩니다. 당신은 그들을 얼마나 가깝게 따라야하는지에 대한 지침으로 사용할 수 있습니다.

54
James Curran

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

48
expedient

레이아웃을위한 하나의 테이블은 그렇게 나쁘지 않을 것입니다. 그러나 대부분의 경우 테이블 하나만 있으면 필요한 레이아웃을 얻을 수 없습니다. 꽤 곧 두세 개의 중첩 된 테이블이 있습니다. 이것은 매우 성가신된다.

  • IS 더 읽기가 어렵습니다. 그건 의견에 달린 것이 아닙니다. 거기에 식별 마크가없는 더 많은 중첩 태그가 있습니다.

  • 프레젠테이션과 내용을 분리하는 것은 좋은 일입니다. 왜냐하면 자신이하는 일에 집중할 수 있기 때문입니다. 두 가지를 섞으면 읽을 수없는 부 풀린 페이지가됩니다.

  • 스타일 용 CSS는 브라우저가 파일을 캐시 할 수있게하며 후속 요청은 훨씬 빠릅니다. 이것은 거대하다.

  • 테이블은 당신을 디자인에 묶어 놓습니다. 물론, 모든 사람들이 CSS Zen Garden의 유연성을 필요로하는 것은 아니지만, 여기 저기 조금씩 디자인을 변경할 필요가없는 사이트에서 일한 적이 없습니다. CSS를 사용하면 훨씬 쉽습니다.

  • 테이블은 스타일을 지정하기가 어렵습니다. 유연성이별로 없습니다 (즉, 표 스타일을 완전히 제어하기 위해 HTML 속성을 추가해야 함).

필자는 아마도 4 년 동안 비표준 데이터에 대한 테이블을 사용하지 않았습니다. 나는 다시 보지 않았다.

앤디 버드 (Andy Budd)가 읽는 CSS Mastery 를 제안하고 싶습니다. 환상적이야.

Image at 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

45
Ben Scheirman

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

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

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

테이블과 div가 응용 프로그램의 요구 사항에 부합한다고 생각합니다.

우리가 직장에서 개발하는 어플리케이션에서 우리는 조각들이 동적으로 자신의 컨텐츠에 맞게 크기 조정되는 페이지 레이아웃이 필요했습니다. CSS와 DIV가있는 크로스 브라우저에서 작동하도록 노력하면서 며칠을 보냈는데 완전히 악몽이었습니다. 우리는 테이블로 전환했고 그것 모두는 단지 작동했습니다.

그러나 우리는 제품에 대한 청중이 매우 적습니다 (웹 인터페이스를 갖춘 하드웨어를 판매합니다). 접근성 문제는 우리에게 중요하지 않습니다. 화면 판독기가 테이블을 제대로 처리 할 수없는 이유를 모르겠지만 개발자가 처리해야하는 방식인지는 모르겠다.

36
17 of 26

CSS/DIV - 디자인 소년을위한 일뿐입니다. DIV/CSS 문제를 디버깅하는 데 수백 시간을 소비했으며 인터넷을 검색하여 애매한 브라우저로 작업하는 마크 업의 일부를 얻었습니다. 당신은 하나의 작은 변화를 만들고, 전체 레이아웃은 끔찍하게 잘못됩니다. 지출 시간은 뭔가를 3 픽셀 이동 한 다음 다른 방법으로 2 픽셀을 줄 이도록합니다. 어떻게 든 나에게 틀린 것처럼 보입니다. 당신이 순수 주의자이고 무언가가 "해야 할 일이 옳지 않다"라고해서 그것이 당신의 삶을 1000 번이나 더 쉽게 만든다면, 당신은 모든 상황과 모든 상황에서 그것을 사용해야한다는 것을 의미하지는 않습니다.

그래서 나는 마침내, 순수하게 상업적인 근거로 결정했습니다. 최소한으로 사용하고 있지만, DIV를 올바르게 배치하기 위해 20 시간의 작업이 필요하다면 테이블에 고정시킬 것입니다. 그것은 틀렸어, 순정 주의자들을 혼란스럽게 만들지 만, 대부분의 경우 시간이 절약되고 관리하기가 더 저렴합니다. 그런 다음 순수 주의자를 기쁘게하기보다는 고객이 원하는대로 응용 프로그램을 작동시키는 데 집중할 수 있습니다. 그들은 결국 청구서를 지불하고 CSS/DIV의 사용을 강요하는 관리자에 대한 나의 주장 - 나는 고객이 그의 급여를 지불한다는 것을 지적 할뿐입니다!

이 모든 CSS/DIV 인수가 발생하는 유일한 이유는 CSS의 단점과 브라우저가 서로 호환되지 않기 때문이며 그럴 경우 세계의 웹 디자이너 중 절반이 일자리에서 벗어날 수 있기 때문입니다 .

당신이 윈도우 폼을 디자인 할 때 컨트롤을 움직여 보지 않았다면, 컨트롤을 움직여 보지 마십시오. 그래서 웹 폼으로 왜 이것을하고 싶은지 왜 이상한 지 생각해보십시오. 나는이 논리를 이해할 수 없다. 레이아웃을 올바르게 시작하고 문제가 무엇인지 확인하십시오. 저는 디자이너가 창의력을 노리는 것을 좋아하기 때문에 응용 프로그램 개발자는 실제로 응용 프로그램을 작동시키고, 비즈니스 객체를 만들고, 비즈니스 규칙을 구현하고, 고객 데이터의 비트가 서로 어떻게 관련되어 있는지 확인하고, 고객과의 만남을 보장하기 때문에 요구 사항 - 당신도 알다시피 - 실제 물건처럼.

저를 잘못 이해하지 마십시오. 두 인수는 모두 유효하지만 양식을 설계하는 데있어보다 쉽고 논리적 인 접근 방법을 선택하는 개발자를 비판하지 마십시오. div에 대해 테이블을 사용하는 올바른 의미보다 걱정할 일이 많습니다.

예를 들어,이 토론을 기반으로 몇 가지 기존 tds 및 tr을 div로 변환했습니다. 45 분 동안은 모든 것을 서로 나란히 놓으려고 애 쓰면서 혼란스러워했습니다. 10 초 만에 TD가 다시 작동합니다 - 곧바로 모든 브라우저에서 작동합니다. 제게 이해시켜 주시겠습니까? 제가 다른 방법으로 그것을하기를 원하는 것에 대한 가능한 정당화는 무엇입니까?

23
Tim Black

레이아웃은 쉬워야합니다. CSS에서 머리글과 바닥 글을 사용하여 동적 인 3 열 레이아웃을 만드는 방법에 대한 기사가 있다는 사실은 빈약 한 레이아웃 시스템이라는 것을 보여줍니다. 당연히 당신은 그것을 작동시킬 수 있지만 그것을하는 방법에 관한 말 그대로 수백 개의 기사가 있습니다. 분명히 명백하기 때문에 테이블과 유사한 레이아웃을위한 그러한 기사는 거의 없습니다. 당신이 테이블에 반대하고 CSS에 찬성하더라도,이 사실은 모든 것을 취소합니다. CSS의 기본 3 열 레이아웃은 종종 "The Holy Grail"이라고 불립니다.

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

나는 CSS를 좋아한다. 그것은 놀라운 스타일링 옵션과 멋진 위치 지정 도구를 제공하지만 레이아웃 엔진으로는 부족합니다. 동적 그리드 위치 지정 시스템이 있어야합니다. 먼저 크기를 모른 채 여러 상자에 상자를 정렬하는 간단한 방법입니다. <table>이나 <gridlayout> 등으로 부르지는 않겠지 만 CSS에서 누락 된 기본 레이아웃 기능입니다.

커다란 문제는 누락 된 기능이 있다는 것을 인정하지 않으면 서 CSS 열혈자가 CSS의 모든 것을 되돌릴 수 있다는 것입니다. CSS가 세계의 모든 다른 레이아웃 엔진과 같이 괜찮은 다중 축 그리드 위치 지정을 제공한다면 테이블 사용을 중단하는 것이 매우 행복 할 것입니다. (이 문제는 이미 W3C를 제외한 모든 사람들이 여러 언어로 여러 번 해결되었다는 것을 알고 있습니까? 그리고 그 누구도 유용하지 않다는 것을 아무도 부인하지 않았습니다.)

한숨. 충분한 벤트. 모래에 머리를 다시 붙여주세요.

21
needlestack

508 준수 (시각적으로 오류가있는 화면 판독기의 경우)에 따르면 테이블은 화면 판독기가 이상하게 만드는 원인이되므로 레이아웃이 아닌 데이터 보관 용으로 사용해야합니다. 또는 나는 그렇게 들었다.

각 div에 이름을 지정하면 CSS를 사용하여 div를 모두 스킨 할 수 있습니다. 그들은 당신이 필요로하는 방식으로 앉아있는 것보다 조금 더 고통 스러울뿐입니다.

19
Rob

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

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

생각해 볼 또 다른 것 : filesizes . 테이블 기반 레이아웃은 일반적으로 CSS 대응 크기의 두 배입니다. 우리의 고속 광대역에서 큰 문제는 아니지만 다이얼 업 모뎀을 사용하는 사람들에게 있습니다.

18
Ross

Div에 기반한 레이아웃은 mantain, evolve 및 refactor에 더 쉽다는 것을 추가하고 싶습니다. 요소를 재정렬하기위한 CSS의 몇 가지 변경 사항이 있습니다. 내 경험에 비추어 볼 때 테이블을 사용하는 레이아웃을 재 설계하는 것은 악몽입니다 (중첩 된 테이블이 더 많을 경우).

당신의 코드는 의미 관점에서 의미가 있습니다.

14
Guido

CSS 레이아웃은 일반적으로 콘텐츠가 자연 순서대로 제공되고 스타일 시트없이 의미가있는 경우 액세스 가능성에 훨씬 좋습니다. 테이블 기반 레이아웃을 고수하는 것은 화면 판독기뿐만 아니라 모바일 브라우저가 페이지를 올바르게 렌더링하는 것이 훨씬 어려워집니다.

또한 div 기반 레이아웃을 사용하면 머리말, 꼬리말 및 인쇄 된 페이지에서 내비게이션을 제외하는 것과 같은 인쇄 스타일 시트를 사용하여 멋진 작업을 손쉽게 수행 할 수 있습니다.이 기능을 사용하여 불가능하거나 적어도 훨씬 어려울 것입니다. 테이블 기반 레이아웃.

레이아웃보다는 div를 사용하는 것이 레이아웃과의 분리가 테이블보다 쉽다는 생각이 들면 CSS Zen Garden 에서 div 기반 HTML을 살펴보고 스타일 시트를 변경하면 레이아웃이 어떻게 크게 바뀔 수 있는지 생각해보십시오. HTML이 테이블 기반이라면 같은 레이아웃의 다양한 레이아웃을 구현할 수 있는지에 대해 ... 테이블 기반 레이아웃을 수행하는 경우 CSS를 사용하여 셀의 모든 간격과 패딩을 제어 할 가능성이 낮습니다 (if 처음에는 플로팅 divs 등을 사용하는 것이 더 쉬울 것입니다. CSS를 사용하여 모든 것을 제어하지 않고 테이블이 HTML의 왼쪽에서 오른쪽 및 맨 아래 순서를 지정하기 때문에 테이블은 HTML에서 레이아웃이 매우 고정적으로되는 경향이 있습니다.

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

13
MB.

이것이 논쟁의 여지가있는 질문이라는 사실은 W3C가 시도 될 레이아웃 디자인의 다양성을 예상하지 못했다는 증거입니다. 의미 상 친숙한 레이아웃을 위해 divs + css를 사용하는 것은 좋은 개념이지만, 구현의 세부 사항은 실제로 결함이있어 실제로 창의적인 자유를 제한합니다.

나는 우리 회사 사이트 중 하나를 테이블에서 div로 바꾸려고 시도했습니다. 그런 두통으로 인해 제가 부어 있던 작업 시간을 완전히 없애고 테이블로 되돌아갔습니다. 수직 정렬을 제어하기 위해 divs와 씨름하려고 애쓰는 동안이 논쟁이 불거지면 결코 흔들리지 않는 주요 심리적 문제로 저주했습니다.

수직 정렬과 같은 단순한 설계 목표를 달성하기 위해 사람들이 자주 복잡하고 추악한 해결 방법을 제시해야한다는 사실은 규칙이 충분히 유연하지 않다는 것을 강력히 시사합니다. 사양이 충분하다면 왜 유명 사이트 (예 : SO)가 테이블 및 기타 해결 방법을 사용하여 규칙을 굽히는 것이 필요하다고 생각합니까?

13
DLH

DIV에서 어떤 주장도 내게는 호의적이지 않습니다.

나는 말할 것이다 : 신발이 맞는다면, 그것을 입는다.

두세 개의 열로 내용을 렌더링하는 좋은 DIV + CSS 메서드를 찾는 것이 불가능하지는 않더라도 어렵지 않습니다. 모든 브라우저에서 일관성이 있으며 의도 한대로 보입니다.

이 팁은 대부분의 레이아웃에서 테이블에 대한 균형을 잡는 데 도움이됩니다. 그리고 나는 그것을 사용하는 것에 죄책감을 느낍니다. (이유는 사람들이 단지 나쁜 말을하기 때문에 나에게 들으 려합니다.) 결국 실용적인 견해는 단지 테이블을 사용하는 것이 쉽고 빠릅니다. 나는 시간당 돈을 내지 않으므로 테이블은 나에게 더 싸다.

13
Radu094

레이아웃 용 테이블 요소를 사용하면 테이블 형식 데이터와 관련이 거의 없다는 것은 사실입니다. 그래서? 내 상사가 신경 써? 내 사용자가 신경 써야합니까?

Google 및 기타 자동화 시스템 do care는 여러 상황에서 마찬가지로 중요합니다. 시맨틱 코드는 지능형이 아닌 시스템이 구문 분석하고 처리하는 것이 더 쉽습니다.

12
ceejayoz

일부 응용 프로그램에서 생성 된 중첩 테이블의 6 개 레이어가 포함 된 웹 사이트에서 작업해야하고 잘못된 HTML을 생성 한 경우 사소한 변경으로 인해이를 수정하는 것이 사실 3 시간 작업이었습니다.

이것은 물론 Edge 케이스이지만 테이블 기반 디자인은 유지할 수 없습니다. css를 사용하는 경우 스타일을 분리하여 HTML을 수정할 때 파손을 걱정하지 않아도됩니다.

또한 자바 스크립트를 사용해보십시오. 한 테이블 셀을 한 테이블에서 다른 테이블의 다른 테이블로 옮깁니다. div/span이 복사 - 붙여 넣기 방식으로 작동하는 곳에서 수행하기보다는 오히려 복잡합니다.

"내 상사가 관심있어"

내가 네 상사라면. 너는 신경 쓸거야. ;) 당신의 인생을 존중한다면.

8
Kent Fredric

레이아웃 유연성
엄지 손톱이 많은 페이지를 만들었다 고 상상해보십시오.
DIVs :
각 축소판 그림을 DIV에 넣으면 왼쪽으로 띄우면 10 개가 연속으로 나타납니다. 창을 더 좁게 만들고 BAM - 연속 6 또는 2, 또는 많은 적합.
표 :
행에 얼마나 많은 셀이 있는지 명시 적으로 말해야합니다. 창이 너무 좁 으면 사용자는 가로로 스크롤해야합니다.

유지 보수성
위와 같은 상황. 이제 세 번째 행에 세 개의 미리보기 이미지를 추가하려고합니다.
DIVs :
그들을 추가하십시오. 레이아웃이 자동으로 조정됩니다.
TABLE : 새 셀을 세 번째 행에 붙여 넣습니다. 죄송합니다! 거기에 너무 많은 항목이 있습니다. 그 줄에서 어떤 것을 자르고 그것을 네 번째 줄에 놓으십시오. 이제는 너무 많은 항목이 있습니다. 그 줄에서 일부 잘라 내기 ... (etc)
(물론 서버 측 스크립팅으로 행과 셀을 생성하는 경우에는 문제가되지 않습니다.)

7
Nathan Long

나는 배가 항해했다고 생각한다. 업계가 제시 한 방향을 보면 CSS와 Open Standards가 그 토론의 승자라는 것을 알 수 있습니다. 이는 대부분의 html 작업에서 양식을 제외하고는 디자이너가 테이블 대신 div를 사용한다는 것을 의미합니다. 내가 CSS 전문가가 아니기 때문에 나는 힘든 시간을 가졌지 만 그게 사실입니다.

7
Thomas Wagner

또한 테이블이 모바일 브라우저에서 제대로 렌더링되지 않는다는 것을 잊지 마십시오. 물론 아이폰에는 킥 - 엉뚱한 브라우저가 있지만 모든 사람들에게는 아이폰이 없다. 테이블 렌더링은 최신 브라우저를위한 땅콩 일 수 있지만 모바일 브라우저를위한 수박의 무리입니다.

개인적으로 많은 사람들이 <div> 태그를 너무 많이 사용한다는 것을 알았지 만, 적당히 읽을 때 매우 깨끗하고 읽기 쉽습니다. 사람들은 CSS보다 테이블을 읽는 것이 더 힘들다고 언급합니다. 어쩌면 사실 일 수도있는 '코드'의 관점에서; 그러나 내용 (뷰> 소스)을 읽는 관점에서 스타일 시트를 사용하는 구조를 테이블보다 이해하기가 훨씬 쉽습니다.

5
Swati

당신은 테이블에 익숙해 보이는 것 같습니다. 레이아웃을 테이블에 배치하면 레이아웃 만 제한됩니다. CSS를 사용하면 비트를 이동할 수 있습니다. http://csszengarden.com/ 아니요. 레이아웃은 일반적으로 중첩 된 div가 많이 필요하지 않습니다.

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

SEO 혜택은 가장 중요한 콘텐츠를 페이지 위쪽으로 올리고 콘텐츠 - 마크 업 비율을 높이는 기능에서 비롯됩니다.

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

5
Rimantas

의미 론적 마크 업을 둘러싼 전체적인 생각은 레이아웃을 포함하는 마크 업과 프리젠 테이션의 분리입니다.

Div는 테이블을 대체하지 않고 관련 콘텐츠 (,)의 블록으로 콘텐츠를 분리하는 데 자체적으로 사용됩니다. 기술이없고 테이블을 사용하는 경우 원하는 레이아웃을 얻으려면 셀로 내용을 분리해야하지만 시맨틱 마크 업을 사용할 때 프리젠 테이션을하려면 마크 업을 터치 할 필요가 없습니다. 이는 정적 페이지보다는 마크 업이 생성 될 때 정말로 중요합니다.

개발자는 레이아웃을 암시하는 마크 업 제공을 중지해야합니다. 그래야 컨텐츠를 표현할 수있는 기술을 가진 사람들이 우리 업무에 착수 할 수 있고 개발자는 프레젠테이션의 필요성이 바뀌면 코드를 다시 사용할 필요가 없습니다.

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

이것은 div가 레이아웃 용 테이블보다 더 좋은지 아닌지에 관한 것이 아닙니다. CSS를 이해하는 사람은 '레이아웃 테이블'을 사용하여 모든 디자인을 똑같이 복제 할 수 있습니다. 진정한 승리는 HTML 요소를 사용하여 HTML 요소를 사용하는 것입니다. 테이블 형식이 아닌 데이터에 테이블을 사용하지 않는 이유는 정수를 문자열로 저장하지 않는 것과 같은 이유입니다.이 기술은 정해진 용도로 사용할 때 훨씬 쉽게 작동합니다. 레이아웃을 위해 테이블을 사용해야하는 경우 (1990 년대 초기의 브라우저 단점으로 인해) 분명히 지금은 아닙니다.

4
domgblackwell

중앙 콘텐츠 열이 페이지 레이아웃에서 사이드 바보다 먼저로드되고 렌더링되도록 CSS와 div를 알아내는 것이 좋습니다. 그러나 플로팅 div를 사용하여 로고를 스폰서 십 텍스트와 수직으로 정렬하는 데 어려움을 겪고 있다면 테이블을 사용하고 평생을 즐기십시오. 선 (禅) 정원의 종교는 벅값에 많은 돈을주지 않습니다.

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

"프레젠테이션과 콘텐츠 분리"라는 코딩 표준에 따라 달라지는 응용 프로그램의 변경 로그는 세로 사일로 전체에서 병행 변경 패턴을 보여줍니다. "컨텐츠"변경시 항상 "프리젠 테이션"변경이 수반되는 경우 분할이 얼마나 성공적입니까?

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

3
Patrick May

테이블은 CSS보다 일반적으로 더 쉽고 유지 보수가 쉽지 않습니다. 그러나 테이블이 실제로 가장 단순하고 가장 유연한 솔루션 인 몇 가지 특정 레이아웃 문제가 있습니다.

CSS는 프리젠 테이션 마크 업과 CSS가 같은 종류의 디자인을 지원하는 경우에 바람직합니다. CSS에서 타이포그래피를 지정하는 것보다 font- tags가 더 낫다고 주장하는 사람은 없습니다. font- 태그이지만 훨씬 깔끔합니다.

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

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

테이블을 사용하는 not 의 가장 중요한 이유는 액세스 가능성입니다. 웹 컨텐츠 접근성 지침 http://www.w3.org/TR/WCAG10/ 레이아웃에 테이블을 사용하는 조언. 내게 필요한 옵션 (어떤 경우에는 법적으로 의무가있을 수 있음)이 염려되는 경우 테이블이 더 단순하더라도 CSS를 사용해야합니다. CSS를 사용하여 항상 테이블과 동일한 레이아웃을 만들 수 있으므로 더 많은 작업이 필요할 수 있습니다.

3
JacquesB

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

현재 사용중인 SAP 포털에는 HTML이 60K를 넘는 홈 페이지가 있으며 페이지 내에서 세 번 깊은 7 개의 테이블로 이동합니다. Javascript에 16 개의 iframe을 넣고 내부에 비슷한 테이블 문제가 있거나 지나치게 무거운 CSS 등을 사용하면 페이지의 무게가 5MB를 초과합니다.

대역폭을 사용하여 사용자와 활동을 수행 할 수 있도록 페이지 가중치를 낮추는 데 시간을 할애 할 필요가 있습니다.

3
Mike Cornell

DOM 조작은 테이블 기반 레이아웃에서 어렵습니다.

시맨틱 div :

$('#myawesomediv').click(function(){
    // Do awesome stuff
});

테이블 포함 :

$('table tr td table tr td table tr td.......').click(function(){
    // Cry self to sleep at night
});

두 번째 예제는 어리석은 일이며, 테이블이나 td 요소에 항상 ID 나 클래스를 적용 할 수 있습니다.하지만 이는 테이블 지지자가 너무 격렬하게 반대하는 의미 값을 추가하는 것입니다.

3
Chris Fletcher

나는 어떤 문제가 이미 다루어지지 않은 것을보고 놀랐다. 그래서 여기에 나의 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. 다른 문제에 대한 다른 해결책

"모든 사람들이 divs & CSS를 알고 있기 때문에"레이아웃 테이블은 일반적으로 무시됩니다.

그러나 테이블은 작성하기가 더 쉽고 이해하기 쉽고 대부분의 CSS 레이아웃보다 견고합니다. (그렇습니다, CSS는 견고 할 수 있습니다, 그러나 다른 브라우저 및 화면 해상도에서 그물을 통해 빠른보기는 종종 그렇지 않다는 것을 보여줍니다)

유지 관리, 유연성 부족 등 테이블에 대한 많은 단점이 있지만 ... 목욕탕에 아기를 던지지 않겠습니다. 빠르고 신뢰할 수있는 솔루션을위한 전문적인 용도가 많이 있습니다.

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

나는 무릎 덩어리 반응에 아팠고 지쳤다. "Oh noes! 레이아웃 테이블!"

"그 목적을 위해 의도 된 것이 아니므로이 방법으로 사용하면 안됩니다"군중, 위선이 아닌가? 대부분의 브라우저에서 제대로 작동하는 데 필요한 CSS 트릭을 어떻게 생각하십니까? 그 목적을위한 것이 었습니까?

3
Sylverdrag

테이블을 사용하는 사이트를 유지하는 것이 좋으며 코드를 작성하는 데 시간이 오래 걸립니다. 떠 다니는 div가 두렵다면, 그 길을 따라 가세요. 그들은 이해하기 어렵지 않고 엉덩이에 약 100 배나 더 효율적이고 백만 시간 덜 고통 스럽습니다 (이해하지 못하면 제외하고 컴퓨터의 세계에 오신 것을 환영합니다).

테이블을 가지고 레이아웃을하는 것을 고려하는 사람은 내가 그것을 유지할 것을 기대하지 않습니다. 그것은 웹 사이트를 렌더링하는 가장 엉덩이 - 뒤로 방법입니다. 우리는 지금 훨씬 더 나은 대안을 가지고 있습니다. 나는 결코 다시 가지 않을 것이다.

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

3
Chuck Le Butt
  1. 병합/10/20 깊은 colspan/rowspan 분할 시도하십시오. 한 번 이상 나는 누군가와 싸움을 시작하기 위해 본능을 억제해야했습니다. [?!]
  2. 표시 순서를 변경하지 않고 소스 코드 순서를 변경하십시오. [SEO, 유용성, ...]
  3. 우리가보고있는 바로 그 페이지는 ~ 150K입니다. 적절한 CSS를 사용하면 거의 절반으로 줄일 수 있습니다. [SEO (예, SEO, 최신 Google 사양 읽기 등), perfo, ...]
  4. 임의의 너비에서 작동 할 수있는 반복기 템플릿을 만들어보십시오.
  5. 이 표에 기반한 SO 매체의 문제에 대한 논의는 특이점을 유발하고 우리 모두를 파괴 할 수 있습니다
2
Halil Özgür

엄격하게 표현과 내용을 분리하는 문제는 C++의 구현 파일에서 헤더 파일을 분리하는 것과 거의 비슷합니다. 그것은 의미가 있지만 고통 일 수도 있습니다. Witness Java와 C #은 클래스가 단일 소스 파일에 정의되어 있습니다. 더 새로운 언어의 저자는 프로그래머 두통을 일으키는 원인이되고있는 무언가를주의하고 그것을 제거했다. 이것이이 토론의 요지 인 것 같습니다. 한 편은 CSS가 너무 어렵다고 말하면서, 다른 쪽은 CSS 마스터가되어야한다고 말하고 있습니다.

간단한 레이아웃 문제 때문에 프레젠테이션이 완전히 분리되어야한다는 규칙을 왜 굽히지 않으십니까? HTML로 직접 프리젠 테이션을 제어 할 수있게 해주는 새로운 태그 (또는 div 태그에 대한 확장 기능)는 어떨까요? 어쨌든 우리는 이미 프레젠테이션을 HTML로 유출하지 않았습니까? h1, h2 ... h6를보십시오. 우리 모두는 이러한 컨트롤 프레젠테이션을 알고 있습니다.

코드 (및 HTML은 코드)를 읽을 수있는 능력이 매우 중요합니다. 전문가는 가능한 한 대중에게 접근 가능한 프로그래밍 환경을 만드는 것이 얼마나 중요한지 간과하는 경향이 있습니다. 전문 프로그래머 만이 중요하다고 생각하는 것은 매우 근시안적입니다.

2
user825628

나를 위해 큰 문제는 테이블, 특히 중첩 된 테이블, 적절하게 배치 된 CSS 구현보다 렌더링하는 데 오래 걸립니다. (You can css를 느리게 만들 수 있습니다.).

모든 브라우저는 각 div가 별도의 요소이기 때문에 CSS를 더 빨리 렌더링하므로 사용자가 읽는 동안 화면이로드 될 수 있습니다. (대용량 데이터 세트 등). 그 인스턴스의 테이블 대신 CSS를 사용하여 레이아웃을 처리하지도 않습니다.

중첩 테이블 (셀 안의 테이블 등)은 마지막 "/ 테이블"이 발견 될 때까지 브라우저 윈도우에 렌더링되지 않습니다. 더욱 나쁜 것은 - 잘 정의되지 않은 테이블은 심지어 언젠가 렌더링하지 않을 것입니다! 그렇지 않으면 일이 오동작합니다. ( "TD"등으로 제대로 열거되지 않음)

대부분의 경우 테이블을 사용하지만 큰 데이터와 최종 사용자를 위해 화면을 빠르게 렌더링하려는 욕구에 대해서는 CSS가 제공하는 것을 최대한 활용하려고 노력합니다.

2
Tim Fischer

나는 두 가지 방법으로 사이트를 운영해야했고, 세 번째로 테이블, div 및 스타일이 포함 된 두려운 "하이브리드"레이아웃을 작성해야했습니다. Divs/CSS가 도움이되었습니다.

박쥐 바로 한 테이블 셀의 코드 가중치와 일치 시키려면 divs를 세 개 중첩시켜야합니다. 이 효과는 중첩 테이블과 함께 확장됩니다.

나는 또한 내 사이트의 모든 페이지에 대해 하나의 변경 대 하나의 레이아웃을 변경하는 것을 선호합니다.

Divs/css로 프리젠 테이션의 모든면을 완벽하게 제어 할 수 있습니다. 테이블은 끔찍한 방식으로, 특히 IE에서는 아직 지원하지 않을 옵션이없는 브라우저를 사용합니다.

Divs/css 웹 사이트의 유지 보수 또는 재 설계를위한 내 시간은 테이블에있는 것의 일부분입니다.

마지막으로 CSS와 사실상 모든 스크립팅 언어로 전환 가능한 레이아웃을 혁신 할 수 있습니다. 그것은 테이블을 가지고 나에게는 불가능할 것이다.

결정을 내릴 때 투자 수익 (ROI)과 함께 행운을 빈다.

2
John Dunagan

한 가지 예 : 페이지의 주 컨텐츠 영역을 가운데에 놓고 싶지만 내부에있는 수납 물을 포함하려면 플로트해야합니다. CSS에는 "float : center"가 없습니다.

그것이 중심 요소 안에 "수레 포함"하는 유일한 방법은 아닙니다. 그래서 전혀 좋은 주장이 아닙니다!

어쨌든 그것은 거짓 전제, "divs 대 테이블"것입니다.

페이지를 세 개의 열로 빠르게 나누는 것은 어떨까요? 테이블 쉽습니다. 솔직히 말해서. 그러나 전문가들은 페이지 요소의 위치를 ​​페이지에 고정시키기 때문에 더 이상 레이아웃에 사용하지 않습니다.

진정한 논거는 "페이지에서 HTML에 의한 위치 지정"과 대조적으로 "CSS (바라 건 말하자면 원격 파일)에 의한 위치 지정"입니다. 분명히 후자와 반대로 모두가 후자의 이점을 볼 수 있습니까?

  1. 크기 - 페이지 레이아웃이 HTML에 있거나 페이지에서 캐시 될 수없고 모든 페이지에서 반복되어야합니다. 레이아웃이 페이지가 아닌 캐시 된 CSS 파일에 있으면 엄청난 양의 대역폭을 절약 할 수 있습니다.
  2. 여러 개발자가 동시에 같은 페이지에서 작업 할 수 있습니다. HTML에서 작업하고 다른 사람은 CSS에서 작업합니다. 저장소 필요 없음, 덮어 쓰기, 파일 잠금 등의 문제 없음.
  3. 변경하는 것이 더 쉽습니다. 다른 브라우저에서 레이아웃에 문제가있을 수 있지만 CSS 파일 하나만 수정하여 정렬 할 수 있습니다.
  4. 접근성은 이전에 많이 언급했듯이 테이블은 모든 사람이 2 차원 레이아웃을 사용할 수 있다고 가정합니다. 그것은 일부 사용자가 귀하의 콘텐츠를 보는 방식이 아니며 Google이 귀하의 콘텐츠를 보는 방식이 아닙니다.

이걸 고려하세요:

[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]

6 셀이있는 테이블의 두 행을 나타냅니다. 2 차원 테이블 레이아웃을 볼 수있는 사람은 각 그림 아래에 캡션이 표시됩니다. 그러나 음성 합성, PDA 또는 검색 엔진 스파이더를 사용하면

picture picture picture caption caption caption

그 자리에있는 테이블에서 명백한 관계가 사라집니다.

가능한 가장 짧은 시간에 주어진 디자인을 달성하기 위해 HTML 페이지에 사각형을 배치하는 작업에 DIV와 CSS를 더 잘 사용합니까? 아니, 아마 그렇지 않을거야. 그러나 주어진 디자인을 달성하기 위해 직사각형을 빠르게 배치하는 것은 아닙니다. 나는 훨씬 더 큰 그림을 생각하고있다.

2
AmbroseChapel

내용과 레이아웃을 분리하면 다른 html 파일을 만들지 않고도 프린터 친화적 인 레이아웃이나 사이트의 다른 스킨 (스타일)을 쉽게 생성 할 수 있습니다. Firefox와 같은 일부 브라우저는보기 메뉴에서 스타일 시트를 선택할 수도 있습니다.

테이블없는 레이아웃을 유지하는 것이 더 쉽다고 생각합니다. rowspans, colspans 등에 대해 걱정할 필요가 없습니다. 컨테이너 div를 만들고 필요한 곳에 콘텐츠를 배치하면됩니다. 그리고 그것은 내가 더 읽기 쉽다고 (<div id="sidebar"><tr><td>...</td><td>...<td>sidebar</td></tr>) 생각했다.

그것은 당신이 배워야 만하는 조금의 "속임수"입니다. (그리고 당신이 그 트릭을 마스터하면, 더 쉽고 더 합리적이라고 생각합니다).

2
Grad van Horck

"테이블은 더 느립니다"라는 주장에 응답하려면 렌더링 시간을 생각하고 있습니다. 이는 잘못된 척도입니다. 매우 자주 개발자는 페이지 레이아웃 전체를 수행하는 거대한 테이블을 작성하여 다운로드 할 페이지의 크기를 크게 늘릴 수 있습니다. 좋든 싫든, 거기에는 여전히 많은 전화 접속 사용자가 있습니다.

ViewState 오버플로

1
Greg Hurlman

과거의 경험으로 볼 때 DIV에 가야합니다. OOP에서도 주요 목표는 객체 간의 결합을 줄이는 것이므로이 개념을 DIVS와 표에 적용 할 수 있습니다. 표는 데이터를 보관하는 데 사용되며 페이지 주위에 배치하는 데 사용되지는 않습니다. DIV는 페이지 주위에 항목을 정렬하도록 특별히 설계되었으므로 디자인에서 DIV를 사용해야하고 테이블은 데이터를 저장하는 데 사용해야합니다.

또한, 테이블로 만든 웹 사이트를 편집하는 것은 매우 어렵습니다 (제 생각에는)

1
Richard

div와 CSS 포지셔닝은보다 유연한 디자인을 가능하게하여 웹 페이지를 쉽게 수정하고 템플리트 화하도록합니다.

즉, 유연성에 관심이 없다면 CSS로 표로 변형 된 일부 div가 아닌 표를 사용하는 것이 확실히 쉽고 빠를 수 있습니다. 나는 테이블을 좀 더 빨리 볼 수 있도록 디자인을 할 때 테이블을 사용하는 경향이있다.

1
workmad3

CSS를 사용하여 레이아웃을 디자인 할 때 일반적으로 모든 주요 섹션에 고유 한 루트 (본문 레벨) div를 제공하고 상대/절대 위치 지정을 사용하여 적절한 위치에 배치합니다. 행과 열을 사용하여 나타낼 수있는 배열로 제한되지 않기 때문에 이것은 테이블보다 약간 융통성이 있습니다.

또한 레이아웃을 다시 정렬하기로 결정하면 (즉, 탐색 표시 줄을 지금 당장 원할 것입니다) 간단히 한곳에서 요소의 위치 (CSS 파일)를 변경하고 HTML은 ' 변경하지 않아도됩니다. 내가 테이블로 그렇게하고 있다면 같은 정보를 얻기 위해 정보를 찾아야하고 속성 모딩 및 복사 및 붙여 넣기를 많이해야합니다.

실제로 CSS를 사용하여 sers 레이아웃 작동 방식을 선택할 수도 있습니다. 콘텐츠 영역의 일반적인 크기가 변경되지 않는 한 약간의 PHP 스크립팅을 사용하여 사용자 기본 설정에 따라 CSS를 출력하고 사이트를 자신의 취향. 다시 한 번 테이블에서 가능하지만 유지 관리가 훨씬 더 어렵습니다.

마지막으로, CSS는 테이블이 결코 제공 할 수없는 하나의 주요 이점, 즉 디스플레이 장치를 기반으로 컨텐츠를 다시 포맷하는 기능을 허용합니다. CSS를 사용하면 모니터에 사용하는 것과 스타일이 완전히 다른 스타일 (위치, 서식 등)을 사용할 수 있습니다. 이것은 다른 미디어로도 확장 될 수 있으며, 훌륭한 예는 Opera Show로, 똑똑하게 디자인 된 (그리고 매우 표준적인) CSS 향상 페이지를 슬라이드 쇼로 볼 수 있습니다.

결국 유연성과 관리가 진정한 승자입니다. 일반적으로 CSS를 사용하면 레이아웃으로 더 많은 것을 할 수 있습니다. 테이블 기반 레이아웃에 대해 기술적으로 비표준은 없지만 왜 자신을 제한하고 싶습니까?

1
Nicholas Flynt

과거에는 화면 판독기 및 기타 접근성 소프트웨어가 테이블을 효율적으로 처리하는 데 어려움을 겪었습니다. 어느 정도까지, 이것은 독자가 테이블 내부에서 본 것을 토대로 "테이블"모드와 "레이아웃"모드를 전환하여 스크린 리더에서 처리하게되었습니다. 이것은 종종 잘못되어 테이블을 탐색 할 때 사용자가 수동으로 모드를 전환해야했습니다. 어쨌든 크고 종종 자주 중첩 된 테이블은 화면 판독기를 사용하여 탐색하는 것이 매우 어렵습니다.

Div 나 다른 블록 레벨 요소를 사용하여 테이블을 다시 작성하고 중첩 된 경우에도 마찬가지입니다. div의 목적은 fomating 및 layout 요소로 사용되므로 유사한 정보를 보유하고 시각적 인 사용자를 위해 화면에 레이아웃하는 데 사용됩니다. 화면 판독기가 페이지를 만날 때 CSS 기반 및 HTML 기반 기반의 레이아웃 정보를 무시합니다 (모든 화면 판독기에는 해당되지 않지만 JAWS, Windows Eyes 및 Linux 용 Orca입니다.).

이를 위해, 테이블 형식의 데이터, 즉 여러 가지 차원에서 논리적으로 의미가있는 데이터를 일종의 헤더로 정렬하는 것이 테이블에 가장 적합하고 div를 사용하여 페이지의 내용 레이아웃을 관리합니다. ( "표 형식 데이터"가 무엇인지 생각하는 또 다른 방법은 그것을 그래프 형식으로 그리는 것입니다 ... 가능하지 않으면 테이블에서 가장 잘 표현되지 않을 수 있습니다)

마지막으로 테이블 기반 레이아웃을 사용하면 페이지의 요소 위치를 세부적으로 제어 할 수 있도록 매우 중첩 된 테이블이 자주 사용됩니다. 이것은) 두 가지 효과가 있습니다 : 1. 각 페이지의 코드 크기 증가 - 탐색 및 공통 구조가 종종 테이블로 수행되기 때문에 각 요청에 대해 동일한 코드가 네트워크를 통해 전송되는 반면 div/css 기반 레이아웃은 css 파일을 가져옵니다 한 번 이상, 그리고 적은 wordy divs를 사용합니다. 2.) 많이 중첩 된 테이블은 클라이언트 브라우저에서 렌더링하는 데 훨씬 오래 걸리고로드 시간이 약간 느려집니다.

두 경우 모두, "last mile"대역폭의 증가는 훨씬 빠른 개인용 컴퓨터뿐만 아니라 이러한 요소를 완화 시키지만 많은 사이트에서 여전히 존재하는 문제입니다.

이 모든 것을 염두에두고 다른 사람들이 말했듯이 테이블은 그리드 지향적이기 때문에 테이블이 더 쉽습니다. 문제의 사이트가 오래 머물지 않거나 유지되지 않을 것으로 예상되는 경우 가장 비용 효율적인 사이트 일 수 있으므로 가장 쉬운 일을하는 것이 좋습니다. 그러나 예상 사용자 기반에 장애인이 상당 부분 포함되어 있거나 오랜 시간 동안 다른 사람이 사이트를 유지 관리하는 경우 간결하고 액세스하기 쉬운 방법으로 일을 처리하는 데 시간을 할애해야 결국 더 많은 성과를 거둘 수 있습니다.

1
cdeszaq

Divs/CSS를 사용하여 모든 브라우저에서 변경 사항을 적용 할 수 있는지 테스트 할 때 페이지 디자인을 변경하는 것이 더 쉬운 방법인지, 특히 모든 해킹이 있는지를 이해하는 것은 여전히 ​​어렵습니다. 많은 시간과 돈을 낭비하는 엄청난 좌절감과 지루한 과정. 고맙게도 508 법안은 미국에만 적용되며 (예 : 무료 - 그래 맞은 나라) 영국에 본사를 둔 것처럼 내가 선택한 스타일로 웹 사이트를 개발할 수 있습니다. 대중의 (미국) 신념과는 달리 워싱턴에서 제정 된 법률은 다른 국가에도 적용되지 않습니다. 법안이 발효 된 날은 웹 디자인 세계에서 좋은 날이었을 것입니다. 나는 IT 업계에서 25 년 동안 나이가 들어감에 따라 점점 더 냉소적으로 변해가고 있다고 생각하지만, 이런 종류의 법안은 단지 직업을 보호하는 것이라고 생각합니다. 현실에서는 누구나 합당한 웹 페이지를 두 개의 테이블과 함께 쓸 수 있습니다. DIV/CSS로이 작업을 수행하는 데는 많은 노력과 지식이 필요합니다. 제 경험으로는 몇 시간이 걸릴 수 있습니다. 아주 간단한 문제에 대한 해결책을 찾고, 이상 주의적 열광적 인 사람들로 가득 찬 포럼에서 이해할 수없는 기사를 읽으면 모든 일을 '옳은'방법으로 논합니다. 발가락을 물에 담그고 모든 경우에 올바르게 작동하도록 할 수는 없습니다. 또한 DIVS/CSS를 사용하는 데있어 결정적인 가이드가 부족하여 모든 상황에 적용 할 수 있으며 브라우저에서 작업하고 괴짜로 말하면서 '보통'언어를 사용하여 작성한 것으로 보입니다. 약간의 보호주의.
저는 응용 프로그램 개발자이고 기본 응용 프로그램을 만들고, 비즈니스 개체를 디자인하고 구현하고, 데이터베이스를 만드는 것보다 레이아웃 문제를 파악하고 모든 브라우저를 테스트하는 데 거의 두 배의 시간이 걸립니다. 백 엔드. 내 시간 = 돈, 둘 다 나와 내 고객 모두를위한 것입니다. 그래서 비용 절감과 고객을위한 돈 가치 제공에 찬성하여 모든 프로 DIV/CSS 주장을 거부하지 않으면 유감입니다. 어쩌면 개발자가 생각하는 방식 일 수도 있지만 복잡한 테이블 구조를 변경하는 것이 DIV/CSS를 수정하는 것보다 훨씬 쉽습니다. 고맙게도 이제는 이러한 문제에 대한 솔루션 인 WPF가 제공됩니다.

1
Tim Black

나는 아무도 웹 사이트가 어떻게 설계되고 구현되는지를 신경 쓰지 않는다.

HTML 마크 업에서 "table"과 "div"/ "span"태그를 모두 사용합니다.

Div를 선택하는 이유에 대해 몇 가지 주장을하겠습니다.

  1. 멋진 디자인을 위해 적어도 3 개의 태그 (table, tr, td, thead, tbody)를 작성해야하는 테이블의 경우 중첩 된 테이블이 많을 때가 있습니다

  2. 페이지에 구성 요소가 있습니다. 나는 정확하게 설명하는 방법을 모르지만 시도 할 것이다. 로고가 필요하다고 가정하고 다음 페이지 내용에이 로고를 배치해야합니다. 표를 사용하여 2 개의 이미지를 자르고이를 2 개의 다른 TD에 넣어야합니다. DIV를 사용하면 간단한 CSS를 사용하여 원하는대로 정렬 할 수 있습니다. 어떤 솔루션이 가장 좋습니까?

  3. 뭔가를하기 위해 3 개 이상의 중첩 테이블을 사용할 때 DIV를 사용하여 테이블을 다시 디자인하려고합니다.

그러나 나는 아직도 테이블을 사용하고있다 :

  1. 표 데이터

  2. 자기를 확장하고있는 콘텐츠

  3. dIVs 상자 모델은 브라우저마다 다르므로 많은 솔루션이 프로토 타입입니다. 많은 발전기가 테이블 등을 사용하기 때문입니다.

1
Dani

레이아웃을 위해 여전히 테이블을 사용함으로써 우리는 div 부문의 혁신에 빠져 있습니다.

많은 사람들이 div의 레이아웃을 쉽게 만들 수있는 솔루션을 제시했습니다. 가장 인기있는 것은 그리드 아키텍처입니다. 이 아키텍처를 기반으로하는 동적 레이아웃 생성기가 있습니다. 체크 아웃 : 1) 960.gs 및 (http://grids.heroku.com/) 2) 청사진과 너무 늦었 어.

테이블 레이아웃이있는 아키텍처 및 도구 측면에서 혁신을 많이 보지 못했습니다.

나는 모든 이론을 제쳐두고 CSS와 div를 사용한 레이아웃이 더 빠르다고 말할 것이다. 오히려이 방향으로의 혁신은 무엇보다도 쉽게 만들었습니다.

1
Pixelgrey

테이블은 단순하거나 일시적인 것을 위해 함께 던지는 HTML에 적합합니다. 대규모 웹 사이트를 구축하는 경우 div 및 CSS를 사용해야합니다. 웹 사이트가 변경되면 시간이 지남에 따라 관리하기가 더 쉬워지기 때문입니다.

1
Adam Rosenfield

1 : 그렇습니다. 스크린 리더를 사용하면 사라집니다. 페이지에서 정보를 추출하려고 시도하는 다른 도구를 사용하는 경우 테이블 형식 데이터를 나타내는 데 사용되지 않는 테이블이 표시되는 것은 잘못된 것입니다.

Div 또는 span은 내용을 분리하는 데 허용됩니다. 정확히 해당 요소의 의미 임. 검색 엔진, 스크린 리더 또는 기타 다른 요소가 테이블 요소를 만나면 "다음은 테이블에 표시되는 테이블 형식의 데이터"를 의미합니다. 우리가 div를 만나면 "이것은 div 내 콘텐츠를 별도의 부분이나 영역으로 옮기는 데 사용되는 요소입니다.

2 : 가독성 : 잘못되었습니다. 모든 프리젠 테이션 코드가 CSS에 있으면 HTML을 읽을 수 있으며 페이지의 내용을 이해할 수 있습니다. 또는 CSS를 읽고 프레젠테이션을 이해할 수 있습니다. 모든 것이 html로 뒤죽박죽이면 내용과 내용이 무엇인지 알기 전에 모든 프레젠테이션 관련 비트를 정신적으로 파헤쳐 야합니다. 또한 CSS를 이해하지 못하는 웹 개발자를 만나기가 무서워서 실제로 문제가되지 않는다고 생각합니다.

3 : 테이블이 느립니다 : 예. 이유는 간단합니다. 테이블을 렌더링하기 전에 포함 내용을 완전히 구문 분석해야합니다. div는 before 내용이 구문 분석 된 경우에도 렌더링 할 수 있습니다. 즉, 페이지로드가 완료되기 전에 div가 표시됩니다.

그리고 테이블이 훨씬 더 깨지기 쉬우 며 다른 글꼴과 글꼴 크기 및 레이아웃을 변경시킬 수있는 다른 모든 요소와 함께 다른 브라우저에서 항상 동일하게 렌더링되지는 않습니다. 표는 특정 브라우저에서 한 픽셀 씩 사이트를 벗어나게하거나 사용자가 글꼴 크기를 변경하거나 다른 방식으로 설정을 변경할 때 확장 성이 떨어지지 않도록하는 훌륭한 방법입니다.

물론 # 1이 큰 것입니다. 많은 도구와 응용 프로그램은 웹 페이지의 의미 적 의미에 따라 다릅니다. 일반적인 예는 시각 장애인을위한 스크린 리더입니다. 웹 개발자 인 경우 다른 방법으로 사이트에서 일하기 위해 귀하를 고용 할 수있는 많은 대기업이 있습니다. 필수이 경우에도 사이트에 액세스 할 수 있습니다. 이는 HTML의 의미 적 의미에 대해 생각해야한다는 것을 의미합니다. 시맨틱 웹 또는보다 관련성이 높은 마이크로 포맷, RSS 리더 및 기타 도구를 사용하면 더 이상 브라우저를 통해서만 페이지 컨텐츠를 볼 수 없습니다.

1
jalf

내 영어가 유감이지만 다른 이유가 있습니다.

나는 어떤 정부 조직에서 일했고 테이블을 사용하지 않는 가장 큰 이유는 장애인들을위한 것입니다. 그들은 기계를 사용하여 웹 페이지를 "번역"합니다.

문제는이 "번역 기계"가 TABLE에 의해 완료되면 웹 사이트를 읽을 수 없다는 것입니다. 왜 ? TABLE은 DATAS 용입니다.

사실, 테이블을 사용하는 경우 각 CELLS에 대해 장애인이 테이블에있는 위치를 알 수 있도록 일부 정보를 지정해야합니다. 큰 테이블이 있고 화면의 셀 하나만 보이도록 확대해야한다고 가정 해보십시오. 셀이 어느 라인인지 알고 있어야합니다.

따라서 DIV가 사용되며 장애인은 단순히 텍스트를 읽을 수 있으며 행/열에 대해 별다른 정보를 얻지 못하면 별다른 정보를 얻지 못합니다.

나는 또한 빠르고 쉬운 템플릿을 만들기 위해 TABLE을 선호하지만, 이제는 CSS에 익숙해졌습니다 ... 강력하지만 실제로 당신이하는 일을 알고 있어야합니다. :)

1
RVeur23

Flex에는 세로 열에 배치하기위한 태그가 있습니다. 나는 그들이 전체 레이아웃/내용이 정직하다고 생각하지는 않지만 적어도 그 문제를 해결했습니다.

CSS로 좌절 한 많은 사람들과 마찬가지로 쉽게 대답하기 위해 멀리서도 넓게 보았고 그것을 발견했다고 생각했을 때 기분이 상한 느낌에 빠져 버렸습니다. 그런 다음 Chrome에서 페이지를 열 때 희망이 사라졌습니다. 나는 그것이 불가능하다고 말할만큼 충분히 숙련되지는 않았지만, 누군가가 동료 검토를 위해 샘플 코드를 제공하여 확실하게 수행 할 수 있음을 분명히 보지 못했습니다.

그렇다면이 섬의 CSS 측 누군가가 세로 기둥을 배치하기위한 사고 방식/방법론을 추천 할 수 있습니까? 나는 두 번째와 세 번째 행에서 절대 위치 지정을 시도했지만 모든 곳에서 겹치는 물건으로 끝나고 페이지가 축소되면 float도 비슷한 문제가 있습니다.

이것에 대한 답변이 있다면 -(- 올바른 일을하세요 - "이봐 ** 흐름 : 세로 | 가로"를 시도했는데 머리가 완전히 없어졌습니다.

1
Shanimal

Google은 표 안에 포함 된 텍스트 콘텐츠에 매우 낮은 우선 순위를 부여합니다. 나는 자선 단체에 SEO 조언을하고 있었다. 그들의 웹 사이트를 조사 할 때 테이블을 사용하여 사이트를 레이아웃했습니다. 각 페이지를 볼 때, Google 검색 상자에 사용 된 자신의 페이지에서 어떤 단어 나 단어의 조합이 있더라도 페이지는 최상위 검색 페이지에 나타나지 않습니다. 그러나 검색에서 사이트를 지정하면 페이지가 반환되었습니다. 한 페이지는 정상적인 표준에 의해 작성된 사본으로 검색 결과를 좋게 만들지 만 반환 된 검색 결과의 첫 번째 페이지에는 나타나지 않았습니다. . (이 텍스트는 표 안에 있음을 알 수 있습니다.) 그런 다음 표 대신 div에 있던 페이지의 텍스트 섹션을 발견했습니다. 검색 엔진에 해당 div의 단어 몇 개를 입력합니다. 결과? 검색 결과에서 2 위를 차지했습니다.

1
Simon Measures

한 번에 테이블이로드된다는 것을 알게되었습니다. 즉, 연결이 느릴 때 테이블 전체가로드 될 때까지 테이블이 비어있는 공간이 유지되고 다른 한 손으로 div가 데이터가 오면 빠르게 위에서 아래로로드됩니다. 그리고 그것은 이미 완료되었는지 여부에 관계없이.

1
Davy

요소가 레이아웃의 특정 물리적 관계를 유지할 필요가있을 때 테이블을 사용하십시오. 데이터의 경우, 일반적으로 테이블은 uxexpected 방법으로 열을 감싸고 연관을 혼동하지 않기 때문에 사용할 최적의 레이아웃 요소입니다.

특정 관계에 있어야하는 비 데이터 요소도 테이블에 렌더링되어야한다고 주장 할 수 있습니다.

유연한 CSS 레이아웃은 휴대 기기 및 대형 화면, 인쇄 및 기타 디스플레이 유형에 적합한 콘텐츠에 적합하지만 때로는 매우 구체적인 방식으로 콘텐츠를 표시해야하며 화면 판독기가 쉽게 액세스 할 수 없도록 요구하는 경우가 있습니다. 그것은 정당화 될 수 있습니다.

1
Sal

가능한 한 많은 테이블을 피하려고 노력하지만 여러 컨트롤 유형과 그룹화에 대한 매우 엄격한 컨트롤을 사용하는 캡션 위치를 혼합 한 복잡한 양식을 디자인 할 때는 DIV를 사용하는 것이 신뢰할 수 없거나 거의 불가능할 수도 있습니다.

이제는 DIV 기반 레이아웃을보다 잘 수용하기 위해 이러한 양식을 다시 디자인 할 수는 없지만 일부 고객의 경우 기존 레이아웃을 이전 버전 (기존 ASP로 작성)에서 변경하지 않는 것이 중요합니다. 사용자가 익숙한 종이 양식.

양식의 표현은 동적이기 때문에 (일부 섹션의 표시는 사례의 상태 또는 사용자의 권한을 기반으로합니다), 논리적으로 그룹화 된 양식 요소의 TABLE을 각각 포함하는 스택 된 DIV 세트를 사용합니다. TABLE의 각 열은 CSS에 의해 제어 될 수 있도록 분류됩니다. 그렇게하면 DIV의 행을 감싸는 테이블이 아닌 문제없이 폼의 다른 섹션을 끌 수 있습니다.

1
CMPalmer

나는 몇 년 전에 스크린 리더와 테이블 문제를 연구하고 대부분의 개발자들이 믿는 것과 모순되는 정보를 생각해 냈습니다.

http://www.webaim.org/techniques/tables/

"접근성 옹호론자들은 레이아웃 테이블이 좋지 않다고 말하면서 CSS 레이아웃 기술을 대신 사용해야한다고 말합니다.하지만 그들이 말한 것에는 진실이 있습니다. 그러나 레이아웃을 위해 테이블을 사용하는 것이 최악은 아닙니다. 접근성 측면에서 할 수있는 일. 모든 종류의 장애를 가진 사람들은 접근성을 염두에두고 설계된 테이블이라면 쉽게 테이블에 액세스 할 수 있습니다. "

1
Rimian

나는 이것이 일반적인 문제와 관련된 문제라고 생각한다. HTML이 태어날 때 아무도는 그것의 대폭적인 사용을 예견 할 수 없었다. 자체 성공의 무게로 거의 붕괴 된 또 다른 기술. 녹색 텍스트 터미널에서 HTML 페이지가 vi 로 작성되었을 때 TABLE은 페이지 방문객에게 데이터를 표시하는 데 필요한 모든 것이 었으며 주로 표 형식으로 이해되는 데이터였습니다.

우리 모두는 사물이 어떻게 진화했는지 알고 있습니다. 테이블은 비교적 최근에 유행을 벗어나지 만, DIV와 CSS 기반 레이아웃 (접근성이 마지막이 아닌)을 선호하는 데는 많은 이유가 있습니다. 물론 나는 내 인생을 살리기 위해 CSS를 쓸 수 없다 :-) 나는 그래픽 디자인 전문가가 항상 가까이 있어야한다고 생각한다.

그것은 말하기를 ... 현대 웹 사이트에서도 테이블에 제시해야하는 많은 데이터가 있습니다.

1
Manrico Corazzi

테이블 각도를 지원하는 경우 테이블이있는 사이트를 찾은 다음 화면 판독기를 가져와 - 화면 판독기를 끄고 모니터를 끄십시오.

그런 다음 의미 론적으로 올바른 div 레이아웃 사이트로 시도하십시오.

차이점을 확인할 수 있습니다.

테이블의 데이터가 페이지 레이아웃이 아닌 테이블 형식 인 경우 테이블은 사악하지 않습니다.

1
Allen Hardy

테이블에 대한 내 지식에 따라 너무 많은 테이블이 중첩되어 있으면 페이지를 렌더링 할 때 브라우저에 큰 오버 헤드가 있습니다.

1 - 브라우저가 전체 테이블이로드 될 때까지 최종 뷰 렌더링 대기를 기다립니다.

2 - 테이블을 렌더링하는 알고리즘은 값 비싸지 않고 한 번에 수행 할 수 없습니다. 브라우저는 콘텐츠를 가져오고 언제 콘텐츠의 너비와 높이를 계산하려고 시도합니다. 따라서 중첩 된 테이블을 가지고있는 경우 브라우저가 첫 번째 행을 받았고 첫 번째 셀에 많은 양의 콘텐츠가 있고 너비와 높이가 정의되어 있지 않으면 너비를 계산하고 첫 번째 행을 렌더링합니다. 2 열은 셀 # 2에 많은 양의 콘텐츠가 있습니다. 이제 2 행 셀의 폭을 계산할 것입니다. 첫 번째 행은 어떨까요? 그것은 재귀 적으로 너비를 계산합니다. 그건 클라이언트 쪽에서 나쁘다. (예를 들어 사이트에) 프로그래머는 데이터를 가져 오는 시간, 최적화 된 데이터 구조 등을 최적화 할 것입니다. 서버 측에서 완료 할 때까지 최적화 할 수 있습니다 (예 : 2 초). 최종 사용자가 최종보기를 가져 오는 데있어 최종 사용자가 8 초. 여기서 뭐가 잘못 됐니? 1. 네트워크가 느릴 수 있습니다! 네트워크가 괜찮 으면 어떨까요? 네트워크가 다음 1 초 안에 내용을 전달하는 것은 무엇입니까? 이 여분의 5 초가 소비되는 곳은 어디입니까? 염려 할 사항 - 브라우저가 테이블을 예측하고 렌더링하는 데 많은 시간을 할애 할 수 있습니다!

테이블을 최적화하는 방법? 표를 사용하는 경우 셀의 너비를 항상 정의하는 것이 좋습니다. 이것은 브라우저가 맹목적으로이 너비만을 차지하는 것을 보장하지는 않지만 브라우저가 초기 너비를 결정할 때 큰 도움이됩니다.

하지만, 결국 div는 브라우저에서 CSS를 캐싱 할 수있는 좋은 방법입니다. 테이블은 캐시되지 않습니다!

1
Biranchi Panda

순수한 레이아웃으로 사용 된 테이블은 액세스 가능성에 대한 몇 가지 문제점을 제기합니다 (나는 들었습니다). 그러나 나는 당신의 페이지에있는 무엇인가의 정확한 정렬을 보장하기 위해 테이블을 사용함으로써 어떻게 든 웹을 무력하게 만들고 있다는 것을 여기서 묻고있는 것을 이해합니다.

나는 사람들이 FORM 레이블과 입력이 실제로 데이터라는 것과 테이블에 들어가야한다고 주장하는 것을 들었습니다.

몇 가지 요소가 올바르게 정렬되도록 테이블을 사용하면 코드에서이 엄청난 증가를 초래한다는 인수는 단일 DIV가 모든 요구를 충족시킬 수있는 방법의 예를 포함하는 경향이 있습니다. 그들은 항상 IE5, IE5.5, IE6, IE7 용으로 작성해야만했던 CSS 행과 특수 브라우저 해킹의 10 줄을 포함하지는 않습니다 ...

나는 당신의 디자인에 균형을 사용하는 것이 남아 있다고 생각합니다. 테이블은 도구 상자에 있습니다.

0
HB

확실히 OP는 약간의 바람이었고, 그 논쟁은 너무 일주일이되어서 쉽게 반박되었습니다.

웹 페이지는 웹 개발자의 영역이며, div와 CSS가 나에게 충분한 표보다 낫다면 말입니다.

서버 애플 리케이션에 의해 생성 된 테이블에 의해 레이아웃이 달성 된 경우, 새로운 레이아웃은 응용 프로그램의 재구성 및 재 작성이라는 응용 프로그램으로 변경되어 css 파일로 변경됩니다.

게다가 접근성. 레이아웃에 사용되는 테이블은 웹 사이트를 액세스 할 수 없게 만들기 때문에 사용할 수 없습니다. 불법은 말할 것도없고 부끄러 울 것도 없습니다.

0
Ian

매우 짧은 대답 : 유지 보수가 가능한 웹 사이트를 디자인하는 것은 테이블로는 어렵고 표준 방법으로는 간단합니다.

웹 사이트는 테이블이 아니며 서로 상호 작용하는 구성 요소 모음입니다. 그것을 테이블로 묘사하는 것은 의미가 없습니다.

0
Rich Bradshaw

내용 유지 (특히 전자 상거래에서 항상 일어나는) 사이트 유지 관리 및 디자인 오버홀 (overhauls) 측면에서 :

컨텐트와 디자인은 테이블을 통해 함께 매쉬됩니다. 컨텐트와 디자인 모두를 업데이트합니다.

콘텐츠를 디자인과 별도로 = 디자인을 업데이트하고 콘텐츠를 약간 변경할 수 있습니다.

제 방식대로했다면 XML을 생성하고 XSLT에서 마크 업으로 변환하고 상호 작용을 위해 CSS와 Javascript로 디자인 한 내용을 PHP 유지할 수 있습니다. 자바쪽에 대해서는 JSTL에서 JSP로 마크 업을 생성한다.

0
mltorrefranca

DIV를 사용하면 쉽게 전환 할 수 있습니다. 예를 들어 다음과 같이 할 수 있습니다.

Menu | Content

Content | Menu

Menu
----
Content

HTML이 아닌 CSS에서 쉽게 변경할 수 있습니다. 여러 스타일 (오른 손잡이, 왼손잡이, 작은 화면 전용)을 제공 할 수도 있습니다.

CSS에서는 인쇄에 사용되는 특수 스타일 시트에서 메뉴를 숨길 수 있습니다.

또 다른 좋은 점은 시각적으로 다른 방식으로 표시 되더라도 콘텐츠가 코드에서 항상 동일한 순서 (메뉴 첫 번째, 내용 이후)에 있다는 점입니다.

0
ofaurax