Чому люди роблять столи з дівами?

У сучасній веб-розробці я все частіше зустрічаю цю закономірність. Це виглядає приблизно так:

<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 структуру для серйозних конструктивних змін. І таблиці не роблять завдання складнішим або легшим, ніж діви.

Насправді, єдиний спосіб, коли я бачу, що таблиці можуть ускладнити макет, це якщо ви ab їх використали і створили безбожний безлад. Ви можете зробити це і з дівами.

Отже ... у спробі змінити це з рентгена на цілісне запитання: чого я пропускаю? Які фактичні переваги від використання «штучної таблиці» над реальною?

Про повторюване посилання: це не пропозиція використовувати інший тег чи щось подібне. Це питання про використання <table>VS display:table.

Це загальна модель для складання чуйних таблиць. Табличні дані складно відображати на мобільних телефонах, оскільки сторінка буде збільшена для читання тексту, тобто таблиці відходять від сторони сторінки, і користувач повинен прокручувати назад і вперед, щоб прочитати таблицю, або сторінку буде зменшено , зазвичай означає, що таблиця занадто мала, щоб можна було читати.

Чуйні таблиці змінюють макет на менших екранах - іноді деякі стовпці приховані або стовпці об'єднані, наприклад, ім’я та адреса електронної пошти можуть бути окремими на великих екранах, але згортатися в одну клітинку на маленьких екранах, щоб інформація була читабельною, не потребуючи прокрутки.

<div>s використовуються для створення таблиць замість <table>тегів з кількох причин. Якщо <table>використовуються теги, перед тим, як додати власний код, потрібно змінити типи та макет браузера за замовчуванням, тому в цьому випадку <div>теги економлять на великій кількості CSS на платформі. Крім того, більш старі версії IE не дозволяють змінювати стилі таблиці за замовчуванням, тому використання <div>s також згладжує розробку крос-браузера.

Існує досить хороший огляд чуйних таблиць на CSS-трюках .

Редагувати: Я повинен зазначити, що я не виступаю за цю закономірність - вона потрапляє у пастку дивітів і не є семантичною - але саме тому ви знайдете таблиці, виготовлені з divs.

Питання полягає в тому, чи дані є семантично таблицею (тобто набором даних або одиницями інформації, логічно організованими в двох вимірах), або ви просто використовуєте сітку для візуального компонування, наприклад, тому що ви хочете розширити бічну панель чи щось подібне.

Якщо ваша інформація є семантично таблицею, ви використовуєте <table>-tag. Якщо ви просто хочете сітку для цілей компонування, використовуйте деякі інші відповідні елементи html та використовуйте display:tableв таблиці стилів.

Коли дані семантично є таблицею? Коли дані логічно організовані вздовж двох осей. Якщо це має сенс із заголовками рядків або стовпців, то у вас може бути семантична таблиця. Прикладом чогось, що не є семантично таблицею, є подання тексту стовпцями, як у газеті. Це не семантично таблиця, оскільки ви все одно читаєте її лінійно, і жодне значення не втрачається, якби презентація була видалена

Гаразд, чому б не використовувати <table>для всього, а не лише для чогось, що є семантично столом? Візуально це, очевидно, те саме (оскільки елемент таблиці просто є display:elementу таблиці стилів за замовчуванням).

Різниця полягає в тому, що семантична інформація може допомогти альтернативним агентам користувача. Наприклад, зчитувач екрана може дозволити вам орієнтуватися у двох вимірах у таблиці та читати заголовки комірки для обох осей, якщо ви забудете, де ви знаходитесь. Це було б просто заплутано, якби таблиця не була семантично таблицею, а просто використовувалася для візуального компонування.

<table>Проти display: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%;
  }
}

Чому діви, а не таблиці

Таблиця містить табличні дані - подання таблиці нерозривно пов'язане зі структурою таблиці. Табличні дані завжди повинні бути в табличній формі незалежно від того, де ви розміщуєте цей вміст або на якому екрані / пристрої ви хочете його відображати.

