Tuscany errata

~ 12 April 2006 ~

Oh the woes of supporting one’s code. I’ve quickly realized it becomes only more woeful when the code is documented, printed, and in the hands of thousands of readers…

I don’t typically encourage readers to fix bugs for me, but I figure we need to lay these on the table for those who already own CSS Mastery and may be experiencing these issues. Both were assumed to be isolated cases as I couldn’t duplicate them. However, enough readers have emailed showing the same error repeatedly, causing the words to slowly roll off my very own tongue, “Dude, your code is whacked!”

And so it is. But fear no more, as I’ve successfully eliminated one of the issues. Yet my ever-so-humble JavaScript skills have prevented me from eradicating the second. Allow me to explain each.

1. Incorrect height for #masthead in Firefox 1.5 (Windows only).

Some of you have noticed improper overlapping between the logo/nav area and the bottom half of the layout while viewing tuscany.cssmastery.com in Firefox 1.5. This occurs only in the Windows version as far as I’m aware, and to date I have yet to be able to duplicate it via BrowserCam. The image below shows the error (which was captured by a reader):

Image showing height problem in Win Firefox 1.5

The code used for the logo/nav wrapper div (given the selector name of masthead) looks like this:

#masthead {
	position: relative; 
	background: #F7F7F4 url(../img/bg_repeat.gif) repeat-x;
	height: 15.4em;

Turns out FF/Win doesn’t like the height specified as em if the default text size is small. The overlapping will occur anyways if text size is decreased, but I make the disclaimer in the book that if users are going to resize the text, they’ll most likely resize the text up, not down. But apparently this incorrect overlapping is the default for some FF/Win users.

Best way to fix it? Just add min-height: 246px and that seems to do the trick. I skipped this originally because IE doesn’t support min-height, but given this is a Firefox-only bug and Firefox supports min-height, we’re all good.

Final code looks like this:

#masthead {
	position: relative; 
	background: #F7F7F4 url(../img/bg_repeat.gif) repeat-x;
	height: 15.4em;
	min-height: 246px;

Oh, and why was em originally used as the height value, instead of px or min-height? Go buy the book. (wink)

2. The JavaScript expression used to mimic min/max-width causes IE/Win to freeze.

Actually, this isn’t a bug at all. This was thrown in to forcibly cause IE/Win users unrestricted punishment. Kidding. Of course. But maybe only partly.

The Tuscany site is a fluid layout. Fully fluid layouts can be a bit wild on larger monitors, so the site includes specifications for min-width and max-width for the entire layout. However, as we all know by now, IE 6.x doesn’t support these properties (though that’s rumored to change in IE 7 according to Dave). Thus, a JavaScript hack is needed to mimic min/max-width for IE.

Here’s the expression I use in the book. Sadly, I don’t recall where I found this and therefore can’t speak for its validity.

#container, #footer {
	width: expression(document.body.clientWidth < 740? "740px" : document.body.clientWidth > 1200? "1200px" : "auto");

This expression forces the width of the layout to be 740px if the browser is narrower than the same, or 1200px if the browser is wider than the same. Seems all fine and dandy, but according to some readers, when grabbing the edges of the browser and dragging to resize it, IE freezes completely. Dead. Muerto. Buh-bye. The only fix I’ve located so far is one that requires removing the left/right margin and/or padding for the element(s) that use the hack, but I’ve got only a margin: 0 auto; in #container and no margins or padding in #footer.

Anyone have any experience with this expression? Any javascriptophiles out there that can tell me if my code is valid? Perhaps it has something to do with the auto margin value. Any other thoughts as to why it’s freezing?


Matthew Pennell provides a fix for the IE 6 min/max-width hack.


Veer Veer: Visual Elements for Creatives.
Stock photography, type, and killer tees. Genuinely recommended by Authentic Boredom.

1   JaX ~ 12 April 2006 at 02:02 PM

My poor understanding of Javascript has been my downfall on more than one occasion. It’s always interested me how developers are either skilled at design or programming - essentially they use separate sides of the brain. I wish I could help you here. Good luck, amigo!

2   Michael Hessling ~ 12 April 2006 at 02:34 PM

