By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,567 Members | 1,056 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,567 IT Pros & Developers. It's quick & easy.

Netscape compatibility

P: n/a
Hi,

I need help : I found the simplest and most precise way to open and close
submenu layers. it works perfectly with IE, but for some odd reason NS won't
recognize it.

Can anyone tell me why ?

And is there a way around the problem ?

I really like the elegance of this code and would like to keep using it.

Thanks in advance.
Roger Desparois
<head
<script language="Javascript"`>
<!--
function Pop(name){
eval("document.all."+name+".style.visibility='visi ble'");
}
function Wop(name){
eval("document.all."+name+".style.visibility='hidd en'");
}

//-->
</script>
</head>

<body>
<div id="prod"
Style="background-color:#ff0000;Position:Absolute;Left:39px;Top:89px ;Width:1
78px;Height:16px;Visibility:visible;z-index:31" onmouseover="Pop('smprod')"
onmouseout="Wop('smprod')">
<table width="178" height="16" border="0" cellspacing="0" cellpadding="0"
class="menu">
<tr>
<td align="center" valign="middle">Volleyball</td>
</tr>
</table>
</div>

<div id="smprod"
Style="background-color:#ff0000;text-align:right;Position:Absolute;Left:39px
;Top:105px;Width:178px;Visibility:hidden;z-index:32"
onmouseout="Wop('smprod')" onmouseover="Pop('smprod')">
<table width="178" border="0" cellspacing="0" cellpadding="0" class="menu">
<tr>
<td><img src="../images/espace1px.gif" width="178" height="5"></td>
</tr>
<tr>
<td align="center" valign="top">
<a href="../volleyball/en-ballons.html">Balls</a><br>
<a href="../volleyball/en-souliers.html">Shoes</a><br>
<a href="../volleyball/en-genouillere.html">Kneepads</a><br>
<a href="../volleyball/en-chevillere.html">Ankle braces</a><br>
<a href="../volleyball/en-filets.html">Nets</a><br>
<a href="../volleyball/en-accessoires.html">Accessories</a></td>
</tr>
<tr>
<td><img src="../images/espace1px.gif" width="178" height="5"></td>
</tr>
</table>
</div>
</body
Jul 23 '05 #1
Share this Question
Share on Google+
26 Replies


P: n/a
VK
Leaving out the question of the code elegance... I feel you came here for a
quick-n-dirty solution and not for a JavaScript lessons:

<script language="Javascript"`>
<!--
function Pop(name){
document.getElementById(name).style.visibility='vi sible';
}

function Wop(name){
document.getElementById(name).style.visibility='hi dden';
}
//-->
</script>

WHY??
Because document.all is an Explorer's proprietary collection, other browsers
do not support it.

LATER MAY LOOK HERE:
http://www.dynamicdrive.com/dynamicindex1/index.html
(of course there are many similar places with even better code)


Jul 23 '05 #2

P: n/a

"VK" <sc**********@yahoo.com> wrote in message news:41*********************@news.freenet.de...
Leaving out the question of the code elegance... I feel you came here for a
quick-n-dirty solution and not for a JavaScript lessons:

<script language="Javascript"`>
<!--
function Pop(name){
document.getElementById(name).style.visibility='vi sible';
}

function Wop(name){
document.getElementById(name).style.visibility='hi dden';
}
//-->
</script>

WHY??
Because document.all is an Explorer's proprietary collection, other browsers
do not support it.

LATER MAY LOOK HERE:
http://www.dynamicdrive.com/dynamicindex1/index.html
(of course there are many similar places with even better code)





Yes. documemt.all is IE. Here's a test for Netscape 6 and above I believe:

ns6 = (!document.all && document.getElementById);
//ns6 = true if Netscape 6+

Netscape 4 is this:

ns4 = (document.layers);
//ns4 = true if Netscape 4

ie4 = (document.all && !document.getElementById);
// ie4 = true Internet Explorer 4

ie5 = (document.all && document.getElementById);
// ie5 = true Internat Explorer 5 and up

I'm not sure how to integrate Firefox and Opera in this scheme.

Finally yes the scripting is fine for IE. You might consider fixing the CSS. Attributes are all lower case.
Also the relative ../images may be able to change to /images. The trouble is that in new Microsoft web
servers they have disabled relative adddressing without overhauling the new security relative addressing will no
longer work.

George Hester
__________________________________

Jul 23 '05 #3

P: n/a
On Sat, 09 Oct 2004 15:23:19 GMT, George Hester <he********@hotmail.com>
wrote:

[snip]
Yes. documemt.all is IE.
Opera also supports it, and I believe ICEBrowser does, too.

[snip]
ns6 = (!document.all && document.getElementById);
//ns6 = true if Netscape 6+

Netscape 4 is this:

ns4 = (document.layers);
//ns4 = true if Netscape 4

ie4 = (document.all && !document.getElementById);
// ie4 = true Internet Explorer 4

ie5 = (document.all && document.getElementById);
// ie5 = true Internat Explorer 5 and up
Browser detection, whether by interpretation of the user agent string, or
object inference, is fundamentally flawed. You don't *need* to know what
browser you're using, just what it's capable of doing.

Obviously you haven't read FAQ entry, 4.26.
I'm not sure how to integrate Firefox and Opera in this scheme.
You don't.

[snip]
The trouble is that in new Microsoft web servers they have disabled
relative adddressing without overhauling the new security relative
addressing will no longer work.


I'm glad I use Apache.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #4

P: n/a
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message news:opsfl0sgpwx13kvk@atlantis...
On Sat, 09 Oct 2004 15:23:19 GMT, George Hester <he********@hotmail.com> Obviously you haven't read FAQ entry, 4.26.

Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.


If you gave a link to the FAQ article you mention I would read it.
Actually this came from soneone else on the Internet it is not mine. In any case how is it flawed?
But of course if the article you mention answers that then that is what I would be looking for. Thanks.

George Hester
__________________________________
Jul 23 '05 #5

P: n/a
Lee
George Hester said:

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message =
news:opsfl0sgpwx13kvk@atlantis...
On Sat, 09 Oct 2004 15:23:19 GMT, George Hester =

<he********@hotmail.com> =20
Obviously you haven't read FAQ entry, 4.26.
=20
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.


If you gave a link to the FAQ article you mention I would read it.
Actually this came from soneone else on the Internet it is not mine. In =
any case how is it flawed?
But of course if the article you mention answers that then that is what =
I would be looking for. Thanks.


You've been reading this newsgroup for an awfully long time
to not know where to find the FAQ:

http://www.jibbering.com/faq/

Jul 23 '05 #6

P: n/a
On Sat, 09 Oct 2004 15:54:24 GMT, George Hester <he********@hotmail.com>
wrote:
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:opsfl0sgpwx13kvk@atlantis..
[snip]
Obviously you haven't read FAQ entry, 4.26.


[snip]
If you gave a link to the FAQ article you mention I would read it.
The FAQ, and links to it, are posted three times a week. It exists in the
signatures of several regular posters, and is mentioned plenty of times in
responses to posts.

You've posted to this group longer than I have. I shouldn't need to tell
you where to find the article.
Actually this came from soneone else on the Internet it is not mine.
So?
In any case how is it flawed?


It isn't reliable and can, in some instances, entirely fail to identify
the intended browser. Furthermore, scripts based on this technique often
fail to work, or take advantage of new features, in future browser
versions.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #7

P: n/a
"George Hester" <he********@hotmail.com> writes:
Yes. documemt.all is IE. Here's a test for Netscape 6 and above I believe:

ns6 = (!document.all && document.getElementById);
//ns6 = true if Netscape 6+
That also matches Opera 6 (unless identifying as IE) and Opera 5, and
possibly also Safari and Konqeror (unless they decided to support
document.all as well).
Netscape 4 is this:

ns4 = (document.layers);
//ns4 = true if Netscape 4
Also matches OmniWeb.
ie4 = (document.all && !document.getElementById);
// ie4 = true Internet Explorer 4
Also matches WebTV.
ie5 = (document.all && document.getElementById);
// ie5 = true Internat Explorer 5 and up
Also matches Opera 7, and Opera 6 when identifying as IE.
I'm not sure how to integrate Firefox and Opera in this scheme.


FireFox is based on the Mozilla project, just as the Mozilla Browser
Suite and Netscape 6+. They act identically.

Opera 7 is not distinguishable from IE 6 using only document.all and
document.getElementById.
Since there are many different browsers, and always more than an
author expects, trying to recognize specific browsers is rarely
a good idea. Because some people have tried doing it anyway, and
have made pages that refuse to show themselves to some browsers,
the users of those browsers frequently make their browser detect
as another one, making detection even more impossible.

If the existence of document.all/document.getElementById is releveant,
because script is going to use those specific properties, then it
makes sense to test for their presence. In that case, it doesn't
matter what browser it is anyway.

<URL:http://jibbering.com/faq/#FAQ4_26>

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #8

P: n/a

"Lee" <RE**************@cox.net> wrote in message news:ck********@drn.newsguy.com...
George Hester said:

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message =
news:opsfl0sgpwx13kvk@atlantis...
On Sat, 09 Oct 2004 15:23:19 GMT, George Hester =

<he********@hotmail.com> =20
Obviously you haven't read FAQ entry, 4.26.
=20
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.


If you gave a link to the FAQ article you mention I would read it.
Actually this came from soneone else on the Internet it is not mine. In =
any case how is it flawed?
But of course if the article you mention answers that then that is what =
I would be looking for. Thanks.


You've been reading this newsgroup for an awfully long time
to not know where to find the FAQ:

http://www.jibbering.com/faq/


well here we go. I went to the link and looked under 4.26: Here was their example that I assume is the way it is supposed to be done:

if (document.getElementById &&
document.getElementById('el') &&
document.getElementById('el').style ) {
// We know that this browser supports getElementByID and has
// a style object, so we can set a style property.
document.getElementById('el').style.color="red";
}

That looks pretty familiar.

I didn't see anything about fundamentally flawed of what I presented earlier. Oh well thanks for the liink.

--
George Hester
__________________________________
Jul 23 '05 #9

P: n/a
On Sat, 09 Oct 2004 16:28:33 GMT, George Hester <he********@hotmail.com>
wrote:

[snip]
well here we go. I went to the link and looked under 4.26: Here was
their example that I assume is the way it is supposed to be done:
It's a way. It could be made more efficient by saving the references
obtained rather than repeated look-up.
if (document.getElementById &&
document.getElementById('el') &&
document.getElementById('el').style ) {
// We know that this browser supports getElementByID and has
// a style object, so we can set a style property.
document.getElementById('el').style.color="red";
}

That looks pretty familiar.
When compared to what?
I didn't see anything about fundamentally flawed of what I presented
earlier. Oh well thanks for the liink.


Hmmm.

I take it you didn't read the linked pages in that entry.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #10

P: n/a

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message news:opsfl2gwhnx13kvk@atlantis...
On Sat, 09 Oct 2004 15:54:24 GMT, George Hester <he********@hotmail.com>
wrote:
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:opsfl0sgpwx13kvk@atlantis..


[snip]
Obviously you haven't read FAQ entry, 4.26.


[snip]
If you gave a link to the FAQ article you mention I would read it.


The FAQ, and links to it, are posted three times a week. It exists in the
signatures of several regular posters, and is mentioned plenty of times in
responses to posts.

You've posted to this group longer than I have. I shouldn't need to tell
you where to find the article.
Actually this came from soneone else on the Internet it is not mine.


So?
In any case how is it flawed?


It isn't reliable and can, in some instances, entirely fail to identify
the intended browser. Furthermore, scripts based on this technique often
fail to work, or take advantage of new features, in future browser
versions.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.


I'm sorry Mike. I don't usually click on links unless I have an ovrriding need to. If it is to see what someone asks a question about or it may have information that I am interested in at the moment then I do. Otherwise not usually. That's just me which of course I have every right to be.

Not reliable seems weird. Not reliable means that sometimes ie5 will be false and sometimes true based on the direction the wind is blowing using IE5. That's a weird interpreter.

Take advantage of new features. Yes that true. But then IE 5, IE 6 NN4 NN6 ain't gonna get any newer as far as I know. So those variables I provided should always give the same vaues based on the use of those browsers. If they are not reliable then it is not an issue with the code it is an issue with the interpreter used in those browser. I didn't know that was a possibility. Thanks for pointing that out.

George Hester
__________________________________
Jul 23 '05 #11

P: n/a

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message news:opsfl25pvjx13kvk@atlantis...
On Sat, 09 Oct 2004 16:28:33 GMT, George Hester <he********@hotmail.com>
wrote:

[snip]
well here we go. I went to the link and looked under 4.26: Here was
their example that I assume is the way it is supposed to be done:


It's a way. It could be made more efficient by saving the references
obtained rather than repeated look-up.
if (document.getElementById &&
document.getElementById('el') &&
document.getElementById('el').style ) {
// We know that this browser supports getElementByID and has
// a style object, so we can set a style property.
document.getElementById('el').style.color="red";
}

That looks pretty familiar.


When compared to what?
I didn't see anything about fundamentally flawed of what I presented
earlier. Oh well thanks for the liink.


Hmmm.

I take it you didn't read the linked pages in that entry.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.


No as I explained earlier. I'm just that much of a clicker on the Net. The reason being
I have been burned too often. I'm sure the additional links are safe. But you must understand
that I use a Server with basically no security and signed on as Administrator. So I have to be very careful
what I do. I can operate this way have been for a very long time. I take no risks and I know where trouble lies
usually before it happens. Sometimes I fail but that hasn't happend since msblaster and even that was
innocuous for me. Did have trouble with coolwebsearch but I got that one licked too.

Oh the browser variables are in a js file called in the header. So they are never accessed but once when the
page loads.

George Hester
__________________________________
Jul 23 '05 #12

P: n/a
On Sat, 09 Oct 2004 17:06:19 GMT, George Hester wrote:
I'm just that much of a clicker on the Net. The reason being
I have been burned too often.


You should try surfing with a browser, rather than
your OS component. Much safer.

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane
Jul 23 '05 #13

P: n/a
Roger Desparois wrote:
I need help : I found the simplest and most precise
way to open and close submenu layers.
Simplicity is at least partly a matter of perception. One line of code
might seem to qualify but when that line of code combines a number of
actions, and eliminates much sensible checking and verification, the
simplicity is only really in its appearance.
it works perfectly with IE, but for some odd
reason NS won't recognize it.
It is not that odd a reason. Any code that employs a Microsoft
proprietary feature should be expected to fail on a non-Microsoft
browsers (and often on non-default configurations, or non-Windows, IE).
Can anyone tell me why ?
The quick answer is the use of - document.all - as Netscape/Gecko
browsers have traditionally not implemented it (the most recent Mozilla
versions are implementing it as a concession to ancient code written in
the "both browsers" days without sensible feature detection. It seems
unlikely that a gecko browser with 'Netscape' in its name will be
released based upon the latest Mozilla code).
And is there a way around the problem ?
The simple act of showing/hiding a DOM element with CSS is achievable on
all dynamic, and many less-dynamic, browsers. Including some relatively
ancient browsers like Netscape 4, if the element in question is assigned
a CSS potion value of 'absolute' or 'relative', for the effort of adding
some extra lines of code.
I really like the elegance of this code and would like to
keep using it.
It is a hack.

<snip> <head ^
A closing '>' might be a good idea here.
<script language="Javascript"`>
Script elements are required to include the TYPE attribute in HTML 4.
The language attribute is deprecated and becomes redundant when a TYPE
attribute is included:-

