Forum Moderators: not2easy
The only argument I don't care to hear is "what if the user uses their own stylesheet to change font-sizes?" - as far as I'm concerned, there's absolutely nothing I can do about that - save having entire websites as images - which is not feasible :) If they need to use their own stylesheet then so be it - we don't need to worry about it if we can do nothing about it, right?
I've seen the 76% method:
body { font-size: 76%; }As far as I knew, this had the most consistency - in every browser tested by the Noodle Incident [thenoodleincident.com] this made all fonts exactly the same in size. That's a big pro. A big con is the knowledge that this is completely dependent on the base font-size of the browser being 16px. This is fine for IE 6 and 7 (since there is no option to change base font size) but for Firefox, Opera, and Safari the base font-size can be changed at will. Seeing as 76% to that value is a fairly big change, it can make your font-sizes look extraordinarily small. Legibility is paramount.
I've seen the 100.01% method:
body { font-size: 100.01%; }While this one doesn't have as much consistency (from what I've tested, Opera OS X and Safari display the font sizes slightly bigger, with Firefox [OS X & Windows] IE 6, 7 and Opera Windows displaying consistently) it does have slightly more flexibility - if a user has specifically set their font-size, we can naturally assume they like it to be of a larger or smaller size. This will not change that (the .01% part is to overcome a bug in previous versions of Opera [previous to the current one at 9, I believe] that rounded the 100% to 99% or something silly (don't quote me on that :D) To me, this is a better option than the 76% method one.
(I currently use the 100.01% method :D)Then there's good old absolute font-sizing:
body { font-size: 16px; }.. which is bad because neither IE 6 nor 7 can resize the text through their browser control, View > Text Size. This is worse than the top two, however the web is probably more saturated with such sites, since it was the norm around the last century :)
So...
So, I thought, since IE 6 & 7 can't change base font-size, it's always 16 (unless they add their own stylesheet yada yada don't care,) to have readable text resizing couldn't we use...
My proposed method:
<!--[if IE]>
<style type="text/css">
body { font-size: 100.01%; }
</style>
<![endif]-->(I... don't think the .01% needs to be there, I'm fairly sure that only affected Opera, but someone needs to confirm that for me :D)
And then for all the standards-compliant browsers:
<style type="text/css">
body { font-size: 16px; }
</style>
.. seeing as all standards-compliant browsers have the ability to change absolute font-sizing at will?
Questions, comments, approvals and disapprovals welcome.
But well done on your approach as well.
Fotiman that Yahoo fonts CSS is interesting and if someone can help explain the logic in the first rule to me I might be tempted to take a closer look at it. I was immediately put off it when it opened with a hack, I especially hate hacks when they're unexplained
so 2 questions..
Why the 13px base?
and what's that hack doing?
body {
font:13px arial,helvetica,clean,sans-serif;
*font-size:small;
*font:x-small;
}
The reason I ask about the hack (I know that it's primarily a method to feed IE a value which allows text resizing) - how does it work, never seen that one before - why does IE6 & 7 (standards) not see the third font size?
Suzy
[added]
having a fair coloured hair moment :o
Q1 - 13px = small/x-small size (depending on render mode)
[edited by: SuzyUK at 9:19 pm (utc) on Feb. 28, 2007]
Curiosity: can we reliably assume versions of IE to handle percentages properly? Say, enough for us to allow the base font-size to be the size of our main copy?
Just for IEs:
body { font-size: 75%; }For standards-compliant:
body { font-size: 12px; }Has anybody heard of calculation problems with IE? Where 16px * 0.75 might equal 11px in IEMath...
Or, on the flipside, has anybody heard of calculation problems with the standards-compliant browsers? Where setting an absolute base font-size ruined something?
How about:
body {font-size:1em;}
h2 {font-size:120%;}
p {font-size:90%;}Or:
body {font-size:99%;}
h2 {font-size:1.2em;}
p {font-size:0.85em;}Seems to work for me, I guess it depends what browsers you are wishing to support - I don't do Tantek hacks or such to support IE5.x any more, they'll just get the text a bit bigger that's all. Konqueror has a smaller default font size, so your page text will respect that default and be smaller. IE6/7, Firefox and Opera all do the same thing. You can do something similar to the above with font-size keywords too.
I'm not sure of the reasoning behind the complex hacks here, assuming you're in standards-compliance mode. Setting font-size is as complex as you want it to be. If you're looking for a pixel-perfect design and are prepared to use every possible hack just to make things fit in this week's current browser favorites, then you might as well just stick to tables and font tags.
In other words, the desire to set an absolutely identical text size across all browsers is not the description of the problem, but is the problem itself. :)
The IE conditional comment is problematic on a couple of levels - firstly, using it at all is a defeat in itself, trashing the promise of cross-browser CSS compatibility and returning to browser-specific code (which standards were supposed to protect us against).
In an ideal and fair world, brilliant, we wouldn't need to ever check how our code renders in more than one browser, should we? They should all render the same.
But we don't. Standards are meant to protect us, but they don't.
Secondly, on a more detailed level, you're sniffing for "IE" without checking version numbers. What about IE8? You've have code which is browser dependent and not stable over the long-term - you'll be forced to check each time a new IE is released. (This is not to reject all usage of IE Conditional Comments, which are often the "lesser evil", but they should still be seem as a last resort.)
Sorry, I didn't use version numbers because it was examplified - I'd imagine for 6 & 7 do what I suggested, leave IE 8 alone for now.
I'm not sure of the reasoning behind the complex hacks here, assuming you're in standards-compliance mode. Setting font-size is as complex as you want it to be. If you're looking for a pixel-perfect design and are prepared to use every possible hack just to make things fit in this week's current browser favorites, then you might as well just stick to tables and font tags.
The reasoning was to find a way to make all browsers display their font sizes, at least at their "normal" or "medium" setting, at the same size.
And it's not for pixel-perfect - perhaps exactly the opposite - it's to create fluid layouts that can expand with font-size.
Imagine a vertical menu with a content area side-by-side. Imagine, if a user has their text size set to Larger rather than Medium, or 110% rather than 100%, that they see exactly the same website, have exactly the same whitespace, no matter what?
Imagine what happens when Scalable Vector Graphics are widely supported? Imagine sites that scale entirely, perfectly, just as if it were a Flash website?
In other words, the desire to set an absolutly identical text size across all browsers is not the description of the problem, but is the problem itself. :)
On the contrary, I don't believe it to be a problem, I believe it to be the future :)
There are many discussions of not only font-size but line-height (whitespace) line length for readability, and box width (sized in ems) which are all dependant on the base font size. What has been found so far is that the whole resize thing/scalability of a page works better if the base size is set in pixels (relative to the screen resolution). there are not so much extra/missing borders, gaps etc more consistent typography settings.. The whole idea of using pixels and fluidity might be more widespread if IE resized pixels but it doesn't. The Next thing is the x-browser handling of the maths calculations to me it matters not if that calculation is actually pixel perfect rather it's at least a measure which allows you to do other calculations especially line height without taking a stab in the dark or using guess work in other words it doesn't matter if the base size is 13px or 16px as long as you have a base it makes the counting logical.
And it's not for pixel-perfect - perhaps exactly the opposite - it's to create fluid layouts that can expand with font-size.
That's exactly it.. the pixel is not an absolute unit - as Zelman says in DWWS - It's Absolutely Relative. Getting the all important "base" as consistent as possible allows us to think forward and build fluid layouts which also adhere to the "readability rules" in as many cases as possible too.
There is perhaps a much simpler truth behind all this - Screen is not the same as Print, so while typography line length/height may be caluculated by letter size in print which would be em's on the screen, just about anyone who designs for screens, or watches TV knows what a pixel is.
The pixel is relative to screen resolution as letter size is relative to paper. Almost all browsers handle pixels consistently now.. the old NN4 and Opera6? blips are a distant memeory for most.
So pixels in a stylesheet are not necessarily a sign of designer "control" - like everything else they have been abused or misunderstood and should now be looked at for what they are, a relative unit.
Setek I have no proof but just gathering from what I can read - the % method is touted to more reliable at resizing with consistent rounding of the pixel value than ems. ems are also font family dependant which adds another variable to the mix in any calculations I suppose.
I have looked at the keyword method now - found out why that "font" hack was working - and I believe it may well have legs as a method, (can be used without the hack though the hack is only back compatible so.. depends on your view) I'm not sure if it's any more advantageous starting IE with keyword rather than a percentage, would need to look further - it just seems logical that it might be.. and if Yahoo have put it in there grids then you have to think someone knows something ;)
will look some more later, would welcome your thoughts if you've tried it
Suzy
Setek I have no proof but just gathering from what I can read - the % method is touted to more reliable at resizing with consistent rounding of the pixel value than ems. ems are also font family dependant which adds another variable to the mix in any calculations I suppose.
Ooh brilliant, I knew using ems were a little worse than using % because of different font families, yet for some reason completely forgot it :)
As for keyword vs. percentage as the initial base (just for IE) I don't know, unfortunately I haven't had an IE 5.5 or under test box for quite a while :/ I can look at (if any) differences between keyword and percentage on IE 6 and 7 though :)
When making the base font-size 10px, then applying 1.2em on top of that, I would expect 12px?
In fact, when changing fonts to something else, I would expect the percentages to continue being 12px, where a thinner font would provide me with different values had I used ems.
I found using 1.2em gave me consistent 12px, whereas 120% gave me consistent 11.9333px. Though I noticed no time with the different fonts I'd used (Tahoma, Trebuchet MS, Verdana, Arial, basically all the websafe ones) where the 12px differed from the 11.9333px (or it was so infinitesimally small a difference to the human eye) that it didn't really matter.
Just thought it was interesting.
I wasn't looking for 'actual' pixel perfection of the font rendering size, rather scaling stability ;) I just wanted to see if there was any advantage to using the keyword value over the percent hack for getting IE to scale in the first place (both are user based anyway) and then if so was there any reasons why yahoos grids are using 13px with the
small/xsmallmedium/smallMy suspicions were aroused when at the bottom of the grids fonts page in order to scale 13px up to 26px they tell you to use a value of 197% - huh? ermmm shouldn't that be 200%!
The reason I thought this might be important is if 200% is not 200% or 2em how would anyone calculate an approximation of a 200px wide column to ems using this method - and what impact would that have x-browser.
So I also added into my test two coloured divs one sized in px the other in em which is part of the point of this is it not.. not only to get a consistent base font-size but more importantly to follow through to liquid/scalable layouts? (anyway if not it helped demonstrate what I'm about to tell you I found)
First off I tested the Y!s 13px with
small/xsmallresult 1: nice and easy to use in conjunction with Y!s 'ready reckoner table' but no use as a tool for x-browser liquid layouts.
Next I tested the same thing but with 16px and a
medium/smallresult 2: fine if you can base whole site on 16px, it's nice easy counting - and I have to wonder why the Yahoo Grids aren't using 16px/medium/small as their base? It would make their calculation table easier ;)
Next I was testing why use the keyword values at all - even if medium is an improvement over small in the first 2 x tests, why not just use 100%? 'medium' equates to the user default as does 100% - and if you use 100% you shouldn't need the IE5.x hack just the conditional or 1x parse hack (whatever your pref!)
So I tried the 100% value against all the same tests as
mediumresult 3: no difference when default
mediumSo then I set about checking the stability of resetting the base font to be smaller using the percent method to see how it compared the test 1.
I reset the base font to 13px/81.25% - interestingly the font size scaled up with no noticeable differences up to 52px/400%/4em (overkill but just checking)
Box width differences did sometimes occur again - BUT this time they're not compounding - they are purely rounding differences 0-4px depending on chosen width (in my tests). The result was the same if the base font was set to 16px/100% and then a nested div used to scale body down to 13px.
So in conclusion your OP method is the right one to choose IMHO
- I'm not going near the keyword method.. because even while its differences are not so noticeable until larger font sizes with one of them - it does have much greater repercussions with both when it comes to getting flexible with layouts. The percentage method is just about as perfect as it gets - there a few small rounding error problems x-browser but they are not compounding and to me they come into the "non pixel perfect" part of the reason for using them then. Oh and I wouldn't go much lower than 12px/75% as a base for calculating em widths because of users being able to set a minimum font size. ems will be based on their minimum which I know is the point but I'd not be basing a layout on an unrealistic minimum like 10px on a large screen resolution.
YMMV of course but I'm glad I took a closer look.
Suzy
I found no difference between using % or em to actually scale the fonts, my test results where the same using either method.
e.g. in the following
First off I tested the Y!s 13px with small/xsmall and sure enough it needed the 197% to match the 26px font.
In the above case I also confirm it needed 1.97em instead of 2em (for IE to match font)
Sorry should've clarified more - I didn't mean it to look like I ignored your point, and I'd only looked percentage scaling :oI found no difference between using % or em to actually scale the fonts, my test results where the same using either method.
That's cool - just wondering if it might've led to a difference with the whole 13px and 197% :)
So in conclusion your OP method is the right one to choose IMHO
- I'm not going near the keyword method.. because even while its differences are not so noticeable until larger font sizes with one of them - it does have much greater repercussions with both when it comes to getting flexible with layouts. The percentage method is just about as perfect as it gets - there a few small rounding error problems x-browser but they are not compounding and to me they come into the "non pixel perfect" part of the reason for using them then. Oh and I wouldn't go much lower than 12px/75% as a base for calculating em widths because of users being able to set a minimum font size. ems will be based on their minimum which I know is the point but I'd not be basing a layout on an unrealistic minimum like 10px on a large screen resolution.
Lovely, thanks for the affirmation :)
I was thinking actually of using 10px as the base but never actually use it - barring for calculation purposes...
body { font-size: 10px; /* w/62.5% for IE */ }
div#content { font-size: 120%; /* change body copy to 12px */ }
h1 { font-size: 240%; /* change headings to 24px */ }This way, it becomes much easier to calculate what font sizes to use - rather than leaving base copy at 12px or 16px (which was my first want, being the default and all.)
Calculating with a base of 10 is easier since at heart, we're all decimal, no matter how hexadecimal some people would like to think they are :)
