Who are the next billion users and how do we accommodate them

Where are the next billion users for our applications come from? When answering this question we have to be careful. The answer itself is easy, the implications of the answer, not so much. I’ll leverage 2 presentations to support the rest of the essay.

Tal Oppenheimer from Google’s Chrome team made a very interesting and thought provoking presentation about building the web for the next billion users and what we should consider when building our experiences.

Bruce Lawson from Opera takes a different view of the next billion users. He warns us about where these users are coming from and what we need to do on our end to make their experience with you app better.

We, western web developers, are spoiled by choice. We have above average bandwidth, devices are powerful and have plenty of storage and we have both desktop and mobile devices for everyday use as well as development. We can also argue about build tools and about frameworks and debate the little minutiae of front end web development

But not all our users have the same hardware we do and bandwidth doesn’t cost the same everywhere. Not all developers have the same resources than we do.

If we take for a fact that the next billion users will come from Asia (not counting Japan) and Africa then we definitely have to change our mindset as developers.

I’ll pick India and China as two examples of what the next billion users may look like. I will not cover political censorship or the Great firewall in China. I don’t know how the firewall works and it’s outside my area of expertise. I also don’t want to deal with politics.

Infrastructure and cost

The first thing we need to consider is how much does it cost to go online. Even if connectivity is expensive we have better infrastructure and, in metropolitan areas, we have better options for speed and they continue to improve.

In countries like India the number of internet users has increased but not at the same rate as infrastructure and therefore the cost of that infrastructure is higher in India than it would be elsewhere.

Some times we forget that Javascript or no Javascript is more than having it turned on or off but also of it being available. Do we plan for what happens if a JavaScript request times out or if the user agent

The idea behind Progressive Enhancement is to have content for all browsers, regardless of capabilities. Most apps I’ve interacted with will present blank screens when Javascript fails… for whatever reason.

What happens when your connection is so slow that the request times out regardless of how much you’re compressing your data. Or what happens when you’re using a proxy browser like Opera Mini in its current incarnation where most Javascript and CSS is not supported in the payload the server sends to the browser?

Aaron Gustafson’s Understanding Progressive Enhancement presents the best defintion of progressive enhancement and graceful degradation:

Graceful degradation focuses on building the website for the most advanced/capable browsers. Testing in browsers deemed “older” or less capable usually takes place during the last quarter of the development cycle and is often restricted to the previous release of the major browsers (IE, Mozilla, etc.).

Under this paradigm, older browsers are expected to have a poor, but passable experience. Small fixes may be made to accommodate a particular browser. Because they are not the focus, little attention is paid beyond fixing the most egregious errors.


Progressive enhancement focuses on the content. Note the difference: I didn’t even mention browsers.

Content is the reason we create websites to begin with. Some sites disseminate it, some collect it, some request it, some manipulate it, and some even do all of the above, but they all require it. That’s what makes progressive enhancement a more appropriate paradigm. It’s why Yahoo! swiftly adopted it and used it to create their Graded Browser Support strategy.

I am normally an advocate for progressive enhancement but for it to be an effective strategy we need to have content to enhance.

The browser landscape

One of the biggest surprises when researching this article was the difference browser landscape between the China, India and the US and the appearance of new browsers in the landscape that, while available in the US, have a significantly larger market share in Asia.

The tables below are taken from stat counter and reflect data from June 2015 to June 2016.


Top 9 Mobile & Tablet Browsers in China from June 2015 to June 2016


I’m making the assumption that the version of Opera used in India and China is Opera Mini and that UC Browser is also a proxy browser

Opera Mini and UC Browser are proxy browsers. They work by sending your request to a remote server that fetches the resources for your page, filters some of the content, and returns a compressed blob to the device to render. Because of the way the current version of these browsers fetch the content they don’t handle Javascript or most things we take for granted.

How do we create content?

When we look at this question we should look at the following aspects:

  • The actual content we create
  • Handling device limitations and how it affects the content we create.

Cultural awareness on the content we create

Different audiences require different content and addressing issues that may not seem relevant. These are some examples:

In his presentation Bruce Lawson suggest we don’t require a last name because there are people in Asia who only use one name and requiring a last name means they can’t register for our service.

Even in countries that speak the same language words can have different meanings.

I’m a Spanish native speaker and always thought that guagua only means baby as it did where I grew up. But according to Wikitionary it may also mean bus in other areas where people speak the language.

Colors can have different meaning depending on the user’s cultural background. In the table below, taken from http://blog.globalizationpartners.com/culturally-customized-website.aspx, we can see how different cultures perceive color. How does the perception of color afect how people see your brand and content?

COLOR USA China India Egypt Japan
Red Danger
Good fortune
Death Anger
Orange Confident
Sacred (the Color Saffron) Virtue
Yellow Coward
Celebration Mourning Grace
Green Spring
Eternal life
Blue Confident
Purple Royalty
Royalty Unhappiness Virtue Wealth
White Purity
Mourning Fun
Joy Purity
Black Funeral
High Quality
Evil Death

Working with the constraints of users’ devices

