Here is a document I've been building over the past year while working on CSS files based on ems for dimensions.
Let's say you want the text in <div id="foo"> to have a font size of 14px, while its parent div has a font size of 16px. In ems, this translates as (target size)/(context size) = 14 / 16 = 0.875em. What I used to do was reach to the calculator app each time, and copy paste the result in my css.
At some point I realized I was often calculating the same sizes over and over again; storing these recurring sizes in a document allowed me to refer to it for a quicker copy&paste, resulting in a less tedious workflow. Project after project, little by little these tables completed themselves, and here we are today.

Formating decisions

The value is followed by a semicolon: placing the caret after the colon of the css rule, a simple paste will finish the line, no need to type the semicolon at the end. In the case of replacing an existing value, placing the caret after the colon and hitting command+shift+right arrow followed by command+V proved to be a smooth keyboard ride.

The target and context in pixel sizes in the comments are here for two reasons: it made finding the right value in this reference document quicker(1) and it's easier to get back in the logic of the file when you haven't worked on it for a while — it lowers the em abstraction bar.

The 16px column is the first one, as it is the one I have been refering to the most, given it's the default font size in html documents. The following columns respect the logical order, but only even numbers. Odd font size contexts are not referenced here because I haven't been using them in my designs.

The file is available here on GitHub, so feel free to fill the remaining voids, and improve it whatever way you may find.

Happy em sizing everyone.

(1) the eyes don't have to grab the correct line from the target values in the left column and then follow this line to the adequate context column.

When developing CSS style sheets called with media queries, you will be more comfortable if you can identify two things at a glance: what's the queried context you're in, and how a given element is behaving with the properties you've been editing.

Let's say you have 4 contexts to work with: S, M, L and XL for example. While you choose the break points trigering calls to these contexts's style sheets, it's handy to vizualize in the browser when the switch is happening. Johann Brook's method is very clever as it uses the :before selector to generate a block above your page; targeted widths are displayed in plain text when you access the different contexts. While clever, displaying a large block above the layout can prevent you from fine tuning another element just below it. Also, do you really need to be reminded of the display sizes when you are the one editing them in the markup? Adding a background color to the body or any other relevant element proved to be as useful and less obstructive.

Adding a background-color to any element I wished to style has worked very well for some years now, and a little variation makes it useful to both track one element and display the queried context: pick one colour for each context and use shades of it for the different elements you need to visualize. 0to255.com by @jamesmadson makes it really easy.

Here is a fictionnal webpage presented in the stages you could go through using both of these methods.

• One – markup styled with common properties and background color applied to the body.
• Two – background colors applied to the elements you wish to track while you build your contexts style sheets.
• Three – context style sheets built.
• Four – final result with contexts displayed, for presentation purposes.
• Five – final result.

Johann's idea is very helpful when you need to collaborate and display the break points you choose. I'd reduce the footprint of the generated content though: less text along with an opacity brought to 0.5. Also, having the position set to fixed allows you to keep the context displayed if you have to scroll down.

body:before{
	content: "M";
	padding: 0.5em;
	display: block;
	text-align: center;
	background: yellow;
	opacity: 0.5;
	position: fixed;
	top: 5em;
	left: 5em;
	z-index: 99;
}

While we're at it, if you're using CSS Edit (and you should anyway), don't forget that you can merge your media queries style sheets as tabs in one window, and have your common styles opened in another window beside it. I'm only suggesting it because while I was working on Bureau's CSS, I played a lot with Exposé instead and felt stupid when I realized last week I could have used tabs.

If you'd like to comment or share some tricks you use when building media queried pages, link them to me via @thibautsailly and I'll add them here.

Desktop image by Hector Simpson.

Pedaling in the dust of rocket designers such as Ethan Marcotte or Andy Clark, I made this website's layout react to your browser window's width. If you play with the resize handle, you'll figure out what that means it if you haven't already. If nothing happens, download and use a modern browser. Blondes will smile at you in the street. It's very heartwarming, you'll see.

Through the use of the mighty CSS3 Media Queries, three different layouts are at your disposal on the desktop (design choices will be detailed in a coming post). If you use an iPhone or an iPad, lucky you : there's a layout for each orientation of these two devices. I'm aware this looks Apple centric and not really opened to other existing terminals, but if I had some other mobile devices at my disposal I would have worked to ensure a compatibility towards them. If somebody in Paris is reading this and owns an Android device, I'd be happy to have some feedback and/or borrow some minutes with the device. Same goes for the "Retina Display" optimizations : they won't be there until I get a hand on one. My birthday is coming though, there's hope.

Anyway, every layout was optimized for your reading comfort. In the case of the iPad, I made sure that there was a sufficient margin on both sides of the text for comfortable thumb swiping, in either orientation.

It still needs polish, but I needed to publish. Improvements will happen, iteratively.

Here are some useful links I found while putting this all together :

• A list apart : responsive web design – the article that started it all, with one excellent illustration.
• Safari reference for web content – essential if you want to understand how web pages are rendered on the iPhone/iPad, and what you can do to control it.
• Fonts for iPad and iPhone – nice and handy list of fonts available for both platforms. I was going to go for Palatino bold on the headings, but does the antialiasing sucks on the iPad for this one.

For any comments, please use the Twitter, thank you.