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

665

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

Почему?

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

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

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

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

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

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

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

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

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

Benno Richters
источник
Согласен, с таблицами все в порядке при представлении табличных данных. Их следует избегать при использовании его исключительно для макета. С другой стороны, иногда вам нужно идти по легкой дороге сейчас, а потом улучшать ее. Просто посмотрите на источник, и вы поймете, что я имею в виду.
взломан
Есть дубликаты вопросов и ответов на stackoverflow.com/questions/30251/tables-instead-of-divs
Онорио Катеначчи
11
Ответ прост: это зависит. Если таблицы используются для решения конкретной проблемы, которую не могут сделать текущие версии CSS, они хорошо используются. Если вы начинаете получать таблицы внутри таблиц, внутри миллионов таблиц, то вы делаете это неправильно. Если это временная таблица просто для размещения двух колонок или чего-то в этом роде, я не запрещаю это своей команде: это быстрее и проще сделать. (Я сам всегда стараюсь использовать CSS, но в конце концов доставка важнее правильного семантического HTML)
AlfaTeK
1
@Camilo SO все еще живет в 20-м веке. Джефф, видимо, не знает, как использовать ulтег. Просмотрите все списки на этом сайте (значки, связанные вопросы, последние теги). Все они либо одиночные столбцы, либо длинные абзацы, разделенные br.
И Цзян
2
@Brad: В зависимости от некоторых конкретных деталей (это мое мнение о любых умных ответах ;-), что использование DIVs ВСЕ ЕЩЕ лучше, чем злоупотребление таблицами. Две части документа, расположенные рядом друг с другом, могут на законных основаниях содержаться в элементах DIV, но они, безусловно, НЕ являются табличными данными. Неважно, какой будет конкретный стиль; контент либо табличный, либо нет. Примечание: я тоже не пропагандирую DIVitis :)
Бобби Джек,

Ответы:

496

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

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

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

Конрад Рудольф
источник
139
«изменение корпоративного макета на самом деле будет означать изменение каждой отдельной страницы» - действительно ли люди все еще дублируют корпоративный макет на каждой странице? Это так легко разрешить с помощью мастер-страниц или пользовательских элементов управления в .net, включая файлы в php или классическом asp и т. Д. ... Любой, кто копирует макет компании, подобный этому, заслуживает ** удара! ;-)
Джон Макинтайр
43
Извините, но это на самом деле "пирог в небе", желаемое за действительное. Пользователи заботятся? Нет. Никого это не волнует, кроме небольшого количества заблудших ревизионистов. HTML (включая таблицы) намного старше, чем относительно новое понятие «семантика против макета». Да, и источник, пожалуйста, для "большинства профессиональных веб-разработчиков против вас".
Клет
20
Опечатка выше: семантика подразумевалась с самого начала. <table> в HTML всегда предназначался только для табличных данных, а не для разметки (в ранние годы вы все равно не могли изменить внешний вид таблицы, что препятствовало ее использованию в качестве привязки макета). На самом деле, в ранних версиях HTML вообще не было понятия макета, и HTML никогда не предназначался для макета, но для структурирования текста. Более того: самое первое предложение HTML неоднократно предостерегает от злоупотребления тегами, влияющими на макет, и предостерегает от использования логической над физической разметки.
Конрад Рудольф
109
Получите программу чтения с экрана и попросите ее прочитать страницу с макетом таблицы. это все.
Corymathews
8
@ Серджио: пожалуйста, не редактируйте соответствующую информацию. Это является Ссылками сомнительное утверждение , я использую, и я хочу сделать это совершенно ясно. Ваша редакция положила мне в рот претензию, которую я не могу поддержать, фактически сделав меня лжецом, если это окажется ложным.
Конрад Рудольф
290

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

Семантика 101

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

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

Проблема, конечно, в том, что велосипед - это не машина. Класс автомобиля - неподходящий класс для экземпляра велосипеда. Код не содержит ошибок, но семантически неверен. Это плохо отражается на программисте.

Семантика 102

Теперь примените это к разметке документа. Если ваш документ должен представлять табличные данные, то соответствующий тег будет <table>. Однако, если вы поместите навигацию в таблицу, вы неправильно используете назначение <table>элемента. Во втором случае вы не представляете табличные данные - вы (не) используете <table>элемент для достижения цели презентации.

Вывод

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

