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

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

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

Если вы назначаете имена каждому из div, вы также можете скинуть их все вместе с помощью CSS. С ними немного сложнее сидеть так, как вам нужно.

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

I guess it's true that using the table element for layout has little to do with tabular data. So what? Does my boss care? Do my users care?

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

См. Этот повторяющийся вопрос.

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

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

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

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

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

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

"Не все ли равно моему боссу"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It's good to separate content from layout
But this is a fallacious argument; Cliche Thinking

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

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

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

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

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

Никаких аргументов в пользу DIVs с моей стороны.

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

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

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

Вот мой ответ программиста от подобная нить

Семантика 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 / CSS. Практически во всех их последних разработках для заголовков разделов используется графика. Эти графические файлы указаны в CSS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Это НАМНОГО труднее читать. Это не зависит от мнения. Просто больше вложенных тегов без каких-либо опознавательных знаков.

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

• 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

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

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

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

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

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

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

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

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

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

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

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

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

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

It's good to separate content from layout But this is a fallacious argument; Cliché Thinking.

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

So what? Does my boss care? Do my users care?

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

Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and css.

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

By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.

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

Readability of the code I think it's the other way around. Most people understand html, little understand css. It's simpler.

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

It's better for SEO not to use tables

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

Tables are slower. An extra tbody element has to be inserted. This is peanuts for modern web browsers.

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

Show me some benchmarks where the use of a table significantly slows down a page.

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

Most web sites that need an upgrade need new content (html) as well. Scenarios where a new version of a web site only needs a new css file are not very likely.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. табличные данные

2. контент, который расширяется самостоятельно

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

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

Menu | Content

Content | Menu

Menu
----
Content

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

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

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

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

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

Вот раздел html из недавнего проекта:

<?xml version = "1.0" encoding = "utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns = "http://www.w3.org/1999/xhtml" xml:lang = "en" lang = "en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv = "content-type" content = "text/html;charset=utf-8" />
    <meta http-equiv = "Content-Style-Type" content = "text/css" />
    <link rel = "stylesheet" type = "text/css" href = "./styles/base.css" />
</head>
<body>
    <div id = "header">
        <h1><!-- Page title --></h1>
        <ol id = "navigation">
            <!-- Navigation items -->
        </ol>
        <div class = "clearfix"></div>
    </div>
    <div id = "sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id = "footer"><!-- Footer content --></p>
</body>
</html>

А вот тот же код, что и макет на основе таблицы.

<?xml version = "1.0" encoding = "utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns = "http://www.w3.org/1999/xhtml" xml:lang = "en" lang = "en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv = "content-type" content = "text/html;charset=utf-8" />
    <meta http-equiv = "Content-Style-Type" content = "text/css" />
    <link rel = "stylesheet" type = "text/css" href = "./styles/base.css" />
</head>
<body>
    <table cellspacing = "0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan = "2">Footer</td>
        </tr>
    </table>
</body>
</html>

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

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

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

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

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

One example: you want to center the main content area of a page, but in order to contain the floats inside it, it needs to be floated. There is no "float: center" in CSS.

Это не единственный способ «удерживать поплавки» внутри центрированного элемента. Так что вообще нехороший аргумент!

В каком-то смысле это ложная посылка, идея «дивы против таблиц».

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

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

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

Учти это:

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

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

picture picture picture caption caption caption

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контент и дизайн объединены с помощью таблиц = обновление и контента, и дизайна.

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

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

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

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

<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, но никогда не находил ничего, что работало бы каждый раз без проблем.

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

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

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

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

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

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

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

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

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

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

Проблема в том, что эта «переводческая машина» не может читать веб-сайт, если это делает TABLE. Почему ? Потому что ТАБЛИЦА для ДАННЫХ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потому что ЗАПРЕЩАЕТСЯ поддерживать сайт, который использует таблицы, а кодирование занимает НАМНОГО больше времени. Если вы боитесь плавающих div, пройдите курс по ним. Их нетрудно понять, они примерно в 100 раз эффективнее и в миллион раз меньше зануды в заднице (если вы их не понимаете - но, привет, добро пожаловать в мир компьютеров).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Со столами:

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

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

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

.1. CSS и SEO:

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

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

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

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

Конечно, если нужно обработать результаты с помощью JavaScript, с div'ами стоит потрудиться.

.3. Быстрое тестирование конвертации

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

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

Таблицы макета обычно не одобряются, потому что «все знают, что div и CSS» - лучший способ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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