You may have gotten the IE min/max-width hack from Tofte. I’ve noticed the IE freeze, too, but don’t have a solution.

3   david gee ~ 12 April 2006 at 02:57 PM

I’ve used similar javascript in IE before without having it freeze up on me, so this is quite weird. I can’t test out a solution, but my guy instinct tells me it may have something to do with using document.body.clientWidth in combination with the strict doctype, which is forcing IE to render in standards mode. Although I still get a return value from document.body.clientWidth in standards mode, document.documentElement.clientWidth would be more correct, although this would only work in IE 6+. You might also try using document.body.scrollWidth, which gives the amount of space available before horizontal scrolling occurs. Personally, I’d probably use a .htc behavior file which gives you a bit more leeway around structuring your javascript correctly.

Also, you need to specify a width on your code blocks and add an “overflow: auto” in there, right now your code is spilling over into your sidebar (on this page).

4   david gee ~ 12 April 2006 at 02:58 PM

umm, “guy instinct” should be “gut instinct”. That’s what I get for using cliches, I guess.

5   Cameron Moll ~ 12 April 2006 at 03:04 PM

David - I’ve got overflow:auto in there. Still spilling over, eh? Apparently the woes continue…

As for your suggested fix, you lost me at .htc. First I’ve heard of it. Is this htaccess, or a diff type of file?

6   erat ~ 12 April 2006 at 03:12 PM

The one time I’ve used an .htc file was to give IE6 alpha transparency support for an image. It’s a fairly common fix:


Looks to me like VB script, but what do I know. I’m not a MS programmer.

Not that any of this helps your situation, but I figured I’d jump in and offer an example of an .htc file…

7   Jeff Coleman ~ 12 April 2006 at 03:16 PM


I noticed the same freezing effect when I resized the page on your portfolio site, as well. I wanted to see how your beautiful and elegant design handled a skinny-width page in IE—and got punished for it :)


8   david gee ~ 12 April 2006 at 03:19 PM

Sorry for the comment spam, this will be the last one:

I managed to set up a simple test case and recreate the problem. document.body.scrollWidth doesn’t work as a fix, however I changed your code to use document.documentElement.clientWidth and resized for over a minute with no freezing, so that seems to fix the problem. Unfortunately, IE 5.5 (AFAIR) does not support document.documentElement, so you’ll need to change your code to something very ugly, and throw in an additional ternary to check for document.documentElement at the front:

width: expression(document.documentElement?document.documentElement.clientWidth < 740? “740px” : document.documentElement.clientWidth > 1200? “1200px” : “auto”:document.body.clientWidth < 740? “740px” : document.body.clientWidth > 1200? “1200px” : “auto”);

Alternatively, use a .htc behavior:

#container, #footer {
behavior: url(path/to/resizer.htc);

and then in /path/to/resizer.htc:

<public:component xmlns:public=’http://dummy.org/schema’>
<public:attach event=”onresize” onevent=”setWidth()” xmlns:public=’http://dummy.org/schema’ />
<script type=”text/javascript”>
function setWidth() {
var doc = document.documentElement?document.documentElement:document.body;
this.style.width = doc.clientWidth < 740? “740px” : doc.clientWidth > 1200? “1200px” : “auto”);

Apologies for the formatting, I tried using <pre> & <code> but it’s still a mess.

9   Marc Köhlbrugge ~ 12 April 2006 at 03:24 PM

Try using documentElement.clientWidth

10   Marc Köhlbrugge ~ 12 April 2006 at 03:29 PM

Woops, just too late :). I use the following code:

