Block modifier affecting sub-block elements about getbem.github.io HOT 16 CLOSED

(poke @iamstarkov @varya)

from getbem.github.io.

@ncoden I think, you shouldn't use myblock inside of myblock. IMHO it's kind of anti-pattern in BEM.

from getbem.github.io.

@f0rmat1k It's a DOM representation. If a BEM component can recommend a "standard use", BEM allows to use and nest your blocks as you want, reorder its elements or put them lower in the DOM tree...

from getbem.github.io.

@ncoden yes, it's allowed, but in my opinion it's something like an anti-pattern.

from getbem.github.io.

Let's clarify what is anti-pattern, so what pattern we should follow where.

• BEM is a syntax for an OO approach : the pattern is to define consistent and modular objects, elements inside block. modifier modifing block
• DOM is an empty room where you freely place and nest your objects : the pattern is Do what the fuck you want here
• So BEM in DOM is Do what the fuck you want, as long as you apply a block modifier on this block, and you keep a block element inside this block.

from getbem.github.io.

You are right, but as i know, important goal of BEM — isolation of block styles and solving css global namespace peoblem. When you are using

myblock myblock--modifier
   myblock

you're losing independence of nested "myblock" (reason why you came here). It's just my opinion. I haven't needed to inser block into the same in 2 years of using BEM.
We can also ask for @tadatuta what he thinks about described situation.

from getbem.github.io.

btw anti-pattern ≠ prohibited.
For example, this is anti-pattern but legal BEM code:
<div class="some-block some-block-1"></div>.
Better to use the modifier <div class="some-block some-block_num_1"></div>.
Maybe better to call it "best practise".

from getbem.github.io.

No. "myblock" is still fully independant.

I want to be able to use "myblock" as :

myblock myblock--modifier
  myblock
    ...

But I will never declare "myblock" rules like:

.myblock > .myblock { ... }

If having a "block" inside an other modified "block" create side effects (deeper block elements are affected too by modifier), it actually make the "block" component not independent. Because you're not able to use it in any situation.

from getbem.github.io.

@ncoden

But I will never declare "myblock" rules like:

this. its fine, while you are working alone. Once you are creating components within a team, there is no guarantee this wont happen

from getbem.github.io.

@iamstarkov 👍 I should say:

But we shouldn't declare "myblock" rules like:

Because IT is anti-pattern.

from getbem.github.io.

@ncoden btw i mean not .class > .class but nesting of the same blocks.

myblock myblock--modifier
   myblock
       myblock__elem

leads to losing independency of nested myblock__elem, because another block affects on it (even if it's the same block).
The second point: which of the two myblock is a truly parent-block of myblock__elem? No answer, we don't know exactly. This uncertainty is a reason, why i think, that it's anti-pattern.

from getbem.github.io.

leads to losing independency of nested myblock__elem, because another block affects on it

It's the purpose of this issue.

...
        myblock__elem myblock--modifier__elem

instead of

...
        myblock__elem

which of the two myblock is a truly parent-block of myblock__elem? No answer, we don't know exactly

It is the child of the closer same parent. For exemple:

myblock     // (1)
    myblock // (2)
        myblock__elem // child of (2) at its recommended place

myblock myblock--blue // (1)
    myblock           // (2)
        myblock__elem myblock--blue__elem // child of (1) placed inside (2)

But the common case is:

mylist
    mylist__item
    mylist__item
        mycomponent
            mylist
                mylist__item
                mylist__item
    mylist__item

from getbem.github.io.

@ncoden So I advise you to just use the > in css when you're describing modifier rules.

from getbem.github.io.

@f0rmat1k The common case, not the only case.

The following situation is proper and possible

mylist mylist--vertical
    u-padding // or what you want (u- for util)
        mylist__item mylist--vertical__item
        mylist__item mylist--vertical__item
            mycomponent
                mylist
                    an-another-random-component
                        mylist__item

from getbem.github.io.

@ncoden Ye, now i see. It looks like real methodology problem. I think there isn't common solution, you should process such situation differently. E.g. you can remove the cascade by using elemMods instead of mods of block.

from getbem.github.io.

@f0rmat1k I'll use block__element--modifer when a modifier can be freely applied on one element, independently of the other. Here, the modifier is semantically attached to the block, so I prefer to use block--modifier__element to clearly indicate You should apply this modifier on all elements too.

Thank you a lot @f0rmat1k and @iamstarkov for your help. I didn't found a better solution, but you helped me to organize my point of view.

I will come back to you if I found a better way :)

from getbem.github.io.