My<cod/>.net
Есть ли бизнес-причина для стремления к чистому макету CSS?
Кажется, что каждый раз, когда я пытаюсь создать чистый макет CSS, мне требуется гораздо больше времени, чем если бы я использовал таблицу или две. Получение трех столбцов одинаковой длины с разными объемами данных, по-видимому, требует особых причудливых хаков, особенно при решении проблем кросс-браузера.
мой вопрос:
Кому могут навредить эти несколько столов?
Таблицы, кажется, работают особенно хорошо на табличных данных — почему они так оскорбляются в этот день и возраст? Google.com имеет таблицу в своем исходном коде, так же как и многие другие сайты (stackoverflow.com, кстати, не имеет).
Как и многое другое, это хорошая идея, которая часто заходит слишком далеко. Мне нравится управляемый макет div+css, потому что обычно довольно легко изменить внешний вид, даже резко, просто через таблицу стилей. Также приятно быть дружелюбным к низкоуровневым браузерам, читателям экрана и т. д. Но, как и большинство решений в программировании, цель сайта и стоимость разработки должны учитываться при принятии решения. Ни одна из сторон не является правильным путем, чтобы идти 100% времени.
BTW, я думаю, все согласны с тем, что таблицы должны использоваться для табличных данных.
В реальном мире ваши шансы взять один дизайн и полностью перекинуть его, не касаясь markup, довольно малы. Это хорошо для блогов и придуманных демо-версий, таких как csszengarden, но это фиктивное преимущество на любом сайте с умеренно сложным дизайном, на самом деле. Использование CMS гораздо важнее.
DIVs плюс CSS != семантический тоже. Хороший HTML хорошо подходит для SEO и доступности всегда, независимо от того, используются ли таблицы или CSS для компоновки. Вы получаете действительно эффективный, быстрый веб-дизайн, комбинируя действительно простые таблицы с некоторыми хорошими CSS.
Макеты таблиц могут быть более доступными, чем макеты CSS, и обратное также верно - это зависит от порядка источника контента TOTALLY, и только потому, что вы избегаете таблиц, не означает, что пользователи с читателями экрана автоматически будут хорошо проводить время на вашем сайте. Таблицы компоновки не имеют отношения к доступу для чтения с экрана при условии, что содержимое имеет смысл при линеаризации, точно так же, как если бы вы делали макет CSS. Таблицы данных отличаются друг от друга; их действительно трудно правильно разметить, и даже тогда пользователи программного обеспечения screen reader обычно не знают команд, которые им нужно использовать для понимания данных.
Вместо того чтобы мучиться из-за использования нескольких таблиц компоновки, вы должны беспокоиться о том, что теги заголовков и текст alt используются правильно, а метки форм назначаются правильно. Тогда у вас будет довольно хороший удар по реальной доступности мира.
Это связано с многолетним опытом проведения тестирования пользователей на доступность веб-сайтов, специализацией на доступном дизайне сайтов, а также с консультациями для cahoot, онлайн-банка, по этой теме в течение года.
Поэтому мой ответ на плакат-Нет, нет никаких деловых причин предпочитать CSS столам. Это более элегантно, более удовлетворительно и более правильно, но вы как человек, который строит его, и человек, который должен поддерживать его после того, как вы-единственные два человека в мире, которым наплевать, будет ли это CSS или таблицы.
Использование семантического дизайна HTML - это одна из тех вещей, где вы не знаете, чего вам не хватает, если вы не практикуете это. Я работал на нескольких сайтах, где сайт был рестайлингован после того, как это произошло, практически не повлияв на код на стороне сервера.
Рестайлинг сайтов-это очень распространенный запрос, то, что я заметил больше сейчас, когда я могу сказать "yes" вместо того, чтобы пытаться отговорить себя.
И, как только вы научились работать с системой компоновки страниц, это обычно не сложнее, чем макет на основе таблиц.
Я думаю, что CSS макет с как можно меньшим количеством таблиц чище и лучше, но я согласен, что иногда вы просто должны использовать таблицу.
С точки зрения бизнеса, это, как правило, "то, что собирается сделать это самым быстрым и надежным способом."По моему опыту, использование нескольких таблиц обычно попадает в эту категорию.
Я обнаружил, что очень эффективный способ уменьшить межбраузерные различия в рендеринге CSS - это использовать "strict" 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*/
}
Если у вас есть публичный веб-сайт, реальный бизнес-кейс-это SEO.
Доступность важна, и поддержание семантического (X) HTML намного проще, чем поддержание макетов таблиц, но это место #1 в Google принесет домой бекон.
Например: ежемесячный веб-отчет: 127 миллионов просмотров страниц за июль
Ежемесячный веб-отчет: 127 миллионов просмотров страниц за июль ...
Latimes.com продолжает улучшаться в SEO (поисковая оптимизация), что означает, что наши истории занимают более высокое место в Google и других поисковых системах. Мы также лучше работаем на таких сайтах, как Digg.com. Все это приводит к еще большей открытости и большей читательской аудитории, чем когда-либо прежде.
Если вы посмотрите на их сайт,у них есть довольно приличный макет CSS.
Как правило, вы находите относительно мало макетов таблиц, хорошо работающих в SERPs в эти дни.
Основная причина, по которой мы изменили наши веб-страницы на макет на основе DIV/CSS, заключалась в задержке рендеринга страниц на основе таблиц.
У нас есть общедоступный веб-сайт, причем большинство его пользователей базируется в таких странах, как Индия, где пропускная способность интернета все еще является проблемой (она улучшается изо дня в день, но все еще не на одном уровне). В таких условиях, когда мы использовали табличный макет, пользователям приходилось довольно долго смотреть на пустую страницу. Тогда вся страница будет отображаться как единое целое в виде галочки. Преобразовав наши страницы в DIV, мы сумели принести некоторое содержание в браузер почти мгновенно, как только пользователи вошли на наш веб-сайт, и это содержание, где достаточно, чтобы привлечь пользователей, пока браузер не загрузит все содержимое страницы.
Основным недостатком реализации на основе таблиц является то, что браузер будет показывать содержимое таблицы только после того, как он загрузит весь html для этой таблицы. Проблема будет устранена, когда у нас есть главная таблица, которая охватывает все содержимое страницы, и когда у нас есть много вложенных таблиц. Для 'flexible tables' (тех, кто не имеет фиксированной ширины), после загрузки всего тега таблицы, браузер должен проанализировать до последней строки таблицы, чтобы узнать ширину каждого столбца, а затем должен проанализировать его снова для отображения содержимого. До тех пор, пока все это не произойдет, пользователи должны смотреть на пустой экран, а затем все появится на экране в один момент.
Держите свой макет и контент отдельно друг от друга, что позволяет вам легко перепроектировать или вносить изменения и изменения в свой сайт. Это может занять немного больше времени, но самая длинная фаза разработки программного обеспечения-это техническое обслуживание . Дружественный сайт css с четким разделением между контентом и дизайном лучше всего подходит в ходе технического обслуживания.
По моему опыту, единственный раз, когда это действительно повышает ценность бизнеса, - это когда есть необходимость в поддержке 100% для доступности. Если у вас есть пользователи с нарушениями зрения и / или вы используете экранные программы для просмотра вашего сайта, вы должны убедиться, что ваш сайт соответствует стандартам доступности.
Пользователи, которые используют screenreaders, как правило, имеют свою собственную высококонтрастную таблицу стилей с большим шрифтом (если ваш сайт сам ее не предоставляет), что облегчает для screenreaders разбор страницы.
Когда screenreader читает страницу и видит таблицу, он сообщает пользователю, что это таблица. Следовательно, если вы используете таблицу для макета, это становится очень запутанным, потому что пользователь не знает, что содержимое таблицы на самом деле является статьей, а не какими-то другими табличными данными. Меню должно быть списком или коллекцией дивов, а не таблицей с пунктами меню, опять же это сбивает с толку. Вы должны убедиться, что используете blockquotes, alt-tags title attributes и т. д., Чтобы сделать его более читаемым.
Если вы сделаете свой дизайн CSS-управляемым, то весь ваш внешний вид может быть удален и заменен на необработанный вид, который очень удобочитаем для этих пользователей. Если у вас есть встроенные стили, табличные макеты и т. д., то вы усложняете для этих пользователей анализ вашего контента.
Хотя я действительно чувствую, что обслуживание облегчается для некоторых вещей, когда ваш сайт полностью выложен с CSS, я не думаю, что это относится ко всем видам обслуживания-особенно когда вы имеете дело с кросс-браузером CSS, который, очевидно, может быть кошмаром.
Короче говоря, ваша страница должна описывать свой состав в соответствии со стандартами, если вы хотите, чтобы она была доступна для указанных пользователей. Если у вас нет необходимости/требования и, вероятно, не будет необходимости в этом в будущем, то не тратьте слишком много времени, пытаясь быть пуристом CSS :) используйте смесь стилей и методов компоновки, которая подходит вам и облегчает вашу работу.
Ваше здоровье!
[EDIT-добавлено зачеркивание неправильных или вводящих в заблуждение частей этого ответа - см. комментарии]
Еще одна вещь, которую я только что вспомнил,вы можете назначить другую таблицу стилей для страницы для печати или отображения.
В дополнение к обычному определению таблицы стилей можно добавить следующий тег
<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />
Который будет отображать документ в соответствии с этим стилем, когда вы отправите его на принтер. Это позволяет удалить фоновые изображения, дополнительную информацию верхнего / нижнего колонтитула и просто распечатать исходную информацию без создания отдельного модуля.
сделать полную реконструкцию 15-страничного веб-сайта, просто обновив 1 файл, - это рай.
сделать полную реконструкцию 15-страничного веб-сайта, просто обновив 1 файл, - это рай.
Это действительно так. К сожалению, наличие одного файла CSS, используемого 15 000 сложными и широко различающимися страницами, - это ваш самый страшный кошмар. Измени что-нибудь - может быть, это сломает тысячу страниц? Кто знает?
CSS-это обоюдоострый меч на таких больших площадках, как наша.
Идея заключается в том, что дизайнеры могут разрабатывать, а веб-разработчики могут реализовывать. Это особенно актуально в динамических веб-приложениях, где вы не хотите, чтобы ваши дизайнеры путались в вашем исходном коде.
Теперь, пока существуют шаблонные движки, дизайнеры явно просто обожают сходить с ума и CSS позволяет вытягивать гораздо больше трюков, чем таблицы.
Как разработчик, я отказался от CSS Layout в основном потому, что мой дизайн все равно отстой, так что, по крайней мере, он может сосать правильно :-) но если бы я когда-нибудь нанял дизайнера, я бы позволил ему использовать все, что выплевывает его редактор WYSIWYG.
Бизнес-причина для CSS макета: вы можете сдуть клиентов, сказав "our portal is totally customizable/skinnable without writing code!"
Опять же, я не вижу никакого зла в разработке блочных элементов с таблицами. Под блочными элементами я имею в виду те места, где нет никакого смысла разбивать упомянутый элемент на части в разных конструкциях.
Поэтому табличные данные лучше всего представлять в виде таблиц, конечно. Проектирование основных строительных блоков (таких как строка меню, тикер новостей и т. д.) внутри их собственных таблиц также должно быть OK. Просто не полагайтесь на таблицы для общего макета страницы, и вы будете в порядке, я думаю.
*I позволит ему использовать все, что выплюнет его редактор WYSIWYG
Меня просто немного вырвало...
*ahh "привет"? Вы же не думаете, что графический дизайнер пишет CSS от руки?
*I позволит ему использовать все, что выплюнет его редактор WYSIWYG
Меня просто немного вырвало...
*ahh "привет"? Вы же не думаете, что графический дизайнер пишет CSS от руки?
Как ни странно, я работал с несколькими дизайнерами, и лучшие из них делают ручную настройку своих css. Парень, о котором я думаю, на самом деле делает всю свою дизайнерскую работу в виде файла XHTML с парой файлов CSS и создает графические элементы на лету, когда они ему нужны. Он использует Dreamweaver, но только в качестве навигационного инструмента. (Я многому научился у этого парня)
После того, как вы сделали инвестиции, чтобы изучить чисто CSS-ориентированный дизайн и имели небольшой опыт (выяснили, где IE отстой [честно говоря, это становится лучше]), он заканчивается быстрее, чем я нашел. Я работал над системами управления контентом, и приложение редко приходилось менять, чтобы дизайнеры придумали радикально другой внешний вид.
Кроме того, что он легко обновляется и соответствует требованиям...
Я использую для разработки всех веб-сайтов на основе таблиц, и сначала я был устойчив, но мало-помалу я перешел к CSS. Это не произошло в одночасье, но это произошло, и Вы тоже должны это сделать.
Было несколько ночей, когда я хотел выбросить свой компьютер из окна, потому что стиль, который я применял к div, не делал того, что я хочу, но вы учитесь на этих препятствиях.
Что касается бизнеса, как только вы перейдете к проектированию веб-сайтов по CSS вплоть до науки, вы можете разработать процессы для каждого сайта и даже использовать прошлые веб-сайты и просто добавить другой графический заголовок, цвет и т. д.
Кроме того, не забудьте вставить/включить все многоразовые части вашего сайта: заголовок, подзаголовок, нижний колонтитул.
Как только вы перелезете через горб, оттуда все будет идти вниз по склону. Удачи вам!
:: кивает на палмси и Джона Гэллоуэя. ::
Я согласен с фактором ремонтопригодности. Мне действительно требуется немного больше времени, чтобы сделать мои начальные макеты (так как я все еще ученик джедая в искусстве CSS), но сделать полную реконструкцию 15-страничного веб-сайта, просто обновив 1 файл, - это рай.
Некоторые дополнительные причины, почему это хорошая практика:
- Доступность-в идеале веб должен быть доступно для всех
- Производительность-сохранить пропускная способность и более быстрая загрузка на мобильном устройстве устройства (у некоторых из них отсутствует пропускная способность степень и не может быть сложной компоновки таблицы быстро). Кроме того, быстрая загрузка-это всегда хорошо...
Когда screenreader читает страницу и видит таблицу, он сообщает пользователю, что это таблица. Следовательно, если вы используете таблицу для макета, это становится очень запутанным, потому что пользователь не знает, что содержимое таблицы на самом деле является статьей, а не какими-то другими табличными данными
Когда screenreader читает страницу и видит таблицу, он сообщает пользователю, что это таблица. Следовательно, если вы используете таблицу для макета, это становится очень запутанным, потому что пользователь не знает, что содержимое таблицы на самом деле является статьей, а не какими-то другими табличными данными
Это на самом деле не так; программы чтения с экрана, такие как JAWS, Window Eyes и HAL, игнорируют таблицы компоновки. Они очень хорошо справляются с реальной сетью.
Это определенно так. Если вы все еще стремитесь к нему, вы не получаете его правильно.
Компоновка DIV+CSS на самом деле намного проще, чем табличная компоновка, с точки зрения ремонтопригодности и производительности. Просто продолжайте практиковать это, пока еще не слишком рано говорить об этом.
Макет таблицы тоже хорош, он просто не предназначен для макетов и имеет исключительные недостатки, когда речь заходит о незначительной настройке.