Creating CSS sprites

Creating and using CSS sprites is straightforward:

1. Merge images into a single image.

2. Create CSS styles that reference the appropriate sprite location.

3. Add HTML markup placeholders for the images.

Merging images

You can use your favorite image editor, such as GIMP or Photoshop, to merge images. Create a canvas large enough to house all the sprites, copy and paste each image, lay out the images in a logical order, and save. You’ll likely save the resulting image as a PNG (see Chapter 3 for selecting the right format).

$ convert edge.png chrome.gif firefox.png safari.png
  -append PNG8:browsers-sprite.png

Creating CSS styles

Once you have the single image created, the next step is to create the appropriate CSS styles. CSS sprites use the background-image and background-position properties to move the image out of the viewable area. These attributes have existed since 1996 in CSS1 and have nearly ubiquitous browser support.

a.icon {
  display:inline-block;
  text-indent: -9999px;
}
.icon {
  background-image: url('/images/browsers-sprite.png[]');
  background-repeat: no-repeat;
  height: 128px;
  width: 128px;
}
.icon-facebook {
  background-position: 0px 0px;
}

.icon-twitter {
  background-position: 0px -128px;
}

.icon-linkedin {
  background-position: 0px -256px;
}

.icon-googleplus {
  background-position: 0px -384px;
}

A quick checklist for the styles:

• Keep track of the relative position (-x, -y) of each sprite on the canvas.

• Specify the width and height of the viewable sprite to avoid visual gaffes.

• Use one style per sprite to avoid overlap.

• Update all the relative positions if you change the sprite.

Adding HTML markup

For each location where you will use the sprite you will need a corresponding HTML element that supports background styling. You’ll have to use a blocking element, which in most cases means you’ll use a <div> or <span> instead of <img>. The HTML markup is usually the part that grates on most purists because it requires you to mix presentation with content.

<a class="icon icon-edge"
href="https://www.microsoft.com/en-ca/windows/microsoft-edge">
    Microsoft Edge
</a>
<a class="icon icon-chrome" href="https://www.google.com/chrome/">
    Chrome
</a>
<a class="icon icon-firefox" href="https://www.mozilla.org/en-US/firefox/new/">
    Firefox
</a>
<a class="icon icon-safari" href="http://www.apple.com/safari/">
    Safari
</a>

In this example we have made the social media links clickable while also making them accessible for anyone using a screen reader.

Automating to avoid image and link rot

Clearly, creating sprites by hand isn’t ideal. In fact, the biggest risk of manually creating sprites is image rot—images that are no longer being used but are still included in the sprite. The worst case is when the same image is included multiple times but at slightly different sizes.

If you are manually creating the sprite, then you will either need to revisit all the old references, or just blindly add a new image to the bottom of the existing sprite. The latter is the path of least resistance. Unfortunately, this will result in an ever-growing sprite canvas. Consider the pain and suffering of having to refactor all your CSS after your CEO discovers that the site is slow because of a 1 MB sprite (… not that this has actually happened to anyone I know).

Fortunately, there are many tools available to help automate the creation and referencing of sprites. Usually, the first approach is to do a global search and replace on HTML and CSS files. Don’t do that. It is painful and will be fraught with problems. You shouldn’t underestimate the creativity of your marketing team.

The better approach is to automate the creation of sprites and CSS styles. Clearly define the style-naming convention with your creative teams. Follow this up by removing all GIF/PNG/JPG files during your deployment process and monitor for broken links to find offenders.

Many frameworks now have automated mechanisms to create sprites. If you are starting from scratch, I suggest using Sprity. Sprity is very extensible and can plug into your existing styling frameworks (SCSS/Less) and build automation systems (Grunt/Gulp), but can also be plumbed into an existing deployment script.

For example, we can simplify our output with this command line to create both out/sprite.png and out/browsers.css files:

