fancy menu

[windandwaves]

Hi Guys

I need a bit of help with a fancy menu...

http://www.sunnysideup.co.nz/j/menu

I have two questions

1. it does not seem to work on Safari on a mac - what should I do?

2. right now, it can only open one menu item at the same time.... if
you move your mouse quickly to the next menu item, it does not open
it. I wrote this purposely like this so that the "old" menu would not
stay half open while the new one opened. Basically, what I want to do
is to start a new instance of the function. I can change all
variables into arrays, but can I make the entire function set into an
"instance" instead, so that multiple instances can operate at the same
time?

Thank you

Nicolaas

[David Mark]

On Jul 27, 2:54 am, windandwaves <[e-mail]:

Hi Guys

I need a bit of help with a fancy menu...

http://www.sunnysideup.co.nz/j/menu

I have two questions

1. it does not seem to work on Safari on a mac - what should I do?

Debug it in Safari on a Mac. Oddly enough, it works in the Windows
Safari beta.

>
2. right now, it can only open one menu item at the same time.... if
you move your mouse quickly to the next menu item, it does not open
it. I wrote this purposely like this so that the "old" menu would not

You want to use clicks, not rollovers for this. What if the user
doesn't have a mouse? Also, you are hiding content without regard to
whether scripting is enabled. Turn scripting off and you will see
what I mean.

stay half open while the new one opened. Basically, what I want to do

If the "opener" function is called for one pane while another is
sizing, clear your timeout (should really be an interval), size the
interrupted pane to its maximum height and set the timeout for the new
pane.

[windandwaves]

On Jul 27, 7:34 pm, David Mark <[e-mail]:

On Jul 27, 2:54 am, windandwaves <[e-mail]:

Hi Guys

I need a bit of help with a fancy menu...

http://www.sunnysideup.co.nz/j/menu

I have two questions

1. it does not seem to work on Safari on a mac - what should I do?

Debug it in Safari on a Mac. Oddly enough, it works in the Windows
Safari beta.

yes, I noticed that too (about the PC beta version)! Question is -
how do you debug javascript on safari... no easy task! I found this:

http://blog.deconcept.com/2005/07/28...en-debug-menu/

Will have a go!

>

2. right now, it can only open one menu item at the same time.... if
you move your mouse quickly to the next menu item, it does not open
it. I wrote this purposely like this so that the "old" menu would not

You want to use clicks, not rollovers for this. What if the user
doesn't have a mouse? Also, you are hiding content without regard to
whether scripting is enabled. Turn scripting off and you will see
what I mean.

Two good points!

>

stay half open while the new one opened. Basically, what I want to do

If the "opener" function is called for one pane while another is
sizing, clear your timeout (should really be an interval)

what do you mean with that?

, size the
interrupted pane to its maximum height and set the timeout for the new
pane.

Great idea!

Thank you

Nicolaas

[David Mark]

On Jul 27, 11:29 pm, windandwaves <[e-mail]:
[snip]

what do you mean with that?

I mean use setInterval, not setTimeout. It is an interval after all
and you won't have to keep setting the timeout.

[windandwaves]

On Jul 28, 4:38 pm, David Mark <[e-mail]:

On Jul 27, 11:29 pm, windandwaves <[e-mail]:
[snip]

what do you mean with that?

I mean use setInterval, not setTimeout. It is an interval after all
and you won't have to keep setting the timeout.

Here is the rework.... thanks for your help

http://www.sunnysideup.co.nz/j/menu/

[David Mark]

On Jul 29, 7:00 am, windandwaves <[e-mail]:
[snip]

>
http://www.sunnysideup.co.nz/j/menu/

That's a lot better. But are those headings going to actual links? I
see some link to cnn.com, but I assume that was for testing. If they
are not going to link anywhere, you should not include href
attributes. In your onload event, you should add href attributes (eg
"#") to turn them into links.

Also, it would be smoother to hide all but the first one, rather than
hiding all of them and then showing the first. And realize that on a
page with images, you will likely get a flash of the contents while
the page is loading. The alternative is to hide the contents by
default and create the associated style block (or individual rule)
with script, but that will make your code more complex.

And the contents for header 1 say they are for header 2, which made it
look broken. I looked at the source and saw that it is just a typo.

[David Mark]

On Jul 29, 7:00 am, windandwaves <[e-mail]:

On Jul 28, 4:38 pm, David Mark <[e-mail]:

On Jul 27, 11:29 pm, windandwaves <[e-mail]:
[snip]

what do you mean with that?

