Help understanding EMs in responsive web design

Many articles often advocate using EMs as a unit of measure for responsive web design.

But why? After building my first responsive web design, I don’t see how EMs are useful at all.

In theory, using Ems means that if you drop the font size, the layout will shrink accordingly.
However, in practice, when creating a responsive design, you have to redefine the values of the layout for smaller screen sizes anyway*, so using EMs doesn’t really bring any benefit.

A particular disadvantage of using EMs is that the size of an EM is relative to the parent element. This means if you have a design which has several nested elements, it can become very tricky to keep track of what the actual size of an element is. REMs (relative ems) are a solution to this, but they don’t work in IE6-8.

When building my first responsive design, I used Sass to perform the EM calculations. That way, I could work in pixels and then output everything as EMs. However, this wasn’t a perfect solution, as when debugging with Firebug, all the values were displayed in EMs, which made debugging cumbersome (compared to using pixels).

In short, I can’t see what the benefits of EMs are. I am tempted to stick to pixels and percentages for my next project (using pixels for fonts and a combinations of pixels and percentages for layout).

Because so many articles recommend using EMs, I think the problem is probably with me failing to understand them.
So, I would greatly appreciate it if someone could give me some pointers about EMs so I could better understand them.

*For example, if you have a 12 column grid on a desktop design, you are going to have to re-design it to a 2 column layout on a mobile version.
Just dropping the font size is not going to work, as you could never get a 12 column grid to fit on a mobile screen.

(PS I am aware that EMs are useful if the reader want to increase the font size, as the layout will increase in size. However, most browsers come with a zoom feature which makes this benefit less compelling).

I would say that if you’re thinking in terms of a grid layout then you’ll probably struggle to get ems to work for you. They just don’t work like that. You’ll get the most out of ems if you stop thinking of the page as a grid, and start to think of it as a series of elements laid out in relation to each other and to (sometimes invisible) parent elements.

If you need pixel precision then ems are not the right way to go. If you’re always having to convert ems into other units to perform calculations, that’s not going to be a sensible strategy either. Different types of design work better with different types of units.

Sometimes you can use ems for certain elements only. You might have boxout/quotes floated down the side of an article – set the width of these in ems and they will always have roughly the same amount of text on each line, no matter what size the text is. Or you might just use ems for line-heights or paragraph spacing. Another good option if you go for a flexible width design is to set a max-width in ems, to avoid the page stretching too far on a large viewport.

I’d argue anyone saying em’s and responsive design are somehow made for each other is being silly. I use em’s whether I build responsively or not. They just make more sense (to me).

What does go together is flexible containers and responsive design. I’ve seen people write 5 or 6 different @ media queries for all these different devices, when they could have covered the same devices with 2 or 3 sets and let flexible containers do a lot of the rest of the work. I think.

But why? After building my first responsive web design, I don’t see how EMs are useful at all.

I would build a “regular” site in ems and carefully refrain from setting things like font-sizes on containers (set those on the actual text elements, then you avoid a lot of the “nesting issues” of ems) and play around with it on a type of design you’re already comfortable with in px. If you want to become more comfortable with ems. It would probably suck to try to switch to ems just because some article said you need them for responsive design.

You seem to be tying EM’s to the layout size as the only reason to use them – and have the ‘order’ in which things happen backwards. It’s not about the user increasing the font size in the conventional sense, so much as it is the fonts automatically enlarging in relation to the systems DPI setting; which is fixed at 96dpi on some devices, but some devices even default to larger and in Windows (which actually CARES about accessibility) can be changed system-wide. It’s favored for use so that the user doesn’t have to dive for the zoom to change it when the page loads in the first place. (something I often have to do which BREAKS many ‘fixed’ layouts or makes them useless)

I mean, of the four machines I use regularly, only one is 96dpi (my netbook); two are 120dpi (road laptop and workstation) and my media center Acer Revo is set to 144dpi… my old phone from a few years ago seemed to start at 72dpi. (which is close to the 75 default on old Mac’s and “real” Unix workstations, that Mac guys called 72 when it wasn’t)