(d = document.compatMode == “CSS1Compat” ? document.documentElement : document.body) &&
(d.clientWidth > 1024 ? “1024px” : d.clientWidth

I’ve got it from Paul O’B (http://www.pmob.co.uk)

11   Michel Fortin ~ 12 April 2006 at 03:34 PM

There is nothing fishy with your JavaScript expression; I can’t see anything wrong with it.

If you haven’t done so, I’d suggest trying what David said about changing document.body.clientWidth with document.body.scrollWidth. My theory is that IE gets stuck in an infinite loop because of a circular depependency: something like your expression changing clientWidth forcing IE to recalculate the expression which set clientWidth again and so on.

12   Cameron Moll ~ 12 April 2006 at 04:40 PM

Thanks, crew. I’m off to give a few of these a go… Other ideas still welcomed.

13   Kevin ~ 12 April 2006 at 08:11 PM

I was able to reproduce the improper overlap on tuscany.cssmastery.com in Firefox 1.5 Mac thusly: Small Text and Very Small Text

14   Paul D ~ 12 April 2006 at 09:46 PM

I don’t know if this is off-topic, but the Tuscany page is also messed up in Safari 2.0.3.

15   John Cade ~ 12 April 2006 at 11:58 PM

The Tuscany page is working fine in both IE and FF for me. Your portfolio page is working perfectly as well.

16   Matthew Pennell ~ 13 April 2006 at 12:16 AM

I’ve been able to avoid the IE-freeze issue in the past by NOT specifying identical widths in the expression; so instead of saying “if the width is less than 740px, set it to 740px”, change it to “if the width is less than 745px, set it to 740px”.

You get an ever-so-slight jump when you resize to the target width, but it avoids the freeze - presumably caused by an endless loop as the size hits the target width.

17   Dimitri Glazkov ~ 13 April 2006 at 06:02 AM

Matthew is spot on. The freeze is caused a racing condition in IE at the moment when the size of the window hits the target width. AFAIK, you can never completely get rid of this as long as you’re using expressions.

18   Luke Lutman ~ 13 April 2006 at 07:39 AM

Here’s some code I’ve been using for min-width in IE (no freezing problems, afaik):

// Create min-width functionality in IE
function ie_minwidth () {
// This function is only called from a width:expression() rule in style.css
// Get the width of the window
// IE5-Win always return 0 for documentElement.clientWidth, but returns the proper value for body.clientWidth (see: http://www.quirksmode.org/viewport/compatibility.html)
var w = Math.max (document.documentElement.clientWidth, document.body.clientWidth);
if (w > 1000) return w + “px”;
return “1000px”;

You can see it in action at http://www.zimmertwins.com

19   Matthijs Abeelen ~ 13 April 2006 at 09:10 AM

I have experienced the same issue with IE freezing and found out that the solution of not setting the two values to the same width solves it (as Matthew suggests). What Dimitri suggests about the racing condition is probably the cause.

20   Cameron Moll ~ 13 April 2006 at 10:39 AM

Looks like Matthew’s suggestion (comment #16) may work. See this copy of the site with non-identical widths. Can any of you with IE verify that it no longer freezes?

21   Bryant ~ 13 April 2006 at 11:21 AM

Just checked it on in IE6 on Windows - looks like it works just fine, no freezing.

22   Cameron Moll ~ 13 April 2006 at 12:11 PM

Thanks, Bryant. Can others verify too?

23   Michelle Flynn ~ 13 April 2006 at 12:21 PM

Yup sure, no problems in my IE6 in Windows either! Works a treat.

24   chris ~ 13 April 2006 at 12:57 PM

in your new version, once I had maximized my IE window, the content never shrank back again as I reduced window size.

25   Cameron Moll ~ 13 April 2006 at 01:26 PM

Hmm, that’s a bit bizarre.

26   John Riviello ~ 13 April 2006 at 01:43 PM

Thanks a lot for the min/max-width info, Cameron. I’ll definitely get some good use out of this. To fix the problem with the content not shrinking after you resize your browser to be larger than 1200px, just change the ‘1198? “1200px”’ part of the expression to ‘1202? “1200px”’.

When setting the max-width with this method, always be sure to check for a slightly larger value than the width you want to set it at.

27   Cameron Moll ~ 13 April 2006 at 03:34 PM

Ah ha. How about now? (refresh)

28   Robert Pierce ~ 13 April 2006 at 09:57 PM

Hey Cameron,

It looks like you’ve fixed the freeze, but it’s looking pretty munged up on my IE (6.0.29 on XP Pro). I’ve emailed you a screenshot.

Thanks for working on this. I was pulling my hair out today. I’d started with the Tuscany layout (as you’d given me permission to) and had a great fluid design going. I was doing some browser testing and ran into this. Haven’t seen anything like it before. I’ll implement the fixes and get my blood pressure down now. :)

29   Neil ~ 14 April 2006 at 11:36 AM

Fear not for we are saved, grab your very own
Cameron Moll Grunge Mix theme:


30   Ben ~ 14 April 2006 at 01:15 PM

Hey Cameron, how’s it going - I was just looking over your problem with the javascript. Here’s what happened on my IE - it froze up and I thought it was dead - so I went to try and change to Firefox but when I moved my cursor down to my start bar it was like there was an invisible force field - after about 20 seconds, the window unfroze and everything was back to normal, except the IE window. I can resize the window, but the content doesn’t resize, and the cursor shows the little hourglass icon so it’s thinking. I thought the fact that I couldn’t move my mouse to the bottom of the screen might indicate something. Not sure if that helps. IT’S BROKE MAN! Jk

P.S. I’ll send you a screenshot.

31   Jeff Kenny ~ 15 April 2006 at 08:03 PM

Aha. Good call on setting slightly different values, that makes total sense. The only other workaround I’ve found for this was to send IE into quirksmode, but that has other CSS ramifications…

32   Blair ~ 18 April 2006 at 06:42 AM

As others have noted, setting slightly different values for the text case and the result seem to fix the problem. I’m 99% sure that’s why I used the following version on our site:

#wrapper {
width: expression(document.body.clientWidth > 1024 ? “1024px” : (document.body.clientWidth < 762 ? “760px” : “100%”));

33   Adrian ~ 18 April 2006 at 01:40 PM

I find that even with the fix suggested on your lastest post, IE still freezes (at least for me, running windows). This seems to work well though:

* html #container {
w\idth: expression(document.documentElement.clientWidth 1202? “1200px” : “auto”);

34   Dan ~ 19 April 2006 at 07:59 AM

My personal opinion is that hacks are bad news - especially when it comes to IE. In the case of min-width and max-width, you’d be better off using a separate js file and css if necessary. In this case the best thing to do is use IE conditional comments <!—[if IE 5]><![endif]—> You’ll be better off in the long run.


35   Cameron Moll ~ 20 April 2006 at 07:59 AM

Agreed. That’s why I’ve got the expression stored in a separate ie.css file.

36   bessington ~ 20 April 2006 at 01:26 PM

cameron, had a similar problem when trying to set IE to a min width. I used a larger value check for my page:

#wrapper {
width: expression(document.body.clientWidth 1024? “1024px” : “auto”);

and it worked dandy, no feezing issues. i think the issue may have to do with the size of the horixontal scrollbar? may be completely wrong about that one.

37   bessington ~ 20 April 2006 at 05:38 PM

yes that was supposed to be:

width: expression(document.body.clientWidth 1024? “1024px” : “auto”);


Authentic Boredom is the platitudinous web home of Cameron Moll, freelance new media designer, author, and speaker. More…

Come in, we're hiring

Full-time and freelance job opportunities. Post a job...

...view all jobs »


A selection of fine reading, available for a limited time only:

In Print

CSS Mastery CSS Mastery: Advanced Web Standard Solutions A solid round-up of indispensable CSS design techniques by Andy Budd, Simon Collison, and Cameron Moll.

Mobile Web Design Mobile Web Design A guide to publishing web content beyond the desktop. Tips, methodology, and resources. Now available.


Letterpress Posters Letterpress Posters The unassuming beauty of a freshly letterpressed print.

Wicked Worn That Wicked Worn Look. Techniques for that worn, aged, distressed look.

Mister Retro Mister Retro Machine Wash Filters Turn the dial to “Instaworn” with these filters.

Blinksale Blinksale Dive in and enjoy shamelessly easy invoicing from Firewheel Design.

Basecamp Basecamp My preferred web app for internal and client project collaboration.


HOW Conference HOW Conference Austin, June 24–27. Pentagram, Adobe, P&G, et al.

Web Design World Web Design World Seattle, July 20–22. Practical sessions on web design.

An Event Apart Stimulate Salt Lake City, September 2009. Entrepreneurship and design conference.

Feed Me
Articles: RSS
Linkage: RSS

Follow me: Twitter