사람들이 div로 테이블을 만드는 이유는 무엇입니까?

현대 웹 개발에서 나는이 패턴을 훨씬 더 자주 접하게됩니다. 다음과 같이 보입니다 :

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

그리고 CSS에는 다음과 같은 것이 있습니다 :

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

^{* (클래스 이름은 단지 예시 일 뿐이며 실생활에서는 요소의 내용을 반영하는 일반 클래스 이름입니다)}

나는 최근에 스스로 이것을 시도했습니다. 왜냐하면 ... 모두들 알고 있습니다.

그러나 나는 여전히 그것을 얻지 못한다. 왜 이러는거야? 테이블이 필요하면 날려 버려서 <table>끝내십시오. 예, 레이아웃 용이라도 마찬가지입니다. 그것이 테이블을위한 것입니다-테이블 형식으로 물건을 배치하십시오.

내가 가진 가장 좋은 설명은 이제 모든 사람들이 "레이아웃을 위해 테이블을 사용하지 마십시오"라는 진언을 들었으므로 맹목적으로 따릅니다. 그러나 그들은 여전히 필요 (아무 것도 테이블의 확장 기능이 없기 때문에) 레이아웃을 위해 테이블을, 그래서 그들은을 <div>(그것 때문에 하지 테이블!) 다음 테이블 어쨌든 그것을 만드는 CSS를 추가합니다.

전 세계에 걸쳐 이것은 당신에게 방해가되는 임의의 불필요한 장애물을 놓은 다음 장애물을 피하기 위해 추가 작업을하는 것처럼 보입니다.

레이아웃을 위해 테이블에서 벗어나는 원래의 주장은 나중에 테이블 형식 레이아웃을 수정하기 어렵다는 것입니다. 그러나 "가짜 테이블"레이아웃을 수정하는 것도 마찬가지로 어렵습니다. 실제로 레이아웃을 수정하는 것은 항상 어려운 일이며, 약간의 조정보다 더 심각한 것을 원한다면 CSS를 변경하는 것만으로는 충분하지 않습니다. 당신은 것입니다 이해하고 심각한 설계 변경에 대한 HTML 구조를 변경해야합니다. 그리고 테이블은 작업을 div보다 어렵거나 어렵게 만들지 않습니다.

사실, 나는 테이블, 수정 레이아웃 어렵게 만들 수 있다는 것을 볼 수있는 유일한 방법은 경우입니다 시종 을 사용하고 경건 치 못한 혼란을 만들었습니다. div로도 그렇게 할 수 있습니다.

그래서 ... 이것을 rant에서 끊임없는 질문으로 바꾸려는 시도에서 : 내가 무엇을 놓치고 있습니까? 실제 테이블보다 "가짜 테이블"을 사용 하면 실제로 어떤 이점이 있습니까?

중복 링크 정보 : 다른 태그 나 다른 것을 사용하는 것은 아닙니다. 이것은 <table>vs 사용에 대한 질문 display:table입니다.

반응 형 테이블을 만들기위한 일반적인 패턴입니다. 페이지가 텍스트를 읽기 위해 확대되고, 즉 테이블이 페이지의 측면에서 벗어나고 사용자가 테이블을 읽기 위해 앞뒤로 스크롤해야하거나, 페이지가 축소되기 때문에 표 형식의 데이터는 모바일에 표시하기 까다 롭습니다. 일반적으로 테이블이 너무 작아 읽을 수 없습니다.

반응 형 테이블은 작은 화면에서 레이아웃을 변경합니다. 때로는 일부 열이 숨겨 지거나 열이 병합됩니다. 예를 들어 이름과 전자 메일 주소가 큰 화면에서는 분리 될 수 있지만 작은 화면에서는 하나의 셀로 축소되어 스크롤 할 필요없이 정보를 읽을 수 있습니다.

