Open FMRobot opened 10 years ago
а если red нужно сделать грин, переписывать классы элементам?
Однако, зачастую дублирование названия элемента является избыточным.
Иногда ваш подход может привести к конфликту модификаторов, если вдруг придется к одному блоку примиксовать другой.
Stylus нотация выглядит привлекательнее
"а если red нужно сделать грин, переписывать классы элементам?" - пример очень плохой, в реальном проекте лучше использовать более абстрактные имена классов:
button--red => button--alert Тогда при замене красного на берюзовый не будет никаких проблем в виде переписывания классов у кнопок
Обратите внимание на то, что автор не призывает использовать классы вида .button--red
. Он использует селектор-плейсхолдер %
в SASS, чтобы затем включить свойства с помощью @extend
и получить .button--delete
.
Как мне кажется это просто раздувание sass файла, на каждый чих отдельный плейсхолдер, на каждый чих отдельный модификатор... В итоге в большом проекте мы получаем мешанину в которой ну очень просто запутаться, а это уже конфликт с идеологией БЭМа
Мы к такой же идее пришли в 2013 году: https://github.com/ideus-team/guidelines/blob/master/frontend/bem.md
Внутренние Sass-селекторы вида %модификатор - это Sass реализация абстрактных блоков BEM (i-блоков). Это BEM, нет никакого БЭВМ.
%i-block {
// стили абстрактного блока
}
.b-block {
@extend %i-block;
}
Чуть больше Stylus для (БЭ)Модификаторов в классической нотации #b_ http://codepen.io/ilyar/pen/qERXjM
Пришёл к тому, что абстрактные классы #b_ CSS в Sass всё же лучше реализовывать через mixin+include, а не %extend-only-selector+extend
@mixin i-block {
// стили абстрактного блока
}
.b-block {
@include i-block;
}
Проблема extend в том что бывают ситуации, когда создать экземпляр класса на основе абстрактного блока или очень сложно (класс вложен в другой класс — extend нужно выносить за пределы скобок, на самый верх, иначе он включит в себя лишний каскад) или невозможно (media queries).
Опять-таки раз мы и так реализуем все связи и зависимости через язык высокого уровня (Sass), то нам нет нужны поддерживать связность силами CSS (когда на выходе классы перечисляются через запятую) и логично чтоб и тут её не было.
Да и Harry Roberts одобряет http://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/ ведь „Repetition in a compiled system is not a bad thing: repetition in source is a bad thing.“
Примеры: 1) Через mixin+include (работает):
.b-form {
@mixin i-styledElement {
/* styles for form element… */
}
input {
@include i-styledElement;
height: 56px;
}
.mobile &__item.-styled select {
/* styled select on mobiles */
appearance: none;
@include i-styledElement;
}
}
Компилируется в
.b-form input {
/* styles for form element… */
height: 56px;
}
.mobile .b-form__item.-styled select {
/* styled select on mobiles */
appearance: none;
/* styles for form element… */
}
2) Через %extend-only-selector+extend (не работает)
.b-form {
%i-styledElement {
/* styles for form element… */
}
input {
@extend %i-styledElement;
height: 56px;
}
.mobile &__item.-styled select {
/* styled select on mobiles */
appearance: none;
@extend %i-styledElement;
}
}
Компилируется в:
.b-form input, .b-form .mobile .b-form__item.-styled select, .mobile .b-form__item.-styled .b-form select {
/* styles for form element… */
}
.b-form input {
height: 56px;
}
.mobile .b-form__item.-styled select {
/* styled select on mobiles */
appearance: none;
}
Сравните.
Код от mixin+include меньше и аккуратней.
Обратите внимание — extend вставляет класс родительского блока (.mobile .b-form__item.-styled .b-form select) при создании нового элемента на основе %i-блока, т.к. код %i-блока находится внутри родительского класса (.b-form
). Этот пример заработает только если %i-блок вынести за пределы b-form. А если мы будет создавать элемент внутри media querie то вообще ничего не поможет — extend там не работает.
button--red
Ох, очень семантичное имя класса, супер!