More rMenu & hasLayout

The IE7 demo page has been updated. Follow along if you’d like.

I’ve run into my old friend, the background color bug. But now I understand it.

If you try to use menu #5 to navigate layouts->skidoo->background images you’ll find the menu disappears as you move between background images and border into masthead. (Actually it might vary depending on your computer’s default font size).

In Menu #6 it works fine. What’s wrong with #5? Well the only difference between 5 and 6 is that 6 has a background-color set on the UL elements.

It seems what’s happening is as the mouse moves between elements in the popped menu IE is calculating what object it’s currently on top of. Without a background color, the text of the page (perhaps any element outside of the menu system) appears to take the focus, as if it’s on top of the menu. It’s like IE is looking THROUGH the menu item.

If I add a background color to the anchors or ULs IE will recognize there’s an object between the mouse and the text and that will get focus and the menu doesn’t disappear.

Now I’ve got a background color set on the LI elements. I set a background color on the anchors only when they have focus. This is so I can use color to show the path to the current position in the menu. (Note how the Layouts and Skidoo menu options turn orange as you get to the third-level of the menu.) If I did set background colors on all anchors, even those that aren’t active, this disappearing menu (background color) bug goes away.

So backgrounds on ULs and anchors fixes it, but not the LI. Why?

Well, the UL and anchor tags have hasLayout triggered. The LIs don’t.

So we see yet one more curious property of hasLayout.

And here’s the thing. Here’s a really big gripe with IE7. They’ve had several years to develop a new rendering engine. Did they? No. They just patched what they could of the old engine. So this reliance on the infamous hasLayout property will continue, along with all the bugs associated with it. And as long as they continue to use their old layout engine IE will continue to suck for advanced CSS design.

Microsoft: REWRITE IE’S LAYOUT ENGINE!

Oh, haven’t heard back from those IE guys yet, but I did forward along the information I had on this bug.

Is everyone else starting to understand why I hate IE7?

rMenu & hasLayout

I’ve yet to hear back from Microsoft regarding the IE7 bugs, so I took matters into my own hands and have found out what’s causing the majority of the bugs and how to work around them.

To follow along you’ll need to download IE7 RC1. Then check out the IE7 rMenu Demo.

It’s all about hasLayout. This is the best review of all things related to hasLayout and this is Microsoft’s take on the situation. These two documents will give you everything you need, and more, to understand what might be the source for the vast majority of IE-related layout bugs.

And so it is no surprise that it is the source of my problems as well.

Menu 1 & 2 in the demo have specific widths set on the LI elements. This triggers hasLayout on the LI elements. Menu 3 has no specific width set on the LIs and thus they do not have layout. 1 & 2 display gap, z-index, and visibility bugs, 3 does not exhibit any of those bugs.

But menu 3 has a new bug. Mouse through the top-level menu and you’ll see the content below the menu moves vertically a few pixels. This doesn’t happen in menus 1 & 2. What’s going on?

( Nevermind the lack of side borders. That’s less an IE bug and more a poor management of applying negative margins to have elements overlap. I fix that in menu 5… but we’re getting ahead of ourselves. )

Menu 4 is an exact copy of Menu 3 with one exception: zoom:1; is applied to the anchors inside the LIs. The vertical jumping disappears. This means triggering hasLayout on the anchors fixes the text jog.

Menu 5 is a (relatively) bug-free implementation working in IE7.

But there’s one problem left. When the menus pop over text and you mouseover the menu that’s over a text block, the menu disappears. Actually it’s when you mouse over the text and you’re outside an anchor (hasLayout strike again!) such as the border between menu items (which is on the LI element).

So maybe I need to draw borders on anchors and not list items. I know I had a specific reason why I didn’t want to do that, but I’ve forgotten it. Guess I’m going to rediscover why.

So there you go. Some headway in the rMenu saga.

IE7

On Friday I was contacted by a member of the IE7 team regarding my previous blog entry asking for specifics regarding the problems I’m having with IE7.

Cool. Whoever got the IE7 guy(s) to see that post, thanks.

So I put together a very quick demo of dropdown menus targeted at IE7. I stripped out all the CSS hacks and other misc. crap that wasn’t needed so that it’s just the relevant CSS.

If you want to follow along you’ll need to have the latest copy of IE7 (RC1) installed on your machine.

In the stylesheet is a section titled Test/Debug Menus and is the only CSS in the whole stylesheet specifically targetted at the individual menus. All other CSS is shared across all four menus.

Menu 1 has gaps between a couple of the menu items. These gaps also exist in the submenus. They seem to be caused by the presence of the hidden submenu. These submenus are absolutely positioned; that should remove them entirely from the flow of the document. It seems this is not entirely the case. Z-indexing seems to be broken as well since the menus pop below the LI elements that do not have focus.

