IE7, The Script

I was having dinner with friends last week, and one of them, another HTML monkey, told me about a fantastic JavaScript you could conditionally attach to IE6 to make it behave like IE7 (and well, now IE8). After the previous week’s headaches with the absolutely positioned elements next to floating ones, I said if this script works as advertised, why the hell hasn’t anyone told me about it before now?

So I’ve been giving it a shot with my new BlueTrip framework installed, and, well, it’s not manna from heaven. In fact, all the main problems I have with IE6 aren’t fixed with the IE8.js or IE7.js. One of the subsidiary scripts (to recalculate the box model) made IE6 and IE7 crash. On top of not fixing the major problems in IE6, it also breaks what I’ve already fixed, and I don’t want to hack fix a hacked fix.

In all, I put the conditional for IE7 to use the IE8.js script — even though the effect is fairly minor and causes a redraw burp — but I left IE6 the way it is. Honestly, at this point, knowing the hacks already, and having to use a conditional stylesheet anyway (for Peekaboo bug, 3-pixel job, etc. that don’t get handled by the script), it’s just easier to do it manually. Makes sense now why I’ve never heard anyone else hawk this “solution.”

On second thought, considering the redraw burp, I may as well take it off for IE7, too.

I knew it sounded too good to be true.

---

What the script does fix:

• Fixed positioning
• Maximum and minimum width and height
• Many selectors previously unsupported are now supported 
• IE6 will support alpha transparency for png images both as background and foreground images – but see next

And my brief testing concluded that the max-/min-height support didn’t really work either. I’m not sure about the rest since I try not to use those.

Absolutely Positioned element disappears in IE6

This bug is not unlike the Duplicate Rendered Characters in IE 6 that I documented earlier, having to do with IE6 bugginess around floated elements near absolutely positioned elements.

PROBLEM:
I’ve got an absolutely positioned list item at the end of a bunch of floated list items.1 In between the first floated items and the absolutely positioned items, I have another block.

• The blue blocks were floated into place.
• The red blocks are nested inside blue_block_2.
• Red blocks 1 to 4 are floated into place.
• red_block_5 has to be positioned absolutely, otherwise it mucks up the elements in blue_block_3.

Everything looks good in Firefox, Safari, Opera, Chrome, IE7, and IE8.

But wait! That’s right. IE6 needs to suck up more precious minutes in my dwindling life supply; it hides red_block_5.

Using the IE Developer Toolbar, I can make the block reappear by typing…well, anything into the style attribute: zoom, display, etc.

But when I try any of these in the IE6 stylesheet, nothing changes.

SOLUTION:
Craig Buckler at SitePoint explains that IE6 hides absolutely positioned items if they’re coded right before or right after floated sibling elements. He suggested that adding an empty, static element (such as <div></div>) would make IE6 pop the missing element back in.

Sadly, this did not work for me. But thanks to one of his readers, Paul O’B, I found a solution that worked in my case. In the IE6 stylesheet, I added clear: both to the red_block_5 element. I also had to change the left positioning value, but that did the trick.

Happiness.

---

1. Many snarky commentators love to ask things like “why would you need to use absolute positioning anyway? Why not change the markup so the elements fall into place inside the appropriate containing element?”

My response is that my page is marked up the way it is because in the absence of stylesheets and JavaScripts, the content still flows logically, and all the elements that should be grouped together are grouped together.

“So why don’t you change the design to keep the elements together if they’re supposed to be together?”

Because visually, there are other elements that are more important, and my red_block_5 element can be shunted in favour of other visual hierarchies. Basically, there’s another element at the bottom of blue_block_3 that logically belongs within blue_block_3 (vertically), but also flows naturally after red_block_4 (horizontally).

So my case may be very particular, but I don’t think so. Besides, I don’t think I should have to give up either markup logic or visual logic just to make IE6 happy. That’s asinine. IMHO, IE6 just needs to go away.

