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

Кажется, существует общее мнение, что таблицы не должны использоваться для разметки в HTML.

Почему?

Я никогда (или редко если быть честным) не видел хороших аргументов для этого. Обычные ответы:

• Это хорошо, чтобы отделить контент от макета
  Но это ошибочный аргумент; Мышление клише . Я думаю, это правда, что использование элемента таблицы для разметки имеет мало общего с табличными данными. И что? Мой босс заботится? Заботятся ли мои пользователи?
  
  Возможно, я или мои коллеги-разработчики, которым нужно заботиться о веб-странице ... Является ли таблица менее обслуживаемой? Я думаю, что использовать таблицу проще, чем использовать divs и CSS.
  
  Кстати ... почему использование div или span хорошо отделяет контент от макета и таблицы? Чтобы получить хороший макет только с div-файлами, часто требуется много вложенных div-ов.

• Читаемость кода,
  я думаю, что все наоборот. Большинство людей понимают HTML, мало кто понимает CSS.

• Для SEO лучше не использовать таблицы.
  Почему? Кто-нибудь может показать некоторые доказательства того, что это так? Или заявление от Google, что таблицы не рекомендуется с точки зрения SEO?

• Таблицы медленнее.
  Нужно вставить дополнительный элемент tbody. Это арахис для современных веб-браузеров. Покажите мне несколько тестов, где использование таблицы значительно замедляет страницу.

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

Я действительно заинтересован в хороших аргументах, чтобы использовать divs + CSS вместо таблиц.

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

Это хорошо, чтобы отделить контент от макета Но это ошибочный аргумент; Мышление клише.

Это вовсе не ошибочно, потому что HTML был разработан специально. Неправильное использование элемента не может быть полностью исключено (в конце концов, новые идиомы также появились на других языках), но возможные негативные последствия должны быть уравновешены. Кроме того, даже если бы не было аргументов против неправильного использования <table>элемента сегодня, это может произойти завтра из-за того, как поставщики браузеров применяют к элементу особый режим. В конце концов, они знают, что « <table>элементы предназначены только для табличных данных» и могут использовать этот факт для улучшения механизма рендеринга, в процессе которого слегка изменяются способы его <table>поведения и, таким образом, ломаются случаи, когда они ранее использовались неправильно.

И что? Мой босс заботится? Заботятся ли мои пользователи?

Зависит. Твой босс заостренный? Тогда ему может быть все равно. Если она компетентна, то она будет заботиться, потому что пользователи будут .

Возможно, я или мои коллеги-разработчики, которым нужно заботиться о веб-странице ... Является ли таблица менее обслуживаемой? Я думаю, что с помощью таблицы проще, чем с помощью divs и css.

Большинство профессиональных веб-разработчиков, кажется, против вас^{[ цитата нужна ]} . Это столы являются на самом деле менее ремонтопригодны должно быть очевидно. Использование таблиц для макета означает, что изменение корпоративного макета фактически будет означать изменение каждой отдельной страницы. Это может быть очень дорого. С другой стороны, разумное использование семантически значимого HTML в сочетании с CSS может ограничить такие изменения CSS и используемыми изображениями.

Кстати ... почему использование div или span хорошо отделяет контент от макета и таблицы? Чтобы получить хороший макет только с div-файлами, часто требуется много вложенных div-ов.

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

Читаемость кода, я думаю, что все наоборот. Большинство людей понимают HTML, мало понимают CSS. Это проще

«Большинство людей» не имеют значения. Профессионалы имеют значение. Для профессионалов макеты таблиц создают гораздо больше проблем, чем HTML + CSS. Это все равно что сказать, что я не должен использовать GVim или Emacs, потому что Notepad проще для большинства людей. Или что я не должен использовать LaTeX, потому что MS Word проще для большинства людей.

SEO лучше не использовать таблицы