$ sprity out/ images/*.png -s browsers.css

The Sprity default creates styles prefixed with icon- which, fortuitously, matches our preceding example.

Drawbacks and shortcomings

While CSS sprites do provide broad browser support and are well understood, it isn’t all unicorns and rainbows. There are many rough edges in this technique.

Operationally:

• Global sprites versus local sprites: should you create one global sprite but have many of the icons unused in a page, or have one sprite per page but have duplication?

• Large sprites need to partitioned. Sprites shouldn’t be larger than 10 packets (~40 KB). Use partitioning schemes to manage growth.

• Cache invalidation—any change will cause the sprite to be invalid and render downstream caches moot. You will certainly need to version your sprites and force the end user to download the new sprite, even if 90% of the icons haven’t changed.

• You must be vigilant about ensuring that unsprited references to small images don’t creep into the system.

• Chicken and egg: sprite first or style first? Sprites must be created first before creative teams can style a page and decide if the sprite is good enough. Iterating on an icon is burdensome.

Stylistically:

• Images can’t be styled. You must manually implement CSS properties, like shadows, coloring, and underlining, by creating yet another image and sprite.

• Different sizes and layouts also require different image sprite sets.

• Animated PNG/GIF/WebP files can’t be included in a sprite (though arguably they are likely not small images).

• Sprites mix presentation and content by injecting HTML.

Considerations

As you would expect, there are caveats to consider when you are utilizing a data URI.

Increased size

The biggest objection to using data URIs is the bloat from base64-encoding the binary. Base64 will increase the raw byte size by ~35%. Fortunately, Gzip will reduce the contents between 3% and 37%. (Using Brotli you could get this down even further.) Overall most images will have no larger net size when transferred. (Though note that really small images can see some increases in size because of the headers required.)

Figures 10-8 and 10-9 again utilize the study of the top 1 million images, this time converted using Base64 and then Base64 with Gzip, respectively. The locus of the results shows a net decrease in byte size after inlining.

Figure 10-8. Base64 only: image width versus % increase size from base64

Figure 10-9. Base64 then Gzip: image width versus % increase size from base64/Gzip

Browser support

Unfortunately, data URIs are an advent of modern browsers. For those prior to IE8 you’ll need to have a non-inlined version of your CSS that references the images directly. IE8 also has an artificial limit of 32 K of encoded URIs. You can use the Internet Explorer conditional comment to add the correct CSS:

<!--[if lte IE 8]>
<style href="ie-noinlining.css />
<![endif]-->

Request blocking

The real problem with inlining is that the images have effectively moved up in priority and the transfer of the image is now blocking the transfer of other critical resources. As we have previously discussed, images are generally low priority, so by inlining them with data URIs we give the image an effective high priority because it is transferred at the time of the HTML or CSS.

Processing time

Further complicating the issue is that the decode process takes additional CPU and memory. One study by Peter McLachlan at Mobify found that “when measuring the performance of hundreds of thousands of mobile page views, loading images using a data URI is on average 6x slower than using a binary source link such as an <img> tag with an src attribute!”

While this is something that can be optimized over time in modern browsers, the use of data URIs can slow the loading and processing of the file. If you embedded all images in the HTML, resulting in an uncompressed doubling, it would impact the time to compute the DOM or calculate styles.

Caching and CSP

As with sprites, changes to images require caches to be invalidated. Unlike with spriting, though, the impact isn’t localized to a single image; it now requires the encapsulating CSS and HTML to be versioned or invalidated from the cache. If only an icon changes, then the entire page must be redownloaded.

Likewise, if your site employs a content security policy (CSP), the base64 or digest hash will need to be updated. Using inline images creates an ecosystem change.

Better: Deferred data URI stylesheet

If you are concerned about blocking the critical rendering path by inlining images in the HTML and CSS, another approach is to use an asynchronous CSS stylesheet.

1. Replace CSS background properties to remove the url() reference. You can replace it with a solid color #ffffff or even with a 1×1 inline pixel so as not to minimize the stylesheet differences:

   .myclass {
     width: 123px;
     height: 456px;
     background: #ffffff no-repeat
   }

2. Create a new CSS stylesheet (we will call it images.css) with just the CSS selector and real background properties that include url('data:images/ ...') with inline source for the actual content:

   .myclass {
     background-image: url('data:image/gif;base64, ... ')
   }

3. Defer the loading of images.css with the following JavaScript (courtesy of Scott Jehl’s loadCSS.js (https://github.com/filamentgroup/loadCSS):

<script>
  // include loadCSS here...
(function(w){
	"use strict";
	var loadCSS = function( href, media ){
		var doc = w.document;
		var ss = doc.createElement( "link" );
		var refs = ( doc.body || doc.getElementsByTagName( "head"
		             )[ 0 ] ).childNodes;
		var ref = refs[ refs.length - 1];

		var sheets = doc.styleSheets;
		ss.rel = "stylesheet";
		ss.href = href;
		// temporarily set media to something inapplicable to ensure
		// it'll fetch without blocking render
		ss.media = "only x";

		var onloadcssdefined = function( cb ){
			var resolvedHref = ss.href;
			var i = sheets.length;
			while( i-- ){
				if( sheets[ i ].href === resolvedHref ){
					return cb();
				}
			}
			setTimeout(function() {
				onloadcssdefined( cb );
			});
		};

		// once loaded, set link's media back to `all` so that the
		// stylesheet applies once it loads
		ss.onloadcssdefined = onloadcssdefined;
		onloadcssdefined(function() {
			ss.media ="all";
		});
		return ss;
	};
	// commonjs
	if( typeof module !== "undefined" ){
		module.exports = loadCSS;
	}
	else {
		w.loadCSS = loadCSS;
	}
}( typeof global !== "undefined" ? global : this ));

  // load a file
  loadCSS( "/images.css" );
</script>

<noscript><link href="/images.css" rel="stylesheet"></noscript>

<!--[if lte IE 8]>
<style href="ie-noinlining-images.css />
<![endif]-->

The net result will be a combined CSS with just the inlined images. This combined CSS is loaded asynchronously (don’t forget to include the legacy fallback for IE 5–8). All of the inlined images will have two distinct benefits:

• Total bytes are reduced via Gzip to 1–3% less than even the original total bytes.

• Images will avoid being manipulated by intermediate proxies that can recompress images and distort images for mobile users (we will discuss this in Chapter 13).

Tools

There are many tools options to help you create inline images with different approaches.

• You can use automated frontend optimization services, such as PageSpeed for Apache, NginX, and IIS. Many content delivery networks (CDNs) also include this service as part of their value-add delivery.

• Build tools into your development workflow. Compass can automate the creation in your SCSS/SASS stylesheets. Grunt tasks, like grunt-data-uri, can also examine existing CSS and transform the content automatically ahead of deployment to production.

• Roll your own tools. You can use the base64 command on most Linux systems or use the base64() equivalent function in most languages.

Overview

There are two approaches to utilizing web fonts:

• Single-character replacement: Create the new HTML entity &#broccoli; with the image seen in Figure 10-10.

  

  Figure 10-10. Image to create new HTML entity

  These images can be referenced by decimal position or defined colloquial name. Existing characters can also be replaced.

• Typographic ligatures: this is essentially the same as a single-character replacement but has some additional usability benefits. Instead of a single-character replacement, you can do multiple-character replacement to replace a whole word with an icon. For example, the word love can be replaced with the ♥ character. In this way, “I love broccoli” will be rendered “I ♥ broccoli.”

Additionally, icon fonts can be styled with CSS just like any other text. This includes color adjustments, shading, shape, rotation, and even font styles like bold and italic. Adding CSS styles to font icons provides you with flexibility and eliminates the need to regenerate from source when applying subtle aesthetic changes.

Creating and using icon web fonts

Assembling an icon font is fairly straightforward. You can assemble a new icon font by using existing web fonts or, using SVG images as source, by defining character mapping and converting to the various web font formats. The trickier part is ensuring cross-browser support, fallback, and accessibility.

Fortunately, you don’t have to build your icon web font from scratch. There are many font libraries ready for use, many of which can be reassembled into purpose-built web fonts. IcoMoo, SymbolSet, Font Squirrel, and Pictos are just some of the many sites that can assemble, create, and host icon fonts. (We’ll discuss hosting and performance shortly.)

If you’re using images for Asian characters, this is the best place to start to build a logographic typeface.

There are many tools for type designers and typographic experts to create custom web fonts. This includes FontLab Studio, FontForge, and many others. However, for custom icon web fonts this may involve a lot more complication and is not necessarily scalable for use with your creative teams.

There are also a number of tools that can help you automate the process of creating web fonts and avoid the manual design process. Typically these tools start with SVG images, transform them into the custom font, and provide the appropriate character mapping. The typical workflow starts with SVG images, converts to an SVG font, and then converts that font to the other web font formats, such as TTF, EOT, WOFF, and WOFF2. Alternatively, there are also Grunt and Gulp tasks (such as grunt-webfont or gulp-iconfont) that wrap up these individual steps into a single task, making it easier to automate the process.

To demonstrate this workflow we will use the following libraries:

1. SVG images >> SVG font

2. SVG font >> TTF font

3. TTF font >> EOT font

4. TTF font >> WOFF

5. TTF font >> WOFF2

There are a number of other libraries that are also useful for this process that we won’t explore, specifically:

• SVG Optimizer, which reduces the redundant information and helps collapse the code paths.

• TTFAutoHint, which can help improve rendering of fonts, particularly in Windows, for maximum readability.

Using the same browser logos we used when creating the CSS sprite we can combine them into a web font. This time we will start with SVG representations. Our folder /images contains the following SVGs, as shown in Figure 10-11.

• images/safari.svg

• images/firefox.svg

• images/u0065-edge.svg

• images/u0063,u0063u0068u0072u006fu006du0065-chrome.svg

Figure 10-11. SVG browser icons

Invoking the conversion to create the SVG font (fonts/browsers.svg) is fairly straightforward. This will create the root font we will use to convert to the other web font formats. It is also the step where the character mapping, ligature creation, and colloquial glyph naming occurs. In this example, the filename will also provide hints for character mapping for the Edge and Chrome logo. The letter e will be replaced with the Edge logo or the ligature chrome will be replaced with the Chrome logo.

$ svgicons2svgfont --fontname=browsersfont -s uEA01 
  -o fonts/browsers.svg images/*.svg

Likewise, converting to TTF, EOT, WOFF, and WOFF2 can be accomplished thusly:

$ svg2ttf fonts/browsers.svg fonts/browsers.ttf
$ ttf2eot fonts/browsers.ttf fonts/browsers.eot
$ ttf2woff fonts/browsers.ttf fonts/browsers.woff
$ ttf2woff2 fonts/browsers.ttf fonts/browsers.woff2

Utilizing the newly created web font is now as easy as adding the font declaration and associated HTML:

<span class="icon icon-safari"></span>
<span class="icon icon-firefox"></span>
<span class="icon icon-edge"></span>
<span class="icon icon-chrome">chrome</span>

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

.icon {
    font-family: 'browsersfont' !important;

    font-feature-settings: "liga"; /* enable ligatures */
}