Галерея мініатюр (або багато інших речей, наприклад, форма реєстрації, меню тощо) не є табличними даними. Він може бути представлений як таблиця в деяких макетів дизайну, але в інших випадках, як вузькі екрани телефону, ви хочете, щоб він використовував більш традиційні компонування блоків. Або, можливо, ви хочете відображати ескізи на бічній панелі замість основної області вмісту.

Тепер ваш вибір полягає в виведенні різної розмітки для вмісту широкого екрана (таблиць) і бічної панелі або вмісту вузького екрана (діви) - це означає, що сценарії на стороні сервера повинні знати про те, куди йде контент, якщо ви будуєте програму - або у вас серверний скрипт виводить ту саму розмітку (тому що це не має значення, де ви це ставите) і використовуйте різні правила CSS для різних ситуацій.

Отже, тоді у вас є вибір завжди виводити таблиці, а потім переосмислювати правила відображення природних таблиць за допомогою блоку (який дійсно повинен перемелювати деякі передачі в голові будь-якого розробника), або виходити з чітко маркованими значками, які дозволяють більш гнучко підходити до стилізації.

І найкраща практика вже декілька років полягає у тому, щоб уникати таблиць, коли не потрібно подавати табличні дані.

За старих часів двигун подачі столу " з'являвся " повільніше, коли ви використовували відсотки для ширини стовпців. Двигун по суті повинен був завантажити весь набір даних, перш ніж він почав з'ясовувати, наскільки великим є все, щоб намалювати його на екрані.

Двигун DIV був іншим. Коли браузер зіткнувся з DIV, він піде вперед і розмістить його і почне наповнювати вміст в рядку. Звичайно, диви можуть стрибати, коли дані закінчуються. Тому я з'явився в цитатах вище. Часові рамки для завершення обох були однаковими, однак таблиці не були намальовані до кінця, що означало, що користувач не був впевнений, завантажується чи ні на секунду чи дві.

Це стало гірше, оскільки таблиці вклалися.

Тоді були (і досі існують) способи зробити візуалізацію таблиці FAR FAR швидше. В основному, даючи йому підказку, що розміри стовпців не змінюються, браузер негайно починає видавати табличні дані. Зрештою це означає, що таблиці насправді можуть відображатися у правильному положенні швидше, ніж діви, надаючи їм вигляд, що вони кращі.

Але це ще не вся історія. Все інше полягає в тому, що більшість дияволів просто не намагаються вивчити своє ремесло досить добре, щоб знати це. Натомість вони стрибають на різних трамвайних вагонах та йдуть із будь-яким кодом, з якого можна скопіювати / вставити. Навіть сьогодні я вважаю, що дуже мало веб-розробників знають різницю від одного вчення до іншого - і це причина номер один, чому різні сайти мають всілякі обхідні шляхи для покриття різних браузерів.

Отже, поставимо +1 вам за запитання.

Якщо я можу отримати тут трохи "мета", це приносить мені дві проблеми:

Перше: хтось пропонує правило з якоїсь вагомої причини, і люди повністю пропускають суть, дотримуючись технічної літери правила, ігноруючи дух. Вони знаходять певний спосіб здійснити всі погані речі, які правило намагалося запобігти, а технічно дотримуючись правила як викладене.

Друге: Хтось бачить проблему і пропонує правило, щоб її запобігти. Інші бачать цінність цього правила. Потім вони наполягають на сліпій відданості цьому правилу, не зважаючи на первісну проблему, яку він повинен був вирішити та / або незалежно від того, які інші проблеми він створює. У мене було багато розмов, де хтось каже: "Ти повинен зробити X, тому що це правило", а потім я запитую: "Але навіщо нам робити X?", І вони дивляться на мене здивовано і роздратовано і кажуть: "Але Я щойно сказав вам! Тому що це правило! " Я відповідаю: "Але це, здається, спричиняє більше проблем, ніж це вирішує. Я думаю, що нам краще зробити Y." І тоді людина каже: "Ні, дивіться, я вам покажу. Бачте, саме тут, у цій книзі. X - це правило".

У цьому випадку у нас є проблема: Тег таблиці виконує дві речі: Один, він керує компонуванням документа. По-друге, вона передає ідею, що вкладені дані складаються з рядків і стовпців чисел або інших даних.