Я не знаю, правда ли это, и не использовал бы это в качестве аргумента, но это было бы логично. Поисковые системы ищут соответствующие данные. Хотя табличные данные, конечно, могут быть актуальны, пользователи редко ищут. Пользователи ищут термины, используемые в заголовке страницы или аналогичные видные позиции. Поэтому было бы логично исключить табличный контент из фильтрации и, таким образом, сократить время обработки (и затраты!) В значительной степени.

Таблицы медленнее. Нужно вставить дополнительный элемент tbody. Это арахис для современных веб-браузеров.

Дополнительный элемент не имеет ничего общего с медленностью таблиц. С другой стороны, алгоритм разметки таблиц намного сложнее, браузеру часто приходится ждать загрузки всей таблицы, прежде чем он сможет начать разметку содержимого. Кроме того, кэширование макета не будет работать (CSS может быть легко кэширован). Все это уже упоминалось ранее.

Покажите мне несколько тестов, где использование таблицы значительно замедляет страницу.

К сожалению, у меня нет данных о тестах. Я был бы заинтересован в этом сам, потому что правильно, что этому аргументу не хватает определенной научной строгости.

Большинству веб-сайтов, которые нуждаются в обновлении, также необходим новый контент (html). Сценарии, когда новой версии веб-сайта нужен только новый файл CSS, маловероятны.

Не за что. Я работал над несколькими случаями, когда изменение дизайна было упрощено разделением контента и дизайна. Часто все еще необходимо изменить некоторый HTML-код, но изменения всегда будут намного более ограниченными. Кроме того, изменения в дизайне должны быть сделаны динамически. Рассмотрим шаблоны шаблонов, такие как тот, который используется системой блогов WordPress. Расположение таблиц буквально убило бы эту систему. Я работал над аналогичным случаем для коммерческого программного обеспечения. Возможность изменить дизайн без изменения кода HTML была одним из требований бизнеса.

Еще одна вещь. Расположение таблиц значительно усложняет автоматический анализ веб-сайтов (очистку экрана). Это может звучать тривиально, потому что, в конце концов, кто это делает? Я был удивлен сам. Соскребание экрана может сильно помочь, если рассматриваемая служба не предлагает альтернативу WebService для доступа к своим данным. Я работаю в биоинформатике, где это печальная реальность. Современные веб-технологии и веб-сервисы не достигли большинства разработчиков, и зачастую, очистка экрана - единственный способ автоматизировать процесс получения данных. Неудивительно, что многие биологи до сих пор выполняют такие задачи вручную. Для тысяч наборов данных.

Вот ответ моего программиста из ветки simliar

Семантика 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 вы можете взять одну и ту же разметку и изменить макет в зависимости от среды, что является хорошим преимуществом. Для печатной страницы вы можете спокойно отключить навигацию, например, без необходимости создания страницы, удобной для печати.

Одна таблица для разметки не будет так уж плохо. Но большую часть времени вы не можете получить нужный макет только с одним столом. Довольно скоро у вас есть 2 или 3 вложенных таблицы. Это становится очень громоздким.

• Это гораздо сложнее читать. Это не зависит от мнения. Просто есть больше вложенных тегов без опознавательных знаков.

• Отделение контента от презентации - это хорошо, потому что оно позволяет вам сосредоточиться на том, что вы делаете. Смешение двух приводит к раздутым страницам, которые трудно читать.

• 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 иногда бывает очень сложно. Вы не отделяете контент от презентации, вы отделяете презентацию от презентации! Куча вложенных элементов div не отличается от таблицы - это просто другой набор тегов.

Другая проблема, связанная с отделением HTML от CSS, заключается в том, что они нуждаются в глубоких знаниях друг друга - вы действительно не можете отделить их полностью. Макет тега в HTML тесно связан с файлом CSS независимо от того, что вы делаете.

Я думаю, что таблицы против divs сводится к потребностям вашего приложения.

В приложении, которое мы разрабатываем на работе, нам нужен был макет страницы, где части динамически изменяли бы размер своего контента. Я потратил несколько дней, пытаясь заставить его работать кросс-браузерно с CSS и DIVs, и это был полный кошмар. Мы перешли на столы, и все это просто сработало .

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

