The Anatomy of Web Fonts

[ArticleBot]

This is an article discussion thread for discussing the SitePoint article, "The Anatomy of Web Fonts"

[Sojan80]

Nicely done. I thoroughly enjoyed it. I also now know and understand better what makes a good screen typeface.

Nice article, not to sure about that sIFR approach seems like too much going on, wouldn't it be easier to use css background images as a text replacement and style the text to display:none.

Overall a good article, however...

I am disapointed to see you endorse the use of fixed width fonts (px) over scalable fonts (ems, %, etc.)

The use of fixed width fonts creates accessibility issues and can make it harder for people with larger monitors or poor eyesight to view the page.

The only reason to use a fixed width font is to try to limit the way the content displays. In short, this is just poor web design and is a dis-service to the website owner. A good web designer would create a layout that can resize and flow, while still looking good, so that the webpage can be viewed on different size screens and by people with different eyesight capabilities.

Hm, links in the article don't work in the print version...?

[peach]

I agree with Andrew, non-scalable fonts should be a thing of the past, I can't believe you're promoting inaccessible typography here. Also, sIFR is embraced by many designer for the fact that it supports the scaling functionality of our browsers, if you're a fan of non-scalable text there is no need to use sIFR because you might as well use an image.

Hi AndrewY/peach,

I absolutely agree with you that "<em>a good web designer would create a layout that can resize and flow, while still looking good"</em>.

In fact, to quote myself :) "<em>Don't inhibit this freedom by assuming users' requirements or by attempting to force too many of your own preferences onto users.</em>"

I also agree that pixels (px) are <a href="http://usabletype.com/styles/sizes/">not the best method of sizing fonts on the web</a>. However, a common misconception is that pixels are not scalable, period.

The reason pixels are not the ideal method for sizing text is because Internet Explorer on Windows does not allow for scaling of text sized with pixels - and IE is still the market leading browser. It is important to realise that it is IE that is broken, and that no where in the CSS spec does it say that text set in pixels should not scale. It does in every other browser.

The example from Jared Digital was used purely to compare the font size of his headings in a simple way.

I should have guessed that the tricky subject of font sizing would rear its head - despite the fact I tried to avoid it. ;)

I read an article a while back about setting font sizes. It used a technique based on the default size being equivalent to 16px. by using a percentage to shrink this default to 10px so its easier to work with then using ems of this size to set the font sizes of h# tags, but i cant find the link. DOh!

found the article,

http://www.clagnut.com/blog/348/

[muffinresearch]

@AndrewY and peach: I really don't think Andy is advocating non-scalable fonts, though the example given probably gives the wrong idea.

Perhaps the example could be expanded to include an em or percentage based implementation of the typographers scale?

Otherwise this article is a great foundation for anyone looking to learn more about web typography - consider it bookmarked.

Note that there are available typographic elements such as the em-dash "—" that should be used instead of the double hyphen "--" that this article employs.

[AlexW]

Originally Posted by James

Nice article, not to sure about that sIFR approach seems like too much going on, wouldn't it be easier to use css background images as a text replacement and style the text to display:none.

James, along with the scalabilty advantages Peach alluded to, sIFR has a number of other advantages.

The key benefit in my eyes, is it's dynamic nature. If we wanted to use an unusual Bauhaus font on the article titles on SitePoint, we would have to generate a 1000 new graphic for 1000 articles. If we edited any of those titles, we'd need to generate another graphic. If I wanted to try a slight variation on the font I chose, another 1000 graphics. With sIFR, I could change the font across the entire site in 5 minutes.

Additionally longer title images have no ability to wrap, and no ability to be copied and pasted -- both of which sIFR handles elegantly.

It's certainly not for every job, but it is a very powerful design tool.

[mattymcg]

@James: if you do lean towards image replacement rather than sIFR, you should use some CSS that handles accessibility better. With display:none, screen readers like JAWS won't read out your text.

This was a very interesting article, thank you for taking your time to write this.

[EOBeav]

This is an excellent and timely article about the underemphasized art of text treatment on the web. I think I'll, uh, print this one out.

[Cheyne]

Very informative, all of my websites are content powered so this stuff is all very applicable to me.

