Миксы и каскад для вложенных блоков

[andysh7]

Привет всем!

Дано: использование CSS по методологии БЭМ без bem-tools или enb.

Вчера наткнулся на статью про миксы и на комментарий Виталия про использование каскадов для вложенных блоков:

Вложенные селекторы могут быть при: 1) определении стилей одних блоков/элементов внутри других для изменения их вида. Например, если надо изменить блок link при вхождении его в элемент tab блока head: .head__tab .link { color: blue } 2) изменении вида элементов блока в зависимости от его модификатора: .head_size_big .head__tab { font-size: 150%; }

У меня по этому поводу несколько вопросов:

1. Нормально ли что мы всё таки используем каскад для вложенных блоков? Тут конечно не реализация стилей от контекста, но тем не менее мы повышаем специфичность в данном случае.
2. Если таким образом использовать каскад, то можно модифицировать только лишь блок? Или же таким образом можно модифицировать и элементы блока, тем самым вмешиваясь в его реализацию извне?
3. Такая ситуация: допустим я миксую два блока, либо миксую блок и элемент другого блока на одной ноде. a. В идеальном случае при миксе блоки должны взаимодополнять друг друга? т.е. не может быть перекрывающихся CSS-свойств? b. Если же миксовать блоки с перекрывающимися css свойствами тут уже играет роль порядок следования блоков. Что если мне нужно чтобы одно из свойство моего блока преобладало и не зависело от порядка? Ну или ситуация - мне нужно вообще поменять свойство на совершенно иное, если блоки находятся именно в такой связке (миксе). Допустимо ли писать .link.pseudo-link в реализации одного из блоков? Т.е. описывать замиксованное поведение в одном из блоков?

Надеюсь не слишком запутанно спросил :) Заранее благодарю за ответы.

[tadatuta]

Привет!

Нормально ли что мы всё таки используем каскад для вложенных блоков? Тут конечно не реализация стилей от контекста, но тем не менее мы повышаем специфичность в данном случае.

«Разрешение» на вложенные селекторы есть прямо в FAQ на bem.info.

Повышение специфичности здесь кажется тоже оправданным: блок-родитель отвечает за то, что его потомки выглядят иначе, чем сами по себе.

Если таким образом использовать каскад, то можно модифицировать только лишь блок? Или же таким образом можно модифицировать и элементы блока, тем самым вмешиваясь в его реализацию извне?

Ответ есть в самом вопросе :) Если разработчик понимает, что делает и понимает, какие последствия такой архитектуры могут быть, то было бы странно ему запрещать. Но так определенно не стоит делать, например, при использовании внешней по отношению к проекту библиотеки — нельзя гарантировать, что в следующей версии внутренний мир блоков не изменится. Или если над проектом работает большая команда.

допустим я миксую два блока, либо миксую блок и элемент другого блока на одной ноде Если же миксовать блоки с перекрывающимися css свойствами тут уже играет роль порядок следования блоков. Что если мне нужно чтобы одно из свойство моего блока преобладало и не зависело от порядка?

Мы гарантируем порядок с помощью дополнительной технологии deps.

Ну или ситуация - мне нужно вообще поменять свойство на совершенно иное, если блоки находятся именно в такой связке (миксе). Допустимо ли писать .link.pseudo-link в реализации одного из блоков? Т.е. описывать замиксованное поведение в одном из блоков?

В примере с .link.pseudo-link я бы выразил pseudo-link через модификатор самого link и это бы решило неоднозначность. Но действительно бывают ситуации, когда два блока в виде микса должны обладать дополнительными свойствами. В таком случае могу предложить миксовать еще и третий блок, который будет отвечать за их «совместное» существование.

[andysh7]

Спасибо за развернутый ответ!