CSS / DIV - это просто работа для дизайнеров, не так ли? Сотни часов, которые я потратил на отладку проблем с DIV / CSS, на поиск в Интернете, чтобы получить какую-то часть разметки, работая с неясным браузером - это сводит меня с ума. Вы вносите одно маленькое изменение, и вся раскладка идет ужасно неправильно - в этом вся логика. Тратьте часы, перемещая что-то на 3 пикселя таким образом, а затем что-то еще на 2 пикселя, чтобы все выровнялись Это просто кажется мне как-то неправильно. Тот факт, что вы пурист и что-то «не то, что нужно делать», не означает, что вы должны использовать это до n-й степени и при любых обстоятельствах, особенно если это облегчает вашу жизнь в 1000 раз.

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

Единственная причина, по которой встречаются все эти аргументы CSS / DIV, это из-за недостатка CSS, а также из-за того, что браузеры несовместимы друг с другом, и если бы они были, половина веб-дизайнеров в мире была бы без работы ,

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

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

Показательный пример - на основе этой дискуссии я преобразовал несколько существующих tds и trs в div. 45 минут возились с ним, пытаясь заставить все выстроиться рядом друг с другом, и я сдался. ТД возвращаются через 10 секунд - работает - сразу - во всех браузерах, больше ничего не нужно делать. Пожалуйста, попытайтесь заставить меня понять - какое у вас может быть оправдание, если вы хотите, чтобы я сделал это как-то иначе!

Макет должен быть легким. Тот факт, что есть статьи о том, как создать динамический макет из трех столбцов с верхним и нижним колонтитулами в CSS, показывает, что это плохая система макетов. Конечно, вы можете заставить его работать, но есть буквально сотни статей о том, как это сделать. Подобных макетов с таблицами почти нет, потому что это очевидно. Неважно, что вы говорите против таблиц и в пользу CSS, этот факт отменяет все это: базовый макет из трех столбцов в CSS часто называют «Святым Граалем».

Если это не заставляет вас говорить «WTF», тогда вам действительно необходимо отменить помощь kool.

Я люблю CSS. Он предлагает удивительные варианты стилей и некоторые классные инструменты позиционирования, но в качестве механизма компоновки его недостаточно. Должна быть какая-то система динамического позиционирования сетки. Простой способ выровнять блоки по нескольким осям, не зная сначала их размеров. Мне наплевать, если вы называете это <table> или <gridlayout> или как-то еще, но это базовая функция макета, которая отсутствует в CSS.

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

Вздох. Достаточно вентиляции. Иди вперед и воткни свою голову обратно в песок.

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

Если вы присваиваете имена каждому из элементов div, вы можете объединить их все вместе с помощью 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-аналоги. На нашем высокоскоростном широкополосном соединении это не такая большая проблема, как на модемах с коммутируемым доступом.

Я хотел бы добавить, что макеты на основе div проще в обслуживании, развитии и рефакторинге. Просто некоторые изменения в CSS, чтобы изменить порядок элементов, и это сделано. Исходя из моего опыта, перепроектирование макета с использованием таблиц - это кошмар (больше, если есть вложенные таблицы).

Ваш код также имеет смысл с семантической точки зрения.

Никаких аргументов в пользу DIV от меня нет.

Я бы сказал: если обувь подходит, носите ее.

Стоит отметить, что трудно, если не невозможно, найти хороший метод DIV + CSS для рендеринга контента в двух или трех столбцах, который одинаков для всех браузеров и при этом выглядит так, как я задумал.

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

CSS-макеты, как правило, намного удобнее для доступа, если контент представлен в естественном порядке и имеет смысл без таблицы стилей. И не только программы чтения с экрана борются с макетами на основе таблиц: они также усложняют для мобильных браузеров правильное отображение страницы.

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

