Cross-browser question: making Netscape recognize frames within document within frame within frame

[David Hayes]

I tried finding an answer on http://www.quirksmode.org/ without success.

I am attempting a complicated Frames structure. I have made it work in IE,
but not Netscape.

I begin with three frames, where the two lower ones are within a Frameset
within the master Frameset:

1111111111111111111

2 3333333333333333
2 3333333333333333
2 3333333333333333

I can change the URL of the content of any of the three frames with commands
such as these:

parent.frames[0].location='masthead.html';
parent.frames[2].location='sidebar.html#068';
parent.frames[3].location='mainspace.html#068';"

These work in Netscape as well as IE.

The cross-browser differences begin after I split up frame 3 into more
frames. I do this (upon a user click) by loading into frame 3 an HTML file
that is nothing but code for a new frameset. The frameset divides this
window into three columns. Each column loads with an HTML file inside it.

Even here, Netscape and IE both load the new page and display the new
content. The trouble is when I try to substitute new files for the ones in
these sub-frames. IE does what I want, Netscape remains frozen.

To change the content of the frames within the document within the #3 frame
(which itself is within a frameset within a frameset within the master
window), I use:

parent.frames[2].frames[0].location='Producer.html#E1'
or:
parent.frames[2].frames[2].location='reasons.html#C2'

I have also been able to use:

parent.frames[2].document.frames[0].location='Producer.html#E1'
or:
parent.frames[2].document.frames[2].location='reasons.html#C2'

And even:

parent.parent.frames[2].frames[0].location='Producer.html#E1'

IE handles them all. Netscape doesn't do anything. Is there a way of
addressing these inner frames via Netscape that I have failed to consider?

--
David Hayes

(remove the name of the programming language from email address to make it
usable)

[Martin Honnen]

David Hayes wrote:

I am attempting a complicated Frames structure. I have made it work in IE,
but not Netscape.

I begin with three frames, where the two lower ones are within a Frameset
within the master Frameset:

1111111111111111111

2 3333333333333333
2 3333333333333333
2 3333333333333333
How about posting the relevant HTML instead of ASCII art?
I can change the URL of the content of any of the three frames with commands
such as these:

parent.frames[0].location='masthead.html';
parent.frames[2].location='sidebar.html#068';
parent.frames[3].location='mainspace.html#068';"

These work in Netscape as well as IE.
If you have three frames then parent.frames[3] is not null?

Anyway, frames can be given names and then referenced by name which
might be safer then finding the proper index. So you could try
<frame name="frameName" ...>
and then
if (parent.frames && parent.frames.frameName) {
parent.frames.frameName.location.href = ...
}
The cross-browser differences begin after I split up frame 3 into more
frames. I do this (upon a user click) by loading into frame 3 an HTML file
that is nothing but code for a new frameset. The frameset divides this
window into three columns. Each column loads with an HTML file inside it.

Even here, Netscape and IE both load the new page and display the new
content. The trouble is when I try to substitute new files for the ones in
these sub-frames. IE does what I want, Netscape remains frozen.
Have you checked the Netscape JavaScript console? Does it show errors?
To change the content of the frames within the document within the #3 frame
(which itself is within a frameset within a frameset within the master
window), I use:

parent.frames[2].frames[0].location='Producer.html#E1'
or:
parent.frames[2].frames[2].location='reasons.html#C2'
As said it might help to name frames and then use the names instead of
the index.
I have also been able to use:

parent.frames[2].document.frames[0].location='Producer.html#E1'

document.frames is IE object model stuff so that will surely give errors
in the Netscape JavaScript console.

If naming frames doesn't help I suggest you post a URL where we can
visit the problem, but check the JavaScript console and tell us about
the error messages you get. And clearly identify what needs to be done
to trigger the error, where/how you call your frame location change code
(e.g. on button click or directly onload, could be simply a problem with
sibling frames not being accessible then).
--

Martin Honnen
http://JavaScript.FAQTs.com/

[David Hayes]

"Martin Honnen" <ma*******@yahoo.de> wrote in message
news:41*********************@newsread2.arcor-online.net...

David Hayes wrote:

I am attempting a complicated Frames structure. I have made it work in IE, but not Netscape.

I begin with three frames, where the two lower ones are within a Frameset within the master Frameset:

1111111111111111111

2 3333333333333333
2 3333333333333333
2 3333333333333333
How about posting the relevant HTML instead of ASCII art?

