Simon Pascal Klein

The Aussie security–trade cock-off

2013-06-12T00:00:00+00:00

In this second image, then, Australia is a middle-power who’s economic interests are coming into conflict with its traditional security interests by virtue of the fact that its primary partners in security and trade are increasingly coming to see each other as strategic competitors in a contest over who has the largest and most gorgeous penis in all of the big blue Pacific ocean — which is full of trash anyways. The winner of this giant inter-civilisational cock-off stands to win all of the rubbish in the ocean which it can then recycle into sparkly-jewel bits that their militaries can wear on their colour-co-ordinated uniforms — which will make them really pop in that spring sunshine. That, or they could just use the literal islands of rubbish to Bedazzle their national junk. Either way, one dick will end up flaccid and the other will be using aluminum-decorated-pubic-hair to show the rest of the world just how glorious their national junk really looks when you get it in the right light. And won’t we all be so proud ourselves. (Seriously though, there’s a lot of shit in the ocean.)

From a friend.

Top 10 dos and don’ts of Web Typography

2011-04-13T00:00:00+00:00

As a designer setting type well is a common and important task. While honoring the text we’re setting we need to ensure its legibility and readability. Further we ought to provide visual cues that highlight relationships between and amongst the text. In doing so we provide the text with a range of qualities encouraging and empowering a reader to either skim quickly to a specific snippet of information or to comfortably digest larger sections of the text.

My list

To a good designer setting text becomes second nature, but having a quick checklist to fly through in order to ensure the basics are covered can be useful, particularly for aspiring newcomers to the field. This is my list, used as a set of general guiding principles:

1. Apply no more than three typefaces per design (or page)

Setting no more than three typefaces (or digitally, fonts) per design is a great basic rule. Applying and setting text with a larger variety of typefaces (even if they are similar) creates a sense of disunity; readers are given the notion that related if not the same types of text (e.g. body paragraphs) are unrelated. Using a larger variety of similar typefaces might side-step this disunity but the reader will still note — even if subconsciously — an oddity. Even if they are unable to describe and source the disturbance the effect can remain.

The reason “or page” is in this rule is to provide artistic freedom. Jason Santa Maria’s web site illustrates this fittingly with his creatively diverse designs and styles that his blog posts express, while his site at large retains perfect unity.

2. Set headlines large and invitingly, at the top of the page

There used to be this amazing fright of setting large text on the web. Body copy set at 10px (and even lower!) seemed rampant, and headings were rarely treated to anything beyond a slightly larger font size. Headings are some of the very first strings of text read by the eye when navigating to a new page, and vital to mark sections in passages. As such, grace headings with the size and styling they deserve to invite the reader and provide ample, but unobtrusive sign-postings for lower tier headings to guide the reader.

3. Size body copy 14px+

This is a related and perhaps the most important rule of thumb: give body copy the size it needs to be comfortably read on a screen. Of course a large range of other factors influence and legibility and readability of text and particularly more closely set body copy, but size remains critical.

Remember that not many of us have 20–20 vision; a good default is 14 pixels.

4. Ensure a good text to background contrast

Upping the font size is a sure way of making your text more legible, but legibility (and as a result, readability) will be diminished by poor contrast between the text and the background on which it rests.

The well-established standard is to place dark text on a light background, or vice versa. Absolutely avoid clashing colors or a barely visible grey on a white background.

Special care needs to be applied to light text on a dark background because it doesn’t have the same contrast (even though it first may appear so) as it’s cousin opposite: increase the tracking, measures, and leading accordingly.

5. Apply stress and emphasis discreetly

This is partly and editorial principle, partly a typographic one: don’t litter text with superfluous underlines, bolding, and italics; apply emphasis and stresses sparingly exactly for added and intentional emphasis.

On a side note, avoid overly long hyperlinks with underlines, particularly on serifed typefaces and even more so at smaller sizes. The default font-decoration: underline; will cut through glyphs with descenders (chiefly g, j, p, q, and y) and make them more difficult to discern. A handy solution is to set no text-decoration and instead use a border-bottom: 1px; or only on mouse hover (a:hover).

6. Do not set continuous text in full capitals

Ascenders and descenders exist for good reason: they allow us to easily identify words. A word that is set in upper- and lowercase is more recognizable than same word set entirely in uppercase due to the uniformity of the height and baseline of the word. For example, contrast:

‘THE RESULTS OF LEGIBILITY ANALYSES CAN BE CONTRADICTORY, BUT ONE THING IS CLEAR: TEXT SET IN CAPITALS IS HARDER TO READ THAN TEXT SET IN UPPER- AND LOWERCASE. THIS MAY NOT BE PARTICULARLY IMPORTANT IN THE CASE OF INDIVIDUAL WORDS, BUT IT IS FOR LARGE AMOUNTS OF TEXT. THEN TOO, THERE IS ALSO A GREAT DIFFERENCE IN THE AMOUNTS OF SPACE.’

with:

‘The results of legibility analyses can be contradictory, but one thing is clear: text set in capitals is harder to read than text set in upper- and lowercase. This may not be particularly important in the case of individual words, but it is for large amounts of text. Then too, there is also a great difference in the amounts of space.’

If you find yourself needing to set longer strings of text wholly in uppercase alongside regular body copy, consider setting them with a more ample leading in small capitals (font-variant: small-caps;).

‘The results of legibility analyses can be contradictory, but one thing is clear: text set in capitals is harder to read than text set in upper- and lowercase. This may not be particularly important in the case of individual words, but it is for large amounts of text. Then too, there is also a great difference in the amounts of space.’

7. Give the type space to breathe; set ample measures and leading

Leading straight on (no pun intended) from the close of the last rule, ensure your text has enough room to breathe; give it the space it needs, both vertically and horizontally to ensure a good, crisp contrast for legibility and readability.

Check that lines are not too short requiring jerky, quick dashes of the eye to trace to each following line, but also not too long to get lost when reaching the end of a line and then proceeding to the next. Going hand-in-hand with the line length is leading: provide enough space between lines, but not too much to rip the text apart.

8. Be wary of fonts not designed for screen use

Extending beyond the core web-safe fonts is an endevour deserving merit, but only select quality typefaces that match the medium you are working with. There is a fantastic abundance of fonts in the world, of which only a subset is good for setting body copy, and an even smaller subset of which has been optimized, or designed specifically for web use.

Look out for good hinting tables and test your font at smaller sizes (10px, 12px, 14px) on a variety of browsers and operating systems to gauge how well the various font rendering engines display the font.

9. Ensure webfont assets are subsetted and cached

When using @font-face webfont assets the page size will increase — the user agent (chiefly the browser) will need to download the font for text to be rendered with it. One way to reduce this load size is to subset the font: remove unneeded glyphs for characters you won’t ever be using (e.g. an English web site has little to need for Cyrillic glyphs and visa versa). The second is suggest to user agents to cache the asset for a certain period of time such that subsequent visits don’t result in re-downloading the font.

10. Don’t use Comic Sans

More of a personal note and frustration. But seriously, why would you use this overused and quite unattractive comic typeface when there are so many others to choose from, including freely licensed ones like Comic Jens.

And you?

That’s my list. What’s yours?

This article was originally written by me for, and published on DesignFestival.com — Top 10 dos and don’ts of Web Typography. It has been been republished here with permission.

Achieving good legibility and readability on the Web

2011-03-22T00:00:00+00:00

My last piece on web typography provided an exhaustive look at getting type to the Web, covering the ins and outs of the @font-face technology. Now that we can get the fonts we want rendered on the Web, let’s examine legibility and readability more closely by covering the elementary typographic factors that affect them.

At first, typography can seem like an inherently dull field — dealing with fonts and sizes, bolding this, and italicising that could come across as rather arbitrary, or as difficult: where does one start?

Definition and purpose

Definitions avoid confusion, and purpose gives us a light at the end of the tunnel. Quite simply, typography is the art of creating and setting type with the purpose of honoring the text it sets.

You will have already made a “typographic” decision by selecting an adequate typeface (digitally, a font) for whatever project you have in mind. The next step is dealing with the headings, subheadings, paragraphs, lists, tables, excerpts, quotes, and their many siblings (the micro) by making choices about how they are organised on the page (the macro: grids, columns, and margins). Then we can highlight how they relate to each other (§ Highlight relationships and provide navigation).

Typography exists everywhere where there is set type (i.e. movable type): it pertains to financial reports, the local newspaper, cereal cartons, the novels on our bedside tables, religious scriptures, and by extension, “movable type” on the web.

Each of us probably has a good grasp of what we think constitutes good typography. Looking at the local newspaper, or cereal carton, or the books on the bookshelf, you’ll probably be able to list a range of properties that make it “good”.

The merits of our typographic choices are immediately apparent, and two of the most important are a text’s legibility and its readability.

Legibility

Legibility refers to the recognizability of individual glyphs (the individual markings that signify the semantic character(s)). A range of factors influence a glyph’s legibility: stroke, width, angle (of the stroke), style (e.g. roman, full-capitals), slant (of the whole style), color (actual color and typographic color, i.e. contrast of the letterform to its background), background color, and more.

Readability

Legibility is distinct from readability. Readability refers to the recognizability of whole words, sentences, paragraphs, tables, or whatever the text en masse constitutes. A range of macro factors affect readability: the measure (line length), the leading (line height or spacing), justification or alignment, the style of the typeface, the kerning and tracking, the size of the type, and more.

Of course, both are interrelated; changes to the point size will impact the legibility of both the individual glyphs, and the words they compose.

Highlight relationships and provide navigation

Just like WCAG’s (WCAG 2.0, § 2.4) accessibility guidelines on ensuring that hyperlinks can be understood out of context, typographic hierarchy gives the text a certain “skimmability”. Good typographic hierarchy allows the text as a whole to be navigated with ease, such that readers can find their places again, or skip superfluous introductory information and get straight to what they are browsing for.

A good typographic hierarchy will provide visual cues to readers: headings are sized and styled in a way that makes them immediately identifiable as headings; paragraphs are uniform in styling, and their beginnings and ends are well marked out; quotations are recognizable, separate from the paragraphs they are enclosed by, and so forth.

Such hierarchies will also highlight inherent relationships between elements on the page: labels are placed in proximity to graphs, charts, and graphics, and through their proximity, are identifiable as descriptive notations.

In another example, imagine a more complex, two-color design. A table holding quarterly profit figures could feature a light-blue background, whereas the nearby table of detailing the quarterly loss could have a soft red background, and the aggregate of the two, superimposed on top of one another in a line graph, would have the profit line in a strong blue, and the line depicting losses in a hard red. Graph notations should provide a legend, but color can also be used to signify the relationships.

