Elastic Design

It can be difficult to move from a static, pixel-based design approach to an elastic, relative method. Properly implemented, however, elastic design can be a viable option that enhances usability and accessibility without mandating design sacrifices.

A pixel is an unscalable dot on a computer screen, whereas an em is a square of its font size. Because font sizes vary, the em is a relative unit that responds to users’ text-size preferences.

It is perhaps easier to adopt a print-like, static approach to design because there is less to think about when dimensions don’t change. To employ an elastic approach, however, is to fully exploit the capabilities of computer displays and web browsers.

You may want your website to display in a specific way, but your users may want it another way. Enforcing anything on a user is bad for usability and therefore detrimental to the success of the website.

To understand how Elastic Design works, we must first take another look at a subject that would seem to be played out: namely, different methods of text sizing. Once we find a way to make the web safe for resizable text, we can move on to layout techniques that exploit it.

Elastic text#section2

Text is the most obvious candiate for elasticity. The ability to set a text-size preference is a commonly used option that shouldn’t be ignored.

Accessibility isn’t all about blindness and screen readers. There are many more people who are not blind but do have impaired vision — a group that will one day include most of us as we grow older. One of the simplest ways to make a website more accessible is to allow users to change the size of the text; to deny this option takes away user control and quite possibly prevents the user from reading content comfortably.

If a designer uses a unit like pixels to define font size, a majority of users won’t be able to scale the text because Internet Explorer for Windows does not increase text size in the same way as some other browsers. Whereas Mozilla and Opera will scale text that is set using pixels, IE Windows will not.

The problem with ems#section3

Ems would appear to be the unit of choice when it comes to relative text sizing. The default height of text in a browser is generally 16 pixels, which is too large for most designers’ tastes. To use ems, designers typically set the initial value to something smaller than 1em.

For example:

body {font-size: 0.8em;}
h1 {font-size: 2em;}
p {font-size: 1em;}

Sounds good in principle, but there’s a problem — if you set the "text-size" setting in Internet Explorer to "smaller" or "smallest," the text becomes so small it is unreadable. As Internet Explorer is so popular and the "smaller" text-size setting is a popular one, ems do not appear to be a valid option.

Jeffrey Zeldman has argued in the past that pixels, while problematic, are a better unit than ems to specify the size of text. He draws upon the extensive research of Owen Briggs, who tested 264 different text sizing methods and demonstrated that relative units such as ems don’t work. Many designers now employ the pixel as a unit of defining text size, not for absolute pixel-perfect control over the look of their web pages, but because there appears to be no sensible alternative.

So it would appear that we are stuck with either unpleasantly large or unfortunately unscalable text. But read on.

The "big text" alternative style#section4

Many authors combat the accessibility problem of non-resizable pixels by including an option to increase text size on their pages using an alternative stylesheet that can be activated from a link on the web page.

This is a good accessibility tool, but one that would be much better if used in conjunction with relatively sized text (as on the Wired News site). You shouldn’t expect a user to be familiar with your specific interface. Users are typically more familiar with interface of their browser, and if they want bigger text, they are more likely to try change it via their browser than via your interface. Furthermore, they will probably expect this setting to work across all web sites and shouldn’t be expected to change the settings of every website they visit.

CSS keywords#section5

Font-size keywords (xx-small, medium, x-large, etc.) appear to be the answer. Font sizes increase if the user selects "larger" or "largest" in IE and will decrease if they select "smaller" or "smallest"…up to a point. The main benefits of keywords, other than their elasticity, is that text sized using keywords will never have an actual pixel-size below a certain point, so it should always be readable no matter what text-size option the user selects.

Keywords are covered in more detail elsewhere on ALA and perhaps the best demonstration of this approach is the site you’re looking at right now. (Before the latest redesign, ALA had an alternate "Bigger text" style switcher, with one style using pixel-based type sizes and the other using relative, keyword-based sizes.)

Percentages prove ems work#section6

Ems work because the miniscule-text problem can be overcome easily by setting the initial font size to a percentage. There is no apparent reason for this to work, but it does. When this solution is implemented, the leaps between the IE text-size settings do not appear to be as drastic, and designers can set a sensible initial text size that will resize to a readable size at "smaller" and "smallest" settings. This puts ems back in the ring. (Even a certain Mr. Briggs now prefers ems.)

For example:

body {font-size: 80%;}
h1 {font-size: 2em;}
p {font-size: 1em;}

The benefit of using ems over keywords is that you can use ems to define the dimensions of your entire layout, which will then scale in proportion to the text.

Elastic layout#section7

Perhaps more difficult than elastic type for a designer to get his or her head around is the completely relative layout — but it is quite feasible to set the dimensions of a layout in ems.

Elasticising a layout so that its size will change when a user explicitly opts to change text size may seem unnecessary and even unwanted, but if you have text that can be expanded and contracted, it can make sense for the layout in which it is contained to expand and contract accordingly.

Additionally, if a user chooses to display text in a larger size, the amount of spacing around it should expand proportionally, maintaining the designer’s chosen proportions and keeping the text easy to read.

Another benefit of this approach is that it prevents undesirable text wrapping. If a narrow column’s width is defined in pixels, it can break (and throw off the entire layout) if any text contained within it grows. This problem is solved by defining the column in proportion to the text.

For a working example of this approach, see the Elastic Lawn design in the CSS Zen Garden.

Too wide!#section8

After defining the initial font-size of a page to 100%, a width of 36ems should result in a width of 576 pixels (as a point of reference, ALA has a width of 600 pixels) on the "medium" text setting of Internet Explorer. This 36ems increases to 768 pixels on the "largest" setting (tested on IE 6 for Windows). Using anything much larger than this will result in something too wide, at the "largest" text setting, to display on an 800 pixel wide screen.

CSS has a solution for this: the max-width property, which could be used to specify a maximum width for an element. Unfortunately (who would have thought?) Internet Explorer doesn’t support it.

The other solution is to use a liquid layout in which the width of the content area isn’t specified at all so that the text flows to fit to the width of the screen (HTML Dog uses this solution). Many would argue that this renders the content less readable on large displays, but it is beneficial for smaller displays such as those on mobile devices.

If you opt for the elastic layout approach, there may still be a need for the pixel unit in defining borders or pixel-constructed objects such as bitmap images, which can cause a problem with size-based relationships; but then there’s nothing stopping you from elasticising them as well.

Elasticizing images#section9

Setting the size of bitmapped images relatively can result in aesthetic disaster, but there is another way of dealing with images — by maintaining the intended resolution of the image itself but clipping it to the desired dimensions.

This can be done with a background image replacement. Here’s an example using a heading element — one might use a number of other image replacement techniques:

h1 {
	font-size: 1em;
	width: 10em;
	height: 100px;
	text-indent: -1234em;
	background-image: url(whatever.jpg);
}

Or (as at hebig.org and v-2.org) it can be done with an img element within a containing element such as a div that has the following CSS:

div {
	width: 10em;
	overflow: hidden;
}

Many of the elastic design methods that are covered in this article may be viewed on my demonstration page.