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.
First, great article. I have been covering the issue of liquid web design since about 1999 following Glenn’s theory and it’s good to see a twist to the method.
Also, perhaps consideration to emerging standards should be given. In specific SVG. We all know that this won’t work with photographs but the W3C has some pretty good examples of illustrated, line-drawn images that scale very well using SVG. Sure, mainstream adoption is quite a ways off for SVG, but something to consider for the future.
Another thing that is not covered in the article is an accessability feature of some browsers and OSs: zoom. I think what this Elastic Design accomplishes is quite simular to a zoom effect. Consider the demand for this type of design if the major browsers all supported the zoom accessibility feature.
A reference to Opera existed in a previous version of the article. It is quite a good comparison – the difference being that this method can’t (currently) expand or contract background-images.
I don’t use Opera for anything other than testing, but those people I know who do do seem to like the page zoom functionality.
Your article is well-done and helpful, and the area of text size is one that is very important to be left customizable to the user.
However, I take issue with your (and many other’s) general statement that “enforcing anything on a user is bad for usability and therefore detrimental to the success of the website.”
It is, in some areas, up to the designer, as a trained individual (hired, presumably, because he has skills that the end users don’t) to make and enforce design decisions for the end users.
This is not arrogance as a designer, but rather, confidence in the justification for there to be design as a paid, skilled occupation.
Again, text size is an appropriate place for end user customization, and this article is an admirable analysis of where we are, technologically, on the issue, but a blanket statement that designers should not be enforcing design decisions on a user maligns our occupation.
How are you achieving that :hover effect on your links on that CSSZenGarden design you linked in the article?
Nice design, too, by the way. And yet another helpful article from ALA.
*clap*
seth
> whereas an em is equivalent
> to the size of one character
No, it is not.
http://www.w3.org/TR/CSS21/syndata.html#length-units
“em: the ‘font-size’ of the relevant font”
I’ve been reading misconceptions about the em unit in print and online typography for nearly 20 years now. An em isn’t the width of an M or any other character. It is a unit equivalent to the point size (or other ‘font-size’), and it is a square with that dimension.
Abolutely right. I was trying to keep things simple, but I should have worded it better.
Copy changed; thanks, Joe.
We snagged on that line while editing, but couldn’t think of a more precise formulation that wouldn’t require two paragraphs of explanation (thus breaking the flow).
Your comment helped us craft one.
Enforcing the end user a bad thing? Look, if someone wants a bigger sized font than I decided, great! But some fonts I will set to a fixed size simply because I want the site to look good at all times.
Of course I can use all these tricks to make the site flexible, but trust me, the only ones that know you can resize text are programmers, webdevelopers, and the readers of ALA.
Basically, I think it’s nonsense to make your sites not only browser friendly, but also friendly for that .0001% of your visitors that want to resize their font. Windows has other tools for that called a “magnifying glass” 😉
Great article, though. I always enjoy reading others’ comments on these challenges. That doesn’t mean I agree with all of it, fortunately.
I did a design for a personal friend’s blog (http://tkfast.webhop.org/, some aspects of which are somewhat broken, so bear with me), and decided to take some liberties and experiment. I used the same em technique listed in this article.
The end result is nice, however those with small screens who just want the text resized (such as older folks using legacy computers, a fairly frequent case) will be in a bad situation. Perhaps, if this design technique becomes prevalent, the future will offer separate techniques for layout zoom and text zoom. We’ll have to see. I’ll be checking out the page zoom in Opera, just to see what they have going.
Great article though, and very timely. I like the ideas on image scaling. Web design is a constantly evolving trade, and this article really portrays that.
One aspect I’m interested in is the impact of elastic font sizes on printing.
If a user has their resolution cranked up to 2048×1536, has an appropriate font size set, then is this going to work well when printed?
Perhaps the print style sheet _should_ use fixed width fonts?
Yes, a print style sheet should use pts. to specify its font sizes.
I recently redesigned a site using em’s as the basis of the site layout. It seems like it worked out fairly well. Instead of using a percentage as the base font-size, however, I used a pixel size.
Thanks for the informative article. It gave me some more stuff to go on and let me know that my design decisions on the layout were on the right track.
Like Dris and rick, I did something very like Patrick’s elastic layout for a redesign last year (http://www.nthposition.com/). Judging from user reactions, it is a very useful method for a site that has a heavy reliance on large bodies of text that necessarily have to be easy to read at just the size the user wants.
It certainly cut down on the copious “I don’t like your fontsize/linelength/font” feedback that had been a drawback of the previous (fixed) design.
Thanks for the article, I think it’s really good to have a definition of a third option to throw in to the ever-challenging fixed v fluid debate.
That’s an excellent and well written summary of stuff I’d read elsewhere but hadn’t quite grasped the *reason* for doing. This is far and away the best article I’ve read on ala since the latest re-design.
I shall certainly be revisiting all my ems based stylesheets…
(How are you achieving that :hover effect on your links on that CSSZenGarden design you linked in the article?)
a {
color: #fe6;
background: url(underline1light.gif) bottom repeat-x;
text-decoration: none;
}
a:hover { background-image: url(underline2light.gif); }
I’m guessing the background image in the hover is an animated gif.
Any comments about pressuring the browser makers to provide *proper* accessibility tools, such as Opera’s page zoom? I do think that designers have their plate full, and it seems to me this issue is best handled by the user agent, using its wonderful system-level programming. It’s a little crazy that web content developers have to hack their way through this.
If Opera can do it, the others can too.
Great article. After reading Zeldman’s excellent book recently, I disagreed on one point: font sizes. I’ve used the percent-base + rest-em method for a while on different sites now with nothing but good response.
For some reason I have’nt visited the HTML Dog site before reading this article – a diamond of a resource!
(Btw, I’m a grandmaster noobster on blogging, so don’t expect much valuable content om my site if you happen to visit it 🙂
Cheers!
A)
I think the bigger issue about large resolutions is not too-wide-text lines, but rather really small text sizes.
If the line length is too long on a fluid or ‘relative’ layout, the window can be resized to acomodate the user. The problem’s cause here is that many users _always_ have their browsers’ windows maximized, but it’s a solvable problem.
On the other hand, if the text is too small and the size is specified in pixels (or other fixed unit), then there is no way to change the text size (at least in some browsers).
B)
Marcel (and others), you say you want your site to look good at all times, then think about text resizing as taking a sheet of paper closer or farther to look at it comfortably. And also: if people aren’t comfortable reading your content (however beautiful it may be), they may not come back.
C)
If a designer is afraid that their users don’t know that they can change the text size in their browser, then educate them. Add a note on a help page, at the top of each page, on the FAQ, whereever.
D)
Isn’t em a width unit and ex an height unit? Just asking.
I’m impressed by the way images can also be resized with ems, not just text. Hence the layout can be preserved. But stop. Is enlarging an image the way to go? Let’s think:
1) The image becomes blurry – users might not find it as pleasing, or think you can’t use good images.
2) People who have trouble reading small text will – in theory – also have trouble with fine detail in small images. Therefore to enlarge them could be an excellent idea.
3) Although Opera enlarges images as well as text, sometimes the result is messy. There is also an option in the Preferences to “Smooth zooming of images”. I think it’s off by default.
Jeffrey Zeldman once posted a link to a page that used a background image covered by an adjacent column. On large screens you were able to see more of the image. But on smaller screens you missed out on the detail covered up. Plus there was no way of knowing that there was more detail to see.
A great example using JavaScript to resize the whole layout can be seen on the Smoking Gun code demos:
http://www.smokinggun.com/code/scale.php
Certainly an interesting area. A good article. Thanks ALA.
There is a workaround for the max/min- CSS properties bug in IE. Using JavaScript expressions *inside* your style-sheet, you can simulate what other browsers support natively:
http://www.svendtofte.com/code/max_width_in_ie/
I haven’t test whether or not the code works when JavaScript is disabled, since the code goes into the CSS rather than a seperate .JS file (or inline or whatever.)
I found in my own experimenting, and then also with the Elastic Lawn layout at CSS Zen Garden, that the left-hand side of the layout gets cut off at larger text size settings in Mozilla 1.5 and Firebird 0.7. I’m not sure about browsers running previous versions of the GRE.
Head to http://www.csszengarden.com/?cssfile=063%2F063%2Ecss while using Mozilla and crank the text size up to 200% (1024 x 768 screen) and you’ll see what I mean. This does not happen in Internet Explorer or Opera. This also isn’t an issue when the layout isn’t centered in the screen.
body {
font-size: 80%;
}
This is bad advice. The trade-off with setting fonts this way is that users who actually set the text-size in their browser will get a font-size smaller than their *specified* preference (granted, they may have also set a minimum size option). These users will have to resize their text every time they enter and exit your site. Annoying.
IE users generally don’t know they can resize text. However, if they find resizing doesn’t work on your site (and the next site and the next) it won’t reflect badly on your site, rather they will blame their computer. This is a good thing. It puts pressure on Microsoft to fix their software.
Pixels are the better option IMHO (80% is a trick to get a 12-13px size in most browsers anyway). It does not harm users of huge monitors provided they set their resolutions apropriatly, and users of up-to-date browsers can resize if need be. Only set em’s on the body if you want to tap into the user’s preferences.
Let the market sort out the problem. Don’t fix broken browsers at the expense of users who do the right thing.
Otherwise, good article.
I came up with pretty much the same principle for a site i’m working on. The problem was that the client requested a header navigation bar using dropdown menus. So I had to make the dropdowns elastic too.
I based the dropdown menus on the previous article of Patrick and added some nifty javascript code
U can find the result here.
Thanks for the article. It certainly cleared up things and added a very interesting third option to the fixed vs fluid debate.
Well, let me start by saying that I liked the article very much. It was informative and the examples were quite interesting. The problem I’m having is that the more I look into and research this subject the less I am able to determine whats the best solution I should use.
This article states that using EMs along with some minor hacks is an effective way to get “elastic” user adjustable type and layout sizing using CSS, however, other articles here in ALA and elsewhere claim that EMs and % are not the best solution at all and should be avoided in favor of pixel sizes or no sizes at all (“Dao” design I guess). These articles have also been quite persuasive and informative on the subject.
I think what I’d really like to see, and what is needed is a table or side by side comparison of the pros and cons of each technique – a more consice breakdown of the techniques concepts and their appropriate usage.
As a Web Coder for a state government agency, I want and need to make my site accessable to as many folks as possible, and stay compliant with current coding standards and techniques as well.
I’d hate to be a usability hardnose and commit to absolute sizing to keep my sites orderly and readable to the average user, but it’s getting way too complicated to do something so simple as create a site that works across browsers and looks and behaves well too.
I have to say though, that ALA is one of, if not the most valuable resoruces ANYWHERE for Web Coders like myself to find useful information such as this. Very accessable, timely and informative!
Thanks again for your excellent work!
But how do you place div in the center of your page with internet explorer 5? at http://www.easy2rent.nl i have problems with getting this right. does anyone have an idea?
it should be:
http://www.easy2rent.nl/index.php
So, Marcel, you’re saying two things here:
1. That programmers, webdevelopers, and others “in-the-know” about font resizing make up .0001% of users.
2. That you want your site to look good at all times.
I’d ask how you know came on the statistic for number one and if number two is true why wouldn’t you use the elastic technique to make your site look good “at all times” (at all times meaning at different screen resolutions and when the user controls font sizes).
Yes MS offers the magnifier, which very few home users really know about. My grandmother after having gotten her first computer wasn’t given a manual that said “If you need glasses use the ‘Magnifier'” she did however manage to find the View -> Text Size -> Larger from the menu pretty quickly.
I personally think that you can’t make assumptions about what capabilities your users do or do not have. I feel more comfortable making the extra effort to accomidate the user base than attempting to enforce all of my own ideals upon them.
On the flip side of that if you are building a site for yourself and you are the target audience then build it however you want. But really how many people are building sites just for themselves. Take into account that the users are not you.
I managed to make everything elastic for this web comic site: http://www.bohemiandrive.com
There’s quite a bit of javascript for keeping certain things centered vertically and for keeping div heights matched, but barring that it’s not very hard syntactically. (Regarding javascript, I essentially had to poll the text size with an invisible div 1 em from the top of the page because Opera doesn’t seem to fire any events when you scale the page.)
In most places the effect is more interesting than beneficial, but for the strips themselves it’s actually useful (I think) because it lets you zoom in and out on the panels, for instance to see more context if you want to. It would be a pain to size all the images with ems manually, I’m sure, but for this site the images (panels) are uploaded through a backend that figures out their size automatically and stores their dimensions, which are converted to ems when the pages are rendered (16 pixels to 1 em).
At the moment I’m viewing this in IE 5.1/Mac, a browser I don’t normally use, at 800 x 600 on a 15 inch CRT screen (14 inches viewable) at 120%, and with “Allow page to set colors” unchecked. The example summary page for this article seems to be a little too elastic. When I zoom above a certain percentage, the text goes right off the screen, making paragraphs hard to read. Any reasonably usable solution needs to at least allow paragraphs to be readable without horizontal scrolling. That is also why Opera’s zoom feature and Microsoft’s magnifying glass are not particularly helpful features: they require both vertical and horizontal scrolling. Actually, magnifying glass features tend to make me a bit seasick.
On a personal level, how much trouble I am going to go to in order to read a site depends on how much I need to get information (or want to get entertainment) from that site. If a site is midly hard to use, I generally grumble but still use the site unless there’s an easier-to-use alternative. If a site is too hard to use, and I don’t need to use that site, I tend to leave that site. I will only write the Webmaster and complain about the site’s accessibility or usability if I absolutely have to do business with that site.
I happen to run (as a team member) a site that people have to do business with, for a government agency. We made the decision long ago, for accessibility, to stick with the browser’s default font size for the body text. We have never got a complaint about the font size being too large, except from my co-workers who have an eye for design, something I don’t claim to have. There are probably some people out there who are grumbling about our font size, but it doesn’t make the site unusable for them so they don’t complain.
We partner with other sites to provide certain services. Again these are sites people have to go to, with no other Web sites as alternatives. If someone has a complaint about these sites, they sometimes direct these complaints to us. One of these sites, which is heavily used, recently changed from browser default font size to a reduced font size, and I saw a few user complaints about that. (And any actual complain represents multiple complaints.)
Personally, I do like to see nice design, but font size is not the place to exercise it. If it’s uncomfortable for me to use your site, I don’t care how beatiful the design is, I will curse it. I’m there for the content. If I can get the content easily without having to switch browsers or go into my preferences, then I’m happy to admire your design.
Adrian wrote:
>>>
body {
font-size: 80%;
}
This is bad advice. The trade-off with setting fonts this way is that users who actually set the text-size in their browser will get a font-size smaller than their *specified* preference (granted, they may have also set a minimum size option). These users will have to resize their text every time they enter and exit your site.
[…]
Pixels are the better option IMHO (80% is a trick to get a 12-13px size in most browsers anyway). It does not harm users of huge monitors provided they set their resolutions apropriatly, and users of up-to-date browsers can resize if need be. Only set em’s on the body if you want to tap into the user’s preferences.
<<< I don't follow your argument. Let's say that someone has set the default font size of his/her browser to 50px. Then, let's say that he/she visits two sites: one where the font size is set to 12px, one where it's set to 80%. In the first case, the browser would display 12px fonts, and the user would have to resize the text on each visit, just as you say he/she would have to do with percents or ems (with the difference, of course, that the browser used by the vast majority of people doesn't resize px sizes). In the second case, though, the browser would display 40 px fonts (80% of 50), which MIGHT still be too small, but at least a lot better than 12 px - meaning that IF the user needs to resize the text, it's going to be easier (e.g. bump it up ONE notch instead of three or four). Bottom line: the only way to NOT tap into the user's preferences is to not set font sizes at all, but if you're going to set them, ems and percents are better than pixels, because even though your sizes might be suboptimal, they're at least proportionally suboptimal to the user's default.
I’m perplexed by “designers” who use the “must look good” argument when it comes to flexible site design. (I’m also horribly amused by ALA’s rather poor website design, but I’ll get to that.)
Seems to me that a trulyprofessional design would look good with a large range of fonts and screen sizes; that’s part and parcel of the job. It’s not even about “font magnification” for vision-challgenged folks. It’s about accepting that not everyone has the same set of needs, and a flexible web page should try to accomodate as wide a range as possible while remaining sane. CSS makes that easy, so use its features.
Let’s take this ALA article page as an example. In my browser (I’m using a 15″ LCD display at 1400×1050 resolution) I see over 2/3rds of the page just being wasted on… gray. Oooh, yeah, that’s a stunningly brilliant design. Somebody used pixel sizes for everything, didn’t they? (Looking at the CSS… yup.) Well, it “looks good” if you happen to think huge gray borders are a compelling visual feature. (Oh, sorry, it’s my fault because my browser window is “too big”. 🙂
Using percentage fonts (and ems) is just part of it, but an important part. I, the user know what I need in terms of font sizes–you don’t. (And yes, ideally most authors would use the 100% setting as a minimum font size–but since not enough people know about font resizing in their browsers we’re kinda stuck.)
I also happen to believe that a far more effective use of browser real estate can be made than chewing it up with things like huge empty gray borders… if “designers” would start using screen percentages instead of fixed pixel sizes.
Great article. Thumbs up! I was about to post someting about SVG here, but I see Nick Finck allready did that 🙂 That would really make a layout elastic; for instance, imagine the company logo stretching and shrinking as you resize the browser.
Peterman:
You need to take into account that if somebody wants 50px text across all sites they would use the !important directive. IE provides this functionality with a setting called “ignore font sizes specified on web pages”
Otherwise, by setting a default size in their browser as per your example, what users are effectively saying is: “50px is my preferred size, however I’m prepared to let the designer over-ride this value if they’d like”.
Therefore, the site rendering at 12px would be exhibiting the desired behaviour. It would only be undesired if an “ignore site’s sizes” type setting had also been applied by the user.
Adrian: what you say is correct, but AFAIK it’s also irrelevant to the issue we were discussing: pixels vs percents/ems. If someone uses the !important directive, their preference shouldn’t be overridden, no matter what font size unit the site OR the user uses. (Unless you know of a browser bug that I don’t know of?)
Zoomed graphical text may not be legible when zoomed, even if the zooming is smoothed. This is because the text was probably anti-aliased to look nice.
I strongly dislike Opera’s page zoom because it leads to horizontal scrolling. There is not much worse than having to scroll back and forth horizontally to read each line of a paragraph. A better zoom would zoom each object individually and reflow the page as needed. AFAIK, only WebTV does this (although in WebTV’s case, it makes graphics smaller, not larger).
In defense of AListApart’s gray space, there is an optimum line length of 2.5 alphabets (approximately 38em). It is harder to read text which goes all the way across a very wide screen.
Good article and good discussion.
Firstly, ALA’s central column is fairly pleasing, but SHOULD expand horizontally WITH the text-size, then there would be no faulting it IMO (also needs a background-color: white; for the main text as you can’t read it if the text bg image doesn’t load).
—
And my main point is that of all the great discussion here, there’s is only one slightly bad comment…
(http://www.alistapart.com/discuss/elastic/#c6151)
“It is, in some areas, up to the designer, as a trained individual (hired, presumably, because he has skills that the end users don’t) to make and enforce design decisions for the end users.”
… It’s primarily the “enforce” bit I disagree with. Any well trained designer will know you have a constant battle to do what’s best for the users. To force your decisions upon them IS arrogant because you are saying you are not wrong, where-as a good designer will know the proof of the pudding is in the eating – you’ve only done a good job if the testing and evaluation meets the requirements, and if real life success is achieved.
I agree often the designer can make the best decisions, but ONLY if they know enough about the user. On the WWW, you DON’T know enough about the user.
Allowing the user to change the text-size is just what designer’s need.
Instead of trying to research the average favoured text sizes, and choosing a fixed size that only makes the ‘average’ user happy, we can now ask EACH user EXACTLY how they like their text served and give them what they want. Assuming we can set up the page to accommodate all or nearly all the range of text sizes people may desire, without the layout suffering beyond what is acceptable.
If you say 12pt (for example) is the text-size best for the average user, and you ask all of your users if the text-size is OK, most will say ‘I guess so’, some will say’ I’d have made it different, but it’s not too important,’ and the knowledgeable will say ‘I’d rather make my own choice and not be told what I like’.
If you instead ask those same users to set the text to the most comfortable size all by themselves, they will use your site with more ease, increase efficiency and effectiveness, and above all, they’ll be happier that they are using a “tailor-made” site rather than the “one size fits all” variety that is, regrettably, still the norm.
You have to strike the balance. It’s somewhere between asserting no design decisions – making yourself redundant; and telling the user what they like – making yourself a stylist or artist and not a designer.
—
The only thing in our way of using current technology now is bad browser implementation and lack of user’s knowledge of how to use such features.
Hopefully there will be simpler, easier to use technology in the future.
This doesn’t seem to work as expected in NetFrontv3.0, an embedded browser.
BODY { font-family: verdana, arial, helvetica, sans-serif; font-size: 76%; }
.head_link { font-family: serif; font-size: 1.0em; }
produces bigger text than just a 12px setting.
Peterman said:
<<< Adrian: what you say is correct, but AFAIK it's also irrelevant to the issue we were discussing: pixels vs percents/ems. If someone uses the !important directive, their preference shouldn't be overridden, no matter what font size unit the site OR the user uses. (Unless you know of a browser bug that I don't know of?) >>>
That’s right. However I believe it is relavant to the discussion because if someone sets a default text without specifying its !importance then it means s/he is still happy to see the text as the designer invisioned it.
So why set a default text at all? I would like to be able do it *only* so I can comfortably read sites like useit.com that have given control of font-sizing to me.
This ties into the pixels v ems debate because if you specify an 80% size, the resulting size will be 80% of my desired size for unstyled sites. This is not what you or I want: I want to see the text either the way you envisioned it, or at my default size. If you use pixels, great! I get to see your masterpiece. If you use ems, you’re tapping into my preference for unstyled sites and getting it wrong.
Lots of great discussion here on the subject and I have learned much from following it and reading and experimenting with the technique. However some of the discussions here seem to be losing sight of the basic concept. This is just a technique, a tool for your toolbox. Something you can use if you need it and find it useful. Kind of like using a Phillips head screwdriver instead of a standard depending on the screw you need to, you know, screw. Or perhaps a better hardware analogy would be using a spring or hinge instead of a bolt or bracket to connect something.
I work at a state government agency and I happen to be redesigning our agency’s public site and accessibility and usability issues are a top priority for me right now. I have to consider and try to accommodate as many potential users and whatever browser or system they might be using, so flexibility is a good thing. This looks to be a very good answer and tool to use on some critical issues I’ve been having in my current redesign and I will definitely be trying to implement it once I fully understand its function.
So keep the discussions on the technique stimulating, but lighten up a bit out too, it’s just another great idea and tool that we can use to get the job done!
Unlike many designers, my eyes are on the far side of 45 years old and getting older all the time. I habitually use a larger font size than many people do, and I often re-size as I move from site to site.
I am not all that happy with sites laid out in ems, because often when I up the font size (e.g. on that ZenGarden elastic layout or at nthposition.com) the stuff on the right moves off-screen and and I get a scroll bar. I *hate* scrolling right to left, it’s a royal pain especially for those of us who also have movement troubles and try to avoid mousing.
Designers tend to be people with a very strong sense that only some things are “right”, visually: they want certain proportions and visual relationships. Unfortunately for them, on the WWW that’s a bug not a feature. For me, it’s a feature: I can read things even if the publisher prefers to use a font size of 10 instead of 12.
If someone puts together a set of pages which only differ in the way font size is expressed, I am willing to be the Elderly Eyeballs User test victim and say what I think of them.
And BTW, people like me represent at least 20% of the online population overall.
<<<< I am not all that happy with sites laid out in ems, because often when I up the font size (e.g. on that ZenGarden elastic layout or at nthposition.com) the stuff on the right moves off-screen and and I get a scroll bar. I *hate* scrolling right to left,... >>>>
This is a good reason for developers to use max-width. I know it isn’t supported by IE but there is a hack that can be used for IE that doesn’t affect non-IE browsers at http://www.svendtofte.com/code/max_width_in_ie/ . I also use this method to support min-width.
My site is currently using an elastic sidebar. The main content area is liquid (with em sized margins). I’ve used an em sized max-width to keep it looking nice on large displays (too bad for IE; but hey, IE users can resize their windows if the lines are too lont). The only problem is if the font is HUGE, the sidebar (about 10 ems) will fill the screen leaving very little room for the content. One solution would to give a min-width (perhaps in pixels) to the content area, causing hoizontal scroll to view either the sidebar or the content.
The article says, “The default height of text in a browser is generally 16 pixels”, but this is only the case for archaic browsers such as MSIE 5,6 and NN4. Opera, Firebird, Mozilla, and Konqueror all show 1em to be significantly smaller than 16px. Opera is around 13px and the Geckos are about 12px.
The article says, “The default height of text in a browser is generally 16 pixels”, but this is only the case for archaic browsers such as MSIE 5,6 and NN4. Opera, Firebird, Mozilla, and Konqueror (Safari?) all show 1em to be significantly smaller than 16px. Opera and Konqueror are around 13px and the Geckos are about 12px.
I notice both your demo page and Mr. Briggs use an XHTML Doc type. Is this necessary for this type of css? When I had no Doc type I got one result, and when I used the default html Doc type I got another result (different type sizes) for the elastic type .
Roxanne wrote:
>>When I had no Doc type I got one result, and when I used the default html Doc type I got another result (different type sizes) for the elastic type
Roxanne:
DOCTYPE affects how strictly (i.e. how accurately) a browser will interpret your CSS. See this ALA article for more:
http://www.alistapart.com/articles/doctype/
Adrian wrote:
>>>
I want to see the text either the way you envisioned it, or at my default size. If you use pixels, great! I get to see your masterpiece. If you use ems, you’re tapping into my preference for unstyled sites and getting it wrong.
<<< I see what you're getting at: Pixel sizes are optimal for the designer, and for users who wish to see exactly what the designer intended. Default sizes are optimal for the user*. Em/percent sizes other than 1em/100% are optimal for neither. However, I don't see this as a big problem; if the site is to be able to look good and be fully usable with the users default font size, it has to accommodate for a wide range of sizes, since not all users have the same default. This means that it should also be able to look good and be usable with a font size that is proportionally bigger/smaller than your default (80% of your default is 100% of someone else's default). And if a site is NOT able to look good and be fully usable with any other font sizes than the designer's, then it's only optimal to those who are able to comfortably read in that size, right? Here comes the asterisk: *Default sizes are only optimal for those users who have set their default size, and it appears to me that few users have, or are even aware that they can. I'd be happy to be proven wrong, though. To summarize the pros and cons of different font sizing methods: Pixel pros: + Allows the designer to create a subjectively perfect design that users are able to see as intended, provided they don't override the font-size with e.g. !important directives. Pixel cons: - Suboptimal font sizes for those who don't have the same taste and eyesight as the designer. - 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.) Default size pros: + Always optimal font size for those users who've set a default size. Default size cons: - Suboptimal for those who haven't, and they are probably many. 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. Em/percent cons: - Well, it's still suboptimal. Feel free to add to the list, and remember (all of you) that we're only talking about base font sizes; it's never a bad thing to use relative font sizes e.g. to make headings (sensibly) bigger than body text. And ems vs pixels vs percents for sizing other things than fonts is an entirely different subject. Now, I really do think that the best solution would be if everyone just set their default sizes so that they could comfortably read unstyled text (and leave some room for smaller text like copyright notices and such), and that designers just left the base font size at 100%. But unless both these things happen at once, there's going to be suboptimal font sizes for a lot of users at a lot of sites. And while it might be fair to ask web designers to do their part, I don't think it's fair to ask users to "please set your font sizes to show web designers we mean business, even if it means that text becomes too small on sites that don't respect your settings". There is the argument that users who go to the trouble of setting a default font size should be rewarded, and that those who don't take advantage of their browsers configurability have themselves to blame. I think this argument is mostly valid, but I also think there's validity to the counter-argument that modern browsers often provide quick ways to specify both a fixed font size (a la !important) and a minimum font size, making sure that text is never too small, and that hardcore power users can create their own stylesheets. 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. Pixel sizing comes a long way down, because its benefit is only a benefit to the designer, to those users who share the designers taste and eyesight, and to those users who are more interested in looking at a beautifully designed site than actually reading or using it.
Vigil wrote:
>>>
“The default height of text in a browser is generally 16 pixels”, but this is only the case for archaic browsers such as MSIE 5,6 and NN4. Opera, Firebird, Mozilla, and Konqueror (Safari?) all show 1em to be significantly smaller than 16px.
<<< Under Windows, I've installed Opera, Mozilla and/or Firebird alongside IE 4-6, without changing font sizes in any of them, and when I view em-/%-sized text, the size is equal in all of them. Under GNU/Linux, it seems to be a different story; even when I set Opera and Mozilla to the exact same value in pixels, sizes differ.
My rule of thumb for deciding whether a layout “works” is:
– it looks good at viewport widths from 650px to 1024px with IE text size set to “Smaller” (which my husband uses) or “Medium” (which I use).
– no content areas overlap when IE text size is “Largest” and viewport is maximized on a 800×600 screen.
I contend that if a web designer’s layout does not fulfill at least the first requirement it doesn’t matter how pretty or effective the design is on their home system, it is an objectively bad design for the WWW.
It seemed like you reversed your self twice in mid article between using ems, using pxs, and going back to ems, so that it appears that the issue is still in that ‘not quite yet standardized’ stage that was a problem for early CSS and NN4. 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. I don’t really have time for experimentation while keeping clients happy.
I’m learning CSS-p right now, but it is still troubling enough to get it to layout right that there is a lot of trial and error involved. Without a solid position and decision on font sizing, and standardized methods for implementation, it makes the whole enterprise somewhat questionable for use of time.
The odd thing is that px fonts scale just fine in IE 5 for Mac. There’s no problem in Safari. It would seem that if M$ would just cooperate, we could all use px and be done with it.
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/