I mean use setInterval, not setTimeout. It is an interval after all
and you won't have to keep setting the timeout.

Here is the rework.... thanks for your help

http://www.sunnysideup.co.nz/j/menu/

I didn't notice the "please wait" alert when I first looked at it.
Hopefully that is just a placeholder for code that will handle the
"not done" situation more appropriately (as described earlier in the
thread.)

[Richard Cornford]

David Mark wrote:

On Jul 29, 12:28 pm, Richard Cornford wrote:

>David Mark wrote:

<snip>

>>I mean use setInterval, not setTimeout. It is an interval
after all and you won't have to keep setting the timeout.

That is not necessarily the right advice, or good advice. The
main problem with - setInterval - and - setTimeout - is that
neither will interrupt running javascript code (because javascript
is single threaded

<snip>

Yes. You want to set realistic intervals of course.

But is a realistic interval on a 266 MHz PDA processor the same as a
realistic interval on a 2.6 GHz desktop PC processor? Almost certainly
not.

<snip>

>execution of that code, but that is better than the chaos
that - setInterval - can introduce.

I've never seen or heard of the chaotic situation you describe
(locking up the browser.)

Hang around here for a couple of years and you will.

Is it your position that setInterval should
never be used?

No, my position is always that people should understand what they are
doing when they are making design/implementation decisions.

That would seem an extreme position.

It would be.

And correct me if I wrong, but to be safe for older browsers,
don't you have to use string arguments with setTimeout.

That is a bit of a leap. Where browser do not support function reference
arguments to - setTimeout - they also do not support function reference
arguments to - setInterval -, so it would have no baring on anything
previously discussed.

However, a compatibility trick (invented on this very group) exists, and
follows from the observation that when - setTimeout/setInterval - only
accept string arguments they type-convert whatever argument they get
into a string (the normal javascript-style thing to do) and so you can
reliably use function references in environments that only support
string arguments by providing the function object with a - toString -
method that outputs a string of code that will effectively call the
function in question by less-direct means. (Bearing in mind that the -
toString - method will be called along with the call to
setInterval/setTimeout, not at the point when the timeout/interval
expires).

That alone would put me off it as I use setInterval to call
object methods (from inside the objects.)

That seems to assume that the limitations of - setTimeout - in terms of
its handling of arguments would differ from the limitations of -
setInterval -. They don't.

Richard.

[David Mark]

On Jul 29, 8:05 pm, "Richard Cornford" <[e-mail]>
wrote:

David Mark wrote:

On Jul 29, 12:28 pm, Richard Cornford wrote:

David Mark wrote:

<snip>

>I mean use setInterval, not setTimeout. It is an interval
after all and you won't have to keep setting the timeout.

That is not necessarily the right advice, or good advice. The
main problem with - setInterval - and - setTimeout - is that
neither will interrupt running javascript code (because javascript
is single threaded

<snip>

Yes. You want to set realistic intervals of course.

But is a realistic interval on a 266 MHz PDA processor the same as a
realistic interval on a 2.6 GHz desktop PC processor? Almost certainly
not.

<snip>

execution of that code, but that is better than the chaos
that - setInterval - can introduce.

I've never seen or heard of the chaotic situation you describe
(locking up the browser.)

Hang around here for a couple of years and you will.

Is it your position that setInterval should
never be used?

No, my position is always that people should understand what they are
doing when they are making design/implementation decisions.

That would seem an extreme position.

It would be.

And correct me if I wrong, but to be safe for older browsers,
don't you have to use string arguments with setTimeout.

That is a bit of a leap. Where browser do not support function reference
arguments to - setTimeout - they also do not support function reference
arguments to - setInterval -, so it would have no baring on anything
previously discussed.

I thought there were older browsers that supported function arguments
with setInteval, but not setTimeout. Perhaps I was mistaken.

>
However, a compatibility trick (invented on this very group) exists, and
follows from the observation that when - setTimeout/setInterval - only
accept string arguments they type-convert whatever argument they get
into a string (the normal javascript-style thing to do) and so you can
reliably use function references in environments that only support
string arguments by providing the function object with a - toString -
method that outputs a string of code that will effectively call the
function in question by less-direct means. (Bearing in mind that the -
toString - method will be called along with the call to
setInterval/setTimeout, not at the point when the timeout/interval
expires).

That alone would put me off it as I use setInterval to call
object methods (from inside the objects.)

That seems to assume that the limitations of - setTimeout - in terms of

Yes it does. That was why I asked about the respective argument
requirements of older browsers.