Colour, font style, spacing, position, indentation, and a range of other stylistic variations can be used to signify a relationship between elements on the page or across pages — and over the entire website as a whole.

Earned or unearned qualities

As noted earlier, we consciously (and subconsciously) judge the typography of texts. Look back to the newspaper, or pull out a book from the bookshelf, and describe what the text looks like. The newspaper might be bold and almost cheap looking, whereas a book on social psychology might be clean and organised, complete with footnotes and easily looked-up references.

Typography imbues set text with qualities, or a certain interest. A text can appear inviting, graceful, serene, cartoony, dodgy, unbalanced, and/or boring, and importantly these qualities can be both earned and unearned. A good typographer will humbly honor the text they are setting, in honor of the meaning of that text. Bad typography or a lack of care can discourage readers with a sense of boredom, inaccessibility, or cheapness.

Inducing a state of interest

Finally, good typography can induce interest among potential readers. Simply, grace the text with the respect it deserves; if the text is good, and intended to be read and understood, give it the typographic respect it is entitled to. In doing so you will induce a state of interest in browsing readers.

Achieving good legibility & readability

Let’s now focus on achieving the first two core goals of good typography: legibility and readability. The basics of these are well understood given that typography is well over 400 years old in the world of print, but in a digital medium there are a few additional considerations to be made.

Typeface

As previously outlined typefaces have a significant impact on the virtue of the text they set. Selecting a good and applicable typeface that honors the copy and caters for its requirements (e.g. if you know you’ll be setting mathematical symbols ensure the typeface has glyphs for them) is paramount.

Chances are you’re setting larger blocks of text. You will want to pick a good text font: faces that are designed for setting lengthier blocks of text. The best way to test a typeface as a text face is to set a paragraph of Lorem Ipsum in the basic roman at size 12px to 14px with a leading of 1 to 1.5 (see § Leading below) and see how it reads. Text faces can be both serif (e.g. Georgia) or sanserif (e.g. Arial).

Lorem Ipsum is a useful placeholder text when testing stylistic attributes. For testing actual readability it was pointed out to me that one should select a text that has meaning and is intended to be read. Stuck for something to use? Grab an article from Wikipedia or from Project Gutenberg. Thanks to David Owens for this suggestion.

Typefaces are declared in CSS with the font-family property and take descriptive values, either a generic family or specific font family, for example, a transitional serif font stack:

p {
    font-family:
        Baskerville,
        Times
        'Times New Roman'
        serif;
    }

Sizing

When setting type select a comfortable size: 14 pixels and up for most screen text fonts is a good rule of thumb. Not many of us have 20-20 vision and better a tad large than too small.

Note: JavaScript-powered text sizing widgets ≠ accessibility.

Don’t size text arbitrarily; try to stick to a scale:

6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 21, 24, 36, 48, 60, 72.

The “classical scale”.

9, 10, 11, 12, 13, 14, 18, 24, 36, 48, 64, 72.

Another scale.

8, 13, 21, 34, 55, 89.

A scale based on the Fibonacci sequence.

Type is best sized relatively using ems. An em is the distance horizontally equivalent to the type size in points (e.g. 1em of 12pt type is 12pt; 1em of 16pt type is 16pt). We can do this in the CSS using the font-size property:

p { font-size: 1.2em; }

Remember that font sizes are inherited within DOM from parents → children. This can make em sizing calculations for nested elements difficult. A good idea is to size everything in pixels first, and then convert over to ems. Pixels are easy to work with but fall short as a fixed unit, particularly when scaling a website (see § Measure below).

To calculate the desired value in ems, find what 1 pixel is in ems and then multiply by the desired font size (in pixels):

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

For example, if the parent font size (as defined by say the body element) is 16 pixels, but we’d like to size a paragraph — which is a child of the body element — at 12 pixels, we calculate: 1 ÷ 16 × 12 which gives us 0.75em.

The 62.5% trick

There is a neat trick to simplifying these calculations. Consider the following CSS:

p { font-size: 80%; }
blockquote { font-size: 80%; }

which styles this markup:

<p>This is a short paragraph, followed by a quote:</p>
<blockquote>
    <p>block quotes are blocks of quoted material, and can hold a range of 
       things, including paragraphs, lists, and even headings of course.</p>
</blockquote>

80% of 16px is 12.8px, so p and blockquote elements will be that size, but what happens when we put a p element inside a blockquote element? The parent (blockquote) is 12.8px so the p will be rendered at 80% of that: 10.42px.

Guh! Potentially quite confusing. Richard Rutter developed a neat trick to simplifying the sizing calculations of nested elements. Consider: * browsers have a common default size of 16px for text; * set the body to a font-size of 62.5%, resetting everything to 10px.

From here now the calculations are similar for direct descendants of the body, for example 12px = 1.2em; 8px = 0.8em, and so forth. Deeper nested elements are (still) relative of course.

Measure

The measure is the line-length. It’s important to keep lines at a comfortable length, not too long; not too short.

The eye finds difficulty in going to the next line on measures that a too long. A grand and almost infamous example of a website that could do better in this regard is Wikipedia, where the measure is relative to the length of the browser window; expand the window to full-screen on a widescreen and notice how suddenly where there was a comfortable 40 characters per line expand to 100 or more.

Conversely ensure lines aren’t too short that the eye has to drop lines every few words. There are some publication styles where short measures are popular, for example periodicals, but copy that’s set so short elsewhere begins to look cheap, as if once read it could be thrown away just like a newspaper.

Measures are set in CSS with the width property. Ideally set the design or total page width in ems and columns in percentages such that columns, the grid, the entire page design all scale proportionately. For example:

body {
    font-size: 62.5%;
    width: 96em;
    margin: 0 auto 0 auto;
    }
    div#content {
        width: 75%;
        float: left;
        }
    div#sidebar {
        width: 25%;
        float: right;
        }

In this example we’ve used the 62.5% trick to reset the base font size to 10 pixels in the body and defined a total design width of 960 pixels which is centered. Meanwhile, we’ve defined two div elements: one as a sidebar with a width of 240 pixels (25% of 960 = 240 pixels) and the other as a content container with width of 720 pixels (75% of 960 = 720 pixels). This design scales perfectly, even when only text-only zoom is available.

Leading

It’s important to provide ample space between lines for the eye to read along and travel between lines with comfort and ease. A good rule is to give copy with short measures less leading, and longer measures more leading.

Leading is controlled in CSS using the line-height property, and can set unit-less number values (e.g. 1.5) whereby it acts as a multiplier of the font size:

p { line-height: 1.5; }

This means the leading will be one and a half times the size of the font-size. Unit-less values are easier too keep track of and work with when setting leading for descendent elements, and scale nicely.

Alignment

Alignment is the placement and arrangement of text. When setting blocks of copy align text to the left margin or “gutter”, and don’t be afraid of having a ragged edge (i.e. “left-aligned”, “flush-left”, or “ragged-right”). Justification is great if there is a sufficient measure to cater for the adjustment of the word-spacing and ideally if automatic hyphenation is accessible — avoid justification in narrow columns of text.

Alignment is controlled in CSS using the text-align property, and takes descriptive values, for example:

body { text-align: left; }
    div#content p { text-align: justify; }
    div#content p.verse { text-align: center; }

The culmination (contrast)

Legible and readable text has a high contrast with its surroundings without becoming an eye-sore. Good contrast is achieved by setting text with the above factors in mind, with the addition of the color of the type to the background it is placed on. A good guiding principle is dark on light or visa versa. Avoid clashing colours or a barely visible grey on a white background.

In CSS the text color is controlled by the color property while the background is controlled by the background-color property and takes numerical and descriptive values. For example:

div#content p {
    color: #111;
    background-color: white;
    }

Pay attention to contrasts when working with light text on a dark background. Dark text on a light background generally has a higher contrast than light text on a dark background. Thus, when light text rests on a dark background check its contrast — increase leading and decrease font-weight as applicable.

div#footer p {
    color: white;
    background-color: #333;
    line-height: 1.8;
    font-weight: lighter;
    }

Closing

Robert Bringhurst once articulated: ‘well-chosen words deserve well-chosen letters’. Good web typography should seek to invite readers by revealing the tenor and meaning the text, and highlight relationships through a uniform hierarchy for ease of navigation.

In other words, web experiences that feature good typography are easier and more pleasurable to read and use. Applying these principles should provide your text with the first step towards this goal: elementary typographic goodness through better legibility and readability.

This article is a consolidation of two articles originally written by me for, and published on DesignFestival.com (Setting Type On the Web: An Introduction and Achieving Good Legibility and Readability on the Web). They have been been republished here with permission.

Getting type to the Web

2011-03-04T00:00:00+00:00

The last year and a half has seen a rekindling of the interest in web typography, marked by the popularity of sites like ilovetypography.com (now trending on 67,000+ subscribers) and the growing number of typography articles pertaining to the subject across the web design and development community. Typography remains central to aesthetics, accessibility, and of course legibility. Those who master it and apply it to the Web have been admired for the ingenuity of their work, both stylistically and in their technical implementation.

Typography brings aesthetic order to information, aiding reading and navigation. Typography differentiates; it is a core element of branding. The bottom line is that good typography when applied to the Web creates web experiences that are easier and more pleasurable to use. This renewed enthusiasm in the field has turned a new page in web typography, and can chiefly be attributed to the rise of web fonts and their growing availability across the browser range, permitting us to extend beyond the core ‘web safe’ fonts (Andale Mono, Arial, Courier, TNR, Impact, Verdana, Georgia, and Trebuchet MS). Good typography begins with selecting typefaces appropriate to the text being set; the right typeface or group of faces for the right work. Setting a graphic horror novel in TNR or Helvetica would be inappropriate to the genre of the book, and the graphical medium it utilises. However a good page-turner novel (for which a transitional typeface like TNR is far better suited) would be difficult to read if it were set in a script typeface.

Typography exists to honor content

Selecting good typefaces is one step and is perhaps made harder now that we have more than the core ‘web safe’ fonts to work with (or those that are next most likely to be installed). Implementing them for our web sites is another technical hurdle. This article highlights the options for getting type on the Web and then cover each method in detail while retaining a strong focus on web standards.

Options for bringing fonts to the Web

Browsers implement custom fonts in different ways. This disparity boils down to an open versus closed debate — locking down the methods to secure the font assets from easy download from the web site which uses them versus a more open model built on trust. To some degree this debate bears similarities to the one that raged when images were first available on the Web, and similarly, these differences in implementation have largely been settled as WOFF is hopefully finalised as a standard by the W3C.