Here goes:

<FRAMESET ROWS="85,*" frameborder="0" border="0"
framespacing="0">
<FRAME SRC="masthead.html" noresize scrolling="no"
marginheight="0">
<FRAMESET COLS="33%,67%" frameborder="0" border="0"
framespacing="0">
<FRAME frameborder="0" border="0" framespacing="0"
marginwidth="10" marginheight="10" SRC="sidebar.html"
name="sidebar" scrolling="auto">
<FRAME frameborder="0" border="0" framespacing="0"
marginwidth="10" marginheight="0" SRC="mainspace.html"
name="mainspace" noresize scrolling="auto">
</FRAMESET>
</FRAMESET>

I can change the URL of the content of any of the three frames with commands such as these:

parent.frames[0].location='masthead.html';
parent.frames[2].location='sidebar.html#068';
parent.frames[3].location='mainspace.html#068';"

These work in Netscape as well as IE.

If you have three frames then parent.frames[3] is not null?

In that frames [2] and [3] are inside [1], the above referents work.
frames[1] is never used because it contains the other two and thus has no
room to display HTML of its own. (Anyway, this part of the code works in
both NS and IE.)
Anyway, frames can be given names and then referenced by name which
might be safer then finding the proper index. So you could try
<frame name="frameName" ...>
and then
if (parent.frames && parent.frames.frameName) {
parent.frames.frameName.location.href = ...
}
Actually, I have tried this. Note the names "sidebar" and "mainspace"
above. (Read on to see where what I'm doing now is different from what I
tried in the past.

The cross-browser differences begin after I split up frame 3 into more
frames. I do this (upon a user click) by loading into frame 3 an HTML file that is nothing but code for a new frameset. The frameset divides this
window into three columns. Each column loads with an HTML file inside it.
Even here, Netscape and IE both load the new page and display the new
content. The trouble is when I try to substitute new files for the ones in these sub-frames. IE does what I want, Netscape remains frozen.

Have you checked the Netscape JavaScript console? Does it show errors?

No. My question: would the fact that the errors are occurring within a
document *within* the main document affect this outcome?

To change the content of the frames within the document within the #3 frame (which itself is within a frameset within a frameset within the master
window), I use:

parent.frames[2].frames[0].location='Producer.html#E1'
or:
parent.frames[2].frames[2].location='reasons.html#C2'

As said it might help to name frames and then use the names instead of
the index.

I have also been able to use:

parent.frames[2].document.frames[0].location='Producer.html#E1'

document.frames is IE object model stuff so that will surely give errors
in the Netscape JavaScript console.

I have tried to work this by addressing the frames by a name, but not until
the thinking-through this issue that came with the writing of these two
newsgroup posts have I wondered whether it would work to address the frame
by TWO names, such as [...].document['documentName'].frame['mainspace']

That now being said, if the response given here is correct -- that
document.frames is IE without NS support -- mightn't the be no
direct-equivalent solution?
If naming frames doesn't help I suggest you post a URL where we can
visit the problem, but check the JavaScript console and tell us about
the error messages you get. [...]

Before I do, I'd like to pose the question as to whether there is a simple
difference as to whether the frame[n].frame[n], frame[n].document[n],
document[n].frame[n] structures of IE have equivalents in NS. If there are,
I can proceed on my own and report back the success (if any) and what (if
anything) I had to tweak to make this happen. (My proceeding on my own will
save anyone else the effort of trudging through a lot of other functions
within the URL, wherein a lot else is going on.)

--
David Hayes

(remove the name of the programming language from email address to make it
usable)

[Mark Preston]

David Hayes wrote:

I tried finding an answer on http://www.quirksmode.org/ without success.

I am attempting a complicated Frames structure. I have made it work in IE,
but not Netscape.

I begin with three frames, where the two lower ones are within a Frameset
within the master Frameset:

I almost hate to mention this, but has no-one told you that users
actually hate frames anyway and that they are not a very good way of
doing pretty much anything at all in a browser? Seriously, although
there may be an answer to your specific question, if I were you I would
redesign the page and get rid of all the frames.

[Martin Honnen]

David Hayes wrote:

I'd like to pose the question as to whether there is a simple
difference as to whether the frame[n].frame[n], frame[n].document[n],
document[n].frame[n] structures of IE have equivalents in NS.

