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

Ответ 1

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

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

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

И что? Помогает ли мой босс? Удовлетворяют ли мои пользователи?

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

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

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

Кстати... почему использует div или span хорошее разделение контента из макета и таблицы нет? Получение хорошего макета с помощью только divs часто требует большого количества вложенных div.

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

Считываемость кода Я думаю, что все наоборот. Большинство людей понимает html, мало понимает css. Это проще.

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

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

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

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

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

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

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

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

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

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

Ответ 2

Здесь мой программист отвечает из simliar thread

Семантика 101

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

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

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

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

Семантика 102

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

Заключение

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

Ответ 3

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

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

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

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

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

Ответ 4

См. этот дублированный вопрос.

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

• Трудно читать. Это не до мнения. В них больше вложенных тегов без идентификационных меток.

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

• CSS для стилей позволяет вашему браузеру кэшировать файлы, а последующие запросы выполняются намного быстрее. Это ОГРОМНОЕ.

• Таблицы блокируют вас в дизайне. Конечно, не всем нужна гибкость CSS Zen Garden, но я никогда не работал на сайте, где мне не нужно было немного менять дизайн здесь и там. Это намного проще с CSS.

• Таблицы сложны для стиля. У вас нет большой гибкости с ними (т.е. Вам все равно нужно добавлять атрибуты HTML для полного управления стилями таблиц)

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

Я бы очень хотел предложить прочитать Мастерство CSS Энди Бадда. Это фантастика.

Изображение на 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

Ответ 8

Хорошо отделять контент от макета
Но это ошибочный аргумент; Cliche Thinking

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

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

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

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

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

Ответ 9

Интересно, кто сделал "источник просмотра" на страницах stackoverflow ~~

Ответ 10

Смешная:

http://giveupandusetables.com/

Ответ 11

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

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

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

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

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

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

Ответ 12

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

Если это не означает, что вы говорите "WTF", тогда вам действительно нужно сбросить kool-помощь.

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

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

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

Ответ 13

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

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

Ответ 14

Мне нравится этот вопрос, потому что он раскрывает то, что верно в любых дебатах.

Абсолютные утверждения: always обычно неверно.

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

Истина

• В большинстве случаев используйте CSS для компоновки.
• В редких случаях используйте таблицы для компоновки.
• Изучите HTML/CSS, получите опыт, затем вы сможете распознать правильные и неправильные случаи.

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

Ответ 15

Вот раздел 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>

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

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

Ответ 16

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

Использование простой таблицы с тремя рядами/3-столбцами (с объединением для верхнего и нижнего колонтитула) для основного макета намного проще. Div - вовсе не святой Грааль. Google для веб-сайтов, пытающихся придумать приличный и легкий CSS с div для вышеупомянутого макета....

Ответ 17

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

Ваш код также имеет значение из semantic.

Ответ 18

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

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

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

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

Ответ 19

Никакие аргументы в DIVs не поддерживают меня.

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

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

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

Ответ 20

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

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

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

Ответ 21

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

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

Ответ 22

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

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

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

"Помогает ли мой босс"

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

Ответ 23

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

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

Ответ 24

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

Ответ 25

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

Ответ 26

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

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

Ответ 27

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

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

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

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

Ответ 28

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

Ответ 29

Вся идея вокруг семантической разметки - это разделение разметки и презентации, которая включает в себя макет.

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

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

Ответ 30

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