Если вы сомневаетесь, что отделить содержимое от макета легче с помощью div, чем с таблицами, взгляните на HTML на основе div в CSS Zen Garden. , посмотрите, как изменение таблиц стилей может кардинально изменить макет, и подумайте, можете ли вы это сделать. добиться того же разнообразия макетов, если HTML был основан на таблицах ... Если вы делаете макет на основе таблиц, вы вряд ли будете использовать CSS для управления всеми интервалами и отступами в ячейках (если вы почти наверняка было бы проще использовать плавающие div и т. д. в первую очередь). Без использования CSS для управления всем этим, а также из-за того, что в таблицах указан порядок слева направо и сверху вниз в HTML, таблицы, как правило, означают, что ваш макет очень сильно фиксируется в HTML.

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

Тот факт, что это горячо обсуждаемый вопрос, свидетельствует о том, что W3C не смог предвидеть разнообразие макетов, которые могли бы быть предприняты. Использование divs + css для семантически дружественного макета является отличной концепцией, но детали реализации настолько несовершенны, что фактически ограничивают свободу творчества.

Я попытался переключить один из сайтов нашей компании с таблиц на div, и это была такая головная боль, что я полностью отбросил часы работы, которые я налил, и вернулся к столам. Попытка бороться со своими дивами, чтобы получить контроль над вертикальным выравниванием, проклинала меня с серьезными психологическими проблемами, которые я никогда не буду трясти, пока идут эти дебаты.

Тот факт, что людям часто приходится придумывать сложные и уродливые обходные пути для достижения простых целей проектирования (таких как вертикальное выравнивание), убедительно свидетельствует о том, что правила недостаточно гибки. Если спецификации достаточно, то почему высококлассные сайты (например, SO) считают необходимым изменить правила, используя таблицы и другие обходные пути?

Я думаю, это правда, что использование элемента таблицы для разметки имеет мало общего с табличными данными. И что? Мой босс заботится? Заботятся ли мои пользователи?

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

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

Это, конечно, крайний случай, но дизайн на основе таблиц не поддерживается. Если вы используете css, вы выделяете стиль, поэтому при исправлении HTML вам не нужно беспокоиться о нарушении.

Кроме того, попробуйте это с JavaScript. Переместите одну ячейку таблицы из одного места в другое место в другой таблице. Сложно выполнить там, где div / span будет просто работать с копированием-вставкой.

"Мой босс заботится"

Если бы я был твоим боссом. Тебя это волнует. ;) Если вы цените свою жизнь.

Гибкость макета
Представьте, что вы создаете страницу с большим количеством миниатюр.
DIVs :
если вы поместите каждую миниатюру в DIV с плавающей точкой влево, возможно, 10 из них поместятся в ряд. Сделайте окно уже, а БАМ - это 6 на ряд, или 2, или сколько угодно.
ТАБЛИЦА:
Вы должны явно сказать, сколько ячеек подряд. Если окно слишком узкое, пользователь должен прокрутить горизонтально.

Ремонтопригодность
Та же ситуация, что и выше. Теперь вы хотите добавить три эскиза в третий ряд.
DIVs:
добавьте их. Макет будет автоматически изменен.
ТАБЛИЦА: Вставьте новые ячейки в третий ряд. К сожалению! Сейчас там слишком много предметов. Вырежьте некоторые из этого ряда и поместите их в четвертый ряд. Сейчас там слишком много предметов. Вырежьте некоторые из этой строки ... (и т. Д.)
( Конечно, если вы генерируете строки и ячейки с помощью серверных сценариев, это, вероятно, не будет проблемой. )

Я думаю, что лодка отплыла. Если вы посмотрите на направление, в котором движется индустрия, вы заметите, что CSS и открытые стандарты являются победителями этого обсуждения. Это, в свою очередь, означает, что для большинства html-работ, за исключением форм, дизайнеры будут использовать div вместо таблиц. Мне тяжело с этим, потому что я не гуру CSS, но так оно и есть.

