Есть ли бизнес-причина стремиться к чистому макету CSS?

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

Мой вопрос:

Кому могут навредить эти несколько столов?

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

У Google.com есть таблица в исходном коде, как и на многих других сайтах (между прочим, у stackoverflow.com нет ).

Ответов (21)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бизнес-причина создания макета CSS: вы можете поразить клиентов, сказав, что «наш портал полностью настраивается / меняется скин без написания кода!»

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

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

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

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

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

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

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

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

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

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

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

Ваше здоровье!

[РЕДАКТИРОВАТЬ - добавлено зачеркивание неправильных или вводящих в заблуждение частей этого ответа - см. Комментарии]

делать полную реконструкцию 15-страничного веб-сайта, просто обновив 1 файл, - это рай.

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

CSS - это палка о двух концах на таких крупных сайтах, как наш.

:: кивает Палмси и Джону Галлоуэю ::

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

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

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

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

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

...

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

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

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

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

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

Макеты таблиц могут быть более доступными, чем макеты CSS, и обратное также верно - это ПОЛНОСТЬЮ зависит от исходного порядка контента, и то, что вы избегали таблиц, не означает, что пользователи с программами чтения с экрана автоматически будут хорошо проводить время на вашем сайте. . Таблицы макета не имеют отношения к доступу для чтения с экрана при условии, что содержимое имеет смысл при линеаризации, точно так же, как если бы вы выполняли макет CSS. Таблицы данных разные; их действительно сложно разметить должным образом, и даже в этом случае пользователи программ чтения с экрана обычно не знают команды, которые им нужно использовать для понимания данных.

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

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

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

Еще несколько причин, почему это хорошая практика:

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

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

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

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

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

семантика 101

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

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

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

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

семантика 102

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

заключение

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

Я действительно могу видеть таблицы в Stack Overflow на странице пользователя.

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

Помимо того, что он легко обновляется и соответствует требованиям ...

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

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

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

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

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

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

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

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