.icon-safari:before {
    content: "ea01";
}
.icon-firefox:before {
    content: "ea02";
}
.icon-edge:before {
    content: "65";
}
.icon-chrome:before {
    content: "63";
}

Since we have created an icon font with only the icons, only a limited number of characters can be rendered. Any additional text that is caught in the CSS style that is not defined may render oddly with different browsers. For example, if you have the text edge, only the letter e will display and the following characters may have empty boxes. Be careful to scope icon fonts appropriately.

In this example we have enabled ligatures using the CSS property. However, a more comprehensive style would include:

.icon {
    font-family: 'browsersfont' !important;

    /* Ligature support */
    letter-spacing: 0;
    -webkit-font-feature-settings: "liga";
    -moz-font-feature-settings: "liga=1";
    -moz-font-feature-settings: "liga";
    -ms-font-feature-settings: "liga" 1;
    -o-font-feature-settings: "liga";
    font-feature-settings: "liga";
}

As previously mentioned, using Gulp or Grunt tasks can simplify these steps and combine them into a single action. Both tasks will also generate the necessary CSS and mapping to further reduce rendering errors.

Compatibility

Unfortunately, web font support across the browser spectrum is very fragmented (see Figure 10-13). There isn’t a single universal format that is supported by all browsers. While modern browsers have rallied around WOFF and WOFF2, older browsers support a myriad of formats, including EOT, TTF, and SVG. Worse yet, most proxy browsers, including Opera Mini, do not support any web fonts, so fallback is always important.

