In my previous post on Quick and Easy CSS @font-face Code, I provide a choice set of CSS rules for embedding custom fonts into your web pages. It’s a solid, cross-browser technique that works great, but as Marty Thornley pointed out, it would be useful to have a more thorough explanation of how the code actually works. So, rather than going back and adding a bunch of additional information to the original post, I’m following up with a visual walkthrough of the @font-face code.

In step-by-step visual format, this article will show you what the code is doing and how to use it with your own custom fonts.

Step 1: Declaring the @font-face rules

The first thing we want to do is copy & paste the quick and easy @font-face code into our stylesheet:

@font-face { /* declare fonts */
	font-family: "MuseoLight";
	src: url("fonts/Museo300-Regular.eot");
	src: local("Museo 300"), local("Museo-300"),
		url("fonts/Museo300-Regular.woff") format("woff"),
		url("fonts/Museo300-Regular.otf") format("opentype"),
		url("fonts/Museo300-Regular.svg#Museo-300") format("svg");
		}

Yes, it’s a hideous-looking chunk of CSS, but that’s not going to stop us from using it to embed our own custom fonts. Let’s break it down and see how the different parts fit together..

Continue Reading

I’ve been using custom fonts in my designs for quite a few sites now, and have refined what seems to be an ideal chunk of CSS code for implementing the @font-face rules. Some of the sites that include these rules include Perishable Press and Digging into WordPress, which look more stylish and refined with the custom fonts in effect. I’ve tested this code on quite a few browsers, including the following:

• Safari 3.1+
• Opera 10+
• Firefox 3.5+
• Chrome 4.0+
• Internet Explorer 6+

This technique delivers your custom fonts quite consistently to all of these browsers, and degrades gracefully for those that don’t support it. Of course, there are always weird exceptions contingent in particular scenarios, but overall it’s a solid chunk of code put together from much research, experimentation, and testing. I share it here hoping it will help others implement custom @font-face fonts quickly and easily. Let’s step to it..

Continue Reading

I mean, basically anything except for Internet Explorer, which is a debate in and of itself. Here I’m referring to old versions of good browsers, like Firefox 2, Safari 2, Opera 8, and so on. It seems that older versions of these browsers are not as common as older versions of IE, so should we bother supporting them when designing our websites?

Most agree that we shouldn’t support old versions of crappy browsers like IE, but what about older versions of good browsers like Firefox, Opera, and Safari?

Backwards Compatibility

One of the cool things about adhering to Web Standards during web development is that, theoretically at least, your designs should look similar on all standards-compliant browsers. This is one of the reasons why we exclude IE from the conversation — it doesn’t speak the language, and requires a whole realm of special support in and of itself. But even for modern browsers like Firefox and Safari, a standards-based design does not always translate to presentational fidelity in older versions. So how far back should we go? Obviously there’s no reason to go out of our way to support, say, Firefox 1, but what about more recent versions such as 2 or even 3.0?

Rendering Differences

For many modern browsers, the older the version, the more inconsistencies you’ll find. Older versions of Opera are notorious for borking an otherwise perfect design, and the further back you go, the more borked your design is going to get. And for anyone who does support older Opera, you know how frustrating it can be to target and filter specific versions with CSS. The same is generally true for other modern browsers: supporting older versions can get messy, costing endless amounts of time and energy. There’s no reason to have your designs look identical across browsers, but they should at least be usable. Right?

Continue Reading

For my Serious redesign, I push the envelope in terms of CSS’ advanced selector functionality. Stuff like:

• p:first-child
• p:first-child:first-letter
• p:first-child:after
• p:first-child:first-line

Plus lots of other stylistic tricks that require CSS3 support in order to display as intended. Fortunately, most of the browsers to which I am catering with this new design have no problems with most of the advanced stuff. Of course, Internet Explorer chokes on just about everything, but fortunately IE’s proprietary conditional comments make it easy to fix things up with some “special” styles:

Continue Reading

A great way to enhance the visual appearance of various block-level elements is to use a “rounded-corner” effect. For example, throughout the current design for this site, I am using rounded corners on several different types of elements, including image borders, content panels, and even pre-formatted code blocks. Some of these rounded-corner effects are accomplished via multiple <div>s and a few background images, while others are created strictly with CSS.

Of these two different methods, extra images and markup are used whenever I need the rounded corners to appear in all browsers, or in other words, whenever the effect is an essential aspect of the design. And then, on the other hand, when using rounding corners for visual enhancement, I prefer the strict-CSS method because it is much easier to implement. Rounding the corners on image borders or <pre> elements, for example, is an excellent way to progressively enhance the visual presentation of a design (generally speaking).

Continue Reading

One of my goals for the new Perishable Press redesign was to achieve cross-browser, pixel-perfect precision [ ¹ ]. Of course, due to many variables (platform, operating system, browser, extensions, fonts, etc.), it is virtually impossible to achieve complete 100% perfection, but I am certainly interested in examining the design on as many different configurations as possible. Thus, last week after launching the new design, I made an open call for screenshots. Graciously, many of you responded with some great screenshots. Thanks to you, I was able to see Perishable Press “in the wild” on many operating systems and browsers to which I simply don’t have access. Sure, I could have just went to browsershots.com or some similar service, but as Rick Beckman correctly pointed out, it is much more fun to get everyone involved in the process. So without further ado, here is the Perishable Press Quintessential Screenshot Gallery:

Continue Reading

I recently twittered my intention to switch from the Firefox browser to the sleek, new Opera 9.5. I have always used Opera as a secondary browser, especially handy for speedy jumps into cyberspace, browser testing, and taking up space on my hard drive. I have always wanted to switch completely to Opera, but for many reasons, Firefox just keeps pulling me back into its comfortable grasp..

After a quick Opera-9.5 download, I decided to install Opera in its own directory instead of upgrading my current 9-point-whatever version. Unlike some browsers, multiple installations of Opera require nothing more than separate directories (as specified during the setup process). Within moments Opera 9.5 was loaded up and running tuf. The new darker default interface is sleek and sexy, inspiring me all the more to continue my quest to switch from Firefox.

As I began configuring the new Opera with imported bookmarks, speed-dial, home-page settings, and tab groups, I found myself digging up passwords that I haven’t had to remember in years. I know that Opera is equipped with its own “Remember Password” functionality, but you still have to enter each password at least once in order for it to work. Not a big deal, and certainly nothing against Opera, but it would have been great to have been able to import all of my saved Firefox passwords (if that’s even possible). In any case, after loading up and logging in to my core collection of tabbed sites, I spent a majority of the day using Opera instead of Firefox for all of my design, admin, and surfing needs.

Continue Reading

Fifty Favorite Favicons If you have a website, you need a favicon. For those who may not know, favicons are the small, square icons that frequently are associated with websites. Favicons appear in many places, including browser toolbars, bookmarks, tabs, and address bars. Favicons provide immediate visual identification of their represented sites, enabling super-easy navigation for Web users. While surfing bookmarks with fifty tabs open, finding and clicking on icons is far more efficient than reading through piles of link text. Yet, beyond making it easier for people to identify and locate their favorite websites, favicons also play a critical role in site branding and product recognition. Popular browsers such as Firefox, Opera, and Internet Explorer are virtually re-branded when favicon-enabled sites are displayed. For example, observe how willingly modern browsers conform to the image of web designer/developer Jonathan Snook:

Continue Reading

Hiding and filtering CSS rules for specifically targeted browsers is often a foregone conclusion when it comes to cross-browser design considerations. Rather than dive into some lengthy dialogue concerning the myriad situations and implications of such design hackery, our current scheduling restraints behoove us to simply cut to the chase and dish the goods. Having said that, we now consider this post a perpetually evolving repository of CSS filters..

Continue Reading