SelectorFormat refuses valid BEM

[mrpavlikov]

New SelectorFormat linter refuses valid BEM selectors (modifications on elements):

.b-block__element-name_modifier_value {
    border: 1px solid;
}

.b-block__element-name_modifier {
    border: 1px solid;
}

Saying:

Selector `b-block__element-name_modifier_value` should be written in BEM (Block Element Modifier) format
Selector `b-block__element-name_modifier` should be written in BEM (Block Element Modifier) format

Am forced to use custom regular expression for this, would prefer to use built-in feature.

^[a-z]([-]?[a-z0-9]+)*(__[a-z0-9]([-]?[a-z0-9]+)*)?(_[a-z0-9]+){0,2}$

[Anahkiasen]

Well yeah it's --modifier not _modifier no?

[mrpavlikov]

@Anahkiasen seems not.

According to https://bem.info/method/definitions/

menu__item_state_current

According to http://xslc.org/jquery-bem/

b-block4__elem2_mod1_val1

And even if you look at http://yandex.ru

input__sample_js_inited

[mrpavlikov]

@Anahkiasen actially am pretty sure all of these should pass

.b-block__element-name_modifier {
    border: 1px solid;
}

.b-block__element-name_modifier_value {
    border: 1px solid;
}

.b-block__element-name_modifier-name_value {
    border: 1px solid;
}

.b-block__element-name_modifier-name_value-long {
    border: 1px solid;
}

this regex does the job it seems:

^[a-z]([-]?[a-z0-9]+)*(__[a-z0-9]([-]?[a-z0-9]+)*)?(_[a-z0-9]([-]?[a-z0-9]+)*){0,2}$

[davidtheclark]

Yes, @mrpavlikov, I believe that throughout SCSS-Lint what's referred to as "BEM" is a modified version that has become more popular than the original, it seems -- which distinguishes modifiers with --modifier instead of _modifier-name_value. I think that if the linter were to add your regex it should probably be distinguished as "strict" BEM or something like that. Somehow, at least, both patterns should be available, not just the original one you bring up.

[Anahkiasen]

Yes indeed I use the variant Harry Roberts popularised, never really encountered the "original" one, always saw this one being used.

[sds]

It is simple enough to add another convention to the list, but it's unfortunate that this particular convention does not seem to be standardized despite its relatively distinct name.

If people are fine with a strict_BEM convention being the one that @mrpavlikov describes, and continue using BEM for the newer version, I'd be happy to merge a pull request.

If there is significant debate over which convention deserves the pure title of BEM, then please post some evidence for which one deserves the glory.

[mrpavlikov]

@sds well, BEM has been developed by Yandex, so I'd rather stick to their syntax.

Also, according to official bem docs: http://bem.info/method/definitions/ (look at Element modifiers) it's single underscores.

Btw, this doc says

A modifier has a name and a value.

So this is not valid

.b-block__element-name_modifier {
    border: 1px solid;
}

and this is valid

.b-block__element-name_modifier_value {
    border: 1px solid;
}

so regex should look something like:

^[a-z]([-]?[a-z0-9]+)*(__[a-z0-9]([-]?[a-z0-9]+)*)?((_[a-z0-9]([-]?[a-z0-9]+)*){2})?$

[mrpavlikov]

@sds even tho BEM rule should be compatible with bem-tools (set of utilities to generate bem css and layout), for the sake of backwards compatibility it is possibly wise to keep current rule as is to avoid people getting linting errors on update. But since scss-lint is not actually in release state and is just 0.29, 0.30 probably could change this behaviour.

Actually I'm perfectly fine with both ways (keep current BEM rule as is or rewrite to strict one).

[sds]

I'm comfortable changing the default BEM to be the from as specified on the official BEM site, and refer to the more popular version as hyphenated_BEM.

@mrpavlikov I took your regex as-is in 308b084. Would be great if you could take it for a spin (or submit a PR with tests), as I'm a little strapped for time, and this isn't a feature I would use myself. Thanks!