This article is a brain dump from last night’s event.

CSS3 media queries let us adapt CSS rules to different viewport properties; width, height, pixel ratio, even colour and monochrome screens (full list). Aside: the Amazon Kindle (which uses webkit) reports itself as colour, with 8 levels, rather than monochrome.

The common process is to design for the desktop and use media queries to adapt downwards. On thinner devices content is linearised, navigation moves to the top or bottom, less important elements are sometimes hidden; everything is simplified down to the page’s core use case.

A number of tutorials have offered up the exact pixel-based media queries needed to target specific devices, a sort of restricted browser sniffing. This isn’t truly progressive, you can never cover all devices, and devices change, revisiting code for device iterations isn’t going to be fun.

Media queries don’t need to be pixel based either, changing a page layout based on ems will adapt content for larger text sizes. If the user’s text size is huge, our viewport is the same but we’ve got less space to play with, a linear mobile-like design might be more desirable.

This act of adapting downwards works for devices like the iPhone and iPad, but what about those that don’t support media queries? They’re going to get the full desktop version and it’s not going to be pretty.

Luke Wroblewski has suggested designing for mobile first (an excellent read). In terms of responsive enhancement that means creating your linear site as the baseline and building outwards around content, bringing in features as capabilities improve and constraints are relaxed. As the viewport widens, media queries can introduce columns, rather than remove them. It’s the same process but in the opposite direction.

All mobile devices and older browsers would get the simplified, linear design. This works on the assumption that desktop browsers support media queries, IE 8 and below do not, ergo they’ll be seeing the linear site design. This may be acceptable, but in the majority of cases IE will need some sort of hack to get the full featured version.

Using conditional IE comments an IE layout can be hacked in. The IE specific styles are likely to repeat existing code, undesirable, but unavoidable? This is still a one size fits all approach as IE will not adapt to screen or text size. For this we need a JS poly-fill, one that enables media queries in older browsers. There’s a library on Google Code that does just this, CSS3 Media Queries JS.

Building a page that can be linearised means putting the most important information first in the source code. This assumes that the context of “what is important” is similar on different devices. If the context is different, that makes a case for serving different content, usually via a standalone mobile site (which should always come with a link to the full version).

And on the topic of serving different content, there is also the speed problem. Hiding and showing parts of a page using CSS is great, but it doesn’t stop the slower mobile networks from downloading the unnecessary parts, including those huge background images. PPK has written an excellent article on combining media queries and javascript to avoid some of these caveats.

To round this brain dump off, I’ll recommend some other articles on the subject, which go into some of the technical aspects in a little more depth.

Ethan Marcotte’s “Responsive Web Design“
Jeremy Keith’s “Responsive Enhancement“
Yiibu’s “Rethinking the mobile web“
PPK’s “State of Mobile Web Development”

Inevitably coming back to “FofR Online” after such a long period I wasn’t happy with the site, and I’ve committed the web faux pas of changing the design and the domain name at the same time. I’ve dropped the rather meaningless “FofR Online” pseudonym in favour of using my name as a brand. All pages now redirect to paulrhayes.com.

This site is my first experiment with TypeKit and web fonts. I’ve chosen to use Museo for headers and Swing dancer for my name. I can’t say I’m entirely happy, but if I waited for that I’d never release anything.

Update: I have slightly altered the content’s stack to begin with Apple’s Times font rather than Times New Roman, mainly for the superior glyphs that it offers, take for instance ‘fi’ in this post’s title. I’m attempting to research the differences between Times and Times New Roman beyond a simple comparison though internet sleuthing has not proved fruitful.

I’ve spent a short amount of time researching leading, kerning, the measure, et al to improve the legibility of the content region (e.g. The Design Cubicle). I’ve increased the CSS line-spacing and slightly upped the word-spacing to make the content area more readable. The design’s horizontal dimensions are all defined in ems, so the page scales correctly with changes in font size — always maintaining an appropriate measure in the region of 78 characters, ‘a couple of alphabets’ — a good rule of thumb for legibility. The vertical alignment in the header uses pixels to keep the desired appearance. The header image uses the text-indent text replacement technique and a transparent PNG that uses Helvetica Neue to achieve a consistent branding style across platforms.

Mark Boulton states that the leading should increase proportionately with the measure. I am tempted to create a small JavaScript project for a fluid web layout that dynamically alters the CSS line-spacing of the content based on the width of the window and hence the measure; just to see how things change. I think the first problem may be deciding the scaling factor to apply to the line-spacing.

One of the biggest caveats of creating a design that strongly relies on the beauty of fonts is the difference in Windows and Apple font rendering. Take for instance the screen capture below which compares Windows XP (Left, IE7) with OSX (Right, Firefox 3). My preference is towards Apple’s stylish approach that attempts to match print, versus Microsoft’s pixel jamming but easier to read pragmatic rendering. By using fonts as the predominant styling force on the page it is clear that in this case the Apple approach is superior. Joel on Software has a very nice article that makes a good comparison between the two.

Areas still left to develop include the right hand columns, a proper grid layout and the footer, I have put these aside until next week.

This blog has been devised as a spring board for my ideas whilst serving as a professional outlet for my skills, thoughts and collaborations. If I were to include some buzz words in this opening blurb to describe the content I’ll endeavour to put here I might include; CSS3, HTML5, Information Architecture, User Experience, Unobtrusive JavaScript, Prototype & jQuery libraries, SEO, web analytics, OOCSS, progressive enhancement, accessibility, rapid design prototyping and internet marketing.

As an exciting starting point, rather than build my own WordPress theme from scratch I have opted to use the excellent Sandbox theme — ‘beautiful on the inside’. With its hugely powerful class-generating functions Sandbox creates clean and accessible markup with a huge array of context sensitive CSS selectors, creating an ‘exceptionally extensible foundation’.

For more information on the Sandbox WordPress theme I recommend checking out the official Sandbox website hosted at plaintxt or the project home on Google Code.