This is the archive of version one, made in 2006, launched in 2007, and active until 2012. It’s archived to preserve the original design and its content that was referenced in multiple posts, books and galleries. There’s a holding page before the new site arrives.

Entries tagged with ‘interface design’


  1. PHP Advent Seasoning

    Ladies and gentlefolk, I give you the two-thousand and eight PHP Advent Calendar!

    PHP Advent Calendar screenshot.

    As an aside in a season that gets rudely interrupted every year with a huge, great party, the PHP Advent Calendar is adding to the fray. Some of the denizens of PHP are sharing their wisdom from a beat-up old soap box in our quiet, geeky corner of the Web.

    The entire project was launched in a mad, two-day rush, which featured the guys with real talent setting up the server, propagating the DNS, and gathering the initial content. A couple of days after the first article, for my sins, I applied some style to the interface. Twenty-four hours of key-smacking later — and with a good dose of help from the indomitable Jon Gibbins — it was done.

    The project is edited by Chris and Sean with nuts and bolts help from Jon. It is kindly sponsored by OmniTI. I have to tell you, with almost no time to get it done, deadlines looming, colleagues sweating, and the world in general turning far too fast, I’m pretty pleased with the result.

    A single typeface is used throughout. It changes depending on availability, but this seemed like a good opportunity to stretch a face or two. (Writing that made me smile.)

    Although we would have loved to license and use various typefaces not currently available in operating systems, there just wasn’t the time. Without knowing the full range of glyphs the content might need, the faces currently licensed for @font-face linking (many with slightly abridged character sets) might not have had the range we need. So, I chose Baskerville as the primary face with various fall-backs from there. Hopefully the epidemic of the Baskerville italic ampersand will ebb soon, but there are many worse things in life to see on an almost daily basis.

    You might notice the use of the golden ratio, and an attempt to coerce our awkwardly independent browsers into rendering a baseline grid.

    As always, the content was king, queen, barkeep and god: I veered away from images as decoration, considering them unnecessary. I hope nothing overshadows the reading experience. With that in mind the interface is fluid, with a minimum width to stop it all collapsing into a narrow abyss. Most significantly though, the content is genuinely interesting. There are some choice pieces over there, and if you’re interested in PHP at all, swing by, grab the feed, or follow ‘phpadvent’ Twitter for fast updates.


  2. @font-face in IE: Making Web Fonts Work

    All Hallows’ Eve seems the perfect time for something a little spooky. Getting @font-face working in IE may just be spooky enough. As you probably know @font-face already works in Safari 3 via WebKit and is supported in the latest Firefox 3.1 beta. With IE, that means around 75% of the world audience could see custom typefaces today if their EULAs allowed it. Fortunately, there are good free faces available to us already, as well as some commercial faces that permit embedding. Fontin is one of them and I’ve built it into this example page:

    Before we get into the nitty-gritty of making this work, which you can skip to if you wish, I thought a little history and a brief summary of the current status of the web fonts debate might be useful.

    Web Fonts: Then & Now

    Web fonts have been with us for a decade. They were an original part of the CSS2 recommendation in 1998. Recently, the godfather of CSS, Håkon Wium Lie, brought them sharply into focus with articles in CNet and A List Apart. The ironic thing is, IE has supported web fonts using the Embedded Open Type (EOT) format since 1997. The problem was that EOT was a proprietary format, belonging to Microsoft. Not for much longer: it’s been submitted to the W3C and is going through the process towards becoming a web standard.

    Since the debate opened up, the web and type communities have both been busy discussing how the future will unfold. More collaboration between the disciplines would be beneficial to both, and I’d encourage any interested designers or developers to get involved with organisations like the Association Typographique International (ATypI).

    Recently, Bert Bos of the W3C paid a visit to the ATypI Conference in St Petersburg to meet with type designers face to face. His summary of the current situation is essential reading. The debate has continued apace on the ATypI mailing list, which unfortunately has no public archives. However, if you are member of the ATypI, you can see this summary about the conference panel on web fonts by Nadine Chahine that started the debate in earnest. Simply put, type designers seem anxious about @font-face linking making it too easy to steal a font. Both Microsoft’s EOT format and direct font linking are under consideration with EOT a favourite with many. However, rather than paraphrase a wide-ranging set of opinions, I’d encourage you to join the ATypI yourselves as designers and developers to participate or observe.

    If you have other favourite comments or posts about the future of web fonts, please add them to the comments.

    As a designer, I want a straightforward way of licensing and including fonts for my work. I will pay, respect the rights of type designers as I expect mine to be respected, then get on with the glorious business of merging content with type. It’s not as simple as it sounds, though. The licensing of fonts, and the protection of the rights of smaller designers in particular, is a sticky issue. DRM does not work, so what then? Richard Rutter has shared thoughtful insights which are very much worth a read. My view is that I would be perfectly prepared to pay a separate or extra licence fee to use quality fonts on the Web. I would have no problem selling this to my clients. Embedding or linking to fonts has to be straightforward though. I get paid to think about, plan and implement design, not grapple with obstructive software (more on that later). If fonts were delivered through a third-party web service as Richard suggests, the one proviso must be that it would have to be done by someone who knows exactly what it means to scale a service for millions of users. Like most designers though, I have very little knowledge of the real security and scalability issues, but hope to see a comment from a real security expert, shortly.

    User agents are currently taking divergent routes. Bert Bos’ summary reports:

    Mozilla has stated that they don’t want EOT. But they are not opposed to letting the browser check the license, as evidenced by the proposal to let HTTP headers carry license data.

    Microsoft has said that it is impossible for them to support linking to native OpenType as long as font vendors oppose it.

    Apple’s Safari has implemented font download with no checking of licenses. They said they are against EOT, but would not be against browsers checking licenses, e.g., using Mozilla’s proposal.

    Opera remarked that there are more existing and announced implementations for downloading native OpenType than for EOT. They conclude that the market apparently doesn’t need EOT and thus they see no need to support it themselves either. W3C’s limited resources should be spend on more important standards.

    That means that designers and developers have the same perennial problem: Two different implementations to achieve the same result. Safari 3 and Firefox 3.1 beta both support direct linking to OpenType (.otf) font files. Presumably Opera will soon. Only IE 4 to IE 7 support Embedded Open Type (.eot) files. IE8 does not, but will at some point. So, to see Fontin display in standards complaint browsers like Safari 3 and IE, we need to provide two separate fonts.

    @font-face Example

    The @font-face example uses Fontin Regular by Jos Buivenga — a free face kindly provided by Jos with a licensing permitting embedding with attribution. Jos also has many other fine faces available via his foundry site, Exljbris. The example is a quick one using a traditional scale, with all of the CSS available in the <head> of the file.

    1. Set the basic font-family:

      h1, h2, h3, p, td{
      font-family:'Fontin-Regular', georgia, serif;

      Notice the 'Fontin-Regular' name — this is an arbitrary name that can be whatever you like. All it does is tell the browser when to apply the font file referenced in the @font-face rule.

    2. @font-face and .otf for standards compliant browsers:

      Ed: White space inserted for clarity.

      src: url('Fontin-Regular.otf') format('opentype');

      Note the 'Fontin-Regular' name, again. This rules basically tells the browser, when the @font-face is set to 'Fontin-Regular', use the font found at this URL.

      Screen sample of Fontin Regular in Safari 3 set at 16px with 24px line height from the example:

      Fontin in Safari 3

      When Safari renders the page, it will look for the font file, then render the text accordingly. There’s a slight delay as WebKit works. In the example you might notice that the text not requiring the loading of a font file renders quickly, but the rest is blank until the browser catches up. For reference, the Fontin-Regular.otf file is 32KB in size. Some font files can be much larger.

    3. Create the .eot file with WEFT:

      To do this you will need to download and install WEFT3, a Microsoft application for creating EOT files from TT fonts. WEFT is not able to create EOT files from an OTF. It must be converted to a TrueType file, first. WEFT is the only tool for this as far as I’m aware, although I believe there is an open source one in development. If it wasn’t for WEFT, embedding EOT files would be easy. What I want WEFT to do is convert the font to EOT, and allow me to create a subset if required. It does that, but in a nightmarish, frighteningly over-complicated way. Perfect for an All Hallows’ Eve entry. Here are a few tips I learnt the hard way:

      1. WEFT requires the URL of the page or site where the EOT font will be used. It will then ‘scan’ the pages by crawling the site to see what glyphs are used and try and create a subset of the EOT file accordingly. If it refuses to analyse a valid URL as it did for me, get granular and specify pages or sub-directories in your information architecture.
      2. If you’re using WEFT via Parallels and XP Pro, it may refuse to add some fonts in your windows/fonts directory to its database of available fonts. Try using a standalone PC if you can. I haven’t tested in any other virtual machine.
      3. Use the wizard to set up your project, but after that try it manually using the View menu item to see what fonts are available to convert, and the Tools menu item to convert them.
      4. WEFT will try to save the EOT file to a remote location. You can over-ride this manually to save the file wherever you please for you to upload yourself.
      5. Disable your original OTF fonts on your system before testing (obvious but worth a prompt).

      Be warned, WEFT is awful to use, in every way. It did not work for me running Parallels with XP Pro on a Mac. 7th Nov: After more experiments, Weft will accept TrueType (.ttf) files in Parallels. It also worked with the gracious help of Jon Gibbins and his standalone PC running XP Pro. Because it is so painful, I cannot give support for WEFT. You can try the Microsoft WEFT user community, but I can’t comment as to its usefulness, and I could not find any other support avenues.

      Hopefully, you now have an .eot file to use.

    4. @font-face and .eot for IE using conditional comments:

      Ed: White space inserted for clarity.

      <!--[if IE]>
      <style type="text/css” media="screen">
      src: url('Fontin-Regular.eot');

      These are screen samples from IE:

      Screen sample of Fontin Regular in IE6 set at 16px with 24px line height from the example:

      Fontin in IE6

      Notice the bar missing from the capital ‘A’ towards the end of the second line. The tyepface designer, Jos Buivenga is currently looking into the font hinting, with input from John Boardley.

      IE7 sample:

      Fontin in IE7

    See a full size Safari 3 screenshot, and IE6 screenshot on Flickr.

    That’s all! Try the example in different browsers to see how it works for yourself (but please don’t blame me for ClearType’s poor anti-alias at larger font sizes).


    We have only a few web fonts with a EULA that permits embedding right now, unless they are free. Please respect the EULAs of any typefaces you try out until the type community resolves the issue for all commercial fonts.

    My feeling after doing this is that EOT has potential advantages in file size over OTF, but OTF files could always be edited (as far as I’m aware) to create subsets just like EOT. Although EOT is not a DRM solution per se, it feels like one. If it achieves widespread acceptance, no doubt some clever soul will be reverse-engineering an OTF file from EOT before too long.

    What we need to encourage designers and developers to use EOT today is a good tool to create EOT files in the first place. Perhaps even one hosted remotely, where we can buy a licence, convert the font to EOT, grab the same OTF subset for complaint browsers, and get the work using the typefaces we’ve always dreamed of. WEFT is not the tool right now to enable EOT usage. In fact it discourages it.

    Regardless of what security is implemented, the font file will have to be on the audience’s machine somewhere, even temporarily. ‘Defense in depth’ is a term used by web app security experts. It would seem that the question is how much depth will satisfy foundries and type designers, and what form that depth will take.

    As a designer, I can only speak for myself to say that if OTF and TTF were supported, regardless of how easy it was to steal the file, I would still pay as required by the EULA. I have a strong feeling the vast majority of my colleagues feel exactly the same.


  3. Early Reflections on Google Chrome

    Google Chrome screenshots

    The world is abuzz with the imminent release of Google Chrome today. The screenshots on CNet were apparently from the new site that was live for a short time. The news slipped out (or leaked) when, according to the Google blog, they “hit ‘send’ a bit early” and released the Google Chrome comic strip prematurely.

    The comic is a great piece of work by Scott McCloud. It’s a gold-mine of interesting propaganda, and I’d love to link to some of my favourite sections but there’s a critical failing: none of the pages have a permalink! Some kind soul has taken the time to republish the strip so they can be linked although the site was slowing down already when I last visited.

    Does the world need another browser? Do we need another browser to test our work on? Those seem to be the questions I hear first. However, Chrome is built on WebKit, the open source engine that also powers Safari. Safari is also my browser of choice right now — WebKit passes the Acid 3 test and Safari has the best font rendering of any browser I’ve tried — so that gives me hope. Also, Chrome will be open source, and with a few new ideas may push browser science along a little bit in a good direction, especially around security, performance and the UI.

    When I heard the name, it reminded me of the DHTML tricks we used to use way back to remove the chrome from the browser window — effectively stripping it of everything that wasn’t content. Google has said:

    “We don’t want to interrupt anything the user is trying to do. If you can just ignore the browser we’ve done a good job.”

    I do a pretty good job of ignoring the browser already. However, there are problems we’ve all been working around for a long time that Chrome wants to solve. Most of the advances have a visual metaphor in their approach to tabs. Here are some of the things that caught my eye:

    The tab is king

    Tabs will be at the top of the browser window as they are in Opera, making utilities like the address bar part of an individual tab. It makes sense to me: Often I find, when talking to less technical people and trying to get them to go to a URL, they’re so used to ignoring the address bar that I have to help them find it before they can start typing. Google don’t have a URL box though, they have an “omnibox” that does everything from remembering visited URLs to giving search suggestions and allowing us to do free text history searches. It also does autocompletion. The comic strip explicitly mentions getting this right but, just in case it doesn’t, I hope autocomplete can be toggled off.

    In Chrome, the browser controls and URL box are explicitly associated with that unique tab. Everything associated with the site open in the tab is contained within it so it can be moved or detached completely from the window.

    However, people often ignore the page title, too. In the past, this has led to all sorts of wacky, useless and inaccessible page titles being used by developers to stuff keywords or just have fun. I would of liked to have seen the page title better associated with the viewport, and visible in full, not just as part of the tab label.

    Oi, JavaScript, stop!

    How many times does an errant bit of JavaScript slow down the browser to a crawl and sometimes even crash the whole caboodle? Too many times. Chrome has a whole new JavaScript virtual machine dubbed V8. It also claims a multi-threading approach that sandboxes each individual tab so it won’t affect other open tabs, which allows us to close it and kill the process if it’s getting out of hand. They’re also giving us a task manager to enable us to see which tabs or plugins are causing problems by seeing the processing running and how much memory they’re using. Sounds good to me.

    Confined pop-ups

    Chrome will associate pop-ups with each individual tab, and confine them within that tab unless people drag them out to become a new window; an enhancement to just blocking all pop-ups altogether when some are used for legitimate purposes.

    Default tab page

    When a new tab is opened, Chrome will open a tab page with nine of your most visited pages, search history, recently closed and bookmarks. It sounds like an evolved version of Opera’s Speed Dial (Flash demo), that automatically populates the holding page by default.

    Site-specific Chrome

    Taking a lead from apps I find incredibly useful like Fluid, Chrome will allow site-sepcific browsing to access sites like Google Mail in a streamlined window. Hopefully, we’ll be able to do that for any URL, and create icons in much the same way I can with Fluid now.


    Chrome would seem to take sand boxing to its natural conclusion, isolating individual sites from any other open tab, and not allowing access to anything without user permission. I’ll be interested to see what the web app security experts say about this, especially in relation to XSS and CSRF attacks. Chrome will also continually download blacklists for phishing and malware sites and warn users when they visit them. Those lists will also be open source.


    I can’t talk about a new browser without mentioning typography. The WebKit rendering engine already gives Chrome an advantage to build on for web type. All I want to say is that I hope they take a lead from the great work being done with things like @font-face support, and keep a beady eye on the most important thing a browser has to do: help us read. Hopefully, nothing in Chrome will limit the fine work the WebKit team are doing to make hinting, anti-aliasing, grid-fitting and hyphenation as good as they can be. Chrome will be released for Windows first. I’m looking forward to see how it reads, but how it integrated with OS X’s native text rendering will also be very interesting.

    One thing is…

    Google Chrome has already changed the browser landscape and it’s not released yet. We’ll see if all the web application savvy at Google Inc. emerges in the browser — I’m looking forward to it. After all, if we can’t just have one very good browser to design and develop for (oh, what luxury that would be), we may as well have another using WebKit — a rendering engine that’s committed to standards support, is open source, and doing a fine job already.


  4. The Paragraph in Web Typography & Design

    Paragraphs are punctuation, the punctuation of ideas. After selecting a typeface, choosing the right paragraph style is one of the cornerstones of good typography. This is a brief inquiry into paragraph style for the Web.

    To collect my thoughts I put together a rough page of examples. I was interested in openings and texture more than font style, so they all share the same basic copy, typeface, size, and leading (line height). It was mostly for my own reference and will change over time, but you’re welcome to take a peek:

    Typographers use layout techniques like single line boundaries, indents, outdents and versals (drop caps etc.) to punctuate paragraphs in a stream of discourse. Block paragraphs are common to the Web, indented paragraphs are common to print. Browser vendors gave us a default block style of flush left, ragged right with a single line boundary, but there are many variants we can pick from depending on the context.

    In any project, the text itself will have its own tone, rhythm and meaning. It’s our job to provide it with a stage on which to sing. Typography serves the spirit of the text, bringing it before an audience, and then quietly fading into the background as the reader delves into the meaning. As Ellen Lupton says in Thinking with Type:

    Typography is a tool for doing things with: shaping content, giving language a physical body, enabling the social flow of messages.

    In the Web era, designers create narrative spaces made up of text, images, video, etc. We add context and legibility to those formats. We also create spaces where people express themselves. We work with enacted narratives where the content is already available, and emergent narratives to be created over time. Instead of just styling symbols, we’re styling bytes in fluid narrative spaces. We’re bytographers; literally, the writers of bytes, not just glyphs. Yet still, at the heart of this explosion in publishing, is the humble and beautiful paragraph.

    From paragraphos to paragraph

    Punctuation is a word derived from the Latin punctus, to point. Punctus is also the precursor of the period, or full stop. Punctuation was called pointing in English. It was used to indicate pauses or breaths until the 16th century. Punctuation as syntax didn’t emerge until the Renaissance.

    A paragraph was historically a punctuation mark. According to the Online Etymology Dictionary, the word paragraph has roots in the old French word paragrafe from modern Latin paragraphus or “sign for start of a new section of discourse”. That in turn is based on the Ancient Greek word paragraphos, a “short stroke in the margin marking a break in sense". The great reference of the 20th century, the Encyclopædia Britannica says:

    In the oldest Greek literary texts, written on papyrus during the 4th century BC, a horizontal line called the paragraphos was placed under the beginning of a line in which a new topic was introduced. This is the only form of punctuation mentioned by Aristotle.

    This fragment of a parchment scroll shows a paragraphos (a) indicating the line where the new paragraph starts with a break in the text (b).

    Source: The ‘Textual Mechanics’ of Early Jewish LXX/OG Papyri and Fragments by Robert A. Kraft (University of Pennsylvania), The Manuscript Fragments, s.5: parchment roll, ca 100 bce; Rockefeller Museum, Jerusalem.

    Parchment roll fragment

    Medieval punctuation employed a paragraphus—also known as a “‘gallows-pole’ or upper-case gamma, or § (later ¶)”— to separate ideas in a running discourse.

    White space did not punctuate paragraphs until the 17th century. This was the era of Ben Jonson’s English Grammar, where he recommended the use of syntactic punctuation. Around that time, the practise of indenting the first line of a paragraph became part of our standard syntax, along with the use of capital letters for the start of a sentence, and the use of a space between words.

    Technology & cost influencing style

    Materials and technology have always influenced calligraphy and typography. Papyrus was used from the 4th century BC. It was brittle, so papyrus was rolled instead of folded. Parchment codices became more popular in the 5th century AD. The finest parchment was vellum, made from the white skin of a calf. Next came paper: Invented in China in the 1st century, the first latin text was written on paper around the 10th century. By the mid-15th century it was becoming dominant. Johannes Gutenberg printed only 45 copies of his Forty-two line Bible on vellum, using paper for the remaining 135 copies because it was cheaper.

    During the industrial revolution in the 19th century, cheaper wood-based paper emerged along with steam-driven paper making machines. Intuition tells me that also influenced typography. By the turn of the 20th century paper was cheaper than ever before. The cost of inserting a single line of white space between paragraphs—the most common style today—would have reduced. The emergence of the consumer society and rise of advertising also encouraged a change in typographic style. “Fat face” display type was created for bills and advertisements; hyperbole became a style of visual layout. Before the 19th century, the insertion of a full line of white space between paragraphs would have surely been decadent. Perhaps that’s how it became commonplace. However, this is speculation; I cannot find reference to how it became prevalent, so would welcome further evidence.

    The single line boundary is the most common paragraph delimiter used on the Web today and the most common browser default style. Generally, the indent is still the most prevalent paragraph delimiter in printed books and publications. In some ways, the block and indent styles exemplify the divide between Web and print. Printing cost is still a consideration looking at some of the mistreated text in certain paperback books, but printing on a screen effectively removes cost as a factor. Usability is the only currency by which web typography is measured. That’s what we’ll explore next.

    Paragraphs in a narrative space

    The narrative space of a web site is where a story develops as a person navigates the site. This should not be confused with narrative as a text-type. However, in some cases, it does share some characteristics like a chronological order. For example, a blog is a narrative, no matter how broken. It has a chronological order (albeit reverse). Even though a blog has multiple entry points, it can still contain a chronological story. The chapters in that story (entries) may be any one or more of the traditional text-types {narrative; descriptive; argumentative; expository;} but they all form the narrative space of the site.

    The narrative space within a web site is made up of three components: content, layout (style and context), and information architecture.

    Further reading:

    1. Mark Bernstien writing in his mis-spent youth about narrative on A List Apart

    Web design narrative can be compared to architectural narrative: The design of an environmental experience from multiple viewpoints in time and space. Visitors experience a web site in much the same way.

    Web design narrative can also be compared to narrative in game design: both create the narrative space via a screen.

    In both comparisons, the experience of the narrative space is more than just style and technology. In fact, style and technology are tools to create the user experience. The experience of moving through a narrative space on the Web is complex. We understand that people may arrive in that space from any direction and context (referrer). They may be confronted when they arrive with any number of artifacts that convey narrative information (navigation, main content, calls to action, etc.). Any paragraph style must consider context as well as the meaning of the text.

    Thinking about paragraph style

    The way we approach the design of a narrative space on the Web is manifold. In most cases the content is not already available. If it is available, it may be subject to revision as part of a redesign process. The vision of the brand and the purpose of the site can seem clear, but may not be upon further investigation. Sometimes, our job as designers is to help refine both the vision and content. It’s during that stage that we explore layout and get a clue to the context in which the typography will live. We call it experience design. Only after that do we get down to experimenting with style.

    The context, meaning and tone of web copy should always determine typographic style. Reading the text in full—or at least understanding what the text might be before styling it—is a pre-requisite. A common mistake is to allow the design to dominate the text: Design for design’s sake, or even worse, fashion’s sake. The text is made subservient to the canvas that the designer wished to paint on the screen. This is exemplified by the proliferation of fun, but ultimately harmful, web design galleries. Once a user muscles past the gag reflex, or stops admiring the amazing graphical decoration, they can often realise the design is in their way. The content is obscured. The narrative space becomes broken into fragments, like pieces of torn parchment linked tenuously together by calls to action, or a nested index of links called a menu.

    Good typography makes the canvas fit the meaning of the text, not the other way around. It paints pictures with form that enrich the meaning of the words with colour, texture and movement. It is illusive, subtle, and ambient. It’s the shirt that engages from a distance. The closer you get to it the better it seems, but it takes a moment of reflection to even realise why. Robert Bringhurst says it beautifully in Elements of Typographic Style:

    One of the principles of durable typography is always legibility; another is something more than legibility: some earned or unearned interest that gives its living energy to the page. It takes various forms and goes by various names, including serenity, liveliness, laughter, grace and joy.

    When trying to energise paragraph text, meaning and context are the most important factors to consider. Meaning flows from the author. They are trying to share a message, a thought, an idea. Context belongs to the audience. They are trying to understand, extract meaning and find relevance. They’re doing so in the context of their own requirements, but also in the context of the page layout and the wider architecture of the site. A refined sense of empathy will help you find the right form for your paragraphs, if user testing cannot be part of your process.

    Choosing a paragraph style

    There are no hard and fast rules for paragraph style for the Web. Choosing a style depends on all the factors we’ve previously discussed. The 12 example styles I threw together are just a starting point and all paragraph styles need testing in context.

    You may find this place holder markup useful when testing styles.

    All browsers have good support for basic paragraph styles. However, complex treatments of versals and openings can be problematic. There are still browsers with immature standards support when it comes to using techniques like pseudo elements and adjacent sibling selectors. Our ability to specify fonts for body copy is also limited, and inconsistent rendering across platform and browser persistently frustrates creativity and precision. There’s still a lot to work with, though. Here are a few examples, some new and some that are aging beautifully:


      Rob Weychert used indents to wonderful effect in his Across America diary with text set flush left and ragged right. He also uses a deft combination of indents and small-capped openings in his blog posts. Both are a pristine example of using indents to compliment his particular style of writing. Truly a great example of bringing a love of print to the Web.


      Ed Finkler mixes a font stack of Palatino and Palatino Linotype with boundaries that perfectly suit his content. He publishes a mixture of material that’s often technical, so boundaries help delineate the technical writing for skim reading, while the larger size and typeface adds great texture to his site. For the technical material I might have defined sub-heads a little more, but his choice of paragraph style is instinctively good.


      Andy Rutledge treats paragraphs with love. On his home page, extracts from the three latest posts descend in a beautiful hierarchy of size and tone to indicate the chronology. Individual posts also cascade gracefully. Boundried blocks define his thoughts with great clarity. His material is often instructive, so this style perfectly suits the content.


      Cameron Moll indents paragraphs and uses boundaries. This could offend pedants in print but I find it wonderfully pleasing on the Web. His material is often educational so the division of points by boundaries helps legibility. However, one of the main reasons this style works so well is the font size: it could seem small but the indent with a boundary allows the text to breathe and adds great poise and texture.

    A note on indents

    If you choose to use an indent, stylistic tradition suggests that there should be no indent on a paragraph that follows a head or sub head. Tradition also suggests there should be no indent following elements like lists and blockquotes. You can achieve this without extraneous markup using adjacent sibling selectors. For example, if you have already set an indent on your paragraphs:

    p { text-indent: 2.5em;  }

    Then, to stop any paragraphs following a heading of rank 1–3 having an indent you can set:

    h1 + p, h2 + p, h3 + p { text-indent: 0; }

    However, I would caveat that with only if the blockquotes and indents are set flush left with hanging punctuation. Robert Bringhurst suggests: “If your paragraph indent is modest, you may for consistency’s sake want to use the same indent for quotations.” I agree, and I think the same can apply to lists on the Web. In both cases, a boundary is required to separate the list or blockquote from the surrounding paragraphs.

    A note on blocks

    If you choose a block style with no indent, but with boundaries between paragraphs, tradition suggests that there should be no indent on either lists or blockquotes. As you may have noticed from reading this article, I don’t always agree, especially on the Web. It depends on the content and the balance of elements. In certain instances, lists and blockquotes might be used to punctuate the running text, which can help people skim read on the Web.

    Web != print

    People experience the Web differently to print. The Web is not linear; in print people most often read sequentially, from front to back. They may flip, looking for something that catches their eye. After an initial look, they may skip back to interesting items using a table of contents or an index. On the Web this is reversed. Skipping to a certain page via the menu is habitual. This has been encouraged by bad design and web copy writing where inline links in the running text are sparse, if available at all.

    Skim reading is the norm on the Web. It may well even be the case that skimming is normal everywhere, it’s only when we become absorbed that we digest the meaning of the text linearly. It’s a way of filtering the noise in a page to try and get to the content of interest. However, this has become essential because of bad design; pages have been confused with intrusive advertisements, overbearing calls to action, and layouts that don’t serve legibility. It has forced people to skim, whether they want to or not. Better designers refuse such harmful techniques. Getting layout and content right in prototyping is essential.

    Careful choice of paragraph style (and other body text forms) can accommodate all of the differences in audience behavior and expectations. The optimal paragraph style you choose in summary pages may not be the optimal one for dense, detailed pages. A subtle change may well be necessary in different sections of a site. Choose judiciously, but most of all, designers should know why they are choosing a particular form; “because it looks good” is not a good reason on its own; “because it feels good” may well be.


  5. An Ephemeral Site: Denna Jones

    Denna Jones is a designer, and we recently launched a site for her that is unlike any other that Jon Gibbins and I have done before. This is it:

    Screenshot of

    The evolutionary bit for us is under the hood, and to understand why, let me introduce you to Denna, herself.

    Introducing Denna Jones

    Denna’s fascinating to talk to because she is genuinely erudite. Her influences are as diverse as her roles. She’s a former Designer-in-Residence at Central St Martin’s College of Art and Design for the B.A. Architecture course. Currently, she’s Lead Artist for DLA Architecture’s Masterplanning Team, Deputy Editor of Art and Architecture Journal, and the Resident Curator responsible for delivering the arts strategy for the massive Devonport regeneration project. Most recently, Denna’s contributed to books like 1001 Buildings You Must See Before You Die and had an invitation to be the editor of a new tome in the series, 1001 Houses You Must See Before You Die.

    Luckily for us, Denna’s work with spacial narratives is often exploratory, so she was open to our newfangled experiments.

    A Web 2.0 problem

    Denna is also prolific around the Web. She documents her projects and travels using Flickr, and regularly reads, writes about, and observes Web culture as part of her work. So when she came to us to discuss a site it seemed to me she embodied a problem I’d been thinking about for a while: How can our domains be connected to our other personal accounts more naturally? Domains are our identity. However, much of what we publish is locked into other sites where we share it. It’s accessible by APIs at best, or clunky widgets at worst. Technical people can pull everything together but for non-technical people it’s not intuitive. Then there’s the issues of legacy content and copyright. Unsolved as yet, but looming. What will happen to all of our content in five, ten or twenty years time? Will we still have content strewn around the Web disconnected for the most part? Somehow we need to connect the dots. Maybe portable social networks are part of the answer, or Google’s OpenSocial. Whatever the answer, I wanted to include Denna’s existing content in her own site, and to make the future relationship between her Web activity and personal site as seamless as possible.

    Web services, say hi to

    The content on Denna’s site is delivered exclusively by Web services. We take advantage of the ability to share and manipulate data that those services provide to Denna, then let her choose what to publish on her site, and in what context. This is how:

    • Flickr is used to manage all images and some of the site copy direct from Denna’s account. That includes the main display images on the home page, the introduction copy on her work page, and the images and copy for projects. Work projects are managed via a specific Flickr collection, with each set being a project. This enables Denna to choose the display image and write a description that appears on the site. Visitors can also drill deeper via the project link to see other images that Denna has added to each project on Flickr.
    • Tumblr is used for Denna’s blog and her about page. The site archives her entries and allows access to tags and dates exactly like a conventional blog would. We also use tags to display different content around the site like the entries tagged with “projects” that are displayed on the work page.
    • Ma.gnolia is used for bookmarks.
    • Twitter is used for random thoughts and snapshots of her day.
    • Upcoming manages events.
    • Technorati is used for references to her posts in the wider blogosphere in place of allowing local comments which were considered but discarded.
    • Feedburner manages all feeds.
    • Google is used for site search.

    Jon Gibbins did the heavy lifting around the idea, using CakePHP and SimplePie to manage the incoming data. He also added functionality like Technorati reference counts, and the ability for Denna to refresh her site as soon as she published something elsewhere if she didn’t wish to wait for the automatic updates.

    Other small touches were also a pleasure to see unfold, like Denna’s footer image being her Flickr profile image, and the text describing her blog coming directly from her Tumblr byline.

    Denna’s Tumblr account is not linked because she wishes it to remain private.

    Tumblr posed the most significant problems. When we started development, tags were invisible on Tumblr. Entries could be tagged, but tags were not displayed anywhere for people to use. They were absent from the API. Jon Gibbins wrote a workaround and fired an email to Tumblr suggesting it might be good to give people some way of using tags. After a couple of weeks Jon came back to me and declared that although he hadn’t had a reply, the API had just changed to allow tag access. Perfect! We got an email a couple of days later from the Tumblr crew: Did we know that the API supported tags?

    Visual design, typography & layout

    I wanted the design to be a container to allow Denna’s own content to flourish. Although we discussed style, and helped Denna formulate her own house style, it was very much in her hands. Strangely, I had no reservations about this. Putting the choice of stock images in the hands of a client might seem risky to some folks; to me it was exciting, especially as Denna was so enthusiastic about having such an intimate level of control over her own site.

    Typography and layout have a touch of the Swiss modern using Helvetica Neue or Arial (depending on your platform) with a traditional scale. The layout is a hybrid—part fluid, part elastic — meaning it defaults to a 1024px viewport width, shrinks to fit 800px-wide viewports, but grows with browser font size until it fills the available viewport and then wraps.

    Information verbitecture

    The information architecture mostly uses verbs in the directory names—an idea that first surfaced with Chris Shiflett during our recent OmniTI design. It means that web addresses make up sentences wherever useful. For example, a blog entry has a URL of

    HTML, JavaScript & microformats

    Plain old semantic HTML is used with CSS for styling. The interface was designed with accessibility firmly in mind; all JavaScript is introduced as a progressive enhancement to PHP-powered features like the slide-show for the home page.

    Microformats are used wherever appropriate: hCard for Denna’s contact details; hAtom for blog entries; hCalendar for Upcoming events.

    There is still more things we’d like to do, but in the meantime we’ve got a great head start and hopefully the beginnings of something special for an exceptionally interesting voice on the Web.

    Parting shots

    Working with Denna was inspirational. Her boundless curiosity, willingness to experiment, and professional skill made the whole process lots of fun. Her uncompromising belief in the ability of art and design to improve people’s lives makes her just the sort of person we need consulting on the future of our public spaces. It was a pleasure to give her a quasi-professional site that hopefully embodies the spirit of collaboration, personal creativity and expression we all admire. You can read more of her own thoughts on the design in her entry, Websites and the Science of Happiness. I’ll leave you with the opening line of that entry; it’s humbling to be though of in this way:

    “The designers of this website are happiness merchants.”

    Thanks Denna.


  6. A Site for Sore Eyes: OmniTI

    You may have seen the recent case study featuring the evolution of OmniTI’s brand mark. Work on their new web site started soon after that was finished. This is what we did:

    OmniTI index

    OmniTI’s CTO Chris Shiflett and I worked closely on every aspect of the vision, brand message, information architecture, copy writing and content. For me it was the best kind of arrangement resulting in a piece of work I’m especially pleased with. Along the way we developed the kind of relationship that I’ve come to treasure, making me feel like I work in a collaborative industry, rather than a service one.

    OmniTI Sketch mark

    Metaphors for the invisible

    Discussions around the new site made me think of two interesting design problems. Scalability and performance, security, development and infrastructure are invisible arts. Historically, companies have fallen back on metaphors to communicate what they do visually: Faux boxes of imaginary software; stock photography of happy people at computers; they never worked for me. From my perspective, OmniTI is one of the finest development companies in the world. They’ve written some of the seminal technical books in our industry. They work for some of the most heavily trafficked sites on the planet like Digg, Friendster, National Geographic and Facebook. Their contributions to open source are legendary, with their utilities being used by Yahoo!, amongst many others. When tackling email on a massive scale they built the world’s fastest mail transfer agent. To reduce what they are capable of to awkward metaphors seemed disingenuous. I wanted to do something different.

    Another significant problem was how to convey personality. People buy from people, especially in a service industry. The relationships we develop are priceless. Many developers in our business—especially those who attend conferences like OSCON where they often speak—are already aware of the people at OmniTI, but they themsevles don’t tend to shout about what they do. Part of the reason for this is the culture of the company itself: Relaxed and down-to-earth but jam packed full of some of the most talented people anyone could hope to work with. Excellence has become commonplace, making celebrating it feel almost un-natural. It just happens by default. So, the web site needed to show some leg, reveal their personality as well as their work, without forcing patterns of publishing on them that would not be maintained.

    These problems made the job interesting. I wanted to accomplish three specific goals:

    1. Make OmniTI accessible. Personalise the brand, reveal the company character, and the people within it.
    2. Communicate the scale, quality and depth of what they do to technical and non-technical people.
    3. Make the whole experience of researching and contacting them simple, easy and useful.


    To try and accomplish the goals we took a novel approach to design. It might seem ad-hoc, but it was deliberately organic; we let everything develop collaboratively, at almost the same time: From setting the vision to requirements gathering, persona development and task analysis, through to information architecture and copy writing. It sounds insane, but with a condensed time-line and a lot of intellectualising to be done, it worked in a way that only a small agile team that knows each other well can do.

    Along the way we went through four related iterations of style. Each reflected a development stage in the multi-track process we embarked on. The staff started writing a personal note for their own profiles. Some chose to stay with the professional photos, others supplied their own. All of it real though and unfiltered by marketing hype. Read the personal note of Rob Speed to get a glimpse of what I mean. The iterations kept getting better. In fact, everything kept getting better. Nothing is ever perfect, but a feeling of constant iterative improvement is a joy in itself. These are some of the highlights from my point of view:

    Theme, copy writing & content

    The theme is deliberately textual. OmniTI is a company that manipulates data in ways that are so esoteric that sometimes I had a hard time conceptualising the scale, nevermind the method. Text is the prevalent form of web data. It felt right to focus on it.

    Early on I decided to drop almost all decorative images and anything that was not content from the design. The data, the typography, they became the decoration. That went hand-in-hand with the decision to let OmniTI’s people, work and clients tell the company story. We decided to have a dual section in the planet for official company news and relevant posts from the staff’s own personal blogs. For the rest of the site, any copy that didn’t reflect the spirit of the company was avoided, and that which was left would be factual, not hyperbolic. Any claims OmniTI have made are under-estimates, and therefore all the more exceptional.

    Tiered detail

    I wanted to find a way of communicating the scope of their ability in a simple way. The audience diversity made this problematic. When developing personas to identify who we wanted to reach, two stood out: The technician and the executive. Both have very different requirements from the site. Both required detail in different areas. The first answer to this was for the home page. To grab people’s attention, I had the idea to display the actual output of their work as data in real time. There were technical and disclosure issues. We settled (for now) on showing some meta-level data around the number of pages and people that OmniTI’s clients serve:

    Screenshot: 'last month we helped some of our clients publish 880 million web pages, seen by 93 million people.'

    This will evolve over time and also be stored in an archive for future reference. Even more importantly, it is no mere boast. The figures are independently gathered and conservatively rounded down.

    The next solution was to somehow ease all of the audience into the site, whether they were technical or not. The narrative pattern we developed I call tiered detail. At the first level, like the index or any of the main navigation landing pages, chunks of different data are labeled with headers that encourage page skimming to find interesting topics. Copy is short, terse, accurate. The second level, like a personal profile, is more detailed and specific but has contextual links to related second level topics. The copy has links to third level pages where the focus narrows further to provide the kind of detail some people might want. These third level areas can be on site or off site—we didn’t distinguish between the two. All detail is useful when you want it.


    Both Chris and I love beautiful, clean URLs. So when he came up with the idea of using verbs rather than nouns in the information architecture we we quickly agreed to make it so. The outcome of a fair degree of debate and wrangling is the structure you see today. The about page is, the work page is, etc. Deeper pages have a URL that forms a sentence, such as:

    All trailing slashes have been removed making for highly legible and beautiful URLs in any context. More traditional URLs are redirected to the verb, so people can still type and reach the about page. If you wish to know more, read Chris’s post, URLs can be beautiful.

    Typography & palette

    Evolving an interface from a brand, the type choices of which I had nothing to do with, is always interesting. Trying to find compliments is fascinating, even more so in a design that relies heavily on type composition and treatment for decoration. I’ll pretty much let the typography speak for itself .

    Italic Baskerville ampersands in the byline

    Highlights for me are the raised initial used in headlines which I always see as an icon, my favourite Baskerville italic ampersand used in the byline on the home page, and other subtle treatments like the semantics of the page titles or contextual links. I used a traditional scale, body copy is set in Georgia by Matthew Carter with the headlines set in a Lucida stack.

    The palette is included in this section because the typography developed alongside it, and they are irrevocably linked. Or, I should say, they are tonally co-dependent. Although the palette is autumnal, it is a counterpoint to the season, and you may see us have some fun with it over time, but the effect will persist: Type highlighted by luminosity, regardless of palette.

    Layout, functionality & accessible Ajax

    The layout is elastic in every respect to a strict baseline grid. This served the narrative theme, splitting the content in to equal chunks higher in the architecture for skimming, resolving to conventional asymmetric columns deeper in.

    OmniTI contact Ajax

    Jon Gibbins did a sterling job implementing the JavaScript effects on the site. He chose jQuery and added some flavour of his own to make everything accessible with or without JavaScript turned on. That extends to the Google Map on the contact page which fills the expanding container as font size is adjusted. Jon also audited the site for accessibility generally, applying his uniquely pedantic but practical approach to support a wide range of disabilities, especially where the JavaScript is concerned. You can read more in his post, Accessible Ajax: OmniTI.

    All other functionality was handled by OmniTI, with Theo himself building an unbelievably quick search engine with Perl in about an hour, and Chris building out the CMS equally as fast it seemed.

    Experience & narrative

    As designers, we wear a multitude of hats. In the final analysis I think we’re experience designers more than anything else. In many cases we use design to tell stories, or help a story unfold. We create spaces in which enacted or emergent narratives exist and the OmniTI site is no different. Like all real tales though, there’s still much to be told. Hopefully they have a good starting point; an authentic opening chapter where the history of the last ten years can sit comfortably with the next ten.

    For my part, I hope the story is a joy to read. I hope the design is unobtrusive and becomes an ambient signifier that adds a little texture to the content. It is a design I would have liked to implement for Grow itself, so a lot of my own predilections went into it. I was lucky: The great relationship that we have, and the creativity of OmniTI, allowed my ideas some breathing space. We took a journey that resulted in a site that is re-markedly different to other technical companies. Some might view that as dangerous. I think the opposite is true. To me it was a great project to do. Hopefully you’ll find it interesting enough to enjoy. If that’s the case, keep an eye on it; there may be some more subtle changes to come.


  7. Designer PHP: A Dynamic Menu with If and Else

    Recycling PHP and HTML

    In the simple PHP include article I covered how to re-use one file in many pages. If you’re new to using PHP, read that first. Now it’s time to make file includes a bit more useful. In this article, we’ll include one file for main navigation, but make individual menu items “live” depending on the page they appear on.

    This is an article in the “Designer PHP” series of guides to using PHP for interface production. Previously:

    1. A Simple Include

    To perform this feat, we need to do three things:

    1. Declare a variable on each page to tell the menu what markup to display.
    2. Create a file with “live” and regular markup for each menu item. Add PHP to enable us to switch the markup according to the variable.
    3. Include the menu on every page.

    Declare the PHP Variable

    The variable declaration must be in every page the menu will appear on. It must be before the line of code that includes the menu so the menu can pick it up. I would normally insert it above the <!DOCTYPE… to separate the PHP from my HTML as much as possible. This is the variable declaration for the home page:

    (This variable declaration or PHP statement has two key parts: The variable reference, or name $page, and the variable value "home".)

    $page = 'home'; 
    1. The variable name $page does not change. You can change it to whatever you like, just make sure it’s the same on every page.
    2. The value 'home' will be different for each page to tell the menu what to display.

    I usually have the value match the area of the site, so in the example we’re building it will be 'home' on the home page, 'about' on the about page, and so on. You can change the value to whatever you like, and have as many values as you need for individual pages.

    Create the Menu File to be Included

    For our purposes, we’re going to create a dynamic menu for a fictitious site with three pages: “Home”, “About” and “Contact”. You can extend this to apply to as many pages as you like. This is the basic HTML for the menu:

    <div id="nav">
    <li><a href="index.php">Home</a></li>
    <li><a href="about.php">About</a></li>
    <li><a href="contact.php">Contact</a></li>

    We want two different sets of markup for each menu item: “live” markup and regular markup. In this example we’re going to attach a class to the “live” item — <li class="live"> — and wrap the link in an <em> to differentiate it even if styles are disabled. For example, on the home page, the “live” home menu item will end up looking like this:

    <li class="live">
    <em><a href="index.php">Home</a></em>

    To switch between “live” and regular markup, we will use PHP “if, and else statements”. This is the menu HTML with PHP:

    (White space and line breaks inserted for legibility. PHP is emphasised in red. Disable styles to see it in italics if you need to.)

    <div id="nav">
    <?php if ($page == 'home') { ?>
    <li class="live">
    <em><a href="index.php">Home</a></em>
    <?php } else { ?>
    <li><a href="index.php">Home</a></li>
    <?php } ?>
    <?php if ($page == 'about') { ?>
    <li class="live">
    <em><a href="about.php">About</a></em>
    <?php } else { ?>
    <li><a href="about.php">About</a></li>
    <?php } ?>
    <?php if ($page == 'contact') { ?>
    <li class="live">
    <em><a href="contact.php">Contact</a></em>
    <?php } else { ?>
    <li><a href="contact.php">Contact</a></li>
    <?php } ?>

    Copy the code to a new file in your editor. Save it as nav.php inside an inc directory in your site root.

    I have deliberately separated the PHP and HTML as much as possible. There are other ways to achieve the same result, but this removes PHP completely from within HTML tags, hopefully making it easier to read and edit.

    Let me explain what the PHP does: Each menu item is marked up in two different ways: the “live” version and a regular version. The variable we declared tells the PHP in the menu which to display. For example, if $page = 'home'; is declared, the if statement ( <?php if ($page == 'home') { ?> ) will display the “live” markup. If home is not declared then the <?php } else { ?> statement takes over, and the regular markup is displayed.

    To make any of the other menu items “live”, you adjust the variable. The menu picks it up and switches the HTML. Simple. That’s our menu created and ready for use. The next step is to include it on every page.

    Include the Menu

    To do this we use the same technique explained in the simple include article, except this time we’re including the menu file, which we’ve called nav.php. This is the PHP you need:

    <?php include 'inc/nav.php'; ?>

    Insert that in each page at the point you wish the menu to be displayed. The path ( 'inc/nav.php' ) pointing to the nav.php file is relative — make sure you change it if your pages are not all in the site root. Each of your site pages will now look something like this (with the variable value * edited as required):

    <!DOCTYPE… >
    <head>… </head>
    <?php include 'inc/nav.php'; ?>

    That’s all! Now you can get to the fun bit of styling your menu with CSS. If you need to change anything, you simply edit the nav.php file and every page will be updated. Easy, isn’t it? Let’s end with a few tips about errors and security.

    PHP Error Debugging

    If you get a heap of PHP errors on a page instead of the menu, the chances are your include file path is wrong. Check it is pointing correctly to nav.php from the location of the page calling it.

    It’s useful to know that you can navigate straight to the include file directly in your browser and see the markup.


    If the file path is wrong, you will get a 404 error.

    If no menu items are active, or one is incorrectly active in a certain page, check the variable declared at the top of the page. Does it match the on in the if condition that precedes the item you want “live” in nav.php?

    If you’ve done all that, and you’re still having problems, check your syntax line by line. The chances are you’ve missed a tiny mistake. It’s a pain but a good way to learn.


    I grabbed a moment with web application security guru, Chris Shiflett to have him check my PHP. This is what he said:

    Whenever you’re working with a server-side programming language such as PHP, it’s good to be aware of potential security problems, because a simple mistake is all it takes to create one. If you follow Jon’s example, you’re safe, but what happens when you need to modify it to suit your own unique needs?

    Rather than complicate a wonderful tutorial, I’ll just point out that you should research further before doing either of the following:

    1. Add any additional PHP code to your includes.
    2. Use a variable in your include statement, e.g. include "inc/$template".

    If you need to do either of the above, you should first read a little more about remote code execution.

    Further Reading

    Control structures on

    Can You Translate?

    After a wonderful response to the em and elastic layout article, I’d love to hear from anyone who’d like to translate this, or any other article in the series. I’ll be happy to host your work, like the previous Italian translation, or you’re welcome to publish it yourself. Just drop me a line.


  8. Designer PHP: A Simple Include

    Years ago I was introduced to PHP. Since then, using simple PHP includes has saved me huge amounts of time in revising and editing HTML, so I thought I’d share some basic tips and hopefully save you some time, too.

    This is the first article in a series of basic designers’ guides to using PHP for interface production.

    Including CSS style sheets, JavaScript files, and image files in HTML pages will be familiar to most people. PHP includes work in a similar way: Create one file with a chunk of HTML in it (like a menu or a footer) and include it in multiple pages using a bit of PHP. Change the contents of that one file and every page that includes it displays the change. Sexy, eh? Let’s get started:

    What is PHP?

    In case you don’t already know: PHP is a programming language that works on the server—server-side scripting—in much the same way that JavaScript works in the browser (“client-side scripting”).

    All good hosting services have PHP installed on the server. You can find out what version and modules you have installed using phpinfo(). PHP also powers many of the most popular sites in the world. However, all we need to know for our simple purpose is this:

    PHP allows us to create a single file on the server, and include the contents of that file in multiple pages before they are delivered to the browser.

    Creating PHP Files

    Make sure your hosting service supports PHP. Then, instead of saving your site files with a .html or .htm extension, save them with a .php extension. They won’t render any differently in the browser, the extension just tells the server that the file may contain PHP which will need to be executed before the file is served.

    Before creating PHP includes, I usually create the first page of a site in the normal way, but save it as .php. I only pull chunks of HTML out to includes when I start building other pages in the information architecture.

    Example: A Regular HTML Footer

    Web sites usually have a footer that is constant across all pages making it perfect to be included using PHP. This is a simplified example of a regular page with the footer included inline as usual:

    <!DOCTYPE… >
    <head>… </head>
    …main content
    <div id="footer">
    …footer contents

    Making the Footer a PHP Include

    1. Create a directory in your site root called inc to contain all of your includes and keep your files organised.
    2. Remove the whole of the footer markup and paste it into a new file in your editor. Save that file to the inc directory as footer.php (it can be whatever you wish).
    3. In the regular site pages, where the footer would usually be, replace it with a bit of PHP to include the footer.php file:
    <?php include ("inc/footer.php"); ?>

    Important: The file path ("inc/footer.php") is relative to the location of the page including it — make sure it points to the right place from any given page in your site.

    With that bit of PHP in your pages, the footer.php will be included in the page at that place.

    Change the markup in footer.php and it will change for every page where you have included it. Now, when you need to change the date in the footer to include the new year, or change anything about it, you only have to change it once in the include. That’s it! You can make any bit of markup an include.

    More Complex Includes

    PHP becomes even more useful for designers when the state of HTML objects needs to change depending on what page they appear in. For example, the markup and style of main navigation items will change to indicate which item is active. I often apply a class and either disable a link or wrap it in <em> tags. You can do all that in a single menu include. In the next article I’ll show you how. In the meantime, if this is new to you but you’re enthused by it, take a look at if/else statements yourself.

    Further Reading

    1. PHP tutorial from
    2. PHP introduction from W3schools


  9. An Ode to Old-style Numerals

    Most of my bread-and-butter fonts are broken. So is my keyboard. I can still use them but they’re broken because they don’t work as they should, or as I want them to.

    Between the two of them they’re breaking my user interface and interfering with my ability to communicate. Here’s why:

    Modern (lining), old-style & small caps numerals

    All of the core Web fonts apart from Georgia have modern numerals. They are all equal width, and the same height as capital letters. They are great for tabular data because they line up vertically in tables which is probably their raison d’etre. They work perfectly with capitals, too. After that they start to fail. Miserably.

    For my purposes, I’ve use two of the core Web fonts—both excellent in their own way—that were designed by Matthew Carter as examples.

    These are the modern numerals of Verdana:

    Verdana 123456789

    Old-style numerals have variable widths, just like regular letters. The numbers are mostly the same height as the lowercase letters with descenders and ascenders that fall and rise from that beat. They are perfect for use within text, or anywhere outside of the two examples used for modern numerals. They are beautiful, harmonious, easier to read and I want to use them, all the time.

    This is Georgia:

    Georgia 1234567

    Small caps numerals are equally beautiful and, as the name suggests, relate to the size of the small capital. Also, small caps are not just shrunken uppercase letters, and may not fit to the lowercase x-height so numerals can be drawn separately.

    There’s more detailed comparisons and great examples in John D Berry’s Creative Pro article.

    The only problem I’ve come across with old-style numbers is telling the difference between a zero and a letter "o". This hit me when creating the business cards for Grow. My answer was to commit sacrilege and draw an asymmetric line through the zero in the knowledge that letterpress techniques would deboss the faux small caps heavily almost to the weight of a proper small caps font, and the line would clearly differentiate the zero from the "o".

    Every typeface with upper and lowercase letters should have modern and old-face numerals.

    The ClearType fonts include lining and old-style numerals by default.

    They are both needed. However, I mostly type two kinds of text: prose and code. If you ignore the code for a second, I would guess that almost all of the people using an alphabet where old-style is useful are typing prose more often than not. In prose, depending on the type (technical, academic, business etc) there are rules about the use of numbers. Thirty dollars will get you access to chapter 13 of The Chicago Manual of Style or you can also see the Connecticut Community College guide to numbers and lists, and Jack Lynch’s Guide to Grammar and Style.

    Whatever the house style we lean towards, old-style numerals should be available to use. Typographers and designers, please include them in every possible face. I realise that would be pointless unless everyone could use them easily with common software. Therefore, operating system and user interface designers, please give us access to them via a keystroke or two. There’s no easy way to access them right now, even if they exist (unless you edit the typeface itself to swap lining for old-style permanently.) This I can say with complete confidence:

    My keyboard is busted

    The number row on this shiny new Mac keyboard lists all modern numbers with symbols above them, just like yours.

    Mac number keys

    It’s busted in two ways:

    1. If a typeface has modern and old-style numerals I can’t type them both easily. It should be as easy as typing in uppercase or lowercase, which is exactly what it is.
    2. When writing code I use certain symbols a lot and therefore use shift a lot. In fact, with Mac keyboard the most common symbol I type after angle brackets is the hash (or pound in the States): “#”. This is accessed via pressing Alt+3. There is no hint on the key itself. When I switched to a Mac for the first time, I once spent a good amount of time on a train cursing before working it out.

    An answer

    I freely confess I’m opening a can of worms here, and could go into great detail about the various use-cases and modes our keyboards should have. However, that will be for another day. For now I’m offering this simple way operating systems can enable everyone to use old-style numbers without re-mapping the keys:

    1. Give my keyboard access to old-style numerals by default using the existing keystrokes. If they are not available, default to whatever numerals are available.
    2. If modern or lining numbers are also available, give me access to them in the same way that I have access to other capitals: via shift.
    3. Provide access to symbols with a different key. You decide, I don’t mind, but Alt seems obvious. Seriously, who uses ^ on a daily basis? The even less-used symbols should be moved to a double or triple action key configuration.

    If this is all too much of an ask, then at least allow everyone to access old-style numerals with an obvious set of keystrokes that won’t interupt writing flow too much.

    Does this solution make sense to anyone else? There may be problems I haven’t foreseen with the technical or interface aspects, and there’s much I’d like to add about code mode. However, right now I’d just love easy access to old-style numerals, both for the sake of my eyes when I’m reading and my heart when I’m writing.


  10. Web Design Craft & Boxwood Combs

    Around 10,000 years ago in the Stone Age human beings were using boxwood combs. They may have predated that, but that’s what the physical evidence shows. To put that in context, we’ve been using boxwood combs about 700 times longer than we’ve been using the Web, who’s protocols were put into the public domain on 30th April, 1993 by CERN. Boxwood has special properties. It is strong yet soft enough to be shaped and generates no static. A boxwood comb is perfect for purpose.

    Tsuge gushi or boxwood comb

    Boxwood comb via

    Sometime between the Stone Age and now, perhaps around 400 years ago, the Japanese turned Boxwood Combs (tsuge gushi) into something extraordinary. They discovered that Satsuma boxwood (Satsuma-tsuge) was the best quality for a comb. They dipped them in camellia oil to preserve the shine for comb and hair. People sat for 12 hours straight carving a single comb. They began to carve combs of incredible delicacy and precision that to this day, makes Japanese Boxwood combs the finest in the world. They became true craftsmen and women and were immortalised by artists like Hiroshige.

    That still continues today. Jusan-Ya in Tokyo’s old quarter has been there for almost 300 years where Keiichi Takeuchi, a 15th-generation craftsman, still makes boxwood combs by hand.

    The tradition and craft is important, valuable and precious, but the comb in itself is not the final output of this dedication and history. Craftsmen and women like Keiichi Takeuchi don’t create beautiful combs or just help women have beautiful hair. Through their craft they help to make life beautiful, both for themselves and for their patrons. They do this by creating something that responds to people, something perfect for purpose. That’s what all crafts people do, no matter what their profession, trade or art.

    In my eyes, Web design is almost indistinguishable from experience design. In the same way that boxwood comb makers create an experience, so do we. Web designers are all experience designers, or perhaps more accurately we are all narrative designers. A narrative designer creates an interface with flow. If you imagine user tasks as stories or narratives, whether the content is user generated or authored by copy writers, the concept of narrative design starts to make sense.

    The mistake that people make is to see Web design as the evolution of print design. Jeffery Zeldman broke it down rather well recently. Others have also commented on this and related topics. This mistake is best emphasised in Web design galleries. It seems to me that even fellow professionals sometimes forget what they are rating or judging and fall in to the trap of looking at the visual aesthetic alone. Sometimes the comments are disappointingly shallow. I wonder truly how many of us can reach past our predilections for pretty interfaces and fashion, and move into the realm of uplifting experiences that require much more than a glance at a screenshot to judge. The irony is that our discipline is very much about visual design, but it is not just about style. In my view, it should be about building carefully crafted experiences based on a thoughtful empathy with the audience and their goals.

    There are a lot of craftspeople in narrow disciplines. The issue is not a lack of dedication to craft, but the breadth of narrow disciplines that make up Web design craftsmanship. For example, apart from the technical disciplines of CSS, HTML and the vagaries of cross platform and agent behaviour, there are a vast number of others that overlap, merge and relate. To name a few, there are graphic design disciplines such as typography, illustration and layout. There are user centred design disciplines like accessibility, task analysis, persona building, information architecture and wireframing. There are marketing disciplines like copy writing and brand positioning. Then, if we want to truly create excellent user experiences designers need to understand or work with craftspeople who have depth in application optimisation, scalability, security and adaptability. The list could go on and on.

    I think a good Web designer has an understanding of all of these things, has mastered the technical, knows the non-technical and is thereby freed to be concerned with narrative: How users experience an interface and create their own stories based on the information presented to them, or by creating information themselves. Narrative design is what we do.

    In his fascinating article on Game Design as Narrative Architecture, Henry Jenkins of MIT said that, “a story is less a temporal structure than a body of information” which seemed eerily familiar to my way of thinking. He went on to make two relevant observations. The first on enacted narratives that could be compared to brochure sites that we create:

    “…the story itself may be structured around the character’s movement through space and the features of the environment may retard or accelerate that plot trajectory.”

    The second on emergent narratives that could be compared to social sites:

    “…spaces are designed to be rich with narrative potential, enabling the story-constructing activity of players.”

    Web designers have to consider these kinds of narratives on a daily basis. The skill is in how we push, pull and merge all of our technical and non-technical knowledge together. In order for Web designers to be craftspeople we have to be technically rigorous but also creative and organised, imagining and implementing complex narratives with everything in mind. In that sense, Web design is a much more complex discipline than making a boxwood comb but both aspire to the same ambition of creating something that is perfect for purpose.

    It took 10,000 years for human beings to reach the boxwood summit, but I think that many Web designers are there already in their approach. For my part, I’ll still be reaching for the lofty heights of the polymath and on that note I’d better get my finger out and do some work.


  11. Smoothing out the Creases in Web Fonts

    Stickman smoothing out the contour in a ligature.

    Designers often choose one of the core Web fonts for body text because they are widely available, but like all typefaces, they render differently on different operating systems.

    Apple OSX and Microsoft Windows have different ways of rasterising fonts and different text rendering engines. Apple’s text rendering engine is Apple Type Services for Unicode Imaging (ATSUI .) Microsoft’s text rendering engine is Uniscribe .

    Font Rendering Methods in OSX & Windows

    OSX tries to respect the anatomy of the type as far as it can using floating–point positioning — a combination of anti–aliasing techniques and sub–pixel rendering that does not lock glyphs to the pixel grid.

    Windows uses two methods depending on the version of the operating system, (Standard and ClearType.) Standard uses a combination of hinting (grid fixing) and anti–aliasing. ClearType also uses sub–pixel rendering — using LCD display technology to achieve better anti–aliasing. With both of them, it prefers to lock the letters to the pixel grid.

    Comparing fonts at 14px and 800% maginifcation in OSX and Vista.

    Fig. 1: Firefox 2 on OSX (left) and IE7 on Vista (right) font rendering at 800% magnification.

    ClearType is enabled by default in Windows Vista. In 2001, Windows XP had ClearType included but enabled Standard mode by default. Changing to ClearType requires navigating through the Control Panel to find the Appearance settings, then finding a button marked “Effects” to access the options. It’s the Windows equivalent of trying to change the accessibility options in browsers: Even if you know they exists, they’re a pain to find.

    The legibility of each technique is subjective, and also depends on factors like ambient light, resolution, viewing distance, visual impairment, screen type and colour contrast.

    Dave Shea prefers Windows’ ClearType method, as does Jeff Atwood and much of his commentators. For judiciously sized body text I mostly prefer the Apple method, yet previously in brand work I’ve also locked the letters to the pixel grid to get them as sharp as I’d like. Again, it’s subjective: How I see the individual font appear at a particular size and colour is the deciding factor.

    Core Web Fonts

    In August, 2007 Apple and Microsoft renewed the license for the core Web fonts. It was anticipated, but still, there was a collective sigh of relief that the fonts would still be common to all major operating systems. Matthew Carter, the designer of Georgia and Verdana said:

    “By agreeing to make these fonts available cross–platform Microsoft and Apple will support their customers, and confirm their respect for the standards of type–design.”

    Using the default Standard mode in XP, text is rendered with minimal (practically non–existant) anti–aliasing up to a certain size. The size at which text starts to become smoothly anti–aliased seems arbitrary. Good smoothing occurs at various sizes for each variant of each typeface. XP is still the most common platform used by our audience today, and this is how it displays Georgia in IE6:

    IE6 on windwos XP font rendering

    Fig. 2: Screenshot of Georgia displayed in IE6 on Windows XP clearly showing smooth anti–alias starting at 17px.

    For your bookmarks: The Web fonts test suite displays text from all the fonts in a range from 11px to 21px so you can compare and contrast yourself.

    Smooth Header Font Size for Windows XP

    The Web Fonts test suite was used to produce the following table that compares the core Web fonts, and the size in pixels at which good anti–alias starts to occur in XP by default. (Every browser except Safari.) Only whole pixel font sizes were used.

    Typeface Pixel size for smooth anti–aliasing
    Regular Bold Italic Bold Italic Small Caps
    Andale Mono* 18 11 18 18 21
    Arial 18 11 18 12 21
    Arial Black 17 17 17 17 20
    Comic Sans MS 16 11 16 11 18
    Courier New - 16 - 17 -
    Georgia 17 17 17 17 20
    Impact - - - - -
    Times New Roman 18 14 21 18 21
    Trebuchet MS 17 12 17 12 20
    Verdana 17 17 17 17 20

    * Andale Mono does not ship with Windows Vista.

    Noticeably, Impact is never smoothly anti–aliased, and Courier New only when embolded (perish the thought.) The font being rendered with smooth anti–aliasing at the lowest size is Comic Sans; a fact that might produce a wry smile from its creator, Vincent Connare, who never intended Comic Sans to be used outside of the speech bubbles in Microsoft Bob.

    Designers can choose to ignore the smooth anti–aliasing point in XP Standard mode altogether. My view is that headers look better when smoothed as much as possible, so a careful choice of weight for the font is important. Now there’s an added complication. ClearType in Vista seems worse in some circumstances to me than the Standard method, but that is a post for another day.

    Future Font

    Apple’s patent application for a system and method for displaying text—invented by Mark Zimmer—from June 14th, 2007 may make interesting reading for some. It includes references to grid fitting / hinting, specifically a method that, “increases contrast of tops of lowercase characters of the font family and preserves thickness at tops of stems of lowercase characters.”

    In the future, the debate around platform specific font rendering may all be moot, as displays move to ever higher numbers of dots per inch and pixels per inch (160 as per the iPhone.) For now, how a given fonts behaves on different platforms is still crucial to user experience. I’ll still be keeping an eye on XP for a while yet, and I have a funny feeling I’ll be getting good use out of the table for a while, too.

    1. Resources and further reading:
      1. Web fonts test suite
      2. Apple Type Services for Unicode Imaging (ATSUI)
      3. Microsoft Uniscribe
      4. Apple TrueType Reference Manual
      5. Microsoft TrueType Reference Manual
      6. Wikipedia: Font Rasterization
      7. Wikipedia: Anti–aliasing
      8. Wikipedia: Font hinting / grid fitting
      9. Wikipedia: Sub–pixel rending
      10. Microsoft ClearType
      11. ClearType tuner for XP


  12. Design vs Evolution

    I just watched a fascinating TED presentation on self–aware robots from Hod Lipson of Cornell University:

    It was inspiring to watch the spider–like bot trying to understand its own form and how to move forward. It was fascinating to see it not walk like a spider as we might have hoped for. Instead, it found a completely different way of propelling itself.

    Observing users in action within a user centred design (UCD) approach can also be surprising. They often do things we might not expect or be able to predict. As designers, we use our intuition to try and create empathetic experiences that transcend our own predilections. Jared Spool alluded to this recently at dConstruct when he described speaking to members of AIGA. He described how he talked about UCD and experience design to the audience who apparently promptly turned around and said, “that’s what we do!”

    In the article about narrative, I was thinking about developer versus user–generated narratives. The best social networks are platforms for expression. Users generate their own stories within the framework. To do this there is often a symbiotic relationship between the stage (the site) and the players (the users and audience.) The stage is literally set by the players and audience. They often find unique and interesting ways of using the stage to tell their stories. They create and pave new cowpaths which are then expanded upon by the developers. So the narrative being designed by the developers is only one of countless plots the users can follow.

    That’s what the robot was doing. With a reward at the end, it created its own story in order to understand itself and move forward. As Hod Lipson suggests, evolution rather than design may be a much more effective way of allowing robots to discover themselves. The same could apply to website users. Should we design experiences, or help them evolve? If it’s a balance between the two, how do we walk the line?

    The other fascinating portion of the presentation is what happens when rewards are removed. Instead of trying to achieve a task, the robots in the primordial soup of parts and power start to self–replicate. Self–replication becomes the task and the reward; amazingly like us, or any life form.

    You might compare that to certain social networks that exist without a goal as such, but to merely connect people. Users define their own rewards and tasks. Create their own narrative. Think about friends lists or popularity on Facebook. In a way that could also be considered self–replication, but of ideas and influence rather than genes. Conversely, on sites like Cybersocietes—a social networking popularity game where an algorithm calculates popularity based on activity—many users choose not to play a part in the designed narrative of the game. They choose instead to get satisfaction in other ways. They create their own narratives that still revolve around influence; not with the false measure of game points though, but in more subtle ways such as participation in public forums or private groups.

    Perhaps our job is not to design experiences in all cases, but to enable the audience to explore, play, and learn their way to a rewarding experience. Along the way they teach us a thing or two, and we all move forward together. Thanks to the Cornell Computational Synthesis Lab we can also let robots evolve on our computers as a screensaver (unfortunately Windows only) but fellow Mac users can evolve sheep instead.


  13. The Incredible Em & Elastic Layouts with CSS

    Elastigirl saying “I’m an em” and Mr Incredible saying “and I’m a PX”

    Almost a year ago, Ty Gossman over at Stylegala asked me to write an article about elastic layouts. The best I could do was a quick email between work. I always meant to come good on that. Thanks for asking; sorry it took so long.

    Also available in:

    1. Italiano
    2. Deutsch
    3. Español
    4. Russian

    This article will walk you through creating a basic elastic layout; what exactly an “em” is and how to calculate them, how to use ems to create an elastic layer for content with scalable text and images, including basic vertical rhythm.

    What is an Elastic Layout?

    An elastic layout scales with users’ text size.

    More accurately, an elastic interface scales with browser text size—commonly a default of 16px—which users can change if they wish. Some people make a permanent change for accessibility reasons, others use the UI controls to increase text size if they need to.

    Elastic design uses em values for all elements. Ems are a relative size, written like this: 1em, 0.5em, 1.5em etc. Ems can be specified to three decimal places like so: 1.063em. “Relative” means:

    1. They are calculated based on the font size of the parent element. E.g. If a <div> has a computed font size of 16px then any element inside that layer —a child— inherits the same font size unless it is changed. If the child font size is changed to 0.75em then the computed size would be 0.75 × 16px = 12px.
    2. If the user increases (or decreases) text size in their browser, the whole interface stretches (or shrinks.)

    See the elastic layout example. Adjust text size to see it scale. It contains all the CSS and HTML used in this tutorial.

    For other live elastic examples, visit Dan Cederholm’s beautiful and elastic SimpleBits, or resize text on this site.

    Elastic interfaces are flexible and accessible for users, and can be almost as precise as pixels for designers. Layouts can be created accurately and quickly using CSS once we grasp the basic relationship between font size, pixels and ems.

    Introducing Em, the Elastigirl of CSS

    The em is as powerful and flexible as Elastigirl, she doesn’t mind what the font size is, whether 12px, 16 or 60, she will always be exactly equal to it.

    The em is a unit of measurement in typography. What is it and how did it get its name? Here’s a little history:

    An em was originally equal to the size of the metal block used to cut a single letter of type for a specific font. It was roughly equivalent to the width of a capital letter “M”.

    Those with designers’ eyes amongst you might be saying, “hold up a second, letters don’t take up equal space.” You’d be right: Computers use kerning to adjust the horizontal space each letter occupies on the screen, making them equidistant and balanced. Originally, the metal block was trimmed or “kerned” to make the horizontal padding around each letter the same.

    So, in CSS, an em is actually a vertical measurement. One em equals the vertical space needed for any given letter in a font, regardless of the horizontal space it occupies. Therefore:

    If the font size is 16px, then 1em = 16px.

    Getting Started

    Before we start throwing ems around a stylesheet, we need to know what the default font size is in the browser. Luckily, we do:

    All popular browsers have a default font size of 16px. Therefore, at the default browser setting, 1em = 16px.

    In Firefox, you can check default font size via Tools > Options > Content.

    So, before a single CSS selector is written, the browser has a 16px deafult font size. The <body> inherits it unless styled otherwise using CSS. Therefore 1em = 16px, 0.5em = 8px, 10em = 160px and so on. We can now specify any element size we need to using ems!

    Setting Body Font Size

    Some erudite folks suggest setting the <body> font size to either the required font size for body text, or the equivalent of 10px (0.625em or 62.5%) to make calculating child lengths easier. Both have merit, but it seems more logical to me to leave it at the browser default and change it for child elements if necessary.

    So, we know that the body font size will be 16px by default. We also know that if a person has changed their settings, our elastic interface will not break, but adjust. Perfect, so we can set:

    body{ font-size:1em; }

    However, (gasp) IE has a problem with ems. Resizing text from medium (default) to large in IE5/6 would lead to a huge increase in font size rather than the gradual one expected. So another selector is needed to get IE to behave:

    html{ font-size:100%; }

    As Patrick H. Lauke previously pointed out, it’s an IE correction, not a hack—it doesn’t rely on a browser bug to work.

    IE will now behave and resize text gracefully, rather than in mighty leaps of stupefying grandeur.

    Let’s give our <body> some more style, and center everything in the viewport (this will be important later for our content wrapper.) Our initial CSS ends up like this:

    font-size: 100%;
    font-size: 1em;
    font-family: georgia, serif;
    text-align: center;
    color: #444;
    background: #e6e6e6;
    padding: 0;
    margin: 0;

    Formula to Convert Pixels to ems

    When first creating elastic pages, you will find yourself doing calculations a lot. Keep a calculator handy.

    Tip: Find font size for any element with Chris Pederick’s brilliant Web developer toolbar using: Information > Display element information.

    I am no maths wizard, so I needed a simple formula to remember. As a designer, I know pixels intimately, so that’s where I start. I calculate what 1px is in ems and multiple by the pixel size I need. That gives me the equivalent em value. We know that 1em is always equal to the font size of the parent element, therefore:

    1 ÷ parent font-size × required pixel value = em value

    For your bookmarks: Pixel to ems conversion table for font sizes.

    Don’t let my talk of forumla put you off. Elastic interfaces are a joy to build so let’s get practical and create some page elements.

    Building an Elastic Container: The Supersuit

    To create the centred content layer in the example, we need a little HTML. Let’s be really imaginative and give it an ID of “wrap”:

    <div id="wrap">

    We want it to be 740px wide to comfortably fit an 800×600px viewport like the example. What is 740px in ems? Let’s find out:

    1. Set a 740px width in ems for our layer:

      We know that the parent element (<body>) has a font size of 16px. Our child layer (<div id="wrap">) will inherit it. So we can calculate what 1px is in ems:

      1em = 16px. Therefore, 1px = 1 ÷ 16 = 0.0625em.

      Ems allow only three decimal places. More is fine in calculations but before writing CSS, round it up to three.

      Then multiply by 740 to get ems:

      0.0625em × 740 = 46.25em

      Or do the whole calculation in one go with the formula:

      1 ÷ 16 × 740 = 46.25em

      (1 ÷ parent font-size × required pixel value = em value)

      You can use the same formula to calculate ems for any width or height you need. Find 1px is in ems for that element. Multiple that by the pixel value you require to get the em equivalent.

    2. Create CSS:

      Apply the width in ems, center the layer in the viewport using the auto left and right margins, give it a 1px gray border with a white background and align the text left:

      width: 46.25em;
      margin: 1.5em auto;
      border: 0.063em solid #ccc;
      background: #fff;
      text-align: left;

    Now we have an elastic wrapper for our content!

    Styling Text with ems

    Let’s insert a <h1> and a <p> to our wrapper like so:

    <div id="wrap">
    <h1> … <h1>
    <p> … <p>

    Essential reading:

    The Elements of Typographic Style applied to the Web created by Richard Rutter based on the masterwork by Robert Bringhurst.

    While we're here, we might as well add some typographic goodness by selecting a basic leading and adding some vertical rhythm, with everything expressed in ems. Here’s a little more history:

    Leading (pronounced “led–ing”) was traditionally the insertion of lines of lead underneath rows of text. It is expressed in CSS as line-height but instead of adding space below, it increases the space above and below each line of text.

    In the example, I’ve used the same font sizes as Richard Rutter did in his outstanding chapter on vertical motion to make your reading as consistent as possible. The heading font size will be 18px. The paragraph font size will be 12px with an 18px line height. 18px will be our basic leading—the most important value for our interface. Everything else will be proportional to that.

    A note on CSS inheritance: Our content wrapper, <div id="wrap">, has no font size set so it has inherited the 1em (16px) font size from its parent, the <body>. Any elements within our wrapper will also inherit that font size, unless we tell the browser otherwise, as we’re about to do.

    1. Set a 12px font size with 18px line height and margin for paragraphs:

      We know that our paragraphs have inherited a 1em (16px) font size from its parent, <div id="wrap">. From our previous calculation, we already know that 1px is 0.0625em. We simply multiple that by 12 to get the em value for 12px:

      0.0625 × 12 = 0.750em

      Or do the whole calculation in one go with the formula:

      1 ÷ 16 × 12 = 0.750em

      (1 ÷ parent font-size × required pixel value = em value)

      Then apply that to the CSS:

      font-size: 0.750em;

      Margin, line height, padding etc. in ems are all relative to the font size of the element they belong to.

      To calculate the desired line height and margin of 18px for our basic leading we do the following:

      18 ÷ 12 = 1.5em

      Dividing the desired line height (18px) by the element font size (12px) gives us the em value for line height. In this example, the line height is 1 and a half times the font size: 1.5em.

      Add line height and margin properties to the CSS:

      font-size: 0.750em;
      line-height: 1.5em;
      margin: 1.5em;

      Now the browser will say to itself, “Oh, line height and margin is set to 1.5em, so that should be 1.5 times the font size. What’s the font size, again? 12px? OK, cool, make line height and margin 1.5 times that, so 18px.” It will do all that faster than Dash too, and render it. Wow.

    2. Set 18px font size for the <h1>:

      The <h1> has inherited a 1em (16px) font size from it’s parent, <div id="wrap">. So, we already know what 1px is from before: 0.0625em. We simply multiple that by 18 to get the em value for 18px:

      0.0625 × 18 = 1.125em

      Or do the whole calculation in one go with the formula:

      1 ÷ 16 × 18 = 1.125em

      (1 ÷ parent font-size × required pixel value = em value)

      Then apply that to the CSS:

      font-size: 1.125em;

      To retain our vertical rhythm we want to set an 18px line height and margin. Easy: If the font size is 18px then 18px in ems is 1em! Let’s add the properties to the CSS (and make the font weight light:)

      font-size: 1.125em;
      line-height: 1em;
      margin: 1em;
      font-weight: 300;

    We now have vertical rhythm! Let’s move on to images.

    Sizing Images in ems

    To retain the rhythm of the the example page, the size of an image should be a multiple of the basic leading.

    Our image has a width and height of 90px (18px × 5.) It has right and bottom margins of 18px and is floated left in the paragraph text. This is the HTML:

    <img src="90.jpg" alt="Clevedon Pier" /> Lorem…

    The image is a child of the paragraph—it’s parent—so we know that the image has inherited a font size of 12px. Therefore, to calculate the image width and height we do the following using the formula:

    1 ÷ 12 × 90 = 7.5em

    (1 ÷ parent font-size × required pixel value = em value)

    Then apply that to the CSS:

    p img{
    width: 7.5em;
    height: 7.5em;

    We already know what 18px is in ems for the parent paragraph, so let’s add the margin property (and the float) to the CSS:

    p img{
    width: 7.5em;
    height: 7.5em;
    margin: 0 1.5em 1.5em 0;
    float: left;

    N.B. The image does not need to be within a paragraph to give it semantic meaning. The was used in this instance as an example of how to take inheritance into account whilst calculating ems.

    Now we have a supersuit elastic container with some elastic content and vertical rhythm like the example. With a bit of a luck, you have a better insight into creating elastic layouts, and designing with ems in particular. We’re done, you’re the Edna Mode of designers! The elastic example page has all the HTML and CSS you need. View source to grab it.

    Using Elastic Design

    Some of the benefits of elastic design for designers are precision, control and accessibility. However, some people have expressed concerns that allowing the content to expand past the edge of the viewport at larger text sizes could be problematic. Also, text will sometimes wrap and flow within the framework when the text size is changed; a minor issue, but worth noting.

    Concerns have also been expressed over the loss of image fidelity at increased text size. However, if a person changes their text size, the chances are they will also benefit from larger images, and browsers get better at resizing images as they increase in size. Hopefully browsers will get even better at resizing, or maybe we’ll soon have SVG and scalable background images to use.

    Implementing elastic design can deliver a deep understanding of ems in CSS. It definitely has a place in every designer or developer’s toolkit, whether in combination with other techniques in hybrid layouts or on its own.

    And finally…

    Any omissions or errors in this article are my own, so please let me know if I’ve missed something. If you know of other good and relevant resources elsewhere, please add them to the comments or email me and I’ll include them.

    I also take full responsibility for all refences to The Incredibles—my 2 sons gave kind permission for me to use their figures for the title image—and I hope Elastigirl doesn’t mind being compared to the em unit.

    References and Further Reading

    1. Resources:
      1. Elastic layout example (from the article)
      2. Reference table of common pixel font sizes and em equivalents
    2. Further reading:
      1. The amazing em unit
      2. Em discussion on Typophile
      3. The Elements of Typographic Style applied to the Web — Richard Rutter
      4. CSS2: Font size
      5. CSS2: Assigning property values, Cascading, and Inheritance
      6. CSS Layouts: The Fixed. The Fluid. The Elastic. — Mike Cherim
      7. Fixed or fluid width? Elastic! — Roger Johansson
      8. Elastic Design — A List Apart

    Can you Translate?

    Also, translated into Italiano by Nicola Pressi, and Deutsch by Pascal Birchler.

    If you are bilingual and would like to translate this article for non English speakers, please download my vCard via the about page and contact me. Thanks!