Left Half and Right Half Layout

Imagine a scenario where you need to split a layout in half. Content on the left and content on the right. Basically two equal height columns are needed inside of a container. Each side takes up exactly half of the container, creating a distinct break between one. Like many things in CSS, there are a number of ways to go about this and we're going to go over many of them right now!

Using Background Gradient

.container {

  background: linear-gradient(

    to right, 

    #ff9e2c 0%, 

    #ff9e2c 50%, 

    #b6701e 50%, 

    #b6701e 100%

  );

}

http://jsfiddle.net/yrvvbva0/

Using Absolute Positioning

Another route might be to set up two containers inside of a parent container, position them absolutely, split them up in halves using percentages, then apply the backgrounds. The benefit here is that now we have two separate containers that can hold their own content.

http://jsfiddle.net/yrvvbva0/1/

Absolute positioning is sometimes a perfectl solution, and sometimes untenable. The parent container here will need to have a set height, and setting heights is often bad news for content (content changes!). Not to mention absolute positioned elements are out of the document flow. So it would be hard to get this to work while, say, pushing down other content below it.

Using (fake) Tables

Yeah, yeah, tables are so old school (not to mention fraught with accessibility issues and layout inflexibility). Well, using the display: table-cell;property can actually be a handy way to create this layout without writing table markup in HTML. In short, we turn our semantic parent container into a table, then the child containers into cells inside the table — all in CSS!

http://jsfiddle.net/yrvvbva0/3/

You could even change the display properties at breakpoints pretty easily here, making the sides stack on smaller screens. display: table; (and friends) is supported as far back as IE 8 and even old Android, so it's pretty safe!

Using Floats

We can use our good friend the float to arrange the containers beside each other. The benefit here is that it avoids absolute positioning (which as we noted, can be messy).

http://jsfiddle.net/yrvvbva0/4/

Using Inline-Block

If clearing elements after floats seems like a burden, then using display: inline-block is another option. The trick here is to make sure that the elements for the individual sides have no breaks or whitespace in between them in the HTML. Otherwise, that space will be rendered as a literal space and the second half will break and fall down.

http://jsfiddle.net/yrvvbva0/5/

Using Flexbox

http://jsfiddle.net/yrvvbva0/6/

em-based media queries use

It’s not a disadvantage. EM units at the media-query level are not affected by html-scale because they refer to the medium: i.e. device-scale (outside the html). You can set html font-size in EMs too, which is logically consistent. User-set device-scale just means you can’t assume a PX value for anything in your design unless you specifically size it in PX (and even then often not); and that best policy is to set html font-size in EM or %, which is relative to device-scale, and then set anything inside the html scope in REMs, which is relative to html-scale. This forms a relative-size chain: nothing breaks, user/device-scale can be anything, and HTML font-size can be anything, media queries always trigger where they should.

If we’re going to be proportional…

A core tenet of Responsive Web Design (RWD) is fluidity and proportion. Instead of using fixed-width layouts, we enlightened web devs and designers use percentages in our CSS. Font units aren’t pixels or points anymore, they’re percentages (typically for top-level baseline reset) or, more often, ems. And yet the vast majority of us still write width-based media queries in pixels, e.g.:

@media all and (min-width: 500px) {}

@media screen and (max-width: 800px) {}

It’s a natural thought process: for windows or screens of particular width ranges, we want to flow our content in a particular way. This naturally seems like a pixel dimension. But, once again, to bring out my big hammer, what about when we look at things from a content perspective?

Folks who design for traditional reading media—where the content really is king—don’t center design decisions around the absolute width of content-holding elements so much as around the optimal line lengths for the content they’re flowing. There are some tried-and-true numbers one can shoot for that make for the “right” number of letters (and thus words) per line for comfortable human reading.

Thus actual column width is a function of font size and ems-per-line.

Baseline expectations...

You may have seen the rule of thumb (useful, admittedly!) that makes the following general equation in terms of baseline font sizes in CSS:

100% = 1 em ~= 16px ~= 14pt

This means that, at your baseline, that is, before you’ve adjust font sizes in any child elements, the default font size in the browser is usually approximately 16px and usually approximately 14pt but always 100% and 1em.

If we start from a baseline of 16px, you may well wonder what the difference (beyond academic) is between a media query like:

@media all and (min-width: 400px)

and one like this, that uses ems multiplied against the 16px baseline approximation:

@media all and (min-width: 25em)