[COLOR=“Navy”]I recently started a blog about software - blog.nelsondev.net - where I write about Android and Windows programming. As you might imagine I have to display lots of source code - Java, C# and XML.
I’m using the “Preserve Code Formatting” <pre>…</pre> tags in WordPress, which forces a monospace font. It looks OK on IE but weird on Firefox. Somehow the Firefox monospace font manages to be both SMALLER and BIGGER at the same time!! That is, it’s smaller than the default sans-serif font used for the body text so it’s harder to read. but it takes up more vertical space (mainly due to whitespace) and it’s longer, so it’s more likely to run off the page.
Here’s a screenshot from IE:
and here’s one from Firefox:
Obviously I have no control over what fonts the user has installed or his browser settings. Is there anything I can do to get a more pleasing appearance on Firefox without sacrificing it on IE?
Yes, I know where to set the font, infact I’m already doing it there. I tried Courier New which looks even worse than the default monospace font.
Please read my question. My question is how to achieve a pleasing result in both browsers!! There’s no point in getting too fancy with different fonts since they will default to whatever the user has installed on his browser anyway, and the average user probably doesn’t have many monospace fonts installed.
Don’t we have any bloggers here who blog about software and have had to deal with displaying source code in their blog so it looks good on IE and FF? What works?
All OSes and all different browsers use different font-rendering engines. You will NEVER get absolute consistency amongst OSes and browsers.
If you absolutely want the exact same appearance of all text, you need to turn all of your text into images. Images look the same in all browsers and font engines.
That, however, sucks big time and is a terrible solution.
You can use @font-face embedding to specify the exact font you want, and using Fontsquirrel generators can get a fairly consistent browsing experience.
There are other problems with that, too, however. Mainly, the lack of anti-aliasing on XP users without Cleartype enabled. However, using a monospace font, a lack of anti-aliasing might not be too bad.
If you want to override the natural browser font-size of 16px, you need to set another size in px.
And when those who are using IE who use text-enlarge cannot read your tiny 12px fonts, they will leave. Even IE9 still does not resize fonts set in px (no, I don’t really know why, but I do know I’m not the only person in the world who hates zoom as it distorts everything… all I want is text large enough to read!). So far the only fonts I set in px are in/behind logos: so I’m at like 30px. Which may still be too small for someone but at least I’m hitting fewer of them, or I can hope they use a screen magnifier.
ems and % are useless if you haven’t set a base font size.
You already have one, by default. It’s 100%. Of whatever the user has set as their preferred default font size. 1em == their default font size. It’s lovely, really, until you get to different font families and x-heights (like those tiny impossible-to-read beloved-by-everyone new Vista fonts). Then it turns into hell and doesn’t really improve even if you move back over to pixels: 12px calibri is still smaller than 12px verdana.
Use px for when your text must match something else in px, such as a background image. And then, keep the size as large as you can reasonably get away with.
I use em’s for text without thinking, except again when there’s an image involved. I also use it for sizing boxes, but yes there it can get pretty bad because simply changing a font-family can make boxes who used to fit together, not fit together. But the nice thing is they grow the same when you text-enlarge, everyone going with the text (except images) without distortion.
You can set a new body base size in ems or percentages, I will give you that. But when you use ems and percentages in nesting elements, you need to be careful of context.
Someone with <header><h1>Blah</h1></header>
may declare header { font-size: 120%; } thinking they want to increase the font of the header, and then also declare h1 { font-size: 120%; } mistakenly and end up with font that is larger than what they originally intended.
^I dunno what noonope’ll say, but I will say that’s making a lot of work for yourself. If you are going to set things in em’s, you do as little work as possible.
Set the fonts on the text elements, not the boxes. You want to set body text? They’re going to be p’s or inside p’s, frankly, except for things like headers who you’ll want something different on anyway, so you set p {font-size} or even .main p {font-size} but to avoid problems like you mention, don’t set .main {font-size}, cause .main’s holding a whole bunch of things.
You are overlooking one of the most powerful CSS features by using fixed px font sizes. Now, take a look at what a 11px font looks like on a 1280x1024 resolution, even though you’ve put a larger DPI in you OS settings. Like the one at the top
Now, try use the Developer Tools in the browser of your choice (I recommend you FF :)), and change the font declaration to one using em or %. You’ll see what I mean, I hope.
And Sp said it very well:
You already have one, by default. It’s 100%. Of whatever the user has set as their preferred default font size. 1em == their default font size.
I’m in total agreement that fonts at 12px look like a**. I generally use a 16px or equivalent copy text. I think designers for some reason have tried to cram more info than needed into pages.
Unfortunately, that is the most important part of the demo and removing the px or using ems will result in a different monospace font size between IE and other browsers.
The body font-size in the layout above is set to 62.5% which if nothing has been changed by the user will be 10px. Firefox and safari then (for some strange reason) apply 62.5% to the pre element as well which has a default size of 13px thus resulting in the pre element being 8px. Any further changes via em and nestings just compound the issue.
IE on the other hands scales the pre element as expected and the pre element starts at 10px and therefore 1.2em would make it 12px (which is the measurement I used in my snippet above). (Opera seems to follow IE here also).
Therefore for consistency when using monospace fonts (and the pre element) they should be sized in pixels in all browsers except IE6/7. For IE6 and 7 you can use ems instead if you want the user to scale text and still match sizes ok.
Note that if the body’s font-size is instead set in pixels then there are no scaling issues with the pre element and monospace fonts (and can be scaled directly with ems as usual).
I should also point put here that the OP’s original code is invalid with nested pre elements contained inside a p element which is not allowed
The goal was not a consistent monospace but a clear one. Different UAs default stylesheet implementations and font rendering are already “result[ing] in a different monospace font size”. The goal was to improve not to level down the play field. For FF is:
Yes it’s a bad thing but it addresses the actual problem with monospace fonts that has not been pointed out before in the thread. That was the point I was making.
Setting a font-stack is a good solution and may hide the problem initially for browsers who happen to have the fonts you specify but does not address the problem for those who get the monospace font and would therefore still get an inconsistent experience.
As usual there is no one clear answer but there is one clear problem in that the monospace font is a different size when used in conjunction with ems on some browsers. Setting the size in pixels for the monospace font is an easy solution although it disregards the users preferences but in some respects so does setting the body to 62.5% anyway.
In the context of the OPs page where its code that is being displayed then I think that’s acceptable to use pixel sizes for the code inside the pre element because in most cases the code won’t be read like a book but will more likely be copied into an editor for testing.
We make many decisions when coding a page and very rarely people will agree on the same approach.
The body font-size in the layout above is set to 62.5% which if nothing has been changed by the user will be 10px. Firefox and safari then (for some strange reason) apply 62.5% to the pre element as well which has a default size of 13px thus resulting in the pre element being 8px. Any further changes via em and nestings just compound the issue.
Yay, another reason to add to the list of why we should not be using tiny— font %'s on the body in the first place.
The next fad will be masochists setting the body to 33.3333% because it’s a nice irrational number and those are just teh awesome.
My question would by why on earth are you setting such ABSURDLY SMALL font sizes – Of course it appears you’ve bought into that 62.5% == 10px LIE which is likely why the layout is horribly broken for me – since I’m a large font/120dpi user so on some browsers 62.5% == 12px and others it == 13px; some handhelds will try to render that as 7 or 8 px, my MPC would try to do that as 15px – and in any case 62.5% is absurdly undersized /FAIL/ at development. (85% would be much more practical)
As mentioned you also fail to set a default line-height, which you can NEVER trust cross browser; nor to inherit properly – you change font-size you change line-height… Which is why I always just use the condensed property. (and include style/weight since the entire condensed can be ignored if you omit them in some browsers).
But as already said, if you are expecting the exact same size across browsers, OS and system metrics you’ve got completely unrealistic expectations and are missing the POINT of HTML and the WCAG (which is why you would say % or EM in the first place).
Of course the “crappy little stripe” narrow fixed width layout, double wrapping PRE (which if you set a size on PRE makes PRE smaller), lack of code tags around your code…
You do know that, right? The semantic code for your code blocks would be <pre><code>Some code</code></pre>, right? It’s preformatted text, and that preformatted text is code.
You also should NOT be using non-breaking spaces there as that’s just a waste of bandwidth.
Bottom line, lose the non-breaking spaces, get the right tags in there, get rid of that absurdly undersized and unusable 62.5% nonsense, and lose the fixed width.
Of course there’s a dozen other things wrong in the code, but 80-90% of that is just the bloated garbage turdpress shoves down your throat.