A window (and a frame object is a window object too) has a property
named frames in both IE and Netscape, that property is a collection
allowing to access contained frames by index or by name. The property
named frames of the document object is not available in Netscape.
--

Martin Honnen
http://JavaScript.FAQTs.com/

[David Hayes]

> I almost hate to mention this, but has no-one told you that users

actually hate frames anyway and that they are not a very good way of
doing pretty much anything at all in a browser?

I contend that frames, when implemented responsibly and under appropriate
circumstances, enhances the user experience. Take for example a site that
offers vocabulary and definitions. A page designed with frames could have
the vocabulary terms in a scrollable list in the left frame. When the user
clicks a term, the definition could show up in the right-side frame. The
benefits to the user come when the user selects a second, third and fourth
(etc.) term to see defined. The list of terms is already on the page. The
user doesn't have to click the "back" button to leave the second page (which
would have the first definition), wait for the reloading of the first page,
then find his place on the list before he can click a term anew. As a user,
I know that I dislike waiting for a page to reload when I could have had the
information stay in place during the time before I return to it, if it's
likely I will return to it.

Some might object that in circumstances such as this, all of the information
should be on one page. This solution might be impractical. A page with
dozens (even hundreds) of terms *and* their definitions might be over 100K.
The initial loading would take a long time. If the user wants to click just
a handful of select terms, that's a lot of wasted bandwidth. With the
two-frame solution, fewer bytes are transferred. The definitions might be
spread over a dozen or more HTML documents. (When I've done something like
this in the past, that's how many pages I had. The answers can be divided
into individual files for "A-B," "C-D," "E-F," etc. Files for answers for
terms starting with letters not selected at all by a particular user, would
never be downloaded from the server for that user.)

In a single-frame equivalent to this, listing the definitions directly
beside or beneath a term would mean that the definitions would be visible to
a wandering eye a split-second after the user sees a term for the first
time. This is not ideal for classroom situations where it's desirable for a
student to think about an unfamiliar word before mulling over what his
existing knowledge leads him to think it might mean. Withholding a
definition until a user click brings about the desirable. Even if the page
were configured so that the user has to click a link which takes him further
down the page where the definition is (as often happens in Q&A formats),
then clicks a link to return to where he was, we're again talking about a
much larger initial download than necessary.

(For what it's worth, I suggest that in a case such as this, the list of
terms be put in a frame set at a fixed width of 200 pixels, with the
right-side frame getting the remainder of the frame, so that people with
bigger screens don't see a whole lot of blank space to the right of the list
of terms.)

--
David Hayes

(remove the name of the programming language from email address to make it
usable)

[David Hayes]

"Martin Honnen" <ma*******@yahoo.de> wrote in message
news:41***********************@newsread4.arcor-online.net...

David Hayes wrote:

I'd like to pose the question as to whether there is a simple
difference as to whether the frame[n].frame[n], frame[n].document[n],
document[n].frame[n] structures of IE have equivalents in NS.

A window (and a frame object is a window object too) has a property
named frames in both IE and Netscape, that property is a collection
allowing to access contained frames by index or by name. The property
named frames of the document object is not available in Netscape.

This actually provides useful information. As I've stated before, I have
working in IE a setup where I have frames and framesets. Inside one of the
embedded frames (let's call it "mainspace"), I load a particular HTML
document (let's call it the "inner frameset" document) that itself contains
three vertical frames. I manipulate the contents of these three frames in
IE, but haven't been able to replicate this in NS.

If my failure is attributable to NS not recognizing my instructions for
document[n].frame[n] content *within* the master window, then a workaround
is to directly target the HTML document that is itself inside this
"mainspace" frame. One thing I had not considered trying is to remove the
"inner frameset" HTML document, reloading it's content, then reloading it as
the "new" content of "mainspace." At the least, I might trying reloading
the content and then generating a "refresh" instruction upon the "inner
frameset" document or on the whole window.

--
David Hayes

(remove the name of the programming language from email address to make it
usable)

[Mark Preston]

David Hayes wrote:

I almost hate to mention this, but has no-one told you that users
actually hate frames anyway and that they are not a very good way of
doing pretty much anything at all in a browser?

I contend that frames, when implemented responsibly and under appropriate
circumstances, enhances the user experience. Take for example a site that

Oh, I agree with the advantages of the effects you are discussing. My
apologies if that was not clear. My point was that the same can be done
using much easier <div> layers, which are far easier to handle.