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

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

Семантика 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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

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

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

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

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

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

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

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

Смешная:

http://giveupandusetables.com/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Истина

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

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

В соответствии с соглашением 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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0,1. CSS и SEO:

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

b) Когда макет переносится на 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 в полете, а добавление стиля inline ничем не отличается от использования таблицы (содержимое не отделено от макета).

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

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

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

0,3. Быстрое тестирование конверсий

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

0,4. Различные решения для различных задач

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

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

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

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

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

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

Манипуляция DOM затруднена в табличном макете.

С семантическими divs:

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

С таблицами:

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

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

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

Любой, кто рассматривает возможность компоновки со столом, лучше не ожидать, чтобы я его поддерживал. Это самый задне-обратный способ рендеринга веб-сайта. Слава богу, теперь у нас есть намного лучшая альтернатива. Я НИКОГДА не вернусь.

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

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

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

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

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

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

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

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

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

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

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

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

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

CSS-макет сейчас только в моде. Это что-то вроде: Linux лучше, чем Windows, или Oracle лучше, чем SQL Server. Зачем? Потому что они сложнее в использовании. Такая же ситуация с CSS: CSS layout rulez, макет таблицы должен умереть. Поскольку компоновка CSS сложнее.

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

В этом макете комментариев используется таблица:) Это очень удобно, когда вы пытаетесь отобразить данные столбца, но на самом деле не рекомендуется использовать его для общего макета сайта.

Я думаю, что colspan плохо подходит для того, чтобы я захотел вообще отказаться от таблиц для макета.

Попробуйте сделать отзывчивый дизайн со столом, вы получите ответ.;)

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

Это неправильно и совершенно очевидно неправильно.

Работают вертушки для ремня. Вы бы купили его?

Проблема строгое разделение представления и содержимого поражает меня примерно так же, как разделение файлов заголовков из файлов реализации на С++. Это имеет смысл, но это также может быть болью. Witness Java и С#, где классы определены в одном исходном файле. Авторы новых языков заметили то, что вызывало головные боли программистов, и они избавились от него. Кажется, это суть этой дискуссии. Одна сторона говорит, что CSS слишком сложно, другая сторона говорит, что нужно стать мастером CSS.

Для простых вопросов макета, почему бы не сгибать правило, согласно которому презентация должна быть полностью разделена? Как насчет нового тега (или некоторого расширения для тега div), который позволяет нам напрямую управлять презентацией в HTML? В конце концов, разве мы уже не пропускаем презентацию в HTML? Посмотрите на h1, h2... h6. Мы все знаем об этом контрольном представлении.

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

• Попробуйте объединить/разделить 10/20 что-то глубокое colspan/rowspan. Не раз мне приходилось подавлять свой инстинкт, чтобы начать драку с кем-то. [?]
• Попробуйте изменить порядок исходного кода без изменения видимого порядка. [SEO, юзабилити,...]
• Самая (действительно простая) страница, на которую мы смотрим, составляет ~ 150K. Бьюсь об заклад, его можно почти сократить вдвое, используя правильный CSS. [SEO (Да, SEO, читайте последние спецификации Google и т.д.), Perfo,...]
• Попробуйте создать шаблон итератора, который может работать любой шириной.
• Обсуждение вопроса в этой табличной среде SO может вызвать сингулярность и уничтожить всех нас

Мне приходилось делать сайты в обоих этих направлениях, плюс третий, страшный "гибридный" макет с таблицами, div и стилями: Divs/CSS выигрывает, удобно.

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

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

У меня есть полный контроль над каждым аспектом презентации с помощью divs/css. Таблицы беспорядочны, особенно в IE, браузере, который я еще не имел возможности не поддерживать.

Мое время для обслуживания или редизайна сайта divs/css является частью того, что было бы в таблицах.

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

Удачи вам в вашей рентабельности, когда вы принимаете это решение.

Один пример: вы хотите центрировать главной области содержимого страницы, но в чтобы содержать поплавки внутри него, он должен быть размещен. Здесь нет "float: center" в CSS.

Это не единственный способ "содержать поплавки" внутри центрированного элемента. Итак, это не хороший аргумент!

В некотором смысле это ложная предпосылка, вещь "divs vs tables".

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