Another thing to consider is device capabilities. As developers we should not think that everyone everywhere will have the same type of hardware we have available

How do you handle the limitations of proxy browsers when they are the main browser used by your target audience? Both UC Browser and Opera Mini are soon releasing (if they haven’t already) versions that will support more of the technologies to create Progressive Web Applications. Will it be enough to render your content as you intended? Will it be a close approximation?

If you decide to gracefully degrade your content how do you handle Proxy Browsers, since they will be your lowest common denominator?

Testing simulated speed and testing on devices

To get an idea of what would a slow connection would do to your application throttle the connection. This is only available in Chrome Dev Tools under the network tab

It’s a good approximation to what the experience is for users in that type of connection but it’s just that, an approximation. We should still test in the devices we expect our users to have and use.

We should also test on actual devices mirroring, as close as possible, the devices we expect our users to have

Device pile by Adactio on Flicker (cc by 2.0)
Device pile by Adactio on Flicker (cc by 2.0)

In addition to the variety of devices that we have in western countries (some of them shown in the image above) we have many other devices specific to regions or countries.

Do you recognize any of these phones?

  • Nokia X2 _01-3610 
  • Samsung E1282T
  • Nokia 2690
    These are the top three mobile phones used in India in 2015 based on Opera agregate data and presented by Bruce Lawson at Velocity. Look at the specs and form factors of these phones. How does it affect the design and development process?

One last aspect we need to consider is the size of our web content against what it’ll cost users to access it. India’s internet is slower and more expensive than we would expect.

In her presentation Tal Oppenheimer gives the example of some people in INdia having to spend salary equivalent to 17 hours of work to buy a 500MB data package.

If we accept that the standard web application developed in the US is 2MB in size (combination of HTML, CSS, JS, images and any additional content) How much are we asking our users in India (and other places with similar access cost) to spend just to interact with our content? How much are users choosing not to interact with our application because of its cost?


There are many factors to consider when working with the next billion users. This essay rises questions and beings the process of learning more about who the next users of our apps will be.

Case Study: Building a Polymer application

One of the first applications I created with Polymer 0.5 was a project viewer that would list all project ideas I was working on. It had 2 versions with different backends: a JSON file and a Firebase enabled one. At some point the Firebase version stopped working so I decided to revisit the JSON backend to update; it was also time to put all the lessons I’ve learned about Polymer 1.x to work.

The application is built around 3 components:

  • project-app is the shell for the application containing layout elements. This could have been done as an autobinding template in index.html but I’ve always liked to keep them separate
  • project-menu holds icons and links to auxiliary information
  • project-list contains the bulk of our content. This is where we load out JSON data using iron-ajax and display it inside paper-card elements. When we build an API for our projects or decide to move the backend to a nosql database we can move the AJAX call from a local file to hit the API or the datbase as needed.

There is no CRUD for the project. That could be an interesting next step but right now I need a way to display the ideas so I’ll lave it as is for now. May revisit the idea when moving the backend to Firebase.


The index file is simple. It just contains the project-app element.

<!DOCTYPE html>
<html lang="en">
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="description" content="Polymer experiment for displaying list of projects from JSON file">
  <meta name="author" content="Carlos Araya">
  <title>Carlos Araya Portfolio and Project List</title>
  <script src="bower_components/webcomponentsjs/webcomponents.js"></script>
  <link rel="import" href="project-app.html">

The first case is as simple as we can make it. The HTML file contains a script tag to add
&nbsp;webcomponents.js and the element we want to add to the page.

We could add the logic of project-app directly to this file using auto binding templates. It would then look like this:

<!DOCTYPE html>
<html lang="en">
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="description" content="">
  <meta name="author" content="Carlos Araya">
  <title>Carlos Araya Portfolio and Project List</title>
  <script src="bower_components/webcomponentsjs/webcomponents.js"></script>

  <link rel="import" href="elements.html">
