Onmouseover, onmouseout question

[peashoe]

I need to create a javascript that not only changes a picture, but also
the link: here is an example of what I need www.myweddingfavors.com/
I'm working on this website and have it half done:
www.mygiftbasketideas.com - I also what the table to change color on
mouseover - this is the code I am using so far:

in the script.js
if (document.image s)
{
image2= new Image(100,100);
image2.src="/store/images/P/romance.jpg";
image3= new Image(100,100);
image3.src="/store/images/P/welcome_baby_bo y.jpg";
image4= new Image(100,100);
image4.src="/store/images/P/picnic.jpg";
image5= new Image(100,100);
image5.src="/store/images/P/vineyard.jpg";
image6= new Image(100,100);
image6.src="/store/images/P/european.jpg";
image7= new Image(100,100);
image7.src="/store/images/P/lasting.jpg";
image8= new Image(100,100);
image8.src="/store/images/P/birthday_celebr ate.jpg";
image9= new Image(100,100);
image9.src="/store/images/P/patriotic.jpg";
image10= new Image(100,100);
image10.src="/store/images/P/tea.jpg";
image11= new Image(100,100);
image11.src="/store/images/P/thanks.jpg";
image12= new Image(100,100);
image12.src="/store/images/P/spa_pleasure.jp g";
}

function change1(picName ,imgName)
{
if (document.image s)
{
imgOn=eval(imgN ame + ".src");
document[picName].src= imgOn;
}
}

imgOn=eval(imgN ame + ".src");
document[picName].src= imgOn;
then on the HTML page:
<table width="600" border="1" bordercolor="#9 93333" cellspacing="0"
cellpadding="00 ">
<tr>
<th scope="col" align="left"><A href="#"><IMG alt=""
src="{$ImagesDi r}/romance.jpg" name="pic1" border=0></A></th>
<th scope="col" valign="top">
<table height="100%" width="200" cellspacing="0" cellpadding="0"
border="1" background="/store/skin1/images/BACKGROUND.jpg"
bordercolor="#9 93333">
<tr><td width="200" height="30" align="left"><A
onMouseover="ch ange1('pic1','i mage2')"
onMouseout="cha nge1('pic1','im age2')" title="Valentin e Gifts"
rel="nofollow" href="/Valentine-gift-basket.html">
<div class="menu_tex t">&nbsp;&nbsp; &nbsp;&nbsp;&nb sp;Valentine
Gifts</div>
</A></td></tr>...........

How do I do both?
Thanks in advance
Lisa

[Bart Van der Donck]

peashoe wrote:

I need to create a javascript that not only changes a picture, but also
the link: here is an example of what I need www.myweddingfavors.com/
I'm working on this website and have it half done:
www.mygiftbasketideas.com - I also what the table to change color on
mouseover - this is the code I am using so far:

[snip code]

How do I do both?

This demonstrates the principle:

<!-- BEGIN -->
<script type="text/javascript">
linkimg_over = new Image();
linkimg_over.sr c =
'http://www.myweddingfa vors.com/images/core/bridalBtn-over.gif';
linkimg_out = new Image();
linkimg_out.src =
'http://www.myweddingfa vors.com/images/core/bridalBtn.gif';
otherimg_over = new Image();
otherimg_over.s rc =
'http://www.mygiftbaske tideas.com/store/images/P/welcome_baby_bo y.jpg';
otherimg_out = new Image();
otherimg_out.sr c =
'http://www.mygiftbaske tideas.com/store/images/P/birthday_celebr ate.jpg';

</script>

<a href="#"
onMouseover="
document.getEle mentById('pic1' ).src = eval('linkimg_o ver.src');
document.getEle mentById('pic2' ).src = eval('otherimg_ over.src');
"
onMouseout="
document.getEle mentById('pic1' ).src = eval('linkimg_o ut.src');
document.getEle mentById('pic2' ).src = eval('otherimg_ out.src');
">
<img border="0" width="215" height="33" id="pic1"
src="http://www.myweddingfa vors.com/images/core/bridalBtn.gif">
</a>
<img id="pic2" border="0" width="400" height="350"
src="http://www.mygiftbaske tideas.com/store/images/P/birthday_celebr ate.jpg">
<!-- END -->

In order to work around buffering issues, I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">

Hope this helps,