<div><table>몇 가지 이유로 태그 대신 테이블을 작성하는 데 사용됩니다 . <table>태그를 사용하는 경우 고유 코드를 추가하기 전에 브라우저 기본 스타일 및 레이아웃을 재정의해야 <div>하므로이 경우 태그는 많은 상용구 CSS에 저장됩니다. 또한 이전 버전의 IE에서는 기본 테이블 스타일을 재정의 할 수 없으므로 <div>s를 사용하면 브라우저 간 개발이 원활 해집니다.

CSS-Tricks에는 반응 형 테이블에 대한 훌륭한 개요가 있습니다 .

편집 : 나는이 패턴을 옹호하지 않는다는 것을 지적해야합니다.이 패턴은 divitis trap에 빠지고 의미가 없습니다. 그러나 이것이 divs 로 만든 테이블을 찾는 이유 입니다.

문제는 데이터가 의미 적으로 테이블 (즉, 논리적으로 2 차원으로 구성된 일련의 데이터 또는 정보 단위)인지 또는 시각적 레이아웃을 위해 그리드를 사용하는지 여부입니다. 예를 들어 사이드 바를 확장하거나 이와 유사한 것을 원하기 때문입니다.

정보가 의미 상 테이블 인 경우 <table>-tag 를 사용합니다 . 레이아웃 목적으로 그리드를 원한다면 다른 적절한 html 요소를 사용 display:table하고 스타일 시트에서 사용 하십시오.

때 데이터는 테이블 의미입니까? 데이터가 두 축을 따라 논리적으로 구성되는 경우 행이나 열의 머리글에 의미가있는 경우 의미 테이블이있을 수 있습니다. 의미 상 테이블이 아닌 것의 예는 신문에서와 같이 열로 텍스트를 제시합니다. 이것은 의미 적으로 테이블이 아닙니다. 왜냐하면 당신은 여전히 ​​선형으로 읽을 것이기 때문에 프레젠테이션이 제거되면 아무런 의미도 잃지 않습니다.

OK, 왜 사용하지 <table>모든 것을보다는만을 의미 테이블 뭔가를? 테이블 요소 display:element는 기본 스타일 시트에 있기 때문에 시각적으로 동일 합니다.

차이점은 시맨틱 정보가 대체 사용자 에이전트를 도울 수 있다는 것입니다. 예를 들어 스크린 리더를 사용하면 표에서 2 차원으로 탐색하고 위치를 잊어 버린 경우 두 축의 셀 머리글을 읽을 수 있습니다. 테이블이 의미 적으로 테이블이 아니고 시각적 레이아웃에 사용 된 경우 혼동 될 수 있습니다.

<table>대 display:table토론은 의미 론적 마크 업을 사용하는 일반적인 원칙을 단지 경우입니다. 예를 들어 : 왜 적절하고 의미 적으로 마크 업을 방해합니까? 또는 왜 의미 론적 마크 업이 검색 엔진에 더 많은 가중치를 부여합니까?

일부 지역에서는 실제로 접근성 이유로 시맨틱 마크 업을 사용해야하는 법적 법적 요구가있을 수 있으며, 어떤 경우에도 의도적으로 페이지의 접근성을 떨어 뜨릴 이유가 없습니다.

장애가있는 사용자를 신경 쓰지 않더라도 컨텐츠와 다른 프리젠 테이션을 사용하면 이점이 있습니다. 예를 들어 대체 스타일 시트를 사용하여 3 개의 열 레이아웃을 모바일에서 단일 열로 표시 할 수 있습니다.

실제로, 예제에서 "table"과 같은 클래스 이름을 사용하면 시맨틱 마크 업을 시도 할 때 사람들이 실제로 무엇을 이해하지 못하는지 알 수 있습니다. 그들은 내용이 표 형식의 데이터가 아니라는 것을 보여 주려고 했지만 점수가 잘못 되었다는 표시를 얻습니다 .

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

이 개발자가 한 것은 <table>CSS 클래스 이름으로 원래 마크 업을 복제하는 것입니다 . 이것은이 레이아웃이 테이블이 아닌 즉시 클래스 이름이 홀수임을 의미합니다.