Figure 10-13. Browser support for @font-face with web fonts from CanIUse.com (2016)

Each browser also loads fonts differently, resulting in a variety of rendering experiences for users. Of particular note is the dreaded Flash of Unstyled Text (FOUT). For example, Internet Explorer will display the text in an alternate font until the web font is available. This is OK if you have appropriate fallback characters, but it will display empty boxes if you’re using PUA character mapping.

In contrast, Safari will hide the text until the custom font is available and display it only after the font is loaded. Finally, Chrome and Firefox will wait up to 3 seconds and use the fallback font, repainting after the font is available. This Flash of Invisible Text (FOIT) is probably worse from a user experience perspective—especially if the user is on a poor network connection.

Most browsers also load fonts asynchronously with the exception of Internet Explorer. The result is that the icon images can be displayed later and prolong the FOUT period while the fonts are loaded. For smaller icon fonts, inlining the font with a data URI can be more efficient. Unfortunately, because of the multiple font formats, you will also need to inline the different font files even if they aren’t being used.

To work around this, you can use adaptive delivery for your CSS and detect, server side, the browser and version and deliver a specific CSS file with the appropriate inlined font file. (For more details, see Chapter 13.)

While the hoops to generate font files for vector images might seem arduous, the real benefit is bringing accessibility for your website and images, as well as a convenient encapsulation to bring vector images to legacy browsers.