--
Bart

[Bart Van der Donck]

Bart Van der Donck wrote:

[...]

In order to work around buffering issues, I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">

Erm, I mean the opposite:

<META HTTP-EQUIV="cache-control" CONTENT="cache" >
<META HTTP-EQUIV="expires" content="Sat, 31 Dec 2050 23:59:59 GMT">
<META HTTP-EQUIV="pragma" CONTENT="cache" >

--
Bart

[Richard Cornford]

Bart Van der Donck wrote:
<snip>

<a href="#"
onMouseover="
document.getEle mentById('pic1' ).src = eval('linkimg_o ver.src');

<snip>

One of the more telling indicators of an - eval - abuse is where the
argument to - eval - is a siring literal (rather than an expression
combining string literals and variables, which is only almost always
an - eval - abuse). There are no circumstances where the contents of
such a string literal argument to - eval - cannot be used to replace the
entire - eval - call. That is:-

eval('linkimg_o ver.src');

- can _always_ be replaced with:-

linkimg_over.sr c

- to _precisely_ the same effect (except for being shorter, clearer,
(potentially much) faster, better supported and generally easier to
debug if erroneous).
Why use the general - document.getEle mentById('pic1' ) - to reference an
IMG element when the DOM standard - document.images['pic1'] - is more
self-documenting (you know from the source code that an IMG element is
the intended subject of the operation) and potentially much faster
(because of the size difference between the images collection and the
entire document)?

In order to work around buffering issues,

If there are "buffering issues" you should be able to state what they
are (details, cause and effect relationships, symptoms and
consequences). Otherwise you are just suggesting that there is a 'bogy
man' named "buffering issues" out there, waiting to byte those who do
not chant the traditional incantation. That is hardly a rout to
understanding, and certainly not a rout to taking informed control over
achieving a desired outcome in a system that is ultimately rational and
logical.

I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">

<snip>

There is nothing that requires (or even implies) that a UA should pay
any attention to <META HTTP_EQUIVeleme nts in mark-up, and there is
good reason to believe that even if a UA does it would not do so in
preference to HTTP headers sent with a resource (and are subject to
detailed specification). Rather than propose the cargo-cult/mystical
inaction formulation of using META elements in the mark-up, why not
propose the employment of the appropriate HTTP headers?

Richard.

[Bart Van der Donck]

Richard Cornford wrote:

Bart Van der Donck wrote:
<snip>

<a href="#"
onMouseover="
document.getEle mentById('pic1' ).src = eval('linkimg_o ver.src');

<snip>

One of the more telling indicators of an - eval - abuse is where the
argument to - eval - is a siring literal (rather than an expression
combining string literals and variables, which is only almost always
an - eval - abuse). There are no circumstances where the contents of
such a string literal argument to - eval - cannot be used to replace the
entire - eval - call. That is:-

eval('linkimg_o ver.src');

- can _always_ be replaced with:-

linkimg_over.sr c

- to _precisely_ the same effect (except for being shorter, clearer,
(potentially much) faster, better supported and generally easier to
debug if erroneous).

Then that is a better practice indeed.

Why use the general - document.getEle mentById('pic1' ) - to reference an
IMG element when the DOM standard - document.images['pic1'] - is more
self-documenting (you know from the source code that an IMG element is
the intended subject of the operation) and potentially much faster
(because of the size difference between the images collection and the
entire document)?

I'ld say this is more a matter of preference of the coder.

In order to work around buffering issues,

If there are "buffering issues" you should be able to state what they
are (details, cause and effect relationships, symptoms and
consequences). Otherwise you are just suggesting that there is a 'bogy
man' named "buffering issues" out there, waiting to byte those who do
not chant the traditional incantation. That is hardly a rout to
understanding, and certainly not a rout to taking informed control over
achieving a desired outcome in a system that is ultimately rational and
logical.

I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">

<snip>

There is nothing that requires (or even implies) that a UA should pay
any attention to <META HTTP_EQUIVeleme nts in mark-up, and there is
good reason to believe that even if a UA does it would not do so in
preference to HTTP headers sent with a resource (and are subject to
detailed specification). Rather than propose the cargo-cult/mystical
inaction formulation of using META elements in the mark-up, why not
propose the employment of the appropriate HTTP headers?