There are a variety of methods available to us to bringing fonts to the Web for typesetting. They are, in loose historical order of availability:

installed fonts (mostly web-safe);
Flash (e.g. sIFR) and other JS replacement techniques;
Cufón et al.;
webfonts: EOT/EOT Lite via @font-face;
webfonts: OT/TT via @font-face;
webfonts: SVG via @font-face;
webfonts: WOFF via @font-face;
and hosting & licensing services.

Installed fonts

Calling upon installed fonts is the simplest and easiest method. Within our CSS stylesheets we simply call upon a list of fonts via the font-family property and order them as per:

desired
fallbacks
generic (e.g. serif, sans-serif, monospace,)

For example, a transitional serif font stack:

p {
    font-family:
        Baskerville,
        Times,
        'Times New Roman',
        serif;
    }

And a neo-grotesque stack:

h1, h2, h3, h4, h5, h6, h7 {
    font-family:
        Univers,
        Helvetica,
        'Helvetica Neue',
        Arial,
        sans-serif;
    }

If the first available font in the stack is not installed on the client machine it obviously cannot be used for rendering, so it skips to the next attribute in the list, and so on until an available font is found. Good font stacks reflect what is likely to be installed on the machines of our users by taking into account default font libraries for popular operating systems. This allows us to cautiously extend beyond the core ‘web-safe’ fonts by placing another preferred font in the list which still is quite popular.

Flash replacement techniques

Flash replacement is a nifty method of replacing HTML text with Flash text with the help of a JavaScript file. The most popular technique is the Scalable Inman Flash Replacement (sIFR).

While it has support for sub-setting, it is not a feasible long-term solution to bringing truly custom fonts to the Web, particularly with its reliance on non-standard technologies and use of JavaScript. It is also performance demanding with a longer page load time (predominately due to the number of requests made for the required Flash, JavaScript, and CSS files). Its best uses are for setting a single heading or a small series of headings, but it is far from practical for setting body copy.

Cufón et al.

A range of other JavaScript replacement options became available in an effort to get the job done without Flash. Cufón is perhaps the most popular of these with an online front-end for easy conversion of the font data into JavaScript that provides good support for sub-setting with a range of other options on kerning, scaling, cross object resource sharing (CORS) to limit use for a list of domains.

Cufón converts fonts paths to VML (now for the most part deprecated by SVG) stored in JSON and rendered by the JavaScript rendering engine within the user agent. While it has good browser support it also is not a viable long-term solution due to its poor accessibility.

webfonts: EOT/EOT Lite

Since the end of 1997 Internet Explorer 4 has supported Embedded OpenType (EOT) for use through the @font-face element that was introduced in the CSS2 specification. Microsoft’s EOT permitted the download of custom font assets for use in rendering type on a web page (and has seen helped bring writing systems that are not supported by default to the Web) without making those assets useable on the desktop and abetting font copyright infringement.

EOT subsets, compresses, and finally encrypts TrueType font assets. CORS is provided by way of a ‘trusted roots’ list. Unsurprisingly with a proprietary compression method, a proprietary encryption/decryption process, and support only in Internet Explorer, EOT and even EOT Lite (which omits the proprietary MTX compression and the CORS trusted root listing) is a proprietary and non-standard solution as a webfont format.

EOT files can be created with Microsoft’s WEFT, or through ttf2eot, an open source implementation of the converter. WEFT is worth skipping because:

it uses the MTX compression method and is out-performed by other methods like gzip;
it only works on Windows and tends to perform unreliably under emulators (e.g. Parallels);
ttf2eot does not compress — use server-side compression instead;
Font Squirrel’s @font-face web front-end to ttf2eot is simple and easy to use.

webfonts: OT/TT

These work in a similar fashion to EOT webfonts in being referenced in the @font-face src: declaration to be downloaded and used directly to render type.

OpenType/TrueType is a feasible, open method of providing webfonts with a fairly good browser support (Safari 3.1+, Firefox 3.5+, Opera 10+, Chrome 4+; IE9 beta, and Android 2.2+). Of course instantly apparent is that the font assets are not encrypted, bound to any trusted roots, or CORS limitations and are available in a format readily usable on the desktop outside the browser environment (e.g. desktop publishing and word processing) once easily downloaded. Further, sub-setting and compression is not automatic and the responsibility font assets’ host.

webfonts: SVG

These are also part of the @font-face webfonts specification, SVG are referenced in the src: declaration just like EOT, OTF, or TTF fonts.

Again, SVG files are not obscured and thus easily available for download for use beyond the web page they are referenced in. Browser support is fairly widespread also (Firefox 3.5+ Chrome 0.3+, Opera 9+, Apple iOS1+, and Safari 3.1+), and, as with OT/TT webfonts, sub-setting and compression comes down to the host.

SVG files can be gzip compressed into .svgz files.

webfonts: WOFF

Flash/JavaScript replacement techniques and then Cufón have shown web typographers and technologists that a dedicated, open, and standardised webfont format was required. Microsoft’s EOT, Ascender’s EOT Lite extension, OT/TT and SVG direct font linking all competed on the open ground of the Web in a popularity contest to see which would be adopted first with the most widespread use and browser support. This competition revived the discussion at the W3C over an open, standardised webfont format. WOFF seeks to fill this gap.

Working with the @font-face declaration WOFF combines compressed sfnt-font data (PostScript, TrueType, or OpenType) with a XML meta-data bundle to create an open font file perfect for bringing fonts to the Web. WOFF files are created with the open source sfnt2woff. Sub-setting comes down to the host. CORS is available via HTTP response headers. Ultimately the font data can still be extracted, but, if sub-setted, de-packing a WOFF font file to extract useful font data for external use requires effort and it’s likely the resulting font data will be limited (due to the sub-setting).

Currently WOFF is supported in Firefox 3.6+, WebKit, Chrome 5+, and the IE9 development beta.

Hosting & licensing services

While the search for a good, open, and standardised webfont format was underway many foundries and a number of technologists began exploring their own ideas in bringing custom fonts to the Web. Since a number of web hosting and licensing services have sprung up offering a library of fonts at a variety of free and commercial plans: TypeKit, Kernest, Fontdeck, Monotype’s webfonts.fonts.com, Typotheque’s webfont service, &c. Create an account, browse the library, select, pay, inject a few lines of code, refresh; done.

The fontdeck.com homepage.

On the technical side these services provide the right or best font (EOT, OT/TT, SVG, and soon WOFF) to the right browsers — if a query is made by a user using Internet Explorer an EOT file would be served. Sub-setting is done by the providers, depending on which languages and features you are likely or wish to use, and compression is also handled service-side.

The implementations are largely standards-based and provide very extensive browser support. The web front-ends are easy to use, and have an ample library of quality fonts up for selection between all of the services providers.

Finding freely-licensed fonts

Now that we can implement custom fonts on the Web using @font-face you might wonder where to obtain freely-licensed and free of charge quality fonts for use on the Web (and elsewhere). Places worthy of your attention:

the openfontlibrary.org;
theleagueofmoveabletype.com;
fontsquirrel.com, particularly the pre-generated @font-face kits;
the webfonts.info wiki listing;
and Google’s Font Directory available via their Font API directly for linking.

Using `@font-face`

If you choose not to use a hosting and licensing service and instead opt to host and reference font files using @font-face yourself, creating the various font files and getting the syntax for the declaration correct might seem daunting. In reality using a bullet-proof syntax from to Paul Irish and Font Squirrel’s @font-face web front-end it is a piece of cake.

Creating `@font-face` webfont files

If you have a font you want and can use on the web your font is likely to be an OT/TT or PostScript file, which you need to create compressed and sub-setted EOT, OT/TT, WOFF, and SVG files for. The easiest way of meeting all these goals is to use Font Squirrel’s @font-face web front-end:

The Font Squirrel @font-face Kit Generator.

Simply select and upload your font after which you can take the easy route and use default settings to let Font Squirrel to generate your kit for you to download, or you can take the ‘Expert’ path and fine tune just about every nuanced detail of the resulting font files. Accessing custom sub-setting allows precision control over sub-setting character types, sub-setting for languages, sub-setting via Unicode tables and ranges, as well as specific characters, presenting a list of all the characters that will be included in the resulting sub-setted font files.

When you are done download your kit ready for deployment.

‘Bullet-proof’ `@font-face` declarations

Writing a bullet-proof @font-face is not difficult, but there are some gotchas to watch out for. Let’s get to work.

Basically we want to feed Internet Explorer an EOT file and feed other browsers OT/TT files while providing forward support for WOFF-supporting browsers. The order in which we list these files in the src: declarations is important because (surprise, surprise) Internet Explorer will otherwise needlessly download the other files even though it cannot handle them, wasting page load time on unnecessary additional connections and traffic. Thus, using Museo:

@font-face {
  font-family: 'Museo 500';
  src: url('Museo500.eot');
  src: local('?'),
       url("Museo500.woff") format("woff"),
       url("Museo500.otf") format("opentype"),
       url("Museo500.svg#museo") format("svg");
    }

Dissecting this, we start by giving the font we want to link a name we can reference for font stacks. The attribute is arbitrary.

Next comes the EOT file, first in the src: list as to avoid IE having that aforementioned fit.

Then the local src: call, though we actually omit specifying a local src: declaration, instead entering ‘?’. There are two main reasons for this. Firstly, it prevents the (although rather unlikely) chance that the user will have a font installed (which will be used instead, saving the download) that matches your local attribute but is not actually your desired font wrecking your font stack and possibly your design. It is very unlikely that a font installed will be named ‘?’, and under the OpenType specification any two-byte unicode characters will not work as a font name, excluding Macs entirely from this problem with this solution.

Secondly, there a variety of bugs still evident in Webkit and Mac OS X in handling local references. If you feel certain that there is a high likelihood that a user could have your desired font installed (e.g. it is a freely available and freely licensed popular typeface like Museo) and it would be unlikely that there could be another font installed that bears the same local reference then making local entries is quite OK — it comes to weighing up the likelihood of either instance.

In case you do want to define a local src: reference it might seem odd that you can write two slightly different entries for local in src:, for example: src: local("Museo 500 Italic"), local("Museo500-Italic"),. Huh? This is because some browsers refer to local fonts via their PostScript names. To find the local names for a font under Mac OS X open Font Book, select your font and select Preview → Show Font Info (or ⌘ + I). For Windows there is a downloadable Font properties extension. Once installed right-click and zip to Properties on a font file and click on the Names tab to see the name details.

Screenshot of Mac OS X’s Font Book demonstrating the Font Info view mode.

