- About the author
- Jonathan Christopher
The most important thing being delivered from any Web site is the content. Therefore, time and effort should be spent on making that content the most accessible aspect of any project. The method in which you style the content intensive elements of your document has a very strong effect on accessibility. There are different ways to style text according to the medium on which the text will appear. It is generally accepted that using em units to scale your text is the best method.
Why is em preferred over other methods such as pixel, percentage, or ex units? This issue has been written about and discussed in many well written articles already. If you are unfamiliar with the differences between the various unit sizes, you should take a minute and read the following articles:
There are many more excellent articles with a lot of great information on using em as a font-size unit. What is usually a hard concept to grasp is why it is the preferred method to use. After all, it is much easier as a developer to use pixel sizing and be completely positive as to how big your fonts will be. When first using em, it is sometimes difficult to determine why a font is represented in a particular size. The concept of a font size being dependent on a variable becomes confusing very quickly at first.
The most important thing to keep in mind is that opposed to pixel units, em units are relative to the font size of parent elements. If you take a step back and look at it, everything boils down to the font size of the browser itself – essentially giving the developer no control of the font size of their document. To the developer’s advantage, more often than not, users do not change the default font size of their browser and many don’t know that it is even possible; however, the people who do know how to change the font size are the people that matter in this situation. Those users are the ones who may have a visual impairment that requires them to browse the Web using larger font sizes so they are actually able to read text on screen. It is those people that developers should aim to acclimate with their CSS.
Aside from people with visual impairments there are other reasons to discontinue the usage of px. Picture the following scenario: You have just finished development on a site for a major client and they have requested a presentation in order to show them what you have been doing with their money. You are standing in front of a room of 20 board executives and have your work displayed on a projector. As a side note, you’re in the business place of the client, and the only browser available on their Windows XP presentation computer is Internet Explorer. After presenting what you’ve come up with, you open the floor to any questions and one of the execs in the back reports that he can’t read some of the text on screen. Here is where your presentation can excel or diminish.
Unfortunately, the font-size within your document is being controlled using pixel units and can’t be adjusted with Internet Explorer. Had you styled your document using em font units, you would be able to increase the font size of the browser which would in turn scale all of the text within your document, enabling this particular board member to read the text.
While this situation may not always be applicable, it should still be taken into account. It may be an extreme situation, but when developing it is important to keep in mind the end user. Not trying to be over-dramatic, allowing for scalable text is an important feature to keep in mind. While many modern browsers are able to scale px units, IE/Win does not, and as we all know, it is by far the most common configuration for our end users and must be taken into account.
Research shows that the ex unit would be a preferred method of scaling text when being compared to em units. A wonderful explanation is provided by mozillaZine in their article titled Em Units Versus ex Units. In which they explain that using em units can result in some font-size rounding issues. Scaling the overall font size has a positive effect on this problem, but using ex still seems like the way to go considering all the facts. It would be wonderful to implement, provided that it was consistent in cross browser performance. Unfortunately, this is not the case.
After testing in Firefox, using ex seemed to perform just right. After getting used to ex it seemed as though it was an effective way to determine font-sizes. Testing in Opera proved otherwise. All of my fonts were extremely small and almost impossible to read. After looking into this, it seems as though Opera and IE render 1ex as 0.5em which is the cause of all the trouble. Further investigation lead me to believe that the cause of this wasn’t Opera or Internet Explorer, but a limitation of the Windows OS somehow. I wasn’t able to find much detail as to the cause of this problem, but the fact remains that the default rendering is not correct.
Using a percentage as a font-size indicator simply does not seem intuitive. In day to day use, you usually don’t find yourself setting a font size as a percentage. Many people are used to setting points in word processing applications, which more often than not use a point system. This closely relates to pixel values and is more natural to use as opposed to a percentage for many people.
Some developers do prefer to use percentages as opposed to other units. It really comes down to preference. The thing to keep in mind is the issue of scalability in an effort to assist the end user in any way possible.
As stated before, using em units for font-size is dependent on the font size of parent elements. This is the most important concept to grasp when using em to scale text, and most often confusing to early adopters. As you know, the default font size for ‘medium’ text in browsers is 16px. When trying to determine em units for fonts based on a 16px font size can be difficult and might even require the use of a calculator from time to time. Developers have come up with the solution of scaling down the font size of the entire document by shrinking the overall font size from within the body to a value such as 62.5%. As a reminder, scaling the font size allows the developer to set the value of 1em equal to a pixel equivalent of 10. This makes things much easier on the developer due to the fact that you can determine the em font size simply by taking the pixel size you envision and dividing by ten.
In order to keep from being confused, it is often a good idea to keep font-size declarations to a minimum. Once the font-size is defined in the body, you should only continue to define where needed due to the fact that em font-sizes are relative to parent elements.
The idea behind scalable text is to allow for greater accessibility. If the only attribute being controlled with em in your stylesheet is font size – the structure of your layout may be degraded greatly the instant the user changes font size. If a particular element is styled in a way that the width and height is determined by a pixel value and the contained content is a tight squeeze, increasing the font size will force it to exceed your intended boundaries, possibly resulting in lost content or other ill effects.
This brings a major issue to mind: What would the point of having scalable text be if making use of the feature destroys your presentation? The answer is to control your document as the font size increases or decreases.
If you have container elements which house your content, allow them to expand in a way which will not destroy your layout. One way is to control the height of your container using em and control the width using px. This way you have control over how wide the container is, yet it will scale in height to accommodate changing font sizes.
When using relative font sizes, you will come to realize that as the font sizes increase greatly, things may get ugly. One way to better the situation is to control the overflow content not essential to your document. In certain circumstances it may be in your better interest to set a width of an element and then set an overflow:hidden and allow the content to become truncated.
This issue shouldn’t come up very often in real life circumstances. It is rare that a user would be browsing your site with a default font size of 25px or so.
Another effective way of using em units is to measure your margins. The majority of time this again occurs with vertical measurements only. As a font size increases and scales downward, there is potential of overlap with neighboring elements that are positioned based on pixel values. To correct this, more often than not em units can be used to space the elements from one another, and that space will scale in equal increments along with the font-size.
The overflow problem became an issue when styling Monday By Noon. The list elements chosen to be included in the design became a disaster after a few font size increases. To deal with this, the overflow solution was put into effect. Setting overflow:hidden to certain elements of those lists allows for the structure to be retained while conveying the content as best as possible.
Those list elements along with the Search section of the site are also spaced using vertical em margins because of overflowing issues as the font-size grew. To retain the look of Monday By Noon, the majority of widths are still controlled using pixel values. As this may be frowned upon by some, it is used to retain the look and feel of the site. Ideally, a particular Web site could be scaled in its entirety based on the font size of the user.
After taking some steps to lightly test the usage of em units, I’ve found that the character rendering seems to be off kilter in both Galeon and Epiphany when using Linux. They appear to reflect the same issues as Opera and IE in Windows but I wasn’t able to find a great deal of related information. Otherwise, adopting an em font-size unit seems like the best way to
increase the accessibility and usability of your site in modern browsers once the learning curve is overcome.