Миксы достаточно универсальны. В простом варианте - это готовый набор css-правил. В более сложном случае - это параметизированные примеси, по сути - функции. Для новичков не сразу понятна разница, хотя они имеют принципиальные отличия: первый вариант по сути copy-paste. Второй - функция, принимающая аргументы и имеющая более сложный алогритм вывода.

Рассмотрим основные отличия этих видов.

Copy-Paste

Простые миксы выводятся так, как они заданы.

.border_radius {
    -webkit-border-radius: 5px;
    -moz-border-radius: 5px;
    border-radius: 5px;
}
 
// используем 
h1 {
	.border_radius;
}

То есть для H1 пропишется всё, что указано в .border_radius. С практической точки зрения микс предназначен только для быстрой вставки различных «заготовок» css-классов.

Недостатки простых миксов

У таких миксов есть несколько недостатков, один из главных - микс целиком попадает в результирующий css-код. По сути такие миксы равны обычным css-правилам, поэтому компилятор не может их отличить.

Предыдущий пример приведёт вот к такому результату:

.border_radius {
  -webkit-border-radius:5px;
  -moz-border-radius:5px;
  border-radius:5px;
}
h1 {
  -webkit-border-radius:5px;
  -moz-border-radius:5px;
  border-radius:5px;
}

То есть вначале вывелся сам микс (компилятор посчитал его обычным css-правилом), а после еще раз, но уже как функция-микс.

К счастью проблема решается очень просто - нужно использовать параметизированные примеси, превращаяя «примесь» в аналог функции.

Микс как функция

Чтобы микс стал функцией при его написании нужно указать скобки. Сравним два примера.

.border_radius {
    border-radius: 5px;
}
 
// используем 
h1 {
    .border_radius;
}

// результат
.border_radius { border-radius:5px; }
h1 { border-radius:5px; }

То есть мы получили и .border_radius и h1. Добавим в микс скобки.

.border_radius() {
    border-radius: 5px;
}
 
// используем 
h1 {
    .border_radius;
}

// результат
h1 { border-radius:5px; }

Остался только h1, а класс .border_radius исчез из конечного результата.

Наборы правил для множества тэгов

Пусть у нас есть некий HTML-каркас для какого-либо своего блока шаблона. Это может быть слайдер, меню, виджет или какая-то заготовка из предопределенных тэг.class. При верстке очень часто встречаются такие блоки, где часть css-правил кочует от шаблона к шаблону.

Скажем плагин облака рубрик имеет такие стили:

// plugin CatClouds
div.catclouds {
	text-align: center;
	
	span {
		line-height: 1.4em;
	}
}

Данные правила практически никогда не меняются, но, для правильной работы плагина, необходимы в каждом шаблоне. Таким образом проще всего сделать микс, который и выполнит вставку этих правил.

// микс
.mix_catclouds() {
	text-align: center;
	
	span {
		line-height: 1.4em;
	}
}
 
// используем
div.catclouds {
	.mix_catclouds;
}

То есть в миксе можно указывать сколько угодно вложенных правил.

Этот подход можно использовать для решения задач, где есть уже какие-то предопределённые условия. Например можно придумать набор правил для модульной сетки сайта. Мы знаем, что сетка задаётся в main.php и содержит фиксированный HTML для базовых div-блоков. Один микс может выводить сетку для левого сайдбара, второй - правого. Как-то так:

.left_sidebar()
{
	div.content {
		float: right;
	}

	div.sidebar1 {
		float: left;
	}
}

.right_sidebar()
{
	div.content {
		float: left;
	}

	div.sidebar1 {
		float: right;
	}
}
 
//используем 
.right_sidebar; // правый 
 
// или  для левого
// .left_sidebar;

Сравнение вёрстки css-фреймворком и less

CSS-фреймворки содержат наборы предопределенных правил. Поэтому, если верстальщик решит использовать фреймворк в своей работе, то ему нужно переделывать HTML-код, прописывая css-классы фреймворка. То есть при использовании любого css-фреймворка верстальщику никуда не отвертеться от того, чтобы лезть в HTML-код и править его под себя.

Удобно ли это? Вряд ли. Тем более, есть такой HTML-код, к которому добраться будет проблематично. Например в MaxSite CMS type-файлы имеют своё именование и каждый раз менять, да еще и поддерживать правки при каждом обновлении системы... Бр-р-р-р-р...