Кроме того, не забывайте, что таблицы не очень хорошо отображаются в мобильных браузерах. Конечно, у iPhone есть потрясающий браузер, но у всех нет iPhone. Рендеринг таблиц может быть арахисом для современных браузеров, но для мобильных браузеров это куча арбузов.

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

Похоже, вы просто привыкли к таблицам и все. Размещение макета в таблице ограничивает вас только этим макетом. С помощью CSS вы можете перемещаться, посмотрите на http://csszengarden.com/ И нет, компоновка обычно не требует большого количества вложенных элементов div.

Без таблиц для разметки и правильной семантики HTML намного чище, следовательно, его легче читать. Почему кто-то, кто не понимает CSS, должен читать это? И если кто-то считает себя веб-разработчиком, то хорошее понимание CSS является обязательным условием.

Преимущества SEO заключаются в возможности размещать наиболее важный контент выше страницы и иметь лучшее соотношение контента к разметке.

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

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

Вся идея семантической разметки заключается в разделении разметки и представления, которое включает макет.

Div не заменяют таблицы, они имеют свое собственное использование для разделения контента на блоки связанного контента (,). Если у вас нет навыков и вы полагаетесь на таблицы, вам часто приходится разделять содержимое на ячейки, чтобы получить желаемый макет, но вам не нужно прикасаться к разметке, чтобы добиться презентации при использовании семантической разметки. Это действительно важно, когда генерируется разметка, а не статические страницы.

Разработчики должны прекратить предоставлять разметку, которая подразумевает компоновку, чтобы те из нас, кто обладает навыками представления контента, могли продолжать работу, а разработчикам не нужно возвращаться к своему коду, чтобы вносить изменения, когда презентация нуждается в изменении.

Дело не в том, лучше ли div'ы, чем таблицы для разметки. Кто-то, кто понимает CSS, может довольно просто продублировать любой дизайн, используя «таблицы раскладок». Настоящая победа заключается в использовании элементов HTML для того, для чего они существуют. Причиной того, что вы не будете использовать таблицы для не табличных данных, является та же причина, по которой вы не храните целые числа в виде строк символов - технология работает намного проще, если вы используете ее в целях, для которых она предназначена. Если когда-либо было необходимо использовать таблицы для разметки (из-за недостатков браузера в начале 1990-х), то это, конечно, не сейчас.

Инструменты, использующие макеты таблиц, могут стать чрезвычайно тяжелыми из-за объема кода, необходимого для создания макета. Netweaver Portal от SAP по умолчанию использует TABLE для разметки своих страниц.

На производственном портале SAP, на котором я сейчас работаю, есть домашняя страница, HTML-код которой весит более 60 КБ и занимает семь таблиц глубиной, три раза на одной странице. Добавьте в Javascript неправильное использование 16 iframes с похожими проблемами таблиц внутри них, чрезмерно тяжелый CSS и т. Д., И страница весит более 5 МБ.

Стоит потратить время на то, чтобы уменьшить вес страницы, чтобы вы могли использовать пропускную способность для взаимодействия с пользователями.

Стоит выяснить CSS и div, чтобы центральный столбец контента загружался и отображался перед боковой панелью в макете страницы. Но если вы изо всех сил пытаетесь использовать плавающие div-ы для вертикального выравнивания логотипа с каким-либо спонсорским текстом, просто используйте таблицу и продолжайте жить. Религия дзен-сада просто не дает большого эффекта.

Идея отделения контента от представления состоит в том, чтобы разделить приложение таким образом, чтобы различные виды работы влияли на разные блоки кода. Это на самом деле об управлении изменениями. Но стандарты кодирования могут только исследовать текущее состояние кода поверхностно.

Журнал изменений для приложения, которое зависит от стандартов кодирования для «отделения контента от представления», покажет шаблон параллельных изменений в вертикальных хранилищах. Если изменение «контента» всегда сопровождается изменением «презентации», насколько успешным является разбиение?