이 개발자가해야 할 일은 표에있는 정보를 고려하는 것입니다. 썸네일 갤러리입니까? 그럼 :

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

이제 적응 형 CSS를 만들 수 있습니다.

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

왜 div가 아닌 테이블

테이블에는 테이블 형식의 데이터가 포함되어 있습니다. 테이블 표시는 테이블 구조와 불가분의 관계로 연결됩니다. 표 형식의 데이터는 내용을 어디에 두거나 표시하려는 화면 / 장치에 관계없이 항상 표 형식이어야합니다.

썸네일 갤러리 (또는 등록 양식, 메뉴 등과 같은 다른 많은 것)는 테이블 형식의 데이터가 아닙니다. 일부 디자인 레이아웃에서는 표처럼 표시 될 수 있지만 좁은 경우에는 좁은 전화 화면과 같이보다 전통적인 블록 레이아웃을 사용해야합니다. 또는 주 컨텐츠 영역 대신 사이드 바에 축소판을 표시하려고 할 수 있습니다.

와이드 스크린 컨텐츠 (테이블)와 사이드 바 또는 좁은 스크린 컨텐츠 (div)에 대해 서로 다른 마크 업을 출력하도록 선택합니다. 즉, 프로그래밍 방식으로이를 구축 할 경우 서버 측 스크립트가 컨텐츠의 진행 방향을 알아야합니다. -또는 서버 측 스크립트가 동일한 마크 업을 출력하도록하고 (이 위치를 신경 쓰지 않기 때문에) 상황에 따라 다른 CSS 규칙을 사용합니다.

따라서 항상 테이블을 출력 한 다음 블록으로 자연 테이블 표시 규칙을 재정의하거나 (모든 개발자 헤드에서 실제로 일부 기어를 연마해야 함) 스타일링에보다 유연한 접근 방식을 허용하는 레이블이있는 div를 선택할 수 있습니다.

그리고 몇 년 동안 모범 사례는 이제 테이블 형식의 데이터를 표시 할 필요가 없을 때 테이블을 피하는 것이 었습니다.

예전에는 열 너비에 백분율을 사용할 때 테이블 렌더링 엔진이 "느리게 나타 납니다. 엔진은 본질적으로 전체 데이터 세트를 다운로드해야 화면에 모든 것이 얼마나 큰지 파악하기 시작했습니다.

DIV 엔진은 달랐습니다. 브라우저에 DIV가 발생하면 계속해서 배치하고 컨텐츠를 인라인으로 채우십시오. 물론 데이터로드가 완료되면 div가 이동할 수 있습니다. 따라서 위의 인용문으로 표시된 이유는 무엇입니까? 둘 다 완료하는 시간 프레임은 같았지만 끝날 때까지 테이블이 그려지지 않았으므로 사용자는로드가 1-2 초인지 여부를 확신 할 수 없었습니다.

테이블이 중첩되면 상황이 악화되었습니다.

테이블 렌더링 FAR FAR을 더 빠르게 만드는 방법이있었습니다. 기본적으로 열 크기가 변경되지 않는다는 힌트를 주면 브라우저가 즉시 테이블 형식의 데이터를 렌더링하기 시작합니다. 궁극적으로 이것은 테이블이 실제로 div보다 정확한 위치에 더 빨리 표시되어 더 나은 모양을 제공 할 수 있음을 의미합니다 .

그러나 그것은 전체 이야기가 아닙니다. 나머지 대부분은 대부분의 개발자가 단순히 이것을 알기에 충분히 기술을 배우는 것을 귀찮게하지 않습니다. 대신 그들은 다양한 악 대차를 타고 복사 / 붙여 넣을 수있는 코드를 사용합니다. 오늘날에도 필자는 한 문서 유형과 다음 문서 유형의 차이점을 아는 웹 개발자가 거의 없다는 것을 알았습니다. 이것이 다양한 사이트가 다양한 브라우저를 다루는 모든 종류의 해결 방법을 가지고있는 가장 큰 이유입니다.

