Hacker News Reader

Comment by Fifer82 | Hacker News Reader

To be honest, I still find CSS a mess. I really dislike it. I feel like JS and HTML are pretty solid, then you have this CSS hacky shit with no decent docs and I just didn't get it.

Recently I wanted to use Material Components, and the whole BEM thing makes my eyes cry.

`custom-on-dark .mdc-icon-toggle.mdc-ripple-upgraded::before`

`custom-on-dark .mdc-icon-toggle.mdc-ripple-upgraded::after`

`mdc-toolbar__section mdc-toolbar__section--align-start`

I just am not going to work with that in my code and it screams to me something is wrong.

View on HN

I'm not a fan of BEM either. It terribly feels like over-engineering and ignores certain principles of CSS. Often, much better clarity could be achieved simply with better naming and structuring of elements.

>I'm not a fan of BEM either. It terribly feels like over-engineering and ignores certain principles of CSS.

It's actually under-engineering (a brute force, hacky solution), and it ignores those principles of CSS (cascading for one) on purpose because they have been historically found to be more harm than good.

Something about it reminds me of being new to programming.

var the_first_left_menu_item_animation_enter

var the_second_left_menu_item_animation_enter

What causes this problem? Does CSS not have any modular capability and that is why? Is it global by definition? Not really sure what I am trying to say.

>What causes this problem? Does CSS not have any modular capability and that is why? Is it global by definition?

It has crappy scoping and modularity rules.

> Often, much better clarity could be achieved simply with better naming and structuring of elements.

I'm always interested in seeing examples of good class naming and structure if you have some available.

BEM is more about specificity, modularity, and namespacing than it is about clarity (which many think it also achieves).

Well, I disagree with some assumptions it makes. For example, `.button--active` should help avoiding collisions with other elements using the same modifier `.active`. But I would argue that either there are shared styling rules between such "colliding" elements, or the modifier is named poorly (i.e. shouldn't be as generic as `active`.

I particularly liked the way tachyons does styling, in contrast to this. (http://tachyons.io/)

".ba" to add border all or ".bt" for border top... then just add ".b--dashed" for dashed border... ".georgia" will use Georgia font... ".red" will color it red.

Though class names they used can be more uniform IMO.

From their examples:

    <article class="mw7 center ph3 ph5-ns tc br2 pv5 bg-washed-green dark-green mb5">
        <a class="f6 br-pill bg-dark-green no-underline washed-green ba b--dark-green grow pv2 ph3 dib mr3"href="#">Sign Up</a>
    </article>

...I sure wouldn't want to maintain that site.

Why do you want to spend all your time editing your HTML, adding and removing classes in multiple places again and again, when you could just make one change in your CSS?

Whats the benefit of tachyons over just writing inline styles?

The author discusses it a bit here: https://github.com/tachyons-css/tachyons/issues/12

The key points from there, regarding your question specifically: 1) inline styles can't use media queries, while there are tachyon classes for different devices. 2) Ditto for pseudo classes. 3) The browser renders them faster.

But I think your actual question was something more along the lines of "isn't styling individual elements considered bad practice?" That has a bigger answer and is more philosophical. I, too, recoil at it, but I'm open to best practices changing or being considered differently in the context of web applications vs web pages.

For example, react and JSX changed my mind about mixing JS and markup and even styling to some extent.

>I, too, recoil at it

But you're recommending this? This has advantages over inline styles, but doesn't avoid the main drawback of using them: difficulty to maintain and change.

Reply on news.ycombinator.com