С LESS подход диаметрально противоположный. Есть произвольные HTML-тэги. В less-файле подготавливаются миксы и подставляются под нужный тэг. Нет никакой необходимости лезть в исходные HTML-файлы - вся вёрстка целиком перемещается в less-файл. Удобно? Однозначно!

Миксы в миксах

Это следующий этап, превращающий микс из простой функции в целые классы функций. Вот пример такого микса:

.font()
{
    .verdana()
    {
        font-family: Verdana, Arial, Helvetica, sans-serif; 
    }
    
    .arial()
    {
        font-family: Arial, Helvetica, Verdana, sans-serif; 
    }
    
    .georgia()
    {
        font-family: Georgia, "Times New Roman", serif; 
    }
    
    .times()
    {
        font-family: "Times New Roman", Georgia, serif; 
    }
}

Видно, что в нём микс в миксе. Для вызова такого микса следует использовать символ « > ».

.font > .arial;
.font > .verdana;
.font > .times;
.font > .georgia;

Удобен данный подход тем, что в миксах можно подготовить самые разные наборы, которые будут логически сгруппированы и удобны для использования (с точки зрения верстальщика, конечно же).

Подобным образом можно сгруппировать и наборы сложных css-правил. Например горизонтальное меню помимо некоего базового комплекта правил, может содержать подмиксы, управляющие цветом только определенной группы: верхние пункты, выпадающие, основной контейнер:

.menu > .base();
.menu > .container();
.menu > .top();
.menu > .down();

Аргументы миксов

Аргументы превращают миксы в полноценные функции. Думаю, нет смысла рассказывать об основах переменных и аргументах, поскольку это азы LESS, но вот остановиться на некоторых нюансах стоит.

Прежде всего нужно учитывать, что агрументы миксов это не просто агрументы, но еще и «переключатели». Возможны ситуации, когда микс не сработает из-за неверно объявленной функции. При этом объявлением микса будет не только его имя (то, что до скобок), но и скобки и их аргументы. То есть одноименных миксов-функций может быть множество!

.color() {
	color: red;
}
 
.color(@a) {
	color: @a;
}
 
.color(@a: green) {
	color: @a;
}

Используем:

h1 {
	.color;
}

Какого цвета будет H1? Зеленый. Потому что получится вот такой css-код:

h1 {
  color:red;
  color:green;
}

• Первый микс сработал потому что мы вызвали .color без аргументов.
• Второй микс не сработал, потому что при вызове .color должен быть обязательный аргумент, который мы не указали.
• Третий сработал, потому что у микса задан дефолтный аргумент.

h1 {
	.color(blue);
}
 
// результат
h1 {
  color:blue;
  color:blue;
}

Это сработали второй и третий миксы.

Далее. У миксов в аргументах можно не указывать переменные. Это несколько непривычно и называется «совпадение с шаблоном». Например есть два микса .sibebar, один из них размещает сайдбар слева, другой справа.

.sibebar(left)
{
	...
}
 
.sibebar(right)
{
	...
}

Для левого сайдбара используем:

.sibebar(left);

Для правого

.sibebar(right);

В данном примере left и right, переключатели, согласно которым будет срабатывать тот или иной микс. Причем отмечу, что «переключатель» может свободно комбинироваться с другими аргументами, например так:

.sibebar(left, @width: 270px)
{
	...
}
 
// используем
.sibebar(left, 250px);

А по-русски можно?

Можно! Об этом знают даже не все опытные верстальщики. В LESS нет жестких правил именования! Посмотрите несколько примеров.

красный() {
	color: red;
}
 
// используем
h1 {
	красный;
}

Ещё.

цвет() {
	красный() {
		color: red;
	}
	
	синий() {
		color: blue;
	}
}
 
// используем
h1 {
	цвет > красный;
}
  
h2 {
	цвет > синий;
}

А вот с переменными придется задавать строго с «@» и по-англиский. Ругается компилятор. :blank:

текст() {
	жирный(@bold: bold) {
		font-weight: @bold;
	}
	
	цвет(@color){
		color: @color;
	}
}
 
// используем
h1 {
	текст > цвет(green);
	текст > жирный(bold);
}

Так что при желании можно верстать и «по-русски». :lol: Ну или как минимум убрать ведущие точки в именах миксов. :coolsmirk: