Search

Effective Style with em

Posted: March 13, 2006 Comments(129)

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.

Why not px?

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.

Why not %, or ex?

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 % to Scale Font

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.

Putting em to Use

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.

Uses Outside of Font

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.

Container Elements

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.

Dealing with Overflow

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.

Margins

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.

For Example…

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.

Cross Browser Issues

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.

Digg This Article

Related Content

  1. Google HTML/CSS Style Guide
  2. CSS Organization Methods and Writing Style
  3. Beginning to Style Your RSS Feed

Categories

Categories Accessibility, Development

Tags

Tags , , , ,

Get my newsletter

Receive periodic updates right in the mail!

  • This field is for validation purposes and should be left unchanged.

Comments

  1. I was always curious as to the reasoning behind using em over ex.

    As for the usage of em, it is not compatible in any IE versions below 4. They view em and ex both as pixels so to set the font as 1.5em may show it as 18px in later versions of the browser but IE3 will show it as 1.5px. While

  2. Sorry about that, apparently I can’t use the less than symbol in comments. As I was saying, while many people do not use any IE versions below 4, this is still a potential compatibility issue for those that do.

  3. @Michael: You bring up an excellent point. When viewing a styled document using an older browser such as those you mentioned would not be very usable with text sized using em. Thanks for bringing up that point, as it is an important one.

    As a side note — you were correct, WordPress doesn’t care so much for the less than symbol in which case you can use < just for future reference.

  4. When I first starting doing html and css I had read a few articles stating that em/ex was better than px. Trying it out for the first time, I could not seem to get it right. My font sizes would always show up incorrectly. This article has allowed me to revist ex/em and their uses. Understanding that font sizes with ex/em are based on the parent elemet is the step I was lacking. Thank you for the wonderful article.

  7. “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.”

    If I Ctrl-Mousewheel up or down, the fonts will get scaled, also if I’m using IE/FF. Or is that something totally different?

  8. I like em because it is relative to the user’s preference. That’s why it surprised me to find an em-advocate as yourself to be using:

    font:62.5%

    in the body selector of this article. That’s unreadable, man. 😉

  10. To be fair to IE, the next version has zooming built in to magnify the page.

    Excellent article, and it will be a while before IE7 ships.

  11. Yeah, I like using em’s too, but it’s annoying if you use tables because the em effect is (Incorrectly I think) accumulated ..
    so if body is 0.81em and td is 0.75em you end up with 0.81*0.75 em which is not good.

  12. @jinesh: Thanks for throwing up that link. I will definately take a minute to check out that method. I totally understand what you mean about the difficulty of using em for width of elements — it becomes tricky very fast.

    @Cheyne: Thanks for the heads up!

    @Andy: What I meant by that was that if a font size is set using px, IE/Win will not change it even if you try to increase the font size manually, which is a major drawback.

    @thedude: Forgive me, I’m not sure exactly what you’re saying here. Are you unable to read the fonts here?

    @Ole: It is absolutely old news… I’m just trying to get some content out there on it so more developers use the technique. There are many many wonderful sites that still use px for font.

    @Tim: Yes — IE7 will definately have some major upgrades, yet does not render this site correctly using IE7b2. If you happen to have access to IE7b2 check it out. I’m not paying too much attention to it yet because it is DEFINATELY a beta, but it will be interesting to see what changes developers will have to go thru to accomodate.

    @DrG: Yes, pixel rounding is one issue many people have with using em units. Scaling your font to try and create minimal instances of that happening would be my suggestion.

    Thanks for everyone’s great comments. I didn’t really expect this article to get so much attention — but I’m glad there is healthy criticism going on and I’m sure there is more to come. Thanks again.

  13. In my norwegian webdesigner community we all have used this for years. It’s good that you notice new programmers;)

  14. yo! IE4? IE3?! please, life is complicated as it is. [em] is my preferred method of scaling fonts, and setting body font size to 62.5% just looks plain ridiculous.. then again, i’m just a random stranger passing by.

  15. Ha, someone proclaims virtues of em but cannot use them on own site. Bravo.

    Call me when the two column setup resizes with EM.

    Call me when images resize with EM.

    Call me when whole website changes its size in either IE/Mozilla, not just the fonts.

  16. @george: I understand where you’re coming from… but sometimes real world situations call for all browser support. From time to time a client will compain of their site not rendering correctly, and come to find out they’re using a severely outdated version of AOL (IE) to check the status.

    @kadmin: The two column layout is intented to retain structure as the font sizes increase. This was done on purpose. Perhaps you didn’t read the entire article? Also, it is not just the text that is resizing — the list elements also scale to retain their look and feel. Understandably yes, they do lose any appeal once the font size is blown up 3 or 4 levels, but trying to make a pretty looking list using fonts that are ~72pixels tall isn’t an easy thing to accomplish. I hope this clears up a few of the issues you’re having with the article and the site. Thank you for putting up your opinion.

  17. Great, em definitely seems like the way to go, both for scaling up text on big monitors as well as potentially scaling down for smaller screens like PDA’s.

    @DrG: em scaling is inherited from its containers, in the case you mentioned, its like saying set all the body text to .81em, then set the table cell to .75em of this, so it is the correct and logical behaviour. What you want is text 6% smaller that the body text so set the td text to .94 em.

  18. Nice article but I will continue to use % values which are much easier to figure out and much less math.

  19. @musonica: I’m glad the article was helpful for you. I haven’t done much research on using em for handhelds however — I’m not sure how well supported em’s are on the various proprietary browsers out there.

    @David: You’re definately not alone there. There are many developers who use % or other methods and each have their own reason. I’m glad you decided to give the article a read anyways. Thanks a lot for commenting.

  20. Hey, great site for discussing accessibility issues:

    Except that YOU IGNORE THE FONT SIZE THAT I HAVE SET IN MY BROWSER. As a consequence, I CAN HARDLY READ YOUR SITE AT ALL.

    Sheesh, how hard can this be for folks to understand … Forget the em’s versus ex’s etc. – JUST STOP FRIGGIN’ AROUND WITH THE FONT SIZE PEOPLE HAVE CHOSEN TO READ IN !!!

  21. Dear Jon,

    Thanks for the reply, please excuse me if my comment was harsh. But as I said before, I hate when websites do px/pt sizing on their elements. And especially when one is advocating the usage of em!

    For example, this comment field, I can fit only 10 characters per line, all because comment field is sized not per character count (or cols property), not by em, but by px.

    I run 1600×1200, can you figure out how your website looks at this resolution?

    Just in case you dont then let me explain: it takes less than half of the available screen estate. With semi readable font.

    So I decide to enlarge the website. Both, IE and Mozilla do not enlarge the images nor, more importantly, the two column layout. They can if you set them to em, but you dont, even if you advocate to use em. Oh, sure, now I have readable fonts, but only 3 words per line.

    Why not edit your website to run everything as either em? or screen %?

    Ofcourse, you could say: use Opera as it is best for zooming in, or links/lynx with your favourite font size.

    Ofcourse, you could say: use different (lower!) resolution.

    Ofcourse, you could say: 10% loss of users is an acceptable loss.

    take care

  22. I don’t see much sense in using ONLY em at the moment. When I’m doing an expensive layout I have to rely on px für DIVs, or have you seen a background-width property yet?

    Also, browsers are able to resize pixel-based content and i guess much better than they resize em-units. Your example with that presentation doesn’t count!

    It would be beautiful vision, a resolution-independet web.. someday.. hopefully. I suggest using em for fonts and leaving the layout pixel- or percent-based.

    Ok, just tested. IE is an argument. I really wonder, cause that browser support a body {zoom: 200% }-property.

  23. @TC: I think you’ve missed the point of this article. For the people that have changed the default resolution on their browser, using em to size your fonts allows those users to increase the font size if it isn’t readable. If you increase the font size on this particular page is it better?

    @kadmin: I really appreciate your comments — and no, no offense was taken. I am open to criticism at any time and place.

    You bring up an excellent point. And as it is the case I can picture what this site would look like at such a large resolution — and it doesn’t look pretty. So I absolutely can understand where you’re coming from. This article was written to get opinions such as yours out in the open and up for discussion. I do plan on giving this layout a more fluid aspect in which it will grow in width as such large resolutions are used — but it is still in development at the moment, unfortunately.

    I am going to look into the ridiculous font size issue you mention as far as the comments are concerned, as I have just heard that same thing from another reader.

    I also understand the issue of images not scaling which is another issue for the most part — image quality degrades very quickly if you allow them to expand. So where is the happy medium? What do you think?

    And of course, you cant expect readers to use another browser — what they’re viewing your site with isn’t by mistake, its their choice right? Same thing regarding a user changing their entire resolution just to read your site — what was the point of spending all the money on that huge widescreen LCD then?

    You raised some excellent points and I’d like to thank you for that. I’m going to do some personal research into what you’ve said and hopefully make some adjustments which help you to view the site in an acceptable fashion. Thanks again. I hope to see more comments from you in the future.

    @mg: I would have to agree with you in a certain aspect — using ONLY em is almost a stretch, but theoretically would provide the most accessible solution.

  24. Nice article. I decided to go the em route for my site and it worked quite nicely. I would definitely do some things differently next time, but I’m very happy with it.

    The nicest thing about em for myself is the fact that if you use Flash, the embedded swf will scale when em dimensions are applied to it. Quite a few people have written about it lately. If you’re going to plop Flash in that’s primarily vectors, you might as well be able to scale it. 😉

    Nice article.

  26. i’m confused as to why some are saying 62.5% body font-size is unusable.
    I understand jinesh’s comment, that some older browsers may give different results as to what 62.5% equals, but regarding it being unreadable, it was my underrstanding that 62.5% could be used to set 1em=10px (except for in those browsers jinesh is refering to) … then child elements of the <body> (ie. all page elements) could refer to EMs in the manner:
    1em=10px
    1.6em=16px
    etc
    etc
    So, while 10px may be too small for paragraph copy, one could set <p> font-size to 1.2em (12px) … or whatever they like. IMO, this takes the “math” out of the hassle of setting div and image sizes in EMs as well. i’ve used this method on my own site and haven’t noticed any problems in the browsers that I’ve tested it in (while my current layout throws to text only for the time being for IE5.x (unrelated to sizing with EMs), my past layout worked in it using this method)

  27. @P.J.: I don’t deal much with Flash so it is great to read what you had to say — thanks a lot for including that in your comment, I’m sure other people will find it interesting also.

    @dan: I’m glad you liked it — be sure to read all the comments here — some really great reflections on the article and some even better criticisms.

    @ryan: I was wondering the same thing when reading some of the comments here. The articles linked towards the beginning bring up the very issue of setting the percentage as a way to help with the math of the whole ordeal and it seems to make sense. Hopefully we’re able to read a response. Your observation is the same in mind in that 10px is often too small for text, but it is solved by increasing the em size in the actual element itself. Thanks for your comment, I appreciate it.

  29. @ryan/@Jon

    The whole issue with setting the font-size to 62.5% is the following. What if I, the user, have a stylesheet that sets the font-size of the body element on every page to 90%? When I come to your site, my style will override yours, and all the text will be larger because it’s getting sized up from 90% instead of 62.5%. The only reason I would set up my 90% rule in the first place would be to _shrink_ the text size I see by default, and now your page is showing up even bigger than it would without my style.

    What’s the point? You as the developer should suck it up and do the math, meaning define your styles against a 100% body. Yes, that means the size of most of your text in em’s will be less than 1. I know that makes the math harder, but as the developer, the burden is on you to make your content accessible for me, the end user. I don’t care what you think your content should look like; I have ultimate control of how I consume your content. Of course, designers hate this, but it’s the nature of the web. This seems to be the hardest thing for web designers to get over. Your end users may not want to see your site the way you intended them to see it, and that’s okay!

  30. @mg : “When I’m doing an expensive layout I have to rely on px für DIVs, or have you seen a background-width property yet?”

    primo : background scaling is proposed for css3

    secundo : there is a work around with z-ordering, and img within a div, something along the lines of:

    div style=’position:absolute;left:[X1]em;top:[X2]em;z-index:0;width:[XX]em;height:[YY]em’
    img style=’width:[XX]em;height:[YY]em;’
    /div

    (didnt use the html inequalities since someone mentioned that they dont work and screw posts).

    hence you can have a background that scales..

    ofcourse, you then get into IE alpha png issue.

    ofcourse, you then get into the whole ‘src of img cannot be set in css’ issue.

    Still, its possible to have background image scale!

  31. My issue with em is when it comes to laying out text elements as buttons / rollover elements with solid background shapes, which then have to line up with other non-text elements…
    Maybe I haven’t spent enough days at it, but it’s a pain to try to get it to work across a reasonable set of browsers and when someone tries to upscale the text, the layout breaks (as it must). The most I do at the moment is to try to keep the relevant data from disappearing horizontally.

    As for accommodating people using legacy browsers, as far as I know, IE 6 works on Windows 98 and I’m not sure I should be encouraging anyone to use Windows 98 or earlier and/or an obsolete browser which may be a significant security/privacy risk (does Microsoft still update IE 5 and below?).

  32. jason: interesting point. so perhaps rather than setting the body font-size to 62.5%, setting a containing div (first child of the body) font-size to 62.5% would resolve that situation?
    it’s extra mark-up but, seems it would work, no?

  33. @Jon “I also understand the issue of images not scaling which is another issue for the most part — image quality degrades very quickly if you allow them to expand. So where is the happy medium? What do you think?”

    I agree, this is a problem, however its being worked on, although, all things considered, too slowly.

    Vector graphics is one sollution. Many images on websites are just logos, headers, corner rounding (digression: people, please use the css ‘border-radius’ for rounding corners). With SVG things never scaled more beautifully!

    But what about pixel art? Pictures? Simple, provide upsampled image, so when displayed by default its smaller than in reality. This has one problem: bandwidth waste. Again, this should not be an issue with one technology: JPEG2000. This ‘new’ (afterall, its year 2006 now) image compression format provides better quality at smaller file sizes. To make it even more fun, JPE2000 also has support for sequential quality (think interlaced feature in the old days). Download 20% of the file and you can see the image. The more you download, the sharper it just gets. (all thanks to the wavelet compression)

    Browsers could stop download at some quality level, without downloading all the image information (jp2, unlike jpg, has support for quaranteed lossless compression). Someone wants to enlarge the image? Simple : browser starts a resumed download of the image and gets more detail.

    In the good old days there was another feature in html.
    IMG
    LOWSRC=black_and_white.gif
    SRC=real_image.jpg

    but it was dropped…

    So we can only wait for SVG/JPEG2000 and their proper support in browsers, ad all our image scaling problems will finally go away !!

    Ofcourse, at the same time we, as web site designers, need to show browser developers that we want nicer image scaling! that we want JPEG2000/SVG.

  34. @Jason: You raise an interesting point, but if sites were coded using a relative font size — wouldn’t the user CSS file no longer be needed? Just thinking out loud here, but if that were the case, wouldn’t you as the user just reset the default font size in your browser preferences and be on your way? What do you think? I _absolutely_ agree in that it is the developer’s responsiblity to make the content as accessible as possible and thanks for the comment.. its an aspect of this situation I hadn’t thought of before.

    @won: That is definately a major concern for many people. Enabling your site to be ‘scalable’ does limit the introduction of certain design elements. Thanks for your comment!

    @ryan: If I’m not mistaken we would still be faced with the same situation — em units are based on the values of parent values so I assume we would be in the same boat — correct me if I’m wrong, I haven’t had time to test.

    @kadmin: Wow. Thanks so much for that post… you’ve really shown me that I need to brush up on compression methods and their advancement. Thanks a lot for posting what you did, it will be a good base to work from when I start Googling for answers. SVG graphics do seem to be quite a promising future for design. Thanks again for the comment — much appreciated.

  35. jon: setting a firstchild of the body container div’s font-size to 62.5% would scale all elements to 62.5% of the users personal css file’s body setting. so it would be (IMO) better than having the body tag set to 62.5% and relying on that as the font-size for the rest of the layout. Setting a containing div to 62.5% would still allow the user’s css file to at least still scale down the page. Relying on a developer defined <body> font-size of 62.5% would produce the opposite desired effect for the user (their page would scale up).
    Granted 62.5% of 90% isn’t going to display the page as anyone desired … it at least won’t produce the oposite effect for those users

  36. alright …
    i’ve officially become distracted with this 😛
    i’ve updated the style sheet for my site to accomodate the problem presented by jason.
    rather than defining “body { font:62.5% … }”
    i’ve defined the first container div to:
    font-size:10px !important;
    font:62.5% …
    so now it shouldn’t scale up for anyone using a personal stylesheet and i *think* 1em=10px for everyone (except IE users using their own stylesheet … they’ll see 62.5% of whatever body setting their personal stylesheet is set to)

  37. setting first child of the body font-size to 62.5% does not solve the issue

    Jason’s issue is that the main font on the page should be 100%… so the main text and default text sizes are fully set by the user

    im not sure what percentage of websites allow this anyway… so jason stylesheet might be a big hinderance in surfing the web?

  38. i *think* his issue was more that the user should be able to control the relative sizing of elements on the page … and the method discussed (setting the body tag to 62.5%) may affect users whose personal stylesheet settings tried to scale everything down, as they would actually see things enlarged for personal settings between 62.6% + (as all other elements on the page would be based on the overridden 62.5% body setting).
    my previous post however didn’t allow any scaling for users who were using their own style sheet with a body font-size setting (as it was overriding _any_ reference to a %, EM type of measurement with a px measurement … so they would see it as intended (pixel-wise) by the developer no matter what … taking control from the user) … rather than the first “!important” font-size being set to 10px, it should probably be set to 62.5% as well. that *should* i think keep things relative for everyone

  40. Jon, great article! A topic I’ve been meaning to research a little more as it’s only been briefly covered in any of the CSS books I’ve read.

    I myself, have always declared a fixed pixel size for the body, then scaled using percentages for everything else. I knew you could accomplish the same thing using em but wasn’t sure what the pros were. Font scaling in IE is a huge one and more than enough to convince me to start using em in place of %.

    BTW, congrats on the Digg and the fantastic conversation you’ve got going on here!

  41. @ryan: It surely looks like you’ve already got a head start over me researching and testing a possible solution… I’m going to spend some time real soon looking into what you’ve done and see what I can come up with too.

    @jbb: You bring up an interesting point, but Jason is right in that he is the person that Web designers aim to please. Given the fact that he uses a custom stylesheet is beyond our control and should be taken into consideration as a possibility. It is our job as developers and designers to convey our content in the most effective, usable, and accessible fashion possible.

    @Matt: I’m glad you found some time to have a read. Thanks for throwing a comment up. I’m really taken back by the conversation regarding this issue — I couldn’t be happier with the result. It has allowed me to read lots of personal opinions on the subject and was great to talk to other people about it. I too for me most part used px units for pretty much everything, mostly because I didn’t understand what ‘relative font sizes’ were at first. As far as Digg… thanks a lot. I absolutely didn’t expect the reaction the article got but it’s crazy. Thanks again for posting, hope to hear more from you sometime soon.

    I’d like to again thank everyone that has commented on this article — there is no doubt that you’ve made the article much more comprehensive. You’ve also inspired me to look into a better way of putting lengthy comment sections on a better display. Thanks again to everyone for taking time to read, write, and discuss.

  42. **sad but i’m still working for the day (and still watching this) 🙂
    feel free to take a look at any of the html/css from my site as a starting point or to mess around with or anything … excuse all the extra mark-up (first build (pre-alpha) of this version of my site). i think my innitial suggestion to jason’s comment should work alright – just:
    html:
    <body>
      <div id=”main-container”>

    css:
    #main-container {
      font-size:62.5%;
    }

    seems to work alright in opera using a local styelsheet.
    the double font-size declaration isn’t necessary unless you want to force 10px for users with their own stylesheet (which may be a worse user experience than jason’s original criticism of the technique)

    i’m done now … i swear 😉

  43. @people who set their own default font size with their own stylesheet.

    The only people who do this are people who are web designers/developers. Yea, sure, there is the occasional 1 out of 10,000 non-computer dork who does this but for the most part it’s computer people. You shouldnt be upset with someone if you come to their site and the type is all screwed up because YOUR stylesheet is messing it up. And if it is messed up youre probably smart enough to hit cmd/ctrl + once or twice to fix the problem.

  44. “If you increase the font size on this particular page is it better?”

    Jon, I haven’t looked at the code for your page – but you must be using fixed font sizes, because the font does not resize AT ALL, when using IE’s View:TextSize option. So it does not matter which setting I use; the font size stays the same – ie. nearly unreadable.

    In my own sites, I never refer to fonts except as percentages: font-size:75% for smallish, font-size:120% for largeish, and so on. Then, the size obey’s the user’s base setting. If the user has good eyesight & sets their base size small, they will see lots of text; but if, like me, they have poor eyesight & can not read small fonts, they just set their base size larger, & it all adjusts automagically.

    HTH,
    TC

  45. @TC: I just opened up the site in IE and tested the ‘View > Font Size’ changes on this site and they worked fine. The text was 100% relative/dynamic.

  46. Once again, I’m sure this is an interesting article, but I won’t read it. Why?

    1. Too long: Writers today are egotistical and like to hear themselves talk. I’m one of them.

    2. Fonts too small to speed read the article.

    3. While I think I agree with the gist of the topic, most clients couldn’t give a rat’s ass about em’s, ex’s, px’s or %’s. They just want their sites. Now. And that sucks.

  48. @ryan: Not sad, I’m the same exact way with this type of thing.

    @David: I can see your point with this comment, but something about the situation still leads me to put at least some of the weight on the developer for some reason. On the other hand I do agree with you in saying that a possible solution is the user increasing the font size to read the site, which is what we’re getting at here.

    @TC: I’m going to have to go with Michael here in saying that I’ve tested the site in IE multiple times to view the text scaling and I think the fault in your comment is where you say that you haven’t checked the stylesheet of this site and therefore assume fixed font sizes are being used. The stylesheet definately says otherwise. The only thing I can think of is that you may be viewing the site with a development stylesheet that was unfortunately cached by IE in your case. What I can recommend is that you clear your cache and try the page again. Thanks for your comments.

    @Michael: Thanks for taking the time to check out this issue — I’m seeing the same results as you.

    @Frakety Frak: I’m sorry to hear you feel this way… but I’m going to have to disagree with a couple things here. Number one, I don’t think that an article’s length relates to a writers ego. I’m not sure why a writer would make an article longer just to read their own words — I think you’re comparing it to certain people who like to hear themselves talk. The article is the length it is due to the fact that I wanted to cover what was written about and thats the bottom line.

    The fact that you view the font as being too small is the entire point of this article. Increasing the font size would bring the design from my vision to yours and you would be able to read it.

    Sure, most clients will not care that the text is scalable. Most of them will never know it is possible. But the people that will know are those that need it to work and are able to make it work. That is the point of the entire article.

    @Ivan: No problem, I’m glad you enjoyed reading it!

  49. Hi Jon

    Now I see what is happening. Your page DOES respond to the IE6 View:TextSize command. I was wrong to say that it doesn’t.

    But you have artificially reduced the size of your text, below the user’s selected default size. So it still looks too small to me, even on IE’s largest View:TextSize setting!

    Moving from Medium, to Larger (my preferred setting), to Largest, produces almost no visible effect, because of this fact that you are reducing all these sizes unilaterally, behind the scenes.

    So I return to my original comment. A properly designed site should not unilaterally ignore the user’s selected default text size! Does no-one else care? Maybe, because not many other people have complained about it, here. Alternatively, perhaps most of the people like me, just take one look – say “it’s too small” – and never read a further word!

    At the end of te day, I can’t see how you can argue against this simple fact: you have coded your page in such a way that many people will imply not be able, or willing, to read it. You are unaware of this, because you personally have 20/20 vision!

    Cheers,
    TC

  50. @TC: I totally understand where you’re coming from, and have increased the text size of the article and comments to compensate. I wasn’t trying to disprove the notion that the text was too small to read — it was set to 11px in print terms. I often find myself using fonts that may be just too small due to the fact that small fonts are a personal preference of mine. But when developing a site such as this, one that aims to please each and every viewer — a more broad approach must be taken. Thanks a lot for returning to post replies and give your input, I hope to hear more from you in the future.

    Are these font size choices easier on the eyes for everyone?

    I’ve also come to the conclusion that more effort must be spent in designing the conversation elements of Monday By Noon. Anyone else become annoyed when trying to comment and having to scroll 10 feet up? I do. So keep an eye peeled for some changes to this in the future.

  51. Nice article… I’m using ems instead of pixels for quite some time now and I think it’s a good technique … it’s also make me write CSS more carefully with less mistakes …

  52. Opera and IE render 1ex as 0.5em which

    I’m not sure what the problem with this is. This is pretty close to the values Firefox claims in the article you mention:

    1 em is 10.06667 pixels, and 1 ex is 6 pixels

    If there are drastic rendering differences, the it is because of other problems.

    Anm

  53. I dont get the whole em/ex conversion to px? Why do you even care about it?

    Do you even know what does em and ex mean?

    story telling time:

    In the good old days, 70s, Donald Knuth, a programmer extraordinaire, was writting a book. When getting printouts he hated the formatting. So created own file standard to ensure proper formatting. The ‘TEX’ system. By itself the tex system was cumbersome to use because it lacked macros and defaults. These were slowly added creating LaTeX and teTeX (most popular distros of tex).

    Anyways, Tex came with methods of ensuring that things had proper width or height, depending on our needs. We had width/height in all the standard printing formats (inch/cm/mm), but also we were given relative width and height.

    Relative width and height?

    YES my dear children, what if you wanted some image to take exactly the height of a normal letter? or width of a letter?

    So we got two measuring units:
    – em – Width of capital letter M
    – ex – Height of lower case x

    This is all great, but what about pixels?

    Bah, what about them? we want our company logo to be 2x larger than the rest of text, set its width with em, height with ex, and we are done!

    Again, pixel discussion, especially when deal with font sizes, is useless.

  54. On another note of font sizes, firstly : I agree with everyone who said this before “default text should have default browser size. Period!”

    Someone pipped in that custom css is not common. True, but I had setup such contraptions to many older people (my parents for one).

    Think about it this way: there is a percentage of users who will consider your website’s fonts too small for them to read.

    Some of them will know ctrl-plus, some of them will have custom css. Either web developers, or older people, a fraction of all people. The rest, majority, will ignore your site like they ignore the classified ads in the newspaper. Set too small of a font and few people will ever bother reading.

    Some developer blogs are already making fun as to how these so called web designers are screwing it all for us:

    http://www.yafla.com/dforbes/categories/blogging/2006/01/13.html#a239

  55. Jon

    Thanks for the dialog, I have enjoyed it. My initial comment was fairly aggressive, so it’s good that you ignored that & responded nicely. We all have our own “hobby horses”; small text size is one of mine!

    Good luck with your endevours,
    TC

  57. @Anm: You are correct — I went on to say that after more research I read that the discrepancy was due to an issue with the Windows operating system on which I was testing.

    @Kadmin: Thanks for taking the time to write out such a lengthy comment. Firstly, I would have to disagree in that discussing font size is a useless arguement. The size, color, typeface, and orientation of a font can really effect the overall design of a site. There does come a time when a design can severely impair one’s ability to read — and that is a problem. In regards to your comments of developer blogs ‘making fun’ of small font sizes: I don’t use smaller fonts because I think they ‘imply professionalism and academic worth’. I’m not sure where this idea would originate from. As you prefer larger text, I prefer smaller text. It is a matter of personal preference that can be argued until we’re blue in the face. The issue that needs to be concentrated on here is the result for the end user, no matter what their preference is, right? As an aside, a quick look at the stylesheet for the blog you linked — a font-size:0.75em is included when styling the body.

    After the three or so impressions on this particular site saying that the font was difficult to read lead me to increase the size in order to accomodate.

    I’m not sure about others — but personally I don’t feel that knowing you’re able to change the default font in your browser has reached a level of common knowledge to accept. I think if I were your average Web surfer and every page I viewed had 16 pixel text I would become irritated. Given, this would naturally provoke me into researching to determine if there was a way to fix such an issue, and in the end would more than likely cause me to adjust my default font size and browse happy. In theory that sounds like an ideal situation — users knowing what they want and how to get it. For the time being however, I would have to stand behind the designer having at least some control over the initial font-size, but accomodate those users that wish to adjust it. This is especially true when it comes to styling headers in design. I absolutely feel that a designer should have control over how headers should be styled and sized. What do other people think?

    Thanks a lot for expressing your opinion — you provided another angle to look at this issue and inspired me to research some possibilities even further. Thanks for commenting and I hope to hear more from you.

    @TC: I’d like to thank you too — thanks for taking the time to express a critical opinion and offer your insight. I’m glad we were able to discuss this with a multitude of people and the conversation happening over the comments has made the article so much more valuable. I appreciate you taking the time to post that screenshot — gives a good visual as to where you’re coming from. I’ve taken a look at the style of the page you compared to MBN in the screenshot, and noticed that they set the font size to 0.75em in the body and 0.95em in the paragraph you’ve captured. I haven’t looked any deeper but from that it appears as though that site is also not using your default font size either. Regardless — thanks for putting in the time you did and helping to make this article more complete. I truly appreciate it and hope to see your input in response to future articles.

  58. Very well put Jon. I totally agree – “I would have to stand behind the designer having at least some control over the initial font-size, but accommodate those users that wish to adjust it.”
    “provoke me into researching to determine if there was a way to fix such an issue” … precisely … the way a user “consumes a site” (as i believe it was earlier referred to in this thread) to some degree lies on the user’s shoulders. as designers it’s extremely difficult (perhaps unrealistic … and maybe even impossible short of a text-only site) to provide a _default_ solution that fits everyone’s needs … but we also can’t provide a solution that eliminates the user’s ability to comfortably access the site (as jason had pointed out in setting the <body> tag’s font-size and relying on it to relatively set child elements’ sizes). the challenge is being able to accommodate as many users as absolutely possible.
    To some degree sizing is going to effect any designed website … otherwise web typography would be essentially reduced to text only non-styled sites (should i use an <h3> here, or an <h4>?). It’s a rather interesting time in web design (imo) with the growing range of resolutions being used. which is actually the reason i began looking into sizing all page elements in EMs. while increasing the text-size on a page whose sizes are set in EMs means that some content may extend beyond the width of a user’s screen … the user can _still_ access the information using those ever so dreaded horizontal scroll bars. imo, that’s the medium. and users with higher res screens will be able to view the layout exactly as intended … while images will scale and be pixelated, readability of body copy (the ratio of line-height to width) will remain intact … the pertinent content is still accessible by them. to _not_ increase the width of a block of copy but increase the font-size might better suit text-only users (as they won’t have to use their mouse to read) it can hinder the usability of a hi-res user (as text becomes more unreadable when it gets to 4-5 words a line).
    as for images becoming pixelated, realistically, hi-res users aren’t getting or expecting higher resolution imagery at this time in web design. imo, the structure or overall layout of the page is more important in most cases (though if it were important that the imagery be displayed at high resolution … a photo gallery or something … an alternate solution for those users could be provided)
    and yes, i also agree “can be argued until we’re blue in the face.” … but that’s my rationale for adapting and trying to further develop the practice

  59. Ryan: Thanks so much for really contributing to this conversation. I can’t begin to explain how unexpected the response to this article was and I’m psyched about it — talk about inspiration to keep going. You raised some great points here, and really helped to push the conversation along. I totally agree with what you’re saying and feel the same way — that designers should absolutely have a certain control over the typography of a design, but it should accomodate to the end user. I didn’t mean to come off ugly when I mentioned ‘blue in the face’… I’d have to agree with you in that it is one of the things that does help me to try and refine my practices both when designing and developing. I hope to see more posts from you in the future, thanks for posting what you have.

    P.S. sorry it took so long to respond, you know how schedules can get…

  60. no, no ugliness … perhaps a little smiley emoticon would have been appropriate following my “and yes, i also agree … ” comment

  61. Just putting some feedback into this article as it was the main one that pushed me in the direction of using em’s.

    I ran into this bug in IE and found a fix for it. Just thought I’d share it. Please note that I’ve only _just_ thought of this and haven’t thought it all through – I did coin the technique Wingus/Dingus font sizing (futurama ftw). Wingus being the size applied to the html element, Dingus being the sizing applied to the body element.

    http://members.iinet.net.au/~malen/em_sizing/broken.htm

  63. I’m not sure if this has alread been mentioned, but for those with visual impairment, IE6 offers all the accessibility of other browsers when it comes to font size.

    All they need to do is set IE’s accessibility preferences properly.

    Tools -> Internet Options -> General -> Accessibility… -> Ignore font sizes specified on web pages.

    Anyone with visual impairment significant enough to need text resizing (as opposed to using a large monitor and lower resolution like most people with disabilities) should simply browse with that option enabled. Then, IE will apply default font sizes and resize them all uniformly.

    Do some research before you moan about IE 😉

  64. Using anything other than the user default as the base (content) size is nothing less than rude. Content paragraphs should never be smaller than browser UI, but that’s what we get here: http://mrmazda.no-ip.com/SS/mondaybynoon1792x1344x168e.jpg
    A fairly simple user stylesheet can fix most of the problems, but it can lead to much too small line lengths, and fails to fix the inadequate contrast problem: http://mrmazda.no-ip.com/SS/mondaybynoon1792x1344x168f-uss.jpg

    “the default font size for ‘medium’ text in browsers is 16px” is false. The IE6 default is 12pt. Most other non-Gecko browsers also size the pref in pt, like word processors size text. At the M$ default 96 DPI, this happens to work out to 16px, but not all M$ systems retain that DPI setting. M$ labels it “large fonts”, and users who find things too small in doze do use it more often than you might think. More importantly, High resolution laptop vendors typically pre-configure to this 120 DPI setting. The result of 120 DPI is that 12pt equates to 20px instead of 16px. Now that laptops outsell desktops, “large fonts” are a lot more common than they used to be, and presuming a 16px default is clearly more presumptuous than it used to be: http://mrmazda.no-ip.com/auth/bigdefaults.html
    For more detail on what modern browser default sizes actually are, read:
    http://lists.css-discuss.org/mailman/private/css-d/2006-January/057975.html

    Just because you’re using em to size text doesn’t automatically make your page accessible. 9pt/12px text, which is the result of the Clagnut 62.5% on body coupled with 1.2em on paragraphs for a user with a 12pt/16px 96 DPI default, cannot be resized up to 14pt with the IE text resizer. Many senior users need 14pt, as do other low vision users. For one of them who has already set 14pt with the “larger” widget setting, there remains only one increment available, and it fails to bring your 9pt text up even to 12pt. Examples of this elsewhere you can find in screenshots on http://mrmazda.no-ip.com/auth/pxmonkeys.html

    Designers should stop thinking px, simply wiping its existence from their memories and toolboxes. Px is for lazy designers, and aren’t necessary. They make magazine and poster pages for hosting on the web, not pages designed for the naturally fluid web medium. Including px as a valid unit for setting CSS font sizes was a spec mistake. At a 16px default, 1px is .0625em. If want a 10px border, set the border width to .625em, and you get a 10px border when the default remains 16px, and a perfectly scaled border when the default is something other than 16px. Visit my home page in any GUI UA released this century, and you can see unlimited zoom and unzoom nicely handled, without a single size designated in either px or % in the CSS.

    Widths set in px need to go to. Fixed width pages lead to inordinate whitespace for widescreen and high resolution visitors (this page also free from sizes set in px or %): http://mrmazda.no-ip.com/SS/bbcSS.html

    Another spec mistake was permitting any units for line-height. http://mrmazda.no-ip.com/auth/line-height-inherit.html demonstrates that problem. Font: 76%/1.6 creates more an illusion of improved readability and a factual improvement. The best readability, as long as line lengths are kept optimal, is with the user’s choice of font size, and normal leading. Extra leading makes a web page look like a double-spaced high school term paper – amateurish.

    I find reading this page easiest by turning off your styles entirely in the view menu, same as with most CSS-styled pages on today’s web. That’s sad.

  65. To be fair to IE, the next version has zooming built in to magnify the page.
    But if we look back on Mozilla ond Opera’s history, it took it’s time to reach microsoft.

  66. I hope that every reader of this article takes the time to read Felix’s writeup. There are some good links there and he brings up some valid points.

    @Felix: I’m sorry that you’re forced to view this page with no styles — but on the other side of the coin isn’t it good that you’re able to do it? Personally I don’t have an issue with font sizes as I prefer smaller text, but I am one person, and developers need to aim to please everyone. Thanks for taking the time to write such a comprehensive response.

    @Tom: Agreed, Internet Explorer is definitely making leaps of progress with their latest version.

  67. […] As it stands, an author’s style sheet declarations will have precedence over any styles defined within a user’s style sheet. To level the playing field, we find !important. Adding this keyword combination after any declaration in your style sheet (as a user) will give your style the power to overcome what has been defined by the author. This returns the control of the style to the user, and is a good thing. Your site should look just fine if someone wants to change the font size you chose, right? […]

  70. Nice Article. I have also practiced this article, and it will be usefull for the learners like me. Also it will help me in the interviews.
    Thanks.

  71. […] The heading itself is given a position:relative which acts as a reference point for the span. The span is styled with position:absolute, positioned to the top left of the heading and given a height of 0.55em. Using em will render as half of the parent elements font size, which is essential for the technique. Setting display:block and overflow:hidden allows us to cut the span in height to create the DuoTone effect. Setting a different color to the span and its parent heading finishes the technique. […]

  72. […] There have always been things about my site that I wasn’t happy with. I’ve built it out so much over the past year and a lot of it felt (and looked) tacked on. Every time I open my stylesheet I cringe at the sight of some old habits I’ve since broke and always wanted to go back and rewrite it. But really, who’s gonna do that? Not this guy! I a lot of changes that brought my CSS up to a state that I can at least live with until I do a full redesign. I changed all my font units from percentage to em. I never really knew the full advantages of em over the other units until I read Effective Style with em over at MondayByNoon. A great read if you’re not fully in the know on that topic. I also removed pixel units from everything with a value of zero – another bad habit of mine. And lastly, I revised all my colours and shortened those that duplicate to 3 characters. It’s funny how long it’s taken me to change my ways. Every CSS or Web Standards book I’ve read has always shown the proper way of doing things, but I never bothered to change. Old habits die hard, I suppose. […]

  73. With Mozilla Firefox, it doesn’t matter what size the font is in a sites CSS. As long as the CSS incorporates EM for font-sizing, (as the article is all about) – the text can be resized to the readers preference.
    CTRL and + or – will increase and decrease the font size respectively.
    Thats the biggest advantage of using EM over PX.
    I believe IE has the same effect – but, other than for testing, who uses that anymore?!
    PS. First time vistor, found you from MattBrett.com. Other than the pale grey text for the comments, this site is inspirational to all designers.

  74. @Stephen: I’m really glad you’ve found the site, do you feel that the comment text should be darker than it is? Do you find it difficult to read? Thank you very much for the compliment.

  84. @Justin Kistner: I had similar thoughts when I published this article. I’m glad it was widely received as a good discussion was formed and a lot of different views were thrown into the mix.

  85. […] As with every site, there are going to be some articles that act as it’s “claim to fame”. I’ve definitely got a couple. Firstly it was Effective Style with em. This was an article I had written about using relative font size (specifically em units) to control the character size of your document. I was blown away by the response, and in my opinion, a really intelligent conversation was held after the piece was published. […]

  86. Interesting read – great comments.

    For those of you who liked the comment by Felix – and let me first say that for the most part, I agree with what he has to say.

    But, before you annoint him, you should load up IE – I’m using IE7 (yes, IE, like 60-70% of the rest of the world) right now – and then load this page of his and make your own judgement.

    http://mrmazda.no-ip.com/auth/auth.html

    regards,
    Mike

  87. Very good article, the comments are even better!

    – The 62.5% default text side seems not a good idea, because in ie6/ie7 even the largest setting is small for many visitor (especially on large resolutions). Ie7 “zoom” (and any other zoom like Opera etc.) for me is useless and ugly (I want to size up only fonts not images)

    It’s worth to visit Felix’s site: 100% of ie users when see the the “nice” popup go away and never come back 🙂

  88. An interesting post with very interesting comments. I wandered in here because I’m looking for an answer as to why things break for some Windows “120 DPI” users. Rather than increase DPI and therefore shrink sizes, it just seems to reset the system default fonts …or some such behavior… which then breaks some layouts (such as navigation) because they see HUGE fonts all of a sudden.

    If there’s ever a follow-up along these lines, someone let me know.

    Meanwhile, I enjoyed reading Felix’s comments because he addressed the 120 DPI issue which is increasingly common.

    However, his site is wholly unreadable and absurd. (Heh. Post script: yeah, I launched IE7 just now to see that javascript popup which was incredibly annoying.)

  89. @Mike: I’m a big fan of Felix’s reaction to this article. His points were well supported and his opinion is more than valid. I just wish that more people knew they were able to set the default text size in their browser in an attempt to take advantage of everything he said.

    @ak: I’m not a huge fan of ‘full site’ zoom either — it interferes with the concept of relative font sizes. On the other hand, it provides a way for designers to have their design keep it’s proportions and shape even when they don’t mean to. Personally, I think one or the other should be chosen and adopted by browser makers simply due to the fact that regardless of your choice, your design will not behave as intended in one environment or the other.

    @Romer!can: The comments really make this article, there’s no question about it. Personally I haven’t had the opportunity to work with various DPI but it’s something that absolutely can not be ignored as time goes on. Thanks for stopping by and including your thoughts — I hope to see more of your comments on future pieces.

  90. Nice article, although i do not fully agree.
    Basically i’d never touch the basic font size. This is chosen by the user and should not at all be altered. Then when you see this font size as 100% it’s easy to set other font sizes in percent. Although em would do as well. The main benefit for the em unit is not for sizing fonts, but for sizing boxes. On high resolution large screens the user probably has a larger font set up. Not altering this prevents text lines from getting too long. Sizing the navigation and main containers with em units keeps the page proportions to a best compromise between screen size and user selected font size.
    So as a summary: Never size the standard text and use some relative sizing for other texts, always referring to the user selected font size. Wether you use em or percent is not that importent. Use em units to size the boxes on your page.

  91. @Siegfried: It’s very difficult to resist altering font sizes in design (for me at least). I absolutely agree with you in that using relative sizes for element dimensions can really help the visual scalability of your design. In my personal experience, the default font size in a readers browser is merely the default with which it was installed. Many people don’t know they can alter the default font size.

  93. I just discovered this article – thanks a lot for explaining how to use em for scaling text.
    Best regards from Germany

  99. Holy crap, who would have ever thought there was so much to say about em? Not only a huge post, but there are tons of comments!

  103. I found this article extremely useful and well written. This is all something that I know I need to start putting into practice, but needed to fully understand first. Thanks again.

  118. […] Effective Style with em 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… […]

  126. […] 调整好字号，字体，我的blog默认启用的是1.6em的大号字体，在小屏幕上看实在有点挥霍空间了，有必要调小几号，我一直都是em字号方式的拥护者，为什么？见Effective Style with em。 […]

Leave a Reply

Your email address will not be published. Required fields are marked *