Чому б не використовувати таблиці для компонування в HTML? [зачинено]

Здається, що загальна думка, що таблиці не повинні використовуватися для компонування в HTML.

Чому?

Я ніколи (або рідко кажучи чесно) не бачив для цього гарних аргументів. Звичайні відповіді:

• Добре відокремлювати вміст від верстки,
  але це помилковий аргумент; Кліше мислення . Я думаю, що це правда, що використання елемента таблиці для компонування має мало спільного з табличними даними. І що? Чи хвилює мій начальник? Чи хвилюються мої користувачі?
  
  Можливо, я або мої колеги-розробники, яким доводиться підтримувати догляд за веб-сторінками ... Чи таблиця менш рентабельна? Я думаю, що використовувати таблицю простіше, ніж використовувати divs та CSS.
  
  До речі ... чому використання div або span добре відокремлює вміст від верстки та таблиці не? Щоб отримати гарний макет лише з дивами, часто потрібно багато вкладених дівок.

• Читання коду
  Я думаю, що це навпаки. Більшість людей розуміє HTML, мало хто розуміє CSS.

• SEO краще не використовувати таблиці
  Чому? Чи може хтось показати якісь докази того, що це? Або заява від Google про те, що таблиці не відволікаються від перспективи SEO?

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

• Капітальний ремонт макета простіший без таблиць, див. Css Zen Garden .
  Більшість веб-сайтів, які потребують оновлення, також потребують нового вмісту (HTML). Сценарії, коли для нової версії веб-сайту потрібен лише новий CSS-файл, не дуже ймовірні. Дзен Сад - приємний веб-сайт, але трохи теоретичний. Не кажучи вже про його неправильне використання CSS.

Мені дуже цікаві гарні аргументи використовувати divs + CSS замість таблиць.

Я збираюся переглядати ваші аргументи одна за одною і намагатись показати в них помилки.

Добре відокремлювати вміст від верстки, але це помилковий аргумент; Кліше мислення.

Це зовсім не помилково, оскільки HTML був розроблений навмисно. Зловживання елементом може не викликати сумнівів (зрештою, нові ідіоми склалися і в інших мовах), але можливі негативні наслідки повинні бути врівноважені. Крім того, навіть якщо б не було аргументів проти неправомірного використання <table>елемента сьогодні, це може бути завтра через те, як постачальники браузерів застосовують спеціальний режим до елемента. Зрештою, вони знають, що " <table>елементи призначені лише для табличних даних" і можуть використовувати цей факт для вдосконалення механізму візуалізації, в процесі тонко змінюючи <table>поведінку, і, таким чином, порушуючи випадки, коли раніше їх неправомірно використовували.

І що? Чи хвилює мій начальник? Чи хвилюються мої користувачі?

Залежить. Ваш начальник гострий? Тоді йому може бути все одно. Якщо вона грамотна, то вона піклується, тому що користувачі будуть .

Можливо, я або мої колеги-розробники, яким доводиться підтримувати догляд за веб-сторінками ... Чи таблиця менш рентабельна? Я думаю, що використовувати таблицю простіше, ніж використовувати divs та css.

Більшість професійних веб-розробників, схоже, проти вас^{[ цитування потрібне ]} . Це столи є насправді менш ремонтопрігодни має бути очевидно. Використання таблиць для компонування означає, що зміна корпоративного макета насправді означатиме зміну кожної окремої сторінки. Це може бути дуже дорого. З іншого боку, розумне використання семантично значущого HTML у поєднанні з CSS може обмежувати такі зміни у CSS та використаних зображеннях.

До речі ... чому використання div або span добре відокремлює вміст від верстки та таблиці не? Щоб отримати гарний макет лише з дивами, часто потрібно багато вкладених дівок.

Глибоко вкладені <div>s - це антидіапазон так само, як макети таблиць. Хороші веб-дизайнери не потребують багатьох з них. З іншого боку, навіть такі глибоко вкладені диви не мають багатьох проблем у макеті таблиць. Насправді вони навіть можуть сприяти смисловій структурі, логічно розділяючи вміст на частини.

Читання коду Я думаю, що це навпаки. Більшість людей розуміє html, мало розуміє css. Це простіше.