질문을해서 +1합니다.

여기서 약간의 "메타"를 얻을 수 있다면 두 가지 문제가 있습니다.

하나 : 누군가가 어떤 이유로 정당한 규칙을 제안하고, 사람들은 정신을 무시하면서 규칙의 기술 서한을 따라 요점을 완전히 놓칩니다. 그들은 기술적으로 말 그대로 규칙을 따르면서 규칙이 예방하려고했던 모든 나쁜 일을 성취 할 수있는 방법을 찾습니다.

2 : 누군가 문제를보고이를 방지하기위한 규칙을 제안합니다. 다른 사람들은이 규칙의 가치를 봅니다. 그런 다음 그들은 원래의 문제와는 상관없이이 규칙에 대한 맹목적인 헌신을 주장하며 다른 문제가 무엇이든 관계없이 주장합니다. 나는 누군가가 "그것이 규칙이기 때문에 X를해야한다"고 말한 다음 많은 대화를했습니다. 그리고 "하지만 왜 우리는 X를해야합니까?"라고 물었습니다. 방금 말씀 드렸습니다. 규칙 이니까요! " "하지만 그것이 해결하는 것보다 더 많은 문제를 일으키는 것 같습니다. Y를하는 것이 더 나을 것 같습니다." 그리고 그 사람은 "아니요, 보여 드리겠습니다.이 책의 바로 여기에 있습니다. X는 규칙입니다."라고 말합니다.

이 경우에 문제가 있습니다. 테이블 태그는 두 가지 작업을 수행합니다. 하나는 문서의 레이아웃을 제어합니다. 둘째, 동봉 된 데이터는 숫자 또는 다른 데이터의 행과 열로 구성되어 있다는 아이디어를 전달합니다.

많은 사람들이 해결책을 제안했습니다. 테이블 태그를 사용하여 논리적으로 "테이블"이 아닌 것들의 레이아웃을 제어하지 마십시오. CSS를 사용하십시오.

그러나이 솔루션에는 문제가 있습니다. 테이블 태그와 그 하위 태그는 CSS를 사용하여 달성하기 쉽지 않은 매우 유용한 레이아웃 기능을 많이 수행하며,이를 달성 할 수있을 때이를 수행하는 데 필요한 코드는 번거롭고 읽기 어렵고 유지하기가 어렵습니다. 깨끗하고 쉬운 방법이있을 때 왜 어색하고 어려운 방법으로해야합니까?

개인적으로, "테이블 태그 안에 무언가가 있다는 것이 반드시 그것이 행과 숫자의 열을 나타내는 것을 의미하지는 않습니다"라고 선언하는 것이 더 나을 것이라고 생각합니다. 이것은 터무니없는 선언이 아니었을 것입니다. "p"태그는 문법적으로 정확하고 논리적으로 구성된 영어 문장의 단락에만 사용될 수 있다고 말하는 사람은 없습니다. 나는 누군가가 순서 번호가 아닌 글 머리 기호를 원했기 때문에 논리적 순서로 나오는 목록에 "ul"태그를 사용하는 것이 잘못되었다고 말하는 것을 들어 본 적이 없습니다. 기타.

이미있다 톤 여기에 큰 응답의는. 그러나 table요소에는 존재하지 않는 렌더링 제한이 있음 을 추가하고 싶었습니다 div. 가상 스크롤링 (예 : SlickGrid , DataTables 및 기타) 을 수행하는 테이블을 만들어보고 실망 할 것입니다. 작동하지 않습니다. divCSS는 훨씬 더 유연한 렌더링을 허용하므로 대부분의 (모두?) 최신 Javascript 그리드는 s를 사용 합니다.

다른 제한 사항도 있습니다. 내 일반적인 규칙은 전체 화면을 단일 화면에서 보려고 할 때 table요소를 사용하거나 많은 사용자 정의 렌더링을 원하지 않으면 결과를 많이 제어 할 수 있기 때문에 div를 사용한다는 것입니다 훨씬 더 쉽게.

