Changing styles and having them "stick"

[twp144]

Hi,

I have some javascript to change the style class of various <td>s when you right click on them. Now when I click on a link to another page, then click the "Back" button, it seems that all but the last changed <td> revert to the styles they had when the page was loaded.

This is an Intranet app, so I'm targeting IE 6. I'm using

parent.document.getElementById(tdId).className = style;

where tdId is some element id and style is the new style. Again, I can change the styles of say 5 of them, click on a link to go to another page, and when I click the "Back" button, 4 out of the 5 (all but the most recently changed one) will revert to their original styles.

Is there a way to have them all remember that they got changed?

Thanks.

[rocknbil]

haha. Went through this just the other day with a particularly difficult customer that insists on swimming against the stream, except my problem was remembering which layers were last visible.

Whatever initialization that occurs when you load the page resets your styles (or in my case, visible layer) to the initial state when you return. I resolved it by setting a document cookie so that when you return to that page, the Javascript reads the cookie and if it is present and has a value, uses the cookie value to set the currently visible one (or in your case, selected style.) If the cookie is not present or has a null value, then go ahead and use the default.

[Rambo Tribble]

A backdoor approach that avoids cookies is to store a string as the window.name. Window.name is a read/write string that most pages never touch, except in the case of popups. To be compatible with NN4, avoid spaces or punctuation in the string.

[twp144]

Wow I didn't think I would get useful help so quickly. I will try it out and let you know how it works. Thanks!

[ricfink]

I've found that when a problem like this pops up it usually helps to look at the overall approach that's being taken. In other words, address the problem at the step BEFORE the step where the problem rears it's head.

Do you have to use the element's class to effect the change? Can't it be an inline style using the style object.

I realize rethinking this might take some time but it might be a lot less work in the long run.

Let us know how you resolved this.

[twp144]

ricfink,

I have a calendar of "events" that get read from the database. Each event is a <td> element. I would like the user to be able to "cancel" events by right-clicking the <td> element. The right-click is targeted at an <iframe> to do the database update, then it goes and changes the style of the <td> to give feedback that the cancel has taken place. I don't want to reload the entire page after each cancel because that would be too slow in case someone wanted to cancel a lot of things in succession.

In response to your question about the inline style, I'm not sure I understand your point. I'm using <td class="someClass"> to set the initial style. Would using the style property somehow alleviate this problem?

[ricfink]

I'm trying to get the general idea of what you're doing.
Are you using a hidden iframe to act as an "agent" to reach out to the database?
(Also, I'm curious - why a right-click? And how does the user know to do that?)
And what visual styles are you changing? the color or what?

Anyway - CSS uses a certain internal logic to resolve conflicting styles. In short, some rules are more powerful than others.
For instance, setting an inline style like this:

<div class="redfont" style="color:blue;">TEXT</div>

will override setting it by class in the style sheet like this:

.redfont {color:red;}

The color of the word TEXT will be blue.

The javascript equivalent of setting the style inline is, as in your original example:

parent.document.getElementById(tdId).style.color = "red";
Then it will definitely be red no matter how the className has changed.

Now, I don't know if it will prove to be any more "sticky" than changing the className but my instincts tell me there's gotta be an answer to this some way, somehow without resorting to too much hackery.

[twp144]

Sorry, but I wasn't too clear in describing my scenario. Yes, I am changing the visual style of the <td> elements. How the user knows to right-click is orthogonal to this problem I believe, so I won't go into it.

I'm using the class to specify the background color of the <td> element. If the event is active, it has one class, otherwise it has the cancelled class. The hidden iframe does hit the database, and changes the class of the event accordingly. This part I think I have working fine.

The problem is that I will perform a series of these changes of classNames, visit another page, click the "Back" button, the classes will revert back to the classes they had when the page was first loaded.

If the page starts out:
[red class][red class][red class][red class]

and I dynamically change the first, second, and last (in that order):
[blue class][blue class][red class][blue class]

I will visit another page, then click the "Back" button and the page will appear
[red class][red class][red class][blue class]

which is not how I left the page. This is what I meant by "stick". It seems to remember the last change but not anything before that. I hope that clarifies my problem.

Thanks.

[ricfink]

Not orthogonally, I'm going to try to duplicate the problem you're describing.
I wanna see it.

[ricfink]

OK twp, I see it. And I am working under the assumption that the iframe is reaching out to the server to make the changes to the database and then, when the request returns it changes the background color in the parent document. One td element at a time.

Some way has to be found to make the page in the iframe "remember" all of the td elements it has changed in the parent document. This could be done on the server side or you could go for a cookie that updates itself every time a change is made created by the page in the iframe.

However, I think you may be asking for trouble by allowing the user to make changes, drift away to other pages, and then come back. I mean, by then, the "session" for making these changes is over, right?
Better to expire the page and make a fresh call to the server I think.

Hope this helps narrow the problem down.

[Rambo Tribble]

Here's a simple example using the window.name to hold the string for setting the values. Note that this is just an example and is inadequate to rely on in the event another site modifies the window.name (few sites do, though the Economist would be an example of one that does).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Untitled</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<style type="text/css">
div{height:200px;width:300px;}
.rd{background:red;}
.bl{background:blue;}
.gr{background:green;}
</style>
<script type="text/javascript">
function setCls(){
if(window.name!=""&&window.name.indexOf("_x_")!=-1){
var div_cls=window.name.split("_z_");
var div_cls_ln=div_cls.length;
for(var i=0;i<div_cls_ln;i++){
if(div_cls[i].indexOf("_x_")!=-1){
var set_ea=div_cls[i].split("_x_");
document.getElementById(set_ea[0]).className=set_ea[1];
}
}
}
}

function chgCls(div_id,new_cls){
document.getElementById(div_id).className=new_cls;
window.name+=div_id+"_x_"+new_cls+"_z_";
alert(window.name);
}
</script>
</head>
<body onload="setCls();">
<div id="divOne" class="rd" onclick="chgCls('divOne','bl');"></div>
<div id="divTwo" class="bl" onclick="chgCls('divTwo','gr');"></div>
<div id="divThree" class="gr" onclick="chgCls('divThree','rd');"></div>
</body>
</html>

[twp144]

ricfink,

I think you're asking for details that don't matter. The iframe shouldn't need to remember anything, because someone not using an iframe would probably have the same problem. What if I had just pure javascript and I wanted the right click to change the classes as I described?

And I'm asking for trouble somehow? I think a user should be able to make changes, go somewhere else, come back, and have the changes be maintained.

[twp144]

Rambo Tribble,

Thanks very much for the example that actually works. I'm not sure if I want to use the window.name, but it does appear to fix what I'm describing.

[Rambo Tribble]

Glad to be of assistance. I'm not really advocating using window.name, but it might be useful if the user is blocking cookies. Basically, a cookie would work the same way, though you would have a bit more overhead and you might have to be more careful about clearing the cookie values if new settings were chosen, depending on the persistence you choose for the cookie.

[ricfink]

twp:

"And I'm asking for trouble somehow? I think a user should be able to make changes, go somewhere else, come back, and have the changes be maintained."

Please don't blame me. This all has to do with the basic nature of http. You can complain about it all you want but you're not going to get data of any kind to persist when the user leaves the page without either writing a cookie or making a fresh call to the server. This problem was why Netscape came up with cookies to begin with.

I wish there was an easier way.

Other than that, live and learn, 'cause I didn't know window.name could be used to house data and have it persist.

[jbot]

window.name and any other custom OOP solution are only good as replacements for session only cookies. there is no persistence alternative to cookies, sessions, or serverside logs of some or other sort.