"Більшість людей" не має значення. Професіонали мають значення. Для професіоналів макети таблиць створюють набагато більше проблем, ніж HTML + CSS. Це як би сказати, що я не повинен використовувати GVim або Emacs, оскільки Блокнот для більшості людей простіший. Або що я не повинен використовувати LaTeX, оскільки MS Word простіший для більшості людей.

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;

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

Семантика 102

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

Висновок

Чи помітять відвідувачі? Ні. Ваш начальник піклується? Можливо. Чи іноді ми вирізаємо кути як програмісти? Звичайно. Але ми повинні? Ні. Кому вигідно, якщо ви використовуєте семантичну розмітку? Ви - і ваша професійна репутація. Тепер ідіть і робіть правильно.

Очевидна відповідь: Дивіться CSS Zen Garden . Якщо ви скажете мені, що ви можете легко зробити те ж саме з макетів на основі таблиць (пам’ятайте - HTML не змінюється), то будь-яким чином використовуйте таблиці для компонування.

Ще дві важливі речі - доступність та SEO.

Обидва дбають про те, в якому порядку подається інформація. Ви не можете легко представити навігацію вгорі сторінки, якщо ваш макет на основі таблиці розмістить його в 3-й комірці 2-го ряду 2-ї вкладеної таблиці на сторінці.

Тож ваші відповіді - це ремонтопридатність, доступність та SEO.

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

Дивіться це повторне запитання.

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

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

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

На жаль, CSS Zen Garden вже не можна використовувати як приклад хорошого дизайну HTML / CSS. Практично всі їх останні дизайни використовують графіку для заголовка розділів. Ці графічні файли вказані в CSS.

Отже, веб-сайт, метою якого є показати перевагу утримання дизайну від вмісту, тепер регулярно здійснює БЕЗПЕЧНИЙ ГРИХ введення вмісту в дизайн. (Якби заголовок розділу у файлі HTML змінився, заголовка розділу не відображатиметься).

Що лише свідчить про те, що навіть ті, хто виступає за сувору релігію DIV & CSS, не можуть слідувати власним правилам. Ви можете використовувати це як орієнтир у тому, наскільки уважно ви їх дотримуєтесь.

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

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

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

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

• CSS для стилів дозволяє браузеру кешувати файли, а наступні запити набагато швидше. Це ВЕЛИЧЕЗНО.

• Столи замикають вас у дизайні. Звичайно, не всім потрібна гнучкість CSS Zen Garden, але я ніколи не працював на сайті, де мені не потрібно було трохи міняти дизайн тут і там. З CSS це набагато простіше.

• Столи важко стилізувати. У вас не дуже велика гнучкість з ними (тобто вам все одно потрібно додати атрибути HTML, щоб повністю керувати стилями таблиці)

Я не використовував таблиці для нетабличних даних, ймовірно, протягом 4 років. Я не озирнувся.

Я дуже хотів би запропонувати прочитати 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 - це макет! Зміст - це дані в таблиці, презентація - сама таблиця. Ось чому відокремити CSS від HTML часом може бути дуже складно. Ви не відділяєте вміст від презентації, ви відокремлюєте презентацію від презентації! Купа вкладених дівок не відрізняється від таблиці - це просто інший набір тегів.

Інша проблема відділення HTML від CSS полягає в тому, що їм потрібні інтимні знання один про одного - ви насправді не можете їх повністю розділити. Макет тегу в HTML щільно поєднаний з файлом CSS незалежно від того, що ви робите.

Я думаю, що таблиці vs divs зводяться до потреб вашої програми.

У програмі, яку ми розробляємо на роботі, нам знадобився макет сторінки, де фрагменти динамічно розміщували б їх вміст. Я витрачав дні, намагаючись змусити це працювати на крос-браузері з CSS та DIV, і це був повний кошмар. Ми перейшли на столи, і це все просто спрацювало .

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

CSS / DIV - це просто завдання для дизайнерів, чи не так. Сотні годин, які я провів налагодження проблем DIV / CSS, шукаючи Інтернет, щоб отримати частину розмітки, працюючи з неясним браузером - це зводить мене з розуму. Ви зробите одну невелику зміну, і весь макет іде жахливо не так - де в принципі логіка в цьому. Витрачаючи години таким чином, рухаючи щось 3 пікселі, потім щось ще 2 пікселі, щоб змусити їх вирівнятись. Це якимось чином мені здається просто неправильним. Тільки тому, що ти пурист, і щось "не правильно робити", не означає, що ти повинен використовувати це до п ятого ступеня і за будь-яких обставин, особливо якщо це полегшує твоє життя в 1000 разів.

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

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

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

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

