Почему бы не использовать таблицы для разметки в 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 Энди Бадда. Это невероятно.

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

или или как угодно, но это базовая функция макета, которая отсутствует в 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, чтобы изменить порядок элементов, и это сделано. Исходя из моего опыта, перепроектирование макета с использованием таблиц - это кошмар (больше, если есть вложенные таблицы).

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

Источник

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

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

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

Источник

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

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

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

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

Источник

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

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

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

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

Источник

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

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

Источник

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

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

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

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

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

Источник

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

Источник

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

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

Источник

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

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

Источник

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

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

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

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

Источник

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

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

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

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

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

Источник

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

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

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

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

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

Источник

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

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

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

Источник

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

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

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

Источник

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

Источник

Манипуляция DOM сложна в табличном макете.

С семантическими элементами:

$('#myawesomediv').click(function(){
    // Do awesome stuff
});

С таблицами:

$('table tr td table tr td table tr td.......').click(function(){
    // Cry self to sleep at night
});

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

Источник
Другие вопросы по тегам