I am not aware of an HTTP header that affects image preloading
techniques from javascript, and I'ld be surprised if this would exist.

Let me tell you why I counseled the use of those META headers. About
two/three years ago I used such image preloading techniques in a
geo-application. It worked well, but it appeared that in Microsoft
Internet Explorer (I think 5.x at that time) the image buffer could be
flushed sometimes so that the browser needed to fetch the image(s) back
from server. It didn't happen too often though, but it did, and I had a
feeling at that time that it had something to do with the code
complexity of that project as well. Since I added the META-tags, the
images were cached correctly and were always shown immediately.

For me that was reason enough to start using them ever since for this
kind of image preloading.

--
Bart

[Richard Cornford]

Bart Van der Donck wrote:

Richard Cornford wrote:

>Bart Van der Donck wrote:
<snip>

<a href="#"
onMouseover="
document.getEle mentById('pic1' ).src = eval('linkimg_o ver.src');
<snip>

One of the more telling indicators of an - eval - abuse is where
the argument to - eval - is a siring literal (rather than an
expression combining string literals and variables, which is
only almost always an - eval - abuse). There are no circumstances
where the contents of such a string literal argument to - eval -
cannot be used to replace the entire - eval - call. That is:-

eval('linkimg_ over.src');

- can _always_ be replaced with:-

linkimg_over.s rc

- to _precisely_ the same effect (except for being shorter,
clearer, (potentially much) faster, better supported and
generally easier to debug if erroneous).

Then that is a better practice indeed.

>Why use the general - document.getEle mentById('pic1' ) - to
reference an IMG element when the DOM standard -
document.image s['pic1'] - is more self-documenting (you
know from the source code that an IMG element is the
intended subject of the operation) and potentially
much faster (because of the size difference between the
images collection and the entire document)?

I'ld say this is more a matter of preference of the coder.

And using - eval - on a single string literal is not just a matter of
preference?

There are 4 reasons for using - doucment.images - to reference IMG
elements:-