На конкретний випадок - на основі цієї дискусії я перетворив декілька існуючих TDS і Trs на діви. 45 хвилин возився з цим, намагаючись змусити все вишикуватися поруч, і я здався. ЗР через 10 секунд - працює - відразу - у всіх браузерах, нічого більше робити. Будь ласка, спробуйте дати мені зрозуміти - яке ви маєте виправдання для того, що хочете, щоб я це зробив інакше!

Макет повинен бути легким. Той факт, що є статті, написані про те, як досягти динамічного макета трьох стовпців із заголовком та колонтитулом у CSS, свідчить, що це погана система компонування. Звичайно, ви можете змусити його працювати, але в мережі є буквально сотні статей про те, як це зробити. Немає таких статей для подібного макета з таблицями, оскільки це очевидно. Незалежно від того, що ви говорите проти таблиць і на користь CSS, цей факт скасовує все: основний макет трьох стовпців у CSS часто називають "Святим Граалом".

Якщо це не змушує вас сказати "WTF", тоді вам дійсно потрібно відкласти команду kool.

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

Більша проблема полягає в тому, що, не допускаючи відсутніх функцій, CSS-завзятці стримували CSS від усіх можливих. Я б із задоволенням зупинився на використанні таблиць, якби CSS забезпечив пристойне багатоосеве розташування сітки, як в основному, будь-який інший механізм компонування у світі. (Ви розумієте, що цю проблему вже багато разів вирішували багатьма мовами, крім W3C, так? І ніхто інший не заперечував, що така функція була корисною.)

Зітхнути. Досить вентиляції. Ідіть вперед і засуньте голову назад в пісок.

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

Якщо ви призначите імена кожному з divs, ви можете зняти їх разом разом, використовуючи 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. На нашому високошвидкісному широкосмуговому зв'язку це не велика проблема, але це стосується модемів, що мають комутовані комутатори.

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

Ваш код також має значення від семантичного точки зору.

Ніяких аргументів у DIVs мені не сприяє.

Я б сказав: Якщо взуття підходить, носіть її.

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

Це підказує трохи баланс до столів у більшості моїх макетів, і хоча я відчуваю себе винним у тому, що їх використовую (дурень чому, люди просто кажуть, що це погано, тому я намагаюся їх слухати), врешті-решт, прагматичний погляд - це просто простіше і швидше мені використовувати ТАБЛИЦІ. Мені не платять за годину, тому столики для мене дешевші.

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

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

Якщо ви сумніваєтеся, що розділити вміст від верстки легше за допомогою div, ніж за допомогою таблиць, погляньте на HTML на базі div у CSS Zen Garden , подивіться, як зміна таблиць стилів може кардинально змінити макет, і подумайте, чи могли ви досягайте тієї ж різноманітності макетів, якщо на основі HTML був табличний ... Якщо ви робите макет на основі таблиці, ви навряд чи будете використовувати CSS для контролю всіх інтервалів та прокладок у клітинках (якби ви були, ви майже напевно мені буде легше використовувати плаваючі диви тощо в першу чергу). Не використовуючи CSS для контролю над усім цим, а через те, що таблиці задають порядок ліворуч праворуч та верхній у нижній частині речей у HTML, таблиці, як правило, означають, що ваш макет стає дуже зафіксованим у HTML.

Реально я думаю, що дуже важко повністю змінити макет дизайну на основі div-and-CSS, не змінюючи девісів трохи. Однак за допомогою макета на основі div-і-CSS набагато простіше налаштувати такі речі, як проміжок між різними блоками та їх відносні розміри.

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

Я спробував переключити один із сайтів нашої компанії з таблиць на діви, і це був такий головний біль, що я цілком скоротив годин роботи, яку я вилив у неї, і повернувся до столів. Намагання боротися з моїми дівами, щоб отримати контроль над вертикальним вирівнюванням, прокляла мене основними психологічними проблемами, які я ніколи не похитнуться, поки триватиме ця дискусія.

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

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

Google та інші автоматизовані системи роблять догляд, і вони так само важливі в багатьох ситуаціях. Семантичний код простіший для неінтелектуальної системи проаналізувати та обробити.

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

