Firefox 3.x CSS tip

It seems that Firefox 3.x interprets font sizes a little differently than Firefox 2.x. I found that where I had specified ‘pt’ sizes in stylesheets and it looked fine in Firefox 2.x, they get blown out of proportion and huge in Firefox 3.x. The solution is to use em or ex measurements for fonts.

The symptoms didn’t appear to be caused by a font issue at all – tabs getting shifted out of whack in a web application chrome or text getting cut off in weird places. I was really glad to have figured out why it was happening and I’m also super-happy the fix is so easy. :)

Rate this:

Share this:

Like this:

LikeLoading...

Related

About Máirín Duffy

Máirín is a principal interaction designer at Red Hat. She is passionate about software freedom and free & open source tools, particularly in the creative domain: her favorite application is Inkscape. You can read more from Máirín on her blog at blog.linuxgrrl.com.

But as far as I know “em” or “%” changes from browser to browser or even from user to user, so a page which looks fine on the browser (or computer) you use might look totally different on other browsers (or computers). That’s why I use pixels on my pages. You can be sure that the look is always the same. Pixel dimensions used to be a bad idea when browsers couldn’t handle zooming them but nowadays there is no popular browser left not supporting zooming on text whose dimensions are in pixels. I never heard of “ex” though, I’ll look into that.

I believe the main reason to avoid using pixels as units for font size is that IE6 refuses to scale fonts when the user chooses to do so. All the other browsers have no issue in scaling text with size defined in pixels.

Canol, even using pixel sizes, the appearence will be different from user to user and browser to browser, because people will have different fonts (with different metrics), different browser window widths, and (as you yourself note) may alter the text size.

Using pixel sizing to avoid variation in display is Doing It Wrong – the display is going to vary no matter what, you need to figure out how to work with that, rather than against it; generally, using relative measures for sizes is more effective in doing this.

voyou, if you define your measure as pixel the appearance does not change from browser to browser, no matter what the user’s font settings or browser width is. And when they alter the text size then of course it changes, what do you expect?

It is true, and I was aware that this was possible. The problem, ultimately, is mixing vector-based objects (like fonts) with bitmap objects (like images).

If you have an opinion about how the fonts and images should “balance” (e.g.: if you are a designer), then you have to reconcile how fonts and images scale with respect to one another.

Treating them both as vectors introduces pixel scaling in the images, which is unattractive, but worse, foists the unattractive presentation on all viewers. Try explaining to your client that the reason his images are grainy is because you’re Doing It Right (sorry, voyou, I respect your position, and truly wish I could follow it), and all he needs to do is resize his browser window…just…so.

The sad fact is that treating them both as bitmaps stabilizes the presentation. In the default view, images are clear. Although zooming introduces pixelation, this is generally understood by the zoom-er as the consequence of zoom-ing.

Yes, I’m Doing It Wrong. Moreover, not only am I unrepentant, I recommend to others to Do It Wrong as well. I am a recidivist AND a subversive. ;-)

In order to Do It Right, what we really need is a new image format, plus a smart client application, where the client will progressively download the image until it either (1) has it all, or (2) has received enough of it to display it properly according to the necessary DPI setting (the display resolution times the zoom). There are wavelet schemes which provide just that, and have been around at least since the ’90’s, but they haven’t caught on. In the 90’s, you couldn’t count on the client having enough computing power to make it practical.

Bucky, I agree that there’s no really good way of combining (fixed-pixel-size) images with text. I think the best compromise available to us is simply to accept that the relative sizes of our text and our images will vary somewhat. This means choosing designs which look acceptable across some plausible range of relative image and text sizes. This is an unfortunate constraint, but all design is about responding to constraints.

The alternative, specifying all dimensions in pixels, is just too fragile. Consider how big a difference there is in the presentation between the same text, at the same pixel size, in Verdana and Arial. An attempt to produce a pixel-perfect design with one font will, at best, produce a poor-looking design, if the user has a font with significantly different metrics; at worst (and this is not uncommon), the text will overflow it’s pixel-specified bounds and be unreadable. And I don’t think it’s enough to say that the user has to take what they get if they choose to zoom the page, at least, if that zooming renders the page unreadable through clipped or overlapping text. For many users, the unzoomed page will be unreadable or simply unpleasant to read because the font size is too small. If the zoomed page is also unpleasant or hard to read, they’ll simply go elsewhere.

Hopefully, in the not-too-distant future, we’ll be able to use flexible sizes for our images, too. Firefox’s image scaling algorithm is already pretty good for images with smooth gradiants (like photos), and, ideally, one could use a vectory format for line art, which would also scale well.