Carl Camera
источник
39
Извините, это не удерживает воду. Вы не используете автомобиль для mybike, потому что вместо этого вы определяете класс "велосипед". Вы не можете определить что-то еще для «<table>», потому что это больше, чем простой семантический тег - он говорит браузеру, как отображать его содержимое.
Джимми
57
Хорошая аналогия и отличный вывод. Почему босс и / или пользователи должны принуждать кого-либо делать правильные вещи? Неужели никто больше не гордится своей работой?
Шерм Пендли
39
Я думаю, что это довольно высокомерный пост, который ничего не объясняет, а просто повторяет те же утверждения снова, не отвечая на вопрос. Я не понимаю, почему он получил так много голосов ????
Маркус
10
Я согласен с Таркумом. Этот ответ довольно субъективен и фактически не отвечает на поставленный вопрос. Хотя я согласен с тем, что для макета страницы следует использовать DIV, я не могу представить, чтобы какой-либо веб-дизайнер был бы озадачен макетом на основе таблицы.
Ричард Эв
16
@tharkun & Richard: Почему «семантически неверный» субъективен и ничего не объясняет?
Винко Врсалович
104

Очевидный ответ: см. CSS Zen Garden . Если вы скажете мне, что вы можете легко сделать то же самое с макетом на основе таблиц (помните - HTML не меняется), тогда непременно используйте таблицы для макета.

Две другие важные вещи - это доступность и SEO.

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

Так что ваши ответы - ремонтопригодность, доступность и SEO.

Не ленись. Делайте вещи правильно и правильно, даже если их немного сложнее освоить.

erlando
источник
24
Часто используемый трюк в Zen Garden заменяет текст на изображения и определяет его в CSS, делая его невидимым из HTML. Очень, очень неправильно.
GvS
3
Извините, но это не правильно. Текст все еще находится в HTML - это одно из требований CSSZG-дизайна. HTML должен остаться без изменений.
Эрландо
10
Если вы внимательно посмотрите на некоторые проекты, текст в некоторых заголовках отличается от текста в HTML. Это потому, что HTML-код сделан невидимым, а вместо него вставлено изображение. (Пример: csszengarden.com/?cssfile=/212/212.css&page=0 , «Путь» к «Достижению»)
GvS
6
К сожалению, нет абсолютно никаких доказательств того, что макеты div лучше для SEO. Кроме того, сами Google заявили, что проверка HTML для них не имеет значения - немного другая проблема, но она нацелена на таблицы, потому что они редко проверяют.
Рассерженная шлюха
«Большинство из вас знакомы с достоинствами программиста. Их, конечно, три: лень, нетерпение и гордыня ». - Ларри Уолл
Инкредибл
91

Смотрите этот дубликат вопроса.

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

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

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

оборота Джоэл Коухорн
источник
Да, в самом деле. Я вижу это дубликат Я пропустил его. Любые действия, кроме обещания, я буду более осторожным в следующий раз :-)?
Бенно Рихтерс
Не беспокойся Это будет все более и более распространенным, поскольку число вопросов увеличивается. Я даже не понизил голос. Мы просто хотим быть уверены, что все они в конечном итоге указывают на общий источник.
Джоэл Коухорн
8
Мне очень нравится этот ответ. Использование семантически значимых тегов - это не просто традиция, это позволяет темным не браузерам (программы чтения с экрана, скребки экрана, различные парсеры) правильно классифицировать различные объекты на вашей странице.
Призрак Ватсон
6
Я надеялся, что кто-то скажет об этом. Доступность должна быть главным приоритетом!
Андрей
Я не могу сказать, что согласен с тем, что доступность должна быть главным приоритетом в коммерческой деятельности. Соотношение затрат и выгод не представляется возможным. Это все равно что поставить пандус для инвалидной коляски в альпинистском магазине - нелепая трата ресурсов, которые можно было бы применить к предметам с лучшим CBR. Если вы говорите о медицинском учреждении, то пандус для инвалидной коляски будет приоритетом. Кроме того, я бы беспокоился только о доступности веб-страниц для сайтов, созданных для людей с нарушениями зрения.
Питер Воне
54

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

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

Это говорит лишь о том, что даже те, кто защищает строгую религию DIV & CSS, не могут следовать своим собственным правилам. Вы можете использовать это в качестве ориентира в том, насколько внимательно вы следуете им.

Джеймс Керран
источник
18
Вы имеете в виду , что они делают , <h1>Some Text</h1>а затем в их CSS: h1 { background-image('foo.jpg'); text-indent:-3000px }? Это правильный способ сделать это, потому что вы сохраняете максимальную семантическую информацию в html без стилей. Или, может быть, я вас неправильно понял.
Каран
9
Карен права, ты не прав, Джеймс. Ваш пример - соломенный человек. Забывать менять изображение при смене семантического HTML было бы глупо. Так что оставил свой ноутбук в автобусе. В чем ваша точка зрения?
AmbroseChapel
36
@Ambrose: Потому что весь смысл чертового сайта в том, чтобы продемонстрировать разделение контента и стиля. Контент и стиль должны правильно обрабатываться разными людьми, ни один из которых не должен «помнить», что другой изменил.
Джеймс Керран
5
Г-н S & N: это еще больше ухудшит положение. Вы должны были бы динамически генерировать новые изображения - в правильном стиле. Итак, теперь вы перешли от стиля до кода бизнес-уровня.
Джеймс Керран
9
@James: Контент и стиль не всегда могут быть обработаны разными людьми. Когда контент стилизован, сотрудничество должно происходить. Как это может <h1><img src="something.png"></h1>быть лучше, чем <h1 class="something image">Something</h1>? В любом примере что-то необходимо обновить. Но второй пример гораздо более доступен.
Джош
48

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