But our Dutch kitty hit upon part of it – you’re still thinking in grids; which to be honest is a MISERABLE /FAIL/ at web design and reeks of your typical “But I can do it in Photoshop” nonsense… It means you are thinking layout as you make your markup or even before you make markup which to me, well… is putting the cart before the horse. Using a few standard section containers I typically write 99% of my complete HTML semantically before I even THINK about the layout – that way I can build the layout in CSS that fits the content, instead of shoe-horning the content into a layout it may or may not even be compatible with. (which explains the result most people seem to be sleazing out and calling websites these days!). Suspect it’s also why I NEVER have the issues with header orders some people seem to complain about (that resulted in the HTML5 idiocy of “lets make everything a H1”)

Seriously, if you’re playing around with “grids”, you’re already shooting yourself in the foot with fixed width nonsense and you’re NEVER going to get EM’s working properly. That’s why fluid and semi-fluid are SIMPLER THAN FIXED WIDTH AND GRIDS!!! Yes, I said SIMPLER, because you can just set your section/column widths to whatever makes sense for the sidebars, and leave the main column to dynamically adjust to whatever’s left over. I KEEP hearing people call fixed width ‘easier’, and to be frank I keep going “HOW?!?” - unless of course you’ve got some PSD jockey trying to turn their goof assed pretty picture into a viable layout, something I’ve rarely if ever seen actually work right if you care in the least about accessibility!

It’s why as she said you’ll often see people with five or six (or ten) media queries in their code to do something that could be done with two or three if they just designed fluid in the first place.

But of course, you’ll always have the people who “need” non web-deployable nonsense like fixed height or fixed width containers in the content area or across the whole page; IMHO what they really need is a good backhand. Sorry, is my total disgust with the industry as a whole seeping through again?!? Draw a goofy picture, crap it into a fixed width layout that is useless on pretty much every machine I own, with non-semantic markup in document types that show they have their head wedged permanently up 1997’s backside (like HTML5) with piss poor color contrasts and absurdly undersized fixed metric fonts – that’s a plan for victory, right?

I swear, 99% of the design ‘issues’ people have when it comes to SIMPLE MALFING THINGS like font sizes and dynamic widths (what we called it for a decade BEFORE the stupid “responsive design” label was slapped on it for no good reason) are more akin to the old Marx Brothers joke “Doctor, Doctor, it hurts when I do this…”

Grids… To be brutally frank every time I even hear that mentioned I feel the need to strangle somebody. Just more “but I can do it in photoshop” nonsense.

Stephanie Rieger makes a point about container flexibility here: http://stephanierieger.com/the-trouble-with-android/

I think this may be the idea article writers are getting the “use ems for responsive design” from. Em’s allow a type of flexible container, but that’s not the only method.

Regarding grids, I’m sure some standardista somewhere has made grids work flexibly. I don’t know how, since I don’t use them, but I can’t imagine grids getting the hype they get from standardistas if they always failed horribly at responsive layouts.

You mean like my current width stack?


#pageWrapper {
	min-width:734px;
	max-width:72em;
	width:95%;
	margin:0 auto;
}

Or how to drive completely nutters the people who can only think in tables?

Did I say tables? Don’t I mean grids? NO, because grids is just tables without the table tags so far as I’m concerned. As Dan used to say “the people who used to just make layouts out of endless nested tables for no good reason now just make endless nested DIV for no good reason” – In a way I’m glad he never lived to see so many people jumping on the HTML5-tard wagon slapping endless pointless containers like SECTION, HEADER or NAV around tags that ALREADY HAVE SEMANTIC MEANINGS for no good reason.

Your first post ninja’d in before my Stephanie link got in there.

But yes, there are units like % and properties like min/max-* as examples of flexibility without being limited to em’s.

I used that example (which is what I use on new pages these days) explicitly because it uses all three – em max-width, px min-width, % width.

Min-width being for the device (which is handed off to narrower sheet using media queries anyways, included mostly for browsers that don’t know media queries for width) so that’s naturally in px.

Max-width being to account for the dynamic nature of %/EM

and the width in % since I like a little bit of margin on wider screens, and it trips haslayout in legacy IE.

I also tend to use “* html #pageWrapper” to send legacy IE (5+6) a 752px fixed width. Sucks to be them, oh well… Not even bothering to send them expressions anymore, but that doesn’t mean the page won’t still at least be usable for them.

That’s the combination that offers the maximum flexibility. The width is sized to the viewport primarily (meaning that most of the time all the content will be visible) with the minimum making sure that fixed size content such as images will not break the layout and the maximum making sure that lines of text don’t become too long to easily read.

Thanks for the replies. There are some really good points raised!