• Jim SilvermanJim Silverman, over 5 years ago

    What happens when we want to apply that exact same styling to another list that's not a "menu"? You think it's smart to just duplicate the entire CSS block?

    i'm not sure how BEM would solve this. all classes related to "menu" would start with "menu__" and not be able to be repurposed.

    Let's say we're styling a and its children/descendants via nested CSS. What happens when someone realises the should be an and changes the element, breaking the styling?

    fair enough.

    Also, for what it's worth, element type selectors are slower to parse than classes. Child selectors are even slower. Descendant selectors are slower again.

    ids and inline styles are the fastest, if we want to go that route. differences are trivial in most cases.

    0 points
    • Colm TuiteColm Tuite, over 5 years ago

      i'm not sure how BEM would solve this.

      It wouldn't. I'm just saying this is one of the many problems which surface when you use nesting.

      When styling a component and its child elements, you usually have 3 options:

      1. You can add a class to each element in the component (using a smart naming convention), then extend your styles to those classes.
      2. You can litter the component's html with all the classes necessary to style it.
      3. You can add a class to the parent and style all its children via nested CSS on element type selectors.

      I never, ever use option 3. It's by far the worst of the 3 options. I go back and forth between options 1 and 2, depending on the complexity of the component; if I think the html is getting too messy, I transfer it into a component.

      The goal is to end up with highly reusable styles, form separated from function and the ability the edit the html without breaking any styling. Nesting CSS simply cannot accomplish this.

      0 points
    • Hamish TaplinHamish Taplin, over 5 years ago

      With regards the first issue, the point is that you're tying your CSS to the elements you've used and, even worse, their structure. This isn't re-usable without changing the CSS every time you want to use those styles elsewhere and doesn't follow the principle of separation of concerns.

      For example, you may wish to use divs instead of a ul — you then have to add an additional rule to your CSS which add complexity. What happens if you, further down the line, want to style some spans in the same way? Again, another rule. If you just use classes your separating the style from your markup where .menu and .menu__item can be used with any markup.

      I can understand why the syntax of BEM puts people off—I was the same at first. However, I tried it on a few projects and I would never go back. It solves so many problems with specificity and increases modularity so much that it become really obvious once you start using it. You don't even have to use BEM syntax—just the principle of OOCSS is enough (eg. the way Bootstrap is written).

      1 point
      • Jim SilvermanJim Silverman, over 5 years ago

        again, problems arise when you start nesting willy-nilly. not a good idea to go more than a second level deep.

        what i'm saying is ".block element.modifier" instead of ".block__element--modifier" this results in much cleaner code in both CSS and HTML, is easy to maintain, completely modular and is barely tied to structure.

        it seems the only tangible advantage of BEM is, as you've stated, the freedom to change html elements used. though i've rarely had a need for that.

        1 point
        • Hamish TaplinHamish Taplin, over 5 years ago

          I wouldn't describe that as 'cleaner' at all as it's unnecessarily specific and inherently less re-usable. What problem does it solve?

          1 point