Реальный аргумент - это "позиционирование, выполняемое CSS (надеюсь, в удаленном файле)", а не "позиционирование, сделанное HTML на странице". Неужели каждый может видеть преимущества первого, а не последнего?

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

Рассмотрим это:

[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]

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

picture picture picture caption caption caption

и связь, очевидная с таблицей на месте, исчезает.

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

Огромная проблема для меня заключается в том, что таблицы, особенно вложенные таблицы, занимают намного больше времени, чем правильная реализация css. (Вы можете сделать css так же медленно).

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

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

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

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

И я считаю, что проще поддерживать нестандартную раскладку. Вам не нужно беспокоиться о rowspans, colspans и т.д. Вы просто создаете некоторые контейнеры-div и размещаете контент, в котором вам нужно. И я сказал, что это также более читаемо (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).

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

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

Вот проверка реальности: Все старое новое снова.

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

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

Два с головы.

Таблицы предназначены для табличных данных, а не для дизайна.

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

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

Многие из них придумали решения, облегчающие создание макета для div. Наиболее популярной из них является grid-архитектура. На этой архитектуре созданы динамические макеты. Проверять, выписываться: 1) 960.gs и (http://grids.heroku.com/) 2) план и так много в последнее время.

Я не видел много инноваций в плане архитектуры и инструментов с макетом таблиц.

Я бы сказал, что все теории в сторону, практически макет с CSS и divs быстрее. Скорее инновации в этом направлении облегчили что-либо.

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

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

2 - Алгоритм рендеринга таблицы дорогой и не в один проход. Браузер, когда и когда получает содержимое, попытается выполнить вычисление ширины и высоты содержимого. Итак, если у вас есть вложенные таблицы, скажем, браузер получил первую строку, а первая ячейка имеет большой объем содержимого, а ширина и высота не определены, он будет вычислять ширину и отображать первую строку, В среднем, пока он получает вторую строку, ячейка №2 будет иметь массу контента! Теперь он рассчитает ширину для ячеек 2-й строки. Как насчет первого? Он будет вычислять ширины рекурсивно. Это плохо на стороне клиента. (На сайт пример). Как программист, вы будете оптимизировать такие вещи, как время для получения данных, оптимизированные структуры данных и т.д. Вы оптимизируете все, что нужно сделать на стороне сервера, скажем, через 2 сек, но конечный пользователь получает окончательный вид в 8 сек. Что здесь не так?   1. Может быть, сеть медленная! Что делать, если сеть в порядке? Что сеть передает содержимое в течение следующих 1 сек? Где этот дополнительный 5 секунд потребляется? О чем беспокоиться - браузеру потребуется много времени на оценку и визуализацию таблиц!

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

Но, в конце, div - отличный способ, поскольку браузер может быть кэширован браузером; а таблица не кэшируется!

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

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

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

Если бы был ответ на этот вопрос, я был бы в восторге от - правильной вещи -. Просто скажите мне что-нибудь вроде: "Эй, ты пробовал ** поток: вертикальный горизонтальный" и я "Полностью из твоих волос.

Я до сих пор не совсем понимаю, как divs/CSS упрощают изменение дизайна страницы, когда вы рассматриваете объем тестирования, чтобы обеспечить работу изменений во всех браузерах, особенно со всеми хаками и т.д. Его чрезвычайно расстраивающий и утомительный процесс, который тратит много времени и денег. К счастью, законодательство 508 распространяется только на США (земля бесплатно - да, право), и поэтому, будучи в Великобритании, я могу создавать веб-сайты в любом стиле, который я выбираю. В отличие от популярной (США) убеждения, законодательство, принятое в Вашингтоне, не распространяется на остальной мир - благодарите за это. Должно быть, это был хороший день в мире веб-дизайна в день вступления в силу законодательства. Я думаю, что становлюсь все более циничным, когда я старею старше 25 лет в ИТ-индустрии, но я уверен, что такое законодательство просто защищает рабочие места. На самом деле каждый может сбить разумную веб-страницу с помощью нескольких таблиц. Для этого требуется DIV/CSS. По моему опыту, для поиска решений простых проблем и чтения непонятных статей на форумах, полных идеалистических фанатиков, может потребоваться много часов и часов, которые все спорят о "правильном" способе делать что-то. Вы не можете просто окунуться в воду и заставить все нормально работать в каждом случае. Мне также кажется, что отсутствие окончательного руководства по использованию DIVS/CSS "из коробки", которое применимо ко всем ситуациям, работающим над браузерами, и написанное с использованием "нормального" языка без каких-либо выкидышей, также пахнет бит протекционизма.
Я разработчик приложений, и я бы сказал, что для решения проблем с макетами и тестирования для всех браузеров требуется почти в два раза больше, чем для создания базового приложения, проектирования и реализации бизнес-объектов и создания базы данных. Мое время = деньги, как для меня, так и для моих клиентов, поэтому я сожалею, что не отклоняю все аргументы pro DIV/CSS в пользу сокращения расходов и обеспечения ценности для моих клиентов. Возможно, это так, как работают разработчики, но мне гораздо легче изменить сложную структуру таблиц, чем изменять DIVs/CSS. К счастью, теперь появилось, что решение этих проблем теперь доступно - его называют WPF.

Google дает очень низкий приоритет текстовому контенту, содержащемуся внутри таблицы. Я давал некоторые советы SEO местной благотворительной организации. Изучая их сайт, он использовал таблицы для компоновки сайта. Если посмотреть на каждую страницу, независимо от того, какие слова - или комбинация слов - со страниц, которые я использовал в окне поиска Google, страницы не будут отображаться ни на одной из верхних страниц поиска. (Однако, указав сайт в поиске, страница была возвращена.) Одна страница была хорошо скопирована по нормальным стандартам для получения хорошего результата при поиске, но все же она не появлялась ни на одной из первых страниц результатов поиска. (Обратите внимание, что этот текст был в таблице.) Затем я заметил раздел текста на страницах, который был в div, а не в таблице. Мы помещаем несколько слов из этого div в поисковой системе. Результат? Он пришел в №2 в результатах поиска.

Несколько лет назад я исследовал проблему чтения и чтения экранов и придумал информацию, которая противоречит тому, что считают большинство разработчиков:

http://www.webaim.org/techniques/tables/

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

Прошу прощения за мой английский, но вот еще одна причина:

Я работал в какой-то правительственной организации, и причина номер один, чтобы не использовать ТАБЛИЦУ, предназначена для людей с ограниченными возможностями. Они используют машины для "перевода" веб-страниц.

Проблема заключается в том, что эта "машина перевода" не может читать веб-сайт, если это делается TABLE. Зачем? Потому что TABLE для DATAS.

на самом деле, если вы используете ТАБЛИЦЫ, для каждой КЛЕТКИ вы должны указать некоторую информацию, чтобы дать возможность инвалидам узнать, где они находятся в ТАБЛИЦЕ. Представьте, что у вас большой стол и нужно увеличить, чтобы увидеть только 1 ячейку на экране: вы должны знать, в какой строке вы находитесь.

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

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

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

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

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

3: Таблицы медленнее: да, они есть. Причина проста: таблицы должны быть проанализированы полностью, включая их содержимое, прежде чем они могут быть отображены. Когда он встречается, div может быть отображен, даже до того, как его содержимое будет проанализировано. Это означает, что divs будут отображаться до того, как страница закончит загрузку.

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

Конечно, № 1 - большая. Многие инструменты и приложения зависят от семантического значения веб-страницы. Обычный пример - экранные считыватели для слабовидящих пользователей. Если вы являетесь веб-разработчиком, вы обнаружите, что многие крупные компании, которые могут нанять вас для работы на сайте, требуют, чтобы сайт был доступен даже в этом случае. Это означает, что вы должны думать о семантическом значении своего html. С семантической сетью или, что более важно, микроформатами, rss-считывателями и другими инструментами, содержимое вашей страницы больше не просматривается исключительно через браузер.

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

То же самое верно, когда divs или другие элементы уровня блока используются для воссоздания таблиц и сильно вложены. Цель divs должна использоваться как элемент fomating и layout, и как таковая предназначена для хранения подобной информации и размещает ее на экране для зрителей. Когда скрининг сталкивается с страницей, он часто игнорирует любую информацию о макете, как на основе CSS, так и на основе html-атрибута (это неверно для всех читателей экрана, но для самых популярных, таких как JAWS, Windows Eyes и Orca для Linux это).

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

Наконец, с табличным макетом, чтобы добиться мелкомасштабного управления положением элементов на странице, часто используются сильно вложенные таблицы. Это имеет два эффекта: 1.) Увеличенный размер кода для каждой страницы. Поскольку для каждого запроса часто выполняется навигация и общая структура, один и тот же код отправляется по сети для каждого запроса, тогда как макет на основе div/css вытягивает файл css один раз, а затем использует менее многословные div. 2.) Очень вложенные таблицы занимают намного больше времени для визуализации браузера клиента, что приводит к немного более медленному времени загрузки.

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

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

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

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

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