Тому багато людей запропонували рішення: Не використовуйте теги таблиць для управління компонуванням речей, які логічно не є "таблицями". Використовуйте CSS.

Але є проблема з цим рішенням. Тег таблиці та його підтеги виконують багато дуже корисних функцій компонування, яких нелегко досягти за допомогою CSS, і коли їх можна досягти, код, необхідний для цього, часто громіздкий - важко читати і важко підтримувати. Чому ми повинні робити речі незграбними, складними способами, коли існує чистий, простий спосіб?

Особисто я думаю, що нам було б краще просто заявити: "Те, що щось знаходиться всередині тегу таблиці, не обов'язково означає, що воно являє собою рядки та стовпці чисел". Це не було б кричущим вимовою. Я ніколи не чув, щоб хтось сказав, що тег "p" можна використовувати лише для речей, які є справді абзацами граматично правильних, логічно побудованих англійських речень. Я ніколи не чув, щоб хтось сказав, що неправильно використовувати тег "ul" для списку, який насправді йде в логічному порядку, просто тому, що ви хотіли, щоб кулі, а не порядкові номери. І т.д.

Є вже тонни великих відповідей тут. Але я хотів додати, що tableелементи мають обмеження щодо візуалізації, які не існують для divелементів. Спробуйте скласти таблицю з віртуальною прокруткою (наприклад: SlickGrid , DataTables тощо), і ви будете сильно розчаровані. Це просто не працює. Більшість (All?) Сучасних сіток Javascript використовують divs, оскільки css дозволяє значно гнучкіше відображати.

Є й інші обмеження. Моє загальне правило: якщо я збираюсь бачити всю таблицю на одному екрані, і я не хочу будь-якого / багато спеціального візуалізації для цього, я використовую tableелемент, інакше я переходжу до дівів, тому що я можу значно контролювати результати , набагато легше.

HTML і CSS розвинули певну міру гнучкості, що означає, що навіть концептуально "блокувати" елементи на зразок <div>(найдавніша і найзагальніша форма вмісту блоку) не потрібно відображати як блоки:

div { display: inline; }

Як зазначаєте, <div>можна переробити для наслідування <table>і своїх попутників. Насправді, більшість тегів може. З урахуванням їх особливої ролі, я сумніваюся , що ви могли б з користю перепризначити теги макросів , як <html>, <head>, <body>і <script>, а «загальні» теги , як <div>, <p>, <b>, <em>, <span>, і <pre>? На захоплення. Зробіть блоки вбудованих тегів, блоки вбудовані, попередньо відформатовані теги потоку, нерухомі плавають. Сходи з розуму, якщо тобі подобається!

Це можливо . Ви можете закрутити пряжу про те, як ми всі повинні використовувати "семантичну розмітку" бла-бла- бла , або вірити з піфоністами, що "повинен бути один - і бажано лише один - очевидний спосіб зробити це". І все ж Тім Тоді - розумний і цікавий хлопець. Давши вільну руку, він вивчить їх усіх. Це включає використання наявної гнучкості для заміни. Деякі мудрі, деякі будуть доведені інакше. Але проби, помилки та досвід - це єдиний спосіб дізнатися це. Тож існують достатні умови для заміни.

Я не думаю, що занадто швидко говорити, що заміна також необхідна. Як мінімум, це надзвичайно зручно . В протягом довгого часу, HTML не було <menu>, <section>або <aside>елементи. Однак веб-сторінки та додатки скрізь мають меню, розділи та бічні панелі. Як? Оскільки елементи списку HTML ( <ul>, <ol>і <li>) були легко перероблені, а деякі звички перекваліфіковані як контейнери та частини меню. <div>може стояти на <article>, <section>, <aside>, <figure>, і <summary>. HTML5 наздогнав і додав замовлені елементи для деяких раніше неадресованих випадків використання. Це відмінне оновлення та виправлення, що забезпечує загальне використання в реальному світі.