Then come the WOFF and OT/TT src: definitions, followed by the SVG definition. Note the #museo in "Museo500.svg#museo". This is because SVG files are XML files and thus we need to reference the starting div (e.g. after the opening meta-data) that references the start of the font vector paths.

That’s it; done. Credit and kudos goes to Paul Irish for revealing nitty-gritty details of writing bullet-proof @font-face syntax definitions.

Problem: ‘double-setting’ styles and variants

When using @font-face, we are likely to be dealing with separate font files of the same family for the various font styles, e.g., foobar-regular.otf, foobar-italic.otf, foobar-bold.otf, foobar-smallcaps.otf, and so forth.

This can become an issue — consider elements such as strong and em which are styled with setting the face in a bold and italic respectively. If we declare the italic as we would normally in the CSS (as we would to get the style into our design) what will happen is that the italic is digitally italicised (fake italics) by the font rendering engine. Result? Our italic font or bold font is taken and digitally italicised or boldened, creating ugly results.

If we avoid or overwrite the various declarations (e.g. em { font-style: normal; }) and for whatever reason our desired @font-face font is not available, we rob other fonts in the font-stack of their styling. We overcome both these issues by setting the font styles within the @font-face declaration, informing the user agent that we are in fact defining an italic or a bold already and that these should be left as is when used to set something that is declared via the CSS to be italic or bold:

@font-face {
  font-family: 'Museo 500';
  font-style: italic;
  src: url('Museo500.eot');
  src: local('?'),
       url("Museo500.woff") format("woff"),
       url("Museo500.otf") format("opentype"),
       url("Museo500.svg#museo") format("svg");
    }

Considerations

Caveats, drawbacks, and compromises exist in everything, and type setting is not excluded. There are a number of considerations that need to be made and kept in mind when putting type on the Web. Many of the compromises that are made in the print world do not apply to the web medium, but others take their place.

More ≠ better

Corresponding to the growing availability of new fonts for the Web it is important to note that more fonts does not necessitate instant better typography. Fonts are assets. They may be thought of as a tool in the toolbox; a wallpaper in an interior designer’s arsenal. She might have access to a thousand different patterns and colours of wallpaper but if most of them are of a poor quality material or just lack the required pleasing grace that is required to open up and brighten (or darken as the situation merits) the space they are applied to then having another thousand more does little good.

For screen or print?

In addition to artistic concerns, many typefaces available as fonts for the Web have not been designed for web (or more accurately screen) use. Type design and typography blossomed in the print industry. There are hundreds of exquisite professionally designed and cut typefaces and families available for all types of print work, but many of them have not been readied for use on a screen. Good fonts that were designed or have been carried across to the digital world have been carefully optimised to render perfectly on a pixel screen. This optimisation is known as hinting and good web fonts subsequently have good hinting tables.

Sub-setting

A digital font is data, and large fonts, i.e. ones that have a large glyph set covering a large character range will begin to become sizeable assets for the user agent to download for rendering. Two techniques are used here to reduce the size of font assets to make them smaller thus reducing network latency.

The first technique is called sub-setting, and is a process of removing glyphs for characters from a font file that are not used. Imagine a great high-quality superfamily with fantastic language support that also boasts additional historical ligatures, various extra stylistic sets, swashes, small-capitals, and more. A single font for even just the roman of this family could exceed a 1024 kB. If none other than ASCII, Latin 1, Latin Extended-A, and Latin Extended-B is needed (which covers all Western European Languages with a bit of wiggle room) there are a lot of unused characters for which glyphs are downloaded superfluously.

Sub-setting can be done in a font editor (such as FontForge, the free software font editor). Simply open your font, select unused character blocks and delete them; save — make sure you keep a copy of your original though.

Compression

The second technique is compression. Compressing font asset is much like compressing files to reduce the size of email attachments. Through compressing font files we can further reduce latency and network traffic. This operation is done server-side, compressing various assets that the user agents requests which upon download are decompressed on the fly and used to render the web page.

The two most popular methods are through external extension modules to the Apache web server; mod_deflate and mod_gzip. It is likely that your web hosting service will provide support for at least one of these (if not it is a worthy request to make — after all lowering their latency and traffic is in their own operational interest).

If you find yourself using Microsoft’s IIS there is a HTTP Compression setting that can be enabled and tuned.

Configuring mod_deflate

Once installed and enabled we can configure mod_deflate in our .htaccess file:

# Compression using deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css

<FilesMatch "\\.(js|css|html|htm|php|xml|txt|otf|ttf|eot|svg|woff)$">
    SetOutputFilter DEFLATE
</FilesMatch>

In FilesMatch list the file extensions for which files mod_deflate should compress.

Configuring mod_gzip

Similarly mod_gzip can also be configured in the .htaccess file:

# Gzips content if possible
<IfModule mod_gzip.c>
    mod_gzip_on Yes
    mod_gzip_dechunk Yes
    mod_gzip_item_include file \.(html?|txt|css|js|php|pl|otf|ttf|eot|svg|woff)$
    mod_gzip_item_include handler ^cgi-script$
    mod_gzip_item_include mime ^text\.*
    mod_gzip_item_include mime ^application/x-javascript$
    mod_gzip_item_include mime ^application/json$
    mod_gzip_item_include mime ^application/vnd.ms-fontobject$
# There is no content-type for OTF yet, so we can get away by just
# listing the extension in the mod_gzip_item include file listing.
# For the sake of being good I have added the vendor-specific
# IANA content-type for EOT.
mod_gzip_item_exclude mime ^image\.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
    mod_gzip_send_vary On
</IfModule>

Just like mod_deflate’s FilesMatch using mod_gzip_item_include file we can list the file extensions for files that mod_gzip should seek to compress. The content types can also be listed via the mod_gzip_item_include mime lines by notating the IANA media types as done for the vendor-specific EOT vnd.ms-fontobject.

You can test how well compression is performing through a variety of browser developer plugins or by using Mark Nottingham’s REDbot, a robot that checks HTTP resources for common problems and pitfalls. For example, when checking http://sitepoint.com REDbot notes via the Content-Encoding that mod_gzip is in use. When checking the assets we can see that 84% of the original size of the page (when decompressed) is saved through the use of mod_gzip, with detailed figures for the various assets.

Caching

FInally we can also cache our font files reducing both latency and network traffic. Caching allows us to inform the user agents that access our site and download our assets that some of the assets are unlikely to change in the foreseeable future, and as such downloading them again when accessing out site at a later stage will be a waste of time and data — just store (‘cache’) these assets in the user agent’s cache locally. Assets that would be unlikely to change would likely include stylesheets (.css files), JavaScript files for site functionality (.js script files) and of course font assets.

We can cache various assets via the .htaccess file by again selecting a range of content types with FilesMatch and then setting a maximum time that these assets should be cached by user agents before downloading the asset again (to ensure cached copies remain updated). Note: the max-age time is set in seconds (here 2592000 seconds = 43,200 minutes = 720 hours = 30 days).

# Cache following file types for one month
<FilesMatch ".(js|jpeg|jpg|...|otf|ttf||eot|svg|woff)$">
    Header set Cache-Control "max-age=2592000"
</FilesMatch>

And that’s it!

Now empowered to apply custom fonts onto the Web either self-hosted or via a web font licensing and hosting service be sure to look out for the second article in the series on styling that freshly set type all pretty.

This article was originally written by me for, and published on DesignFestival.com — Getting Type to the Web. It has been been republished here with permission.

Anti-procrastination wallpaper and some musings

2011-02-26T00:00:00+00:00

I procrastinate. Just about everyone does. I do it chiefly when my tasks seems too hard or I can’t seem to summon the motivation to do it, and I just “quickly” dash off to check this (email), or that (my news reader), or the other (a video of an explosive ordnance disposal marine dancing). To keep me in line (and because I was getting bored of my recent wallpapers) I quickly did up a motivational wallpaper.

The wallpaper

German: Zaudern ist eine Verschwendung von deinem Potenzial; zurück an die Arbeit. (‘Procrastination is a waste of your potential; get back to work.’). Feel free to grab a full-sized version for yourself.

Two realisations on procrastination

After musing over why I procrastinate (somewhat ironically I may have been procrastinating at the time) I came to two small epiphanies.

Dealing with hard tasks

The first concerned to-dos that seem too hard or complicated; I feel like I don’t know where to begin? Classic examples for me have been writing an essay, writing an article for this website, or getting that design job started. My solution has been fairly simple: explore and break down the task. A task called “Write major essay on Foucault’s theories on power and power relations” is an abstract and unappealing to-do. This should become a project ideally, under which other tasks are organised, including for example: “research topic”, “brainstorm topic”, “construct core argument or thesis”, “write an outline”, “write first draft”, “send draft to friends for review”, “final polishing”, and “hand in essay”.

So if you come across a to-do that seems abstract try to break it down. A good sign that hints to an overly abstract and problematic task is a one whose estimated completion time I can’t estimate with certainty. Solution: take that say three-hour or four-hour task into smaller, digestible and easier tasks.

Tasks you just don’t want to do

The second was over those things that sit in my to-do list but I don’t particularly want to do. It might seem boring, annoying, tiresome, arduous (see above) or whatever else. The bottom line is they need to be processed (that’s why it’s in your to-do list, right?). Besides the obvious — define what the problem is (e.g. is it too abstract?) — realise that the item is in your to-do list for generally one of two reasons:

You actually want to get it done. If this it case then just get it done and think of the grander scheme of things (the satisfaction of getting it done and getting to the next phase in the project). If possible break down the task into smaller tasks.
It’s something you accepted (for any number of reasons) that you now, in retrospect regret taking up. At this point you have a fork: get it done and learn from the experience to avoid taking on a task like it again, or if it actually needs reconsideration revisit the item (and possibly project); you could delegate it, consult the friend or client or whoever is involved. Importantly: learn from the experience and try to avoid it occurring again.

Why do you procrastinate? How do you avoid it?

Why I have not bought an iPad

2011-02-15T00:00:00+00:00

Besides the cost or more specifically the opportunity cost (saving that money, grabbing this elegant Victorian military coat for the upcoming winter), or a list of other goodies and necessities), there a range of reasons why I haven’t purchased an iPad (or other tablet for that matter).

This might read as a scathing assessment, but it is really more a personal reality check after having fantasized about the iPad so much recently.

The iPad and a cut of its brothers and sisters from the Apple range. Photo by Mehrad.HM, licensed CC-NC-SA 2.0.