Select tag z-index glitch in IE

I thought this was fixed for IE7, but not so.

Set Up:
We have a page with 3 tabbed divs; only one is displayed at a time, while the others are display: none. The default div that displays on load contains a select tag which changes the content in a table inside that div based on date. The second div displays a dynamically generated table in standard HTML. The third and last div contains a Flash movie.


Problem:
In IE 6 & 7, when the second tab is clicked to hide the first div and display the second div, there is a mystery horizontal rule (at the same height as the top of the table in the first div). This line seems to be on the top layer, and causes anything below the line to be unclickable.


Solution:
Quickie: remove the <select> tag and use something else (custom slider or create the select menu as a DHTML drop-down instead).

This sounds like it could be fixed with the jQuery iframe method, but we haven’t tried it yet.

But what I want to know is why the select still creates the bug when it’s containing element has display: none. Does display: none mean that all the included elements are still lurking underneath? This makes no sense since normally, display: none causes the page to change size.

Solution for double margin bug in IE6

Here’s another one to cross off.

Problem:
Float a child block and add a margin on the same side as the float (so, margin-left if float: left, margin-right if float: right), and IE5-6 doubles the margin value.

Insane, right?

Solution:
For a long time, I simply halved the margin value in an IE conditional. Which is unacceptable when the margin value is odd.

But now, there’s a better solution. In the IE5-6 conditional:

.fix_doublemargin { display: inline; }

Happiness ensues!

Credit: P.I.E.

Solution for negative margins/indents bug in IE 6

Over two and a half years ago, I wrote about this bug for which I didn’t know a fix. This week, I’ve had the problem resurrect, and after more Googling, found the solution from another blogger. Here it is:

Give the child that is getting cut off, haslayout like so:

<!--[if lte IE 7]>
 <style type="text/css">
   #child {
     zoom: 1;
     position: relative;
   }
 </style>
<![endif]-->

In my situation, I’ve used just position: relative; to fix both IE 6 & 7 because using zoom: 1; wrecked the auto width of the child element. [Don’t know if this fixes IE 5.x, and don’t care.]

I’ve read from others that the reverse sometimes cures, too, so I suggest trying both, then trying one or the other to see which gets the result you need. Buffet-style IE hacks!

Woohoo! I can finally cross this one off.

Duplicate Rendered Characters in IE6

The Issue: I’ve got an absolutely positioned link inside a floated container. The link is being partially duplicated outside of and below the container.

According to P.I.E., the problem is that I have comments between all the floated siblings of the container, and IE has a problem figuring out what to do with comments between floats (WTF?!). This bug also pops up if there are hidden inputs and any item with display: none amongst the floating siblings, though I have yet to experience this delight for myself.

The Solution: I tried all of the suggestions on the P.I.E. site, but only two things worked for me.

1. Removing all of the comments directly between the floating containers.
2. Using the IE conditional to wrap the comments, as in:
   

<!--[if !IE]><!-- MY COMMENT --><!--[endif]-->

Opacity in IE6

The Issue: First problem is that text set with opacity looks like crap. It’s to do with the anti-aliasing (yes, even with ClearType enabled).

Second problem is that even when you use


.opaque {
-ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=70)";
filter: alpha(opacity=70);
}


The opacity doesn’t kick in.

The Solution: For problem 2, add zoom: 1; to the IE-only rule above.

Happiness ensues.

As for IE6 anti-aliasing ugliness, I just wipe out the filter: filter: none;. So you don’t get opacity in IE6. Not the end of my world.

According to stats for the website, at least a quarter of the IE traffic is still using version 6. UPGRADE, PEOPLE! DO IT! DO IT NOW!

The bane of my existence…

Italics in IE6

The Issue: Italics force their container slightly wider in order to show the overflowing slanting edge of the letter when the container (such as an <em>) does not have a set width.

This happens to break my P.I.E. (Positioning Is Everything) layout.

Happily, this is a well-documented bug at P.I.E.

