Есть ли причина для стремления к чистой компоновке CSS?

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

Мой вопрос:

Кому эти несколько таблиц будут больно?

Таблицы, по-видимому, особенно хорошо работают на табличных данных; почему они так оскорблены в наши дни? У Google.com есть таблица в исходном коде, поэтому многие другие сайты (например, stackoverflow.com).

Ответ 1

Поскольку это стек переполнение, я дам вам ответ моего программиста

семантика 101

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

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

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

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

семантика 102

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

вывод

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

Ответ 2

Как и многие вещи, это хорошая идея, которая часто переносится слишком далеко. Мне нравится макет div + css, потому что обычно довольно легко изменить внешний вид, даже резко, только через таблицу стилей. Также приятно быть дружелюбным к браузерам более низкого уровня, программам чтения с экрана и т.д. Но, как и большинство решений в программировании, цель сайта и стоимость разработки должны учитываться при принятии решения. Ни одна из сторон не верна в 100% случаев.

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

Ответ 3

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

DIVs плюс CSS!= семантический. Хороший HTML хорошо стоит для SEO и доступности, независимо от того, используются ли таблицы или CSS для макета. Вы получаете действительно эффективные, быстрые веб-проекты, объединяя действительно простые таблицы с хорошим CSS.

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

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

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

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

Ответ 4

Использование семантического HTML-дизайна - одна из тех вещей, где вы не знаете, что вам не хватает, если вы не практикуете ее. Я работал на нескольких сайтах, где сайт был рестайлингом после факта с небольшим или никаким воздействием на серверный код.

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

И, как только вы научились работать со структурой макета страницы, обычно это не сложнее, чем табличный макет.

Ответ 5

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

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Кроме того, для страшных проблем IE6 CSS вы можете использовать этот хак:

.someClass {
    background-color:black; /*this is for most browsers*/
    _background-color:white; /*this is for IE6 only - all others will ignore it*/
}

Ответ 6

Если у вас есть общественный сайт, реальный бизнес-пример - SEO.

Доступность важна и сохранение семантического (X) HTML гораздо проще, чем поддержка макетов таблиц, но это # ​​1 место в Google принесет домой бекон.

Например: Ежемесячный веб-отчет: 127 миллионов просмотров страниц за июль

Ежемесячный веб-отчет: 127 миллионов просмотров страниц за июль

...

Latimes.com продолжает улучшаться в SEO (поисковая оптимизация), что означает, что наши истории занимают лидирующие позиции в Google и других поисковых системах. Мы также работаем лучше на таких сайтах, как Digg.com. Все это добавляет больше внимания и большей читаемости, чем когда-либо прежде.

Если вы посмотрите на свой сайт, у них будет довольно приличный макет CSS.

Как правило, вы находите относительно небольшое количество макетов таблиц, которые хорошо выполняются в SERP в наши дни.

Ответ 7

Основная причина, по которой мы изменили наши веб-страницы на макет на основе DIV/CSS, - это задержка в создании страниц на основе таблицы.

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

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

Ответ 8

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

Ответ 9

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

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

Когда читатель просматривает страницу и видит таблицу, она сообщает пользователю таблицу. Следовательно, если вы используете таблицу для макета, она становится очень запутанной, потому что пользователь не знает, что содержимое таблицы на самом деле является статьей, а не некоторыми другими табличными данными. Меню должно быть списком или коллекция divs, а не таблица с элементами меню, опять же запутанная. Вы должны убедиться, что вы используете blockquotes, атрибуты заголовков alt-tags и т.д., Чтобы сделать его более читаемым.

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

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

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

Ура!

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

Ответ 10

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

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

<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />

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

Ответ 11

Выполнение полного обновления 15-страничного веб-сайта только путем обновления 1 файла - это рай.

Это верно. К сожалению, использование одного файла CSS, используемого 15 000 сложными и широко разнящимися страницами, является вашим худшим кошмаром. Что-то изменилось - это сломало тысячу страниц? Кто знает?

CSS - это обоюдоострый меч на больших сайтах, подобных нашим.

Ответ 12

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

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

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

Ответ 13

Деловая причина для макета CSS: вы можете сдуть клиентов, сказав: "Наш портал полностью настраивается/скинируется без написания кода!"

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

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

Ответ 14

* Я бы позволил ему использовать то, что его редактор WYSIWYG выплеснул
Я просто подбросил немного...
* ахх привет? Вы не думаете, что графический дизайнер пишет CSS вручную?

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

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

Ответ 15

Кроме того, он легко обновляется и совместим...

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

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

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

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

Как только вы перейдете через горб, все будет вниз от холма. Удачи!

Ответ 16

:: кивает на palmsey и Jon Galloway::

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

Ответ 17

Некоторые дополнительные причины, почему это хорошая практика:

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

Ответ 18

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

Это на самом деле не так; такие как JAWS, Window Eyes и HAL игнорируют таблицы макетов. Они отлично работают при работе с реальной сетью.

Ответ 19

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

Ответ 20

i на странице пользователя можно увидеть Таблицы в переполнении стека.

У него даже есть кучи встроенных стилей...

Ответ 21

Там определенно есть. Если вы все еще стремитесь к этому, вы не понимаете это правильно.

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

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