HTML과 CSS는 어느 정도의 유연성을 발전 시켰습니다. 즉 <div>, HTML의 가장 오래되고 가장 일반적인 형태의 블록 콘텐츠와 같은 개념적으로 "차단"요소 도 블록으로 표시 할 필요가 없습니다.

div { display: inline; }

아시다시피, 동료 여행자 <div>를 모방하기 위해 용도를 변경할 수 있습니다 <table>. 실제로 대부분의 태그가 가능합니다. 그들의 특별한 역할을 감안할 때, 나는 당신이 유용하게 같은 매크로 태그를 매핑 할 수 의심 <html>, <head>, <body>,와 <script>같은, 그러나 "일반적인"태그 <div>, <p>, <b>, <em>, <span>,와 <pre>? 잡아라. 인라인 태그 블록, 인라인 블록, 미리 형식이 지정된 태그가 흐르고 고정 태그가 플로팅되도록합니다. 원한다면 미쳐 라!

그건 가능합니다 . "시맨틱 마크 업"blah blah blah 를 어떻게 사용해야하는지 , 또는 Pythonistas와 "어떻게해야합니까? 그러나 팀 토디 는 영리하고 호기심 많은 사람입니다. 자유로운 손이 주어지면 그는 모두를 탐구 할 것입니다. 여기에는 대체 할 수있는 유연성 사용이 포함됩니다. 일부는 현명하고 일부는 그렇지 않으면 입증 될 것입니다. 그러나 시행 착오와 경험이 그것을 알아내는 유일한 방법입니다. 따라서 충분한 치환 조건이 존재합니다.

나는 대체가 필요하다고 말하는 것이 과도하다고 생각하지 않습니다. 최소한 매우 편리합니다 . 오랜 시간 동안, HTML은하지 않았다 <menu>, <section>또는 <aside>요소. 그러나 모든 웹 페이지와 앱에는 메뉴, 섹션 및 사이드 바가 있습니다. 어떻게? HTML 목록 요소 ( <ul>,, <ol>및 <li>)는 쉽게 용도를 변경하고 일부 사용은 메뉴 컨테이너 및 부품으로 다시 분류 되었기 때문입니다. <div>위해에 서 수 <article>, <section>, <aside>, <figure>,와 <summary>. HTML5는 이전에 다루지 않은 일부 사용 사례를 따라 잡아 맞춤 요소를 추가했습니다. 일반적인 실제 사용을 수용하기위한 훌륭한 업데이트 및 수정입니다.

그럼에도 불구하고, 맞춤형 태그 나 시맨틱 모델이없는 일반적인 관용구가 많이 남아 있습니다 . 나와 다른 사람들이 매일 사용하는 페이지, 각주, 풀 따옴표, 댓글 스트림, 관련 아바타, "좋아요", 자막 및 자막과 같은 것들. 우리는 무엇을해야합니까? 우리가 할 수있는 것. HTML6 또는 HTML7이 따라 올 때까지 앞으로 5 년 또는 10 년 또는 수년 동안 우리의 작업을 지원하고 지원하기 위해 클래스 및 ID와 함께 "밀폐하지만 부정확 한"요소를 재사용하십시오. HTML / CSS의 "그렇습니다. 이론 상으로는 X입니다. 그러나 우리는 그것을 태그하고 Y로 작업 할 것"능력은 매우 편리합니다. 정말 없어요. 웹 컨텐츠를 유연하게 만들며 취하지 않습니다.

더 나아가서, "의미 론적 마크 업"은 돌이킬 수없는 한계가 있습니다. 콘텐츠에 대해 상상할 수있는 모든 종류의 엄격한 구조에 해당됩니다.

표준 형식은 모든 인간의 필요, 욕구 및 다양성을 포괄 할 수 없습니다. 그들은 항상 사람들이 지금 하고있는 일의 "곡선 뒤에"있을 것 입니다. 그들이 어떻게 혁신하고 있는지. HTML5는 여전히 17 세기의 각주, 부제목 및 기타 인쇄 혁신에서 여전히 뒤쳐져 있습니다. 많은 정보 근로자와 컨텐츠 제작자에게 필수적인 기능이 부족합니다. 그래서 우리는 즉흥적입니다.

