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]

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]

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/safaris-hidden-debug-menu/

Will have a go!

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!

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]

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]

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/

 

[Richard Cornford]

On Jul 27, 11:29 pm, windandwaves wrote:
[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.

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
they just could not do so). So in reality you specify the period in the
setTimeout/Interval call and the browser will act the first available
opportunity _after_ that period (subject to the precision of the OS
timers, which can be as poor as ticking at 56+ millisecond intervals,
and rarely better than 10 millisecond).

With - setInterval -, if the interval comes up while another script is
executing the code executed by - setInterval - will have to wait until
it has finished executing. If, while it is waiting, the period expires
aging the same code will have to wait again for the current code to
finish before it can execute, except this time it also has to wait for
the first - setInterval - code to execute before it can start. And this
accumulation of queued code continues until the originally running code,
and all the code that -setInterval - has set up to run on the completion
of pervious code, has finished executing.

It is extremely unlikely that running all this - setInterval - scheduled
code in immediate succession will be doing anything more useful than
running it once, but it will take time, and may be sufficient time for
it to block more of - setInterval -'s attempts to execute code.
(Remembering that while this is going on the browser is also queuing
code execution for events triggered by user interactions) And all if
this is going to be very variable depending on how fast the computer
running the code is, how loaded it is, and how fast the javascript
environment provided by the browser is. Those are a lot of variables to
test, and a worst-case outcome, on a sufficiently slow system, is that
the first interruption results in a chin reaction where the browser
queues up so much - setInterval - code that it can never dig its way
out, and just locks up with CPU at 100% from then on.

The advantage with - setTimeout - code calling - setTimeout - when it
finishes is that only one piece of code can ever be waiting for the
completion of running javascript. On a slow, and/or heavily loaded
system, the result may be the slower (more delayed/interrupted)
execution of that code, but that is better than the chaos that -
setInterval - can introduce.

Richard.

 

[David Mark]

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 27, 11:29 pm, windandwaves wrote:
[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.

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

Yes. Neither will result in perfect synchronization as they have to
wait for other code to finish.

they just could not do so). So in reality you specify the period in the
setTimeout/Interval call and the browser will act the first available
opportunity _after_ that period (subject to the precision of the OS
timers, which can be as poor as ticking at 56+ millisecond intervals,
and rarely better than 10 millisecond).
Right.


With - setInterval -, if the interval comes up while another script is
executing the code executed by - setInterval - will have to wait until
it has finished executing. If, while it is waiting, the period expires
aging the same code will have to wait again for the current code to
finish before it can execute, except this time it also has to wait for
the first - setInterval - code to execute before it can start. And this
accumulation of queued code continues until the originally running code,
and all the code that -setInterval - has set up to run on the completion
of pervious code, has finished executing.

Yes. You want to set realistic intervals of course.

It is extremely unlikely that running all this - setInterval - scheduled
code in immediate succession will be doing anything more useful than
running it once, but it will take time, and may be sufficient time for
it to block more of - setInterval -'s attempts to execute code.

Depends on the code and interval.

(Remembering that while this is going on the browser is also queuing
code execution for events triggered by user interactions) And all if
Right.

this is going to be very variable depending on how fast the computer
running the code is, how loaded it is, and how fast the javascript
environment provided by the browser is.

Of course.

Those are a lot of variables to

test, and a worst-case outcome, on a sufficiently slow system, is that
the first interruption results in a chin reaction where the browser
queues up so much - setInterval - code that it can never dig its way
out, and just locks up with CPU at 100% from then on.

That's why you want to use a realistic interval (eg not 1ms.)

The advantage with - setTimeout - code calling - setTimeout - when it

I was wondering if we would get to that.

finishes is that only one piece of code can ever be waiting for the
completion of running javascript. On a slow, and/or heavily loaded
system, the result may be the slower (more delayed/interrupted)

It is generally a little choppier.

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.) Is it your position that setInterval should
never be used? That would seem an extreme position.

And correct me if I wrong, but to be safe for older browsers, don't
you have to use string arguments with setTimeout. That alone would
put me off it as I use setInterval to call object methods (from inside
the objects.)

 

[David Mark]

[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]

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.

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]

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.




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


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


It would be.


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 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.