What strategy do you use for setting Font Sizes on your web pages?
My SitePoint book implies that you should favor Em’s.
My HeadFirst book says you should set the Font Size on the <body> tag to a Keyword, and then specify Font Sizes for all other Elements to either Em’s or Percentages.
What do you think is the best approach?
Debbie
The contents of that link don’t prove anything to me.
I also don’t see how looking at wordpress or joomla code will prove your opinion that
[I]
Well remember, most people can’t even master the simplicity of inheritance and specificity…
[/I]
All it would show me is what joomla and wordpress code looks like.
All the proof you need. 
That or go to any wordpress or joomla based site and hit ‘view source’. You want to see inept coding, NOTHING beats a custom wordpress template.
I’m not sure that is correct.
Setting the body to 1em will mean no change at all because 100% of 100% is still 100% and is therefore unnecessary.
However setting the body to 1em will incur the scaling bug in ie7 and under and instead you should use 100% instead (which is the same thing but doesn’t trigger the bug in IE7.)
I don’t see why it should - I wouldn’t have thought it’s rocket science to work out that 80% of 80% of something = 64% of that something.
I would also have thought that using px for font size is a no-no because a 10px font-size is going to appear large on a low res. screen and very tiny on a large res. screen.
As I said before keywords are ok but you don’t know if they will be the same between browsers and you are limited to the scaling factor that the browsers provide between each keyword so there may be variance in the sizes you get. You can’t for example make text 1px larger using keywords alone and would have to revert to ems or percent to do that so you may as well stay with ems from the start.
Historically keywords haven’t been used much because all versions of IE in quirks mode and IE5 are one complete size out compared to other browsers.
The default is medium anyway which is basically the same as not specifying a size anyway.
As I said it’s matter of debate/choice as to which method you use and these days with browsers that can zoom the issue isn’t as bad as it was as most browsers apart from IE can zoom pixel sizes text if needed (IE7/8 can only zoom the whole page).
The best answer is basically to do nothing and then set your sizes for your elements in ems as required. This creates a layout relative to the base size of the browsers default and respects the settings that the user may have set. Usually the body element is set to font-size:100% which cures the IE text resize scaling bug otherwise the page resizes disproportionately.
I guess I don’t see the difference between this and using KEYWORDS like my Head First book suggested?
If I do it the way you mentioned above, then everything is relative to the font set in the user’s browser, right?
So if the user changes the Default Font to LARGE then all of my font would scale relative to that, right?
By contrast, if I set everything to a KEYWORD (e.g. Medium), then everything is also relative to that font size, right?
And if the user changed the Default Font to LARGE, wouldn’t that over-ride the KEYWORD I set?
Not sure if you follow me?
Debbie
That’s one of the questions that’s likely to start a war as there are many different answers.
The best answer is basically to do nothing and then set your sizes for your elements in ems as required. This creates a layout relative to the base size of the browsers default and respects the settings that the user may have set. Usually the body element is set to font-size:100% which cures the IE text resize scaling bug otherwise the page resizes disproportionately.
Keywords are ok but they are not standardised between browsers and nobody uses them much these days apart from triggering 13px font size in IE which can then be scaled using ems (see faq).
There are many threads around on the subject and you will likely get many different answers depending on perspective.
http://www.sitepoint.com/forums/showpost.php?p=1239970&postcount=6
But how does all that prove your opinion that
Well remember, most people can’t even master the simplicity of inheritance and specificity…
I never said that everyone understands inheritance - what I said was that I am not sure that “most people” don’t and I still haven’t seen any proof that most don’t.
Good question :scratch:
I haven’t actually tried it, but my understanding is that a font-size of 1em will set the font size to whatever default font size the user has set in their browser.
A font size of 1.5em will set the font size to 1.5x whatever the default font size is in the browser.
To see for sure, you can set up a simple “Hello World” paragraph and play around with the css and browser font sizes and see what happens
I’m not sure if setting css styles for <html> is the same as setting it for the <body>. By convention I have always normally set styles for the <body> and its children.
No, it uses that as the starting point. If you have your browser default text size at 14px, and I then set, for example, h1 {font-size:1.5em;}, you will see that at 21px. But Myopic Meg has her default font size at 30px, so she would see the heading at 45px.
That’s why you should use ems or %, because it then reflects the user’s default size, which using px doesn’t. And as Paul said, keywords are just a bit too rough-and-ready, and inconsistent.
Why do you set it in <body> ?
Why not <html> for instance?
Why? Why not? Why not why? I’m not aware of any reason to set it on one or the other, but you’re more likely to be setting other styles on the body element, so you might as well include the font in there as well.
Does that over-ride the default font size the user has set in his/hr browser?
Why do you set it in <body> ?
Why not <html> for instance?
Debbie
yep, I guess I just went about pointing out the fact that em is relative to the browser default size in a roundabout way.
my :twocents: - I would use em.
I set a default font size for the <body> in the css and then set appropriate sizes in specific elements if required.
Okay, just clarifying.
As I said it’s matter of debate/choice as to which method you use and these days with browsers that can zoom the issue isn’t as bad as it was as most browsers apart from IE can zoom pixel sizes text if needed (IE7/8 can only zoom the whole page).
Okay.
Thanks,
Debbie
Well remember, most people can’t even master the simplicity of inheritance and specificity, which is why the slap classes on everything and extra DIV around everything for no good reason
Because in many older browsers HTML is a non-rendering element, so you risk it being ignored. Mind you, that’s mostly older pre-IE6 browsers that applies to, but with 80% of windows mobile handhelds still running IE 5.5 (since IE6 has only been available on win mobile since 2008, and then only on Win mobile 6 sp1) it’s simpler to put it where you know it will work every time instead of running the risk of someone complaining.
It’s why as a rule the only thing I’ll set on HTML is height:100% and overflow:hidden when making 100% min-height layouts – it’s safer for anything else to pretend the HTML element does not exist in your CSS.
Oh, I didn’t see it mentioned yet, but you should keep in mind that % and EM are based on the currently set value. As such if you declare 85% on a P when you have 85% on body, you’re going to get 12px at 96dpi, not the normal 14px (well, 13.6 rounded up) – 85% of 85% of 16px… just as 120% on body and 120% on a child would give you 144% of 16px @ 96dpi. ALWAYS remember it’s relative to whatever was set before it.
That little nuance is what makes a lot of designers go screaming back to using PX for everything flushing their accessibility down the toilet.
Keywords would be one of those “what is this, 1995?” moments. The WCAG recommends %/em, so use %/em.
Personally, I like to set body to 85%/140% (second number is line-height!) for most sans-serif fonts, though I’ll sometimes drop to 80% for verdana or ms trebuchet… 85% delivers basically 12pt (14px@96dpi/17px@120dpi) in most cases, the ideal size according to research on the subject.
Mind you that’s for e-mails, but it seems to apply well to websites too. (and they are talking pt, NOT px!) though as they noted, just changing the face changes that rule – verdana seems more comfortable at a smaller size. Serif fonts because the serif’s dirty up the font thanks to the low DPI generally need larger sizes – which is where that 100%=16px @ 96dpi number originally came from for Times New Roman… Even TNR isn’t all that legible that small even on low pitch displays, and more heavily serifed fonts typically require 20px or more for the best legibility (100%=20px @ 120dpi)
It’s also important to understand the different behaviors of each font size/type. I wrote a page some time ago that shows how all the different renderers behave when sent different values.
http://battletech.hopto.org/html_tutorials/fontCompare/template.html
The side-by-side comparison about halfway down the page shows what/why/where (and why anyone who needs accessibility doesn’t use gecko based browsers like firefox and gets annoyed with IE8’s new behavior).
You also have to ALWAYS keep line-height in mind. You change the font-size, change the line-height. That’s illustrated on that page as well at the bottom, where the font-size is changed but the line-height remained fixed. (that one can really confound nubes)
Finally, always keep in mind you magic font might not exist, might be outright ignored, hence the use of fallback families… sometimes it’s better to err on the side of too large should your font not exist and the default one be too small. There are also cases like image interactions where you may find yourself forced to use PX for compatibility between different system metrics (even if FF completely screws the pooch on that by resizing PX when it shouldn’t!). In that case keep in mind the above 96dpi numbers as the minimums for 120dpi users – so go below 14px at your own risk. 12px/smaller should be avoided at all costs unless it’s something like a menu that’s in all-caps…
Oh, yeah. All-caps buys you about 15% size on legibility, but really should only be used on single words like in menus.
Ah, the joys of a screen target.
So basically you don’t know what’s wrong with mountains of ineptitude like:
<div id="wrapper">
<div id="header">
<div class="logo">Site Title</div>
<div id="topmenu">
<ul id="topmenulist">
<li class="linkitem">
<a href="http://www.somedamnedsite.com/" class="linkAnchor" title="Home">Home</a>
</li>
<li class="linkitem">
<a href="http://www.somedamnedsite.com/faq" class="linkAnchor" title="FAQ">FAQ</a>
</li>
<li class="linkitem">
<a href="http://www.somedamnedsite.com/aboutus" class="linkAnchor" title="About Us">About Us</a>
</li>
<li class="linkitem">
<a href="http://www.somedamnedsite.com/links" class="linkAnchor" title="Links">Links</a>
</li>
<li class="linkitem">
<a href="http://www.somedamnedsite.com/forums" class="linkAnchor" title="Forums">Forums</a>
</li>
</ul>
</div><!-- end Top Menu -->
</div><!-- end Header -->
</div><!-- end wrapper -->
<div id="wrapper">
<h1>Mayor takes million dollar payoff</h1>
<p>Some text explaining that</p>
<h2>Look! Kittens!</h2>
<p>Kittens are cool</p>
</div><!-- end wrapper -->
That abounds in site after site after site that people end up asking for help for, or that template after template after template serves up? Can you list all the most likely stupid mistakes in the above code? On most websites there would be ten general ‘types’ of error totalling 28-30 ‘common mistakes’ that are a perfect example of what I’m talking about.
… and usually 70-80% of the people asking for help in the forum I linked to have these errors, and prior to WP3, every wordpress template was equally guilty of those bandwidth wasting mistakes – some of which are just ignorance of known bugs or failure to grasp semantics, but much of which is a failure to grasp how inheritance works… specifically the ‘cascading’ part of cascading style sheets.