To me the iPad sits between a smartphone and a laptop. Both are established devices catering for a fairly developed (and changing) list of tasks and use cases. Let’s take a look: * the iPad definitely does some things better than a smartphone, but; * it’s bigger (doesn’t fit into your jeans pocket), and vitally, doesn’t do telephony; * the iPhone does an OK job for things an iPad does pretty well (and makes calls), * and for tasks the tablet does pretty well, my MacBook does even better; * thus where I need mobility, I stick to the iPhone, * and when I know I need to get proper work done, I take the laptop.

Exploring the use cases

To explain this thinking I’ll run through a few use cases.

Audio-visual

I listen to music all the time. I tune into podcasts a lot too, and I also watch YouTube videos and films fairly regularly. I’ll either be out and about using the iPhone (music, podcasts, and the occasional YouTube video) or at home, using my sound system or my Sennheiser headphones. If I want to watch a film, I’ll watch it on the TV or my laptop with the sound system. Use case for the iPad: none.

Browsing

If I want to browse the web, it’s typically for a snippet of important information that I need while mobile (e.g. travel time tables), or to pass the time catching up on a few webcomics — both tasks the iPhone is quite fine for. Otherwise I’m in front of my MacBook. Use case for the iPad: next to none.

Taking pictures

I don’t take that many pictures. If I want to take pictures I could use the iPad… oh, wait, nevermind. When I to take photos I’ll either want a quick shot of something for which the iPhone suffices or I’ll want to actually shoot proper pictures, and I’ll bring along my DSLR. I think the iPad actually goes short here: a camera in a mobile device is something most users expect from modern devices and especially Apple devices. Use case for the iPad: it has no camera…, i.e. none.

Reading

I find myself reading a lot, particularly for my university courses. When I want to read ebooks or PDFs I take my Kindle 3, which has a better battery life (cheers to the E ink screen) and is comfortable on the eyes over a long period of time (again, the E ink screen). Use case for the iPad: I wouldn’t want to spend $500+ a device that doubles as a mirror; none.

Other considerations

no multi-tasking
no Adobe Flash;
no HDMI out;
no widescreen (again something I think users would almost come to expect from Apple, though, granted this was probably a compromise in the product design);
a closed application ecosystem;
attachable keyboard? — if I had an iPad and the attachable Apple keyboard (for a whopping USD $69) I’d wonder why I didn’t bring my laptop.

Good use cases?

Hard to say. Maybe a nice solid platter to serve appetizers and have a fancy wall paper underneath. Too thin to be a door stop.

Beyond the glorified paperweight, electronic picture frame, or the yuppie coffee table highlight (providing gaming, music, basic browsing, YouTube, around and near the coffee table) I think there are a few good use cases for the iPad. For me the coffee table appliance is attractive, but an incentive to waste my time and when I need to do work my MacBook is just as mobile, and better.

Those aside, there are a few specialized apps for specific industries (e.g. mining, medical, education perhaps, …) for which the iPad is probably great.

The smartphone & laptop market

The smartphone market is becoming more competitive with the entrance of direct iPhone competitors. The existing BlackBerry range and the recent rise of Android phones offer a good range of features that keep prices competitive. Bottom line: you probably need a mobile phone, and smartphones are cheaper than tablets (which generally can’t do telephony).

By a similar accord the entry level laptop or netbook market is also highly competitive. In fact many netbooks are cheaper in price than an iPad (e.g. the Asus EeePC) while a fully-fledged MacBook is only $500 more expensive than the basic iPad model and $170 more expensive than the upper range iPad. Bottom line: most netbooks are cheaper, and a decent laptop is only a tad more expensive.

Closing

I prefer using tools that do one or a few things well, and avoid tools that do many things poorly. The iPad remains a tool that does a few things better than my phone, but lacking telephony and the power of a proper laptop it ends up performing many of the tasks required in my use cases poorly: * my iPhone is chiefly a phone, and fulfils a range of smartphone functions quite well; * my Kindle is chiefly a reading device, and it does that perfectly; * my Canon DSLR is… a camera, and shoots pictures perfectly; * and my laptop does just about everything else I need.

Sorry iPad.

How I browse the Web

2011-01-14T00:00:00+00:00

Developers, authors, and service providers of content and applications have an obligation to try to prevent harm from coming to their users by use of their work. Users have a natural inclination in this regard; i.e. looking after yourself. The former group need to remain on top of the latest and best practices to keep their users safe. However, as users are the recipients of both good and bad security, it is they who will benefit most from staying informed

There is a nice quote I remember reading a few years back:

Building software is a constant struggle between software engineers trying to build bigger, better and more idiot proof software and the Universe trying to build bigger and better idiots. So far the Universe is winning.

Although the design vs idiocy struggle isn’t really over (my good friend Andy White reminded me of product warning labels), we have realised that we can teach people a variety of habits and shape their expectations through use. That aside, I think the quote from above can be aptly reworded to fit a ‘new’ problem we have encountered:

Building software is a constant struggle between software engineers trying to build bigger, better, and more secure software and malicious parties trying to find bigger and better loopholes. I’m not sure who is winning.

The onus has always been on the service provider to ensure user security (and privacy), and while that responsibility has not shifted (if it failed on your watch expect legal repercussions), clueing in users will help in the good design vs malicious intent struggle by making life harder for those with ill intentions.

My beginning on the Web

I have thankfully had very few encounters with malicious software in my almost ten years of working on computers. Before I had access to the Internet I played Diablo II and Starcraft on an old Windows 98 box that had little to no connection beyond itself (I didn’t have the money to afford a USB memory stick back then). When I finally got my own computer with ’net access it wasn’t long before it ran SuSE Linux and after various Linux distributions I now find myself chiefly on a Mac. While Linux and the Mac are generally accredited with being more secure in their integral design than Windows has, the Web remains an interesting playground, and browsing behaviours contribute to privacy and security.

For a long time I had no idea what third-party cookies were, yet alone what a cookie was. JavaScript and Java were analogous to me. HTML was some weird way of writing up what the web page in its rendered finality seemed to do a lot better and prettier, and everything in Flash (when it worked) was absolutely stunning and awesome. Disillusionment swiftly followed as I wanted to publish my own content onto the Web.

It was not until I myself wanted to publish content onto the Web that I began to understand the technologies I was using and even relying on every day. I had become (and still largely am) impatient in my use of software, a characteristic that is widespread in most users of computers. We want to get it as fast as possible, install it as fast as possible, get it going as fast as possible and get the desired results (which may or may no coincide with the program’s actual functionality) as fast possible. User manuals seem a concept married in the past, together with big grey boxes and CRT monitors.

This impatience (and the ease by which we can be distracted it is coupled with) is a major hurdle in finding the interest and dedication to learn about the technologies of the Internet which are used by almost two billion people.

My learned practices

Two core principles form the foundation of good security and privacy for me: Trust No One (TNO) and no or minimized disclosure. Following these tenets can be inconvenient and at times seemingly unnecessarily bothersome but I strongly believe they have kept my financial information secure, my passwords impossible to guess and near impossible to brute force within an average human life time (if not thousands of years), malware off my computers, and my personal information safe.

Each of the following lessons and practices branch from and support these two principles.

A better browser

The first step I took on Windows was leaving Internet Explorer in the dirt and getting a safer browser. While just about all of the major modern browsers nowadays are fairly reliable and secure (and can be tweaked for improvement) the default settings and behaviours still sets them apart. That aside, pick from Firefox, Safari, Chrome, Opera, Epiphany, (and/)or Konqueror.

I primarily use Firefox on my Mac.

A password manager

For a long time I withheld from using a password manager or keyring. I gave the one inbuilt in Firefox a spin twice and found it sucked hard the moment I was away from my computer. It did a lot of things well but I also wished it could do a few things more: store secure notes and financial account details. Later I found what I craved in 1Password, which integrates with my browser and phone.

The primary upside of using a good password manager is you stop using the same three or four passwords for all your online accounts, particularly given the likelihood that your passwords were never that good as per their memorability. With a good password manager you can auto-generate pseudo-random maximum entropy passwords for every account and have them auto-filled when revisiting a web site later.

There are a bunch of password managers out there supporting a variety of operating systems, browsers, and features — do some research and fine one that suits you.

Dealing with pop-ups & listed malicious content

Third was killing pop-ups, and not just the advertisement variety. Most good browsers have their own in-built pop-up blockers. If your browser doesn’t I would reconsider using it at all. Similarly good browsers should automatically stop you from inadvertently accessing listed malicious web sites (and web sites that have been hijacked to serve malicious content) along with phishing and malware.

Kicking ads

Although not inherently unsafe or a threat to privacy, ads are worth mentioning here. This is a contentious issue to some, but to me it’s dead simple: I refuse to browse the Web glutted with ads, particularly the distasteful, useless, and annoying variety that incessantly get in the way of me trying to do my work. I would probably be quite content with an ad blocker that blocked ‘annoying’ adverts only but getting a computer to distinguish between the annoying and passable is nigh impossible.

Ultimately my position on adverts is an extension of my strong belief that it is my choice how to render a Web page — scripting, sudden redirections, pop-ups, and adverts can take away that control and thus I choose how and when to enable them.

To block adverts I use AdBlock Plus.

JavaScript execution control

JavaScript (JS) is a powerful tool for adding a lot of extra pretty and nice features to enhance a Web experience. JavaScript can power enhanced document navigation, event handling (e.g. logging in/out; adding items to a shopping basket), animation, and more. JavaScript can also be used to launch 100 new tabs or windows of your browser, automatically download and execute malevolent software, hijack your accounts on social networking sites, and more.

While JavaScript is generally executed in a sandbox environment and under the terms of a same origin policy, one bored afternoon’s visit to an off-site link listed on Encyclopedia Dramatica many moons ago caused me to reconsider permitting any and all JavaScript from automatic execution upon opening a Web page.

I use NoScript which allows me to make selective decisions about what to allow and what to block by default, while the page has already loaded (e.g. enabling a single embedded Java or Flash applet while continuing to block everything else), and for future visitations to that domain.

There’s a good introductory video on NoScript by CNET on YouTube.

Forcing secure connections

Logons to web sites like Facebook or Twitter are kept active over time via cookies through expiry timestamps. When you login to Facebook, a Facebook server notes that you have logged in and issues you a cookie with your account and a session ID hash, linking your future requests with responses from the server that match your account via that cookie. There is however nothing to stop a third part from intercepting network traffic, noting the cookie, and automatically gaining access to your account by simply making a request to Facebook and sending them your cookie.

Attacks like these are long and well documented, and have been simple to orchestrate for years (and now as easy as clicking through a menu with Firesheep). The good news is that they are just easy to protect oneself from: HTTPS; an ongoing secure HTTP connection.

