Hacker News Reader

Comment by romaniv | Hacker News Reader

Never understood why people prefer verbose and repetitive BEM classes over custom properties and appropriate CSS selectors.

  <div class="my-block my-block__my-element my-block__my-element--my-modifier">

becomes

  <div my-block="my-element my-modifier">

This solves for specificity, and uses built-in CSS features instead of a "manual" workaround.

View on HN

This isn't a realistic example of how you should use BEM, you would never have a block, element, and modifier in one class. The "block" class would be used in a div that wraps the elements:

    <div class="block">
        <div class="block__item">
            I am an item
        </div>
        <div class="block__item block__item--danger">
            I am a dangerous item
        </div>
    </div>

Your simplification relies on an HTML hack and can potentially be more confusing when modifier names start colliding.

Yuck. I would follow the advise in this blog post [1].

https://www.smashingmagazine.com/2013/08/semantic-css-with-i...

Because "my-block" is not a valid attribute for div. You are breaking one language in your attempt to fix your problem in another language.

This argument doesn't stop a myriad of widely used JavaScript frameworks that rely on custom attributes. Besides, if you really care about validity, you can use

  <div data-my-block="my-element my-modifier">

It's still shorter, more readable and avoids repetitions. The difference becomes even more pronounced as the complexity of your styling goes up.

My argument about the attribute is not invalid because they are doing it the wrong way. Custom attributes for HTML should make use of the data attribute, as you point out. One could use data attributes in such a way, I have, but in the past it was something to avoid due to performance issues.

To be fair, I don't know the latest performance figures on attribute selection.

>My argument about the attribute is not invalid because they are doing it the wrong way.

The problem with this argument is that just a few years ago everything ReactJS does now was the wrong way, but for some reason today, it's the best way. So which is it?

It seems to me, that unless it's broken, or goes against an explicit rule from the browser/code designers of html/css etc... it's totally valid. And if it doesn't "feel correct", then maybe it's a trend waiting to happen. <sigh>inline javascript styles</sigh>

What was ReactJS doing a few years ago that was wrong then but correct now? Since I don't know what that is, did the spec change during that time?

As far as I know right now, custom attributes goes against the html standard.

>What was ReactJS doing a few years ago that was wrong then but correct now?

Inline styles for one... created with javascript no less. This was totally verboten not long ago. But then became a "best practice" only because React started doing it.

I disagree, inline styles is never a "best practice" no matter what the reason or who does it. It happens from time-to-time due to necessity, but that doesn't make it best practice. In this case, React is simply doing it wrong.

Reply on news.ycombinator.com