Наконец, CSS позволяет одно преимущество MAJOR, которое таблицы никогда не предоставят: возможность переформатировать контент на основе устройства отображения. CSS позволяет мне использовать совершенно другой набор стилей (включая положение, форматирование и т.д.) Для принтера, чем тот, который я использую для монитора. Это может быть распространено и на другие носители, отличный пример - Opera Show, который позволяет рассматривать продуманную (и очень стандартную) CSS-страницу с расширенными возможностями как слайд-шоу.

Таким образом, в конечном итоге гибкость и управление являются настоящими победителями. Как правило, CSS позволяет вам делать больше с макетом. Там нет ничего технически нестандартного в отношении табличного макета, но почему вы хотите ограничить себя?

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

Я использую теги "table" и "div" / "span" в разметке HTML.

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

• для таблицы вам нужно написать не менее 3 тегов (table, tr, td, thead, tbody), для приятного дизайна, иногда у вас много вложенных таблиц

• Мне нравится иметь компоненты на странице. Я не знаю, как точно объяснить, но попробую. Предположим, вам нужен логотип, и это нужно разместить, всего лишь небольшую часть, над содержимым следующей страницы. Используя таблицы, вы должны вырезать 2 изображения и поместить их в 2 разных TD. Используя DIVs, вы можете иметь простой CSS, чтобы изменить его, как вы хотите. Какое решение вам больше всего нравится?

