В октябре я расскажу на Web Directions South 2009 в Сиднее о CSS Frameworks . Один из основных вопросов, на которые я отвечу в своем выступлении, заключается в том, следует ли использовать CSS Framework в каком-либо конкретном проекте. Поскольку альтернативой является написание ваших собственных стилей CSS с нуля, я исследую некоторые из последних идей о CSS с ручной кодировкой.
Николь Салливан , известный разработчик в этой области, разработал методологию, которая называется « Объектно-ориентированный CSS» (OOCSS). Она рассказала об этом подходе к написанию CSS на веб-сайтах North 2009, и доступно 48-минутное видео .
Салливан — талантливый и привлекательный ведущий, но я нашел видео, в которое можно было бы сразу вложить все. После его просмотра я применил принципы OOCSS к внутреннему проекту здесь, в SitePoint, и я чувствую, что лучше понимаю, о чем все это.
Изменение перспективы
Просто еще одна структура? Думайте по-крупному: «OOCSS на самом деле не фреймворк… а способ написания масштабируемого, разумного, поддерживаемого CSS», — пишет Салливан . Салливан использует и рекомендует сеточную инфраструктуру, такую как Yahoo! YUI Grids , но вы можете писать стили макета с нуля, используя принципы OOCSS, если это ваша задача. Но OOCSS в равной степени относится и к работе, которую вы выполняете после реализации макета сайта, когда вы создаете блоки и контент, которые вставляются в ваш макет.
Большинство веб-дизайнеров склонны писать код CSS так, чтобы он требовал как можно меньше дополнительной разметки (теги <div><span>class По сути, внедрение OOCSS делает умственный переход к простому обслуживанию и повторному использованию ваших стилей, даже если это означает написание дополнительной разметки HTML.
Методологии OOCSS помогут вам выйти за рамки ваших непосредственных целей проектирования и упорядочить свой код, так что добавление нового содержимого сайта, использующего те же стили в будущем, станет тривиальным. При использовании OOCSS добавление страницы нового типа на ваш сайт должно означать, что нет необходимости создавать дополнительные стили или селекторы CSS. Новые типы страниц должны максимально использовать существующие стили CSS.
При разработке сайта с использованием OOCSS вы должны разбить свой дизайн на повторно используемые компоненты, которые OOCSS называет объектами . Каждый компонент представляет собой фиксированную структуру HTML, к которой вы применяете набор правил CSS, которые управляют его макетом (на языке OOCSS, структуру ), и другой набор правил CSS, которые управляют его внешним видом ( оболочкой ). Затем этот компонент может содержать произвольное содержимое HTML: абзацы, списки, таблицы и т. Д., Каждый из которых стилизован независимо от контейнера, в котором он появляется.
Этот последний пункт имеет решающее значение. В OOCSS вы должны избегать того, что Sullivan называет «селекторами на основе определения местоположения», то есть стилями, которые по-разному влияют на контент, в зависимости от того, на какой части вашего сайта он отображается. Если вы хотите, например, чтобы список выглядел по-другому в определенной части вашего сайта, вы должны добавить к нему атрибут class Это гарантирует, что список может быть поднят и повторно использован в другом месте на сайте, при этом его стиль остается неизменным.
Пример в коде
Допустим, каждая страница вашего сайта имеет боковую панель, код которой выглядит следующим образом:
<div class="sidebar">
…sidebar content…
</div>
Теперь, допустим, у вас был набор страниц, на которых вы хотели, чтобы эта боковая панель была немного по-другому — скажем, с другим цветом фона, чтобы выделить продажу определенных товаров. Возможно, вы также захотите внести изменения в некоторые другие элементы этих страниц из-за этой продажи.
Традиционно ваш подход к этому может заключаться в добавлении класса в тег <body>
<body class="onsale">
«Блестящий!», Подумаете вы. «Теперь я могу внести все свои корректировки стиля для этой продажи, не внося никаких дополнительных изменений в мой HTML-код!» Затем вы приступите к написанию набора правил стиля, подобных этому:
body.onsale .sidebar {
background-color: #FFA500;
}
Подход, рекомендуемый объектно-ориентированным CSS, совершенно другой. Вместо одного класса, примененного к body Вот как может выглядеть стиль продажи боковой панели:
.onsalesidebar {
/* extends .sidebar */
background-color: #FFA500;
}
Говорят, что этот класс расширяет существующий класс, который описывает стандартный стиль для элемента. Затем вы применяете его в дополнение к существующему (базовому) классу:
<div class="sidebar onsalesidebar">
…sidebar content…
</div>
Теперь редактор контента может уверенно копировать и вставлять этот код боковой панели на другую страницу вашего сайта или даже на совершенно новую страницу и знать, что он будет отображаться с применением тех же стилей. Те же принципы применяются к оформлению содержимого в пределах этой боковой панели.
Рекомендации для OOCSS фактически рекомендуют значительно более сложную структуру HTML для таких многократно используемых компонентов, которые позволяют применять к ним более сложные стили, включая закругленные углы и эффекты границ, но этот простой пример эффективно демонстрирует фундаментальные принципы, лежащие в основе OOCSS.
В чем смысл?
Салливан работает в Yahoo, где ее основной задачей является повышение производительности веб-сайта. Помимо многократного использования копируемых и вставляемых стилей HTML-контента и блоков компонентов, OOCSS утверждает, что предлагает значительные преимущества в производительности.
Приоритезируя повторное использование стилей CSS на вашем сайте, OOCSS приводит к значительно меньшим CSS-файлам, но немного большим HTML-файлам. Этот компромисс желателен, поскольку размер ваших CSS-файлов напрямую влияет на время, в течение которого браузер отображает пустую страницу во время загрузки вашего сайта. Меньший CSS означает меньше времени, затрачиваемого на просмотр пустой страницы. Как только ваш CSS загрузится, HTML-контент вашего сайта будет отображаться постепенно по мере загрузки. Таким образом, результатом этого компромисса является более высокая воспринимаемая производительность, даже если общее время загрузки немного больше.
Кроме того, избегая селекторов на основе определения местоположения, вы уменьшаете объем работы, которую должен выполнять браузер, чтобы определить фактическое отображение любого элемента на странице. Особенно в мобильных браузерах, но даже на настольных компьютерах это может значительно повысить производительность.
Стоит ли оно того?
Если вам повезло, что вы являетесь единственным разработчиком внешнего интерфейса, работающим над проектом, вы можете использовать принципы OOCSS. Однако преимущества OOCSS в том, что касается повторного использования, действительно проявляются при работе в командной среде.
Старшие дизайнеры внешнего интерфейса могут определить многократно используемые структуры для сайта. Визуальные дизайнеры могут применять привлекательные скины CSS к этим структурам. Редакторы контента могут с уверенностью писать контент, который вставляется в эти структуры, зная, что только тот стиль, который они ожидают, будет применен к контенту, который они пишут.
Однако убедить всю команду прыгнуть на борт OOCSS может быть значительным мероприятием, и именно в этом я нахожусь здесь, в SitePoint. Применив принципы OOCSS к небольшому проекту самостоятельно, теперь я должен решить, стоит ли доводить это до команды разработчиков SitePoint.
Как вы думаете? Означают ли преимущества OOCSS дополнительную дисциплину, необходимую для его внедрения, или CSS уже достаточно сложен?