Clicking menu list in IE causes items to shift

On this site, the menu has an odd problem in IE. Over on the left when I click the menu, sometimes the item I am clicking on sifts up… maybe 1 or 2 pixels. This ‘movement’ doesn’t occur in Firefox, etc, just IE. I have tried changing padding/margins and so on. No luck. I’m really stumped and only have 3 hairs left on my head over this. Any advice would be appreciated!

Thanks,
Carlos

Hi Carlos, welcome to Sitepoint.

I’m not sure where you want the answer to come from. What site? What code? Which version of IE??

I understand the hair-loss thing, I lose a lot too. :slight_smile:

Thanks for the quick reply!
I’m using Internet Explorer 8, but probably the same across all IE versions.

Odd, I put in the link in my previous post but it was removed.

Warehouse Facilities, Salt & Sand Storage, Riding Arenas, Livestock Housing, Construction Storage, Athletic Buildings - ClearSpan Tension Fabric Structures
ClearSpan.com (in case the link is killed again)

Under ‘Solutions’ on the left, those menu choices

Look for <ul class="menu_list">

So all the <li>. Clicking in IE 8 causes the menu to crawl upwards.
:blush:

Hi, sorry for the wait (weekend).

IE7 doesn’t do this, so it seems to be an IE8-only thing (and so also it isn’t anything to do with Haslayout).

That said, besides the super-annoying titles (links with link text should not have titles, esp not with exactly the same text!!), the only thing I see in the CSS that might be to blame is how you’ve styled the anchors… though I don’t see why or how this would be an issue with IE8. It’s just that I notice the single menu item moves up after it’s been clicked, so either while it has focus or active or visited. However since the page immediately refreshes, I can’t really get a good look at what’s happening. The changes seem permanent, which makes me suspect :visited.

You have


#sidebar_2 a:link { color: #333; text-decoration: none; padding:0;margin:0;}

#sidebar_2 a:visited { color: #333; text-decoration: none;padding:0;margin:0;}

You’ve got more CSS than necessary: anchors are inlines and inlines don’t have default margin or padding. Also, there’s really no point in having an a:link set of styles and then an a:visited etc. Did you know you can style “a” by itself? All the other pseudo-classes inherit from that.

#sidebar_2 a {
padding: 0; /for certainty/
color: #333;
text decoration: none;
}

Now you only need
#sidebar_2 a:focus,
#sidebar_2 a:hover {
color: #00723e;
text-decoration: underline;
}

But, because I haven’t seen shifting like this in IE in a long, long time, I’m going to ask you to also try making the anchors blocks of some sort.

I wonder if making them some sort of block element will stabilise them enough in IE8 that there is no longer a space difference.

Well, first, do this:
give the li’s ugly background colours and see if you see any gaps in IE8. I’m curious if there are any. If there’s a gap between the colours then it’s likely a margin issue… if not, a padding (of someone) issue.

Anyway, if you don’t mind the whole row where the text is being clickable, you can add
display: block;
to your anchors.

Otherwise, if you want to keep it like you have now (only the text is clickable) then try float: left; (if you ever add a border or background to the menu, li’s or sidebar then you’ll also want to enclose your floats).

I suspect either making one declaration for regular and visited links, and/or making the links themselves some kind of block element (floats are a type of block) will make IE8 act like everyone else. No guarantees tho : )

HI,

The problem is this line:


.solutions_row a:link, [B]a:visited, a:active[/B] {
    text-decoration: none;
    line-height:14px;
    color:#00723e;
}

You are defining the active and visited states with a different line-height hence the jump.

I believe you meant to do this:


.solutions_row a:link, 
[B].solutions_row a:visited, 
.solutions_row[/B] a:active {
    text-decoration: none;
    line-height:14px;
    color:#00723e;
}



or…


.solutions_row a {
    text-decoration: none;
    line-height:14px;
    color:#00723e;
}

Well, at least I was right about it being something with :visited… but now I wonder why IE8 was the only one who actively showed a difference in line-height…

IE has always had trouble (or a different interpretation) when using a:link and only applies the styles to links if they are not visited (and vice versa).

e.g.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
p a:link {
    height:100px;
    display:block;
    background:red
}
a:visited {
    background:green
}
</style>
</head>
<body>
<p><a href="#">test</a></p>
</body>
</html>


Once the link is visited in IE it shrinks to content height but other browsers still apply the display:block and the height rule is obeyed as well as the change in colour.

Not sure who is right which is why its best to define all styles for a{} as you have done in your example.

Not sure who is right which is why its best to define all styles for a{} as you have done in your example.

Well, duh, IE is obviously wrong… because it’s IE :smiley:

(that was a joke)

There was ONE exception to the “a styles everything” that Tommy would bring up now and then… something to do with using the name attribute. I never got that straight, or why anyone would ever actually use name attributes on anchors… but I think of it every time I post a "#element a {styles;} bit of code.

Yes, the a{} affects named anchors as well so that issue would have to be addressed if used. In most cases named anchors aren’t needed these days as id’s can be used for targets without adding extra code.

Wow, I can’t thank you enough! I was down to the last hair on my head and about to pull it. I’m print-based designer so I often feel my CSS isn’t efficient. I’m sure my stylesheets could be really cleaned up. When I view pro theme designers create their stylesheets I am in awe. I think I need to look for more of what you pointed out Paul because I probably aways do that in my CSS.

Thanks you as well Stomme!

[ot]

When I view pro theme designers create their stylesheets I am in awe.

If they are writing themes for templates, their CSS will be much, much more huge than what any good developer would ever use on a page they’ve completely written themselves. This is simply because Templates are bloated; bloated markup means bloated styling. Templates can’t help this: they need to be flexible to the end-user. [/ot]

None of us started out writing clean wonderful turns-turds-into-snowflakes CSS… it takes time and learning, which you’re doing. You can become nothing except better, the more you write.

It is working well now:
Warehouse Facilities, Salt & Sand Storage, Riding Arenas, Livestock Housing, Construction Storage, Athletic Buildings - ClearSpan Tension Fabric Structures

I’m going to need to go through the entire stylesheet to find more bugs, fat and other junk
:slight_smile: