Dropdown menu stays open in IE7

D

dorayme

After posting similar in another forum a few hours ago, it strikes me I
should have subscribed to this group and included it here. There may be
a simple js tweak that someone knows or can think of:

Under specific conditions, I have noticed a problem in IE7 with a
popular dropdown method. In IE7, the dropdown fails to spring back up if
you focus on another app or window and come back to the doc with the
dropdown. Anyone come across this who can suggest a simple solution or
find where such is outlined please:

<http://dorayme.890m.com/alt/IE7DDFocusProblem.html>
 
T

Thomas 'PointedEars' Lahn

dorayme said:
Under specific conditions, I have noticed a problem in IE7 with a
popular dropdown method. In IE7, the dropdown fails to spring back up if
you focus on another app or window and come back to the doc with the
dropdown. Anyone come across this who can suggest a simple solution or
find where such is outlined please:

<http://dorayme.890m.com/alt/IE7DDFocusProblem.html>
Click to expand...

I can confirm the described behavior in Mozilla/4.0 (compatible; MSIE 7.0;
Windows NT 5.1; {3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 1.1.4322;
..NET CLR 2.0.50727).

It may be related to the fact that the value of the `class' attribute when
the `li' element is hovered over, is invalid. The attribute value is
defined to be a whitespace-separated list of CSS class names, meaning
whitespace must be between class names, not preceding a single class name.
However, the too simple

sfEls.onmouseover=function() {
this.className+=" sfhover";
}

in the error-prone and too complicated

sfHover = function() {
// ...
}

just does that. The event listener should be declared a function --

function sfHover()
{
// ...
}

-- and should test whether it is OK to precede the new class name with
whitespace:

sfEls.onmouseover = function() {
if (this.className)
{
this.className += " sfhover";
}
else
{
this.className = "sfHover";
}
}

That said, IE 7 supports the :hover CSS pseudo-class for `li' elements, so
unless you want to blend-in the menu or achieve similar effects, you do not
need scripting for that (STFW). So

if (window.attachEvent) window.attachEvent("onload", sfHover);

in there is pointless in several respects (STFW for "attachEvent").

<body onload="sfHover()">

suffices and is standards-compliant, whereas sfHover() should be declared
before as follows:

<script type="text/javascript">
function sfHover() {}
</script>

<!--[if lt IE 7]>
<script type="text/javascript">
function sfHover()
{
// ...
}
</script>
<![endif]-->

There remains the issue of detecting the capabilities of UAs not based on
MSHTML, though.

Incidentally, Suckerfish really sucks.


PointedEars
 
D

dorayme

Thomas 'PointedEars' Lahn said:
I can confirm the described behavior in Mozilla/4.0 (compatible; MSIE 7.0;
Windows NT 5.1; {3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 1.1.4322;
.NET CLR 2.0.50727).

It may be related to the fact that the value of the `class' attribute when
the `li' element is hovered over, is invalid. The attribute value is
defined to be a whitespace-separated list of CSS class names, meaning
whitespace must be between class names, not preceding a single class name.
However, the too simple

...
Click to expand...
That said, IE 7 supports the :hover CSS pseudo-class for `li' elements, so
unless you want to blend-in the menu or achieve similar effects, you do not
need scripting for that (STFW). So
...

There remains the issue of detecting the capabilities of UAs not based on
MSHTML, though.

Incidentally, Suckerfish really sucks.
Click to expand...

Thanks for your information. It seemed a queer bug in IE7.

I have a "solution" now, it was detected by someone at alt.html. You can
read the thread there (similar subject name and recent). Basically it
was reaction by IE7 to a lack of a change in styling between the state
of a link and its hover, IE7 seems to need various differences. For
example commenting out

dropDownNav, .dropDownNav ul {
padding: 0;
margin: 0;
color: #00c;
background: #ffc;
/* list-style-type: none; */
line-height: 1.8;
}

stops the queer phenomenon. Odd bug but have we not come to expect such
from IE?

Seems to have nothing to do with the script. Reason I posted is I was
not sure if there was something in the script IE7 was not liking
(whether it needed it or not. And whether it needed it or not, I kept
forgetting! I know that IE6 needs it. (I can test for IE6 but not for
IE7 just at the moment.)

Well, I am no fan of dropdwns (never used one) but there came a moment
where a one level one was a temptation considering it was not essential
but would be useful for most people. Not sure why you say Suckerfish
sucks. I would be particular interest in hearing why the example I gave
(not some other example or multilevel or anything else) sucks in plain
real life consequences (like, it does not work in popular enough browser
x, or it really mucks things up for blind folk, or whatever.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

IE7 DropDown Menu stays dropped. 19
Left margin off-screen in IE7 js-date2 2
Using Teng's datetimepicker in IE7 and Nitro PDF 3
DROPDOWNLIST MENU OPEN (CLICK) 0
Combo dropdown submit button to open in new window 3
In IE, forcing focus on window makes dropdown selects inoperable 3
Docbook vs. Open Doc, some more info 2
UpdateProgress Control and Delays in IE 4

Members online

Total: 50 (members: 2, guests: 48)
Robots: 175

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,811
Latest member
SaulFernan

Latest Threads

Top