Web font pros and cons

While icon fonts are a convenient and durable mechanism to consolidate small vector images, there are many drawbacks. Most notable is the outright lack of support by some browsers—specifically, the lack of support by proxy browsers like Opera Mini. There are also various CSS and rendering nuances in different browsers and operating systems that need to be accounted for and tested. This includes CSS tricks like including !important to avoid browser extension issues and explicitly enabling font smoothing using -webkit-font-smoothing: antialiased and -moz-osx-font-smoothing: grayscale—not to mention issues of alignment, spacing, and churning.

On the other hand, web icon fonts can be good for text, specifically to augment existing text (using ligatures) or logographic content.

SVG fragment identifier links

Often it’s easier to use a common, colloquial name, instead of remembering the coordinates on the canvas. Since SVG is XML, most elements can be marked with a fragment identifier or id attribute. For example, we could define our icon in a <symbol> (which won’t be visible until it is displayed):

<svg>
    <symbol id="chrome-logo"> <!-- ... --> </symbol>
</svg>

You can use fragment identifiers in SVG in many ways. Just as in HTML you can apply specific CSS styling to different nodes by referencing the id. You can also use it as a template for repeat use: you can reference the id in a use block multiple times (for example, drawing leaves on a tree). The identifier link can reference whole other files or a definition in the same file. You name the identifier at the end of the URL after the hash symbol, just as you would with HTML fragment identifiers:

<svg viewBox="0 0 100 200">
    <defs>
        <g id="firefox-logo"> <!-- ... --> </g>
    </defs>

    <use xlink:href="#firefox-logo"></use>
    <use xlink:href="images/browsers.svg#edge-logo"></use>
</svg>

In this example we place two SVG images on our canvas: one internally referenced symbol and another external. For completeness you can see how we reference both a symbol and a group (<g>). The group is wrapped in a defs block to ensure that it doesn’t display until referenced. Hiding the fragment isn’t required; it is convenient. We could always reference the first use of a template. However, it is better practice to define your templates separately. Doing so also solves a particular bug in some browsers (noteably Safari) where references must be defined before they’re used.