Sadly, most web sites that feature user accounts do not offer continued secure logins beyond the actual logon page, including Facebook. Some of these service providers allow for ongoing secure connections over HTTPS but default back to unencrypted HTTP communication, or have links on encrypted pages back to unencrypted ones. I use HTTPS-Everywhere, a Firefox plugin by the EFF that rewrites all my requests to a number of popular sites to use HTTPS.

HTTPS-Everywhere supports Amazon, Amazon S3, bit.ly, Dropbox, the EFF, Evernote, Facebook, GitHub, GMX, Google APIs, Google Search, Hotmail/Live, Identica, Mail.com, NYTimes, PayPal, Twitter, the Washington Post, Wikipedia, and more. You can also write your own rulesets for additional web sites.

Privacy and tracking

Advertisers have been interested in and actively tracking users across the Web for years. If you visit a web site — even one you like and tend to trust — it could be serving up advertisements from third parties (e.g. DoubleClick) which may attempt to track you across the Web in order to get a sense of your browsing habits, build a profile of you, and then target adverts to you.

At first this sounds somewhat cool, but imagine purchasing a gift (e.g. a wedding ring) for your partner and as a result online adverts begin to display wedding-related sales and services. Now imagine if this computer was shared with your partner, and you haven’t proposed yet.

Some of the existing tools noted above (a good ad blocker, good JavaScript execution control, good cookie management, and pop-up blocking) already help in reducing the ability for you to be tracked. In addition I also use BetterPrivacy which looks after LSOs i.e. flash cookies and their speedy deletion. For those who rely on some Flash applets and retaining important data (e.g. preferences for that applet) you can create a whitelist.

Opt-in or opt-out? Some advertisement and tracking services offer an opt-out feature — ‘if you don’t want to be tracked via cookies and/or other identifying sticky information click here to create this cookie and/or other identifying sticky information that says you don’t want to be tracked’. Do not track ≠ do not call, as in telemarketing. Until a specification inclusion in HTML headers is made for a ‘do not track’ variable, opt-in services (which still fall under TNO) and the browser tools above will continue be my safeguard against unwanted tracking.

When my privacy is ultimate I switch over to the secure and private browsing modes provided by most good browsers, particularly with insidious tracking methods like those used by the EverCookie.

Closing

Keeping on top of it all

Some of these tools and some of my current practices might become defunct or redundant in the coming years as the Internet grows and evolves. Keeping up to date with the latest if not fairly recent best practices can be difficult if you’re not working in the security domain or have a penchant for security, and that’s fair enough — if you’ve gotten this far and haven’t broken off to work towards ticking off some of your to-do items then kudos.

I don’t really follow any of the major security portals or analyst blogs (besides infrequent visits to Bruce Schneier’s blog), and only tune into the occasional simplified news story of a security or privacy related event when I happen to be watching TV (which I rarely do these days anyway) to see how it is reported. My springboard for security news currently remains the Security Now podcast by Steve Gibson (hosted by the TWiT podcasting network and also available on iTunes). While Steve’s site isn’t the prettiest ornament on the security Christmas tree and his podcast covers a lot of Windows-related security news (which barely affects me) his coverage remains broad and his explanations are very accessible yet comprehensive.

Das Ende

That’s it — those are my core principles and the browser tools I use that support them. I would be interested in hearing what your best practices are and which tools you use to support them.

Jekyll, a static site generator

2010-11-01T00:00:00+00:00

When I decided to relaunch my web site I chose to give WordPress the flick and try out Jekyll, a Ruby-based static site generator. Jekyll? In the documentation it is described thus:

Jekyll at its core is a text transformation engine. The concept behind the system is this: you give it text written in your favorite markup language, be that Markdown, Textile, or just plain HTML, and it churns that through a layout or series of layout files. Throughout that process you can tweak how you want the site URLs to look, what data gets displayed on the layout, and more. This is all done through strictly editing files, and the web interface is the final product.

Jekyll is a blog-aware, static site generator. It uses a set of template or layout files, the associated CSS files, and plain text files for the posts. The posts can use the Markdown format or another similar markup language. Jekyll grabs the post markup and inserts it into the layouts, spitting out standard HTML markup — along with linked files (any CSS, JavaScript, images, and the like) — ready for you to upload to your web server. There is no content management system, no database, and no specific language support on the web server required; your site is a collection of plain old static HTML files.

Switching back to static markup may at first seem like a reversion to the late 1990s. Yet Jekyll is a simple and elegant system that mimics the characteristics of a dynamic site — drawing content from a database and inserting it into templates via a CMS — without all that complexity. As a firm believer in the KISS principle (Keep It Simple, Stupid), I always try to find the right tool for the job, and Jekyll is a simple solution to a common problem: “I want my own customised blog.” Jekyll is also flexible enough that it can easily be used for other tasks. For example, GitHub uses it to drive GitHub Pages.

This article describes using Jekyll to build a web site: from downloading it, setting up a development environment, and hacking up template files. I conclude with a word on maintaining updates between your development instance (for example adding new blog entries) and synchronising them to your web server. Note that I wrote this piece from a designer’s perspective. Although I had a number of technical hurdles to hop over, Jekyll remains rather simple; for instance, using Jekyll’s template system and Liquid tags is easier than hacking a design as a WordPress theme. I intend this article to be as designer-friendly as possible.

Setting up a Jekyll blog is relatively smooth-going and boils down to a few straightforward steps.

Setting up your development environment

Jekyll is written in Ruby, so you will need to install it. It is as simple as downloading the latest Ruby version for your platform and following the installation instructions. The Ruby installation also includes the RubyGems packaging system, and allows you to download and install other Ruby libraries and programs. If you are using Windows, choose the one-click installer, and make sure you tick the Enable RubyGems option when running the installer.

We will be fetching Jekyll from the Gemcutter RubyGem hosting repository, but we first need to install the Gemcutter program.

If you are on Mac OS X or Linux, open a command prompt and enter the following commands:

$ sudo gem install gemcutter
⋮
Successfully installed gemcutter-0.1.7
1 gem installed
Installing ri documentation for gemcutter-0.1.7...
Installing RDoc documentation for gemcutter-0.1.7...
$ sudo gem tumble

The tumble command will simply make the RubyGems installer query the Gemcutter repository first, when downloading RubyGem packages. This ensures that Jekyll is downloaded from the Gemcutter repository.

Now we can download and install Jekyll:

$ sudo gem install jekyll

If you are on Windows you need to be entering the commands at the Windows command prompt (Start → Run… and enter cmd):

C:\> gem install gemcutter
C:\> gem tumble
C:\> gem install jekyll

Jekyll, like all good software, is modular and does one task very well, relying on other programs and libraries for additional functionality — after all, why reinvent the wheel? This modularity also gives us choice: you can pick and choose from a variety of slightly different tools that perform similar tasks to extend Jekyll, depending on your preferences. For example, if you’d rather write your blog posts in Textile instead of Markdown, you can. For me, however, the default (Markdown) does the trick, and Gem only needs a small number of other dependencies, which are fetched automatically.

For a full list of available gems that extend Jekyll, see the list within the install instructions for Jekyll on GitHub.

Creating the basic file structure and some posts

Now with Jekyll installed let us set up the file system structure. First, create a new directory for you to work in. I put mine in ~/Sites/klepas. Move into this new directory and create the following subdirectories and files:

a plain text file named _config.yml
a directory named _layouts
a directory named _posts
a file for our home page: index.html

That done we can execute Jekyll by issuing the jekyll command at the command prompt. You will notice that Jekyll creates the directory ‘_site’, which now holds an index.html file. If we had our web site and configuration files set up at this point, our finished web site would now be built and ready in the _site directory.

Let us examine this file structure in closer detail:

`_config.yml`

As the filename suggests, this is where your Jekyll configuration lies. It’s typically only a few lines long and allows you to avoid having to specify optional flags every time you run Jekyll from the command line; just stick them into _config.yml and Jekyll will use them every time it is run. For more info on Jekyll configuration see the configuration page on the Jekyll wiki.

`_layouts/`

The _layouts directory holds the web site templates, known as layouts in the world of Jekyll. Layouts use the Liquid template language. When Jekyll is run, your posts are injected into the layouts using the Liquid {{ content }} tag.

Layouts are called upon at the beginning of each post in a string of variables called the YAML front matter that direct how Jekyll will process the file. This allows you to select a different template for each blog post or page as desired.

`_posts/`

As the name suggests, this is where you keep your posts. Posts are plain text files that are named with the format $YEAR-$MONTH-$DATE-$TITLE.$FORMAT. So, for example, I have a post from 25 October 2008 titled “Whose Garamond is it anyway?” which would sit in my posts directory as 2008-10-25-whose-garamond-is-it-any.markdown. It ends in .markdown, but if you use Textile your post filenames would end in .textile instead.

Creating layouts and posts

So, let us create a few layouts and some posts. First, the layouts.

We will create two templates for us to pick from: base.html, which is our base layout and post.html, which extends the base layout and is used for posts.

The base layout includes the HTML doctype, the head tag, and the container div tag that contains the Liquid {{ content }} tag:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"  
    xml:lang="en" lang="en">
  <head>
    <title>{{ page.title }}</title>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
    <meta http-equiv="content-language" content="en" />
    <link rel="stylesheet" href="/css/screen.css" type="text/css" media="screen" />
    <link rel="stylesheet" href="/css/print.css" type="text/css" media="print" />
  </head>
  <body>
    <div id="container">
      {{ content }}
    </div>
  </body>
</html>

As this is the base layout, everything except the contents of the container div will appear on all web pages of your Jekyll site. This becomes even more interesting when we add layouts that extend the base layout. Our post layout, post.html, does just that:

---
layout: base
---
    {% include header.html %}
    {% include nav.html %}
      <div class="entry-content">
        <h2>{{ page.title }}</h2>
        <span>Published: {{ page.date }}</span>
        {{ content }}
      </div>

In the opening few lines of the post layout file, we included a YAML front matter note that defines this layout as an extension of the base layout: layout: base. This means the contents of post.html will be pulled into the container div of the base layout thanks to the {{ content }} Liquid tag. This is also true for all other pages: index.html, about.html, archive.html, and any others as desired.

You may have spotted the two uses of the {% include %} directive at the start of the post template:

    {% include header.html %}
    {% include nav.html %}

Missing from the minimal file structure example outlined above is the _includes directory, which holds little content snippets that you can reuse in layouts and static pages. They could be the site navigation, the header, the footer, or even a very small piece of content like a call-to-action message that you want to include in more than one layout. Using the two Liquid tags above, I am telling Jekyll to fetch and include the contents of _includes/header.html and _includes/nav.html into my post layout upon site generation.