The Solution: Because I no longer care about IE5, let alone IE5.5, I use this:

<!--[if lte IE 6]>
em, .italics { overflow: hidden; zoom: 1; }
<![endif]-->

Happiness ensues.

Vertical scroll bar hide-’n-seek in IE6

The Issue: Some visitors have called to complain that the scroll bar is missing on a page that requires them to click an “I Agree” button at the very bottom. This seems to be a sporadic problem because we’ve only fielded a couple of these calls, and my own testing machine doesn’t exhibit this problem.

Googling resulted in similar complaints from others — until I changed a few things in their stylesheet and fixed their problem. One person set top and left as well as position: relative on a containing div. Changing these to margin-top and margin-left and removing the position fixed his problem. The reason IE6 wasn’t displaying the scroll bar had to do with the positioned element overflowing the base container; that is, the positioned container was treated as a layer because of the top and left settings, so it was “outside” the content flow. Am I making sense? It makes sense in my head, but I’m not using the proper vocabulary.

Anyway, that isn’t what’s happening on my page because the containing elements are all stretching to match the length of the copy (which doesn’t happen with positioned layers). Which means that the scroll bar should be triggered. [I am using the One True Layout so I have a feeling this may be an issue with overflow: hidden on the containing row. I’ve set overflow: visible in the IE fix stylesheet, but I have no idea how to tell if it works or not.]

The other qualification is that not all IE6/Windows XP users are getting this bug.

The Predicament: How do you fix a problem that you can’t reproduce?

Also, we don’t know that this is the only page that is exhibiting the bug, only that it’s the most obvious, since if the visitor can’t click the button at the bottom, she can’t continue to the rest of the site. There haven’t been reports of the bug on other pages. Or perhaps because the visitor with the bug can’t get past this page, she can’t report further bugs on the rest of the site. Either way, I am not incredibly motivated to find a solution. I understand it’s a real problem, but unless I can see it in action, I can’t even begin to think where to start fixing it. I can’t mess with the stylesheet because I can’t tell if it’s making a difference or not.

Anyone ever had a problem like this, please help.

CSS drop-down/fly-out menus and IE select elements

IE5-6 renders select menus on the top-most layer, no matter how you set up the HTML or how you declare the z-index.

The last time this issue came up for me, I included a javascript that would make the select element disappear when the overlapping drop-downs were triggered. This worked fine because the select menu was the same width as the drop-down and so it was completely covered. Now with a different site, this is an impractical option, mainly because there’s no telling where the select menus will end up or how wide they’ll be.

I’m trying to meld a bunch of CSS drop-down/flyout solutions into one mass. Here are all the features I need:

1. Works in IE5-6, IE7, Safari, Mozilla/Firefox
2. Flyout sub-submenus
3. Drops over select menus in IE5-6
4. Includes hover margin of error (mouse forgiveness when moving from menu to sub-menu)
5. Simplest HTML = easiest maintenance

I’m looking at the combined ADxMenu with the WCH script from aplus.co.yu. Haven’t finished testing yet, so I’ll update this entry when it’s all working.

IE’s whitespace between list elements, part 2

So you’re creating a drop-down menu using unordered lists within unordered lists, and you’re using display: block for the li elements, along with a background colour that changes on hover. Looks great in Mozilla, but in IE there’s a mysterious extra space below the list item. It’s not padding and it’s not margin, because both of these have been set to 0!important. But there it is still.

Problem: IE, inexplicably, doesn’t recognise the closing tags for lists (</ul>) and list items (</li>). So any space between your closing tag and the next opening tag is treated as a whitespace. You can close these up, but it makes looking at or editing the markup later a real pain. And even if you do that, if you nest another list inside a list item, the whitespace reappears in IE7 — again, despite closing the gaps and declaring margin: 0.

Solution: Just found this most excellent solution from another blogger: declare float: left; clear: left on the li and the gap closes up! Marvelous!