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

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

Почему?

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

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

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

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

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

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

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

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

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

30 ответов


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

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

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

ну и что? Мой босс уход? Мои пользователи заботятся?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


вот мой программист С simliar thread

семантика 101

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

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

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

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

семантика 102

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

вывод

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


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

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

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

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

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


посмотреть этот повторяющийся вопрос.

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

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

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


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

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

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


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


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

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

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

  • 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


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

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

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

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

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

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


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

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

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

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

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

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


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

Если это не заставляет вас говорить "WTF", тогда вам действительно нужно положить Kool-aid сейчас.

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

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

вздох. Достаточно вентиляции. Давай, засунь голову обратно в песок.


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

Если вы назначаете имена каждому из divs,вы можете снять кожу с них всех вместе, используя 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>

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

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


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

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


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

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

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

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


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

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

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

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


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

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

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


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

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


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

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

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

"моему боссу не все равно"

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


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

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


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


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

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


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

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

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

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


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

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

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

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


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


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

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

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


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

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

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

Если вы действительно хотите разделить продуктивно используйте Subversion и просмотрите журналы изменений. Затем используйте простейшие методы кодирования-divs, tables, JavaScript, includes, functions, objects, continuations, whatever-чтобы структурировать приложение так, чтобы изменения вписывались в простой и удобный способ.


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

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

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


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

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

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

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

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


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

.1. CSS & SEO:

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

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

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

.2. контент:

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

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

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

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

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

конечно, если на результаты нужно действовать через JavaScript, divs стоит того.

.3. быстрое тестирование преобразования

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

.4. различные решения для различных проблем

таблицы макетов обычно диссипируются, потому что" все знают, что divs & CSS " - это путь.

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

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

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

Я, например, устал от реакции коленного рывка " о нет! Таблицы для макет!"