Jason Edelman

haha... don't even get me started on coffeescript... ugh

You're welcome :) glad I could help!

I didn't say making the code look uglier, you did :) I think it looks way cleaner to know where my vars are and that they're being initialized in the order I want them to. The saving bytes part is just a side effect, but the main issue is preventing hard-to-debug errors due to hoisting.

The biggest reason why, as explained above, is due to hoisting. When you declare a variable in the middle of your function, it's not actually getting declared there at runtime. This can lead to all sorts of errors, especially if you're declaring the value of said variable to be a function. I recommend you read the hoisting article mentioned above, namely this part.

Just make sure your hrefs are the same on both links, or make only the element that gets moved into view a link, otherwise you'll run into some really interesting bugs :)

(or make the container a link and the children spans)

If you use SASS and/or Compass, checkout this flexbox mixin :)

The relevant HN discussion

Two things:

1) @extend Placeholders

2) If you need to include any kind of variable, you MUST use mixins. So don't discount them entirely. Also, if you're not careful, @extend becomes a nasty, slippery slope.

@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.

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.

@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.

Neat trick, but be aware that clever code can introduce bugs if being maintained by someone unfamiliar with your trickery :) I'd be sure to leave a very descriptive comment by that line.

Here's a neat little trick for getting background images into HTML emails: https://www.campaignmonitor.com/forums/viewtopic.php?pid=14197

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

best:

result = big > small;

@shoen it's silly, but it's fun and harmless. Could be good for team bonding :)

Again, not trying to insult you, just disapproving of the method outlined in this post. I'm glad I could help you, though :)

@stowball I'm not intending to insult you, I'm just being honest about this technique. You want a "semantic" class name? I gave you one in my first comment. Try "moduleheader" or "moduletitle". Add that class everywhere you'd add "hX" instead and now you can do

h4 { font-size: xpx; }

.moduleheader { font-size: ypx; }

and it will be ypx! Now if you decide to change .moduleheader to zpx and make it red, you have a place to do it, and it will uniformly affect all your ".moduleheader"s. If you wanted to do that with your way, you'd either have to make all hX's red or add another class (what would you call it? "redfont"?) to all of your HTML elements. What if you have 10 of these h4.h2 elements and your designer says, "Actually, these are more of an h3?"

I'm sorry, but you won't convince me to accept this concept as a good idea. This violates web development 101.

On a side note, have you ever used SASS? I'm assuming you haven't, because if you had, you could fix this problem in your actual CSS without even repeating any font sizes:

$h1: wpx;

$h2: xpx;

$h3: ypx;

$h4: zpx;

h1 { font-size: $h1; }

h2 { font-size: $h2; } // etc

.news h4 { font-size: $h2; }

Easy, no?

@samuelmealing the only time I would ever be ok with this technique (I would never recommend it) is if you're writing prototype throwaway code, as this is not scalable in any way. Even then, you're bound to get screwed up. Should this be an H2 or an H4?

IMO, this is just laziness and inexperience.

I'd have to disagree. You're using a class that is descriptive of what the element is supposed to look like, which is a big HTML/CSS no-no that violates the basic tenet of "separation of concerns". That's no different than calling your H4 "biggreenheader" (if you wanted it to be big and green).

A better approach might be ".moduleheader" and styling your module headers differently (in a different location than your default styles). That way if you change your design, you don't have to change your class if it is no longer the size of an H2.

I'd definitely given up on textured backgrounds. You've given me new hope! Thanks :)