[saurab]

great article for sure. very useful for me as i was looking for a nice article on web fonts but found none that explain things so beautifully as this article does.

Just a comment - sIFR may be a well-polished tool, but its techniques result in crap. I hit the demo page, found highlighting to be inconsistent (try highlighting some normal, then sIFR text), and also found headlines to not fit inside their own boxes, creating a bizarre scrolling effect when selecting headline text.

Just leave the layout to the browser. Don't try to act like you know better with crude hacks. Otherwise, there are some very good points in here.

Great article! I only have one gripe: Your code on page 2 suggests people should use pixels as a measure for font size. In truth, this is a bad idea, because it means that the type will render differently at higher resolutions. Better to tell people to use relative font sizes, such as ems, exs or %.

I largely agree with this article. One point I disagree with is the underlining. Yes, an underline *usually* suggests that it's clickable, but typically it also has a change in font colour. It's been my experience that if something is underlined, it's not necessarily clickable, but if a word or phrase is in a crisply different colour, it is almost always clickable. Conversely, having a link where the colour differs only slightly (or not at all) is just poor design.

My kung fu teacher has done some web site design. He would ask me to check it out, and I would end up picking it apart. The first problem is he was using bold/italic/underline/larger fonts/multiple colours far too much. The second problem is that he's colour blind, so things which assault my vision are apparently rather subtle from his perspective.

Which brings us to the question of colour-blindness. How can we properly plan for the colour-blind when designing a site, without taking a misstep for those not suffering from it? I'm guessing there are reference sites out there (I haven't tried to Google yet), but are we compelled to return to return to starkly bland page design in order to appeal to the widest audience?

Related tangent: With Firefox/Mozilla, I'm rather fond of being able to adjust the font size being displayed, simply by using a Ctrl-wheel movement. :)

One thing I noticed when I got a large LCD monitor (with a small dot pitch) was that I now have enough screen real estate to display serif faces with full clarity. It is nice that I don't need to use sans serif fonts as a workaround for low screen resolutions any longer (for my own consumption, at least).

Wow! That was a highly useful article with valuable hard data on font selection.

Excellent article. Especially appreciate the links to some cool sites (Typetester is a dream come true).

I'd like to concur with Robert D. about setting relative sizes in css. For some bizarre reason, Internet Explorer does not allow users to adjust font sizes when designers specify them in px or pts. (All other browsers do.)

A world-class designer/css guru associate of mine has recommended that if you really want maximum accessibility on your site, user percentages. Not even ems. Just percentages.

Of course, this complicates matters for calculating equivalent point sizes, and gets even worse when you consider the effects of nesting. But if you anticipate serving a wide user base, it is essential that you allow users with poor eyesight the ability to increase their fonts.

[andyhume]

@Robert D.

Agreed. I should have made it clear that this code was purely to demonstrate the relative sizes of different text elements on a page. As you point out, until IE on Windows can scale text set in pixels, a relative font setting such as ems or percentages is always better.

@JC:

Colour blindness issues are one reason why underlining should be reserved for linked text in my opinion. If text is coloured, some people may be unable to distinguish it unless it is also underlined.

[andyhume]

@Zigg:

The controversy surrounding sifr is one reason I didn't want to go into it in too much detail. It takes (and deserves) a lot more detailed discussion than I could have given it in this particular article. For a glimpse of this, take a look at the SlashDot thread generated by this article alone - http://developers.slashdot.org/artic...40257&from=rss

Unfortunately, discussions of sIFR tend to generate into something of a slagging match between the for and against parties. Those who want to push the web and design forward in the best way they know how, and those that can only see the bad side of the technology - and won't budge on it.

I like to think I'm somewhere in the middle - seeing it for what it's worth but also advocating caution and an understanding of the implications.

Your code suggests using pixel sizes for text. this is exceedingly bad. At 50dpi (800x600 on a 15" monitor) 10px is 1/5" high; At 121 dpi (1920x1440 on a 21" monitor) it is 1/12". Neither is desireable and 1/12" is not legible.

For predictability and accessibility, use either relative (%, em) or physical (pt, mm) measurements.