целесообразный
источник
Хороший момент, хотя вы можете использовать css для скрытия ячеек в макете на основе таблицы, например, для подавления навигации в печатной версии, макет CSS дает вам гораздо больше гибкости, чем простое скрытие данных.
Кори Дом
Я ударил это одним из моих приложений; Я был счастлив, когда понял, как легко создать «дружественную к принтеру» версию с несколькими печатными CSS-кодами для тех же страниц, что были на экране.
Лоуренс Дол
45

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

Ben Scheirman
источник
1
Я очень рекомендую эту книгу
Джейкоб Т. Нильсен
Содержит хорошие примеры для блочной модели, селекторов и позиционирования.
KMån
36

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

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

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

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

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

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

17 из 26
источник
6
screenreaders работает с таблицами нормально. Проблема в том, что таблицы не имеют дело с screenreaders. Табличное расположение склонно представлять информацию в недоступной манере. Подумайте, как будет выглядеть правая навигация. Это было бы довольно далеко вниз по странице.
Эрландо
Хорошо, тогда это имеет смысл - спасибо!
17 из 26
8
То, что <table> или <div> имеют представление по умолчанию в большинстве экранных агентов, не означает, что они являются элементами представления вместо семантических элементов.
Марк Брэкетт
1
Я не говорю конкретно о HTML, я говорю концептуально в базовом дизайне пользовательского интерфейса. Таблица диктует, как вещи отображаются на экране, то есть, как они представлены пользователю. Это презентация.
17 из 26
1
«Я потратил несколько дней, пытаясь заставить это работать» - если что-то, что я пытаюсь выяснить, занимает больше пары часов, я передаю это сообществу StackOverflow. Не знание, как сделать что-то правильно, не является оправданием для того, чтобы делать это неправильно. Особенно, когда у нас есть все ответы в наших руках.
DaveDev
23

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

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

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

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

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

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

Питер Мортенсен
источник
Я не мог согласиться с этим постом. За те 10 лет, что я занимался дизайном, я не могу вспомнить ни единого момента, когда аргумент «мы используем CSS, потому что он облегчает управление изменениями во всем мире», воспроизводился как точный.
Даниэль Сзабо
6
знаете, что позволяет легко управлять изменениями в сети? MVC и шаблонные системы
Jiaaro
Пожалуйста, не поймите меня неправильно - я все еще использую CSS, но я использую его для применения стиля (цвет, фоновые изображения и т. Д.), А не макета. CSS, кажется, в значительной степени согласован во всех браузерах, когда используется только для управления стилем. Где он имеет недостатки и в значительной степени падает, так это способ, которым макет определяется и реализуется в браузерах. Кто-нибудь когда-нибудь пытался заставить ASP.NET MasterPages надежно работать с DIV? Это почти невозможно!
Тим Блэк
21

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

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

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

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

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

Needlestack
источник
«Фанаты CSS» (как вы выразились) не игнорируют этот факт. Следующая CSS-спецификация имеет не одно, а два решения для решения проблем с макетами в CSS. Макеты шаблонов: w3.org/TR/css3-layout And Grid Positioning: w3.org/TR/css3-grid Это не вводит конкурирующие спецификации. 2 спецификации фактически дополняют друг друга. На момент написания этого комментария, пока ни один браузер не реализует его.
Дэн Герберт
+1: полностью согласен Вам не нужно «заставить его работать» (хотя я тоже не люблю таблицы).
3lectrologos
Это на 100% именно то, что я чувствую. Хотел бы я поднять вас до верного ответа.
bobwienholt
19

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

Если вы присваиваете имена каждому из элементов div, вы можете объединить их все вместе с помощью CSS. Им просто немного сложнее сидеть так, как тебе нужно.

обкрадывать
источник
18

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

Ross
источник
3
Скорость не единственная вещь, которая страдает от больших файлов: многие компании платят за пропускную способность. Если вы сможете вдвое сократить счета за пропускную способность вашего клиента, просто хорошо написав код, это большое преимущество.
Мистер Блестящий и Новый
2
Да, но не забывайте, что хотя HTML-код может быть в два раза больше в макете без CSS, использование макета DIV + CSS приведет (по крайней мере) к дополнительному HTTP-запросу для файла CSS, плюс использование полосы пропускания для сам файл.
goldenratio
12
Но файл CSS нужно загрузить только один раз, так как вся структура таблицы пересылается при каждом запросе страницы.
user151841
3
Вы выбрали дизайн, подходящий для div + css, и показали, что он более многословен в табличном дизайне? Ну и что: было бы так же легко создать дизайн, который хорошо подходил бы для табличного макета и показать обручи, через которые нужно было бы перейти, чтобы воспроизвести его в CSS.
Draemon
4
@Draemon: Может быть, вы хотели бы привести пример?
Бобби Джек,
14

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

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

