CSS Structure

We have adopted BEM where I work, and it's pretty nice: http://coding.smashingmagazine.com/2012/04/16/a-new-front-end-methodology-bem/

@donutdan4114 Yeah. BEM is terrific.

You should never have to write a class called .article__header--headline if you truly grok cascading.

"Keep things generic and re-usable." is one of the golden CSS rules that I always remind myself of whilst developing styles.

@ultimatedelman then please tell me what else would be a good use. I'm willing to learn from mistakes. :)
@davidandrewsmit I agree, especially re-usability is very important though.

@kevingimbel the correct way would be to have a semantic structure, like so:

<article>
    <header>
        <h1>My Headline!</h1>
    </header>
</article>

So you can reference your h1 like so in your SCSS file (if you wanted to get this specific):

article {
    h1 { 
        //header styles here
    }
}

Of course you can add classes and such, but you shouldn't give your elements classes of the same name as what they are, for instance, you shouldn't do this: <article class="article">. A better convention would be something like <article class="news"> or whatever the article is supposed to be representing.

@ultimatedelman in one point I agree with you: Giving an <article> the class article is kinda useless, but there is a reason why I avoid SCSS Structures like

article {
    h1 {
    }
}

If the markup changes, let's say because a new developer comes and decides that all articles should have an h2 as headline because an h1 headline is only used on the header, they'd need to change the SCSS, too. If I use describing names like single__article--headline they're readable AND can be applied to any kind of element. If you only have one thing to change it wouldn't be a big deal but imagine you have a site with hundreds of different elements, all only made with nesting or in other ways related to the mark up. You'll end up running through all your codes to change all the things - if you have describing names and avoid nesting, you'll be able to make changes much faster.

I do lose the nesting feature of SCSS but nesting can cause more problems than it solves. I do only nest :hover,&:before, &:after and :focus - in other words: most of the time only pseudo elements.

I can get much more out of SCSS by using mixins and vars.

Like I said, you can get as specific as necessary, or add classes to your elements. For example:

<article class="news">
    <header class="headline">
        <h1 class="title">I like tuhtles</h1>
    </header>
</article>

Your CSS can now be very generic and reusable:

.news { //styles }
.headline { //styles }
.title { //styles }

If you want to change your h1s to h2s, no problem. You can also re-use your .title class elsewhere, but if you wanted to be specific about a .title in a .headline you just do:

.headline {
    .title { //overriding or additional styles }
}

If you do something like this, you've properly leveraged (I hate that word) cascading, whereas in your example, your pieces are far less modular and will get very specific very fast.

So what would you say? Working on a "My CSS is like my HTML" base requires to change both whenever something new comes in. Which way of naming is the best?

I agree with you Kevin! 100%!

@kevingimbel there's no magic bullet when it comes to building a site. When you change something in one part, you'll often have to change something elsewhere. It's just the nature of the beast. The trick is coming up with loosely-coupled conventions that minimize the amount of change required ;) Your above conventions are very tightly-coupled.

That seems pretty standard now a days, just the syntax is horrendous. Why the need for underscores?

.module
.module--modifier
.module-element
.module-element--modifier