<script type="text/javascript">
<!--
These HTML comment-like sequences are unnecessary in current browser
scripting as they were introduced to address issues with browser that
have not been in use for some considerable time.
function Pop(name){
eval("document.all."+name+".style.visibility='visi ble'");
}


This is what you are describing as simplicity:-

1. Construct a string representing javascript source code.
2. Have that executed as a javascript program in a new eval
execution context. Starting a javascript interpreter,
have it interpret and execute the program and return the
result. A process consisting of:-
A. Resolve - document - against the scope chain and
retrieve a reference to that object (assuming it
exists, probably a safe assumption as - document -
is universal in HTML web browsers).
B. Resolve - all - as a named property of that object
and retrieve a reference to that object (it doesn't
exist in Netscape browsers so the value retrieved
in - undefined - not an object reference).
C. Resolve - style - as a named property of that object
(Netscape errors here as - all - was not an object) and
retrieve a reference to that object (assuming it exists).
D. Assign a string value to the - visibility - property of
that object.

The use of the - eval - contributes nothing to simplicity here, in the
source code or the execution of the code. It follows from nothing but
the author's ignorance of javascript as a language as it is being use to
dynamically insert one identifier in a dot notation property accessor.
Javascript has always offered the bracket notation property accessor as
a means of referencing objects using string value valuables (and
expressions) in place of identifiers. Simply using the bracket notation
in place of eval produces:-

