It has been just over 6 months since The Principles of Beautiful Webdesign hit the shelves and the feedback has been overwhelmingly positive. Even as I was revising the final chapter back in October/November, I had no idea how well it would be received. After four printings, over 50 feedback emails, and a plethora (yes, a plethora) of great reviews, I can safely say that people like it. To me, that alone makes all the work worthwhile. Many thanks to Sitepoint for giving me the opportunity, my wife who kept me on task and motivated, and all the people who have taken the time to write a review. Here’s a list of some of the reviews that you won’t find on the Amazon or Sitepoint product pages:

• 465 Berea Street
• Ask Manny Hernandez
• Anne Kowalski
• Blogcritics Magazine
• Blue Lime Media
• Creative Keys
• Desicritics
• Draiocht Web Design
• Drawing On The Web
• James Booker
• James Pyles from MCSE World Forum
• Maratz
• Mitch Wheat
• Monday By Noon
• Nate Klaiber
• New York Stringer
• Slashdot
• Stevens Media
• Revish
• Teamunited Web Design
• Technology for Humans
• The Coding Humanist
• Visual Gui
• Web in Mind
• Web Teacher

When I was writing The Principles of Beautiful Web Design, I had no idea that the section with the most overlooked typos and errors would be the segment on background positioning. Backgrounds are such an integral part of what I do that I neglected to test what I was writing. However, I knew all along that there is some trickiness to the CSS background-position description, specifically when you start mixing keyword values (top, bottom, left, right, and center) with numeric or percentage values.

The main problem is that the keyword values are to be declared with the vertical value first and then the horizontal (ie, bottom right). With numeric and percentage positioning, you declare them the opposite; horizontal value first and then the vertical. This creates some confusion when you want to do something funky like specify a pixel value for the horizontal position of a bottom aligned background. Do you say bottom 100px or 100px bottom? It would be nice if the browser made the assumption that if you declare an explicitly vertical keyword like bottom, then the other value is horizontal. Safari and IE make this assumption, but Firefox and Opera will only accept one order. If you get the order wrong, the browser will give up on positioning the background altogether and place your background in the default top left corner.

How nice. To avoid this problem, and for the sake of consistency (and sanity) you should always declare the horizontal value first and then the vertical. Even if you are using only keywords, bottom center and center bottom both render the same way, and even though the W3Schools says the former is correct, they both validate.

To figure all this out, I set up a page with 24 different combinations of background-position values containing bottom, right, center, 100px, and 80%. I left out top and left because either of these could be specified simply as 0 which would eliminate the need to mix keywords with numeric values alltogether.

Enjoy: The Background Position Compendium

I’m sure just about every web developer is familiar with client-side stylesheet caching. You know how it goes, you’re making changes to a stylesheet and checking them in your browser and then, all of a sudden, the updates you made don’t show up. When this happens, you either click refresh like a spastic monkey or clear your browser cache and the world returns to normal.

Much more frustrating than that experience is server-side stylesheet caching. Although I’ve seen this happen periodically on Linux servers as well, our Windows testing server here in the office is a cache maniac. If you refresh a page on the server a few times, the machine will start serving a cached version of the stylesheet...and continue doing so for several minutes. You can clear your browser cache and refresh a zillion times, but you’ll still get the cached version. When you point your browser directly to the CSS file, it will actually show the latest version, but when you go back to the page you were trying to refresh, or any page that links to that stylesheet, you’ll still get the cached version. It’s enough to drive me mad, especially when I’m already working on fixing quirky IE issues.

While the server caching settings really should be reconfigured, the accepted local method of dealing with this annoyance is to add a query string to the stylesheet url like so:

<link rel="stylesheet" type="text/css" media="screen" href="css/screen.css?foo"/>

This essentially fools the server into thinking the file must have server-side code, hence forcing it to re-load the stylesheet.

While this parlor trick stops the server-side caching, we often work on sites that do not have the stylesheet seperated into an include, so you can add the ?foo to the stylesheet href value on one page, and as soon as you jump to another page, you get the old stylesheet again. Additionally, we often forget in our final cleanup to remove the query strings when we’re done working on a site, leaving behind our query-stringed stylesheet links for the world to see. Bah!

What’s the solution? Ideally, adjusting the server’s cache settings. As a stopgap though, or for situations where I don’t have control over the server’s cache settings, I wrote a bookmarklet that reloads all the linked stylesheets with a query string of the current timestamp attached. I used a timestamp rather than the usual ?foo because sometimes it seems like the server caches the ?foo query string and we end up using ?foo1, ?foo2, ?foo3... This way, the query string is guaranteed to stay unique.

CSS Cachebuster
As usual with bookmarklets, just right click on the link and "save link as" or drag it into your bookmarks toolbar.

I know, I know, it’s not all that impressive, but I’m proud of my little bookmarklet. As I keep telling Dustin and my other 133t Hax0r friends, I’m a designer, not a coder. Now feel free to pick it apart and tell me what you would have done differently and I’ll update the link above accordingly.