Tag Archives: Added

Incremental increases in intuitiveness

Hopefully (yes, I know that’s not a word, but hopefully William F. Buckley isn’t reading this), this site has now become slightly easier to use, thanks to my super-cool new translucent navigation bar. I’m taking the transparent PNG thing to the next level here, stacking transparencies on top of one another, and the overall effect is very cool, I think: the nav bar is shaded, but you can still see the photo through it all. Actually, the individual text links on the nav bar are separate transparent PNGs, in the top layer. (OK, technically they’re not CSS layers, but whatever.) Then the nav bar itself is part of the next layer down, which includes all of the shading and the logo that are overlaid upon the actual photo, which is at the bottom. This way, I can easily swap in new photos without having to redesign anything else. The photos just need to be cropped to the right dimensions. (Of course, it’s been ages since I’ve taken a new “34” photo. But maybe now I’ll get back into that project. I really want to take a picture of the signs at the end of the offramp from eastbound 494 onto County 34, because they’ve got “End MN 100” and “Begin Cty 34” side-by-side. And I’ve been a fan of 100 since I was about 5 [for some reason… but at any rate, this parenthetical has gone on far too long now].)

I’ve also added in an “Offspring” link which, if you’re logged in and have been granted access, will take you to the new Gallery2-based photo library. But since I don’t want just any old stranger/psycho looking at pictures of my kids, I’ve added the log-in requirement. Like I mentioned in my last post, if I know you, feel free to register for an account, and then let me know and I’ll set you up with access to the gallery.

Thanks, Bill… this is just how I wanted to spend my Saturday

Bill, I really don’t have time for this.

Internet Explorer 6 is incapable of properly rendering CSS applied to a <div> tag when the only child element in the <div> is a table. It sticks arbitrary margins in the document below the table. Here’s an example from a site I’m working on (colors removed to [sort of] protect anonymity). This is how it should look, as rendered by Safari:

Safari screenshot

The concern is the content in the dark title bar. The bar itself is a <div> and the two buttons plus the month/year text is contained in a table. Here’s how it looks in Internet Explorer 6 (note the gap below the header bar):

Internet Explorer screenshot 1

OK. So let’s see, maybe there’s a semi-logical CSS workaround. I already have margin: 0 defined for the class the <div> uses. So I added it to any tables contained within that class as well. No luck. Then I did something really off the wall and added a display: inline property for tables contained in that class. It still didn’t work. So then, appropos of nothing, I added a &nbsp; just so there would be something in the <div> besides the table. And here’s the kicker… I actually added it before the table (retaining the display: inline property of the table:

Internet Explorer screenshot 2

Once again, it’s good that the windows in my office don’t open, or there would be one less PC in this building right now.

Of course the &nbsp; solution is not satisfactory to me. The search goes on. Because, you know Bill, I really have nothing better to do when I’m working on a Saturday morning.

At this point another alternative occurs to me: it’s possible to use the CSS float property to position the buttons and eliminate the table altogether. That fixes the problem in Internet Explorer, but…

Steve, I’ve got a few words for you as well! Look what happens in Safari when I remove the table in the header:

Safari Screenshot 2

Sure, that makes perfect sense. Especially since I have a width="100%" attribute right there in the calendar table. Oh, and did I mention that the width of the panel body is explicitly defined in pixels in the CSS? How is it, how can it be possible, that removing a table from a separate (albeit adjacent) <div> could affect the width of this table?

Now where’s my glass cutter? I think there are one too many PCs and one too many Macs in this office.

After a bit more head scratching, I’ve discovered that the cause of the Safari issue is that I neglected to remove the aforementioned display: inline property I added to my CSS in the midst of the numerous futile experiments I undertook to resolve the initial IE problem. Steve, you’re off the hook.

So, in the end, it turns out that the solution to my problem is to abandon the old-school table-based method of layout and go strictly CSS. I’m sure that’s precisely what Bill wants me to do.