document.all[ name ].style.visibility='visible';

(a much simpler line of code (and much simplified execution), though
equally error prone).

With the exception of the - document - reference (and some would include
that), everywhere that an assumption is made above a test to verify that
assumption is indicated. Simplicity achieved by omitting those tests is
not valuable simplicity.

Adding an implementation of the minimum testing might produced code
like:-

function Pop(name){
var el;
/* Only attempt to use the - document.all -
collection if it exists on this browser:-
*/
if(document.all){
el = document.all[ name ];
}
/* Verify that the DOM element retrieval happened
and returned a valid/usable object reference.
And then verify that the object reference has
a style property:-
*/
if(el && el.style){
/* It should be safe (non-error producing) to
assign a value to 'visibility' the el.style
object (whether the browser assigned meaning
to that action is another question):-
*/
el.style.visibility='visible';
}
}

Which has lost some of its original simplicity but will now not
error-out.

It still will not work with Netscape browsers as they do not implement -
document.all -. To get round that an alternative element retrieval
mechanism must be used. W3C Core DOM standard browsers provide a -
document.getElementById - method that is designed to retrieve a
reference to an element with a (unique) ID attribute that corresponds
with the string argument provided to the method call. These browsers
include IE 5.0+ and Netscape 6+ (and many others). This method is the
preferred method of retrieving such element references is it is most
wildly supported, - document.all - is now only a fall-back alternative
for ancient browser like IE 4 (and one or two others that are not going
to provide the - style - object anyway).