For SVG spriting, we can use the fragment identifier to reference a specific image in a single consolidated SVG. This way we can ignore the location on the canvas:

<img src="images/browsers.svg#firefox-logo" />

It would be tempting to wrap all of our SVGs in <symbol> elements and add the id attribute. Boom. Done. Unfortunately, we would have two problems:

• <symbol> and <defs> aren’t visible. Externally referencing them in your HTML or CSS would likewise draw nothing since the canvas is empty.

• Browser support for referencing fragment identifiers inside an SVG is spotty—but we can work around these issues.

Fragment identifiers and viewBox

To use SVG sprites, we need to provide instruction on how to draw the vector on a canvas. Adding a viewBox attribute provides this detail. Just as we need to consider the viewBox in relation to the viewport when we display the entire SVG, we also need to specify how much of the fragment is displayed so that it can be stretched appropriately inside the referencing HTML node.

You can define the viewBox a few ways:

• Add viewBox in the URL as you would a fragment identifier: browsers.svg#svgView(viewBox(0, 0, 256, 256)). Unfortunately, while Firefox, Internet Explorer, and Edge get it right, Chrome (until 40) and Safari have problems with this approach. It is also only slightly better than using the traditional CSS approach because you need to maintain the coordinate references.

• Use an inline SVG block with a reference to the fragment identifier as follows:

  <svg viewBox="0 0 100 200">
    <use xlink:href="images/browsers.svg#safari-logo"></use>
  </svg>

  This is better but it is odd to require an SVG in order to reference an SVG sprite.

• Define a <view> in the SVG and use that reference. As we mentioned, <g> does not support viewBox and <symbol> is hidden, but a <view> can merge use cases and expose a fragment identifier:

  <svg>
      <view viewBox="0 0 100 200" id="firefox-logo">
          <!-- ... -->
      </view>
  </svg>

  Now referencing the fragment in your HTML will behave as you expect and you’ll be able to style not only the HTML container, but also the SVG elements inside. The only remaining challenge is browser support. Again, not all browsers are created equally and using an <img> with a reference to the SVG + fragment identifier poses problems for Safari. We can more universally get around this by using an <object> tag instead:

  <object data="images/browsers.svg#safari-logo" type="image/svg+xml"/>

Using this approach will allow you to use both fragment identifiers and consolidate SVGs to all browsers that support SVG. We still need to support older browsers by using raster sprites as a fallback.

Automating SVG consolidation and fallback

Just as with raster sprites, we can automate the creation of SVG sprites to avoid image rot and duplication. There are several libraries that can be used with Grunt and Gulp wrappers. For example, Joschi Kuphal’s svg-sprite works well:

$ svg-sprite --view -D out/ images/*.svg

This will generate a consolidated SVG as we would expect with a <view> wrapper and a fragment identifier using the filename:

<svg>
    <view viewBox="0 0 100 200" id="browsers-firefox-logo">
        ...
    </view>
</svg>

You can also use this tool if you want to generate an SVG that uses conventional CSS spriting. This will produce a stylesheet with the coordinates on the consolidated SVG:

$ svg-sprite -css --ccss -D out/ images/*.svg

Legacy support is nearly not an issue. However, there are still many users trapped on devices and browsers with IE <9, Android <5, or iOS <7. You can support them in a few ways:

• If you use the CSS style spriting, you can use device detection and return different stylesheets based on the browser support. (Unfortunately, you can’t use detection examining the Accepts: header.) In this way you would serve /sprites.css to almost all browsers, with the exception that you use a raster-sprited view in /sprites-raster.css. This would require generating raster images and spriting them as well. Wrapper tools like Iconizr can make this easy.

• If you are using <object>, add a fallback to CSS spriting and use a <div> tag inside:

  <object data="images/browsers.svg#safari-logo" type="image/svg+xml">
      <div style="no-svg icon-safari-logo"/>
  </object>

• Do nothing; let the browser show or hide the output. This isn’t a terrible solution because these legacy browsers are usually running low-powered hardware. Displaying nothing will improve the experience without forcing more overhead.