Theme Tweaks & Responsive Design

Before we get back to our regularly scheduled blogging, here’s an addendum on my recent host change plus a brief discussion of “responsive” design and modern CSS sizes.

First, the Akropolis is back! The page did look rather bleak without its colorful header image, and I compensated by rearranging the header text and cutting excessive vertical whitespace. Body text size increased from 14px to 16px, the same 100% default size I always used on my website. Other text was scaled accordingly, typically to 14px or 87.5% of body text. See the section on “responsive design” below for more details on sizing & scaling.

The import of old posts didn’t work quite as flawlessly as I thought. Looking at a post containing Windows file paths, I noticed that WordPress Importer had dropped all backslashes! I had to reinsert them manually from my old export file. Hopefully this bug will get fixed soon.

Replacing Open Sans with Georgia and Trebuchet MS brought up another unexpected issue. Open Sans is a web font, retrieved from Google’s servers at every page load. Twenty Twelve couldn’t know that I no longer needed that font, so it kept fetching Open Sans – evident from a meta link to in the HTML page code. As I couldn’t seem to disable font loading, I just deleted the entire block (lines 118-140 in functions.php for Twenty Twelve 1.1; lines 97–121 for Twenty Twelve 1.2).

Atom/RSS Feed Statistics

Jetpack provides visitor statistics as promised, but I discovered two drawbacks. The smaller is that only the stats viewer can distinguish views from visitors, not the on-site viewer. The bigger problem is that neither viewer shows any feed statistics at all. offers several feed analyzer plugins but with a catch: they log every view locally, using the same MySQL database that holds posts and comments. Unfortunately, my hosting contract explicitly forbids logging or other heavy write load on the included databases. (Jetpack stores its statistics at which is why that feature requires an account.) Rather than risk my host’s wrath I’ll be content with my regular server logs. They record total feed downloads and views referred from the feed – vague but better than nothing.

Responsive Design

Twenty Twelve is a “responsive” theme, meaning that the page layout automatically adapts to small browser viewports in smartphones and tablets. Now that I had a live example, I decided to make the old Kynosarges website responsive as well. As described in Peter-Paul Koch’s overview Combining meta viewport and media queries, this requires two changes.

1. Prevent Desktop Emulation. Mobile browsers expect websites to be designed for desktop browsers, so they emulate a desktop-sized viewport by default. Page layout is performed on that big virtual viewport. The view is initially zoomed out so that the whole page fits on the screen, and text is correspondingly tiny. Users must zoom in and scroll around to get the same text size as on a desktop browser. Responsive design makes desktop emulation unnecessary, so we suppress it with the following HTML directive:

<meta name="viewport" content="width=device-width" />

Some authors like David Calhoun recommend appending initial-scale=1.0 to the content attribute, but it’s not clear why forcing this value is better than letting the browser select a default scale. So both Twenty Twelve and my website use viewport exactly as stated, without any scaling attributes. 2013-09-06: Javier Usobiaga’s Stop using the viewport meta tag (until you know how to use it) is an excellent discussion of this tag and its abuses.

2. Adjust Mobile Layout. Now we must ensure that our page content actually fits that small mobile viewport we’ve requested. Phone screens can comfortably show only a single column of text, so I must remove the sidebar from my text-plus-sidebar layout. This is accomplished by the following CSS media query:

@media print, screen and (max-width: 650px) {
    div.index { display: none; }
    div.article { left: 0; }

That’s for a sidebar on the left (div.index) followed by page content on the right (div.article). For screens no wider than 650 CSS pixels, we hide the sidebar and move the content to the left edge. Incidentally, that’s also exactly what we need to do for print output, so the pages are now nicely printable as well. Twenty Twelve features similar directives, although they are rather more complex (and the sidebar is on the right).

I’m using 650px rather than Twenty Twelve’s 600px because that covers smaller tablets such as the Nexus 7 in portrait orientation (603×797 px). That device’s landscape viewport size is 966×444 px, by the way – see e.g. David Thatcher. “But wait, the Nexus 7 has 1,280×800 pixels!” Yes, but not CSS pixels…

CSS Pixels & Root Em

CSS “pixels” started out as physical screen pixels but that hasn’t been true in a long time. For starters, all modern browsers feature a zoom function which physically enlarges px units. Desktop browsers should also factor in the current monitor DPI so that 1px equals roughly 1/96″ at 100% zoom. CSS pixels tend to be physically smaller on mobile devices, but manufacturers take care to keep them human-readable. Apple doubles px sizes on “retina” screens while others use a 1.5 multiplier, or even an orientation-dependent multiplier like the Nexus 7. See the explanation at JavaScript Kit and the comprehensive lists at Screen Sizes or i-Skool for details. Generally, you should treat CSS pixels like WPF device-independent units: assume that 16px equals the default text size, i.e. 1/6″ or 12 typographical points, and trust browsers to scale them to an appropriate physical size.

Specifying font sizes in CSS pixels disables Internet Explorer’s text size controls, though. Using em sizes instead is not a good idea because em refers to the current font size, leading to unexpected compound scaling. Jonathan Snook’s Font sizing with rem outlines the situation and presents the solution: CSS 3’s new rem size. This “root em” always refers to the em size specified in the root html element – and allows text size selection in IE9/10 if that root specification was a percentage value. The drawback is that older browsers don’t support it, in particular IE7/8, so Twenty Twelve and my website’s CSS specify sizes both in px for those older browsers and then in rem for newer browsers that understand it.

Other Considerations

Making the website responsive required a few other changes. I had wrapped wide tables in resizable scroll boxes using a bit of JavaScript code. That still worked, but I found I had to attach the resizing handler to window.onload in addition to window.onresize, presumably to avoid belated resizing to an already widened viewport.

I had been using smaller tables to format some term/definition lists so that their terms all occupied the same width. That layout fell apart on tiny phone screens where table cells were either too wide or showed ugly line breaks, so I restyled them as ordinary lists. For a few very short terms I used span elements with display:inline-block to keep a fixed width, though.

2014-02-15: I switched the main website over to my WordPress theme, arguably a much simpler solution. The analysis above still applies, though.

Leave a Reply