Font Selection

All type shares characteristics. We’ll look at some of them before we dive into selecting font stacks and other type related element. As we move along we’ll discover that these elements are all interrelated and that changing one of these elements will force changes in others too.

Visual representation of type related terms
Visual representation of type related terms


When you look at your text what is the size of the lowercase glyphs/letters to uppercase? In different fonts the height of lowercase glyphs (measured by the x-height) can be different, some of them being barely half the uppercase height and in others being as tall as two-thirds of the uppercase height.

When looking at type, particularly when you’re testing your content in your chosen typeface and size, make sure that the size is not too small to read. When the height of the lowercase gets too small for the size you chose it gets too hard to read.

Glyph Apertures

Aperture refers to the spacing between open points in letters like ‘c’, ‘e’ or ‘a’. If these apertures are too close the letter can be confused with a lowercase ‘o’ and make the reader’s experience harder than it needs to be

Even Spacing

Make sure that the space between the glyphs and the width of the glyphs in the font you choose are constant and not too far or to close to each other. This constant spacing will make your text easier to read or scan online

Clear Terminals

Terminals are the flourishes at the end of the letters a, c, f, j, r, and y. They can be classified according to the shape: ball (circular), beak (spur), and teardrop (globular).

In long-form text, letters with clear terminals (distinguishable shapes of ball, beak, or teardrop) are easier to spot; therefore, they are more readable than letters with lacking terminals.

Distinguishable Ascenders & Descenders

Ascenders (the lines above the main body of a glyph) and descender (the line below) help make characters easier to read. When you’re choosing typefaces, contrast sans-serif versus serif type to see the difference in how the ascenders and descenders look. For a bad example look at Helvetica.

Styles & Weights

When we see bold and italics on the web, we usually see the browser’s interpretation of bold and italics not the actual italic and bold versions of the chosen typeface.

To make sure that this doesn’t happen to you, make sure that the typefaces you work with have at least 4 versions:

  • Regular
  • Bold
  • Italic
  • Bold Italic

If one of the style fonts are not available then you’re at the browsers’ mercy regarding how bold and italics will render for your page.


In this context, contrast refers to the differences between thick and thin strokes of the font. When working with body copy the thin strokes may disappear or the think strokes may overwhelm the rest of the text.

To make sure none of these situations happen pick a font with low or no contrast.


Until now we’ve looked at the technical aspects of type where we will use the typeface is also important. Context has more to do with how the type feels. If you’re developing responsive sites, does the type feel too tight or constrained in larger screens? Does it feel too loose in smaller displays? The goal is to find typeface that works consistently across your target devices.

Font stacks

Unless you’re using one of the universal fonts, those available everywhere, you will most likely have to plan for what happens if your browser cannot load the font because your internet connection just died or you got caught using a font that you were not licensed to use. That’s where you use the font stack.

