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):
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?
Update
Matthew Pennell provides a fix for the IE 6 min/max-width hack.37 Comments
Stock photography, type, and killer tees. Genuinely recommended by Authentic Boredom.
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.
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).
umm, “guy instinct” should be “gut instinct”. That’s what I get for using cliches, I guess.
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?
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:
http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html
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…
Cameron,
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 :)
Jeff
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”);
}
</script>
</public:component>
Apologies for the formatting, I tried using <pre> & <code> but it’s still a mess.
Try using documentElement.clientWidth
Woops, just too late :). I use the following code:
width:expression(
(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)
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.
Thanks, crew. I’m off to give a few of these a go… Other ideas still welcomed.
I was able to reproduce the improper overlap on tuscany.cssmastery.com in Firefox 1.5 Mac thusly: Small Text and Very Small Text
I don’t know if this is off-topic, but the Tuscany page is also messed up in Safari 2.0.3.
The Tuscany page is working fine in both IE and FF for me. Your portfolio page is working perfectly as well.
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.
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.
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
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.
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?
Just checked it on in IE6 on Windows - looks like it works just fine, no freezing.
Thanks, Bryant. Can others verify too?
Yup sure, no problems in my IE6 in Windows either! Works a treat.
in your new version, once I had maximized my IE window, the content never shrank back again as I reduced window size.
Hmm, that’s a bit bizarre.
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.
Ah ha. How about now? (refresh)
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. :)
Fear not for we are saved, grab your very own
Cameron Moll Grunge Mix theme:
http://www.templatemonster.com/survey_wp_themes.php?theme=cameron_moll_grunge_mix
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.
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…
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%”));
}
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”);
}
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.
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/ccomment_ovw.asp
Agreed. That’s why I’ve got the expression stored in a separate ie.css file.
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.
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…
Full-time and freelance job opportunities. Post a job...
A selection of fine reading, available for a limited time only:
- Jobs home page reorg
- Coming soon: Mobile Web Design, the book
- Dyson ad: Text as more than just words
- Setting sail for Europe
- Review: Sumo Omni bean bag chair
- Dashboard widget for Authentic Jobs
- Limited-time offer: $99 listings
- Nine skills that separate good and great designers
- Fire sale
- Introducing AuthenticJobs.com
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 A guide to publishing web content beyond the desktop. Tips, methodology, and resources. Now available.
Letterpress Posters The unassuming beauty of a freshly letterpressed print.
That Wicked Worn Look. Techniques for that worn, aged, distressed look.
Mister Retro Machine Wash Filters Turn the dial to “Instaworn” with these filters.
Blinksale Dive in and enjoy shamelessly easy invoicing from Firewheel Design.
Basecamp My preferred web app for internal and client project collaboration.
HOW Conference Austin, June 24–27. Pentagram, Adobe, P&G, et al.
Web Design World Seattle, July 20–22. Practical sessions on web design.
Stimulate Salt Lake City, September 2009. Entrepreneurship and design conference.
Articles:
Linkage:
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!