Inconsistency in how bemto identifies a primary block/element class

[jonscottclark]

Hey @kizu,

I wanted to report this issue because I don't know if it's actually a bug or not.. maybe it's just something that needs documenting, or maybe you had a good reason to do this.

If I write:

+b.Component.otherclass
  +e.Element

It compiles as expected to:

<div class="Component otherclass">
  <div class="Component__Element">
  </div>
</div>

But if I change it to:

+b.Component.otherclass(class='_modifier')
  +e.Element

It renders:

<div class="Component otherclass otherclass_modifier">
  <div class="Component__Element">
  </div>
</div>

It appears that when you use the class attribute (as I sometimes do to dynamically insert extra modifier classes) instead of passing the modifiers directly into the selector, bemto will add the modifier class onto the last class in the selector, when, in previous versions and in most other cases, bemto will identify the first class after +b or +e as the primary class.

[kizu]

Hmm, yes, that was intentional, but I can see how this can be a problem. Thanks for the report!

The intention was in 1.0.0 to provide better support for mixing elements, so you could do

+b.foo._mod1._mod2.bar._mod3._mod4

and get proper result:

<div class="foo foo_mod1 foo_mod2 bar bar_mod3 bar_mod4">
</div>

Before 1.0.0 it was impossible as every modifier went to only the first block. And now, as the class from the attribute is added in the end of the class chain, it becomes a modifier for the last block there.

I can see how I could improve the current situation by adding a way to mark some of the blocks “primary”. The default behaviour would stay as it is now, but you would be able to do something like this:

+b.Component_.otherclass(class='_modifier')
  +e.Element

or adding _ after the block's name to mark it to be a primary one, so only this block would get all the passed modifiers.

I'll see if I could introduce this feature today or tomorrow.

[jonscottclark]

I guess I don't really see the use case for the above... I always would assume it would come out like this:

<div class="foo foo_mod1 foo_mod2 bar foo_mod3 foo_mod4">
</div>

I'm not a fan of the proposed syntax, as I'd have to add the extra suffix, eg. Component_ whenever I needed to add regular class.

It seems as though #70 is closer to what the behaviour _should _be on block elements, so that to achieve your example:

<div class="foo foo_mod1 foo_mod2 bar bar_mod3 bar_mod4">
</div>

You would actually use:

+b.foo._mod1._mod2.bar__._mod3._mod4

That way bar__ essentially 'interrupts' the chaining, and its special syntax indicates that it's acting as a new block. At least that seems like what is happening on the element level, in #70.

I wouldn't want to introduce a special syntax to indicate the "primary" component, as it accommodates a small use case and could introduce confusion.

[jonscottclark]

That still leaves the problem of which element should inherit elements that appear in the class attribute. And if the "chain" of the original block element isn't interrupted by a special bar__ class, re: the example above, then my specific use case will work as expected, because .otherclass wouldn't be recognized as a new scope but rather as a regular class.

What do you think?