Again it is necessary to verify that the browser facilitates -
document.getElementByyId -, but if it does not - document.all - can be
tried as a fall back (alternative fall-back mechanisms can be used for
Netscape 4 under some circumstances). The modified code becomes:-

function Pop(name){
var el;
/* Only attempt to use the - document.getElementById -
if it exists on this browser:-
*/
if(document.getElementById){
el = document.getElementByI( name );

}else if(document.all){ // else try - document.all -:-
el = document.all[ name ];
}
/* Verify that the DOM element retrieval happened
and returned a valid/usable object reference.
And then verify that the object reference has
a style property:-
*/
if(el && el.style){
/* It should be safe (non-error producing) to
assign a value to 'visibility' the el.style
object (whether the browser assigned meaning
to that action is another question):-
*/
el.style.visibility='visible';
}
}

The fact that the branching element retrieval mechanism is needed in
both functions, and is more involved than the original anyway, makes
this look considerably less simple. That follows from a failure to
recognise the real steps in this process. The first step in both the
setting of the property to 'visible' or ' hidden' is the retrieval of
the reference to the DOM element. Both functions must use the same
mechanism (and potentially much other code would require the same
facility). This suggests that element retrieval would be better done by
one separate function.

The notes to the newsgroup FAQ cover various approaches to implementing
a single IDed element retrieval mechanism is some detail but a simple
(and non-optimum) implementation might go:-

fucntion getElementWithId(id){
if(document.getElementById){
return document.getElementById(id);
}else if(document.all){
return document.all[id];
}else{
return null; //no retrieval mechanism available
}
}

Reducing the original function to a simple:-

function Pop(name){
var el = getElementWithId(name);
/* Verify that the DOM element retrieval happened
and returned a valid/usable object reference.
And then verify that the object reference has
a style property:-
*/
if(el && el.style){
/* It should be safe (non-error producing) to
assign a value to 'visibility' the el.style
object (whether the browser assigned meaning
to that action is another question):-
*/
el.style.visibility='visible';
}
}

- and having a similar simplifying effect on the internal code of both
functions.

The next step in the process, the verification of and referencing of the
style object, is also common to both functions (and again potentially
useful elsewhere). It would be possible to re-use the element retrieval
function code and wrap the style object handling around it, but element
retrieval is such a generally common requirement in browser DOM
scripting that the element retrieval function is probably best left
available to all code and a style object retrieval function designed to
call it for its element references. So the style object retrieval
function could go:-

function getStyleObjWithId(id){
var el = getElementWithId(id);
return (el && el.style)||el;
}

Reducing the original function to:-

function Pop(name){
var st = getStyleObjWithId(name);
if(st){
st.visibility='visible';
}
}

- and its counterpart to:-

function Wop(name){
var st = getStyleObjWithId(name);
if(st){
st.visibility = 'hidden';
}
}

Which, while not as simple as one line of code, are relatively simple
and clear, will work on DOM standard browsers in addition to IE and will
not error-out on any browsers. (in addition, active support for
dinosaurs like Netscape 4, when such is possible, is now just a matter
of using a more involved element retrieval function (as can be found in
the FAQ notes) as everything down-stream of that is already in place and
cross-browser).

Richard.
Jul 23 '05 #14

P: n/a

"Andrew Thompson" <Se********@www.invalid> wrote in message news:kb****************************@40tude.net...
On Sat, 09 Oct 2004 17:06:19 GMT, George Hester wrote:
I'm just that much of a clicker on the Net. The reason being
I have been burned too often.


You should try surfing with a browser, rather than
your OS component. Much safer.

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane


I do surf with a browser. IE 5.5 to be exact. Is that the "component" you are referring to?
If so yeah I know. But that "component" is not as intractable as you may think. Just requires a little
extra work which sucks.

