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.
Jefferis Peterson wrote:
>>>
It seemed like you reversed your self twice in mid article between using ems, using pxs, and going back to ems
<<< He was just retelling the history of font sizing methods. Em sizes COULD have been used on their own, except that IE/Win has a bug that makes em-sized text too small to read when the user sets the font size to less than medium. HOWEVER, the only thing you have to do is to set the font size in percents for the BODY element, and then you can use ems in all of the rest of the document, and it will work perfectly in IE. Or you could just set all font sizes in %. 100% = 1em, after all. >>>
I get the feeling I should just use px for another year and wait till this whole thing just gets sorted out and the developer tools catch up with some kind of decision.
<<< My opinion is still: Do NOT use pixels for setting font sizes. Use a combination of % and em, OR keywords, OR don't set font sizes at all. >>>
It would seem that if M$ would just cooperate, we could all use px and be done with it.
<<< But that's not the goal we should be heading for. The goal we should be heading for is to give each user exactly what he/she wants. We're never going to reach that goal, but that's no reason to stop trying.
Peterman wrote:
<<< Pixel cons: - Suboptimal font sizes for those who don't have the same taste and eyesight as the designer. >>>
But, in a proper browser, the user can adjust fonts “on the fly” to their desired taste.
<<< - Does not allow users of IE to change the font size from site to site. (You might say that they could just use e.g. !important, but even assuming users know how to do that, they might only have trouble reading a FEW sites, and might have no desire to override ALL sites' settings because of this.) >>>
The crux of the matter. IMHO If this is a problem for IE users they can abandon their browser in favour of a modern one. Simple (in theory).
<<< Em/percent pros: + Provided it's sensible (like, never smaller than 0.8em/80%), and provided that users who set default sizes realize that the default size should be a BIT bigger than "just about readable without squinting", it should be CLOSE to optimal (VERY close or even spot on for a lot), no matter if the users prefer 10px or 100px text, no matter if they've set a default size or not, without any modifications from site to site. >>>
Well, if the user prefers 10px, it will come out as 8px on an 80% site. They may be physically capable to read that size text but computers cannot always be relied upon to display it at that size. Too many provisions here IMHO for this to work as intended.
<<< So, my opinion is still that no method of font sizing is perfect, but today, ems/percents (or keywords, for that matter) come the closest, with default sizes a close second. >>>
I disagree but thank you anyway for considering things from my perspective. Overall though it is a good analysis of the trade-offs for each method. In the end, do what you think is best for your visitors.
Great comments and info. I find that most users who need text to be larger because of slight issues, etc, understand that you can change your browsers resolution even if designers used fixed px values (as I do, sorry…I am evil). Also, Windows (95% users) allows you to globablly change type sizes through-out the OS, no matter what you set your test values to.
Like print design, web design does need to consider some basic rules of typography. Line length for instance. I hate fluid pages bacause you get 20-30 word line lengths on larger monitor settings (if you adjust the browser). This is not good typography and is very hard to read. I prefer to set the width and center the page (as this site does) to make up for larger res settings.
finally, users tend to “print” long text pages (more than two or three window scrolls). I do for sure. I hate reading long text on screen. Even with LCD flat monitor, etc., it is a strain. And again to typography: it is easier to read san serif type on screen and serif type in print (don’t ask me why), so I tend to offer print-formatted pages if possible.
Thanks!
This is the first article I’ve read covering the very important subject of making the text and the page scalable, and having the page scale with the text.
That’s exactly what I did with my site, I set the font sizes with keywords (small, medium, large, etc.), and set the dimensions of the containers in em so it would scale with the text.
That worked great, but I still had a problem. I need some graphics that I had on the front page menu to scale with the text so they wouldn’t interfere with a small display. I thought of something I was sure wouldn’t work, but it did, just not in IE. 😛
I set the width and height of the images in em, and got it close, but on the large side of correct. Then I set a max-width and max-height in pixels that matched the regular size of the images. This allowed the graphics to get smaller, but not go past full size. It worked perfectly until I tried it in Windows in IE 6. IE 6 ignores the max-width and max-height.
I left the graphics anyway, and did one of my picture gallerys for a sample. You can check it out at my site. If M$ would get it’s act together this would be a great solution for making the entire site scalable.
If I am sight impaired and site after site does not resize with the “text-size” option, wouldn’t I investigate another browser? It seems to me you should stop catering to this browser, no matter how popular it is. Curious as to what the pros think about this. Thanks for all the info, “A List Apart” is amazing.
I have used 80% font size for
in a style sheet and 0.8 em foron a couple of different websites and it seems to work well. However, although I have read the Owen Briggs article a few times, I am still puzzled about the effect of the % value for
. If I change this % value, it seems to have little effect on text sizes. In fact I omitted it in one style sheet – and changed IE text settings and there was no effect. Can someone explain why setting % in is important ? I have obviously missed something here.I meant when using the Owen Briggs method in conjunction with tables for layout (I know tables are a bad thing – but they are still used)
The technique presented here doesn’t work in all browsers as is says it does since some browsers (on some platforms) do not default to 16px, although they do default to 16pt. 16pt==16px iff the screen resolution is 72dpi, which it almost never is.
Most browsers just assume this to be the case, and so it works. But, Mozilla and Konqueror on Linux do not work as they appear to take there DPI from X, which sets it correctly.
The answer to this problem is:
html
{
font-size:16px;
}
body
{
font-size:X%;
}
h1
{
2em;
}
… etc
Hope that helps anyone who runs into problems on Linux.
I really enjoyed this article, and found it to be a great choice in designing your pages for great accessibility. My only question would be how do you handle image maps when you want your image to scale as well? I realize if the image remains the same size in pixels this isn’t a problem. But when you specify an image’s dimensions in terms of em, is there any way to get an image map to scale with the picture?
Any feedback on this would be greatly appreciated!
Good article, though a little light on actual layout side of things.
One thing I have been thinking about it is, wouldn’t using a combination of ems (for say margins and padding) and pixels (for the borders) make implementing the box model hack for IE5 a real pain?
If you used all ems or all pixels for a box it would easy to work out fake width and height values you need to feed IE5 but not if you used a mixture or do I have this all wrong?
When in doubt, take a look at the source. The anchor tag has a background image of a dotted underline. The a:hover has switches that to an animated version. Quite a nice effect if a little extraneous.
I’ve seen solutions to this problem using IEs proprietary ‘expression’ extension to CSS. IE uses width: expression() and the rest of the world uses max-width. I think that’s a reasonable use of IEs expressions.
A very good article. After I use the font size approach, the font appears in the same size in both IE 5.0 and Netscape most of time (I have tested so far). A problem on the Netscape 7.1 is that the percentage seems to be ignored sometimes. Font on one page is small, it may be bigger on the next page. How to work around this problem?
Here is my CSS code segment:
body {
…
font-family: Helvetica, Arial, san-serif;
font-size: 80%; /* IE 6.0 */
}
html>body {font-size: 80%;} /* Mozilla, Opera */
h3 {
font-size:1.2em;
text-align:center;}
.TitleText {
font-size:1em;
font-weight: bold;}
I’ve used this technique before actually reading this article.
this is another example of how it may be used:
ps: I know the “buttons” should have been list items, but didn’t have time – had to hand this stuff in minutes 😛
I’m not a designer, just an amateur who got tired of comments like “It looks fair to horrible on my big monitor…” So I got around to making a liquid layout using percentages for dimensions and absolute positioning (in progress)
http://www-personal.usyd.edu.au/~ctillam/japanland/3puzzles/3puzzles.html
Then I found this article, and am now experimenting with ems as a layout and text dimension: great. So nice to see the container expand with the text. Just one thing…
On a mac, using IE5, I had my body style set at 100% and a div which wraps all the text set at 1.2em; within, there’s a nested div with a margin-top of 1em.
Guess what: blank screen. No text at all.
Then I scrolled down, and there was the text, about one-third of the scroll-bar’s travel downwards. A top-margin of 1em on the nested div translated into, at a guess, 1200 pixels.
NS6 and Mozilla render as styled.
This behaviour is consistent for font sizes greater than 1.13em and less than 1.25em.
One of life’s little mysteries.
IE6 Win and points
And while we’re on text-resizing capabilities: I happily accepted what you see written everywhere, including ALA, that Internet Explorer will resize text set in points. This is a miserable and misleading half-truth, as you too can find out for yourself if you investigate the settings at Tools/Internet Options/Accessibility.
Yes, IE6 *will* resize text set in points–if you tell it to ignore the incoming font-size; then it gives you its own five-step range. But if you tell it to honour the incoming font-size, you’ll see what “no-resize” really means.
Sigh.
: }
This was an extremely helpful arcticle. Thanks 😀
Go to agree with Lee, read the article, experimented with the ideas on my website and I like what I see! Cheers!
I just got my new laptop with a screen resolution of 1920×1200 pixels, one of those wiiiide screen things, websites with a table width 0f 100% are unreadable, i almost have to move my laptop from right to left over the table to read text (if i want to keep my head still), but i also can flip the screen (in windows xp you can for these tablet pc’s) than you get a really long and small website, I’m still figuring out what the is the best solution to make a website readable on both screens..
I was glad that this article finally gave us a way to make the most of em’s without compromising too much, but one thing struck me as a result of it – as well as providing for a liquid/elastic design, what would you do if someone was browsing your site with a Page Zoom level set way high? Sure your text will flow, but sometimes it might be better to tailor the content based on the font size also.
For example if you’re showing the first X words of an article – at a “standard” font size you could display perhaps the first 30 words. With a “large” font size, perhaps the first 20 words instead for claritys sake.
So I wrote a script to detect the font size the visitor has set, to the pixel, and report it back again. It can handle Mozilla/Firefox Page Zooming as well as font-resizing. More details here if anyone is interested (especially in helping to test/refine it further):
http://www.launchcode.co.uk/fontheight/