I'm going to offer you a few tips on improving your code. I learned a lot of these lessons the hard way. :)

Forewarning, this is going to run a little long.

Honestly, it looks like you're making it display correctly, but your code is tripping over itself and some rules you defined earlier are coming back to bite you. Take a look at this, for instance:

Basically, you would like for those boxes to have a black background. So that's what you set. The problem is that you've already set any divs within a .container to have a gray background. And since the latter is more specific, it overrides the former.

CSS

Guild says this in his Modular CSS course, but you want to avoid using both broad and specific selectors as much as possible. Exactly how many divs do you plan to have under a .container class? Probably a lot. It's a very broad selector. Probably too broad. You probably plan on having more than one #box-container, so maybe that selector (as an ID selector) is a little too specific.

The reasoning behind that rule is that broad selectors tend to leak out and get applied to elements you never intended them to be applied to. Conversely, overly specific selectors can never be reused.

For the most part, anytime you select an element by tag name, it's too broad. Exceptions to the rule include the typographic elements (p, h1-6, strong, em, u, q, blockquote, cite, etc.), as the purpose of those elements is always tied to the tag name. As long as you scope them (e.g., #article blockquote), you should be good. Elements like body and html are also exceptions because there's only one of each on the page. Lastly, if you're setting styles you really, really want to be global (like changing the color of all links across the page and removing their underlines), then go right ahead.

To avoid selecting a whole lot of tag names, use a class or ID on everything related to layout. I like using IDs for high-level elements that any given page only has one of (my primary header, my primary footer, my primary navigation, etc.) and classes for everything else.

Be descriptive with your class names: rather than just .box (which is a very generic name that could be a panel, a button, a blockquote, or a textarea) use .feature, .col, or .panel. Also, don't use class names like .background-blue; what will happen if you decide to change the background to red?

Keep the naming scheme among your classes similar. Don't use .camelCasing for some classes and .hyphens-between-words for others. Using lowercase with hyphens is the globally accepted standard for CSS. Hint hint, you should probably use it. :)

Abbreviating your class names is generally frowned upon, but there are a ton of exceptions. Everyone knows that .bg translates to "background"; everyone knows that .col translates to "column." Personally, I get sick and tired of typing .container all over the place, so I just shorten it to .cc and add a comment in my CSS saying such.

Speaking of comments, commenting your CSS is always a good thing. If you comment your classes well, you can get away with breaking a few rules.

Don't be afraid to use pseudo-selectors in place of classes whenever you can. They're more flexible than classes are, as they'll adjust to the HTML where classes won't. Instead of adding the .last class to the last link in your nav and changing it whenever you update the nav, use the :last-child pseudo-selector.

Keep your indentation in CSS consistent. It might seem like a little paranoid right now, but it's much easier to read and edit when it's indented properly. When you upgrade to Sass in a few months, remembering this is especially important.

HTML

To add to that, you don't need so many divs in your HTML. One of the big additions in HTML5 were all those semantic tags: header, nav, section, hgroup, footer, article, aside, and main, just to name a few. Use those in place of most of those divs to indicate that this is a high-level element, not just a container or something. None of those elements have any display differences from div; they just make your HTML a whole lot easer to read and understand.

As with CSS, keep your indentation in check. It's easier to let it slip away here, but it's all the more important to keep maintaining it, because losing track of it will cause your sense of the hierarchy to get messed up.

Tying in with the class-naming in CSS, try to keep your HTML self-documenting. It's very rare for me to comment through my HTML because of the way I've arranged my elements:

<section id="post-135" class="post format-standard author-duchenerc sticky">
  <ul class="post-meta">
    <li class="post-author">
      Author: Ryan Duchene
    </li>
    <li class="post-date">
      Date: November 30, 2014
    </li>
    <li class="post-cats">
      Categories: HTML, CSS, Layout
    </li>
  </ul>
  <article class="post-content">
    <h1>Post title lorem ipsum</h1>
    <p>
      Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
    </p>
  </article>
</section>

When I write a new tag, its name should come first (obviously), but the second attribute should be id, if you've assigned any, and the one after that should be class. (That particular order is personal preference; if you have something else you like, go for it.) Between the semantic tag name, the IDs, the descriptive class names, and the content in the HTML, anybody can pick up the general idea of your code just by glancing through your HTML. If they want more info, the stylesheet beckons.

Of course, commenting in your HTML is perfectly fine, especially the end-of-element comments. I just prefer keeping it to a minimum.

Layout techniques

Guil covers all of these techniques and more in his Layout Techniques course, but I'll just go over the basics here. There are three main techniques that I find useful: floats, inline-block, and flexbox.

Floats

Floats were originally designed to allow elements like images to be positioned in such a manner that they would shift toward a certain direction and other elements (especially inline elements) would flow around them. An example would be floating an image inside an article; the image is stuck to the left side of the article, and the text flows around it.

Floats have become a very popular layout tool as they provide a lot of flexibility, and even some source-independent order if used properly. When used for layout, they're accompanied by the clearfix hack, as elements that contain only floated children will collapse without the hack.

Floats have solid browser support, even in browsers older than IE6. ("Fun" Fact: When IE6 was released, you could board a plane in the US while carrying a pocketknife. Yes, IE6 is older than 9/11. And to think it's still used today.)

I recommend using floats in large-scale layout situations where you have a lot of control over where the content will be. Column layouts, grids, navs, and a lot of other large-scale UI components fall in here.

Inline-block

Inline blocks are, ironically enough, a cross between inline elements and block elements. Inline elements wrap around each other very nicely, making them good for text. Block elements stack on top of each other, making them good for layout. Inline-block runs the gap, leaving you with block elements that wrap around well.

The downside to inline-block is that it just does not give you the control that floats do. Everything sticks to the left like glue; there's no way to center anything or reverse its order. The upside over floats is that no clearfix hack is required, and there are more than a few situations when the clearfix hack is impractical.

Inline-block layouts have solid browser support, missing only IE6 IIRC. Use them for smaller UI components where you don't have much fine control, such as buttons, form fields, and (usually) horizontal lists.

Flexbox

Flexbox is the layout system of the future. It lets you do just about anything, and gives you a ton of control over everything. Center the items vertically, align them right, reverse their order, and pull the second one to the end. All just seven lines of CSS, with no changes to the HTML. And, unlike floats, it works vertically as well as horizontally.

Flexbox eats floats for breakfast in all but one area: browser support. Between its three different specs, flexbox covers all modern browsers; only IE8 and IE9 are left out in the cold. Those two browsers have a boatload of users, though. Similarly to floats, you need to establish a flexbox context in order for it to work, which means that it's impractical to apply it to the inline-block stuff.

Use flexbox everywhere you'd use floats, and then some.

Sorry about the wall of text. Hope you enjoyed. And, as a parting gift, I'll leave you with your layout in a CodePen, with pretty code and a pretty face. The CSS file is about 50 lines longer than yours is.

EDIT: Fixed link to CodePen. No, not a joke. Not sure how that happened. :)