Если вы действительно хотите продуктивно разбить код на части, используйте Subversion и просмотрите журналы изменений. Затем используйте простейшие методы кодирования - div, таблицы, JavaScript, include, функции, объекты, продолжения и т. Д. - чтобы структурировать приложение так, чтобы изменения вписывались простым и удобным способом.

Потому что АД поддерживать сайт, который использует таблицы и требует много времени для написания кода. Если вы боитесь плавающих дивов, пройдите курс по ним. Их не сложно понять, и они примерно в 100 раз эффективнее и в миллион раз меньше боли в заднице (если вы их не понимаете - но, эй, добро пожаловать в мир компьютеров).

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

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

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

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

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

Поэтому вопрос не в том, предпочтительны ли таблицы или CSS, а в том, чтобы распознать конкретные случаи, когда использование таблиц может сделать макет более гибким.

Наиболее важной причиной не использования таблиц является доступность. Руководство по доступности веб-контента http://www.w3.org/TR/WCAG10/ advice снова использует таблицы для макета. Если вас беспокоит доступность (а в некоторых случаях вы обязаны по закону), вам следует использовать CSS, даже если таблицы проще. Обратите внимание, что вы всегда можете создать такой же макет с помощью CSS, как и с таблицами, для этого может потребоваться больше работы.

Я был удивлен, увидев, что некоторые проблемы еще не были рассмотрены, так что вот мои 2 цента, в дополнение ко всем очень важным пунктам, сделанным ранее:

0,1. CSS & SEO:

а) CSS имел большое влияние на SEO, позволяя размещать контент на странице где угодно. Несколько лет назад поисковые системы уделяли значительное внимание факторам «на странице». Что-то вверху страницы считалось более релевантным для страницы, чем что-то внизу. «Верх страницы» для паука означает «в начале кода». Используя CSS, вы можете организовать свой богатый ключевыми словами контент в начале кода и по-прежнему размещать его там, где вам нравится на странице. Это все еще в некоторой степени актуально, но факторы страницы все менее важны для ранжирования страниц.

б) Когда макет переходит на CSS, HTML-страница становится светлее и, следовательно, загружается быстрее для поисковой машины. (пауки не беспокоятся о загрузке внешних CSS-файлов). Быстрая загрузка страниц является важным фактором рейтинга для нескольких поисковых систем, включая Google

c) SEO работа часто требует тестирования и изменения вещей, что намного удобнее с макетом на основе CSS

0,2. Созданный контент:

Таблицу значительно проще создать программно, чем эквивалентный макет CSS.

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

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

Кроме того, при создании таблицы содержимое (в переменных) уже отделено от макета (в коде), что упрощает его изменение.

Это одна из причин, почему некоторые очень хорошо разработанные веб-сайты (например, SO) все еще используют макеты таблиц.

Конечно, если результаты нужно обрабатывать с помощью JavaScript, div стоит того.

0,3. Быстрое тестирование конверсии

При выяснении того, что работает для конкретной аудитории, полезно иметь возможность изменять макет различными способами, чтобы выяснить, что дает наилучшие результаты. Макет на основе CSS делает вещи значительно проще

+0,4. Разные решения для разных проблем

Таблицы макетов обычно игнорируются, потому что «все знают, что такое divs и CSS».

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

У столов есть много недостатков, в том числе уход, отсутствие гибкости ... но давайте не будем бросать ребенка в ванну с водой. Существует множество профессиональных решений для быстрого и надежного решения.

Некоторое время назад мне пришлось переписать чистый и простой макет CSS с использованием таблиц, потому что значительная часть пользователей будет использовать более старую версию IE с действительно плохой поддержкой CSS

Я, например, устал от реакции коленного рефлекса "О, нет! Столы для разметки!"

Что касается толпы «она не была предназначена для этой цели, и поэтому вы не должны использовать ее таким образом», разве это не лицемерие? Что вы думаете обо всех хитростях CSS, которые вы должны использовать, чтобы заставить эту чертову штуку работать в большинстве браузеров? Были ли они предназначены для этой цели?