Guido
источник
Моя мечта - иметь графического дизайнера, который берет предоставленные мной объекты / данные и помещает их на страницу, не заботясь о CSS, DIV, TABLE ... :)
Manrico Corazzi
Во-вторых, Manrico - визуальный дизайнер, который позволил бы вам создавать макет и определять фиксированные и процентные измерения, а затем генерировать минимальный HTML и CSS, был бы чрезвычайно полезен!
Ричард Эв
Проблема, с которой я столкнулся в концепции семантической паутины, заключается в том, что в HTML 4 словарный запас очень ограничен и предназначен в первую очередь для технических документов. Многие сайты с коммерческими / маркетинговыми целями могут содержать элементы, которые не вписываются в этот словарь. HTML 5 исправляет некоторые из них с помощью таких тегов, как nav, header, footer, но сейчас мы застряли с использованием таких тегов, как span, которые на самом деле очень мало говорят о том, как должен интерпретироваться контент.
Ник Ван Брант
13

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

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

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

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

Radu094
источник
1
Если вы хотите создать веб-сайт с двумя или тремя столбцами с помощью divs + css, который работает во всех браузерах, вам не следует начинать с нуля. В Интернете доступно множество шаблонов, которые вы можете использовать в качестве основы. Они обычно оптимизированы для корректного отображения во всех браузерах ie6 +
arturh
13

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

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

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

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

МБ.
источник
13

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

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

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

DLH
источник
12

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

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

ceejayoz
источник
Да, например, для блогов движок отделяет комментарии от поста блога. Представьте себе, что макет был разработан с таблицами ..
Омар Абид
2
-1: Google абсолютно безразлично, используете ли вы таблицы для разметки.
Том Андерсон
@Tom Anderson Не потому, что у них есть проблемы с использованием таблиц для разметки, а просто потому, что не-табличный HTML имеет тенденцию быть более семантическим.
ceejayoz
8

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

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

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

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

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

Кент Фредрик
источник
При работе с веб-сайтом, содержащим огромный набор тегов span и div, и засвидетельствование его хрупкости при изменении одного элемента, это приведет к поломке всей страницы (и использование тегов
div
Использование Div не делает ваш код волшебным. Многое следует сказать о соответствующем семантическом использовании тегов.
Кент Фредрик
7

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

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

Натан Лонг
источник
7

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

Томас Вагнер
источник
5

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

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

Свати
источник
Хорошая мысль у вас там; но ИМХО интерфейс для мобильных устройств должен быть совершенно другим с учетом ограничений ввода.
Манрико Корацци
Правда; Вот почему я начал иногда использовать другой подход. В модели MVC мой взгляд всплывет только в виде необработанных данных XML, то есть содержимого. Затем начните с другой модели MVC, где xml raw data = model; view = html / css; контроллер = xsl. Таблица стилей XSL удаляет ненужные данные для мобильных устройств.
Свати
5

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

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

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

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

Римантас
источник
5
  • 508 Compliance - способность программы чтения с экрана понять смысл вашей разметки.
  • Ожидание рендеринга - таблицы не отображаются в браузере до тех пор, пока он не достигнет конца </table>элемента.
Рик Глос
источник
Я помню, как создавал огромные таблицы много лет назад, во времена медленных компьютеров, и я помню, когда появился код, который заставлял их рендериться по мере продвижения. IE6? IE4? Не могу вспомнить, но это, безусловно, изменилось. Конечно, это полезно для табличных данных, но таблицы макетов создаются с точностью до дюйма от их жизни, поэтому, возможно, прогрессивный рендеринг будет менее полезен, поскольку таблица перемещается, чтобы вместить вновь загруженный контент.
ijw
5

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

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

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

Стив Перкс
источник
4

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

domgblackwell
источник
3

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

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

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

Майк Корнелл
источник
3

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

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

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

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

Патрик Мэй
источник
+1 за первые два предложения.
Шон Макмиллан
3

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

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

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

Чак Ле Батт
источник
3

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

JacquesB
источник
3

Я был удивлен, увидев, что некоторые проблемы еще не были рассмотрены, так что вот мои 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, которые вы должны использовать, чтобы заставить эту чертову штуку работать в большинстве браузеров? Были ли они предназначены для этой цели?

Sylverdrag
источник