Це, звичайно, кращий випадок, але дизайн на основі столу неможливий. Якщо ви використовуєте css, ви відокремлюєте стиль, тому під час виправлення HTML у вас менше турбуватися про порушення.

Також спробуйте це за допомогою JavaScript. Перемістіть одну клітинку таблиці з одного місця в інше місце в іншій таблиці. Досить складно виконувати там, де div / span просто працюватиме копіювально-вставляти.

"Чи хвилює мій начальник"

Якби я був вашим начальником. Ви б піклувалися. ;) Якщо ви цінуєте своє життя.

Гнучкість макета
Уявіть, що ви створюєте сторінку з великою кількістю ескізів.
DIVs :
Якщо ви поміщаєте кожну мініатюру у DIV, плаваючий ліворуч, можливо, 10 з них вміщуються в ряд. Зробіть вікно більш вузьким, а BAM - це 6 підряд, або 2, або скільки завгодно.
ТАБЛИЦЯ:
Ви повинні чітко сказати, скільки клітинок підряд. Якщо вікно занадто вузьке, користувачеві доводиться прокручувати горизонтально.

Технічне обслуговування
Та сама ситуація, що і вище. Тепер ви хочете додати три ескізи до третього ряду.
DIVs:
додайте їх. Макет автоматично регулюється.
ТАБЛИЦЯ. Вставте нові комірки в третій ряд. На жаль! Зараз там занадто багато предметів. Виріжте деякі з цього ряду і покладіть їх на четвертий ряд. Зараз там занадто багато предметів. Виріжте частину з цього рядка ... (тощо)
( Звичайно, якщо ви створюєте рядки та комірки за допомогою сценаріїв на стороні сервера, це, ймовірно, не буде проблемою. )

Я думаю, що той човен відплив. Якщо ви подивитесь на напрямок галузі, ви помітите, що переможці цієї дискусії - CSS та відкриті стандарти. Що в свою чергу означає для більшості html-робіт, за винятком форм, дизайнери використовуватимуть divs замість таблиць. Мені важко з цим, тому що я не гуру CSS, але так воно і є.

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

Я особисто виявив, що багато людей використовують занадто багато <div>тегів, але в помірності це може бути надзвичайно чистим і легким для читання. Ви згадуєте, що людям важче читати CSS, ніж таблиці; з точки зору «коду», який може бути правдивим; але з точки зору читання контенту (view> source) набагато простіше зрозуміти структуру за допомогою таблиць стилів, ніж для таблиць.

Схоже, ви просто звикли до таблиць, і все. Внесення макета до таблиці обмежує вас лише для цього макета. За допомогою CSS ви можете переміщати біти, подивитися на http://csszengarden.com/ І ні, макет зазвичай не вимагає багато вкладених дівок.

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

Переваги SEO випливають із можливості мати найважливіший вміст вище сторінки та покращити співвідношення вмісту та розмітки.

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

• 508 Відповідність - можливість екранного читання зрозуміти вашу розмітку.
• Очікування на візуалізацію - таблиці не відображаються в браузері, поки вони не дістаються до кінця </table>елемента.

Вся ідея навколо семантичної розмітки - це розділення розмітки та презентації, що включає компонування.

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

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

Мова йде не про те, чи краще "divs, ніж таблиці для верстки". Хтось, хто розуміє CSS, може дублювати будь-який дизайн, використовуючи «таблиці макетів» досить просто. Справжня виграш - це використання елементів HTML для того, для чого вони є. Причина, по якій ви не використовуєте таблиці для нетабличних даних, є тією ж причиною, коли ви не зберігаєте цілі числа як рядки символів - технологія працює набагато простіше, коли ви використовуєте їх для тих цілей, для яких вони призначені. Якщо колись потрібно було використовувати таблиці для компонування (через недоліки браузера на початку 1990-х), це зараз точно не є.

Інструменти, які використовують макети таблиць, можуть стати надзвичайно важкими через кількість коду, необхідного для створення макета. Портал Netweaver SAP за замовчуванням використовує TABLE для компонування своїх сторінок.

Портал виробництва SAP на моєму теперішньому концерті має домашню сторінку, HTML якої важить понад 60 К і заглиблює сім таблиць, три рази в межах сторінки. Додайте в Javascript неправомірне використання 16 кадрів із подібними проблемами таблиці всередині них, надмірно важкого CSS тощо, а сторінка важить понад 5 Мб.

