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 Thornleypointed 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.
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..
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..
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?
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 conditionalcomments make it easy to fix things up with some “special” styles:
Say goodbye to the age-old clearfix hack and hello to the new and improved clearfix method..
The clearfix hack, or “easy-clearing” hack, is a useful method of clearing floats. I have written about the original method and even suggested a few improvements. The original clearfix hack works great, but the browsers that it targets are either obsolete or well on their way. Specifically, Internet Explorer 5 for Mac is now history, so there is no reason to bother with it when using the clearfix method of clearing floats.
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).
One of my goals for the new Perishable Pressredesign was to achieve cross-browser, pixel-perfect precision [ 1 ]. 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:
I know, I know, not another post about IE6! I actually typed this up a couple of weeks ago while immersed in my site redesign project. I had recently decided that I would no longer support that terrible browser, and this tangential post just kind of “fell out.” I wasn’t sure whether or not to post it, but I recently decided to purge my draft stash by posting everything for your reading pleasure. Thus, you may see a few turds in the next few weeks, but hopefully this isn’t one of them. In any case, here is my final post on IE6, at least for awhile..
As announced at IE Death march, I recently dropped support for Internet Explorer 6. As newer versions of Firefox, Opera, and Safari (and others) continue to improve consistency and provide better support for standards-based techniques, having to carry IE 6 along for the ride — for any reason — is painful. Thanks to the techniques described in this article, I am free to completely ignore (figuratively and literally) IE 6 when developing and designing websites. Now that I have dropped support for IE 6, I feel liberated, free of the constraints that once enslaved my time, energy, and resources. Working on my new design, I have already saved countless hours that would have been wasted on IE 6. If you are still chained to an old copy IE 6, I highly recommend kicking it to the curb and experiencing the freedom for yourself. All it takes is a few lines of code and the decision to go there.
/* set the minimum width for IE 6 */
#target_element {
width: expression((document.body.clientWidth < 335)? "333px" : "auto"); /* min-width for IE6 */
min-width: 333px; /* min-width for all standards-compliant browsers */
}
Although ugly, invalid, and resource-intensive, this technique works well at setting min-width properties for IE6. But beware! There is a catch. Chris Herdt recently wrote in with an important discovery:
…inclusion of any padding or margin on the element that has the fix applied will cause IE6 to crash…
Continuing the CSS Hackz Series, I present a small army of hacks for targeting and filtering Internet Explorer 7! Here, “targeting” IE 7 means to deliver CSS and/or (X)HTML to IE 7 only, while “filtering” means to deliver CSS and/or (X)HTML to every browser that is not IE 7. In other words, targeting is to include (apply), filtering is to exclude (hide). Let’s dive right in..
Conditional Comments
Conditional comments are a proprietary Microsoft technique for targeting and filtering different versions of Internet Explorer. Other browsers do not understand them, and will treat them as regular (X)HTML comments. Of all the techniques presented in this article, conditional comments are perhaps the most flexible method for targeting and filtering any version of Internet Explorer, including IE 7. Here are some self-explanatory examples:
I use the CSS clearfix hack on nearly all of my sites. The clearfix hack — also known as the “Easy Clearing Hack” — is used to clear floated divisions (divs) without using structural markup. It is very effective in resolving layout issues and browser inconsistencies without the need to mix structure with presentation. There are countless variations of the clearfix hack around the Web, and for some sad reason, I keep a file updated with all of them. Recent pruning of my clearfix collection yields two excellent float-clearing techniques:
First clearfix method: addresses several reported rendering and display bugs by declaring very small values for both font-size and height, while also declaring a zero line-height value. A little paranoid perhaps, but the unique declarations seem to have no unintended/negative side-effects. This method also targets IE exclusively for the inline-block declaration. Check it out:
NOTE: This entire article amounts to nothing more than an in-depth learning experience. After writing the article, I realized (painfully) that either format for the second iteration of the downlevel-revealed comment for XHTML is perfectly fine and displays no ill effects or unwanted characters in any browser. Thus, this article is essentially useless, but I am posting it anyway because I just hate deleting several hours of hard work..
As more and more people discover the flexibility, specificity, and all-around usefulness of Microsoft’s proprietary downlevel conditional comments, it behooves us to reiterate the importance of utilizing proper syntax. Specifically, for downlevel-revealed, or negative, conditional comments, the commented content will remain visible unless the associated if condition proves false. For example, if we were using XHTML and wanted to hide a specific CSS file from Internet Explorer 6, we could employ the following conditional comment to do the job:
In this CSS Hackz Series article, I outline several solutions for displaying alpha-transparent PNG (a.k.a. PNG-24 format) images in everybody’s favorite broken browser, Internet Explorer. Specifically, IE versions through 6 (excluding IE 5 for Mac) fail to support alpha-channel transparency for PNG images. In these versions of IE, every pixel containing alpha-transparency is displayed with an ugly, flat gray color.
Fortunately, there are plenty of hacks and workarounds designed to “fix” IE’s PNG image-display problem. Unfortunately, every currently available solution requires the use of Microsoft’s proprietary AlphaImageLoader transparency filter 1. Thus, if you need to display translucent PNG images in IE, the solution will inevitably involve the AlphaImageLoader filter until more sophisticated techniques are developed.
In this article, I discuss the different MIME types available for XHTML and explain a method for serving your documents with the optimal MIME type, depending on the capacity of the user agent. Using either htaccess or PHP for content negotiation, we can serve complete, standards-compliant markup for our document’s header information. This is especially helpful when dealing with Internet Explorer while serving a DOCTYPE of XHTML 1.1 along with the recommended XML declaration.
According to the RFC standards 1 produced by IETF 2, web documents formatted as XHTML 3 may be served as any of the following three MIME types:
I use the CSS clearfix hack on nearly all of my sites. The clearfix hack — also known as the “Easy Clearing Hack” — is used to clear floated divisions (divs) without using structural markup. It is very effective in resolving layout issues and browser inconsistencies without the need to mix structure with presentation. Over the course of the past few years, I have taken note of several useful bits of information regarding the Easy Clear Method. In this article, I summarize these lessons learned and present a (slightly) enhanced version of the clearfix hack..
Just a note to web designers and code-savvy bloggers: make sure your custom error pages are big enough for the ever-amazing <cough> Internet Explorer browser. If your custom error pages are too small, IE will take the liberty of serving its own proprietary web page, replete with corporate linkage and poor grammar.
How big, baby?
Well, that’s a good question. In order for users of Internet Explorer to enjoy your carefully crafted custom error pages, they need to exceed 512 bytes in size. Using proper doctype markup, your custom pages should include more than around 10 lines (roughly) of additional markup and/or content. A good rule of thumb is to throw down at least a couple of decent-sized chunks of code. If you are going for a minimalist set of custom error pages and need a way to increase overall page size, you can always add a paragraph or two of good ‘ol Lorem Ipsum text as a comment in the markup:
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:
..Or something. Frankly, I just needed an excuse to post these steaming little beauties online. Please note that I don’t lay claim 1 to most of these browser bookmarklet/favelet tricks, but I do find them extremely useful. They are posted here for the sake of convenience and for reference purposes, so use at your own risk (i.e., I am not responsible if they crash your browser). Although I use most of these bad boys with Firefox, I wouldn’t be terribly surprised if they also functioned properly in other modern browsers. Nonetheless, along with each bookmarklet/favelet thing, I try to provide as much relevant information as possible, because sometimes you just feel like you’re from another planet. Happy head-scratching!
What are these things?
“Bookmarklets,” “Favelets,” “Browser Enhancement Things” — whatever you want to call them — help increase productivity and simplify tasks executed from within your browser window. Basically, these things are stored as bookmarks and perform some task — such as resize the browser window — when they are clicked. Hmm, perhaps I should check Wikipedia for the “Official” definition .. — nah.
How do I install them?
Installation of these lil’ miracles could not be easier. In most modern browsers, simply drag and drop the bookmarklet link onto your shortcut toolbar (Firefox, Safari, et al) or right-click and “Add to Favorites” (Internet Explorer). Pretty easy. There is a more complicated method as well. Create an empty bookmark or Favorite and copy & paste the bookmarklet source code into the URL field. Either way, these things are pretty common and you shouldn’t have too much trouble. So, without further ado..
If you think you understand the logic behind Microsoft’s downlevel conditional comments, you are sadly mistaken. Sure, they seem simple enough on the surface, but as you really try to wrap your head around how and why they work, the subtle complexities of downlevel conditional comments may leave you dazed and confused…
In our previous article on Internet Explorer’s exclusive browser-detection method, downlevel conditional comments (DCC), we present an introductory exposition, defining expressions and providing several generalized code examples. Overall, it is a very useful article but partially fails at explaining the logic and functionality behind conditional comments. In this article, we strive toward a solid understanding of downlevel conditional comments — how they work, why they work, and where they work. Sure, you could just copy and paste code until something clicks, but actually understanding conditional comments will give you the edge — increasing your knowledge and improving your productivity.
First of all, congratulations if you are geeky enough to understand the title of this article. Many would be like, "CSS, MS.. IE, error ..what..?" Whatever. If you get the title, you will get the point of this utterly pointless exercise. If that is the case, prepare for a delightful romp through geekland. Otherwise, save your precious time and stop reading here (exit strategy).
Well, okay, for the seriously unenlightened, let us explain the object of our present focus:
The default "DNS Error" page for Internet Explorer unfortunately remains a familiar sight for millions of Microsoft users. Typically, the default MS DNS Error page loads whenever a browser is unable to connect to the internet or other networked resource. Once loaded, the error page announces itself with a message that reads "The page cannot be displayed." The page then presents several options: refresh browser, retype address, check connection, check configuration, etc. — Monzilla Media (i.e., me)
Still interested? Well, okay. Actually, it’s no big deal. Just a nice, standards-compliant, CSS-based redesign of that old, nappy Internet Explorer 404 Error page. You know the one. Whenever you can’t connect to the internet, it jumps up at you, sticks out it’s tongue and mocks you. Yes, we hate it, too. But alas, with the release of Internet Explorer 7 comes a ‘brand new’ 404 error page. Surely, it’s just a matter of time before that dumpy old 404 error page circa IE5/6 disappears forever. So, before that tragedy unfolds..
Behold the seventh wonder of the virtual world: max/min-height and max/min-width properties are possible in Internet Explorer! Indeed, by taking advantage of IE’s proprietary CSS attribute, expression, you too can whip IE widths and heights into desirable proportions. The CSS expression attribute enables JavaScript commands to be executed within Internet Explorer. JavaScript via CSS? Thanks, Microsoft!
Why is this so great? Well, because in other, standards-compliant browsers, max/min-height and max/min-width properties are easily accomplished with this simple bit of CSS..
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..
This post is a working repository of code edits and other changes made to Perishable Press themes in order for them to function properly in Internet Explorer 7 (IE7)..
![[ CSS3 @font-face ]](http://perishablepress.com/press/wp-content/images/2010/misc-chunks/font-face.png)
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 ![[ ~{*}~ ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/rounded-corners-deco.gif)
A great way to enhance the visual appearance of various block-level elements is to use a “rounded-corner” effect. For example, throughout the ![[ ~:{*}:~ ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/negotiation-deco.gif)
In this article, I discuss the different MIME types available for XHTML and explain a method for serving your documents with the optimal MIME type, depending on the capacity of the user agent. Using either htaccess or PHP for content negotiation, we can serve complete, standards-compliant markup for our document’s header information. This is especially helpful when dealing with Internet Explorer while serving a DOCTYPE of XHTML 1.1 along with the recommended XML declaration.![[ Image: Fifty of my Favorite Favicons ]](http://perishablepress.com/press/wp-content/images/2007/favicons/favicon-collection.gif "Favicons from my fifty favorite feeds")
![[ Image: Fabulous Shot of Immortal's Abbath and Horgh ]](http://perishablepress.com/press/wp-content/images/2007/misc-chunks/absolutely-fabulous.jpg)
..Or something. Frankly, I just needed an excuse to post these steaming little beauties online. Please note that I don’t lay claim ![[ Image: Human Head via Photographic Cubism ]](http://perishablepress.com/press/wp-content/images/2007/misc-chunks/wrapped-head.jpg)
In our 