• когда более 3 вложенных таблиц для выполнения чего-то, что я собираюсь переделать, используя DIVs

НО я все еще использую таблицы для:

• табличные данные

• содержимое, расширяющее self

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

Из прошлого опыта я должен был пойти на DIV. Даже в ООП основная цель - уменьшить связь между объектами, поэтому эта концепция может быть применена к DIVS и таблицам. Таблицы используются для хранения данных, а не для их размещения вокруг страницы. DIV специально предназначен для размещения элементов вокруг страницы, поэтому дизайн должен использовать DIV, таблицы должны использоваться для хранения данных.

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

Я стараюсь избегать ТАБЛИЦЕЙ как можно больше, но когда мы разрабатываем сложные формы, которые смешивают несколько типов управления и разные позиции надписей с довольно строгим контролем над группировкой, использование DIV недостоверно или часто почти невозможно.

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

Поскольку представление форм является динамическим (где отображение некоторых разделов основано на состоянии случая или разрешениях пользователя), мы используем множество многоуровневых DIV, каждая из которых содержит ТАБЛИЦА логически сгруппированных элементов формы, Каждый столбец таблицы классифицируется таким образом, что их можно контролировать с помощью CSS. Таким образом, мы можем отключить разные разделы формы без проблемы не таблицы для обертывания строк в DIV.

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

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

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

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

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

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

Тем не менее... есть много данных, которые должны быть представлены в таблице даже на современном веб-сайте.

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

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

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

Затем попробуйте с хорошим семантически правильным сайтом div.

Вы увидите разницу.

Таблицы не являются злыми, если данные в них табличные, а не макет страницы.

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

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

См. также: использование ViewState

Я согласен на 100%. Я использую таблицы, и я слышал этот аргумент, чтобы не использовать таблицы в течение примерно 6 лет. За последние 6 лет лицо HTML изменилось очень мало, и угадайте, что, таблицы все еще вокруг.

По-моему, в таблицах не было ничего плохого, только немногие мальчики IT-славы начали читать статьи XHTML, они никогда не понимали, и только начали думать, что divs и spans каким-то образом были предназначены для замены таблиц.

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