더 큰 변화는 정보가 하나의 규칙 집합을 따르지 않는다는 것입니다. 물론, 그것은 테이블로 시작합니다. 그러나 요약을 원할 수도 있습니다. 예를 들어 각 행의 제목을 목록으로 사용하십시오. 공간을 너무 많이 차지하고 공간 절약 인라인 목록으로 사용하고 싶을 수도 있습니다. 제목 만 원하는 레코드가있을 수 있습니다. 클릭하면 기본 세부 정보가 표시됩니다. 또는 복잡한 목록 또는 테이블의 항목을 그룹화하고 분류하려고합니다. 오, 이제는 다른 방식으로 바꾸고 분류하기를 원합니다. 또는 값을 막대 차트로 표시했습니다. 앱, 스프레드 시트 및 데이터 시각화에서 매일 수행되는 작업입니다. 그것들은 우리의 정보 환경의 일부이며, 웹에서 우리가 원하는 것과해야 할 일입니다. 인간은 데이터의 형식과 표현을 지속적으로 재구성합니다. 한 가지 또는 형식 / 레이아웃이 아닙니다. 또는 하나의 개념. 상황과 사용자가 대화 형으로 선택한 선택 사항에 따라 의미가있는 재미있는 기능입니다. 예, 텍스트를 "강조 표시됨"(<em>)이지만 이는 단지 컨벤션입니다. 저는 적어도 6 가지 종류의 "강조"가있는 문서를 작업했습니다. 우리는 필요한 사용자 정의하고 다른 용도, 다른 해석을 위해 그 매핑 할 수 있도록. HTML 강조의 한 종류? 엄청나게 감소. 제한. 다루기 힘든. 동일은 마찬가지입니다 <table>, <p>등

"어디로 가는지"에 대한 전체 커뮤니티의 생각을 정리하는 데 도움이되는 태그 / 요소가있는 것이 좋습니다. 그것은 관습과 관용구를 확립하는 데 도움이되고 우리를 총체적으로 더 효율적으로 만듭니다. 그러나 사물을 다시 매핑하고 해당 구조를 재지 정하고 용도를 ​​변경하는 기능은 무엇입니까? 그것은 웹의 포괄 성과 성공의 일부이며 소포입니다.

유스 케이스가 중요합니다. 콘텐츠 페이지와 응용 프로그램의 레이아웃 / 프레젠테이션에는 큰 차이가 있습니다. 내용에서 의미론은 SEO 인식 및 유용성에 큰 영향을 미칩니다. 이 경우 테이블을 사용하여 테이블 형식의 데이터를 표시하는 것이 일반적으로 올바른 일입니다. 다른 사람들이 지적했듯이 검색 엔진은 처벌을받으며 법령에 따라 정부 유용성 지침을 준수 해야하는 경우 유용성 법률을 위반 할 수도 있습니다.

웹 애플리케이션에서 개발자는 SEO 및 사용 편의성을 위해 완전히 별도의보기를 작성하도록 선택할 수 있습니다. 반응 형 디자인을 통해 사람들은 데스크톱 및 모바일 레이아웃을 처리 할 수있는 뷰를 만들었으며, div는 해당 사용 사례의 테이블보다 낫습니다.

전자 상거래 사이트를 예로 들어 보겠습니다. 찾아보기 또는 검색 결과에서 제품 목록을 보는 경우 일반적으로 테이블 형식의 제품 목록이 표시되지만 이러한보기는 테이블 대신 div (보다 일반적이고 유연한 레이아웃 및 스타일링 옵션을 제공함)를 사용하여 생성 될 수 있습니다. Amazon과 eBay가이 접근법의 좋은 예입니다. 두 사이트 중 하나에서 검색 결과를 검사하면 깊게 중첩 된 div 세트가 나타납니다.