When creating individual post files you also include a YAML front matter note. You can specify whichever fields you like — a title or date, for example — and those values will be available in your layouts. If you specify a layout it will be used for the post. For example:

---
layout: posts_xmas-theme
title: Merry Christmas!
---

The above post will be displayed using a special Christmas theme layout called posts_xmas-theme, and has a title value that can be output in a layout as {{ page.title }}.

Permalinks: if you are worried about permalinks at this point, Jekyll has it under control. The documentation shows how to specify the appearance of your permalinks in the _comfig.yml file.

A short introduction to Liquid

The Liquid template language was developed by the folks over at Shopify, the e-commerce system. It was designed to allow designers and front-end developers to modify their shopping interfaces without affecting the security on the server they are built on.

Liquid is quite simple to learn: there are two types of markup within Liquid, output and tag. Output markup (which is output to text) is enclosed by double curly brackets (or braces), like so:

Hello {{ name }}
Hello {{ user.name }}

Tag markup (statements that are not output as text) is enclosed by matched pairs of braces and percent signs, like so:

{% if user.name == 'tobi' %}
  Welcome, Tobi!
{% elsif user.name == 'bob' %}
  Go away, Bob!
{% endif %}

Tag markup allows if ... else operations, for loops, variable assignment, and more. Output markup also allows you to filter the output through Liquid filters; for example, to change text to uppercase:

Hello {{ 'tobi' | upcase }}

To change a date to a different format, you can do the following to output a date like “November 24, 2009”:

Hello {{ now | date: "%B %d, %Y" }}

Liquid supports a broad range of filters, including date formatting, capitalisation, array element selection, markup manipulation (for example, strip_html which strips HTML from a string), replace functions, truncate functions, and simple mathematical operations like addition, subtraction, multiplication, and division. Jekyll extends these filters with a few more of its own.

For more information on Liquid output and tag markup, see the Liquid for Designers documentation page on the Liquid wiki on GitHub.

Creating pages

You may probably be wondering now how you create pages like the home page and archives page.

The index.html file you created earlier is essentially your home page. All other .html and .markdown (or .textile, and so on) files in the root directory will also be processed by Jekyll. For example, if you create a file called about.html in the root of the Jekyll file structure, it will be placed in the root of the generated site and could serve as your About page.

Pages like the index page can be entirely what you want them to be. You could, for example, pull in the latest three posts, with the latest featuring a large heading and the first 120 words styled in an eye-catching manner, with the other two posts appearing smaller and alongside each other, below the latest. The following is an example index.html file; it opens with a title and a template specified in YAML, and is populated using a range of Liquid extensions to pull in content from the posts directory or otherwise:

---
layout: base
title: The Title of Your Web Site
---
    {% include header.html %}
    {% include nav.html %}
    {% for post in site.posts limit:1 %}
      <div id="container">
        <div class="page-nav-top">
          {% if post.previous %}
            <span class="page-nav-item">
              <a rel="prev" href="{{ post.previous.url }}/" 
                  title="View {{ post.previous.title }}"
              >&larr; View previous article</a>
            </span>
          {% endif %}
          {% if post.next %}
            <span class="page-nav-item">
              <a rel="next" href="{{ post.next.url }}/" 
                  title="View {{ post.next.title }}"
              >View next article &rarr;</a>
            </span>
          {% endif %}
        </div> <!-- /.page-nav-top -->
        <div class="entry-content">
          <h2 class="clear">
            <a href="{{ post.url }}/" title="{{ post.title }}"> 
              {{ post.title }}
            </a>
          </h2>
         <span class="date" 
              title="{{ post.date | date_to_xmlschema }}">
            <span class="published">Published: </span>
            <span class="day">{{ post.date | date: '%d' }}</span>
            <span class="month">
              <abbr>{{ post.date | date: '%b' }}</abbr>
            </span>
            <span class="year">{{ post.date | date: '%Y' }}</span>
          </span>
          {{ post.content }}
        </div> <!-- /.entry-content -->
      </div> <!-- /#container -->
    {% endfor %}
    {% include footer.html %}

As you can see again there are a number of includes for the site header, navigation, and at the end a footer. The main part of the template is a loop:

{{ for post in site.posts limit:1 }}

This tells Jekyll to fetch the posts in the _posts directory, limiting the results to one: the latest post.

Having selected only a single post, we can create chronological “Next” and “Previous” navigation links using the values post.previous and post.next. These values will be true if a previous or next post — chronologically speaking — is available. If they are available we extract the URI and title to output a link.

No documentation: the post.previous and post.next tags are currently undocumented, but work perfectly.

The latest posts title is output with post.title and the link is created using post.url. Every post has a date, so we create a little microformat goodness using post.date. Finally, and quite simply, we output the post’s body with post.content.

Similarly, an archive page is also easy to build:

---
title: Archives
layout: base
---
    {% include header.html %}
    {% include nav.html %}
    <div id="container" class="archives">
      <div class="index">
        <h2><em>Notebook archives</em>…</h2>
        <ul>
          {% for post in site.posts %}
            <li>
              <a href="{{ post.url }}/#notebook" title="{{ post.title }}">
                <span class="date">
                  <span class="day">{ post.date | date: '%d' }}</span> 
                  <span class="month"><abbr>{{ post.date | date: '%b' }}</abbr></span>
                  <span class="year">{{ post.date | date: '%Y' }}</span>
                </span>
                <span class="title">{{ post.title }}</span>
              </a>
            </li>
          {% endfor %}
        </ul>
      </div> <!-- /.index -->
    </div> <!-- /#container.archives -->
   {% include footer.html %}

This time we use the same for loop: {% for posts in site.posts %}, to grab all the posts. Within the loop we create list items for each post and output the posts’ titles and dates. That is all there is to it.

Other directories and files

Apart from the specific directories and files mentioned above, all other directories and files are handled by Jekyll as expected and will be included in the generated site build in _sites/ when Jekyll is run. Thus, a css/ and js/ directory and its contents, a favicon, and whatever else will all be added to the site build.

Testing your site locally

Jekyll comes with a simple web server that allows you to point your web browser over to http://localhost:4000/ and view your site. To enable the web server append --server when executing Jekyll:

$ jekyll --server

Even better, if you are actively updating and making changes, a useful flag to append to the jekyll command is --auto. It will update the contents of the _site directory automatically for you when a file within the Jekyll structure changes:

$ jekyll --server --auto

You can also add auto: true to the configuration file so that you can avoid having to type it in every time.

Version control: if you want to track your Jekyll files in a version control system, it is recommended to make an exception for the _site directory. This is because the files in the _site directory are bound to change a lot, particularly during the development phase.

Deploying your web site

Deploying your generated static site is just a matter of copying the output in _site to your web server. You could use FTP to upload your files, but there are a number of automated methods that make life easier, particularly when you just want to upload the new changes since the last upload.

My preferred current method is to use rsync, a little UNIX utility written by Canberra locals Andrew Tridgell and Paul Mackerras. rsync synchronises data from one location to another, and in doing so only sends changes rather than full files where possible. You could either run this each time you update your site, or via a task script:

$ jekyll && rsync -avz --delete _site/ username@server.com:path/

There are a range of other, more complex automated methods, but they are beyond the scope of this article.

Comments… or lack thereof

As a static site generator without any dynamic extensions Jekyll has no support for adding comments dynamically. There are methods of adding commenting functionality via a third party or similar commenting service, such as DISQUS Comments.

I have personally decided to avoid comments; besides avoiding having to deal with them at all (code-wise, styling-wise, spam-wise — yay!), the best feedback I have ever received were face-to-face or directly via email. I also echo some of the sentiments raised by Alex Payne in his article, Why I Don’t Allow Comments, and More on Everything Buckets in regards to fostering a higher quality discussion.

In closing…

Despite blog CMSs as powerful as WordPress, Movable Type, and so on, I hope you can now see why I found it worth reverting to a simplistic and rudimentary system like Jekyll: use the right tool for the job. Jekyll is a breeze to pick up; its learning curve is certainly less steep than say theme design or hacking for WordPress, in my experience.

Migrating from your existing blog: you can find instructions for migrating from an existing blog — Wordpress, Moveable Type, and others — in the Jekyll documentation on GitHub.

With GitHub Pages using Jekyll, it is common to see many Jekyll users sharing their Jekyll blog sources openly via GitHub. There is a listing of Jekyll-generated sites in the documentation, along with links to their respective GitHub repositories when available. These are great to browse through for some insight on how other Jekyll users have built their web sites.

Learning curves aside, if you are after a simplistic blog tool construction-wise that does not require multiple users or a fully featured web publishing interface, then Jekyll could easily do the trick. And be assured, the sophistication of the final output for Jekyll can generate beautiful multi-layout blogs akin to WordPress.

Ultimately, I changed to Jekyll because WordPress seemed like an overkill and I was up for learning something new. I hope this article serves to help you if you are experiencing a similar predicament.

This article was originally published on SitePoint.com — Jekyll: Sites Made Simple. I wanted to update and re-publish it here for archiving and such that others could potentially stumble upon it.

Web Directions South typography talk

2010-10-15T00:00:00+00:00

I just got back from a better part of a week up in Sydney for the annual Web Directions South. I was invited to present on setting standards-friendly web type. The talk focused on the options currently available for setting type on the web with a strong focus on webfonts (part one) and a supplementary section on then styling the selected type (lots of micro-typography; part two).

Slide 6.

The talk

There is a lot to be written (or said) about typography, and when we work with the web as a medium a lot of extra technical stuff also gets tacked on, so I had plenty of material to cover (I ended up with 112 slides) in a slot of 40-odd minutes including time for questions. However: 1. I wanted to ensure that the talk included the bulk of the stuff you need to get going with webfonts (prime aim of the talk); 2. that’s not all though — now that you’ve got the type you want, styling that type comes next (the fun stuff); 3. I realise the slides are rather text heavy — I prefer reading along with presentations rather than just listening (half the stuff seems to just enter one ear and exit straight out the other for me) so I wanted to offer that option to those who like to read; 4. and finally, the nice upside of which is that anyone can grab the slides of the presentation later and use them as a downloadable resource.

You can grab a high-quality PDF copy of the presentation slides (16.1 MB). The talk is also available on SlideShare. Web Directions kindly recorded the audio of the talk and has made it available as a MP3. Alternatively you can also download an OGG Vorbis copy of the audio recording.

Part 1: Getting a typeface on the web

Options for getting fonts onto the web: * installed fonts (mostly web-safe); * Flash (e.g. sIFR) and other JS replacement techniques; * Cufón et al.; * webfonts: EOT/EOT Lite via @font-face; * webfonts: OT/TTF via @font-face; * webfonts: WOFF via @font-face; * webfonts: SVG via @font-face; * and hosting and licensing services.