Витратити час, щоб зменшити вагу сторінки, щоб ви могли використовувати свою пропускну здатність для занять із користувачами, варто докласти зусиль.

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

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

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

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

Тому що ПРАВО підтримувати веб-сайт, що використовує таблиці, і кодує багато часу, щоб кодувати. Якщо ви боїтесь плаваючих дивів, перейдіть на курс. Їх не важко зрозуміти, і вони приблизно в 100 разів ефективніші і в мільйон разів менше болять в попці (якщо ви їх не розумієте - але ей, ласкаво просимо у світ комп'ютерів).

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

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

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

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

Однак проблема з таблицями полягає в тому, що модель компонування таблиць у CSS не підтримується в Microsoft Internet Explorer. Тому таблиці та CSS не є рівнозначними за потужністю. Відсутня частина - сітчаста поведінка таблиць, де краї комірок вирівнюються як вертикально, так і горизонтально, а комірки все ще розширюються, щоб містити їх вміст. Такої поведінки досягти в чистому CSS без жорсткого кодування деяких розмірів, що робить дизайн жорстким і крихким (доки ми повинні підтримувати Internet Explorer - в інших браузерах це легко досягти за допомогою використання display:table-cell).

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

Найголовніша причина цього немає використання таблиць є доступність. Посібники з доступності веб-вмісту http://www.w3.org/TR/WCAG10/ поради щодо використання таблиць для компонування. Якщо вас турбує доступність (а в деяких випадках вас можуть покладати юридичні обов'язки), вам слід використовувати CSS, навіть якщо таблиці простіші. Зауважте, що ви завжди можете створити такий же макет із CSS, як і для таблиць, це може просто вимагати більше роботи.

Я був здивований, побачивши, що деякі питання вже не висвітлювалися, тому ось мої 2 копійки, окрім усіх дуже дійсних моментів, зроблених раніше:

.1. CSS та SEO:

a) CSS використовував дуже суттєвий вплив на SEO, дозволяючи розміщувати вміст на сторінці, де ви хочете. Кілька років тому пошукові системи приділяли вагомий акцент факторам "на сторінці". Щось у верхній частині сторінки вважалося більш релевантним для сторінки, ніж те, що знаходиться внизу. "Верх сторінки" для павука означав "на початку коду". Використовуючи CSS, ви можете організувати вміст, багатий на ключові слова, на початку коду та зберігати його там, де вам сподобалось на сторінці. Це все ще є дещо актуальним, але на сторінці фактори все менше і менш важливі для ранжирування сторінок.

б) Коли макет переміщується на CSS, сторінка HTML легша і тому завантажується швидше для павука пошукової системи. (павуки не заважають завантажувати зовнішні файли css). Швидке завантаження сторінок є важливим фактором рейтингу для кількох пошукових систем, включаючи Google

в) SEO робота часто вимагає тестування та зміни речей, що набагато зручніше з компонуванням на основі CSS

.2. Створений контент:

Таблицю значно простіше створити програмно, ніж еквівалентний CSS-макет.

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

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

Далі, коли генерується таблиця, вміст (у змінних) вже відокремлений від макета (у коді), що робить його так само легко змінювати.

Це одна з причин, чому деякі дуже добре розроблені веб-сайти (наприклад, SO) все ще використовують макети таблиць.

Звичайно, якщо на результати потрібно діяти через JavaScript, діви варті клопоту.

.3. Тестування на швидке перетворення

З'ясовуючи, що працює для конкретної аудиторії, корисно мати можливість змінювати макет різними способами, щоб з’ясувати, що дає найкращі результати. Макет на основі CSS значно спрощує справи

.4. Різні рішення для різних проблем

Таблиці макетів зазвичай не використовуються, оскільки "всі знають діви та CSS" - це шлях.

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

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

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

Я, наприклад, нудився і втомився від реакції на коліна "О, ні, столи для планування!"

Щодо натовпу "він не був призначений для цієї мети, і тому ви не повинні використовувати це таким чином", чи не це лицемірство? Що ви думаєте про всі трюки CSS, які ви повинні використати для роботи чортового в більшості браузерів? Чи були вони призначені для цієї мети?