Организация Less-файлов

16-08-2012Время чтения ~ 6 мин.CSS, HTML, LESS, SASS 16887

C LESS я начал работать примерно полгода назад, но до сих пор окончательно не определился с наиболее эффективной организацией данных.

С одной стороны LESS - это тот же CSS, только более продвинутый. Следовательно и для less-файлов следует использовать те же принципы. Такой подход - большая ошибка. Мне понадобилось много времени, чтобы это понять и нащупать другое направление, по которому и следует двигаться. Причём я даже не уверен, что это окончательный и самый лучший вариант. :)

LESS на начальном этапе использования

Вначале использования LESS я делал все по образу и подобию CSS. Мне казалось, что следует стремиться сделать как можно меньше кода, использовать сокращения, избегать «бессмысленых» вложений css-правил.

В итоге LESS, конечно же, хоть и упрощает написание кода, но не используется на все 100%.

Постепенно начинаешь понимать, что часть кода строится по единым правилам, и приходит понимание для чего же на самом деле нужны mixins. Для примера, почитайте мою статью «Пример создания универсального LESS-микса для табов (вкладок)».

Потребуется еще некоторое время, чтобы прийти к написанию своего helpers.less. У меня, например, есть миксы для шрифта (размер, цвет, начертание, гарнитура и т.п.), border-radius, внутренняя тень, внешняя, градации, border и т.п.

И вот дальше у меня возник ступор, поскольку все эти вещи лежат на поверхности и понятны всем, а куда двигаться дальше не понятно: LESS ограничился «типовым» использованием CSS.

LESS - это не только CSS

Из CSS мы знаем, что файл стилей должен быть как можно меньше, в нем только используемые правила и следует избегать подключение через @import. Так и я вначале думал и вместо:

div.container {
 
	div.block1 {
	
	}
	
	div.block2 {
    
	}
 }

делал

div.block1 {
 	
}
 	
div.block2 {
    
}

Ведь div.container не содержит стилей, а результирующий css-код второго примера будет проще и короче.

И вот когда я стал «тонуть» в массе безликих div.block1, я понял, что LESS - это не только CSS. Это еще и прекрасная возможность создавать код понятным и ясным.

Первый пример совершенно точно показывает HTML-структуру верстаемого блока. Да, мы получим чуть более объемный результирующий код, который частично нивелируется автоматической «подчисткой» и сжатием LESS-компилятором. То есть выигрыш - мизерный.

Окончательно я в этом убедился, когда сразу несколько моих клиентов в процессе настройки своих сайтов, использовали неоптимизированные изображения для записей и шапки. В самом «легком» случае «прогон» через фотошоп давал не менее 30Кб уменьшение размера файла, а некоторые уменьшались на 100-300Кб! Так стоит ли переживать о лишней паре килобайт css-файла?

Из этого я вывел для себя важное правило: «LESS-код должен быть понятен и удобен в первую очередь для разработчика».

Теперь любое css-правило я начинаю с контейнера блока (конечно, если он есть), а дальше прописываю все его вложенные блоки. Теперь, чтобы сделать стиль уже не нужно лезть в HTML-код и «выцеплять» структуру нужного блока.

Главный less-файл

К этому моменту я пришёл не сразу, хотя в том же Twitter bootstrap - это лежало на поверхности. Идея в том, что всегда существует главный less-файл в котором подключаются остальные.

Важнейшее отличие LESS от CSS в том, что LESS может иметь модульную стуктуру. Если в CSS мы стараемся избегать @import (что порождает дополнительные соединения на сервер), то в LESS - это удобный механизм разделения мессива кода на логические части.

Как именно делить код на файлы решает разработчик. В том же Bootstrap'е это «дизайнерские» элементы.

В MaxSite CMS, и это очевидно, главным будет var_style.less. А подключаемыми будут «функциональные» элементы: плагины, компоненты и т.п.

Оптимальная организация подключаемых файлов