However in Menu 2 I float the LI elements and the gaps go away and the z-index problem is fixed. Floating the ULs doesn’t seem to do anything. So what do you suppose that means?

In Menu 3 the LI widths are set to auto; the default value. This means they should go as wide as they can (as they are block objects). The parent UL element has a fixed width applied to it (10ems) so the LIs are going to be 10ems (or so). Well that works, except the side borders on the LI elements aren’t being rendered. Furthermore, if you mouse over all the top-level menu items you’ll notice everything below menu 3 will jog up 1 pixel. If you scroll all the way up, then all the way down, and do this again, everything including and above menu 3 jogs up 1 pixels. It’s a really odd bug that I’ve encountered quite a lot in IE7.

In Menu 4</strong I try to tackle a bug present in all 4 menus. It seems that the flag which sets whether an element is visible or hidden isn’t being propagated correctly. This leads to an empty third-level menu popping while your mouse is only on a top-level menu item. Here’s how you generate the bug:

1. mouse over the “Layouts” menu item
2. mouse over the “Skidoo” submenu item
3. mouse out of the menu by moving your mouse up the screen to an empty space above the “Skidoo” menu item
4. mouse over “Layouts” again

You should now see three levels of the menu instead of 2. The third level is empty.. just a bunch of blank boxes. Now if you were to mouse out of the menu system by going back up to the “Layouts” menu item and then off the menu, that blank third-level menu won’t appear when you mouse over “Layouts” again.

Your guess is as good as mine in trying to figure out what causes this. In menu 4 I’ve included CSS to explicitly hide UL elements 2 levels below the LI that currently has focus. This doesn’t resolve the issue. So.. .I duno.

My biggest, most insignificant gripe with IE7 is the inability to change the vertical position of the menu bar. Menu bar is the whole “file/edit/view/etc..” text menu bar that’s commonly found at the top of any/every windows application. IE7 hides this bar by default. I want my menu bar because it gives quick access to the more advanced features of IE7. However if I enable it the menu bar appears below the navigation bar (bar with previous/next/reload/stop buttons and the address bar). There is an option to lock (and unlock) the toolbars to position them. However the navigation bar has a static position and cannot be repositioned.

Now why should anyone care about such an insignificant thing as where a menu bar is placed? Well, my first response is, if it doesn’t matter why is there any option at all to change how menu bars are positioned in any of the countless Microsoft applications in which that customization feature is available?

My second argument is that there’s a certain amount of “muscle memory” involved. We’re so use to the standard windows application UI that it’s almost an unconscious act to locate the “X” to close an application, or to find the FILE menu to save a document. By changing the position of the menu bar you disrupt this ‘automated’ process we have. This can cause sutble/momentary confusion and frustration as we now have to ‘actively’ search for the menu bar.

My third argument is aesthetic value. The visual consistency across windows applications where you have a title bar along the top with some solid or gradient color over a text-based menu system provides a level of comfort and eases the process of learning a new application because of that familiarity. It’s like meeting a new person. Sure there are lots of things that are different, but there’s a lot that we are already familiar with… eyes, nose, a mouth, hair, ears, arms, legs, etc… this gives us a base to more easily form a relationship with the person.

I think I know why Microsoft is doing this. I think they’re trying to keep the address of the page you’re viewing visible while browsing the menu. Or it’s because that’s not a real menu bar. If I right-click on open areas of the menu bar I get a context menu with menu-oriented options. If I do this on the navigation bar I get the system menu (the thing you get when you click on the application’s icon in the upper-left of the window or it’s button on the task bar). So methinks a shortcut was taken to implement that navigation bar and it simply is impossible to move. Either way, I want to move the damn thing!

So there you go. That’s a good chunk of the gripes I’m having with IE7. If you’ve got others toss them in the comments.

Where Am I?

I’ve become frustrated — perhaps jaded — with CSS and needed a good break from it. Maybe it’s burnout. Trying to keep things compatible cross-browser is just incredibly frustrating.

IE7 is really starting to piss me off. I hate the UI. Something so simple and basic and they had to go and screw it up. Then there’s the CSS system. They’re on beta 3 now and they still don’t have it right. It’s certainly better than IE6 in many ways.. but the ways that it breaks destroy a lot of my work at doing more advanced things like the drop-down menu. Layouts that work in every other browser are now breaking in IE7. I wish I could find one IE developer, grab them, and show just how broken their CSS is.

It’s frustrating. And every time I look at CSS I’m reminded of this and these negative feelings and it just destroys any existing motivation to work with CSS.