Почему бы не использовать таблицы для разметки в HTML?
Похоже, общее мнение, что таблицы не должны использоваться для разметки в HTML.
Зачем?
Я никогда (или редко если быть честным) не видел хороших аргументов для этого. Обычные ответы:
Это хорошо, чтобы отделить контент от макета
Но это ошибочный аргумент; Мышление клише. Я думаю, это правда, что использование элемента таблицы для разметки имеет мало общего с табличными данными. И что? Мой босс заботится? Заботятся ли мои пользователи?
Возможно, я или мои коллеги-разработчики, которым нужно заботиться о веб-странице... Является ли таблица менее обслуживаемой? Я думаю, что использовать таблицу проще, чем использовать divs и CSS.
Кстати... почему использование div или span хорошо отделяет контент от макета и таблицы? Получение хорошего макета только с div-ами часто требует большого количества вложенных div-ов.Читаемость кода
Я думаю, что все наоборот. Большинство людей понимают HTML, мало кто понимает CSS.SEO лучше не использовать таблицы
Зачем? Кто-нибудь может показать какие-либо доказательства того, что это так? Или заявление от Google о том, что таблицы не рекомендуется с точки зрения SEO?Таблицы медленнее.
Нужно вставить дополнительный элемент tbody. Это арахис для современных веб-браузеров. Покажите мне несколько тестов, где использование таблицы значительно замедляет страницу.Пересмотр компоновки легче без таблиц, см. Css Zen Garden.
Большинству веб-сайтов, которые нуждаются в обновлении, также необходим новый контент (HTML). Сценарии, когда новой версии веб-сайта нужен только новый файл CSS, маловероятны. Zen Garden - хороший веб-сайт, но немного теоретический. Не говоря уже о его неправильном использовании CSS.
Я действительно заинтересован в хороших аргументах, чтобы использовать divs + CSS вместо таблиц.
66 ответов
Я собираюсь просмотреть ваши аргументы один за другим и попытаться показать ошибки в них.
Хорошо отделить контент от макета Но это ошибочный аргумент; Мышление клише.
Это совсем не ошибочно, потому что HTML был разработан специально. Неправильное использование элемента не может быть полностью исключено (в конце концов, новые идиомы также появились на других языках), но возможные отрицательные последствия должны быть уравновешены. Кроме того, даже если не было никаких аргументов против злоупотребления <table>
элемент сегодня, может быть завтра из-за того, как поставщики браузеров применяют к элементу особый режим. В конце концов, они знают, что " <table>
элементы предназначены только для табличных данных ", и они могут использовать этот факт для улучшения механизма рендеринга, в процессе которого незаметно меняется способ <table>
s ведут себя, и, таким образом, нарушают случаи, когда он ранее использовался неправильно.
И что? Мой босс заботится? Заботятся ли мои пользователи?
Зависит. Твой босс заостренный? Тогда ему может быть все равно. Если она компетентна, то она будет заботиться, потому что пользователи будут.
Возможно, я или мои коллеги-разработчики, которым нужно заботиться о веб-странице... Является ли таблица менее обслуживаемой? Я думаю, что использовать таблицу проще, чем использовать divs и css.
Большинство профессиональных веб-разработчиков, кажется, против вас [ цитата нужна ]. То, что таблицы на самом деле менее ремонтопригодны, должно быть очевидным. Using tables for layout means that changing the corporate layout will in fact mean changing every single page. This can be very expensive. On the other hand, judicious use of semantically meaningful HTML combined with CSS might confine such changes to the CSS and the pictures used.
By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.
Deeply nested <div>
Это анти-шаблон как таблицы. Хорошие веб-дизайнеры не нуждаются во многих из них. С другой стороны, даже такие глубокие вложенные 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 Энди Бадда. Это невероятно.
Это хорошо, чтобы отделить контент от макета
Но это ошибочный аргумент; Мышление клише
Это ошибочный аргумент, потому что HTML-таблицы являются макетом! Содержание - это данные в таблице, представление - это сама таблица. Вот почему отделить CSS от HTML иногда бывает очень сложно. Вы не отделяете контент от презентации, вы отделяете презентацию от презентации! Куча вложенных элементов div не отличается от таблицы - это просто другой набор тегов.
Другая проблема, связанная с отделением HTML от CSS, заключается в том, что им необходимо глубокое знание друг друга - вы действительно не можете полностью отделить их. Макет тега в HTML тесно связан с файлом CSS независимо от того, что вы делаете.
Я думаю, что таблицы против divs сводится к потребностям вашего приложения.
В приложении, которое мы разрабатываем на работе, нам нужен был макет страницы, где части динамически изменяли бы размер своего контента. Я потратил несколько дней, пытаясь заставить его работать в разных браузерах с CSS и DIV, и это был полный кошмар. Мы перешли на столы, и все это просто сработало.
Тем не менее, у нас очень закрытая аудитория для нашего продукта (мы продаем аппаратное обеспечение с веб-интерфейсом), и проблемы доступности не являются для нас проблемой. Я не знаю, почему программы чтения с экрана не могут хорошо работать с таблицами, но я думаю, если это так, то разработчики должны справиться с этим.
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. Он предлагает удивительные варианты стилей и некоторые классные инструменты позиционирования, но в качестве механизма компоновки его недостаточно. Там должен быть какой-то тип системы динамического позиционирования сетки. Простой способ выровнять прямоугольники на нескольких осях, не зная сначала их размеров. Мне наплевать, если вы называете это