Здесь я тоже долго не мог «нащупать» оптимальный вариант. Изначально у меня был файл plugins.less, где я складировал стили плагинов. Был файл structure.less, где я задавал модульную сетку сайта. Основной файл был var_style.less, в котором я и работал.

И, поскольку всё было в одном файле, то приходилось постоянно «прыгать» от одной строки к другой: правила добавляются практически в произвольном порядке, скажем вначале один блок, потом другой, а третий между ними, поскольку физически он именно так и расположен, хотя добавился позже всех. В редакторе - куча закладок, постоянно пользуешься поиском. Особенно сложно бывает в ситауции, когда верстается сразу несколько соседних (но не по коду!) блоков, например нужно проконтролировать между ними отступы.

После того, как я осознал, что LESS должен быть модульным, ситуация принципиально изменилась. Нужно «бегать» не в одном файле, выискивая требуемое правило, а между less-файлами конкретных блоков.

Далее. Выяснилось, что less-файлы удобней группировать по каталогам, а критерием будет что-то явно выделяющее блок от других. После многочисленных экспериментов родилась такая структура:

• var_style.less - основной файл.
• base.less - базовые стили оформления шаблона. Это переопределенные HTML-тэги, ссылки, заголовки. То есть всё то, что используется в любой части шаблона.
• blocks - каталог для каких-то единичных блоков шаблона. Например comments.less, widgets.less.
• components - здесь стили компонентов, например footer-statistic.less, footer-copyright.less.
• layouts - мой любимы каталог :) потому что здесь хранятся стили разных модульных сеток. Чтобы поменять расположение сайдбара мне нужно лишь указать соответствующий файл layout.
• menus - здесь хранятся готовые стили горизонтальных меню. Я могу выбрать любой наиболее подходящий вариант и подправить под требуемый дизайн (цвета, размеры - то есть мелочевка).
• mixins - хелперы, миксы.
• plugins - здесь хранятся стили плагинов. Например tabs.less, pagination.less. Тут есть один нюанс - виджеты тоже могут здесь хранится, поскольку фактически виджеты это и есть плагины. Именно по этой причине для виджетов нет отдельного каталога, а один базовый less-файл.
• type - Здесь я храню стили для каких-то точно известных страниц. Например вывод главной - home.less, рубрик - caterory.less. Такая организация несколько проще, чем разбивать каждый блок на отдельный файл - по смыслу они все связаны.

Всё это добро подключается в var_style.less, вот примерно так:

@import url('mixins/helpers.less');
@import url('base.less'); 
@import url('layouts/layout01.less'); 
@import url('menus/menu04.less');
@import url('blocks/widgets.less');
@import url('blocks/comments.less');
@import url('plugins/pagination.less'); 
@import url('plugins/tabs.less');
@import url('components/footer-copyright.less'); 
@import url('components/footer-statistic.less');
@import url('type/home.less');
@import url('type/caterory.less');

Если я добавляю новый компонент шапки, то делаю новый less-файл в components и спокойно с ним работаю.

HTML-вёрстка

Моя концепция - Быстрое создание сайтов. Подходил я к ней долго, и на сегодняшний день изьянов так и не нашёл.

Если верстать функциональными блоками, то предлагаемая организация less-файлов прекрасно вписывается в мою гармоничную картину мира концепцию. Вот примерно по такой схеме:

• По дизайну определяем какой будет функциональный блок, например компонент шапки.
• Создаем php-файл компонента с обязательным DIV-контейнером (можно и wrap-блок и div.clearfix для надежности).
• Если компонент состоит из нескольких ячеек/блоков, то делаем для них соответствующие DIV.
• Подключаем компонент (или php-файл) там где нужно в шаблоне. Например в custom/header_components.php.
• Создаем less-файл в components. Описываем в файле html-структуру.
• Задаем стили, согласно дизайна.
• Программируем, если нужно.
• Сохраняем файлы для возможно будущего будущего использвания.

Такой подход проще «традиционного» и на порядок упрощает и ускоряет работу вебмастера.

ps Понравилась статья? Не забудь твитнуть!