В этом посте я приведу пример организации стилей на типичном проекте.
Небольшое вступление, попробую объяснить актуальность проблемы и зачем это нужно.
Рассмотрим такую ситуацию. Разработчику ставят задачу, реализовать очередной функционал на сайте. Это допустим включает добавление новых разделов, блоков, элементов. Разработчики зачастую не доверяют чужому коду, и когда доходят до верстки, находят css-файл с названием типа main.css и дописывают в конец свои новые стили.
Проходит некоторое время, приходит новый разработчик, ему ставят подобную задачу, он если и пытается разобраться в стилях, то видит, что там нет никакой закономерности, и повторяет то же, что делали предыдущие.
Руководство ставит сроки, разрабатывается все новый и новый функционал, проект растет. В итоге css файлы превращаются в мусорку, сайт грузится дольше, появляется больше дефектов и т.д..
Я думаю, многим это знакомо.
Теперь поговорим непосредственно о самой структуризации стилей.
Держать все стили в одном файле неразумно, со временем в нем довольно сложно становится ориентироваться. Плюс на каждой странице используются около 10% правил из этого файла, а весит он не мало.
Гораздо оптимальнее разделять стили по логическим блокам сайта.
Так же к проекту необходимо подключить библиотеку для работы с css (LESS, SASS, SCSS). Нам понадобится работа с переменными, функциями.
Для уменьшения запросов на сервер необходима сборка файлов. Файлы должны склеиваться по специальной конструкции, можно, например, использовать стандартную констукцию css — import. Здесь возможно потребуется помощь разработчика для редактирования исходников выбранной вами библиотеки css.
Плюс, для уменьшения объема, файлы должны приходить клиенту сжатые. dotLess, например, сжимает файлы при значении
Каждому логическому блоку будет соответствовать отдельный css файл. Так упрощается поддержка, поиск нужных стилей, да и вообще ориентация в файлах. Все данные файлы являются исходниками, будем содержать их в папке /css/sources/. Остальные css-файлы — сборщики, они линкуются на страницы и собирают импортом исходники.
Допустим рассматриваемый проект это некая соцсеть, исходя из этого можно выделить следующую структуру:
/css
/sources — папка для ресурсов, не выкладывается на сервер
/global-vars — файлы данной папки подключаются в каждый css-файл сборщик по мере необходимости
locals.css — глобальные переменные
functions.css — глобальные функции
/common
reset.css — думаю, объяснять не нужно, понятно, что за стили
utils.css — стили типа .clearfix
/content
base.css — основные стили для контента, а именно — h1-h6, p, буллиты для списков (ul.text, ul.dashed и т.д.), dl, dd, dt, изображения и панели в тексте (обтекание текстом), текстовые колонки и т.д.
panels.css — различные панели
tables.css — стили для таблиц в контенте (th, черезполосица)
/controls
buttons.css — виды кнопок
forms.css — общие стили для input-полей (к примеру, внутренняя тень, фокус (рамка), оформление валидационных сообщений и их скрытие по умолчанию)
tabs.css — табы, вкладки
system-notifications.css — системные сообщения, как правило бывают 3-х типов: success (зеленые), failure (красные) и info (серые, синие)
pager.css — пейджер
banners.css — баннеры на сайте
balloons.css — всякие баллуны, всплывающие подсказки, кастомные тултипы и т.д.
/member
thumb.css — аватарка пользователей
card.css — карточка пользователя (аватарка, имя, краткие данные)
cards-list.css — например, грид с карточками
profile.css — профиль пользователя
/modules — различные модули к сайту
search.css
news-list.css
gifts.css
games.css
/not-auth — для неавторизованных пользователей
login.css — форма авторизации
registration.css — форма регистрации
/auth — для авторизованных пользователей
my-account.css
mail-system.css — inbox сообщения, outbox и т.д.
auth-menu.css — меню навигации в авторизованной зоне
my-profile.css — просмотр своего профайла, редактирование
/layouts
common.css
header.css
top-menu.css
footer.css
overlay.css — например, все всплывающие поверх слои будут с затемнением 0.5
main.css — основной сборщик, линкуется на всех мастер-страницах
/layouts
default.css — основной layout сайта, собирает файлы из папки /layouts, подключается на мастере с основным layout'ом
popup-windows.css — стили для popup’ов, подключается на мастер-страницах для popup окон
not-auth.css — собирает стили из папки /sources/not-auth/
auth.css — собирает стили из папки /sources/auth/
/themes — различные тематики сайта
new-year.css
st-valentine.css
/%section-name% — какой-нибудь новый раздел сайта, «сайт в сайте», характерный наличием своего подменю и т.д.
/css
%section-name%.css
layout.css
/sources
menu.css
Конечно же для каждого проекта своя уникальная структура. Важен принцип разделения файлов.
Дополнительное описание к некоторым файлам:
main.css — собирает файлы из папок:
/sources/global-vars
/sources/common
/sources/content
/sources/controls
/sources/member
/sources/modules
functions.css — содержит глобальные функции, типа:
sources/layouts/common.css — глобальные стили по layout'у:
Подключение файлов not-auth.css и auth.css зависит от состояния авторизации пользователя. Например, в asp.net это будет выглядеть так:
Хочу привести концепцию, которой, я считаю, следует держаться.
Новые страницы должны строиться из компонентов, «кирпичиков» — css классов. Некоторые неверно понимают данную концепцию и строят страницу из классов типа mar-bottom-15, float-left или pad-20, что тоже является большой ошибкой.
На всем сайте должен сохраняться единый стиль элементов, т.е. заголовок h1 на одной странице должен выглядеть так же, как и h1 на другой. Заголовки, абзацы, списки, панели, табы, пейджеры, контентные таблицы и т.д. по дизайну должны соблюдать единый стиль.
Перед тем как писать стили для новой страницы сайта следует проанализировать уже существующие css-файлы проекта, возможно там уже есть необходимые стили. Css файл не должен увеличиваться без необходимости.
В заключении скажу, что все описанное выше так же актуально и для JS.
Небольшое вступление, попробую объяснить актуальность проблемы и зачем это нужно.
Рассмотрим такую ситуацию. Разработчику ставят задачу, реализовать очередной функционал на сайте. Это допустим включает добавление новых разделов, блоков, элементов. Разработчики зачастую не доверяют чужому коду, и когда доходят до верстки, находят css-файл с названием типа main.css и дописывают в конец свои новые стили.
Проходит некоторое время, приходит новый разработчик, ему ставят подобную задачу, он если и пытается разобраться в стилях, то видит, что там нет никакой закономерности, и повторяет то же, что делали предыдущие.
Руководство ставит сроки, разрабатывается все новый и новый функционал, проект растет. В итоге css файлы превращаются в мусорку, сайт грузится дольше, появляется больше дефектов и т.д..
Я думаю, многим это знакомо.
Теперь поговорим непосредственно о самой структуризации стилей.
Держать все стили в одном файле неразумно, со временем в нем довольно сложно становится ориентироваться. Плюс на каждой странице используются около 10% правил из этого файла, а весит он не мало.
Гораздо оптимальнее разделять стили по логическим блокам сайта.
Так же к проекту необходимо подключить библиотеку для работы с css (LESS, SASS, SCSS). Нам понадобится работа с переменными, функциями.
Для уменьшения запросов на сервер необходима сборка файлов. Файлы должны склеиваться по специальной конструкции, можно, например, использовать стандартную констукцию css — import. Здесь возможно потребуется помощь разработчика для редактирования исходников выбранной вами библиотеки css.
Плюс, для уменьшения объема, файлы должны приходить клиенту сжатые. dotLess, например, сжимает файлы при значении
<dotless minifyCss="true" cache="false"/> в web.config.Каждому логическому блоку будет соответствовать отдельный css файл. Так упрощается поддержка, поиск нужных стилей, да и вообще ориентация в файлах. Все данные файлы являются исходниками, будем содержать их в папке /css/sources/. Остальные css-файлы — сборщики, они линкуются на страницы и собирают импортом исходники.
Допустим рассматриваемый проект это некая соцсеть, исходя из этого можно выделить следующую структуру:
/css
/sources — папка для ресурсов, не выкладывается на сервер
/global-vars — файлы данной папки подключаются в каждый css-файл сборщик по мере необходимости
locals.css — глобальные переменные
functions.css — глобальные функции
/common
reset.css — думаю, объяснять не нужно, понятно, что за стили
utils.css — стили типа .clearfix
/content
base.css — основные стили для контента, а именно — h1-h6, p, буллиты для списков (ul.text, ul.dashed и т.д.), dl, dd, dt, изображения и панели в тексте (обтекание текстом), текстовые колонки и т.д.
panels.css — различные панели
tables.css — стили для таблиц в контенте (th, черезполосица)
/controls
buttons.css — виды кнопок
forms.css — общие стили для input-полей (к примеру, внутренняя тень, фокус (рамка), оформление валидационных сообщений и их скрытие по умолчанию)
tabs.css — табы, вкладки
system-notifications.css — системные сообщения, как правило бывают 3-х типов: success (зеленые), failure (красные) и info (серые, синие)
pager.css — пейджер
banners.css — баннеры на сайте
balloons.css — всякие баллуны, всплывающие подсказки, кастомные тултипы и т.д.
/member
thumb.css — аватарка пользователей
card.css — карточка пользователя (аватарка, имя, краткие данные)
cards-list.css — например, грид с карточками
profile.css — профиль пользователя
/modules — различные модули к сайту
search.css
news-list.css
gifts.css
games.css
/not-auth — для неавторизованных пользователей
login.css — форма авторизации
registration.css — форма регистрации
/auth — для авторизованных пользователей
my-account.css
mail-system.css — inbox сообщения, outbox и т.д.
auth-menu.css — меню навигации в авторизованной зоне
my-profile.css — просмотр своего профайла, редактирование
/layouts
common.css
header.css
top-menu.css
footer.css
overlay.css — например, все всплывающие поверх слои будут с затемнением 0.5
main.css — основной сборщик, линкуется на всех мастер-страницах
/layouts
default.css — основной layout сайта, собирает файлы из папки /layouts, подключается на мастере с основным layout'ом
popup-windows.css — стили для popup’ов, подключается на мастер-страницах для popup окон
not-auth.css — собирает стили из папки /sources/not-auth/
auth.css — собирает стили из папки /sources/auth/
/themes — различные тематики сайта
new-year.css
st-valentine.css
/%section-name% — какой-нибудь новый раздел сайта, «сайт в сайте», характерный наличием своего подменю и т.д.
/css
%section-name%.css
layout.css
/sources
menu.css
Конечно же для каждого проекта своя уникальная структура. Важен принцип разделения файлов.
Дополнительное описание к некоторым файлам:
main.css — собирает файлы из папок:
/sources/global-vars
/sources/common
/sources/content
/sources/controls
/sources/member
/sources/modules
functions.css — содержит глобальные функции, типа:
.rounded-corners(@radius)
{
border-radius: @radius;
-moz-border-radius: @radius;
-webkit-border-radius: @radius;
*behavior: url(/libs/progressive-IE.htc);
}
sources/layouts/common.css — глобальные стили по layout'у:
.columns-wrapper
{
display: table;
*zoom: 1;
}
.columns-wrapper .column
{
display: table-cell;
*float: left;
}
Подключение файлов not-auth.css и auth.css зависит от состояния авторизации пользователя. Например, в asp.net это будет выглядеть так:
<asp:LoginView runat="server">
<AnonymousTemplate>
<link href="/css/not-auth.css" rel="stylesheet" type="text/css" />
</AnonymousTemplate>
<LoggedInTemplate>
<link href="/css/auth.css" rel="stylesheet" type="text/css" />
</LoggedInTemplate>
</asp:LoginView>
* This source code was highlighted with Source Code Highlighter.Хочу привести концепцию, которой, я считаю, следует держаться.
Новые страницы должны строиться из компонентов, «кирпичиков» — css классов. Некоторые неверно понимают данную концепцию и строят страницу из классов типа mar-bottom-15, float-left или pad-20, что тоже является большой ошибкой.
На всем сайте должен сохраняться единый стиль элементов, т.е. заголовок h1 на одной странице должен выглядеть так же, как и h1 на другой. Заголовки, абзацы, списки, панели, табы, пейджеры, контентные таблицы и т.д. по дизайну должны соблюдать единый стиль.
Перед тем как писать стили для новой страницы сайта следует проанализировать уже существующие css-файлы проекта, возможно там уже есть необходимые стили. Css файл не должен увеличиваться без необходимости.
В заключении скажу, что все описанное выше так же актуально и для JS.
