v2

[belozer]

В поисках более чистого синтаксиса было решено отказаться от block(), elem(), mod() в пользу разделителей #8

Из плюсов

• более лучшая подсветка
• меньше кода
• больше ванильности css

Таким образом pobem становится не заменяющим, а дополняющим инструментом.

Пример нового синтаксиса

.block_mod {
    _othetMod_val {
        __elem {}
    }
   __elem {}
}
→ .block_mod.block_othetMod_val .block__elem {}
→ .block_mod .block__elem {}

в сравнении со старым

Парсинг

Парсинг осуществляется на основе bem-нейминга с запоминанием контекста.

.block__elem_mod_val > h1 __elem2 
// Ctx { block : 'block', elem : 'elem' }, { block : 'block', elem : 'elem2' }

Реализация миксов

.block__elem1.__elem2 {}
→ .block__elem1.block__elem2 {}

.block._m_v._m2_v2.__e._m1 {}
→.block.block_m_v.block_m2_v2.block__e.block__e_m1 {} 

Модификаторы

Для модификаторов нет необходимости указывать . Достаточно разделять пробелами (первый модификатор не обязательно отделять пробелом)

.block _mod _mod2 {} → .block_mod.block_mod2
.block_mod _mod2 {} → .block_mod.block_mod2
.block_mod._mod2 {} → .block_mod.block_mod2

// TODO

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

Пока сомнительное решения для утяжеления. Кажется не явным

.block._mod _mod2 {} → .block.block_mod.block_mod2

Поддержка входного и выходного нейминга (конвертер)

.block_mod_val
→.block--mod--val

.block--mod--val
→.block_mod_val

Перенос конфигации из env в опции плагина

upd

Для трансформаций нейминга использовать https://github.com/tadatuta/bem-naming-transformations

upd
Возможно нужно сделать строгий режим через точку

.button_view_action __text {}
.button_view_action .__text {}

Т.к. без точки читается хуже

Чем сточкой

Если исходить из правил bem - без точки всё ок, но нужно в голове постоянно держать что миксуется, а что нет.

При варианте с точкой - в голове достаточно держать только контекст.

[belozer]

Нужен набор правил, которые будут делать линтинг для pobem.

например

• Обязательность точки у элементов
• Обязательность точки у модификаторов
• Дополнение элементов контекстом .__elem → .block__elem
• Дополнение модификаторов контекстом ._mod → .block_mod

[belozer]

Пример опции для парсинга (взято из @bem/sdk.naming.entity.parse)

{
    wordPattern : '[a-z]+',
    delims : {
        elem : '__',
        mod : {
            name : '_',
            val : '_'
        }
    }
}

[belozer]

Нужно подумать на тем, стоит ли по умолчанию раскрывать селекторы аттрибутов

.block[class*='_mod'] {} →.block[class*='block_mod'] {}

По идее нужно. Но как это должно влиять на контекст? Кажется, что это не совсем безопасное место, т.к. не понятно как правильней.

.block[class*='__elem']._mod {} →.block[class*='block__elem'].block_mod {}
или
.block[class*='__elem']._mod {} →.block[class*='block__elem'].block__elem_mod {}

[belozer]

Псевдо элементы и селекторы атрибутов не должны влиять на контекст

.block:not(.block2) __elem {} → .block:not(.block2) .block__elem {}

.block[class*='block2'] __elem {} → .block[class*='block2'] .block__elem {}

На контекст должен влиять только класс и тэг(элемент, модификатор).

[belozer]

черновик

allowElemScopeOverride

false

.block __elem + .block2 > __elem {} → .block .block__elem + .block2  > .block__elem {}

true (по-умолчанию)

.block __elem + .block2 > __elem {} → .block .block__elem + .block2  > .block2__elem {}

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

Нужено ещё поисследовать эту тему, т.к. палка на двух концах