Есть ли бизнес-причина стремиться к чистому макету CSS?
Кажется, что каждый раз, когда я пытаюсь создать макет на чистом CSS, у меня уходит гораздо больше времени, чем если бы я использовал одну или две таблицы. Получение трех столбцов одинаковой длины с разным объемом данных, по-видимому, требует особых хитростей, особенно при работе с кроссбраузерными проблемами.
Мой вопрос:
Кому могут навредить эти несколько столов?
Таблицы, кажется, особенно хорошо работают с табличными данными - почему их так ругают в наши дни?
У Google.com есть таблица в исходном коде, как и у многих других сайтов (stackoverflow.com, кстати, не).
Ответы 21
Я считаю, что макет 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*/
}
Я бы действительно рекомендовал использовать условные комментарии IE вместо хаков / фильтров CSS для поддержки IE. Он поддерживается и сохраняет ваш основной CSS в чистоте. Большинство сторонников CSS рекомендуют сейчас отказаться от использования хаков. Пример: <link href = "Style/main.css" rel = "stylesheet" type = "text/css" /> <!--[if lte IE 6]> <link type = "text/css" href = "Style/main-ie6.css" rel = "stylesheet" /> <![endif]-->
@JonGalloway Согласен. Однако иногда проще реализовать взлом CSS, особенно если вы хотите сделать это только для одного или двух элементов.
Как и многие другие вещи, это хорошая идея, которую часто заходит слишком далеко. Мне нравится макет, управляемый div + css, потому что обычно довольно легко изменить внешний вид, даже радикально, просто с помощью таблицы стилей. Также приятно быть дружелюбным к браузерам нижнего уровня, программам чтения с экрана и т. д. Но, как и в большинстве решений в программировании, при принятии решения следует учитывать цель сайта и стоимость разработки. Ни одна из сторон не является правильным в 100% случаев.
Кстати, я думаю, что все согласны с тем, что таблицы должен должны использоваться для табличных данных.
Бизнес-причина для макета CSS: вы можете поразить клиентов, сказав: «Наш портал полностью настраивается / меняется скин без написания кода!»
Опять же, я не вижу ничего плохого в проектировании блочных элементов с таблицами. Под блочными элементами я имею в виду те случаи, когда нет смысла разбивать упомянутый элемент на разные конструкции.
Так что табличные данные, конечно, лучше всего представлять в виде таблиц. Создание основных строительных блоков (таких как строка меню, лента новостей и т. д.) Внутри их собственных таблиц также должно быть приемлемым. Просто не полагайтесь на таблицы для общего макета страницы, и все будет хорошо, я думаю.
идея - это то, что дизайнеры могут проектировать, а веб-разработчики могут реализовывать. Это особенно актуально для динамических веб-приложений, где вы не хотите, чтобы дизайнеры возились с вашим исходным кодом.
Теперь, когда есть движки шаблонов, дизайнеры явно любят сходить с ума, а CSS позволяет выполнять гораздо больше трюков, чем таблицы.
При этом: как разработчик, я отказался от CSS Layout в основном потому, что мой дизайн все равно отстой, так что, по крайней мере, он может отстой :-) Но если бы я когда-нибудь нанял дизайнера, я бы позволил ему использовать все, что выплевывает его редактор WYSIWYG.
Храните свой макет и контент отдельно, что позволяет легко изменять дизайн или вносить настройки и изменения в ваш сайт. Это может занять немного больше времени, но самый длительный этап разработки программного обеспечения - обслуживание. Сайт, дружественный к css, с четким разделением контента и дизайна лучше всего подходит в процессе обслуживания.
Использование семантического HTML-дизайна - одна из тех вещей, когда вы не знаете, что вам не хватает, если не практикуете это на практике. Я работал на нескольких сайтах, где сайт был модернизирован постфактум, практически не повлияв на серверный код.
Рестайлинг сайтов - это очень распространенная просьба, которую я заметил больше, теперь, когда я могу сказать «да» вместо того, чтобы пытаться отговориться.
И, как только вы научитесь работать с системой макета страницы, это обычно не сложнее, чем макет на основе таблицы.
:: кивает Палмси и Джону Галлоуэю ::
Согласен с фактором ремонтопригодности. Мне действительно требуется немного больше времени, чтобы закончить мои первоначальные макеты (поскольку я все еще ученик джедая в искусстве CSS), но сделать полную реконструкцию 15-страничного веб-сайта, просто обновив 1 файл, - это рай.
Еще несколько причин, почему это хорошая практика:
- Доступность - в идеале Интернет должен быть доступен для всех
- Производительность - экономия пропускная способность и загрузка быстрее на мобильном телефоне устройства (им не хватает пропускной способности для некоторых степень и не может быть сложным столы быстро). Кроме того, быстрая загрузка - это всегда хорошо ...
По моему опыту, единственный раз, когда это действительно увеличивает ценность для бизнеса, - это когда требуется 100% поддержка доступности. Если у вас есть пользователи с ослабленным зрением и / или использующие программы чтения с экрана для просмотра вашего сайта, вам необходимо убедиться, что ваш сайт соответствует стандартам доступности.
Пользователи, использующие программы чтения с экрана, будут иметь свою собственную высококонтрастную таблицу стилей с крупным шрифтом (если ваш сайт сам ее не предоставляет), что позволяет программам чтения с экрана легко анализировать страницу.
Когда программа чтения с экрана читает страницу и видит таблицу, она сообщает пользователю, что это таблица. Следовательно, если вы используете таблицу для макета, это очень сбивает с толку, потому что пользователь не знает, что содержимое таблицы на самом деле является статьей, а не некоторыми другими табличными данными. Меню должно быть списком или набором div, а не таблицей с пунктами меню, что опять же сбивает с толку. Вы должны убедиться, что используете цитаты, атрибуты заголовков alt-тегов и т. д., Чтобы сделать его более читабельным.
Если вы сделаете свой дизайн управляемым CSS, то весь ваш внешний вид можно будет убрать и заменить необработанным представлением, которое очень удобно для чтения этими пользователями. Если у вас есть встроенные стили, макеты на основе таблиц и т. д., Вы усложняете для этих пользователей анализ вашего контента.
Хотя я действительно чувствую, что обслуживание немного становится проще, когда ваш сайт полностью построен с использованием CSS, я не думаю, что это относится ко всем видам обслуживания, особенно когда вы имеете дело с кроссбраузерным CSS, который очевидно может быть кошмаром.
Короче говоря, ваша страница должна описывать свой внешний вид в соответствии со стандартами, если вы хотите, чтобы она была доступна указанным пользователям. Если у вас нет необходимости / требований и, вероятно, он вам не понадобится в будущем, тогда не утруждайтесь тратить слишком много времени, пытаясь стать чистым CSS :) Используйте сочетание стиля и техник макета, которое вам подходит и делает вашу работу Полегче.
Ваше здоровье!
[РЕДАКТИРОВАТЬ - добавлено зачеркивание неправильных или вводящих в заблуждение частей этого ответа - см. Комментарии]
Ты несёшь чушь, старый Боб. «Пользователи, которые используют программы чтения с экрана, будут иметь свою собственную высококонтрастную таблицу стилей с крупным шрифтом (если ваш сайт сам ее не предоставляет), что упрощает анализ страницы программам чтения с экрана». Это совсем не так.
Это тоже неправильно. «Когда программа чтения с экрана читает страницу и видит таблицу, она сообщает пользователю, что это таблица ... пользователь не знает, что содержимое таблицы на самом деле является статьей, а не некоторыми другими табличными данными».
Программы чтения с экрана обычно игнорируют макетные таблицы и сообщают пользователю только о таблицах данных. Вы когда-нибудь использовали JAWS или Window-Eyes?
В реальном мире ваши шансы взять один дизайн и полностью изменить его, не касаясь разметки, довольно малы. Это нормально для блогов и придуманных демонстраций, таких как csszengarden, но на самом деле это фиктивное преимущество на любом сайте с умеренно сложным дизайном. Использование CMS гораздо важнее.
DIV плюс CSS! = Семантика тоже. Хороший HTML всегда полезен для SEO и доступности, независимо от того, используются ли для макета таблицы или CSS. Вы получаете действительно эффективный и быстрый веб-дизайн, комбинируя действительно простые таблицы с хорошим CSS.
Макеты таблиц могут быть более доступными, чем макеты CSS, и обратное также верно - это ПОЛНОСТЬЮ зависит от исходного порядка содержимого, и то, что вы избегали таблиц, не означает, что пользователи с программами чтения с экрана автоматически будут хорошо проводить время на вашем сайте. . Таблицы макета не имеют отношения к доступу для чтения с экрана при условии, что контент имеет смысл при линеаризации, точно так же, как если бы вы выполняли макет CSS. Таблицы данных разные; их действительно сложно разметить должным образом, и даже в этом случае пользователи программ чтения с экрана обычно не знают команды, которые им нужно использовать для понимания данных.
Вместо того, чтобы мучиться с использованием нескольких таблиц макета, вам следует беспокоиться о том, чтобы теги заголовков и замещающий текст использовались правильно, а метки форм были правильно назначены. Тогда у вас будет неплохой удар по доступности в реальном мире.
Это результат многолетнего опыта проведения пользовательского тестирования на доступность в Интернете, специализирующегося на доступном дизайне сайтов, а также годичного консультирования по этой теме для интернет-банка Cahoot.
Итак, мой ответ на плакат - нет, нет никаких коммерческих причин предпочитать CSS таблицам. Это более элегантно, более удовлетворительно и более правильно, но вы как человек, создающий его, и человек, который должен его поддерживать после того, как вы - единственные два человека в мире, которым наплевать на CSS или таблицы.
When a screenreader reads a page and sees a table, it'll tell the user it's a table. Hence, if you use a table for layout, it gets very confusing because the user doesn't know that the content of the table is actually the article instead of some other tabular data
На самом деле это не так; программы чтения с экрана, такие как JAWS, Window Eyes и HAL, игнорируют таблицы макетов. Они действительно хорошо работают с реальной сетью.
Еще одна вещь, которую я только что вспомнил, вы можете назначить другую таблицу стилей странице для печати и отображения.
В дополнение к обычному определению таблицы стилей вы можете добавить следующий тег
<link rel = "stylesheet" type = "text/css" media = "print" href = "PrintStyle.css" />
Что будет отображать документ в соответствии с этим стилем, когда вы отправите его на принтер. Это позволяет вырезать фоновые изображения, дополнительную информацию верхнего / нижнего колонтитула и просто распечатать необработанную информацию без создания отдельного модуля.
doing a complete revamp of a 15 page web site just by updating 1 file is heaven.
Это правда. К сожалению, ваш худший кошмар станет реальностью, если использовать один файл CSS на 15000 сложных и сильно различающихся страницах. Измените что-нибудь - это сломало тысячу страниц? Кто знает?
CSS - это палка о двух концах на таких крупных сайтах, как наш.
Если у вас есть общедоступный веб-сайт, реальный бизнес-кейс - это SEO.
Доступность важна, и поддерживать семантический (X) HTML является намного проще, чем поддерживать макеты таблиц, но это место №1 в Google принесет домой бекон.
Например: Ежемесячный веб-отчет: 127 миллионов просмотров страниц за июль
Monthly web report: 127 million page views for July
...
Latimes.com keeps getting better at SEO (search engine optimization), which means our stories are ranking higher in Google and other search engines. We are also performing better on sites like Digg.com. All that adds up to more exposure and more readership than ever before.
Если вы посмотрите на их сайт, у них довольно приличный CSS-макет.
Как правило, в наши дни вы обнаруживаете относительно немного макетов таблиц, хорошо показывающих результаты в поисковой выдаче.
Я не думаю, что для этого есть какая-то деловая причина. Техническая причина, может быть, даже так, едва ли - это огромная трата времени во всем мире, а потом смотришь на это в IE, ломаешься и плачешь.
*I would let him use whatever his WYSIWYG Editor spits out
I just threw-up a little...
*ahh hello? You don't think the graphic designer is writing the CSS by hand do you?
Как ни странно, я работал с несколькими дизайнерами, и лучшие из них делать вручную настраивали свои CSS. Парень, о котором я думаю, на самом деле выполняет всю свою дизайнерскую работу в виде файла XHTML с парой файлов CSS и создает графические элементы на лету по мере необходимости. Он использует Dreamweaver, но только как инструмент навигации. (Я многому научился у этого парня)
После того, как вы вложили деньги в изучение дизайна, основанного исключительно на CSS, и набрались небольшого опыта (выяснили, где IE - отстой [честно говоря, становится лучше]), я обнаружил, что он работает быстрее. Я работал над системами управления контентом, и приложениям редко приходилось менять, чтобы дизайнеры придумывали радикально другой вид.
Так как это stackпереполнение, я дам вам свой ответ программиста
semantics 101Сначала взгляните на этот код и подумайте, что здесь не так ...
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
Проблема, конечно, в том, что байк - это не машина. Класс автомобиля не подходит для экземпляра велосипеда. Код не содержит ошибок, но семантически неверен. Это плохо отражается на программисте.
semantics 102Теперь примените это к разметке документа. Если в вашем документе должны быть представлены табличные данные, то подходящим тегом будет <table>. Однако, если вы поместите навигацию в таблицу, вы неправильно используете предназначение элемента <table>. Во втором случае вы не представляете табличные данные - вы (неправильно) используете элемент <table> для достижения презентационной цели.
Кому это больно? Никто. Кому выгодно использовать семантическую разметку? Вы - и ваша профессиональная репутация. А теперь иди и поступай правильно.
Я действительно могу видеть таблицы в Stack Overflow на странице пользователя.
У него даже есть куча встроенных стилей ...
Помимо того, что он легко обновляется и соответствует требованиям ...
Я использую для проектирования всех веб-сайтов, основанных на таблицах, и сначала я сопротивлялся, но постепенно я перешел на CSS. Это произошло не в одночасье, но это произошло, и вы тоже должны это сделать.
Были ночи, когда я хотел выбросить свой компьютер из окна, потому что стиль, который я применял к div, не делал то, что я хочу, но вы учитесь на этих препятствиях.
Что касается бизнеса, как только вы дойдете до разработки веб-сайтов с помощью CSS вплоть до науки, вы сможете разрабатывать процессы для каждого сайта и даже использовать предыдущие веб-сайты и просто добавлять другой рисунок заголовка, цвет и т. д.
Кроме того, не забудьте встроить / включить все многократно используемые части вашего веб-сайта: заголовок, подзаголовок, нижний колонтитул.
Как только вы перебраетесь через горку, все будет вниз по склону. Удачи!
Основной причиной, по которой мы изменили наши веб-страницы на макет на основе DIV / CSS, была задержка отрисовки страниц на основе таблиц.
У нас есть общедоступный веб-сайт, большая часть пользователей которого находится в таких странах, как Индия, где пропускная способность интернета все еще остается проблемой (она улучшается день ото дня, но все еще не на должном уровне). В таких обстоятельствах, когда мы использовали макет на основе таблиц, пользователям приходилось довольно долго смотреть на пустую страницу. Тогда вся страница будет отображаться как единое целое в галочке. Преобразуя наши страницы в формат DIV, нам удалось доставить некоторое содержимое в браузер почти мгновенно, когда пользователи заходили на наш веб-сайт, и этого содержимого было достаточно, чтобы заинтересовать пользователей, пока браузер не загрузит все содержимое страницы.
Главный недостаток реализации на основе таблиц заключается в том, что браузер будет отображать содержимое таблицы только после того, как он загрузит весь html для этой таблицы. Проблема исчезнет, когда у нас будет основная таблица, которая обертывает все содержимое страницы, и когда у нас будет много вложенных таблиц. Для «гибких таблиц» (без фиксированной ширины) после загрузки всего тега таблицы браузер должен анализировать до последней строки таблицы, чтобы узнать ширину каждого столбца, а затем должен снова проанализировать ее для отображения содержимого. . Пока все это не произойдет, пользователи должны смотреть на пустой экран, тогда все будет отображаться в мгновение ока.
Определенно есть. Если вы все еще стремитесь к этому, вы не понимаете этого правильно.
Макет DIV + CSS на самом деле намного проще, чем макет таблицы, с точки зрения удобства обслуживания и производительности. Просто продолжайте практиковать, пока еще не рано об этом говорить.
Макет таблицы тоже хорош, просто он не предназначен для макетов и имеет исключительные недостатки, когда дело доходит до незначительной настройки.
В Stackoverflow есть таблицы в определенной части (по состоянию на декабрь 2008 г.), например на странице пользователя.