Easy JavaScript/Cookie Question

[unremarkable]

I want to display a DIV until the visitor clicks on one of the links in it. This is across sessions. So, I am trying to get a cookie to remember when one of the links has been clicked on, and from then on, to set the visibility of the DIV to 'hidden'. But, I really have no clue how to go about this...

Can anyone help?

Thanks!

un

[StupidScript]

Here ya go ...

<script type="text/javascript">
function setDivCookie() {
document.cookie="hidediv";
}
function checkDivCookie() {
if (document.cookie.indexOf("hidediv")!=-1) {
document.getElementById("linkdiv").style.visibility="hidden";
}
}
</script>
...
<div id="linkdiv" style="visibility:visible">
<a href="..." onclick="setDivCookie()">Link 1</a>
<a href="..." onclick="setDivCookie()">Link 2</a>
...
</div>
...
<script type="text/javascript">
checkDivCookie();
</script>

I tend to stay away from using the "onload" event to manipulate document objects, like a DIV element, as it has been unreliable. Often the onload event will fire before the page is truly loaded, and the object I want to manipulate hasn't been fully initialized, and an error results. Therefore I tend to place the function call at the end of the page code, near </body>, because once that enters the browser's memory, the previous code has definitely been initialized.

[penders]

I tend to stay away from using the "onload" event to manipulate document objects, like a DIV element, as it has been unreliable. Often the onload event will fire before the page is truly loaded....

Really?! Certain browsers? I have always thought the onload event to be the prefered method (can't say I've had a problem in the past)...?

Therefore I tend to place the function call at the end of the page code...

Is this more 'reliable'?! But this doesn't go all the way to separating your JS behaviours from your content, and besides, to have to add extra function calls at the end of the markup is an increased overhead to say the least, particulary if you are adding functionality to many pages. Just curious... :)

[unremarkable]

That's absolutely brilliant, StupidScript, thank you!

Wish I could do that...

I did manage to add an expiry to it so it extends across sessions by myself, but that's the limit of my JS talents!

If you have a minute, could you give a small explanation of what it does? In particular the "if (document.cookie.indexOf("hidediv")!=-1)" bit...

[StupidScript]

function setDivCookie() {
// Add "hidedev" to the cookie's string
// Creates a new cookie if it doesn't already exist
document.cookie="hidediv";
}
function checkDivCookie() {
// Does the cookie string contain "hidedev"?
// Basically, does the statement NOT evaluate to "false"
// "true" can be any positive integer, so it's best to test for "not-false"
// "false" can be either 0 or -1
// If it's 0, then document.cookie.indexOf("hidediv") is
// not available for comparison, and so returns "false" (-1)
if (document.cookie.indexOf("hidediv")!=-1) {
document.getElementById("linkdiv").style.visibility="hidden";
}
}

Really?! Certain browsers? I have always thought the onload event to be the prefered method (can't say I've had a problem in the past)...?

You're right, it is the preferred method, but I have had problems in the past that are solved by a page refresh, but that's not really fixing it. I'm not sure why the onload event sometimes fires "prematurely", but I simply can't count on it when I am trying to manipulate document objects. I do use it when I can setTimeout for something, but not for a hide/show-type of action that applies to a "live" object, as in this case.

Is this more 'reliable'?!

Absolutely ... the code at the bottom of the page is read in after the code toward the top of the page and doesn't rely on whether the browser has received an onload event trigger.

But this doesn't go all the way to separating your JS behaviours from your content

True enough ... the dream continues with reality's thumb in its eye ... ;)

to have to add extra function calls at the end of the markup is an increased overhead to say the least

I'm not sure where this comes into play. Using the method I posted, the script is called as the code is being read into the browser. Using an onload event calls the script at approzimately the same time, although other factors can determine its exact execution time. One way or the other, the script gets called. I don't see that there is any increase in overhead.

[penders]

...an increased overhead...

I actually meant in development time (as opposed to runtime), since you might link the JS file in the <head> section (possibly with a server-side script), but would have to add a call at the end of the body as well - just thinking if you were including the script in many files.

Thanks for the response - I see what you're saying, in fact I may have come across 'this problem' recently and not appreciated it. I noticed a text/image replacement script, called from the window.onload event very 'occasionally' didn't do its thing - a refresh would sort it and could never reproduce it, but must have a closer look!

Sorry, digressed a tad from the original Cookie query...

[StupidScript]

penders, you have just outlined why using common footers is a good idea. I usually include as many common elements as I can, and if I were to be using a script similar to the above, I would definitely place the script call into the footer file that is being included, obviating the need to rework the individual pages.

[penders]

...using common footers is a good idea.

Hhhmmm, of course, very true! :)