html {
  font-family: 'Museo Sans', Verdana, sans-serif;

The browser will use Museo Sans, if is available in a format that the browser can read, if it isn’t then the browser will use Verdana and… in the unlikely event that verdana is not available the browser will use the system’s default sans serif font.

Why is this important, you may be asking. Because not all fonts are the same. Even fonts that look very similar may be different enough to cause problems with your layout. Let’s look at the same Lorem Ipsum text in two different fonts.

The first example will use Stone Humanist, the font I chose for the body text in this document.

See the Pen Example using Stone Humanist by Carlos Araya (@caraya) on CodePen.

The second example uses Verdana, a font created for and released by Microsoft in 1996.

See the Pen Font Example Using Verdana by Carlos Araya (@caraya) on CodePen.

Notice, in particular, how Verdana’s characters are wider and therefore make the line have less content when compared with Stone Humanist. As a further experiment change the front in Example 2-2 from Verdana to Arial and see the difference.

“Web Safe” Fonts

Ever since browsers started using fonts they’ve been able to use fonts available on the user’s system. These are the “web safe” fonts.

CSS Font Stack presents a list of some of the most common desktop fonts that are installed in Macintosh and Windows operating systems. As you can see there are a few fonts that are really safe to use across platforms.

This is yet another consideration when building our font stack. If we build backups other than generic fonts we need to be careful to pick fonts that are wide used or pick 2 or more options to cover both Windows and Macintosh cases.

Generic font families

Most of the time we have a certain font selected for our project and most of the time they will work ok. But what happens when they don’t?

As we saw in the earlier examples the typeface you choose will affect number of words you can fit in a line of text and the way the font writes on screen may look different with the same line height

CSS defines a number of generic font families for use with your content. These families are (with definitions taken from the CSS 2.1 specification):

Glyphs of serif fonts, as the term is used in CSS, tend to have finishing strokes, flared or tapering ends, or have actual serifed (including slab serifs). Serif fonts are typically proportionately-spaced. They often display a greater variation between thick and thin strokes than fonts from the ‘sans-serif’ generic font family. CSS uses the term ‘serif’ to apply to a font for any script, although other names may be more familiar for particular scripts, such as Mincho (Japanese), Sung or Song (Chinese), Totum or Kodig (Korean). Any font that is so described may be used to represent the generic ‘serif’ family.
Glyphs in sans-serif fonts, as the term is used in CSS, tend to have stroke endings that are plain — with little or no flaring, cross stroke, or other ornamentation. Sans-serif fonts are typically proportionately-spaced. They often have little variation between thick and thin strokes, compared to fonts from the ‘serif’ family. CSS uses the term ‘sans-serif’ to apply to a font for any script, although other names may be more familiar for particular scripts, such as Gothic (Japanese), Kai (Chinese), or Pathang (Korean). Any font that is so described may be used to represent the generic ‘sans-serif’ family.
Glyphs in cursive fonts, as the term is used in CSS, generally have either joining strokes or other cursive characteristics beyond those of italic typefaces. The glyphs are partially or completely connected, and the result looks more like handwritten pen or brush writing than printed letterwork. Fonts for some scripts, such as Arabic, are almost always cursive. CSS uses the term ‘cursive’ to apply to a font for any script, although other names such as Chancery, Brush, Swing and Script are also used in font names.
Fantasy fonts, as used in CSS, are primarily decorative while still containing representations of characters (as opposed to Pi or Picture fonts, which do not represent characters).
The sole criterion of a monospace font is that all glyphs have the same fixed width. (This can make some scripts, such as Arabic, look most peculiar.) The effect is similar to a manual typewriter, and is often used to set samples of computer code.

Using a generic family as the last item in your font stack is essential. The system is guaranteed to be available and you can style your content with this in mind. It also makes your CSS less susceptible to slow connections or network failures.

Additional Considerations

There are a couple more elements to consider when selecting a font. They may not seem as important but when put together with everything else we’ll discuss in this page, it’s a lot more important than we give it credit for.

Font size

Even when working with Desktop Operating Systems alone a font may look very different. It doesn’t necessarily have anything to do with the design and all with how the operating system renders fonts and it may not even happen but this is something to consider when testing.

Smaller sizes may cause font details to disappear as the font grows smaller. This may affect the typeface you use for your body text, particularly in smaller devices.

Fonts have become more interesting when particularly since Apple released ‘Retina’ iPhones and iPads and Android phones have been released with even higher pixel density. While the higher density allows you to use more typefaces, your design must still consider browsers with lower pixel density in your design.

This page displayed during development in Chrome for OSX

Content displayed in Microsoft Edge running in a Windows 10 virtual machine

Line height

In CSS line-height control the vertical space between lines. It can help readability and make it easier for people with disabilities to engage with your content.

p {
  font: 1em/1.5 arial, helvetica, sans-serif;

Which is equivalent to this, much more verbose, syntax:

p {
  font-family: arial, helvetica, sans-serif;
  font-size: 1em;
  line-height: 1.5;

I personally prefer the second syntax. It’s explicit in telling you what each attribute controls and it saves you from having to remember what does each part of the expression means. That said you’re more than welcome to use either syntax.

So why do we care about line height. In the example below change the line height attribute, play with values from 1 to 2 or even 3 and see the difference. Which one is more comfortable to read?

See the Pen Line Height Example by Carlos Araya (@caraya) on CodePen.

Line width


Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple-column work, a better average is 40 to 50 characters. Robert Bringhurst’s The Elements of Typographic Style, (p.26)

Until I started working with web type I had never considered line length as an element when building content. But it makes sense, the longer a line of text is the more we need to be mindful when working with it. In the example below, the text at the same width looks significantly different when we adjust the line height.

See the Pen Line Length Example by Carlos Araya (@caraya) on CodePen.

So what should the stack look like?

So, after all these conversations about different types of typefaces, fonts, availability and when to use and not to use them, what should a good font stack look like?

As with many thing in the web it depends. If you were given fonts as part of your design brief then you should follup up with the designer regarding fall back fonts.

If this is your design then I’d suggest sites like Fonts in use or Typewolf to see how other people are using fonts. Another way is to identify a font you like (like I did with the body font for this page), research whether it’s available as a web font and how much would it cost to license.

Once you know what font you want to use, there are services like Typecast to see what the font will look like in an actuall web page… you can even add chunks of your own content to get a more acurate picture of what the typeface will look like with your content.

My default font stack for this project looks like this:

html {
  font-family: 'Stone-Humanist', arial, sans-serif;

I use a different stack for headings and this will be discussed when we talk about headings in more detail.


Type Terminology and Definitions

Before we dive into Type selection we’ll do a few things: clear terminology and setup some common definitions to work from. The first one is the difference between typeface and font and then we’ll dive into a short (and incomplete) glossary of typographical terms

Font versus Typeface

I’ve been guilty of this: use font and type face interchangeably. They are most definitely not the same thing and should not be used as if they are.

Typeface refers to the design of the font.

Fonts is the media that contains typefaces and allows you to use them in your projects.

The best analogy I’ve heard about is that the relationship between typeface and font is analogous to the relationship between music and mp3. One is the content and the other is the media that content is delivered in.

For more information, check out font or typeface and Styles, Weights, Widths — It’s All in the (Type) Family both at

Font Glossary

Visual representation of type related terms
Visual representation of type related terms

Definitions taken from Fontshop’s Typography Glossary and Typography Deconstructed’s Type Glossary

The capitals in a typeface. The name refers to the days of metal type, as the capitals were kept in the upper part of the type case.
The capital letters of the alphabet are uppercase glyphs. Uppercase letters are normally used at the beginning of sentences and as the first letter of proper names.
The small letters in a typeface. The name refers to the days of metal type, as the small letters were kept in the lower part of the type case.
The little letters or non-capital letters of the alphabet are lowercase glyphs. They make up the bulk of written text, with uppercase or capital letters used primarily only to start sentences or proper names.
An artistic interpretation, or design, of a collection of alphanumeric symbols. A typeface may include letters, numerals, punctuation, various symbols, and more — often for multiple languages. A typeface is usually grouped together in a family containing individual fonts for italic, bold, condensed, and other variations of the primary design. Even though its original meaning is one single style of a type design, the term is now also commonly used to describe a type family (usually only with the basic styles regular, italic, bold, bold italic).
(also, fount) A collection of letters, numbers, punctuation, and other symbols used to set text (or related) matter. Although font and typeface are often used interchangeably, font refers to the physical embodiment (whether it’s a case of metal pieces or a computer file) while typeface refers to the design (the way it looks). A font is what you use, and a typeface is what you see.
Any part in a lowercase letter that extends above the x-height, found for example in ‘b’, ‘d’, ‘f’, ‘h’, ‘k’, etc. Some types of ascenders have specific names.
The ascenders of some letters may touch or almost touch letters in the line above causing awkward or distracting patterns. This is most likely to happen or be obvious when a line of text with tall ascenders is below a line of text with long descender. To resolve the problem of touching ascenders and descender you can: Increase the leading (line spacing) between lines of type; Choose a different typeface; For headlines and subheads, some careful editing/re-wording can eliminate the problem; Changing the alignment of the text may also help
An imaginary line drawn from top to bottom of a glyph bisecting the upper and lower strokes is the axis. The slant of the axis (or lack thereof) often helps determine the type classification.
An imaginary line drawn from top to bottom of a glyph bisecting the upper and lower strokes is the axis. For typefaces that exhibit changes in the thickness of curved strokes, the inclination of the axis of the lowercase o is used to measure the angle of stress. A completely vertical axis indicates a design with an angle of 0 or vertical stress. When the axis leans to the left or right the design has angled (positive or negative) stress. Early styles of typefaces generally shared similar axis or stress angles.
The axis or design axis is also an adjustable attribute of some fonts, such as Multiple Master fonts. Adjusting the design axis results in variations in the weight, width, size, and other features of the typeface.
The bracket is a curved or wedge-like connection between the stem and serif of some fonts. Not all serifs are bracketed serifs.
The imaginary line upon which the letters in a font appear to rest.
Cap Height
The height from the baseline to the top of the uppercase letters (not including diacritics).
A triangular, serif-like protrusion at the end of a stroke in certain serif type designs.
The main curved stroke in the letter ‘S’ and ‘s’.
The enclosed or partially enclosed circular or curved negative space (white space) of some letters such as d, o, and s.
Any part in a lowercase letter that extends below the baseline, found for example in g, j, p, q, y, etc. Some types of descenders have specific names.
For contrast, see Ascender
A diacritic is a ancilliary mark or sign added to a letter. Accents are one type of diacritics. In the Latin alphabet their function is to change the sound value of the letters to which they are added; in other alphabetical systems like Arabic or Hebrew they may indicate sounds (vowels and tones) which are not conveyed by the basic alphabet.
The curved part projecting downward from a stem in the lowercase ‘h’, ‘m’, ‘n’.
Small Caps (SC)
Small caps are capital letters that are approximately as high as the x-height of the lowercase letters. When properly designed small caps are absent in the selected font, many applications can create small caps by scaling down the capitals. However this makes these fake small caps too light and narrow, and they don’t harmonize properly with the lowercase. Originally small caps were only available for the roman text weight(s), but nowadays many type families also have them for the italic styles and the bolder weights.
When small caps are built-in as OpenType features, certain (older) operating systems and applications will not be able to access them.
Spacing refers to the distribution of horizontal space on both sides of each character in a font to achieve a balanced and even texture. Spacing problems in difficult letter combinations (exceptions) are solved with kerning. Well-spaced fonts need comparatively less kerning pairs.
Kerning refers to the horizontal space between individual pairs of letters (a kerning pair), and is used to correct spacing problems in specific letter combinations like “VA”. Well-spaced fonts need comparatively less kerning pairs. Fonts that are properly kerned appear evenly spaced without large open gaps of white space between any two characters.
Its original meaning is increasing the vertical space between lines of metal type by literally inserting lead strips. In the digital age it now means the vertical space between lines of text, from baseline to baseline.
In typography, a serif is the little extra stroke found at the end of main vertical and horizontal strokes of some letterforms.
Sans Serif
Typeface that without extensions at the letter’s termination points. Sans serif type lends a clean and sharp appearance to the text, and is suitable for headlines or highlighted matter. Such type, however, is known to retard readability of large bodies of text, specially when less than 10 point in size.
Literally ‘without serif’.
The descending, often decorative stroke on the letter ‘Q’.
The height of the lowercase letters, disregarding ascenders or descenders, typically exemplified by the letter x. The relationship of the x-height to the body defines the perceived type size. A typeface with a large x-height looks much bigger than a typeface with a small x-height at the same size.
A company that designs and/or distributes typefaces; a type manufacturer. The name originated in the days of metal type when type was made from molten lead.

There are many more terms to define but I believe these are enough to get us started. Check the references listed at the beginning of the glossary for additional terms.


Why Typography

This is the first of a series of articles on Typography and the potential of text on the web

Over the past few months I’ve rekindled my interest in typography; how it works in print and how it works online. I’m also working through two typography books that are very relevant to both typographic work and overall front end design and development. Responsive Typography by Jason Pamental, On web typography by Jason Santa Maria and Professional Web Typography by Donny Truong.

But it wasn’t until fluent that I got a better idea of why typography is important.I got the chance to talk with both Eric Meyer, one of my early web design influences, and Jason Pamental, the author of Responsive Typography and a very good presenter.

What I got out of multiple presentations about CSS, typography and new technologies coming and going away (sadly) is that the basics are still important. With that in mind I’ll look at typography through a series of exercises.

The first thing to learn is that all typefaces are different. What works for the typefaces I chose may or may not work for the typefaces you choose for your projects. Where possible I’ll show the typefaces used in this page against other typefaces (most likely from the ‘web safe’ font set.)

Why worry about typography on the web?

Universal Typography — Tim Brown

I love the web and I’ve been working on digital content for almost 20 years. While I agree with the universality and accessibility requirements for the web (it should be accessible by anyone anywhere, regardless of disability or network connection) the content doesn’t have to be boring or plain

Whether we are reading a paper book or a web page or a iBook or Kindle ebook, typography still matters and it’s still an important part of the design process.

For the longest time I’ve heard that the web is not print and that we shouldn’t look at books as sources for web design inspiration. This may be true: the web is not print. But we’re getting to the point where CSS on its own or a combination of CSS and Javascript will gives a large part of what we see in print in a way that won’t look terrible in older browsers, when the user access it with assistive technology, or when CSS and Javascript are disabled.

I started taking a serious look at typography about 3 years ago. I’m not an expect and I’m most definitely not a professional but I’m learning and the more I learn the more I think we can use the full range of web technologies to enhance the text and the reading experience for our users.

I’m also including several things such as CSS Transitions and Animations that, while not directly related to typography, still affect the way text appears on screen.


Responsive SVG graphics

One of the most intriguing things I’ve learned about SVG over the last few months is that we can run CSS, including media queries, inside the SVG file itself so the queries will modify the internal content of the files will change based on the queries inside the svg.

Getting started

[codepen_embed height=”564″ theme_id=”2039″ slug_hash=”MwrgJp” default_tab=”html” user=”caraya”]See the Pen SVG basic example by Carlos Araya (@caraya) on CodePen.[/codepen_embed]

The CSS for the SVG graphic is embedded in the SVG file itself. We copied the SVG file’s XML content directly in the pen, but there’s no reason why the content cannot be saved in a text file with a .svg extension.

Because SVG is an XML vocabulary we need to take some protective measures, particularly with our CSS. You will see < ![CDATA[]]> element surrounding the CSS inside our tag. This is an XML artifact that renders all its content as character data instead of markup. We do this to prevent any possibility of illegal XML characters inside our CSS from messing up the content.

Simple changes

[codepen_embed height=”482″ theme_id=”2039″ slug_hash=”qdpWoJ” default_tab=”result” user=”caraya”]See the Pen SVG with Media Queries by Carlos Araya (@caraya) on CodePen.[/codepen_embed]

For our example, we’ll add ID attributes to all elements. Since we are working in an individual SVG file we don’t need to worry about weight or specificity, we can just do it.

After we add color to our content we create two media queries.

  1. The first one will trigger when the width is smaller than 600px and it will hide the circle by setting its display property to none.
  2. The second one will trigger when the screen becomes smaller than 320px and it will hide the rectangle by setting its display property to none, leaving only the start visible in our SVG image.
@media (max-width: 600px) { /* 1 */
  #circle1 {
    display: none;

@media (max-width: 320px { /* 2 */
  #rectangle1: {
    display: none;

We can get more sophisticated by performing multiple actions within each media query. This allows to play with with both animations, different media query types that I wouldn’t normally use and animations where they are appropriate.

<div class='container'>
  <?xml version="1.0" encoding="iso-8859-1" ?>
  <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "">
  <svg version="1.1" id="Layer_1" xmlns="" xmlns:xlink="" x="0px" y="0px" viewBox="0 0 300 300" style="enable-background:new 0 0 300 300;" xml:space="preserve">

              #rectangle1 {
                fill: #f00;

              #circle1 {
                fill: #00f;

              #star1 {
                fill: #0f0;
                transform:  rotate(0deg);

              /* Media Queries */
              @media (max-width: 1000px) { /* 1 */
                #circle1 {
                  display: none;

              @media (max-width: 800px) { /* 2 */
                #circle1 {
                  display: block;
                  fill: #f0f;

                #rectangle1: {
                  display: none;

                #star1 {
                    display: #663399; /* rebeccapurple */
                    animation: animationFrames ease-out 2s;
                    animation-iteration-count: 2;
                    transform-origin: 0 0 ;

                  @keyframes animationFrames{
                    0% {
                      transform:  rotate(0deg);
                    99% {
                      transform:  rotate(180deg);
                    100% {
                      transform: roatete(0deg);

    <rect x="61.768" y="61.768" transform="matrix(0.7071 0.7071 -0.7071 0.7071 150 -62.1321)" width="176.464" height="176.464" id='rectangle1' />

    <circle cx="150" cy="148" r="96" id='circle1' />

    <polygon points="150, 16.914 176.961, 99.892 264.208, 99.892 193.624, 151.174 220.585, 234.151 150, 182.869 79.415, 234.151 106.376, 151.174 35.792, 99.892 123.039, 99.892 " id='star1' />



We’ll take the same image as we used in the example before and both change colors and perhaps move them around when we hit the different breakpoints. In the Codepen above we do the following things:

  1. In addition to the color for the #star1 element’s fill we make sure that we rotate it to 0 degrees by default
  2. When the browser is 1000 pixels or smaller we hide the circle element
  3. When the browser is 800 pixels or smaller we do the following:
  4. We display #circle1 again (it was hidden in the previous query) and we change its color to #f0f
  5. We take the #star1 element, change its color to #663399 and set up animation attributes: animation tells the user agent what animation, what animation type and for how long we want to use the animation
  6. Definition for the animation steps references in step 5. We define each frame as what percentage of the animation we want that specific action to work on. In this case we defined 3 frames but we can define additional frames to make the animation smoother
#star1 { /* 1 */
  fill: #0f0;
  transform:  rotate(0deg);

/* Media Queries */
@media (max-width: 1000px) { /* 2 */
  #circle1 {
    display: none;

@media (max-width: 800px) { /* 3 */
  #circle1 { /* 4 */
    display: block;
    fill: #f0f;

  #rectangle1: {
    display: none;

  #star1 { /* 5 */
    display: #663399; /* rebeccapurple */
    animation: animationFrames ease-out 2s;
    transform-origin: 50% 50% ;

  @keyframes animationFrames{ /* 6 */
    0% {
      transform:  rotate(0deg);
    99% {
      transform:  rotate(180deg);
    100% {
      transform: rotate(0deg);

The one shortcoming of our image as currently implemented is that there are not enough steps for a smooth 360 degree transition. We could add more steps and make each step more gradual, something like this:

  @keyframes animationFrames{ /* 6 */
    0% {
      transform:  rotate(0deg);
    25% {
      transform:  rotate(90deg);
    50% {
      transform:  rotate(180deg);
    75% {
      transform:  rotate(270deg);
    100% {
      transform: rotate(0deg);

You can use the same techniques to completely change the appearance of your SVG graphic based on size or any query type you can use Media Queries with. The good news is that Media Queries Level 4 provides a much larger feature set for you to work with.

For example, we can modify our SVG content based on whether we’re working with monochrome displays by using a query like this:

@media (monochrome) {
  /* Rules for monochrome displays go here */

Support in browsers or readers

CSS animations should work in all modern browsers that support SVG (all modern browsers from IE9 onwards according to

When I first looked at CSS animations in e-readers I got scared that epub3 didn’t support SVG animations but then I realized that it’s SVG-only animations not CSS animations applied to SVG.

As with all the techniques I’ve discussed here test all your content in your target devices


We can leverage a lot of the CSS tools and specifications inside of SVG files. This is not the only way to do it… We can take the CSS outside of the SVG and incorporate it with the CSS selectors and rules in the rest of our document. This adds our SVG CSS to the list of potential problems of specificity and you’ll have to do a lot more work to make sure the cascade works for your design.

Either way it’s a very interesting technique to add interactivity to your content in the open web.


Books as (web) apps

Books as applications

What would it take to make our books in to applications for the web? In this article we’ll explore what is an application, what is a web application, why it now makes sense to turn our books in to web applications.

What is an application? What is a web application?

Application software (an application) is a set of one or more programs designed to permit the user to perform a group of coordinated functions, tasks, or activities. Application software cannot run on itself but is dependent on system software to execute. Examples of an application include a word processor, a spreadsheet design and management system, an aeronautical flight simulator, a console game, a drawing, painting, and illustrating system, or a library management system. [1]

From Wikipedia

A web application or web app is any software that runs in a web browser. It is created in a browser-supported programming language (such as the combination of JavaScript, HTML and CSS) and relies on a web browser to render the application.[1][2][3]

Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions.

From Wikipedia

Open Web versus OS-specific Apps

It hasn’t been long since browser (Chrome and Firefox) and Operating System Vendors (Microsoft) allow web content to live in the OS as applications subject to packaging and usage restrictions.

I’ve chosen to remain platform neutral as much as possible.

The idea is that we’ll use ‘The Web’ as out application environment where both mobile and desktop users can use the same content. The moment we introduce OS specific features we invite what I call the ‘why not my OS’ syndrome… it’s just not worth it when the web is getting more and more powerful as an application environment all the time.

Mobile devices also have web browsers so we can use the web version in Mobile and we’ll take advantage of that for some mobile browsers (See iOS icons and splash screens, below.)

The DRM/EME monster rears its ugly head

One issue that needs to be addressed is Digital Rights Management or DRM.

People look at DRM as a way to preserve intellectual property and to keep people from giving away or lending books that they did not buy.

But DRM is not a perfect (or even a good) solution. Here are some reasons:

  • The DRM schemas can be broken and the content can still be given away. It is not a trivial exercise, true. But it’s not very difficult either
  • If your ebook provider goes under you will loose access to your books unless the seller has made arrangements to continue supporting the DRM scheme
  • You’re locked to your vendor. Amazon, Apple and Barnes and Nobles all use different DRM schemes and they are not compatible. You may still be locked to your vendor without DRM but it would make switching readers easier if they use a common format without restrictions

Ian Hickson writes about DRM. In one of the last paragraphs of the post, Hickson observes that:

Arguing that DRM doesn’t work is, it turns out, missing the point. DRM is working really well in the video and book space. Sure, the DRM systems have all been broken, but that doesn’t matter to the DRM proponents. Licensed DVD players still enforce the restrictions. Mass market providers can’t create unlicensed DVD players, so they remain a black or gray market curiosity. DRM failed in the music space not because DRM is doomed, but because the content providers sold their digital content without DRM, and thus enabled all kinds of players they didn’t expect (such as “MP3” players). Had CDs been encrypted, iPods would not have been able to read their content, because the content providers would have been able to use their DRM contracts as leverage to prevent it.

This is not just an academic exercise on freedom of expression. Publishers like O’Reilly (described here and here) and Tor have removed DRM from their books and, while the books have been widely pirated, sales have not decreased and have seen a modest improvement. I’ll try to get information from O’Reilly with updated figures and will update the article when/if I received an answer.

In 2009, David Pogue, a technology columnist from the New York Times, wrote a piece about ebooks and copy protection. In the article one of his readers sums up what, to me, the real issue:

“When the iPod introduced music lovers to the idea of copy protection, a years-long war ensued between consumers and the RIAA (and others). The primary issue was that if I purchased a song for my music player, it would only play on that player; I didn’t really own it, per se. Years later, we finally have digital music without copy protection.”

This was reinforced when Amazon deleted books from Kindle readers in 2009 and later in 2012 allegedly wiped a user’s entire Kindle library.

While I understand publishers’ positions, DRM is not the answer any more than it was in the Music industry when Apple introduced the iPod. If we can consistently prove that removing DRM will not damage sales and will improve t he user experience the more we can get publishers to stop thinking in terms of absolute sales as the only goal that matters.

Although not directly related to DRM, in the sense that they don’t provide the full set of access restrictions DRM does, Encrypted Media Extensions (EME) provide a similar platform for building restrictions to video content on the web.

I mention EME briefly because it will become the next battleground in the fight between content distributors and content consumers. The best explanation of what EME is and how it affects the web and its ideals is a page titled What is EME by Henri Sivonen.

What worries me the most is the fact that in the case of Firefox:, as mentioned by Cory Doctorow:

The inclusion of Adobe’s DRM in Firefox means that Mozilla will be putting millions of its users in a position where they are running code whose bugs are illegal to report. So it’s very important that this code be as isolated as possible.

All browsers have some level of support for EME. Firefox has announced their intent to implement EME, Google and Apple already support parts (in the case of Google) and all of the specs (Apple) to fully encrypt video content. At least 3 of these browsers: Firefox, Chrome and Opera (or Chrome Jr.) have open bug reporting systems; how will they be affected by these new restrictions on the proprietary software that makes EME?

Netflix seems to have gotten away with EME, at least for now. MSE, EME, and Web Cryptography APIs to fully control when, how and who can access their content. An earlier post in their technology blog seems to indicate that the technologies are also supported in ChromeOS (with the exception of the Crypto API) and that when Web Crypto is implemented in Chrome then they will move to encrypting all content viewable in Chrome for all platforms.

It’ll be interesting to see how this evolves and what other areas it moves to beyond video. For an interesting discussion about DRM listen to The Web Ahead, Episode 73 with Doug Scheppers and Jeremy Keith.

Online versus offline

One specific type of enhancement we’ll discuss before jumping into the bells and whistles is whether we should add offline caching.

The APIs are in progress. Chrome supports most of the APIs we need to create offline capable applications as part of ServiceWorkers (they support cache, through polyfill, push messaging and notification) whether the page using them is open or not. While the Chrome implementation only support Google Cloud Messaging the idea is that we’ll soon have an open source solution to the push and notification challenges we currently face. So, unless you’re already working with GCM and ther other required technologies it may be better to see what the open web has to offer when the specifications are finalized.

The idea behind push and background notifications is that we can build a fully responsive user experience that will work on and offline and notify the user on specified events, such as updated content, and the application doesn’t even need to be running to do so.

I’ve written about ServiceWorkers when discussing Athena as an offline reading experience so I won’t repeat all the rationale and code here.

In an HTML5 Rocks article Jeff Posnick describes how we can automate the creation of a caching service worker using Gulp.

gulp.task('generate-service-worker', function(callback) {
  var fs = require('fs');
  var path = require('path');
  var swPrecache = require('sw-precache');
  var rootDir = 'app';

    staticFileGlobs: [rootDir + '/**/*.{js,html,css,png,jpg,gif}'],
    stripPrefix: rootDir
  }, function(error, swFileContents) {
    if (error) {
      return callback(error);
    fs.writeFile(path.join(rootDir, 'service-worker.js'), swFileContents, callback);

Enhancing the user experiences

Offline content caching is just part of the exercise. The other part is what additional tools, libraries and scripts we add to our web documents and how will they work in an offline environment.

For each of the technologies discussed below I’ll provide a brief summary and why I chose the technology.

One thing to realize from the beginning is that, while I chose to show all possible technologies, some of these are part of the build process for our site/app they are still important and need to be mentioned

Modernizr and Modernizr.load

Modernizr makes it easier to use new HTML5 tags and APIs and CSS3 technologies in a way that will also provide graceful degradation for our content.

We can leverage Modernizr from both CSS and Javascript.

For CSS Modernizr will add classes for each feature tested depending on whether it supports a feature (regions would be the class if regions are supported) or not (no-regions in that case).

.video .highlight {}

.no-video .highlight {}

For Javascript Modernizr creates an object and attaches all successful tests. for examplle, if we wanto to test if a browser supports video we can do something like this:

if ( {
  console.log ('we can play video');
  // load the vide or do furhter testing
} else {
  console.log ('we cannot play video, need polyfill');
  // load an alternative, perhaps the solution from
  // video for everyone

Modernizr.load uses Modernizr’s feature detection libarry to conditionally load content based on feature availability. Continuing with our video example, if the browser supports HTM5 video and can play h264 (MP4) video we load the video.js otherwise (cannot play h264 or cannot play HTML5 video altogher) we load a polyfill library or, most likely the solution presented in Video for everybody by Kroc Camen.

  test: &&,
  yep : 'video.js',
  nope: 'video-polyfill.js'

There are ways to test for features without using Modernizr, but they all require lots of testing and they are not guaranteed to work on every browser.


Normalize is a CSS library that provides an event and better playing field. In addition to providing the functionality of a CSS Reset library (Like Eric Meyer’s CSS Reset with added functionality.

It [Normalize] fixes common desktop and mobile browser bugs that are out of scope for resets. This includes display settings for HTML5 elements, correcting font-size for preformatted text, SVG overflow in IE9, and many form-related bugs across browsers and operating systems.

For a more detailed explanation see Nicolas Gallagher post abut Normalize.css

Singularity / Susy Grid System

Singularity is a Grid System designed with repsponsive grids in mind. From the documentation:

Singularity is a next generation grid framework built from the ground up to be responsive. What makes Singularity different? Well, a lot of things. Singularity is based on internal ratios instead of context based which allows for better gutter consistency across breakpoints. Ratio based math also allows for non-uniform grids in any unit you want to use.

If you’re used to working with SASS and Compass then it’s a breeze to work with Singularity; however that’s where the problem is: you must work with the Ruby version of SASS and you must work with Compass. Integrating Ruby, SASS installation and compilation and Compass is not a small undertaking so I try to avoid it where possible.

Susy is a more flexible framework; It provides the same functionality without requiring Compass. It also plugs in with existing Grunt SASS tasks, something like this (ignore the syntax for the moment, we’ll revisit Grunt and Gulp later in the article):

// Gruntfile.js
sass: {
  dist: {
    options: {
      style: 'expanded',
      require: 'susy'
    files: {
        'css/style.css': 'scss/style.scss'

Beyond the obvious use of grids to provide a consistent interface to layout content they provide answer to more complicated questions: How do we create layouts with columns of arbitrary width (using percentages or rem units)? How do we span multiple columns? How do we change the gutter for our layout (or parts of the layout)?

Media Queries Support

I am lazy. Even though I have defined my own set of media queries and even took into account different screen sizes and resolutions, it’s not something that I want to maintain long-term. Breakpoint to the rescue!

Breakpoint abstracts a lot of the work in creating Mediaqueries. It includes support for when queries are not supported, ability to pass a context to your own mixins and advanced media queries including: compound queries, density-based and media types.

In an ideal world all browsers would have the same support for the same features and we wouldn’t have to deal with inconsistencies. Media Queries are one step in solving these issues.

Prefix Free and UNCSS

If I don’t have to write it usually I won’t. On the other hand there are times when the accumulation of cruft (old classes the are no longer used) or the sheer size of a framework (think Twitter Bootstrap, Zurb Foundation or Adobe Top Coat) versus the classes from the framework we actually use make for bloated CSS and unnecessary data being sent over the wire.

Addy Osmani has written about this problem along with a potential solution. UNCSS will load the HTML and CSS using Phantom.js and then create a new CSS file using only those selectors that match content in the HTML files. The savings can reach the 100k mark (!).

PrefixFree is a Javascript library that automates vendor prefixes for CSS selectors. The classic example is border radius, there are 5 nearly identical ways to address the same property (WebKit, Chrome/Opera, Mozilla, IE and Standard). Prefix Free takes care of the differences so we don’t have to

When we discuss tooling we’ll talk about grunt-autorprefixer, which removes the Javascript library while achieving the same effect of prefixing content as needed for the browsers we specify.

As I mentioned, I’m lazy and don’t want to write any more code than absolutely necessary have to. This is one way to reduce the code count


Compass Typography suffers from the same issues as all Compass-related plugins do. They depend on Compass which in turns depends on having Ruby installed on your system. Again, don’t get me wrong, I think compass is awesome but it’s not always necessary and it adds bloating to the resulting CSS.

Typeplate takes a minimalist approach to framework development. It doesn’t do much but what it does well and it does simply. It provides a minimal set of HTML models and corresponding SCSS/CSS templates. You can use it as-is or you can enhance it

The idea of using SASS/CSS typography solutions is that it makes it easier to create your content. You don’t always have to stick with what the framework has to offer… I’ve always considered CSS frameworks to be a starting point for my own work and not and end in and of itself.

Neither of the alternatives offers answers to how to load the fonts on the page. Depending on the fonts we may be able to leverage services like, Adobe Typekit, Font Squirrel, Google and Font Deck, among others, to handle the download of your fonts.

Some of the best fonts are not available through font services. If you’re sure the font matches your needs and the license available (in most cases it’s a different license for web and ebooks) you can host the font on your server and use it from there. There are ups and downs like having to provide for font obfuscation and other security measures to having a wider selections of fonts to license and use.

Note the different versions of the same font you have to support to be compatible with most (all?) existing browsers. You probably can do away with supporting IE6 – IE8 if you can but that still leaves you with 5 different formats for each font you want to support (you can convert your woff font to woff2 using this online converter.)

We can embed fonts in our web sites (assuming that we have the license for doing so) with a command like this in our main CSS style sheet:

@font-face {
  font-family: Open Sans';
  src: url('opensans.eot'); /* IE9 Compat Modes */
  src: url('opensans.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('opensans.woff2') format('woff2'), /* Super Modern Browsers */
       url('opensans.woff') format('woff'), /* Pretty Modern Browsers */
       url('opensans.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('opensans.svg#svgFontName') format('svg'); /* Legacy iOS */

And then use the font as you would normally in a font-family instructions.

body {
  background: #efefef;
  font-family: 'Open Sans', sans-serif;
  font-size: 16px;
  line-height: 24px;
  padding: 50px;

CSS Tricks has an interesting article explaining how to use web fonts.

WebFont Loader

The Web Font Loader is a joint project between Typekit and Google that provides tighter control over your fonts loadings process. Main advantage of a system like this is that you can work with fonts from different vendors and reduce the likelihood of the dreaded ‘Flash of Unstyled Content’.

Modular scales and its companion SASS Module provide an easier way to incorporate the scale into you projects.

Drive before you buy

Services like allow you to test fonts in a fully responsive environment with your own text before you commit to using the font in your project. Until recently I thought that was not necessary and that we’d only have to test on devices. This is no longer the case, we should test as much as possible in as many devices as possible.


I love The Web Ahead. I think Jenn Simmons does an awesome job in selecting her guests and having meaningful and insightful conversations about the web; not just the technology but what makes the web work.

This was specially true about the typography episodes where she’s talked to people who have changed the way that I look at fonts and how we use them on the web. The podcasts (in reverse chronological order) are:

Picture elements and responsive images

Wouldn’t it be nice if we could use something like Media Queries for images? We can… it’s the picture element.

The picture element attempts to solve 4 issues / Answer 4 questions:

  • Can I serve different image sizes based on some attribute of the browser accessing the page?
  • Can I provide different images based on DPI?
  • Can I provide different image formats based on device capability? (For example, not all browsers support WebP)
  • Can I provide different images based on my art direction requirements? (full size images may be overkill for smaller devices)

The example below, taken from Opera Developer’s sitearticle on responsive images takes the extreme view of supporting all 4 use cases for responsive images.

For browser windows with a width of 1280 CSS pixels and wider, a full-shot photo with a width of 50% of the viewport width is used; for browser windows with a width of 640-1279 CSS pixels, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. In each case, the browser picks the optional image from a selection of images with widths of 200px, 400px, 800px, 1200px, 1600px and 2000px, keeping in mind image width and screen DPI. These photos are served as WebP to browsers that support it; other browsers get JPG.

    media="(min-width: 1280px)"
    srcset="opera-fullshot-200.webp 200w,
            opera-fullshot-400.webp 400w,
            opera-fullshot-800.webp 800w,
            opera-fullshot-1200.webp 1200w,
            opera-fullshot-1600.webp 1600w,
            opera-fullshot-2000.webp 2000w"
    sizes="(min-width: 640px) 60vw, 100vw"
    srcset="opera-closeup-200.webp 200w,
            opera-closeup-400.webp 400w,
            opera-closeup-800.webp 800w,
            opera-closeup-1200.webp 1200w,
            opera-closeup-1600.webp 1600w,
            opera-closeup-2000.webp 2000w"
    media="(min-width: 1280px)"
    srcset="opera-fullshot-200.jpg 200w,
            opera-fullshot-400.jpg 400w,
            opera-fullshot-800.jpg 800w,
            opera-fullshot-1200.jpg 1200w,
            opera-fullshot-1600.jpg 1800w,
            opera-fullshot-2000.jpg 2000w">
    src="opera-closeup-400.jpg" alt="The Oslo Opera House"
    sizes="(min-width: 640px) 60vw, 100vw"
    srcset="opera-closeup-200.jpg 200w,
            opera-closeup-400.jpg 400w,
            opera-closeup-800.jpg 800w,
            opera-closeup-1200.jpg 1200w,
            opera-closeup-1600.jpg 1600w,
            opera-closeup-2000.jpg 2000w">

Sure, this takes a lot more work to setup both in terms of preparing images of different sizes and resolutions and in terms of preparing your HTML to accomodate all your needs but we can now finally stop depending on servers to convert our images or provide a one-size-fits all solution.

ServiceWorker caching

I ran my first experiment with ServiceWorkers as part of my Athena Framework Experiment where the idea was (and still is) to cache content for offline viewing so that network becomes another layer of enhancement as we only need to be online the first time we access out content and the cache will display the content whether we are online or not.

If you use Chrome as your primary development platform you can take advantage of Push Messaging (Google Cloud Messagin) and Background notification to enhance your users’ experience but only tied to the Google echo system.

Despite the advantages I’ve decided to hold off on Push and Background Notification and concentrate on caching the content. Once the open APIs for Push and Background notification reach candidate recommendation status (meaning that there are two interoperable implementations available in the wild) I will revisit the issue.

Emphasis deep Linking

The Emphasis Library was initially developed by The New York Times as a highlighting and deep linking library. What caught my attention is that you’re not limited to single user linking; you can share the link and it will display the same highlights and annotations that you created.

Emphasis was initially developed as a jQuery plugin which made it less attractive as someone who wanted to develop a dependecy-free framework. When I revisited the plugin I had decided to use jQuery anyways and the pluging had moved away from jQuery as a dependency.

Even though I chose to make jQuery available I was still pleasantly surprised to see the code be made jQuery-free.


A lot of what I write is web-related with lots of code examples for HTML, CSS and Javascript. I know for certain that I don’t want to do the highlighting by hand.

There are many code highlighting libraries available. I chose highlight.js for HTML as well as PDF generated from XML.

I love the library’s breadth of supported languages and the work it saves makes it totally worth it.

Another library worth looking at is Prism.js

Regions and Shapes

If we’ll push the envelope then I want to be able to push the envelope in terns of the technologies that will make the user experience more engaging and interactive content.

I’ve written about shapes both as a new technology and in conjunction with svg clip paths.

Shapes can provide better drop cap support (by wrapping closer to the shape of the letter) and can provide better floated text with different shapes.

Support is inconsistent and must be polyfilled in order to work accross the board. See the polyfill readme file for more information on how to use the polyfill and what browsers are supported.

Regions provide a different way to layout the content that doesn’t involve tables and doesn’t require Javascript.

OS Specific Home Screen Icons and Splash Screens

While I remain committed to keeping this project on the web, there are enhancements we can make to provide a better experience in mobile without loosing the desktop experience.

The downside is that these enhancements are platform specific. Every time we add this functionality we must do so for each browser.

iOS icons and splash screens

When iOS was first introduced one of the features that first caught my attention was the ability to save web sites to the home screen and use them as an online-only web application. I always thought that it was something only full applications or apps from larger companies could do. It wasn’t until I read the Configuring Web Applications section of the Safari Web Content Guide that I realized that it was hard work but it was doable by anyone.

We add the following elements to the head of our content page (not 100% sure if this is for every page or only for the index). The first set of resources deal with fixing the width of the device to a 1 to 1 scale window, full screen and no app bar at the top of the application.

<meta name="viewport" content="user-scalable=no, initial-scale=1.0" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />

The second block adds the application icons that will appear in the home screen when we add the site/app. We have to add multiple icons to account for different screen size/resolution/DPI combinations available to different devices.

<link rel="apple-touch-icon" href="/images/misc/apple-touch-icon-57x57.png" />
<link rel="apple-touch-icon" sizes="72x72" href="/images/misc/apple-touch-icon-72x72.png" />
<link rel="apple-touch-icon" sizes="114x114" href="/images/misc/apple-touch-icon-114x114.png" />

The final step is to add the spalsh screen that will appear while the site is loading. As with the icons, we have to account for different size/resolution/DPI combinations for different devices.

<!-- iPhone/iPod Touch Portrait – 320 x 460 (standard resolution) -->
<!-- These are not all available resolutions, do your homework -->
<link rel="apple-touch-startup-image" href="/images/misc/splash-screen-320x460.png" media="screen and (max-device-width: 320px)" />

<!-- For iPad Landscape 1024x748 -->
<link rel="apple-touch-startup-image" sizes="1024x748" href="/images/misc/splash-screen-1024x748.png" media="screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:landscape)" />

<!-- For iPad Portrait 768x1004 (high-resolution) -->
<link rel="apple-touch-startup-image" sizes="1536x2008" href="/images/misc/splash-screen-1536x2008.png" media="screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:portrait) and (-webkit-min-device-pixel-ratio: 2)"/>

Windows8 application tiles

Windows 8 (in tablets and phones) allows applications to be tiled on the start screen. We can take advantage of this feature by going to completing the form and download the resulting kit. We can the paste the code below on the head of our pages and upload the associated images to the server.

<-- Windows 8+ tile stuff -- Assumes all content is uploaded to server -->
<meta name="application-name" content="My Awesome Site"/>
<meta name="msapplication-TileColor" content="#e809e8"/>
<meta name="msapplication-square70x70logo" content="tiny.png"/>
<meta name="msapplication-square150x150logo" content="square.png"/>
<meta name="msapplication-wide310x150logo" content="wide.png"/>
<meta name="msapplication-square310x310logo" content="large.png"/>

Chrome on Android

Chrome takes a two-prong approach to adding web apps to the homescreen. First it asks to link to a json manifest file (in the example below I called it manifest.json

<link rel="manifest" href="manifest.json">

The manifest itself looks like this:

  "name": "Web Application Manifest Sample",
  "icons": [
      "src": "launcher-icon-0-75x.png",
      "sizes": "36x36",
      "type": "image/png",
      "density": "0.75"
      "src": "launcher-icon-1x.png",
      "sizes": "48x48",
      "type": "image/png",
      "density": "1.0"
      "src": "launcher-icon-1-5x.png",
      "sizes": "72x72",
      "type": "image/png",
      "density": "1.5"
      "src": "launcher-icon-2x.png",
      "sizes": "96x96",
      "type": "image/png",
      "density": "2.0"
      "src": "launcher-icon-3x.png",
      "sizes": "144x144",
      "type": "image/png",
      "density": "3.0"
      "src": "launcher-icon-4x.png",
      "sizes": "192x192",
      "type": "image/png",
      "density": "4.0"
  "start_url": "index.html",
  "display": "standalone",
  "orientation": "portrait"

More information on the Chrome Developers’ site


jQuery has always been a touchy subject for me. On the one hand it is still a good library to smooth out browser idiosyncracies and to provide a common interface for developers to work. I usually chose jQuery over Dojo (even though I think Dojo is the better library) because of all the plugins available and the relative ease of implementing your own.

The problem I have is not really with jQuery but with the people who use the technology without understanding what it does, how it works and how to modify it when needed.

I tend not to use jQuery much but make it available in case there are plugins that the creator may want to use.

The two sides of jQuery

Below are 2 views on the jQUery debate. I will let you decide for yourself if this is worth it.

@zackbloom and adamfschwartz created You Might Not Need jQuery to show developers that jQuery is not the only way to achieve web effect and support older browsers. They use IE as an example, probably because older versions of IE is the most problematic of browsers

John-David Dalton, Paul Irish created a document outlining browser bugs jQuery fixes as an answer to You May Not Need jQuery. They point out that:

While the sentiment of youmightnotneedjquery is great, developers should be aware that ditching libraries, like jQuery, can easily require large amounts of research on their end to avoid bugs (even in modern browsers). The snippets provided by youmightnotneedjquery are a starting point but hardly scratch the surface of being a solid robust replacement to jQuery.

The great thing about an established library, like jQuery, is it’s hammered on by lots of talented people, transparently improved, and refined by the community. jQuery core is very careful not to bloat their codebase and does not add features or fixes without serious consideration and peer review. If it’s in jQuery that means it’s addressing real compatibility issues.

stayInApp jQuery Plugin

One of the annoyances of working on mobile browsers is that clicking on links takes you out of the full screen experience into Safari’s interface.There is a jQuery plugin designed to keep you in your web application when you click on links and, thus, preserving your application’s experience.

The Plugin only works for iOS and it takes advantage of the ability to detect when iOS is in full screen mode

I’m looking for ways to provide and equivalent functionality for Android and Windows.

Tooling and Automation

For most web-related project I’ve used Grunt as my task runner. Grunt was the first software I used to run commands like I used to do with Ant and Make in a pure Javascript environment. sometimes it gets painfully slow but nowhere near as slow as Ant used to be.

Grunt automates all the tasks that I need in a project: convert from SASS to CSS, concatenate and minnify all third party Javascript libraries and plugins, use Autoprefixer and UNCSS on the generated CSS and save it with the same name, copy all the resources needed into a distribution folder and even publish the distribution to Github’s gh-pages branch.

Gulp is similar to Grunt but it starts from a different premise. Where Grunt puts the emphasis on configuring the task to run, Gulp gives developers the flexibility to create their own tasks to work anyway they want and only enforces how these tasks connect to each other. put in another way: “Grunt focuses on configuration, while Gulp focuses on code.”

sass: {
  dev: {
    options: {
      style: 'expanded'
    files: [ {
      expand: true,
      cwd: 'scss',
      src: [ '*.scss'],
      dest: 'css',
      ext: '.css'
  production: {
    options: {
      style: 'compact'
    files: [ {
      expand: true,
      cwd: 'scss',
      src: [ '*.scss'],
      dest: 'css',
      ext: '.css'

The best way I’ve found to do this with Gulp is create two separate tasks, one for development and one for production. They would looks something like this:

gulp.task('sass-dev', function() {
  return gulp.src('src/styles/main.scss')
    .pipe(sass({ style: 'expanded' }))

gulp.task('sass', function() {
  return gulp.src('src/styles/main.scss')
    .pipe(sass({ style: 'compressed' }))

Gulp allows you to pipe commands to output of the previous command. The example below will do the following:

  • Convert the SASS files into CSS
  • Minify the CSS
  • Rename the CSS file and convert it to .min.css
  • Write the resulting file out
//declare the task
gulp.task('sass', function(done) {
    .pipe(sass({ style: 'compressed'}))
      keepSpecialComments: 0
    .pipe(rename({ extname: '.min.css' }))
    .on('end', done);

As you can see, each Gulp tasks does one thing and then passes its output as the input the next task.

Grunt / Gulp links and resources

Towards Subcompact Publishing

In Platforming books Craig Mod proposes a multi platform approach to book publishing anchored in the success of his Artspace Tokyo Kickstarter project.

He suggests that books should have: An open web presence with the complete book content, an iBooks version to enjoy the advanced capabilities available to the format, Kindle and PDF versions of the book with the advantages of each format and the things you can get out of it.

Then in Subcompact Publishing he proposes a departure from tradition in the digital publishing business. It advocates for a system that has/is:

  • Small issue sizes (3-7 articles / issue)
  • Small file sizes
  • Digital-aware subscription prices
  • Fluid publishing schedule
  • Scroll (don’t paginate)
  • Clear navigation
  • HTML(ish) based
  • Touching the open web

While some of these areas apply to periodical publications (magazines and such) several of these elements are applicable to a wider publishing channels.


Note that not all examples listed are books or book-like web experiences. Some, like Unnumbered Sparks, are listed because there was some aspect I thought important to highlight.

  <h3>Books and magazines</h3>
  • Offline Reader. I’m not much for paginated content but think this is an example of how to make it work. It is also built with Polymer so it’s become a good model of how this can be done
  • Artspace Tokyo by Craig Mod and Ashley Rawlings. It highlights a lot of the ethos of Subcompact Publishing and how to Platform books
  • Shape of Design by Fran Chimero. The navigation was a little hard to understand at first but once I understood the metaphor it became very easy to navigate
  • The Magazine provides a good example of what a SubCompact publication may look like. What I loved the most was t he speed of publication, how long it took to download and read and, particularly, the little link trick where clicking on a link will pop up a small window with information about the link and the giving you the option of actually going to the link

Other Online

  • Liz Danzico’s blog provides a clean and crisp interface. I particularly love the way the site (designed by Jason Santa Maria) uses white space
  • Climbing Everest presents a fully interactive experience and it draws the reader to interact with the content
  • Tokyo Otaku Mode started as a Facebook page and reached over 3 million subscribers before developing apps and how to subvert the publishing and marketing worlds
  • Unnumbered Sparks is the largest web browser I’ve ever seen. There is a Chrome instance about 10 million pixels that projects users’ interactions into the hanging structure. Every time I see this project (both the video and the material available at the Autodesk Museum in San Francisco) makes me think I’m not thinking big enough
  • Cabbibo’s website makes extensive use of WebGL and 3D web as an expressive medium. It is in the convergence of 2D and 3D where we can find the trully expressive potential of the web
  • Forest Giant and Alice in Woderland are technology demonstrations from Adobe that push the envelope of what you can do with web technologies. Unfortunately some of the CSS technologies have been caught in what I call “specification hell” with a very uncertain future (which makes me really sad)