Part 2: Setting that type all pretty

Webfonts aren’t the holy grail of web typography problems; remember:

Typography is not picking a ‘cool’ font.

…and further, also note that most fonts available from type foundries are not optimised for screen usage; they’re chiefly designed for print. Having said all this, part two focuses on styling the type you have selected. Main topics covered: * limiting your palette of type families; * using a combination of families, styles, and weights; * using tracking and small-caps for acronyms and tabular data; * sizing type in relative terms — in ems or percentages — and sticking it to a scale; * being careful when mixing different typefaces; * using the proper glyphs, e.g. proper punctuation; * playing with alternate styles for ampersands; * marking paragraphs; * setting and sizing horizontal flow via measures (line lengths); * setting and sizing vertical flow via leading (line heights); * playing with hanging punctuation; * treating text as part of the UI; * and setting it all in and/or around a good and organised grid.

I enjoyed presenting and through it revisiting web typography which I have not much had much time to devote to in these past months. If you have any feedback, thoughts, or otherwise with regards to the presentation or the slides drop me a line.

Oh, I also wanted to thank David Gleason for taking a snap of me on-stage. I really like Instagram’s styling. Cute.

I feel both disgruntled and happy at myself for not having written an entry in almost a year. On the one hand there is a resentful ‘how slack have I been? Why have I not updated!?’ sentiment on my mind. Meanwhile, another part of me feels reasonably content that my time has been consumed aptly; pursuing uni studies, other personal interests, and the obligatory pinch of turbulence (family and otherwise) here and there that made this an interesting year of personal development. I hope to write more frequently in the future.

Interviewed by Gary Barber

2009-10-13T00:00:00+00:00

As a prelude to the upcoming November Australian Edge of the Web conference I’ve kindly been interviewed by Gary Barber. I’ve cross-published the interview below.

Raena Jackson-Armitage from SitePoint also interviewed me on the same note. The interview touches on similar web typography and web fonts topics but focuses more on uptake, usage, licensing, and some recent inspirational sites I’ve stumbled across.

Interview with Gary

Gary It’s nothing new to most web designers that typography on the web just sucks. With the cripplingly limited number of cross platform typefaces available and the different ways font render on the browsers, it’s enough to just make a designer give up in frustration. Discounting the use of the CSS property “font-face” that only leaves the hacks from Cufón and sIFR to allow some alternative relief. Would you recommend these as solutions to overcome this problem or do you have some secret designer “Foo” hidden up your sleeve?

Pascal

With no intention of being controversial right off the bat, I guess I would have to say I reject the premise of the question. I don’t really accept that web typography sucks; sure, it could certainly be a lot better, and I have good hopes for the future, however a lot can be done with what is available to us currently, even as a web standards-devoted designer. We have a number CSS Fonts options available to us, e.g. font-weight, font-style, font-variant, which combined with line-height, sizing, widths, and the actual font declared offer a lot of variety. Remember Jeff Croft’s words: “[t]ypography is not picking a ‘cool’ font”, or any font for that matter.

Gary Personally I’m not a fan of the pre-rolled CSS grids that are now all the rage in some circles. Sure I know that they help people layout a web page, and they assist with getting the rhythm on a page right. But still I suspect that they maybe allowing some designers to be lazy and not think outside the square of the CSS grid. What’s your view on the use of CSS grids especially from a typography slant?

Pascal

A grid exists to help provide structure and rhythm, and so directly relates to typography. Figuring out a good grid and then turning it into versatile, good CSS is effort, and in that regard I like the pre-rolled grid — they are great for those of us who want a grid but have time constraints, or just don’t want to worry too much about them. I personally don’t use them — I use my own grids. This comes down to my enjoyment in actual coming up with one and building it (yes, I probably ought to be clinical tested for some sort of mental ailment) and finding that the pre-rolled ones don’t do things the way I want them to (usually they are over-kills for the projects I’ve worked on).

Gary The debate on property font-face and the resultant licensing issues over EOT and OTF has divided the typography community, especially the Type Foundries. Recent upgrades of FireFox has allow for the use of @font-face, and with a few CSS tweak’s its has now effectively remove the browser incompatibility. Personally I wasn’t a fan of the use of @font-face but I have learned to love it. As a typeface guru how do you see this state of play?

Pascal

Good generally. I see it as a step forward that we’ll have access to a larger range of fonts, but I am worried about their usage — again this reflects off Jeff’s earlier quote I noted. Many of the typefaces currently available for licensing from foundries are designed for print use, and differ from fonts that are designed and optimised for screen usage. There are a lot of fonts out there, and in relation only a small number of really good ones, and of that an even smaller number that have been optimised for screen use. Screen-optimised fonts need to cater for the lower resolutions of screens (apposed to printed material) and as such may feature thicker strokes and serifs (e.g. see Georgia) and good hinting tables to ensure readability at small sizes.

I am aware that Typotheque are investing in creating screen-optimised versions of some of their typefaces. I believe this may be less of a problem in fonts available for web font licensing from foundries as they will be aware of this issue and more of freely-licensed or unlicensed, lower-quality fonts that are used directly via @font-face.

Gary Are the days of Type Foundries numbered for web industry (I’m excluding Print, here, ok)? Do we really have to put up with the same old tired, font centralised ordering-distribution system? What do you think of typographers that are shaking of shackles of the Type Foundries and marketing their works directly with designers via the likes of Typekit and League of Moveable Type?

Pascal

I wrote on this topic in November last year and echoed my belief in the rise of hosting and licensing service. I think non-foundry controlled services like Typekit and Fontdeck who sub-license web fonts for foundries may distribute some of the centralised control that foundries historically possess. That said, I think the best way to give the foundries a run for their money and up the quality of type design all-round is for more high quality open source, freely-licensed typefaces to become available which may be freely distributed and hosted. Some in the type community see this venture as futile or even misguided but I believe it’s the best way to ‘democratise’ type and typography and educate folks about it — ‘Hey, have you heard about typography? Check out this awesome example website of good typography that features a really well-done font’ is a saying amongst non-designers I can’t imagine if ‘well-done font’ is preceded by a dollar sign and figures ranging in three digits before the decimal point (if not more).

Gary Moving on further with groups like The League of Moveable Type popping up all over the place, what’s your take on the matter? Are they providing for the service that designers need? Do you see their product as a general benefit to fellow designers or are they simply ripping the bread and butter from the mouths of the typographers?

Pascal

Yes, absolutely. Time to get a bit progressive and perhaps transgressive. Continuing on from the topics and organisations raised in the last question, I hold organisations, communities, and single type designers who provide considerable and usable parts of their work at no cost (gratis) and under licensing terms (libre) that make distribution and improvements viable in high regard. I think a simple comparison may be drawn here to the personal computer. The personal computer is largely responsible for many technological and general societal advancements due arguably to its increasing affordability. Likewise, the more affordable, or rather the more accessible typefaces and good typography becomes the better the state of typography will be — the more accessible something is the more attainable are the positives (and negatives) that that something provides. People, either individually, in commercial corporations or as self-structured communities who provide fonts, the means of making them, and educational material on the first two and their use for free will better the state of type, type design, and typography.

There is a common argument by critics who suggest that there is a lack of people to do this task or to do it well. I disagree; where there is a will there is a way — look at the many successful free and open source software (FOSS) projects that have bettered the world in one way or another. I think to suggest that type designers are in some fundamental economic way different to programmers, web developers or other smart people who render their time and knowledge in some form to create or better free software to be false. For proof look at organisations like the League of Movable Type and the type designers behind it or working individually: Linux Libertine by Philipp H. Poll, Gentium by Victor Gaultney, and a lot more. It is true that the number of skilled type designers who release freely-licensed works is limited; there are less FOSS type designers than FOSS programmers or web developers, yet compared to software development or web development, type design is a relative niche industry.

Continuing and concluding with economics, of course free typefaces, freely-licensed written material, and type design software will compete in quality and price with commercially available equivalents. The better the quality and variety of these free things, the cheaper and/or higher in quality the equivalent or related commercial products will be need to be. Who benefits? ‘Consumers’ — we do.

Gary Thanks Pascal, see you in few weeks.

Thanks Gary!

The interview is licensed under show otherwise is licensed under the Creative Commons Attribution-Noncommercial-Share Alike 2.5 Australia license — take, share and be merry.

Simon Pascal Klein

The Aussie security–trade cock-off

Top 10 dos and don’ts of Web Typography

My list

1. Apply no more than three typefaces per design (or page)

2. Set headlines large and invitingly, at the top of the page

3. Size body copy 14px+

4. Ensure a good text to background contrast

5. Apply stress and emphasis discreetly

6. Do not set continuous text in full capitals

7. Give the type space to breathe; set ample measures and leading

8. Be wary of fonts not designed for screen use

9. Ensure webfont assets are subsetted and cached

10. Don’t use Comic Sans

And you?

Achieving good legibility and readability on the Web

Definition and purpose

Legibility

Readability

Highlight relationships and provide navigation

Earned or unearned qualities

Inducing a state of interest

Achieving good legibility & readability

Typeface

Sizing

The 62.5% trick

Measure

Leading

Alignment

The culmination (contrast)

Closing

Getting type to the Web

Options for bringing fonts to the Web

Installed fonts

Flash replacement techniques

Cufón et al.

webfonts: EOT/EOT Lite

webfonts: OT/TT

webfonts: SVG

webfonts: WOFF

Hosting & licensing services

Finding freely-licensed fonts

Using @font-face

Creating @font-face webfont files

‘Bullet-proof’ @font-face declarations

Problem: ‘double-setting’ styles and variants

Considerations

More ≠ better

For screen or print?

Sub-setting

Compression

Configuring mod_deflate

Configuring mod_gzip

Caching

And that’s it!

Anti-procrastination wallpaper and some musings

The wallpaper

Two realisations on procrastination

Dealing with hard tasks

Tasks you just don’t want to do

Why I have not bought an iPad

Exploring the use cases

Audio-visual

Browsing

Taking pictures

Reading

Other considerations

Good use cases?

The smartphone & laptop market

Closing

How I browse the Web

My beginning on the Web

My learned practices

A better browser

A password manager

Dealing with pop-ups & listed malicious content

Kicking ads

JavaScript execution control

Forcing secure connections

Privacy and tracking

Using `@font-face`

Creating `@font-face` webfont files

‘Bullet-proof’ `@font-face` declarations

`_config.yml`

`_layouts/`

`_posts/`