1. It is HTML DOM standard (which is an applicable standard
in an environment where you are referencing (x)HTML IMG
elements.
2. It is back compatible (even referencing by ID attribute
instead of by NAME attribute you have included IE 4 at
zero additional coding effort).
3. It is self-documenting (you know the subject is going to
be an IMG element).
4. It is potentially fastest (as the browser has pre-assembled
a collection of all IMG elements on the page)

While arguments in favour of using - getElementById - in its place are
restricted to:-

1. It is Core DOM standard.

Is it really personal preference that would have someone use the latter
over the former, or something else?

>>In order to work around buffering issues,

If there are "buffering issues" you should be able to state
what they are (details, cause and effect relationships,
symptoms and consequences). Otherwise you are just suggesting
that there is a 'bogy man' named "buffering issues" out there,
waiting to byte those who do not chant the traditional
incantation. That is hardly a rout to understanding, and
certainly not a rout to taking informed control over
achieving a desired outcome in a system that is ultimately
rational and logical.

>>I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">

<snip>

There is nothing that requires (or even implies) that a UA
should pay any attention to <META HTTP_EQUIVeleme nts in
mark-up, and there is good reason to believe that even if
a UA does it would not do so in preference to HTTP headers
sent with a resource (and are subject to detailed
specification) . Rather than propose the cargo-cult/mystical
inaction formulation of using META elements in the mark-up,
why not propose the employment of the appropriate HTTP
headers?

I am not aware of an HTTP header that affects image preloading
techniques from javascript, and I'ld be surprised if this would
exist.

You don't think the HTTP pragam, expires and cache-control headers might
come into this then? Do you actually appreciate what HTTP-EQUIV is
supposed to mean in a META element (what aspect of HTTP the EQUIV is
'equivalent' to)?

Let me tell you why I counseled the use of those META headers.
About two/three years ago I used such image preloading
techniques in a geo-application. It worked well, but it
appeared that in Microsoft Internet Explorer (I think 5.x
at that time) the image buffer could be flushed sometimes

What is the "image buffer"? Are you talking about the browser's
client-side cache, or images in a running browser's memory?

so that the browser needed to fetch the image(s)
back from server. It didn't happen too often though, but
it did, and I had a feeling at that time that it had
something to do with the code complexity of that project
as well.

The HTTP headers sent with the images are much more likely to influence
the frequency with which the browser sees the need to query the server
for updates. From what I am reading I suspect that never knew what those
headers were (and possible never knew they existed).

Since I added the META-tags, the images were cached
correctly and were always shown immediately.

So you observed a coincidence, but never established a cause and effect
relationship.

For me that was reason enough to start using them ever
since for this kind of image preloading.

That is "programmin g by coincidence", and so not something you should be
recommending to others. Most of the META tag cargo-cults have started
that way (all praise the mighty HTTP-EQUIV; "META, META, Meta, meta,
....".)

Richard.

[dd]

Bart Van der Donck wrote:

Why use the general - document.getEle mentById('pic1' ) - to reference an
IMG element when the DOM standard - document.images['pic1'] - is more

I'ld say this is more a matter of preference of the coder.

True, it is a preference of the coder, but it's somewhat
inefficient to "ask" the browser to find something by looking
through the whole DOM, when it can already restrict the
search to the images array instead.

It's equally inefficient to do getElementsByTa gName('iframe')
when document.frames[] gives you the same thing.

~dd

[dd]

peashoe wrote:

I need to create a javascript that not only changes a picture, but also
the link: here is an example of what I need www.myweddingfavors.com/

There's an array built for you by the browser called
document.links. You can manipulate the links objects
to change the target:

document.links[i].target = some_alt_target ;

If you use an onmouseover event and call a function to
do the change, you can reference the link object using
the this keyword ( this.target ).

~dd

[Bart Van der Donck]

Richard Cornford wrote:

Bart Van der Donck wrote:

I am not aware of an HTTP header that affects image preloading
techniques from javascript, and I'ld be surprised if this would
exist.

You don't think the HTTP pragam, expires and cache-control headers might
come into this then? Do you actually appreciate what HTTP-EQUIV is
supposed to mean in a META element (what aspect of HTTP the EQUIV is
'equivalent' to)?

The actual HTTP-headers are more important, yes. HTTP-EQUIV might help
here or there and it certanly doesn't harm to repeat an HTTP header in
HTTP-EQUIV. It's right that 'equivalent' is too much honour for these
tags.

Let me tell you why I counseled the use of those META headers.
About two/three years ago I used such image preloading
techniques in a geo-application. It worked well, but it
appeared that in Microsoft Internet Explorer (I think 5.x
at that time) the image buffer could be flushed sometimes

What is the "image buffer"? Are you talking about the browser's
client-side cache, or images in a running browser's memory?

I'm not sure about the exact distinction between those two. Just the
images that were preloaded, stored in buffer and available for
(immediate) referencing on the page.

so that the browser needed to fetch the image(s)
back from server. It didn't happen too often though, but
it did, and I had a feeling at that time that it had
something to do with the code complexity of that project
as well.

The HTTP headers sent with the images are much more likely to influence
the frequency with which the browser sees the need to query the server
for updates. From what I am reading I suspect that never knew what those
headers were (and possible never knew they existed).

Then tell me, does javascript read out the image's HTTP headers in
order to decide when it should flush the (preloaded) image ? I would be
surprised if that were true.

Working with such stuff seems very browser dependent and very dangerous
to rely on. But yes, there is technically no problem at server side.

Since I added the META-tags, the images were cached
correctly and were always shown immediately.

So you observed a coincidence, but never established a cause and effect
relationship.

That is true up to a certain point. I tested my solution thoroughly and
I concluded that it worked okay (which it still does until today, btw).
I'm not sure how things work from your Sedes Sapientiae, but I have
less-than-perfect expierences as well.

For me that was reason enough to start using them ever
since for this kind of image preloading.

That is "programmin g by coincidence", and so not something you should be
recommending to others. Most of the META tag cargo-cults have started
that way (all praise the mighty HTTP-EQUIV; "META, META, Meta, meta,
...".)

It's not programming by coincidence, but a practical solution to a
concrete problem.

--
Bart

[Richard Cornford]

Bart Van der Donck wrote:

Richard Cornford wrote:

>Bart Van der Donck wrote:

>>I am not aware of an HTTP header that affects image
preloading techniques from javascript, and I'ld be
surprised if this would exist.

You don't think the HTTP pragam, expires and cache-control
headers might come into this then? Do you actually appreciate
what HTTP-EQUIV is supposed to mean in a META element (what
aspect of HTTP the EQUIV is 'equivalent' to)?

The actual HTTP-headers are more important, yes. HTTP-EQUIV
might help here or there

"Might help here or there"? Are we working with technology or offering
prayers and sacrifices for a good harvest?

and it certanly doesn't harm to repeat an HTTP header in
HTTP-EQUIV.

Web development is plagued with things that 'do no harm'. It should be
important to distinguish between the things that do some good and the things
that are no more that mystical incantations, and possibly the things that
were once of some value but have not become redundant (and are continued
because they are doing no harm so nothing exists to break the habit).

An example of the latter is wrapping SCRIPT element contents in <!--
.... -->, which, for a short period, was a good idea, but is now totally
redundant but persist because it is (mostly) harmless. Unfortunately the way
in which it persist is in people who operate on the basis of mystical
incantation propose to others that this incantation is necessary when
'conjuring' a SCRIPT element.

It's right that 'equivalent' is too much honour for these
tags.

Absolutly.

>>Let me tell you why I counseled the use of those META headers.
About two/three years ago I used such image preloading
techniques in a geo-application. It worked well, but it
appeared that in Microsoft Internet Explorer (I think 5.x
at that time) the image buffer could be flushed sometimes

What is the "image buffer"? Are you talking about the browser's
client-side cache, or images in a running browser's memory?

I'm not sure about the exact distinction between those two.
Just the images that were preloaded, stored in buffer and
available for (immediate) referencing on the page.

The process that is labelled "preloading " is more a matter of pre-requesting
an image, with the intention of moving it into the browser's local disc
cache. The cachablitly of that image has a considerable impact on the
usefulness of doing that.

>>so that the browser needed to fetch the image(s)
back from server. It didn't happen too often though, but
it did, and I had a feeling at that time that it had
something to do with the code complexity of that project
as well.

The HTTP headers sent with the images are much more likely to
influence the frequency with which the browser sees the need to
query the server for updates. From what I am reading I suspect that
never knew what those headers were (and possible never knew they
existed).

Then tell me, does javascript read out the image's HTTP headers
in order to decide when it should flush the (preloaded) image ?
I would be surprised if that were true.

Javascript has no role in the decision as to whether an image is cached,
used from the cache or re-loaded from the server. The browser makes that
decision, but it certainly is considerably influenced in that decision which
headers are sent with an image (or with the image last time it as requested,
or instead of the image (in the case of a response to a 'If-Modified-Since"
request where the server sees no update)).

Working with such stuff seems very browser dependent
and very dangerous to rely on.

However something is "worked with", a starting position of understanding
what HTTP provided for use in relation to caching would be of considerably
value in determining how any browser may act outside of the specified
behaviour (or fill in any 'gaps').

But yes, there is technically no problem at
server side.

>>Since I added the META-tags, the images were cached
correctly and were always shown immediately.

So you observed a coincidence, but never established a
cause and effect relationship.

That is true up to a certain point.

You either establish a cause and effect relationship or you don't. There is
no "up to a certain point" in that.

I tested my solution thoroughly and I concluded that it
worked okay (which it still does until today, btw).

If your 'solution' was a coincidence (and the theory says it will have been
as there is no reason to expect the cachability of an HTML page (assuming
that the HTTP-EQUIVE META elements on the page will effect its cachablity
(though they can do no more)) would influence the caching behaviour of image
resources that are referenced from the page) but was in itself harmless then
its repeated use ("tested ... thoroughly") would demonstrate nothing.

I'm not sure how things work from your Sedes Sapientiae,
but I have less-than-perfect expierences as well.

Is that another bogeyman named "less-than-perfect expierences"?

>>For me that was reason enough to start using them ever
since for this kind of image preloading.

That is "programmin g by coincidence", and so not something
you should be recommending to others. Most of the META tag
cargo-cults have started that way (all praise the mighty
HTTP-EQUIV; "META, META, Meta, meta, ...".)

It's not programming by coincidence,

Demonstrate the cause and effect relationships and it may not be. But it
looks to me as if you never even considered many of the factors that would
be expected to influence the situation.

but a practical solution to a concrete problem.

You do not even know for certain that it influenced the situation you
described, let alone that it 'solved' anything. The most you are able to say
it that it was not harmful.

Richard.