George Hester
__________________________________
Jul 23 '05 #15

P: n/a
On Sat, 9 Oct 2004 09:33:05 -0400, Roger Desparois
<ro*************@sympatico.ca> wrote:

[snip]
NS won't recognize it.

Can anyone tell me why ?
The document.all collection is a Microsoft invention, support by only a
few other browsers.
And is there a way around the problem ?
Use the W3C Document Object Model (DOM). Whilst support is not 100%, it is
better than the all collection. Optionally, you can add fallbacks to other
element retrieval methods.

<URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdGEID>
I really like the elegance of this code and would like to keep using it.
I'm afraid that a lack of feature testing and unnecessary use of eval is
not elegant.
<head
<script language="Javascript"`>
The language attribute is deprecated and shouldn't be used any more. Use
the (required) type attribute instead.

<script type="text/javascript">
<!--
Script hiding is another obsolete practice, unnecessary for the Web today.
Remove the SGML comments.
function Pop(name){
eval("document.all."+name+".style.visibility='visi ble'");
The eval here, and below, isn't necessary. Properties can be accessed
using the bracket notation which allows the use of expressions to
construct the property name (see
<URL:http://www.jibbering.com/faq/faq_notes/square_brackets.html>).

document.all[name].style.visibility = 'visible';

However, this still lacks feature detection and a cross-browser approach
to accessing elements.

Before your code, you can add this:

var getRefById = document.getElementById ?
function(n) {return document.getElementById(n);}
: document.all ?
function(n) {
var e = document.all[n] || {}, l = e.length;
if('number' == typeof l) {
for(var i = 0; i < l; ++i) {if(e[i].id == n) {return e[i];}}
} else if(e.id == n) {return e;}
return null;
}
: function() {return null;},

It creates a function, getRefById, that will attempt to obtain a function
reference when given the id of an element. Once you have that reference,
you check that the style object is available, and if so, use it.

function Pop(name) {
/* Try to get the element identified as name. */
var e = getRefById(name), s;
/* If a reference was obtained... */
if(e) {
/* ...check for the style property. */
if(e.style) {
s = e.style;
} else {
/* If it doesn't exist, use the element itself. */
s = e;
}
s.visibility = 'visible';
}
}

This can be reduced to:

function Pop(name) {
var e = getRefById(name);
if(e) {(e.style || e).visibility = 'visible';}
}

The main difference is the use of the logical OR operator, '||'. Rather
than operating on booleans only, it evaluates the 'trueness' of the
operands. If the first operand evaluates to true, its value (the style
object in this case) is the result. If the first operand evaluates to
false, the second value is always returned.
}
function Wop(name){
eval("document.all."+name+".style.visibility='hidd en'");
}
The above obviously applies here, too.

[snip]
<div id="prod"
Style="background-color:#ff0000;Position:Absolute;Left:39px;
Top:89px;Width:178px;Height:16px;Visibility:visibl e;z-index:31"
Why this massive amount inline style information? Comparing it to the DIV
below, only the z-index and the visibility property seem to be different.
Move it into a style sheet and use a class selector. The remaining unique
information can be applied with an id selector.

[snip]
<table width="178" height="16" border="0" cellspacing="0"
cellpadding="0" class="menu">
<tr>
<td align="center" valign="middle">Volleyball</td>


Why use deprecated attributes on the table and cell elements when you're
already using CSS?

[snip]

Hope that helps,
Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #16

P: n/a
Lasse Reichstein Nielsen wrote:
<snip>
ns6 = (!document.all && document.getElementById);
//ns6 = true if Netscape 6+


That also matches Opera 6 (unless identifying as IE) and
Opera 5, and possibly also Safari and Konqeror (unless
they decided to support document.all as well).

<snip>

Safari and Konqueror do implement - document.all -, so like NetFront,
IceBrowser and Opera 7 (and sometimes 5-6), they will be identified as
IE 5+.

Richard.
Jul 23 '05 #17

P: n/a
George Hester wrote:
<snip>
No as I explained earlier. I'm just that much of a
clicker on the Net. The reason being I have been
burned too often.

<snip>

At least one of the links form quick answer 26 in the FAQ is to another
page on jibbering.com, so if it is considered safe to view the FAQ in
HTML form (and it is (Currently no FAQ or FAQ notes pages attempt to
execute any script at all)) then it should also be considered safe to
view that page. Though, even when using IE, disabling scripting and
ActiveX should eliminate any risk.

Richard.
Jul 23 '05 #18

P: n/a
Thank you for your comprehensive answer.

<snip>
The use of the - eval - contributes nothing to simplicity here, in the
source code or the execution of the code. It follows from nothing but
the author's ignorance of javascript as a language...


You've got me there.

I learned html when it was still static and I am desperately trying to keep
up with the hectic pace of all the changes.

Reading your reply, I realise that I am only using snipets of things I've
read all over the place, copying javascript code that does what I need
without really understanding it and using CSS only for text attributes where
I should have used it for more.

Consequently I see now that my code is quite ugly, a bastardisation of old
and new programming. I will take your comments to heart and try to clean it.

Thanks again to you (and all the others) for taking the time for your
detailed reply.
Roger
Jul 23 '05 #19

P: n/a
Michael Winter wrote:
On Sat, 9 Oct 2004 09:33:05 -0400, Roger Desparois
<ro*************@sympatico.ca> wrote:

[snip]
NS won't recognize it.

Can anyone tell me why ?


The document.all collection is a Microsoft invention, support by only a
few other browsers.

Please note that the PR version of the final Firefox will also support
"document.all" for compatibility with poorly written code. Not, I feel,
a good idea but certainly an understandable move.
Jul 23 '05 #20

P: n/a
VK
> Netscape 4 is this:

ns4 = (document.layers);
//ns4 = true if Netscape 4


Of course it is totally ancient history by now, so just in respect to the
Great_Olds (meaning NN4x series :-)
:
document.layers was a collection of all layers on the given page. So the
call document.layers gives you the length of this collection. Usually at
least one layer was presented, so it casted nicely to true. But without any
layers it gave you false (0 -> false).
That was the rare case then it was better to use navigator.userAgent and
parseFloat to get the particular build.
I believe by 4.72 they fixed it so document.layers <> document.layers.length
(default property call), but nobody cared too much at that time anyway.
Jul 23 '05 #21

P: n/a
JRS: In article <ck*******************@news.demon.co.uk>, dated Mon, 11
Oct 2004 13:38:02, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.co.uk> posted :
Please note that the PR version of the final Firefox will also support
"document.all" for compatibility with poorly written code. Not, I feel,
a good idea but certainly an understandable move.


If document.all is present in addition to document.getElementById
and/or document.layers then ISTM that multi-browser code which tests
for such entities should be reviewed to see whether the tests are
correctly prioritised.

I believe that the code in FAQ 4.15, and the code that was earlier there
and recognised document.layers, will pass that review.

My version of that earlier code is probably OK as is, but I see in it
some commented-out warning code ...

Perhaps someone could check <URL:http://www.merlyn.demon.co.uk/js-
date2.htm#RC> in the PR version, just to see whether running text-
clocks appear.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 23 '05 #22

P: n/a
Dr John Stockton wrote:

<--snip-->
Perhaps someone could check <URL:http://www.merlyn.demon.co.uk/js-
date2.htm#RC> in the PR version, just to see whether running text-
clocks appear.


Yes, it appears. The entire section appears the same to me in IE6 SP2 as
is it does in Firefox PR
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
Jul 23 '05 #23

P: n/a
"Dr John Stockton" wrote:
Mark Preston posted :
Please note that the PR version of the final Firefox will
also support "document.all" for compatibility with poorly
written code. Not, I feel, a good idea but certainly an
understandable move.


If document.all is present in addition to
document.getElementById and/or document.layers then
ISTM that multi-browser code which tests for such entities
should be reviewed to see whether the tests are correctly
prioritised.


The Mozilla authors have taken the (in my opinion bad, and strange)
decision to implement - document.all - such that it is not detectable
(by typeof or type-converting) so properly structured feature detecting
code will never notice it.

If by prioritised you mean which of the various methods should be the
preferred choice for element reference retrieval,I would still go with -
document.getElementById -, not because it is W3C standard but because it
is the most well defined, and limited, in the behaviour that should be
expected of it. It is possible to add code that will make -
document.all - behave exactly like gEID, but emulating all of -
document.all - on W3C standard only browsers (are there any of those
left now?) is a lot more involved than writing:-

document.all = document.getElementByTagName{'*');

Richard.
Jul 23 '05 #24

P: n/a
Richard Cornford wrote:
The Mozilla authors have taken the (in my opinion bad, and strange)
decision to implement - document.all - such that it is not detectable
(by typeof or type-converting) so properly structured feature detecting
code will never notice it.


I am not defending their decision, but I would imagine the Mozilla authors'
rational for the - document.all - behaviour to be something akin to:

By supporting - document.all - in a way that is not detectable in properly
structured feature detecting code, they eliminate the possibility that the
less-well-supported document.all path will be chosen. However, if the script
is so badly written that it simply assumes document.all will be available,
the code (hopefully) won't fail.

In other words they want the W3C-compatible path taken when presented with:

if (document.all) {
// path not taken by FF 1.0PR
}
if (document.getElementById) {
// path taken by FF 1.0PR
}

but they want something like this to work

<script language="JavaScript1.2">
<!--
// badly written JavaScript here
document.all.myDiv.style.color = 'Red';
//-->
</script>

Personally I think supporting - document.all - will just perpetuate poorly
written code, but I can understand why they have chosen to support it, even
in a limited fashion. They have probably simply gotten tired of being told
their browser is "broken" because it does not work on the many, many, many
poorly authored sites that cater solely to Internet Explorer.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #25

P: n/a
Grant Wagner wrote:
Richard Cornford wrote:
The Mozilla authors have taken the (in my opinion bad, and
strange) decision to implement - document.all - such that it
is not detectable (by typeof or type-converting) so properly
structured feature detecting code will never notice it.
I am not defending their decision, but I would imagine the
Mozilla authors' rational for the - document.all - behaviour
to be something akin to:

By supporting - document.all - in a way that is not detectable
in properly structured feature detecting code, they eliminate
the possibility that the less-well-supported document.all path
will be chosen.


This move makes it questionable as to the extent to which -
document.all - is less well supported (at least when all the gecko users
have updated). Of the scriptable W3C DOM standard dynamic visual
browsers; IE 5+, Opera 7, Konqueror, Safari, Gecko browsers, IceBrowser
and probably others, will support - document.all -, along with less
dynamic W3C browsers like NetFront and Opera 6 (more or less). And with
IE 4 falling into the - document.all - only camp (and probably not being
alone there), Mozilla's decision might have swing the numbers away from
gEBI.

It is a bit like - innerHTML -, it is not DOM standard but it is very
well supported and so difficult to justify not using it on the grounds
that it is not standard.

<snip> Personally I think supporting - document.all - will just
perpetuate poorly written code, but I can understand why
they have chosen to support it, even in a limited fashion.
They have probably simply gotten tired of being told their
browser is "broken" because it does not work on the many,
many, many poorly authored sites that cater solely to
Internet Explorer.


I agree with your proposed motivation, and that it will perpetuate
poorly written code, but I suspect that denying the possibility of
detecting an implemented feature will act to undermine feature detecting
itself and encourage an attitude of charging in with code that "woks"
and never addressing the consequences of its failure.

Personally I don't mind whether Mozilla implements it or not, I am not
going to prefer to use it because it is more chaotic in its behaviour
than gEBI (returning collections sometimes and allowing at least three
distinct methods of indexing its contents (at latest on the latest
IEs)). But if it is there it should be possible to know that it is
there.

That would however be near catastrophic because of the:-

isNet6Plus = Boolean(document.getElementById && !document.all);
isIE5Plus = Boolean(document.getElementById && document.all);

- style browser detecting that is so (misguidedly) pandemic.

In any event the decision appears to have been made so the consequences
may eventually become apparent.

Richard.
Jul 23 '05 #26

P: n/a
Richard Cornford wrote:
Grant Wagner wrote:

By supporting - document.all - in a way that is not detectable
in properly structured feature detecting code, they eliminate
the possibility that the less-well-supported document.all path
will be chosen.

This move makes it questionable as to the extent to which -
document.all - is less well supported (at least when all the gecko users
have updated). Of the scriptable W3C DOM standard dynamic visual
browsers; IE 5+, Opera 7, Konqueror, Safari, Gecko browsers, IceBrowser
and probably others, will support - document.all -, along with less
dynamic W3C browsers like NetFront and Opera 6 (more or less). And with
IE 4 falling into the - document.all - only camp (and probably not being
alone there), Mozilla's decision might have swing the numbers away from
gEBI.

It is a bit like - innerHTML -, it is not DOM standard but it is very
well supported and so difficult to justify not using it on the grounds
that it is not standard.


Besides, the 'all' method is not only applicable to the document object,
but too any HTML element, too, thus permitting to find an element with a
requested ID in only a subtree of the document. I find this useful when
generating complex nodes from (DOM, or textual) templates: I needn't
care about uniquifying (?) all ID attributes, but at most, only the ID
of root template elements.

Cheers,

Alexis
--
some domain is free
Jul 23 '05 #27

This discussion thread is closed

Replies have been disabled for this discussion.