Thomas said:
document.layers is IIRC an Array object. The object itself
has no visibility property, so I do not understand why you
are including it here. It would be more reasonable to try to
access the id-th layer or not supporting the NN4 DOM at all.
Given that line in the context of the rest of the code, I think it's fairly
obvious my intent was "document.layers[id]" rather then "document.layers". A
more appropriate response might have been: "you probably meant
'document.layers[id]'". A correction of my mistake to the original poster
was necessary, a 4-line explanation on what I did wrong given the context of
the rest of the code was not.
Of course, if your intent was to be intentionally obtuse ("... I do not
understand why you are including it here.") then I guess you succeeded.
} else if (document.all) {
o = document.all[id].style;
While the IE DOM has an ambiguity that methods of host objects
can be used as collections (and vice-versa), the documentation
at MSDN uses the method syntax and this is why I think one
should stick to that.
It's a collection, it gets accessed using the collection syntax. MSDN
documentation indicates that document.forms(), .links(), .elements(), etc
should also use the method syntax, but I certainly don't use:
<!--[if IE]>
<script type="text/javascript">
var el = document.forms('theForm').elements('theElement');
</script>
<![endif]-->
<![if !IE]>
<script type="text/javascript">
var el = document.forms['theForm'].elements['theElement'];
</script>
<![endif]>
everywhere I access a form element[] or link[].
This was my first approach for dhtml.js, too. Yet testing the DOM every
time the method is called is not very efficient. Try this instead:
Which is why I wrote: "This script still isn't optimum because it tests
which DOM is supported for each call. The performance difference probably
won't matter in most cases."
I did not want to confuse the issue by combining more advanced concepts with
the concept of feature detection.
else if (document.layers)
{
function getElemById(id)
{
return document.layers[id];
}
}
In my environment Netscape 4 is more likely to be in use than Internet
Explorer 4, so I move the document.layers test up simply to document it's
relative importance. Also, I'd probably add the following catch-all else:
else {
function getElemById(id) { return null; }
}
function hideObject(id)
{
var o = getElemById(id);
if (o)
{
(typeof o.style != "undefined")
? o.style.visibility = "hidden";
: o.visibility = "hidden";
}
}
Depending on requirements, I might code it as:
function setVisibility(id, visible) {
var o = getElemById(o);
if (o) {
if (typeof o.style != 'undefined') {
o.style.visibility = (visible ? 'visible' : 'hidden');
return (o.style.visibility == (visible ? 'visible' : 'hidden'));
} else {
o.visibility = (visible ? 'show' : 'hide');
return (o.visibility == (visible ? 'show' : 'hide'));
}
}
return false;
}
I completely acknowledge the above code is not perfect. It is certainly
possible to get false positives, where the visibility (or other) property is
confirmed as being set on the object but nothing happened in the browser
(Opera 6 and innerHTML are a good example of this). It is possible (but I
feel less likely) to get false negatives. If the visibility property is not
the value you set it to, then either the DOM performed the requested action
and somehow "reset" the value, or the value simply did not get set. Despite
the obvious unreliability of returning a boolean from such a function, I
still think there are circumstances where knowing that setVisibility()
couldn't locate or change the visibility on the specified element can be of
value.
Signatures are by convention (RFC) to be delimited by DashDashSpace
(`-- '), so compliant NetNews software (like mine) can handle them
differently (removing them automatically on reply, coloring them to
distinguish them from the rest of the article, hide them if display
is undesired etc.)
<
http://insideoe.tomsterdam.com/problems/bugs.htm#sigseparator>
explains how to achieve that with Outlook Express which will otherwise
truncate trailing spaces on submit no matter how many you type when
composing the mail/article.
PointedEars
Thank you for the link, but I don't use Outlook Express so that article does
not help. I guess you'll just have to mentally filter out the three lines of
my sig.