Незважаючи на це, залишається багато загальних ідіом, які не мають відповідні теги чи семантичні моделі . Такі речі, як сторінки, виноски, котирування, коментарі, пов’язані аватари, «лайки», підзаголовки та субтитри, якими я та багато інших користуюся щодня. Що нам робити? Що ми можемо. Повторно призначте «близькі, але неточні» елементи з класами та ідентифікаторами, щоб стояти та підтримувати нашу роботу протягом наступних п’яти чи десяти чи стільки років, поки HTML6 чи HTML7 наздоганяють. HTML / CSS "так, це теорія X, але теоретично ми збираємось позначити її та працювати з нею як Y", це неймовірно зручно. Незамінний, справді. Це робить веб-вміст гнучким і не є крихким.

Пройшовши ще далі, "семантична розмітка" має невідмінними обмеженнями . Це стосується будь-якої жорсткої структури, яку ви можете уявити для змісту.

Стандартні формати не можуть охопити все багатство людської потреби, бажання та різноманітності. Вони завжди будуть «за кривою» того , що люди роблять в даний час . Як вони інновації. Heck, HTML5 все ще знаходиться за кривою на виносках, підрубриках та інших нововведеннях друку XVII століття. У ньому відсутні функції, важливі для багатьох інформаційних працівників та творців контенту. Тож ми імпровізуємо.

Ще більш незмінним є те, що інформація не дотримується одного набору правил. Звичайно, це починається як стіл. Але, можливо, ви просто хочете резюме - вимовляйте заголовок кожного ряду, як список. Можливо, це займає занадто багато місця, і ви хочете це як вбудований список, що економить місце. Можливо, у вас є записи, на які ви просто хочете назву, тоді, якщо натискаєте, ви бачите основні деталі. Або ви хочете, щоб елементи зі складного списку або таблиці були згруповані та класифіковані. О, тепер ви хочете, щоб це було перекладено та класифіковано по-іншому. Або значення, нанесені у вигляді гістограми. Це щодня, що робиться в додатках, електронних таблицях та візуалізації даних. Вони є невід'ємною частиною нашого інформаційного ландшафту, а також того, що ми хочемо і потрібно робити в Інтернеті. Люди постійно реорганізують форму та представлення наших даних. Це не одне, або один формат / макет, або одна концепція. Це можливо, з семантикою залежно від обставин та варіантів, які користувачі роблять інтерактивно. Так, позначте текст як "наголошений" (<em>), але це лише умовність. Я працював над документами щонайменше з півтисячі різних видів "наголосів". Нам потрібно вміти налаштовувати та переробляти їх для різних цілей, різних інтерпретацій. Один з типів наголосів на HTML? Вибачливо редукціоністський. Обмежуючий. Крихка. Те ж саме відноситься і до <table>, <p>і т.д.

Чудово мати теги / елементи, які допомагають організувати роздуми всієї громади про те, "куди йде". Це допомагає встановлювати умовності та ідіоми та робить нас колективнішими ефективнішими. Але можливість переробити речі, переробити і змінити ці структури? Це невід'ємна частина всеосяжної мережі та її успіху.

Використання справ має значення. Існує велика різниця між макетом / презентацією на змістовій сторінці та в додатку. За змістом семантика має велике значення для SEO-обізнаності та зручності використання. У цих випадках використання таблиць для представлення табличних даних взагалі є правильним. Як зазначали інші, пошукові системи будуть штрафувати вас, і ви навіть можете порушити закони про користування, якщо законодавство вимагатиме, щоб вони відповідали правилам щодо користування державою.

У веб-додатку розробники можуть вирішити створити абсолютно окремі представлення для цілей SEO та зручності використання. Чуйний дизайн спонукав людей створювати представлення даних, які можуть працювати з макетами на робочому столі та мобільних пристроях, а діви краще, ніж таблиці в тих випадках використання.

Візьмемо, наприклад, сайти електронної комерції. Перегляд списку продуктів у перегляді чи результатах пошуку показує, як правило, список продуктів у табличному форматі, але ці представлення цілком можуть бути створені за допомогою divs (які надають більш загальні та гнучкі параметри компонування та стилізації), а не таблиці. Amazon та eBay - хороші приклади такого підходу. Перегляньте результат пошуку на будь-якому сайті, і ви побачите глибоко вкладений набір дівок.