뉴스 출처: COMSHARP
2008년 후반에 웹 디자이너로서 자신의 코드에 Table을 사용한다는 사실을 인정하기가 부끄럽습니까? 그렇다면 당신은 용기 있는 사람입니다. 웹 디자인은 이상한 산업입니다. 신문을 읽거나 복도에서 광고를 잠금 해제하지만 Table을 사용한다는 사실을 다른 사람에게 알리지 마세요. 소스 코드에서 Table을 찾는 것은 마치 판매원이 바지를 끌어올리다가 흰색 양말을 신고 있는 것을 발견한 것과 같습니다.
테이블이 너무 추악하고 비대해졌습니다. 간단한 내용만 표시하더라도 <table><tr><td> 세 가지 기본 태그가 필요하며, <div와 달리 여러 가지 지저분한 속성이 추가됩니다. > 심플하고 깔끔하며 패셔너블하며, 가장 완벽한 Box 모델을 형성합니다. 안에 물건을 넣고, 싫증나면 자유롭게 수정하면 됩니다. 하나의 레이아웃은 중요하지 않습니다. CSS 정의만 변경하면 완전히 새로운 레이아웃이 탄생합니다. 테이블과 달리 테이블은 행과 열이 있는 식당의 찬장과 같으며 우리처럼 기름기가 많습니다. 지저분하게도 모든 것을 집에 가져가서 구석에 아무렇게나 쌓아두는 부모. Div가 소부르주아지라면 Table은 이 시대에 속하지 않습니다.
즉, 최근 몇 년 동안 W3C는 모두가 중요하다고 생각하지만 모두가 싫어하는 조직입니다. 저는 감히 이렇게 추악한 웹사이트를 본 적이 없습니다. 하지만 그들의 웹사이트는 모든 W3C 표준 검증을 통과할 수 있는 몇 안되는 웹사이트 중 하나입니다. 즉, 그들의 웹사이트는 여전히 매우 추악하지만 문법, 구조 및 접근성 측면에서 완벽하다는 것을 의미합니다. 그러나 이것은 농담입니다. W3C는 매우 중요합니다. 그렇지 않으면 Microsoft는 모든 웹 개발 엔지니어를 돌아올 수 없는 지점으로 데려갈 것입니다. 다행스럽게도 Netscape가 죽은 후 Nirvana는 Firefox를 출시했지만 Opera는 탄생 후 어떤 혜택도 받지 못했습니다. Firefox, 적어도 당신은 도덕적 지원을 받았습니다. 마침내 큰 형이 당신을 돌보러 나온 것을 보셨습니까? 잡스가 돌아온 후, 애플은 예전의 영광을 되찾았습니다. 그제서야 사람들은 세상에 사파리라는 브라우저가 존재한다는 사실을 알게 되었습니다.
W3C에서는 테이블을 사용하여 텍스트, 서식 있는 텍스트, 그림, 링크, 양식 및 기타 테이블을 수용할 수 있다고 말합니다. 그러나 테이블을 순전히 문서 내용을 레이아웃하는 수단으로 사용해서는 안 됩니다. 또한, Table은 대형 디스플레이 장치에서 사용자가 좌우로 스크롤하도록 강제하므로 Table 대신 웹 디자이너 CSS를 사용해야 합니다. 테이블 정의는 W3C HTML 4.01을 참조하세요. W3C가 이 말을 한 때는 1999년 12월 24일이었습니다. CSS가 탄생한 지 오래되었지만 원래의 웹은 문서의 온라인 버전 같았고 지금과 같은 플랫폼이 되지는 않았습니다. 첫 번째 인터넷 버블이 형성되면서 수많은 포털 웹사이트가 등장했는데, 포털 웹사이트의 홈페이지가 신문 전체 페이지를 합친 것보다 크기 때문에 테이블 레이아웃의 창시자가 되었습니다. Complex, Table은 이 점에서 매우 편리합니다. colspan과 rolspan을 결합하면 거의 모든 복잡한 레이아웃을 얻을 수 있습니다.
이 레이아웃 스타일은 2000년대 초반부터 2000년대 중반까지 특히 중국에서 큰 인기를 끌었습니다. Da Weimei의 잠재의식 아래서 사람들은 한 페이지에 담을 수 있는 모든 것을 홈페이지에 집어넣었습니다. 옛날에는 모든 것이 질서정연하게 배열될 수는 없지만 적어도 같은 순서로 배열되어 있습니다. 그러나 이러한 종류의 웹은 마침내 사람들이 혐오감을 느끼게 되는 지경에 이르렀습니다. 검색, RSS 구독, 블로그로 대표되는 개인화 웹이 등장하면서 사람들은 꼭 필요한 소수의 웹사이트를 방문하지 않고도 정보를 얻을 수 있는 채널이 더 많아졌습니다. 기절한 포털의 홈페이지에는 더 단순한 레이아웃, 더 밝은 색상, 큰 아이콘, 큰 배너, 읽기 쉬운 큰 글꼴을 사용하는 신선하고 가벼운 웹 스타일이 등장했습니다. CSS는 이미 매우 성숙했고, Firefox, Opera, Safari와 같은 브라우저는 W3C 표준을 준수하는 데 있어서 IE보다 훨씬 뛰어났습니다. 사람들은 마침내 CSS의 힘을 깨달았습니다. CSS의 핵심은 레이아웃 측면에서 Box 모델이기 때문에 CSS가 첨부할 컨테이너 객체를 찾아야 합니다.
Div는 당연히 Box의 최고의 프로토타입이기 때문에 Div는 겉으로 보기에는 박스형입니다. 미리 특별한 의미를 부여합니다(Box 모델에서도 사용할 수 있음). 반면에 부풀어오른 시대를 지배하는 테이블에 대한 사람들의 증오심으로 인해 시대가 끝나면 후임자들은 오래된 것을 지우기 위해 열심히 노력할 것입니다. 시대의 흔적, 구시대의 상징이나 대표자들의 운명은 대부분 이렇다.
테이블에 대한 모든 부당한 대우는 여기서부터 시작된다. 왜 불공평합니까? W3C에서는 테이블 레이아웃을 권장하지 않고 대신 CSS를 사용해야 한다고만 말합니다. 테이블이 CSS를 지원하지 않는다는 것은 무엇을 의미합니까? 물론 지원되며 Table은 오래된 HTML 객체이고 그 상태가 매우 중요하기 때문에 모든 브라우저는 CSS 지원을 포함하여 Table에 대한 가장 완벽한 지원을 제공합니다. 사람들이 Div를 수용할 때 Table도 Box이고 내부 셀이 여러 개 있는 Box라는 사실을 잊어버린 것 같습니다. Table은 전체적으로 Box 모델과 Margin을 제외하고 내부 셀 측면에서 Div와 차이가 없습니다. 이는 여전히 상자이며 내부 상자에는 이해해야 할 마진 개념이 포함되어 있지 않습니다. 말할 필요도 없이 Div는 훌륭합니다. 그러나 사람들이 Div + CSS라고 하면 Table이 CSS를 사용할 수 없다는 뜻인 것 같습니다.
Div가 지원하는 모든 CSS 속성은 Table에서 지원됩니다. 실제로 Div가 대중화되기 전에 Div의 얼리 어답터들은 Table이 할 수 있다면 Div도 할 수 있을 것이라고 거의 확신하지 못한 채 말했습니다. 가격을 고려하면 Divs에서 수직 중앙 정렬을 달성하려는 사람들은 내가 의미하는 바를 이해할 것이며, CSS Hack 없이 IE6에서 100% Div 레이아웃을 달성하려는 사람들은 내가 의미하는 바를 훨씬 더 이해할 것입니다. 100% 높이 문제, 여러 Div 사이의 너비 적응 문제, Div + CSS 디자인에 종사하는 사람이라면 누구나 겪게 될 것이라고 믿습니다. 이런 점에서 테이블의 장점은 그것이 뛰어나기 때문이 아니라 오래되었고 어떤 브라우저도 그것을 무시할 수 없기 때문이기도 합니다. 또한 사람들은 데이터가 깔끔하게 표시되기를 원하기 때문에 테이블을 발명했습니다. . 그렇게 간단합니다. 그런데 테이블이 나중에 그렇게 많은 명성을 얻은 이유는 무엇입니까? Div 옹호자들은 Table이 다음과 같다고 비난합니다.
코드가 너무 커졌습니다. 실제 콘텐츠를 시작하기 전에 <table><tr><td> 태그를 세 개 이상 작성해야 합니다. 또한 Table의 다양한 태그에는 복잡한 속성 정의도 포함되어 있지만 Div에는 < div만 필요합니다. >라벨.
페이지 렌더링 성능 문제: 브라우저는 렌더링을 시작하기 전에 전체 테이블을 완전히 읽어야 합니다.
SEO에 좋지 않음: 검색 엔진은 콘텐츠와 분리되는 콘텐츠를 좋아합니다.
낮은 접근성: 화면 읽기 소프트웨어와 점자 브라우저는 표의 내용을 잘 이해할 수 없습니다.
의미론적이지 않음: 의미론적 웹이 필요합니다.
기사 1: 코드가 너무 커졌습니다.
우선 CSS로 정의할 수 없는 Table의 속성은 Cellspacing과 Cellpadding뿐입니다. 따라서 나머지 속성은 <table><tr>입니다. <td>와 <div>, 크기가 수십K에 달하는 웹페이지의 경우 수십 개의 테이블을 사용하더라도 추가 코드는 무시할 수 있다고 생각합니다. 테이블 코드가 너무 크다고 불평하는 사람들은 실제로 확인해야 합니다. 매우 비대한 테이블을 작성할 수 있는 사람은 Div를 작성하는 것만큼 간결하지 않을 수 있습니다.
기사 2: 페이지 렌더링 성능 문제
1.6G CPU 및 1G 메모리를 갖춘 2004 노트북을 사용합니다. 이 구성에서는 페이지 렌더링에서 테이블 레이아웃과 Div 레이아웃의 속도 차이를 실제로 볼 수 없습니다. 약간의 차이가 있으므로 네트워크 자체와 관련된 지연은 무시할 수 있습니다.
기사 3: 검색 엔진 최적화에 도움이 되지 않습니다.
앞서 언급한 것처럼 Table 속성 대신 CSS를 최대한 사용하면 생성된 코드와 Div의 차이가 그다지 크지 않을 것입니다. 태그? 나는 지금까지 이 진술의 근거를 찾지 못했습니다.
기사 4: 낮은 접근성
이는 Table의 본질적인 결함이지만 대부분의 Div + CSS 팬은 이러한 이유로 Table을 거부하지 않는 것 같습니다.
조항 5: 불충분한 의미 체계
Semantic Web의 의미는 훨씬 더 심오합니다. 이는 단지 Table과 Div에만 얽혀 있는 것이 아닙니다. W3C에서도 Table이 표 형식의 데이터를 표시하는 데만 사용될 수 있다고 규정하지 않습니다. Table.People의 실제 의미인 HTML 5를 기다리는 것이 좋습니다.
이 글의 목적은 여러분이 Div를 버리고 Table에 합류하도록 만드는 것이 아닙니다. 반대로 Div가 여러분의 디자인 요구 사항을 충족할 수 있다면 Div가 여전히 첫 번째 선택이지만, 그렇지 않으면 Table로 갈 것입니다. 다른 극단. Div를 사용하여 쉽게 얻을 수 없는 많은 디자인은 여전히 Table을 사용하여 얻을 수 있습니다. 물론 무엇을 사용하든 CSS를 사용하여 콘텐츠와 장식을 분리해야 합니다. Div + CSS 및 Table + CSS는 모두 합법적인 디자인이므로 더 간단한 것을 사용하세요. 내 경험에 따르면 콘텐츠 형식을 예측하고 추가하려는 콘텐츠의 표시 형식을 완전히 제어할 수 있는 경우 추가하려는 콘텐츠가 고정되지 않은 경우 Div + CSS를 사용해야 합니다. 예측할 수 없습니다. 형식의 경우 페이지가 접히는 것을 원하지 않으면 Table + CSS를 사용하는 것이 안전한 접근 방식입니다.
이 기사의 출처: COMSHARP CMS 작성자: 35km