<template id="t" is="dom-bind">
    :host {
      margin: 0;
      font-family: 'Roboto', 'Noto', sans-serif;
      background-color: #eee;

    app-header {
      color: #fff;
      background-color: #3f51b5;

    app-drawer {
      --app-drawer-width: 300px;

          <paper-icon-button icon="menu" drawer-toggle></paper-icon-button>
          <div title>Project List</div>





This version builds onto the original by adding an HTML Import link for elements.html which in turns contains imports for all the elements in the application I’ll explain why I did it this way when I discuss build processes.

Next we copy the template from element from project-app and add it to the index page. We add the is="dom-bind" attribute to tell Polymer to stap the content of the template right away.

Which version of index.html you use depends on your requirements. If you require portability or think you may want to use the element in a different project then having a separate project-app element is the way to go as you’ll be able to drop it right into the next app.

If this is a single use element then the auto binding template on the second example works better. The content of the template is automatically stamped into the host document and you don’t need to have an extra element to do so. Just remember that Polymer elements already do everything you can do in an autobinding template so that shouldn’t be the deciding factor.

I will work with a separate project-app element which I’ll refer to in the next section.


Project-app is the standalone container for the application: it uses app-layout element and its components to wrap our project specific items: project-menu for the sidebar and projec-list for our primary content.

<link rel="import" href="elements.html">
<dom-module id="project-app"> 

Any styles we put inside the template will be local to that element. Polymer uses a shim to handle custom properties (a.k.a: CSS variables) and we use them to handle the width of the drawer.

      body {
        margin: 0;
        font-family: 'Roboto', 'Noto', sans-serif;
        background-color: #eee;

      app-header {
        color: #fff;
        background-color: #3f51b5;

      app-drawer {
        --app-drawer-width: 300px;

We use the elements from app-layout to build the structure of the application. app-drawer-layout is the outermost container for the application shell; it holds the project-menu element that will hold the menu items.

app-header-layout is the body of the application. The one item that needs explanation is the paper-icon-button element, more specifically the drawer-toggle attribute. This attribute will do magic behind the scenes and hide the menu until a media query is triggered, it will then hide the left drawer panel and show the menu icon. When you click on the menu the drawer will appear; you can dismiss it by clicking elsewhere eon the screen.

This element will also contain project-list.

            <paper-icon-button icon="menu" drawer-toggle></paper-icon-button>
            <div title>Project List</div>




The final stage is make this into a Polymer element with the script holding a Polymer object that defines it as a project-app element.

          is: "project-app"


If we’re working on progressive web applications we may want to trim the contents of elements.html to just hold the minimal content to stamp out project-app and then cache index.html, elements.html and project-app on Service Worker install.

Why XHTML is still the best answer for web publishing

Brad Neuberg wrote an article about making ePub3 “play nice” with HTML5. I read it and initially agreed with it but, upon second reading and some thought I disagree with the essence of his argument.

Brad opens his argument with the following two bullet points:

  • The first is a version of HTML5 that uses XML’s rules: everything has to be well formed and there can’t be any mistakes in how you create your markup. This is commonly known as XHTML5, to indicate the HTML5 standard but based on XML. XHTML5 tends to be used in specialized back end systems to do text processing as there are fairly sophisticated tools for working with it, and it also turns out to be what EPUB3 uses.
  • The second is tag soup HTML5: you don’t have to close your tags and processing is much looser and closer to the older HTML4 standard. Tag soup HTML5 dominates the open web; it’s probably 99.9% of all the content you would access with a conventional web browser.

He further argumes that because tag soup is the dominant use of HTML5 that all tools should be using it and that XHTML 5 should only be used in back end systems.

In twitter conversation he argues, erroneously in my opinion, that it was the strictness and the restrictions it placed on content authors that caused the split with WHATWG and the creation of HTML 5. It was the move to an XML only environment and the creation of a completely separate mime type (application/xhtml+xml) for XHTML applications that caused the split.

Very few, if any, authors actually publish XHTML. They publish HTML in XHTML compatibility mode without actually changng the mime type of HTML documents or setting up the appropriate default namespace as required for XHTML compliance

First, the future is creating high quality markup in HTML5 and then publishing it into different channels.

In that we agree.

We need a common base to create our content, but let’s also remember that HTML or XHTML cannot do everything.

Creating good coding habbits

If name spaces were not an issue, I would still have an issue with tag soup HTML: it promotes laziness and it makes the code hard to read and understand.

Look at the following example:

<title>Sample document</title>

<h1>Sample document

<p>Lorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem <em> and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random text</p>

<p>Lorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem <em> and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random text

<p>Lorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random textLorem <em><b>and some random text</em></b> Lorem Ipsum and some random textLorem Ipsum and some random textLorem Ipsum and some random text

In the example above, a more or less classic example of a tag soup web document we can see the following issues:

  • There is no distinction between the head and the body of the document
  • The charset of the document is not defined
  • There re mutiple instances of incorrectly nested tags

HTML5 provides mechanisms for user agents to work around inconsistencies outline above. It does not encourage authors to use this system to write HTML content.

Why does this new HTML spec legitimise tag soup?

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

From: wiki.whatwg.org/wiki/FAQ#Why_does_this_new_HTML_spec_legitimise_tag_soup.3F

Specific requirements for authoring HTML5 documents can be found here: Conformance requirements for authors. It again reinforces the idea that because it is possible to create malformed tag soup documents you shouldn’t do it.

Elements from other XML-based name spaces

We can not add these elements to a tag soup-based html document. Whether this is a major issue will depend on your project needs but unless WHATWG/W3C provide an alternative, name spaces are the way to go

ePub 3 uses elements from the following namespaces in order to add functionality to ePub-based publications.

Prefix Namespace URI
epub http://www.idpf.org/2007/ops
m (MathML) http://www.w3.org/1998/Math/MathML
pls http://www.w3.org/2005/01/pronunciation-lexicon
ssml (Speech Synthesis Markup Language) http://www.w3.org/2001/10/synthesis
svg (Scalable Vector Graphics) http://www.w3.org/2000/svg

An example of XML vocabularies used in ePub 3 documents. Taken from EPUB Content Documents 3.0

Javascript support for namespaced content

While technically it would be possible to convert epub:type to epub-type I fail to see the reason why we should. Both Javascript and CSS allow us to query for ePub namespaced (or any other kind of) attributes. we can either query bu class containing the attribute:

//select the first element that has the "content" class name
  var content = document.getElementsByClassName("content")[0];
  //a returns undefined but it still stores the correct value
  var a = content.getAttributeNS('http://www.idpf.org/2007/ops', 'type');
  alert(a); // shows the value of type for that element

We can also wrap our code in ePub specific containers. ePub make available the navigator.epubReadingSystem property which we can use to execute all our ePub realted code without affecting the rest of our script.

// If the user agent is an ePub Reading System
  if (navigator.epubReadingSystem) {
    feature = touch-events;
    // Test for the touch events feature
    var conformTest = navigator.epubReadingSystem.hasFeature(feature);
    // Output if the feature is supported
    alert("Feature " + feature + " supported?: " + conformTest);

See http://code.google.com/p/epub-revision/wiki/epubReadingSystem for more information.


As far as CSS is concerned namespace support was introduced as a draft document in June of 2013. Support is not widespread but when it is, we’ll be able to do something like this:

@namespace "http://www.w3.org/1999/xhtml"; /* This defines the default namespace*/
@namespace epub "http://www.idpf.org/2007/ops"; /* this defines the namespace "epub" */

table {
  border: 1px solid black
epub|type {
  display: block;

Typography II: Fonts to the page

We have typography on the web!

As John Allsopp points out in his blog Happy 17th Birthday CSS we have come a long way but we still have very far to go.

When I first started playing with web design back in 1996 the web was just plain. It was meant as a way to exchange information, not produce the high-end, high-gloss content we see today.

Surprisingly enough we’ve had the ability to embed fonts for over a decade. CSS2 included the ability to embed fonts when it was first released but it wasn’t highly used until CSS3 came out and fount foundries decided that there was money to be made online.

New elements in HTML5 and CSS3 (web fonts among them) allow some wonderful work to be done online without having to resort to images or overtly complicated CSS and Javascript tricks to make it look somewhat like what the designer had originally envisioned.

Examples of good web typography

Licensing: the big pain in the ass

Unfortunately every time we want to work with web fonts the ugly licensing monster raises its head. It’s not just a matter of purchasing the font, converting it to the correct formats (see How do we add fonts to the web? for the actual formats and process involved) but it also involves making sure that the font license allows you to use the font with @font-face techniques (read the EULA that comes with your font to make sure).

@font-face Embedding (Linking)

I didn’t include the @font-face font embedding method in the list above because it’s a different animal. @font-face doesn’t use PHP, JavaScript or Flash to embed the font. It solely relies on CSS and a compatible browser (see @font-face and 15 Free Fonts You Can Use Today for more information).

Information around the web isn’t exactly clear on this but my opinion is that the @font-face method isn’t really “embedding” but instead linking because you’re simply telling the browser where the actua font file is via CSS. This means the font file is directly accessable to your visitors, making this method quite different than the ones listed above.

Even if the font license permits font embedding, it may not permit embedding with @font-face because this method allows direct access to the font file. Microsoft uses the .eot font format (Embedded OpenType) as a solution to this problem. EOT is supposed to respect the flags in the font files for embedding and can be limited to specific domains. Non-IE browsers however, have not adopted this technology and don’t plan to. That means you’ll need to use a .ttf or .otf version of the font for non-IE browsers if you want true cross-browser compatibility.

If you decide to use @font-face, be absolutely, positively sure that the font license allows it. It should specifically state the use of @font-face is permitted and if there are any additional restrictions (ie. give credit somewhere).

From http://blog.themeforest.net/general/font-licensing-for-the-web/

Can I use an Adobe font on the web?

Adobe’s current End-User License Agreement (EULA) for fonts does not permit font linking with @font-face using any font format, including, but not limited to, desktop (“raw”) fonts and the Web Open Font Format (WOFF). Adobe provides select Adobe Web Fonts for use on the web through the Adobe Typekit® web font service, where web font usage is governed by the Typekit service Terms of Use.

A font’s usage permissions are specified in your EULA that accompanied the font when you acquired it. Refer to your EULA to determine the type of usage permitted.

From: http://www.adobe.com/products/type/font-licensing/licensing-faq.html

Typekit and other similar services provide an alternative licensing model. When you use Typekit-like services the fonts remain on the company’s server and you link to them using special Javascript that is specific to a user’s account.

What is Typekit?

The Adobe Typekit service provides secure, subscription-based web font hosting for web designers and developers, made possible by the @font-face rule. Typekit subscribers have access to a collection of fonts that can be used on basically any web site. You can view the Adobe Web Fonts available on the Typekit service on Adobe’s foundry page.

Although Typekit relies on the @font-face rule to work, it is different from web fonts used by end users. Fonts remain protected on the Typekit servers and are dynamically delivered to browsers in the appropriate format to ensure an optimal and consistent typographic experience. Typekit offers user-friendly integration with CSS and HTML code, and other optimizations, like font subsetting.

From: http://www.adobe.com/products/type/font-licensing/licensing-faq.html

You can pick fonts where the license specifically allow unrestricted use of the software. For example the Ubuntu font license states that:

This licence allows the licensed fonts to be used, studied, modified and redistributed freely. The fonts, including any derivative works, can be bundled, embedded, and redistributed provided the terms of this licence are met. The fonts and derivatives, however, cannot be released under any other licence. The requirement for fonts to remain under this licence does not require any document created using the fonts or their derivatives to be published under this licence, as long as the primary purpose of the document is not to be a vehicle for the distribution of the fonts.

From http://font.ubuntu.com/license

A final alternative is a service like Google fonts that provides easy access to a growing number of fonts. Like with the Typekit service, the fonts are still hosted on Google’s servers and it provides you with links to use in your CSS or Javascript.


Is cost an option? (my font pricing horror story)

I’ve loved Stone Sans Humanist ever since I first saw it used in an MIT Press book (The Second Self by Sherry Turkle, I belive). I loved the way that it flowed on the page and how it looked. I didn’t know any better to know the technical aspects of the font. I only knew I really liked it.

Fast forward 12 years. I’m working on an eBook project and I decided I wanted to use my favorite font in my own project. Not only the font wasn’t available for embedding at the time but the cost to license the font for embedding in an eBook was prohibitive at the time and it was very restrictive.

That is the primary reason why I’ve turned to free/open source fonts for most of my work. I’ve also subscribed to the full Typekit service to make sure that the fonts I want are available for the projects I work on even this will not solve the problem because not all fonts are available for all providers (sadly Stone Sans Humanist is not available through Typekit nor through the vendor’s free font service; you).

Where do I find fonts for embedding?

Below is a partial (and already outdated) list of fonts that are available for embedding. This small list does not include Google Fonts or Typekit (which provides a limited free service)

Where do we find good and free fonts?

The list below include fonts and font collections I’ve used in projects in the past


How do we add fonts to a web page?

One of the first things we need to realize is that there are multiple fonts for a given type. For most people making a font bold is just a matter of highlighting the text and pressing Command (or Control) + B but for graphic designers and other people who work with type (online and off) that is sacrilege. When you make a font bold you’re actually assigning a bold font to the text.

Font and CSS declarations

[codepen_embed height=”689″ theme_id=”2039″ slug_hash=”DJsCB” default_tab=”css”]
@font-face {
font-family: "Your typeface";
src: url("type/filename.eot");
src: local("☺"),
url("type/filename.woff") format("woff"),
url("type/filename.otf") format("opentype"),
url("type/filename.svg#filename") format("svg");

@font-face {
font-family: "Your bold typeface";
src: url("type/filename-bold.eot");
src: local("☺"),
url("type/filename-bold.woff") format("woff"),
url("type/filename-bold.otf") format("opentype"),
url("type/filename-bold.svg#filename-bold") format("svg");

@font-face {
font-family: "Your italic typeface";
src: url("type/filename-ital.eot");
src: local("☺"),
url("type/filename-ital.woff") format("woff"),
url("type/filename-ital.otf") format("opentype"),
url("type/filename-ital.svg#filename-ital") format("svg");

h2 { font-family: "Your typeface", Georgia, serif; }
h2 em { font-family: "Your italic typeface", Georgia, serif; }
em { font-style: italic; }

See the Pen Example font-face declaractions by Carlos Araya (@caraya) on CodePen.

See Paul Irish’s @fontface gotchas/ for some early pitfalls of @fontface use

The different font formats used above are explained in the following table:

String Font Format Common extensions
“woff” WOFF (Web Open Font Format) .woff
“truetype” TrueType .ttf
“opentype” OpenType .ttf, .otf
“embedded-opentype” Embedded OpenType .eot
“svg” SVG Font .svg, .svgz


Typekit assigns each user’s kit (one or more fonts packed together) a unique ID that is part of the script yuou are asked to use. The script looks something like this:

[codepen_embed height=”257″ theme_id=”2039″ slug_hash=”uIypz” default_tab=”html”]
<script type="text/javascript" src="//use.typekit.net/pxl2jwi.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>

See the Pen Typekit font import by Carlos Araya (@caraya) on CodePen.

The code above will only work for a single website, specified on the account where the kit was created from.

Google Fonts

Google Fonts allow you to embed fonts in one of three ways:

HTML Link in the head of your document along with your style sheets and scripts.

[codepen_embed height=”146″ theme_id=”2039″ slug_hash=”mdjnc” default_tab=”html”]
<link href='http://fonts.googleapis.com/css?family=Alegreya+Sans+SC:500,500italic|Exo+2:400,100,400italic' rel='stylesheet' type='text/css'>

See the Pen Google Fonts HTML Link by Carlos Araya (@caraya) on CodePen.

CSS Import from your CSS files.

[codepen_embed height=”150″ theme_id=”2039″ slug_hash=”CKdlu” default_tab=”css”]
@import url(http://fonts.googleapis.com/css?family=Alegreya+Sans+SC:500,500italic|Exo+2:400,100,400italic);


p>See the Pen Google Fonts CSS Import by Carlos Araya (@caraya) on CodePen.

Javascript import from within your scripts.

[codepen_embed height=”359″ theme_id=”2039″ slug_hash=”EtaHc” default_tab=”js”]
WebFontConfig = {
google: { families: [ 'Alegreya+Sans+SC:500,500italic:latin', 'Exo+2:400,100,400italic:latin' ] }
(function() {
var wf = document.createElement('script');
wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
wf.type = 'text/javascript';
wf.async = 'true';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(wf, s);

See the Pen Javascript Google Font Loading by Carlos Araya (@caraya) on CodePen.

One font does not fit all: Formats, details and workarounds

Using the following @font-face declarations we have taken care of the defaults for each @font-face declaration by making the bold and italic fonts actualy be bold and italics and, unless the font is actually condensed or stretched, make it explicit that it’s a normal font, not stretched or compressed (if we need to change this we can do it for specific elements).

Another issue to consider is that not all browsers support the same fonts (surprise, surprise). Internet Explorer supports Embedded Open Type fonts, Firefox prefers WOFF, Chrome, Safari and Opera prefer OTF (Open Type Font) or TTF (True Type Fonts) fonts and iOS prefers SVG (Scalable Vector Graphics) fonts.

I built the @font-face declarations below using Paul Irish Bulletproof @font-face syntax.

The original article is a little dated but it is still the best way to work with @font-face declarations on the web because it preserves the same font across all browsers and devices.

@font-face {
  font-family: "Your typeface";
  src: url("type/filename.eot");
  src: local("☺"),
    url("type/filename.woff") format("woff"),
    url("type/filename.otf") format("opentype"),
    url("type/filename.svg#filename") format("svg");
  font-weight: normal;
  font-style: nomal;
  font-stretch: normal;

@font-face {
  font-family: "Your bold typeface";
  src: url("type/filename-bold.eot");
  src: local("☺"),
    url("type/filename-bold.woff") format("woff"),
    url("type/filename-bold.otf") format("opentype"),
    url("type/filename-bold.svg#filename-bold") format("svg");
  font-weight: bold;
  font-style: nomal;
  font-stretch: normal;

@font-face {
  font-family: "Your italic typeface";
  src: url("type/filename-ital.eot");
  src: local("☺"),
    url("type/filename-ital.woff") format("woff"),
    url("type/filename-ital.otf") format("opentype"),
    url("type/filename-ital.svg#filename-ital") format("svg");
  font-weight: normal;
  font-style: italic;
  font-stretch: normal;

See the Pen Multiple @font-face assignments in a single CSS file by Carlos Araya (@caraya) on CodePen.

We can then fine tune our styles by setting properties for elements and selectors as needed. I usually start with setting up a default font and size/line height that will be carried throughout the document. I also provide a stack of backup fonts so that the browser will use the first font in the stack that is available to display the content, finally dalling back to one of the predefined font families (sans-serif, serif, fantasy, cursive, monospace)

[codepen_embed height=”257″ theme_id=”2039″ slug_hash=”tuaGn” default_tab=”css”]
html {
font-family: "Your typeface", Georgia, sans-serif;
font-size: 62.5%;
line-height: 1.5;

See the Pen Finetuning elemements with @font-face defined fonts by Carlos Araya (@caraya) on CodePen.

Fighting FOUT

The Flash of Unstyled Text is a phenomenon in Firefox and Opera that few web designers are fond of. When you apply a custom typeface via @font-face, there is a brief moment, when loading the page, where the font hasn’t been downloaded and applied yet, and the next font in the font-family stack is used. This causes a flash of a different (typically less good looking) font, before it gets upgraded.

Unless you’re designing for ancient browsers (Firefox 3.5 and 3.6 and Opera from th at same time period) FOUT shouldn’t be that big an issue anymore.

If you still need to account for that, you can follow the instructions fom Paul Irish

Styles and typographical elements


Once we have decided on what font stack we will use, we can create our general styles. For example, to create an Italic level 1 heading (<h1>) we could code it like this:

[codepen_embed height=”162″ theme_id=”2039″ slug_hash=”xyEwA” default_tab=”css”]
h1.italics {
font-family: "Your italic typeface", Georgia, sans-serif;
font-style: italic;

See the Pen Setting up italics fonts for H1 tag using @font-face defined fonts by Carlos Araya (@caraya) on CodePen.


If we need a bold text for some emphasis we can make our strong tags bolder by using something like:

[codepen_embed height=”143″ theme_id=”2039″ slug_hash=”DAsLt” default_tab=”css”]
h1.strong: {
font-weight: 700;

See the Pen Assiging bold weight with a @font-face defined font by Carlos Araya (@caraya) on CodePen.

In addition to the standard bold value, CSS allows us to use the value bolder and numerical values from 100 to 700. The differences may be subtle but they are important as seen in the example below:

Comparison between different font weights

See the Pen Comparison between numeric values of the font-weight property by Carlos Araya (@caraya) on CodePen.

The result of the rule above will depend either on available font faces within a font family or weights defined by the browser.


The text-decoration property has a set of predefined values that we can use deepnding on what visual result we want to accomplish. The valid values are:

  • underline
  • overline
  • line-through
  • none

One additional consideration is that we need to make sure to differentiate the page’s hyperlinks from the content that we choose to underline. Otherwise it’ll be confusing for our users when they try to click on underlined content and nothing happens. See the section on hyperlinks related pseudoclasses for more information.

.underline {text-decoration: underline;}

.overline {text-decoration: overline;}

.strikethrough {text-decoration: line-through;}

.none {text-decoration: none;}

Different types of Underlines using the CSS above

[codepen_embed height=”257″ theme_id=”2039″ slug_hash=”hylaK” default_tab=”result”]See the Pen Different styles of underline supported with the text-decoration CSS property by Carlos Araya (@caraya) on CodePen.[/codepen_embed]


The font-stretch property, available in CSS3, selects a normal, condensed or expanded face from a font. In order to see the result of the selection, the font being used has to have a face that matches the value given.

The font-stretch property will not work on just any font, but only on fonts that are designed with different faces matching the defined sizes and that is available on the user’s computer or loaded with a @face-font rule.

font-stretch accepts one of the following values:

  • ultra-condensed
  • extra-condensed
  • condensed
  • semi-condensed
  • normal
  • semi-expanded
  • expanded
  • extra-expanded
  • ultra-expanded

Example of font-stretch

.expanded {
    font-stretch: expanded;

[codepen_embed height=”145″ theme_id=”2039″ slug_hash=”fGDFw” default_tab=”result”]See the Pen Controlling front stretching using CSS by Carlos Araya (@caraya) on CodePen.[/codepen_embed]


The font-variant property allows you to change the targeted text to small caps. It is available in CSS2 and CSS3 with the later assigning additional values to the property.

The values available in CSS2 are:

  • normal (the default)
  • small-caps

CSS3 introduced additional values for this property that are dependenant on features from Open Type being available on the font we are using.

  • all-small-caps Enables display of small capitals for both upper and lowercase letters (OpenType features: c2sc, smcp)
  • petite-caps Enables display of petite capitals (OpenType feature: pcap)
  • all-petite-caps Enables display of petite capitals for both upper and lowercase letters (OpenType features: c2pc, pcap)
  • unicase Enables display of mixture of small capitals for uppercase letters with normal lowercase letters (OpenType feature: unic)
  • titling-caps Enables display of titling capitals (OpenType feature: titl). Uppercase letter glyphs are often designed for use with lowercase letters. When used in all uppercase titling sequences they can appear too strong. Titling capitals are designed specifically for this situation.

These are small caps


Other attributes we can work with

kerning and letter-spacing

In typography, kerning (less commonly mortising) is the process of adjusting the spacing between characters in a proportional font, usually to achieve a visually pleasing result. Kerning adjusts the space between individual letter forms, while tracking (letter-spacing) adjusts spacing uniformly over a range of characters.1 In a well-kerned font, the two-dimensional blank spaces between each pair of characters all have similar area.


The font-kerning property is supposed to provide optical kerning for the font being used. It is not widely supported (if at all). I’d suggest using letter-spacing instead. It may not have the same fine grained control Kenrning does but it’s better than nothing.

Letter spacing is more widely supported and allows you to control the spacing between letters in an element or class. Look at the example below.

p.narrow { letter-spacing: 0.4em }
p.wide {letter-spacing: 1.5em}


As the name implies text align controls the horizontal placement of text on the screen. There are 8 possible values, they are:

  • start: The same as left if direction is left-to-right and right if direction is right-to-left.
  • end: The same as right if direction is left-to-right and left if direction is right-to-left.
  • left: The inline contents are aligned to the left edge of the line box.
  • right: The inline contents are aligned to the right edge of the line box.
  • center: The inline contents are centered within the line box.
  • : The first occurrence of the one-char string is the element used for alignment. the keyword that follows or precedes it indicates how it is aligned. This allows to align numeric values on the decimal point, for instance. This property is not currently supported in any major browser.
  • justify: The text is justified. Text should line up their left and right edges to the left and right content edges of the paragraph.
  • match-parent: Similar to inherit with the difference that the value start and end are calculated according the parent’s direction and are replaced by the adequate left or right value. This is only supported in Chrome.


This property indicates hw far you push the first line of text from the starting border (depending on direction of the text). Additional values control whether the indent is a hanging indent and whether it applies to only the first line or the entire block of text.

  • Fixed value (i.e: 2em): Indentation is specified as a fixed value. Negative values are allowed
  • Percentage (i.e: 20%): Indentation is a percentage of the containing block width.
  • each-line: Indentation affects the first line of the block container as well as each line after a forced line break , but does not affect lines after a soft wrap break . Introduced in the CSS3 Text Module and not currently implemented in any major browser.
  • hanging: Inverts which lines are indented. All lines except the first line will be indented. Introduced in the CSS3 Text Module and not currently implemented in any major browser.


See Expressing Colors in CSS below

Some typography related pseudo classes

Hyperlink related pseudo classes

Although I wouldn’t recommend it we can make some drastic changes to the way links behave and look when they are clicked or after they are visited. The link seudo classes and what they control are:

  • :link controls the link when it’s not being used (there’s no user interaction)
  • :visited applies after the link has been clicked on
  • :hover applies when the mouse is hovering over the link
  • :active applies when the link is being clicked (the state after you over over the link but before it changes to visited)


p>In order to style appropriately links, you need to put the :hover rule after the :link and :visited rules but before the :active one, as defined by the LVHA-order: :link — :visited — :hover — :active.

a:link { color: #666666; text-decoration: none; } 
a:visited { color: #333333; } 
a:hover { text-decoration: underline; } 
a:active { color: #000000; }

[codepen_embed height=”110″ theme_id=”2039″ slug_hash=”bdFKE” default_tab=”result”]See the Pen Styling links with CSS by Carlos Araya (@caraya) on CodePen.[/codepen_embed]

::first-letter and ::first-line

The ::fisrt-letter pseudo class allows you to style the first letter of a paragraph or a chapter differently than the rest of the content. This is commonly used to create Drop Cap effects. We can limit what paragraphs get a drop cap by using the :first-child pseudo element like in the

div.dcexample p:first-child:first-letter {
  float: left;
  color: #903;
  font-size: 75px;
  line-height: 60px;
  padding-top: 4px;
  padding-right: 8px;
  padding-left: 3px;
  font-family: Georgia; }

[codepen_embed height=”316″ theme_id=”2039″ slug_hash=”bihyn” default_tab=”result”]See the Pen Styling First Letter of a Chapter using CSS :first-letter pseudo class by Carlos Araya (@caraya) on CodePen.[/codepen_embed]

::first-line does something similar but with the entire first line of the matching element. This matches when printed publiccations some times have a first line of a chapter in a slightly larger font than nthe rest of the text. In the example below we’ve set the text of the first line to 1.3 em.

div.flexample p:first-child:first-line {
  font-size: 1.3em;
  color: #666;

[codepen_embed height=”320″ theme_id=”2039″ slug_hash=”DbnIk” default_tab=”result”]See the Pen DbnIk by Carlos Araya (@caraya) on CodePen.[/codepen_embed]

Units of measuremet in CSS

CSS Units of Measurement

Expression colors in CSS

Expressing colors in CSS

Regions, Shapes and Exclusions

CSS regions, exclusions, shapes and new publishing paradigms

More stuff to play with: CSS Paged Media

paged media article

Typography doesn’t not replace the designer’s judgment

Links and Resources

CSS Units of Measurement

Defining Length

According to the W3C:

Lengths refer to distance measurements

The format of a length value (denoted by >length< in this specification) is a number (with or without a decimal point) immediately followed by a unit identifier (e.g., px, em, etc.). After a zero length, the unit identifier is optional.

Some properties allow negative length values, but this may complicate the formatting model and there may be implementation-specific limits. If a negative length value cannot be supported, it should be converted to the nearest value that can be supported.

If a negative length value is set on a property that does not allow negative length values, the declaration is ignored.


Absolute length (size) units`

Absolute length units are fixed in relation to each other. They are mainly useful when the output environment is known. Absolute values can be expressed in:

  • in: inches — 1in is equal to 2.54cm.
  • cm: centimeters
  • mm: millimeters
  • pt: points — the points used by CSS are equal to 1/72nd of 1in.
  • pc: picas — 1pc is equal to 12pt.
  • px: pixel units — 1px is equal to 0.75pt.

Or using one of the following pre-defined keywords

  • xx-small
  • small
  • medium
  • large
  • x-large
  • xx-large

Examples of absolute size values

h1 { margin: 0.5in }      /* inches  */
h2 { line-height: 3cm }   /* centimeters */
h3 { word-spacing: 4mm }  /* millimeters */
h4 { font-size: 12pt }    /* points */
h4 { font-size: 1pc }     /* picas */
p  { font-size: 12px }    /* px */

In the example above all elements will retain the assigned measurements, regardless of their parent or surrounding elements measurements.

Absolute size keywords are calculated by the User Agent (browser) and will be slightly different from one to another.

Relative length (size) units

Relative lengths and measurements are based on the computed-style of the current element. The only exception is font-size where the size is calculated based on the parent element

According to W3C:

Relative length units specify a length relative to another length property. Style sheets that use relative units can more easily scale from one output environment to another.


Relative units defined in CSS2 and CSS3

  • em: the ‘font-size’ of the relevant font
  • rem (root em): calculated based on the font-size of the root element
  • ex: the ‘x-height’ of the relevant font
  • percentages: a fraction of the parent element’s measurement

Any of the predefined keywords:

  • Larger
  • Smaller

Examples using em, ex and percentages

h1 { margin: 0.5em; }      /* em */
h1 { margin: 1ex; }        /* ex */
h1 { margin: 125%; }       /* percentage */ 

Examples using rem

html { font-size: 16px /* to make the example clearer */ } 
body { font-size: 1.5rem; } /* =24px */
h1   { font-size: 2.5rem; } /* =40px */