Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: not2easy
em is a relative size, and thus lends itself better to being resized. IMHO, the other two are only useful for your print stylesheet.
I actually think it's easiest to size with PX because you know exactly how big to expect your text to be. To circumvent IE's issues, there's a little trick you can use to make EM sizing relate easily to PX sizing. Set the base font in the <body> tag to 62.8%, then use EMs throughout the rest of the style sheet. The result is that a 1.0em setting approximately equals 10px. It's not precise, and, of course, is different depending on different fonts, but as an approximate guide, it works well. This way you can choose your EM sizes based on a roughly equivalent PX scale...
1.0em = 10px
1.1em = 11px
1.2em = 12px
... and not have to do alot of Save/Refreshes in order to make sure the text is the size you want.
Here's an older thread [webmasterworld.com] on this topic you might want to look at, as well.
As for involving percentages with ems, I acknowledge that it can produce today almost similar results in different browsers. However, notice that I said "today", because we do not know what will happen tomorrow, especially if Microsoft decides to save its sorry (!)--from the much appreciated, slow but steady increase of Firefox browser market, by complying accurately and faithfully with web standards in a new IE that ships with Longhorn or something. So if you have continuous control over what you code, no worries, but if you are selling something or giving it away into the control of others who are not CSS savvies, you may want to be careful of your choices.
If you want your pages to render consistently, you should use absolute base values (and then, if you wish, relative values based on these).
I use pt rather than px, because I know from experience how large 12pt is etc. from using word processors.
My base style sheet specifies all fonts for H1-H6, P, BODY, TABLE, etc using pt. I know that some people will say that this inhibits text resizing in IE, but, unlike some people, I consider this to be a good thing.
You personally prefer keeping your text on your web pages in a fixed definite size, because you personally feel it looks so much better; you may also be a web designers or developer with good eyesight or good glasses or generally no problem whatsoever reading 10px paragraphs, and 8px captions and copyright notices, and I also personally love my paragraphs in that size, too. However, there are thousands, maybe millions, of people--with good eyesight--who get annoyed at such sizes and simply call it too small, then there are thousands others with weak eyesight who find it very hard to read such sizes, etc etc.
So I just had to ask myself: am I designing for me or for my visitors? If it's for me, then by all means I can go for 10px paragraphs, but then again, I say it's even better to go for 1em and use Firefox, so I can see my paragraphs at approx. 10px, and if I want them even smaller, all I have to do is decrease the size one step down. On the other hand, if it's for my visitors, then it is definitely for my interest to not upset or annoy my visitors by taking away control from them and preventing them from changing the text size by assigning px or pt sizes to it, instead of em and percentage sizes.
Forgive me if I don't know enough about em's, but aren't they only semi-relative? Don't you need to set the size of 1 em before using it? And why are em's better than %'s?
However, without a base font size the same thing applies to percentage. You do not know what the user or the browser's default is, and thus a percentage without a base font size is just as a wild guess as an em without one.
I can also say that em may be better than percentage because em is a unit by itself, and regardless to details, units generally feel more accurate than percentages.
Furthermore, em may be better than percentage because when a developer uses em to specify font sizes of the links of a navigation bar, for instance, he/she can later on use em, too, to specify the sizes of the box elements that surround those links; and this is much better if one wants the whole page to consistently and harmoniously increase and decrease in size with the text, or by other means, zoom in and out. Whereas, using percentages for box elements refers to a completely different base or reference, most probably the parent element itself, like the parent div or so.
Finally, this is the exact quote I know from W3:
Use relative length units such as percent or (better) em, or, even better, set a base font-size for the document and use absolute size ([ xx-small ¦ x-small ¦ small ¦ medium ¦ large ¦ x-large ¦ xx-large ]) or relative size ([ larger ¦ smaller ]) when defining the font size for a particular element within the document.
Most people who have poor sight and need larger fonts will have monitors/display settings adjusted accordingly. If they do not, many dialog boxes in applications will be unreadable to them.
Most dialogs in Windows apps use MS Sans Serif 8. I use either Arial 10 or MS Sans Serif 10, because of accessibility issues. On web pages, I almost never use font sizes less than 10pt and if I do for some reason, I'll usually use capitals.
And that category of people, I mean people who are not comfortable with computers and have their eyes itching if they stay for more than 30 minutes in front of a monitor, also include people without perfect eyesight. And you may be very surprised to see how many people out there suffer with reading such 10px font pages every other day, and never even think of using a zooming or accessibility feature or so, simply because they are not exactly newbies, but they use the PC for specific things and that's it for them, they don't care about learning anything else. As for the menu items and Windows dialogue box, well, first, these are very short sentences or even a couple of words, so they can put up with it if they think it's too small, and they usually have to put up with it a couple of times then it becomes familiar, and sometimes they don't even care to read it, and if they use a theme that makes them bigger, that theme doesn't usually cover fonts on web pages.
So as someone else mentioned, we'd all like our pages to look the way we want them to, as designers, but real-life dictates certain guidelines for the trade, guidelines concluded from statistics, usability testing, etc. And that's how industry standards become industry standards, until something revolutionary comes along with someone innovative to change one/some of the industry standards for good, productive, and practical reasons.
And the whole point behind this information is not to use size 16px for your paragraph fonts, not at all; actually you can definitely still use size 10px or whatever equivalent pt you want to use, but it is recommended to use that size in the form of an em size, whether that is a 1em or a 1.2em or whatever. As W3 recommends, you can specify a base font-size, then use absolute and/or relative sizes to specify your paragraphs to be exactly the size of 10px/pt, but when you do so using relative sizes, you still allow control for those people who need to read those paragraphs in a bigger text/font size.
Don't you need to set the size of 1 em before using it? And why are em's better than %'s?
EMs are relative to the size of the current font. If you do not set an explicit font size, the EM is based on the size at which the current font is displayed by default in the browser. The bottom line being that you will only know exactly what size you are getting (when using EMs) if you specify a font size off of which it is based. However, EM sizing will work without such an explicit setting.
EMs are not better than percentages. They work in essentially the same way. Personally, I reserve percents for box sizing (although I rarely even do that) and use EMs for fonts. It's a division that makes life just a touch easier on my brain.
If you want your pages to render consistently, you should use absolute base values (and then, if you wish, relative values based on these).
I know that some people will say that this inhibits text resizing in IE, but, unlike some people, I consider this to be a good thing.
You're absolutely right that some people will say this and I'm one of them. :)
First off, just to be certain that others don't get confused: IE/Win will not allow users to resize text that is sized using absolute (PX, PT) units. If you set the base font (in the <body>) using absolute units, then subsequently use relative sizes (EM, %) throughout the page, your fonts will not resize in IE/WIN. Your base font (and any text you want resized) must be in relative units in order to induce IE to resize any text on your page.
Kaled acknowledges this in the above quote, of course, but I've seen lots of posts where people think that absolute base + relative throughout = resizable text. Just wanted to be sure it's clear that this isn't the case.
Obviously, using absolute units to block users from resizing text is a matter of choice, but I really don't understand the logic behind doing so. It's not any harder to size fonts relatively. Users that don't need to resize the text (including those whose local settings already compensate for small font sizes) won't know or notice any difference. Users that DO need/prefer to resize the text (perhaps they're on a colleague's computer, or are suffering from a migraine) will enjoy an unhindered experience on your page at no real cost to you.
However, using absolute sizes like "small" and "x-large" and relative sizes like "smaller" and "larger"--does. Meaning, specifying a base font-size in px in the body, then using "small" or "medium" later on does allow users to resize the font. And that is the best practice recommended by W3. The second best is using em, then percentage (again in W3's recommendations).
In my opinion, allowing users to resize text is a mistake and only covers one part of the accessibility issue. What about images that are used for headings and other textual content. Those don't get resized when using a text sizing method.
Opera has it right in using a true Zoom feature. This takes the entire page and zooms in or zooms out. Design is left intact as the entire page is being enlarged based on the user's settings, not just the text.
We all know that using ems is a pain in the arse. You will never get a site to look consistent across all browsers. And on top of that, you have to take into consideration the user's local settings. From my perspective, there is too much that can go wrong when allowing users to increase just the font size.
P.S. Pt is strictly for print, not for the web.
If you are using IE and need to adjust for sight impairment, go to...
Tools > Internet Options > General > Accessibility
And from there you can override various page settings.
I've not done a full install of IE in quite some time. If I'm not mistaken, the Size button is not in the toolbar by default. You have to add it by right clicking and customizing the toolbar.
I can't tell you how many users I've added that button for at various clients I see locally. They had no idea it was there and their browsing experience changed after it was added.
P.S. IE on a PC is the only browser that does not allow you to resize text if the page being viewed has absolute font sizes specified.
IE on the Mac allows you to resize, go figure...
...there is too much that can go wrong when allowing users to increase just the font size.
That is very new and weird for me to hear, because I actually sometimes go a long way to just give the users the ability to resize just the paragraphs (or the p elements) and sometimes the ul and ol elements, let alone resize "just the font size".
Very often on the web, it is not that important to see the graphics or the images, unless the designer has produced a single way of navigation that relies on image buttons that do not have (alt) and (title) properties, and unless the designer has produced a single way of navigation that relies on an image map. Aside from these two conditions, which are actually considered bad design according to today's web standards, web graphics and images are not that critical for the average user. On the other hand, paragraphs, which directly relate to "content is king", are definitely the critical and vital parts, of the majority of websites out there, for users to easily view or read.
The buttons of the navigation bar should never be strictly image-based anyway, or there should be a text-only navigation bar in the bottom, for example, so that users can view the website just as you, as a designer, intended for it to look like with its graphics, while, at the same time, they have the ability to increase the size of their critical tools (like the navigation buttons) with the elements that use more than 90% of their eye work or strain: paragraphs. People do not stare at the images or graphics, unless it is some kind of a gallery website--and people with weak eyesight are not the typical kind of visitors for such websites anyway. However, people do stare at the paragraphs for much longer times, and they follow those paragraphs with their eyes, etc. And that's why flexibility is crucial in paragraphs, not only in the font-size, but also in the line-height, when flexibility may not be very vital for images and graphics.
...Opera has it right in using a true Zoom feature...The text sizing feature in IE is flawed...
It is hard for me to fully accept Opera's zoom feature. An immediate reason that comes to mind is that its true zoom feature forces the user who is zooming in to scroll horizontally almost all the time, and that is not good or convenient--for the majority of web users today. A second reason: even this (Opera's) true zoom is flawed. I've tested it before myself and found out that in some pure CSS websites, after you zoom in, it pushes the website to the left cutting away bits of the left side of the website, and you cannot move left to see those cut out parts using horizontal scrolling, making it impossible to read some of the content.
The text sizing feature in IE is indeed flawed, but not because it does not execute its function correctly, but because of its time-wasting and usability-abusive design and because it does not show up by default as you have mentioned. However, it executes its function quite correctly, resizing only relative-sized text and leaving other text as it is. It is the job of the developer to determine which text is to be resized and which text should and can stay with the same size, not the browser's job.
Finally regarding this issue, when em and percentage are used only for certain elements, again like the paragraphs and lists in a certain container, they never abuse the consistency of any website across browsers, because images, box elements, big headings or titles, and even certain navigation-bar links, can definitely use specific dimensions and units like px for the web and pt for print.
And, again, if anyone does not like "em" because he/she wants a certain website to look consistent to the last pixel across browsers (which is close to being impossible when we put IE in mind with all other web-standards compliant browsers), then I believe that W3's most highly recommended solution fits the needs of that developer very well: specificy a base font-size in px for the body element in your style sheet, then use absolute sizes like "medium" and "small" or relative sizes like "smaller" and "larger" later on throughout the website, and that does produce almost pixel-accurate results across browsers, while still giving control for IE users, for example, and also encouraging other browsers to use the wiser resizing/zooming path of changing only "relative-size" elements.
As for the faulty frame resizing, I have no idea why anyone would still insist today on even thinking of using frames on a website. This issue has been recycled over and over again in web usability conferences, debates, and articles, and the single outcome was always: stay away from frames unless 100% of the visitors of a website (perhaps a family--without physically challenged individuals--and a private website?) are fine with them.
Which font-size: px, pt or em?
First pt is a print setting and should be reserved for print stylesheets only, screen resolutions are in pixels, so you can forget pt for screen media stylesheets if you like, yes most browsers will make an educated guess as to a screen size for them, but it may not be consistent.
msg #2: "I find that points tend to display too small on a mac"
msg #16: "P.S. Pt is strictly for print, not for the web."
px - pixels would be absolutely fine in an ideal world but IE will not resize text which is based on absolute pixel settings. Whether or not you feel this is a good idea is neither here nor there, if you use them so IE/Win users cannot "break your design" that's up to you, there are other browers and very possibly those users who know that they prefer/need to be able to resize text, whether they've 20/20 vision or not, may already use another browser or they will soon.. ;)
If you do want your text resizable by the user the only way to accomodate all browsers in all forms is to use another sizing method:
em, percentage, keyword
em - is relative based on the font family. 1em being roughly equivalent to the size of a capital "M" at the users default browser setting.
Your base font (and any text you want resized) must be in relative units in order to induce IE to resize any text on your page
IE (not sure if Mac has this bug.. but probably not) has a bug whereby if you set the initial <body> setting in em IE will resize the text but with wildly incorrect results.. though all is not lost..
To circumvent IE's issues, there's a little trick you can use to make EM sizing relate easily to PX sizing. Set the base font in the <body> tag to 62.8%, then use EMs throughout the rest of the style sheet.
I'm not sure that "62.8%" would make me happy ;) but the theory is correct you can set the <body> size in percent then use em's throughout. I don't use IE but prefer to set the initial body size at the very least to 85-90% if set smaller than this the range of sizes offered to IE users diminishes as the smallest setting a browser goes to is 9px approx.. so if your medium equivalent is already set at 62.8% (approx 10px in IE/Win and 9px in Mac at default settings) you've effectively wiped out the "small and smaller" choices from IE's 5 choice range, and even then the "largest" size might not be big enough for some users..
That initial percentage setting is based on the users default (usually around 16px, though in newer Mac browsers I believe it is around 14px?)
percentages - again a relative unit, basically you can use these throughout and they are very similar in nature to "ems". Percentage is based on the users default setting again, and percentages, like ems will calculate based on the parent element (not just the root) so the cascade will have an effect.
Why use em's instead of percentage?
IMHO sizing a box precisely but fluidly to contain text as it is resized (e.g. height of header) is best done using ems so if using em's to size boxes it might make sense to have the text sized in em's too? Otherwise I look at the two of them as virtually the same you can use percentages to size text and em's to size boxes so possibly the toss of coin as to the difference between them...
are an absolute size [w3.org] as in cascade/inheritance will not come into play when using them. The table on that page link shows the suggested scaling factor that browsers should use.
They too can be used effectively and can be resized by IE, and in fact may be easier to get used to in a transition from absolute pixel/pt sizes.
However note that IE/Win PC has a difference from all other browsers when in quirks mode where the keyword sizes are out by one! so a box model hack may needed to be used to provide x-browser consistency.. (I think their "quirks way" makes more sense but there ya go..)
Small fonts : food for thought
Which one is best for you depends on your audience and the accessibility requirements of the job.
I hope this is an impartial roundup ;) it's meant to be, I don't want to turn this into a "font-size war". I believe like everything else CSS, that font-sizing is no different, there are choices.. to tell you which is best for you to use would be nigh on impossible!
btw there is a text zoom CSS property in IE (proprietary) which acts exactly like Opera's zoom and I'm prety sure it would be possible to build an IE only (using conditionals) stylesheet switcher to provide an "enhancement" for your IE users - js would be required - but it might make a nice functionality add-on if you feel strongly..
i use a mac and there's been no problem with either px or pt with enlarging in firefox, ie 5 mac, or safari
but is there anything criminally wrong with using pt and px in the same stylesheet? i can't find the exact px for a pt, and though i prefer px, i use pt for my h1s.
advice on how to standardize my units and/or miraculously convert all 50 stylesheets on my site to em?
There is no reason why you should not mix pt and px but if you are designing pixel-perfect layouts, you should probably use px.
I never use em but I do use %. I've never looked closely at this but I've always assumed 1em = 100%
"However, it executes its function quite correctly, resizing only relative-sized text and leaving other text as it is. It is the job of the developer to determine which text is to be resized and which text should and can stay with the same size, not the browser's job."
While I agree with pico on many points, this does not add up. What makes IE's behavior correct?
A browser is, essentially, a viewer.
Word, Adobe Acrobat, and every other viewer you can name allows you to scale bigger and smaller.
Regardless of what the author's intentions might have been.
Why should a browser be any different from any other application in this regard?
Frankly, the behavior of IE's Text Size menu is downright wierd.
The decision that ems and percents would be resizeable by the browser was an arbitrary decision by the makers of IE. There is nothing to suggest that ems and percents should be resizeable by the browser while other units of measurement should not.
One of the reasons behind this belief is that we cannot currently zoom in images or graphics on a web page without degrading the quality of the images, to more and more of a look that almost becomes distorted, the more we zoom in. Moreover, this kind of zooming forces horizontal scrolling, which is awkward and not good for most users, especially from a usability perspective. So I simply say, let us keep the structure and the absolute-sized elements intact, and just play around with the size of the relative-size elements...well, unless, unique needs dictate unique measures like using a zoom-everything accessibility feature.
would I make the text sizes to verdana .8em? This looks close to me but will it allow people to resize if they need to?
iluminatae, I think, yes, 0.8em (and adding a 0 to .8 seems better for scanning and usability purposes related to coders, even though many coders don't add it) would roughly be close to 12pt on paper. However, Internet Explorer shows it even a bit bigger if you specify it without any absolute-size declarations in the beginning.
So to make the appearance of your text consistent (and to explain), your best bet is W3C's highest recommendation: set a base font-size for the (body) element, for example, in your style sheet, and in your case 12px sounds like a good choice, then the absolute font size "small" for the text you mentioned in a media="screen" CSS file, and simply add an
in another css file, followed by font-size: 12pt; for the element or part of your choice (maybe p elements in a certain container?), and call that file print.css or any other meaningful name to you. Just an extra css file and 2 extra lines of code, and you get as consistent results as possible in many browsers, still make the text resizable, and get exact results for printing.
One of the reasons behind this belief is that we cannot currently zoom in images or graphics on a web page without degrading the quality of the images
I have a vague idea that I read somewhere that fractal image formats can be zoomed. Are any such formats widely supported by browsers. If yes, I might consider switching.