Annoying HTML border problem

[VectraMan]

That's another reason I don't use jquery, depends what you're used to I suppose but the syntax of plain jscript seems a lot simpler to someone already used to C, C++ and Java. Jquery just seems to turn it into a different language for no obvious reason.

I agree. Plus I don't know how much this is true, but looking something up by string name just seems like it should be horribly inefficient to me.

And is there a good reason for not just doing:

info.style.visibility = "visible";

?

[jmo21]

It's abstracting things... for all you know on one browser it maps directly to setting a property but on another to a whole wodge of nasty DOM/JS.

I'd echo that it's worth getting to grips with if you're not an expert HTML/CSS guy to start with (which seems not to be the case) as it will save you time down the line. Plus it's good to have on your CV

It's worth it for the cross browser compatability alone.

Thought it was ubiquitous amongst web devs now.

[fullyautomatix]

On its own your code works okay in my browser(s) but its maybe some other CSS that is interfering. Can you paste in any other CSS files you include ?

Also, agree with others that unobtrusive javascript is the best way to tackle this kind of event based dom manipulation.

[NickFitz]

Sounds like a typical IE rendering failure. One thing that might give it a nudge and get it working is to use

// assume reference to your toggley thing is in variable "thing"
// as for example would be the result of
// var thing = document.getElementById("toggley_thing");

thing.className = thing.className;

or, if that doesn't work, try

thing.parentNode.className = thing.parentNode.className;

Sometimes IE seems to mess up calculating which bits of the document need repainting. Luckily, the developers never optimised for the case of a className assignment resulting in no change from the previous value, and as a changing className could cause all kinds of layout changes, IE proceeds to recalculate and repaint the element and its descendants, and anything else that's affected as a result.

It ought to do this for the visibility change anyway, but obviously it isn't in this case, so this just nudges it to have another try.

Also, sometimes it just gets it wrong again, but gets it right if the redraw starts at the parent of the problem object, or maybe at some containing element further up the tree; but start as far in as you can and only work out if you have to, as it has a deleterious effect on performance generally.

(Performance considerations might not seem so important nowadays, but as your stuff is for the educational market it's worth bearing in mind that schools and such often have rather crappy old machines that were built to cheap specs in the first place, so anything that helps avoid the risk of flickering redraws is a Good Thing.)

[xoggoth]

Cheers again Nick. I think my just changing the size a pixel has done the nudge it needed in this case but that's useful for further problems and has been added to my ever growing list of quirky things.