@extend в SASS. Когда пора остановиться — 2?

Question

[rtfm mftr]

Насколько оправдано в SASS строить конструкции типа

%background-gold
  background-color: gold

После чего делать @extend в совершенно разных элементах - кнопках, заголовках, ссылках, абзацах, формах? То есть как бы писать весь CSS-файл не "вокруг" селекторов, а "вокруг" правил. К примеру, изучили макет, видим что цвет фона всех элементов дизайна может принимать только три значения и получаем что-то типа

.btn--twitter, .link--nav, .label--feedback.. //еще сто элементов
  { background-color: white }
.btn--submit, .link--outer, .label--subscribe.. //еще сто элементов
 { background-color: black }
.btn--reset, .link--readmore, .label--textarea.. //еще сто элементов
 { background-color: gold }

То есть в итоговом CSS-файле будет много повторений элементов в групповых селекторов, кроме того их правила будут разнесены по разным местам(но не в исходном SASS-файле, где структура остается четкой). Но при этом сами правила вообще ни разу не будут повторяться.
Для каких правил, с каким количеством значений и каким набором расширяющих элементов использовать extend разумно?

Answer 1

[Александр]

Я обычно выношу в переменные коды цветов (типа $face: #face8d). Это удобное расширение для именования тех цветов, CSS-имён у которых нет. Плюс ещё и в том, что $face можно применить и для bg, и для color, и ещё много для чего. Иначе вы сами себя делаете заложником своего же кода.
И сто элементов писать не нужно в одну строку — этим компилятор займётся.
Хорош тот CSS, который не нужно много скроллить, чтобы внести пару изменений =)

Comments

[rtfm mftr]

Это немного не про то. Значения свойств можно вынести в переменные, я так и делаю, но тут вопрос в другом, что лучше
.кнопка {color: $face}
.ссылка {color: $face}
.заголовок {color: $face}
.инпут {color: $face}
или
.кнопка, .ссылка, заголовок, .инпут
{color: $face}
CSS-файл при этом будет плохо читаем, но SASS-файл напротив весьма четко стркутурирован

Answer 2

[Алексей Николаев]

Присоединяюсь к ответившим выше, и добавлю, что extend - не тот инструмент, который стоит использовать повсеместно. В итоговом коде extend будет группировать все селекторы, в которых был вызван другой селектор, и дописывать их. Например,

.selector-1, .selector 2 .selector-3, .selector-4 {
    display:block;
}

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

Comments

[rtfm mftr]

Ну по идее 2 и больше правила уже будут длиннее чем имя селектора и размер css только уменьшится

Answer 3

[Алексей Струков]

Все это конечно хорошо, но только надо учесть несколько моментов. Во первых, при использовании extend наши правила при трансляции в css будут записываться в тот селектор, который мы расширяем, а не в то место, где мы его пишем в scss файле, что может вызвать некоторые проблемы. Например мы хотим переопределить цвет элемента и если сделать это через extend, то есть вероятность что ничего не получится, так как правила extend находятся обычно в начале кода, а остальные правила следуют уже дальше, и если у нас гдето есть селектор, который задает цвет нашему элементу, то сначала применятся правила из extend, а потом снова то значение цвета, что определено далее по коду. Тут надо хорошо проектировать, чтобы случайно не запутаться в этих правилах и чтобы одно не переопределяло другое.
Во вторых, надо помнить о том, что extend не работает внутри медиа запросов, так как там другая область видимости, так что придется либо дублировать все миксинами, либо просто писать обычный css код внутри медиазапросов.