Еще одна вещь, которую я не получаю, заключается в том, что некоторые люди считают, что XHTML чище, но потом я спрашиваю их, знают ли они XSL или XLST, и они говорят "нет" - это слишком сложно, но это одна из лучших вещей о XHTML.

Еще один момент, который стоит отметить, заключается в том, что XHTML никогда не был предназначен для замены HTML 4. HTML 5 заменяет 4, в то время как XHTML имеет свои собственные приложения и идеально подходит для использования в системах CMS.

Это вопрос POV, если я когда-либо видел его.

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

Как только Internet Explorer 8 свергнет Internet Explorer7 и Internet Explorer 6 (это может быть отключено), таблицы будут устаревшими для макета.

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

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

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

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

http://www.maxdesign.com.au/articles/liquid/

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

Лично мне очень сложно отслеживать таблицы на моих HTML-страницах. Если вы хотите действительно создать страницу, вам нужно начать с чертежной доски... буквально. Используя Photoshop или GIMP, начните структурировать страницу, добавить строки, установить расстояния между пикселями между абзацами, элементами списка и так далее. Затем вы можете сделать HMTL с DIV, и все будет под следующей задачей. Затем используйте CSS, чтобы правильно позиционировать, а затем, возможно, JavaScript, если вы хотите добавить динамический материал.

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

Данные: используйте таблицы. Макет: используйте стили. Таблицы могут отображаться быстрее с помощью очень скудного браузера, то есть Links 2 или Lynx без стилизации, просто разметка.

Что касается обслуживания сайта и капитального ремонта проекта при сохранении контента (который происходит все время, особенно в электронной коммерции):

Контент и дизайн размножаются вместе через таблицы = обновление как содержимого, так и дизайна.

Контент отдельно от дизайна = обновить дизайн и, возможно, немного контента.

Если бы у меня это было, я бы сохранил свой контент в PHP, генерируя XML, преобразованный в разметку в XSLT и разработанный с помощью CSS и Javascript для взаимодействия. Для Java-стороны вещей, JSP для JSTL для создания разметки.

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

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

WYSIWYG!!! Я не могу на всю жизнь заставлять наших дизайнеров прекратить использование вложенных DIVS и стилизовать с помощью elementID css в шаблонах, которые предполагается использовать клиентами в проектах CMS. Это весь смысл онлайн-редактора WYSIWYG. Вы одновременно контролируете содержимое и макет! В этом сценарии нет разделения вообще. Позиционированные и стилизованные Divs в некоторой внешней таблице стилей являются анафемами для всей идеи редактирования WYSIWYG. Таблицы видны, вставлены строки, объединены ячейки и так далее. Удачи, пробуйте это с помощью divs таким образом, чтобы это не мешало пользователям.

Используя DIV, вы можете легко переключать вещи. Например, вы можете сделать это:

Menu | Content

Content | Menu

Menu
----
Content

Легко изменить его в CSS, а не в HTML. Вы также можете предоставить несколько стилей (правая, левая, специальная для маленького экрана).

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

Другое дело, что ваш контент всегда в одном порядке в коде (меню сначала, содержимое после), даже если визуально оно представлено иначе.

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

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

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

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

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

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

Аргумент, что использование таблицы, чтобы убедиться, что несколько элементов выстроились правильно, приводит к тому, что это значительное увеличение кода обычно включает примеры того, как один DIV может удовлетворить все их потребности. Они не всегда включают 10 строк CSS и специальные браузерные хаки, которые им приходилось писать для IE5, IE5.5, IE6, IE7...

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

Содержание Div действительно улучшает понимание CSS, но оно намного чище и лаконично

Это не обязательно война. Гармония возможна.

Используйте одну таблицу для общей компоновки и разделов внутри нее.

<table> 
    <tr><td colspan="3"><div>Top content</div></td></tr>
    <tr> 
        <td><div>Left navigation</div></td> 
        <td><div>Main content</div></td> 
        <td><div>Right navigation</div></td> 
    </tr>
    <tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>

Посмотрите - нет вложенных таблиц.

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

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

Обратите внимание, что этот подход даст вам 100% соответствие CSS в текст ссылки

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