Есть ли деловая причина стремиться к чистому макету CSS?
Кажется, что каждый раз, когда я пытаюсь создать чистый макет CSS, это занимает гораздо больше времени, чем если бы я использовал таблицу или две. Кажется, что для получения трех столбцов одинаковой длины с разными объемами данных требуются особые хитроумные хаки, особенно при работе с кросс-браузерными проблемами.
Мой вопрос:
Кто эти несколько столов собирается повредить?
Таблицы, кажется, особенно хорошо работают с табличными данными - почему они так оскорблены в наше время? У Google.com есть таблица в исходном коде, как и у многих других сайтов (нет, кстати, stackru.com).
21 ответ
Поскольку это переполнение стека, я дам вам ответ моего программиста
семантика 101Сначала взгляните на этот код и подумайте, что здесь не так...
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
Проблема, конечно, в том, что велосипед - это не машина. Класс автомобиля - неподходящий класс для экземпляра велосипеда. Код не содержит ошибок, но семантически неверен. Это плохо отражается на программисте.
семантика 102Теперь примените это к разметке документа. Если ваш документ должен представлять табличные данные, то соответствующий тег будет <table>, Однако если вы поместите навигацию в таблицу, то вы неправильно используете <table> элемент. Во втором случае вы не представляете табличные данные - вы (неправильно) используете <table> элемент для достижения цели презентации.
Кому это больно? Ни один. Никто. Кому выгодно, если вы используете семантическую разметку? Вы - и ваша профессиональная репутация. Теперь иди и делай правильные вещи.
Как и многие вещи, это хорошая идея, которая часто заходит слишком далеко. Мне нравится макет, управляемый div+css, потому что обычно довольно просто изменить внешний вид, даже радикально, просто с помощью таблицы стилей. Также приятно быть дружелюбным к браузерам более низкого уровня, программам для чтения с экрана и т. Д. Но, как и большинство решений в программировании, при принятии решения следует учитывать цель сайта и стоимость разработки. Ни одна из сторон не является правильным способом идти 100% времени.
Кстати, я думаю, что все согласны с тем, что таблицы должны использоваться для табличных данных.
В реальном мире ваши шансы взять один дизайн и полностью перерисовать его, не касаясь разметки, довольно малы. Это хорошо для блогов и придуманных демонстраций, таких как csszengarden, но на самом деле это фиктивная выгода на любом сайте с умеренно сложным дизайном. Использование CMS намного важнее.
DIVs плюс CSS!= Семантические, либо. Хороший HTML полезен для SEO и доступности всегда, независимо от того, используются ли таблицы или CSS для верстки. Вы получаете действительно эффективный и быстрый веб-дизайн, комбинируя действительно простые таблицы с хорошим CSS.
Макеты таблиц могут быть более доступными, чем макеты CSS, и обратное также верно - это ПОЛНОСТЬЮ зависит от исходного порядка контента, и только то, что вы избегаете таблиц, не означает, что пользователи с программами чтения с экрана автоматически будут хорошо проводить время на вашем сайте., Таблицы макетов не имеют отношения к доступу чтения с экрана, если содержимое имеет смысл при линеаризации, точно так же, как если бы вы делали макет CSS. Таблицы данных разные; их действительно трудно правильно разметить, и даже в этом случае пользователи программного обеспечения для чтения с экрана, как правило, не знают команд, которые им необходимы для понимания данных.
Вместо того, чтобы мучиться с использованием нескольких таблиц макета, вам следует беспокоиться о том, что теги заголовков и альтернативный текст используются правильно и что метки форм назначаются правильно. Тогда у вас будет довольно хороший удар по доступности реального мира.
Это связано с многолетним опытом проведения пользовательского тестирования доступности веб-сайтов, специализацией на доступном дизайне сайта и консалтингом онлайн-банка Cahoot по этой теме в течение года.
Так что мой ответ на постер - нет, нет никаких бизнес-причин предпочитать CSS таблицам. Это более элегантно, более удовлетворительно и более правильно, но вы, как человек, который его строит, и человек, который должен поддерживать его после вас, являются единственными людьми в мире, которые дают задницу крысе, будь то CSS или таблицы.
Мне кажется, что CSS-разметка с как можно меньшим количеством таблиц чище и лучше, но я согласен, что иногда вам просто нужно использовать таблицу.
С точки зрения бизнеса это, как правило, "то, что сделает это самым быстрым и самым надежным способом". По моему опыту, использование нескольких таблиц обычно относится к этой категории.
Я обнаружил, что очень эффективный способ уменьшить различия между браузерами при рендеринге CSS - это использовать "строгий" тип документа в верхней части вашей страницы:
<!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*/
}
Использование семантического HTML-дизайна - это одна из тех вещей, когда вы не знаете, чего вам не хватает, если не будете практиковаться в этом. Я работал на нескольких сайтах, где сайт был обновлен после факта, практически не влияя на код на стороне сервера.
Рестайлинг сайтов - это очень распространенный запрос, который я заметил больше сейчас, когда я могу сказать "да" вместо того, чтобы пытаться отговорить меня.
И, как только вы научитесь работать с системой разметки страниц, это обычно не сложнее, чем разметка на основе таблиц.
Основной причиной, по которой мы изменили наши веб-страницы на макет на основе DIV/CSS, была задержка рендеринга страниц на основе таблиц.
У нас есть общедоступный веб-сайт, и большинство его пользователей находятся в таких странах, как Индия, где пропускная способность интернета все еще остается проблемой (с каждым днем она улучшается, но все еще не на одном уровне). В таких обстоятельствах, когда мы использовали макет на основе таблицы, пользователям приходилось смотреть на пустую страницу в течение достаточно долгого времени. Тогда вся страница будет отображаться в виде галочки. Преобразовав наши страницы в DIV, нам удалось почти мгновенно передать некоторое содержимое в браузер, когда пользователи зашли на наш веб-сайт, и этого содержимого было достаточно, чтобы привлечь пользователей, пока браузер не загрузит все содержимое страницы.
Основным недостатком реализации на основе таблиц является то, что браузер будет отображать содержимое таблицы только после того, как он загрузит весь HTML-код для этой таблицы. Эта проблема исчезнет, когда у нас будет главная таблица, которая обернет все содержимое страницы, и когда у нас будет много вложенных таблиц. Для "гибких таблиц" (без фиксированной ширины) после загрузки тега всей таблицы браузер должен проанализировать до последней строки таблицы, чтобы определить ширину каждого столбца, а затем снова проанализировать ее для отображения содержимого., Пока все это происходит, пользователи должны смотреть на пустой экран, тогда все будет отображаться в виде галочки.
Если у вас есть общедоступный веб-сайт, то реальный бизнес-пример - это SEO.
Доступность важна, и поддерживать семантический (X)HTML намного проще, чем поддерживать макеты таблиц, но это место № 1 в Google принесет домой бекон.
Например: Ежемесячный веб-отчет: 127 миллионов просмотров страниц за июль
Ежемесячный веб-отчет: 127 миллионов просмотров страниц за июль
...
Latimes.com продолжает совершенствоваться в SEO (поисковая оптимизация), что означает, что наши истории занимают более высокие позиции в Google и других поисковых системах. Мы также работаем лучше на таких сайтах, как Digg.com. Все это дает больше информации и больше читателей, чем когда-либо прежде.
Если вы посмотрите на их сайт, у них будет довольно приличный CSS-макет.
В целом, в наши дни вы найдете относительно мало таблиц, которые хорошо работают в поисковой выдаче.
Храните свой макет и ваш контент отдельно, что позволяет легко изменять дизайн или вносить изменения в ваш сайт. Это может занять немного больше времени, но самой длительной фазой разработки программного обеспечения является обслуживание. Css friendly сайт с четким разделением контента и дизайна лучше всего подходит для технического обслуживания.
По моему опыту, единственный раз, когда это действительно повышает ценность для бизнеса, это когда требуется 100% поддержка доступности. Если у вас есть пользователи с нарушениями зрения и / или использующие программы чтения с экрана для просмотра вашего сайта, вы должны убедиться, что ваш сайт соответствует стандартам доступности.
Пользователи, использующие программы чтения с экрана, будут склонны иметь собственную высококонтрастную таблицу стилей с большим шрифтом (если ваш сайт не предоставляет ее самостоятельно), которая облегчает анализаторам страницы анализ страницы.
Когда программа чтения с экрана читает страницу и видит таблицу, она сообщает пользователю, что это таблица. Следовательно, если вы используете таблицу для разметки, это очень сбивает с толку, потому что пользователь не знает, что содержимое таблицы на самом деле является статьей, а не некоторыми другими табличными данными. Меню должно быть списком или набором элементов div, а не таблицей с элементами меню, опять же, это сбивает с толку. Вы должны убедиться, что используете блочные кавычки, атрибуты заголовка alt-tags и т. Д., Чтобы сделать его более читабельным.
Если вы создаете свой дизайн на основе CSS, тогда весь ваш внешний вид может быть удален и заменен необработанным представлением, которое очень читаемо для этих пользователей. Если у вас есть встроенные стили, макеты на основе таблиц и т. Д., Этим пользователям будет сложнее анализировать ваш контент.
Хотя я чувствую, что обслуживание становится проще для некоторых вещей, когда ваш сайт полностью выложен с помощью CSS, я не думаю, что это подходит для всех видов обслуживания, особенно когда вы работаете с кросс-браузерным CSS, который очевидно, может быть кошмаром.
Короче говоря, ваша страница должна описывать ее оформление в соответствии со стандартами, если вы хотите, чтобы она была доступна для указанных пользователей. Если у вас нет необходимости / требования и, вероятно, вам это не понадобится в будущем, не тратьте слишком много времени на попытки стать чистым CSS-пользователем:) Используйте сочетание стилей и техник верстки, которые подходят вам и делают вашу работу Полегче.
Ура!
[РЕДАКТИРОВАТЬ - добавлены зачеркивание в неправильные или вводящие в заблуждение части этого ответа - см. Комментарии]
полное обновление веб-сайта на 15 страниц путем обновления 1 файла - это рай.
Это правда. К сожалению, использование одного CSS-файла на 15 000 сложных и широко различающихся страниц - ваш худший ночной кошмар. Измените что-нибудь - это сломало тысячу страниц? Кто знает?
CSS является обоюдоострым мечом на больших сайтах, подобных нашему.
Еще одна вещь, которую я только что вспомнил, вы можете назначить другую страницу стилей для печати и отображения.
В дополнение к обычному определению таблицы стилей вы можете добавить следующий тег
<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />
Который будет отображать документ в соответствии с этим стилем, когда вы отправляете его на принтер. Это позволяет вырезать фоновые изображения, дополнительную информацию верхнего / нижнего колонтитула и просто печатать необработанную информацию, не создавая отдельный модуль.
Идея заключается в том, что дизайнеры могут проектировать, а веб-разработчики могут реализовать. Это особенно актуально в динамических веб-приложениях, где вы не хотите, чтобы ваши дизайнеры возились с исходным кодом.
Теперь, когда есть движки шаблонов, дизайнеры просто любят сходить с ума, а CSS позволяет выполнять гораздо больше трюков, чем таблиц.
Тем не менее, как разработчик, я отказался от CSS Layout в основном потому, что мой дизайн все равно не работает, так что, по крайней мере, он может сосать правильно:-) Но если бы я когда-нибудь нанял дизайнера, я бы позволил ему использовать то, что выплевывает его редактор WYSIWYG.
Бизнес-причина для CSS-макета: вы можете удивить клиентов, сказав, что "наш портал полностью настраиваемый / скиновый без написания кода!"
Опять же, я не вижу ничего плохого в разработке блочных элементов с помощью таблиц. Под блочными элементами я подразумеваю, где не имеет смысла разбивать упомянутый элемент в разных конструкциях.
Таким образом, табличные данные лучше всего представлять в виде таблиц, конечно. Проектирование основных строительных блоков (таких как строка меню, новостная лента и т. Д.) В своих собственных таблицах также должно быть в порядке. Только не полагайтесь на таблицы для общего макета страницы, и все будет хорошо, я думаю.
Помимо того, что легко обновляется и соответствует...
Я использую для разработки всех веб-сайтов, основанных на таблицах, и сначала я был устойчив, но постепенно я перешел на CSS. Это не произошло в одночасье, но это произошло, и это то, что вы должны сделать также.
Было несколько вечеров, когда я хотел выбросить свой компьютер из окна, потому что стиль, который я применял к div, делал не то, что я хочу, а вы учитесь на этих препятствиях.
Что касается бизнеса, то, как только вы приступите к разработке веб-сайтов с помощью CSS, вплоть до науки, вы можете разработать процессы для каждого сайта и даже использовать прошлые веб-сайты и просто добавить другой заголовок, цвет и т. Д.
Кроме того, обязательно вставьте / включите все повторно используемые части вашего сайта: верхний колонтитул, подзаголовок, нижний колонтитул.
Как только вы преодолеете горб, оттуда все будет вниз. Удачи!
* Я бы позволил ему использовать то, что выплевывает его редактор WYSIWYG
Я просто вырвал немного...
* ааа привет? Вы не думаете, что графический дизайнер пишет CSS вручную?
Как ни странно, я работал с несколькими дизайнерами, и лучшие из них вручную настраивают свои CSS. Парень, о котором я думаю, на самом деле выполняет все свои дизайнерские работы в виде файла XHTML с парой CSS-файлов и создает графические элементы на лету, когда они им нужны. Он использует Dreamweaver, но только в качестве навигационного инструмента. (Я многому научился у этого парня)
После того, как вы вложили средства в изучение чисто CSS-дизайна и приобрели небольшой опыт (выяснил, где IE отстой [честно, он становится лучше]), я обнаружил, что это быстрее. Я работал над системами управления контентом, и приложениям редко приходилось менять дизайнерам, чтобы они выглядели совершенно иначе.
:: кивает на Палмси и Джона Галлоуэя::
Я согласен с фактором ремонтопригодности. У меня заняло немного больше времени, чтобы сделать начальные макеты (поскольку я все еще ученик джедая в искусстве CSS), но полная модернизация 15-страничного веб-сайта путем обновления 1 файла - это рай.
Некоторые дополнительные причины, почему это хорошая практика:
- Доступность - сеть в идеале должна быть доступна всем
- Производительность - экономьте пропускную способность и ускоряйте загрузку на мобильных устройствах (им в некоторой степени не хватает пропускной способности и они не могут быстро составлять сложные таблицы). Помимо быстрой загрузки всегда хорошо...
Там определенно есть. Если вы все еще стремитесь к этому, вы не понимаете это правильно.
Макет DIV+CSS на самом деле намного проще, чем макет таблицы, с точки зрения удобства обслуживания и производительности. Просто продолжайте практиковать это, пока еще не слишком рано говорить это.
Макет таблицы тоже хорош, просто он не предназначен для раскладок и имеет исключительные недостатки, когда дело доходит до незначительной настройки.
Я не думаю, что есть деловая причина вообще. Техническая причина, может быть, даже и так, едва ли - это огромный тайм-аут во всем мире, а потом ты смотришь на это в IE, ломаешься и плачешь.
Я на самом деле могу видеть таблицы в переполнении стека на странице пользователя.
У него даже есть куча встроенных стилей...
Когда программа чтения с экрана читает страницу и видит таблицу, она сообщает пользователю, что это таблица. Следовательно, если вы используете таблицу для разметки, это очень сбивает с толку, потому что пользователь не знает, что содержимое таблицы на самом деле является статьей, а не некоторыми другими табличными данными.
Это на самом деле не правда; программы чтения с экрана, такие как JAWS, Window Eyes и HAL, игнорируют таблицы разметки. Они очень хорошо работают в реальной сети.