Комментарии #1

Open
FMRobot opened this Issue Feb 6, 2014 · 11 comments

Comments

Projects
None yet
10 participants
@FMRobot
Member

FMRobot commented Feb 6, 2014

No description provided.

@alexeyraspopov

This comment has been minimized.

Show comment
Hide comment
@alexeyraspopov

alexeyraspopov Feb 28, 2014

button--red

Ох, очень семантичное имя класса, супер!

button--red

Ох, очень семантичное имя класса, супер!

@pvpshoot

This comment has been minimized.

Show comment
Hide comment
@pvpshoot

pvpshoot Feb 28, 2014

а если red нужно сделать грин, переписывать классы элементам?

а если red нужно сделать грин, переписывать классы элементам?

@zenwalker

This comment has been minimized.

Show comment
Hide comment
@zenwalker

zenwalker Feb 28, 2014

Однако, зачастую дублирование названия элемента является избыточным.

Иногда ваш подход может привести к конфликту модификаторов, если вдруг придется к одному блоку примиксовать другой.

Однако, зачастую дублирование названия элемента является избыточным.

Иногда ваш подход может привести к конфликту модификаторов, если вдруг придется к одному блоку примиксовать другой.

@awinogradov

This comment has been minimized.

Show comment
Hide comment
@awinogradov

awinogradov Mar 2, 2014

Stylus нотация выглядит привлекательнее

Stylus нотация выглядит привлекательнее

@MrFranke

This comment has been minimized.

Show comment
Hide comment
@MrFranke

MrFranke Mar 5, 2014

"а если red нужно сделать грин, переписывать классы элементам?" - пример очень плохой, в реальном проекте лучше использовать более абстрактные имена классов:

button--red => button--alert
Тогда при замене красного на берюзовый не будет никаких проблем в виде переписывания классов у кнопок

MrFranke commented Mar 5, 2014

"а если red нужно сделать грин, переписывать классы элементам?" - пример очень плохой, в реальном проекте лучше использовать более абстрактные имена классов:

button--red => button--alert
Тогда при замене красного на берюзовый не будет никаких проблем в виде переписывания классов у кнопок

@smolnikov

This comment has been minimized.

Show comment
Hide comment
@smolnikov

smolnikov Mar 5, 2014

Contributor

Обратите внимание на то, что автор не призывает использовать классы вида .button--red. Он использует селектор-плейсхолдер % в SASS, чтобы затем включить свойства с помощью @extend и получить .button--delete.

Contributor

smolnikov commented Mar 5, 2014

Обратите внимание на то, что автор не призывает использовать классы вида .button--red. Он использует селектор-плейсхолдер % в SASS, чтобы затем включить свойства с помощью @extend и получить .button--delete.

@mikaspell

This comment has been minimized.

Show comment
Hide comment
@mikaspell

mikaspell Dec 23, 2014

Как мне кажется это просто раздувание sass файла, на каждый чих отдельный плейсхолдер, на каждый чих отдельный модификатор... В итоге в большом проекте мы получаем мешанину в которой ну очень просто запутаться, а это уже конфликт с идеологией БЭМа

Как мне кажется это просто раздувание sass файла, на каждый чих отдельный плейсхолдер, на каждый чих отдельный модификатор... В итоге в большом проекте мы получаем мешанину в которой ну очень просто запутаться, а это уже конфликт с идеологией БЭМа

@ihorzenich

This comment has been minimized.

Show comment
Hide comment
@ihorzenich

ihorzenich Jan 8, 2015

Мы к такой же идее пришли в 2013 году: https://github.com/ideus-team/guidelines/blob/master/frontend/bem.md

Мы к такой же идее пришли в 2013 году: https://github.com/ideus-team/guidelines/blob/master/frontend/bem.md

@ihorzenich

This comment has been minimized.

Show comment
Hide comment
@ihorzenich

ihorzenich Jan 8, 2015

Внутренние Sass-селекторы вида %модификатор - это Sass реализация абстрактных блоков BEM (i-блоков). Это BEM, нет никакого БЭВМ.

%i-block {
  // стили абстрактного блока
}
.b-block {
  @extend %i-block;
}

Внутренние Sass-селекторы вида %модификатор - это Sass реализация абстрактных блоков BEM (i-блоков). Это BEM, нет никакого БЭВМ.

%i-block {
  // стили абстрактного блока
}
.b-block {
  @extend %i-block;
}
@ilyar

This comment has been minimized.

Show comment
Hide comment
@ilyar

ilyar Jan 8, 2015

Чуть больше Stylus для (БЭ)Модификаторов в классической нотации #b_ http://codepen.io/ilyar/pen/qERXjM

ilyar commented Jan 8, 2015

Чуть больше Stylus для (БЭ)Модификаторов в классической нотации #b_ http://codepen.io/ilyar/pen/qERXjM

@ihorzenich

This comment has been minimized.

Show comment
Hide comment
@ihorzenich

ihorzenich Sep 30, 2015

Пришёл к тому, что абстрактные классы #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… */
}

  1. Через %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 там не работает.

Пришёл к тому, что абстрактные классы #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… */
}

  1. Через %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 там не работает.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment