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

Changing the "SRC" attribute of a frame

P: n/a
Hello;

My "index.htm" page has 3 frames (content, navigation bar, and logo).

I set the "SRC" of the "logo" frame to a blank gif image and then want to
change it's contents after the other two frames have been loaded by using a
javascript statement from the "navigation" frame, as shown below:

top.window.ccs_logo.src = 'images/ccs_logo.gif';
alert(top.window.ccs_logo.src);

The "top..." is working as the "alert" shows the "SRC" has been changed, but
the image in the "logo" frame does not change.

I have spent several hours searching google but can't seem to find what I'm
over-looking. (If more code, or additional details, need to be posted,
please let me know.)

Can anyone help me out

TIA.

Charles...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.674 / Virus Database: 436 - Release Date: 5/2/04
Jul 23 '05 #1
Share this Question
Share on Google+
24 Replies


P: n/a
Charles Crume wrote:
Hello;
My "index.htm" page has 3 frames (content, navigation bar, and logo).

I set the "SRC" of the "logo" frame to a blank gif image and then want to
change it's contents after the other two frames have been loaded by using a
javascript statement from the "navigation" frame, as shown below:

top.window.ccs_logo.src = 'images/ccs_logo.gif';
alert(top.window.ccs_logo.src);

The "top..." is working as the "alert" shows the "SRC" has been changed, but
the image in the "logo" frame does not change.

I have spent several hours searching google but can't seem to find what I'm
over-looking. (If more code, or additional details, need to be posted,
please let me know.)

Can anyone help me out
TIA.
Charles...


Charles, try this:

top.logo.document.ccs_logo.src = 'images/ccs_logo.gif';

Mike

Jul 23 '05 #2

P: n/a
mscir wrote:
Charles Crume wrote:
Hello;
My "index.htm" page has 3 frames (content, navigation bar, and logo).

I set the "SRC" of the "logo" frame to a blank gif image and then
want to
change it's contents after the other two frames have been loaded by
using a
javascript statement from the "navigation" frame, as shown below:

top.window.ccs_logo.src = 'images/ccs_logo.gif';
alert(top.window.ccs_logo.src);

The "top..." is working as the "alert" shows the "SRC" has been
changed, but
the image in the "logo" frame does not change.

I have spent several hours searching google but can't seem to find
what I'm
over-looking. (If more code, or additional details, need to be posted,
please let me know.)

Can anyone help me out
TIA.
Charles...

Charles, try this:

top.logo.document.ccs_logo.src = 'images/ccs_logo.gif';


Correction: I read your message wrong. I think this might do what you want:

top.logo.location.href='images/ccs_logo.gif';

Jul 23 '05 #3

P: n/a
Charles Crume wrote:
Hello;

My "index.htm" page has 3 frames (content, navigation bar, and logo).

I set the "SRC" of the "logo" frame to a blank gif image and then want to
change it's contents after the other two frames have been loaded by using a
javascript statement from the "navigation" frame, as shown below:

top.window.ccs_logo.src = 'images/ccs_logo.gif';
alert(top.window.ccs_logo.src);

The "top..." is working as the "alert" shows the "SRC" has been changed, but
the image in the "logo" frame does not change.


You are not changing the source of the frame with that, you are setting
a property of the top.window

You don't change the SRC of a frame, you change its HREF property.

top.window.css_logo.href="someOtherPage.html";

Thats assuming the name of the frame window is css_logo
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/
Jul 23 '05 #4

P: n/a
mscir wrote:
<snip>
top.logo.location.href='images/ccs_logo.gif';


The named/IDed frame/iframe, as a named property of the global/window
object are not supported (or fully supported) by all browsers. However,
all browsers that understand frames seem to make named frames available
as named properties of the global frames collection. So, given a frame
with the name "logo":-

top.frames['logo'].location = ' ... ';

- or:-

top.frames.logo.location = ' ... ';

- maximises cross-browser support (though some accompanying feature
detection would still be called for).

Richard.
Jul 23 '05 #5

P: n/a
Hi mscir;

"mscir" <ms***@access4less.com.net.org.uk> wrote in message
news:10*************@corp.supernews.com...
mscir wrote:
[snip]
Correction: I read your message wrong. I think this might do what you want:
top.logo.location.href='images/ccs_logo.gif';


Thank you -- this works great!

I'm familiar with object oriented programming, but am new to javascript and
still learning the object model. How did you know "top.logo.location.href'
is what I needed? And... can you tell me where I can learn this? (I've got a
couple of books on javascript and have bookmarked over 20 pages in IE, but
was not able to find what I needed in this instance.)

Thanks again for your help.

Charles...
Charles...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.674 / Virus Database: 436 - Release Date: 5/2/04
Jul 23 '05 #6

P: n/a
Hi Richard;

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:c7*******************@news.demon.co.uk...

[snip]
The named/IDed frame/iframe, as a named property of the global/window
object are not supported (or fully supported) by all browsers. However,
all browsers that understand frames seem to make named frames available
as named properties of the global frames collection. So, given a frame
with the name "logo":-

top.frames['logo'].location = ' ... ';
top.frames.logo.location = ' ... ';

- maximises cross-browser support (though some accompanying feature
detection would still be called for).


Thank you -- your suggestions work great also!

I'm familiar with object oriented programming, but am new to javascript and
still learning the object model. How did you know "top.frames...' is what I
needed? Can you tell me where I can read more about "named/IDed
frame/iframe, as a named property..."?

Thanks again for your help.

Charles...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.674 / Virus Database: 436 - Release Date: 5/2/04
Jul 23 '05 #7

P: n/a
Charles Crume wrote:
Hi mscir;
"mscir" wrote in message
mscir wrote:

[snip]
Correction: I read your message wrong. I think this might do what you

want: top.logo.location.href='images/ccs_logo.gif';

Thank you -- this works great!

I'm familiar with object oriented programming, but am new to javascript and
still learning the object model. How did you know "top.logo.location.href'
is what I needed? And... can you tell me where I can learn this? (I've got a
couple of books on javascript and have bookmarked over 20 pages in IE, but
was not able to find what I needed in this instance.)

Thanks again for your help.
Charles...


Hi Charles,

Sorry about my first incorrect post. I read about 'top' here:

http://www.quirksmode.org/js/frameintro.html

This talks about it too (found w/google while finding first site):

http://www.yourhtmlsource.com/javasc...ingframes.html

Glad it worked,
Mike

Jul 23 '05 #8

P: n/a
Hi Randy;

"Randy Webb" <hi************@aol.com> wrote in message
news:8K********************@comcast.com...

[snip]
You are not changing the source of the frame with that, you are setting
a property of the top.window

You don't change the SRC of a frame, you change its HREF property.
OK. Can you recommend a source of info (book, web site, etc.) where I can
read up on this (I thought I was changing the correct property -- i.e., it's
the frame's "SRC" property that specifies the page/img to use).

top.window.css_logo.href="someOtherPage.html";


I get "Error: 'top.window.ccs_logo' is null or not an object when I use
this. As I am not sure of the object heirarchy (just yet anyways, but I'm
working on it :-), I'm not sure what to change here. "ccs_logo" is the frame
name, but it is in a "framset" that is within a "framset" as shown below:

-------------------------------
<frameset name="xxx" cols="0,*" border="0" frameborder="yes"
borderwidth="12" bordercolor="0000FF" framespacing="0">
<frame src="intro.shtml" name="content_area" scrolling="yes" border="0"
frameborder="0" noresize>
<frameset name="yyy" rows="*,0" border="0" frameborder="no"
bordercolor="FF0000" framespacing="0">
<frame src="images/nil.gif" name="ccs_logo" scrolling="no"
border="0" frameborder="0" noresize>
<frame src="navigate.htm" name="navigate" scrolling="yes" border="0"
frameborder="0">
</frameset>
<noframes>
<body><p>This page uses frames, but your browser does not support
them.</p>
</body>
</noframes>
</frameset>
-------------------------------

Thanks again for your help.

Charles...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.674 / Virus Database: 436 - Release Date: 5/2/04
Jul 23 '05 #9

P: n/a
Hi mscir;

"mscir" <ms***@access4less.com.net.org.uk> wrote in message
news:10*************@corp.supernews.com...

[snip]
Sorry about my first incorrect post. I read about 'top' here:
No problem -- I am grateful for your help!!

http://www.quirksmode.org/js/frameintro.html
This talks about it too (found w/google while finding first site):
http://www.yourhtmlsource.com/javasc...ingframes.html


Thanks, I've bookmarked both pages (I even looked at the first page during
my search and had already bookmarked it). I think I understand the "frame
tree" (at least a little), but am unaware of the various "normal properties"
as mentioned in:

-------------
"As you see, you first walk to the correct frame, then you access normal
properties like location.href or document.title and read them out or change
them."
-------------

Do you know where I can find some documentation on the so called "normal
properties"?? (The site mentions them, but does not give a link to more
info -- unless I missed it.)

I searched and searched google using variations of "javascript frame
properties" and either did not find them are didn't realize I had and kept
on looking.

Charles...


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.674 / Virus Database: 436 - Release Date: 5/2/04
Jul 23 '05 #10

P: n/a
Charles Crume wrote:
<snip>

Thanks, I've bookmarked both pages (I even looked at the first page during
my search and had already bookmarked it). I think I understand the "frame
tree" (at least a little), but am unaware of the various "normal properties"
as mentioned in:
-------------
"As you see, you first walk to the correct frame, then you access normal
properties like location.href or document.title and read them out or change
them."
-------------
Do you know where I can find some documentation on the so called "normal
properties"?? (The site mentions them, but does not give a link to more
info -- unless I missed it.)

<snip>

I think a good place to start might be a frames tutorial. You can find
lots of them with google. I found this searching for 'frame tutorial
html', I think this one looks decent after a quick look, maybe other
people know of better web pages dealing with this subject:

http://www.idocs.com/tags/frames/frames.html

Mike

Jul 23 '05 #11

P: n/a
Hi Mike;

"mscir" <ms***@access4less.com.net.org.uk> wrote in message
news:10*************@corp.supernews.com...

[snip]
I think a good place to start might be a frames tutorial. You can find
lots of them with google. I found this searching for 'frame tutorial
html'
http://www.idocs.com/tags/frames/frames.html


Yes, I found a bunch of them too -- and this one looks real good.

However, and perhaps I have not articulated my difficulty in understanding
this adequately, but I do not see any info on the "location.href" property
that you used in:

top.logo.location.href='images/ccs_logo.gif';

to help me get my problem solved.

I clicked on both the <FRAMESET ...> and <FRAME ...> links and neither has a
"location" or "href" property!! This is what's stumping/confusing me :-(

Where does "location" come from? Where does "href" come from? This site, as
well as all the others I've looked at, show the "SRC" attribute (property??)
to be what holds the URL.

Am I missing something *real* obvious here?

Thanks.

Charles...

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.674 / Virus Database: 436 - Release Date: 5/2/04
Jul 23 '05 #12

P: n/a
Charles Crume wrote:
<snip>
I'm familiar with object oriented programming, but am new to
javascript and still learning the object model.
It isn't anything like as simple as "the object model" as only a limited
part of the browser object model is standardised, browsers do not
necessarily fully (or correctly) implement the standards that do exist,
and some provide additional features.
How did you know "top.frames...' is what I needed?
Even with the diversity in browser DOMs there are common features and
the - frames - collection on the global object is common to browsers
that understand what a frame is.

But to be honest I don't think - top.frames - is what you want. I
think - parent.frames - is actually what you are after. In a frame
within a frameset - top - and - parent - refer to the same object, but -
parent - is a reference to the frame containing the current
window/global object, while - top - is a reference to the topmost (or
outermost) frameset page. If your frameset page is displayed in a frame
of another frameset the - top - reference will refer to the wrong
object, while the - parent - reference will still refer to the
immediately containing frameset's global/window object.

In a single HTML page (outside a frameset) - top, parent, window and
self - all refer to the same (only) global/window object.

I didn't mention that in my previous post because I was primarily
interested in introducing Mike to the benefits for cross-browser
scripting in using the - frames - collection over assuming that a
named/IDed frame would be available as a property of the global/window
object. On the (rare) occasions when browser scripting allows a "one
method suites all" (at least all that understand frames in the first
place) solution, it saves a lot of unnecessary grief to know what that
method is as soon as possible.

But over all I tend towards the often-expressed opinion that frames are
more trouble than they are worth anyway, so the question becomes
somewhat academic.
Can you tell me where I can read more about
"named/IDed frame/iframe, as a named property..."?

<snip>

Formal documentation for browser object models has always been a
problem. Microsoft and Mozilla document their browser's DOMs (though the
Mozilla documentation could do with an update sometime soon) and
Netscape still make documentation for Netscape 4 available (as the
JavaScript 1.3 client-side reference). And the W3C publishes the DOM
standard that are being adopted by web browsers, though they are mostly
concerned exclusively with the document and do not have much to say
about the parts of the browser object model outside of the document.

Apart from that, detailed browser object model documentation is fairly
hard to find. Opera's, for example, mostly refers back to the W3C
standards, and doesn't mention most of the features of IE browsers that
it reproduces.

(The group's FAQ includes URLs for the documentation that has been
identified).

Personally, I like to find out from the browsers themselves exactly what
their object models contain. They aren't always that forthcoming but I
have published some listings of complete example browser object models
at:-

<URL: http://www.litotes.demon.co.uk/dom_root.html >

(They are one html page listing properties (name, current value and
type) per object, with properties that refer to other object acting as
links to the pages that list the properties of those objects. Providing
structure and content for the object models listed. (avoid the
IceBrowser 5 listing at first as it is a bit of an oddity, interesting
in demonstrating the potential diversity but not very representative of
browsers in general))

Richard.
Jul 23 '05 #13

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
Apart from that, detailed browser object model documentation is fairly
hard to find. Opera's, for example, mostly refers back to the W3C
standards, and doesn't mention most of the features of IE browsers that
it reproduces.
I think they *mention* them, but one would need to look up the Microsoft
documentation to see what they actually do :)
<URL:http://www.opera.com/docs/specs/#jscript>
<URL: http://www.litotes.demon.co.uk/dom_root.html >


Kewl!

/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 #14

P: n/a
Richard Cornford wrote:
mscir wrote:
<snip>
top.logo.location.href='images/ccs_logo.gif';


The named/IDed frame/iframe, as a named property of the global/window
object are not supported (or fully supported) by all browsers. However,
all browsers that understand frames seem to make named frames available
as named properties of the global frames collection. So, given a frame
with the name "logo":-

top.frames['logo'].location = ' ... ';
- or:-
top.frames.logo.location = ' ... ';

- maximises cross-browser support (though some accompanying feature
detection would still be called for).

Richard.


Richard,

Do you know of any sites where I can read about browser support for
these different frame methods?

Mike

Jul 23 '05 #15

P: n/a
"Charles Crume" <cc@charlescrumesoftware.com> writes:
However, and perhaps I have not articulated my difficulty in understanding
this adequately, but I do not see any info on the "location.href" property
that you used in:

top.logo.location.href='images/ccs_logo.gif';
I would recommend using
top.frames['logo'].location.href = ...
or
top.frames.logo.location.href = ...
to access the frame through the appropriate collection.
The location property is a property of window objects. A frame is
implemented as a window, so it has all the properties.
You can read more about the location object here:
<URL:http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/location.html>
Where does "location" come from?
It is a property of window objects.
Where does "href" come from?
It is a property of Location objects.
This site, as well as all the others I've looked at, show the "SRC"
attribute (property??) to be what holds the URL.
The src property is a property of Frame DOM elements.

Your HTML page is parsed from text into an internal represntation
called the Document Object Model (DOM), where the document is
structured as a tree. Each HTML element (from start tag to end tag)
generates one Element node in the DOM tree, and has as children (or
children's children etc) all elements that occour between the start
and end tag. This places your Frame element somewhere in the DOM
tree as an instance of HTMLFrameElement. That element has a "src"
property.

The browser also has one object corresponding to each view of a
document, either a separate window or a frame. Those are Window
objects, and are typically also used as the global object for
Javascript execution (the global object is where the global variables
live).
Am I missing something *real* obvious here?


A lot of reading :)
I have some links on DOM and DHTML here:
<URL:http://www.infimum.dk/HTML/references.html#ref_1_4>

The refrences I use the most are the DOM 2 Core and HTML
specifications, the ECMAScript v3 standard, and the Gecko and IE DOM
references, but that is for reference, not learning. They could be
pretty hard on a beginner :)

/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 #16

P: n/a
Randy Webb <hi************@aol.com> writes:
You are not changing the source of the frame with that, you are
setting a property of the top.window

You don't change the SRC of a frame, you change its HREF property. top.window.css_logo.href="someOtherPage.html";
The .window is not necessary. For any window object, it always
points to itself, so "top.window" is always the same as "top".

I recommend using the forms collection instead of assuming that
forms are directly available as properties of the window object.

The href property is not a property of the window object, but of
the location object.

So, try this:
top.frames['css_logo'].location.href = "someOtherPage.html";
Thats assuming the name of the frame window is css_logo


.... and that it is a subframe of the top frame.

/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 #17

P: n/a
Hi Richard;

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:c7*******************@news.demon.co.uk...

[snip]
It isn't anything like as simple as "the object model" as only a limited
part of the browser object model is standardised, browsers do not
necessarily fully (or correctly) implement the standards that do exist,
and some provide additional features.
OH CRAP :-( This is gonna make it kinda difficult to learn.

How did you know "top.frames...' is what I needed?


Even with the diversity in browser DOMs there are common features and
the - frames - collection on the global object is common to browsers
that understand what a frame is.


OK. I think I've got this part figured out :-)

But to be honest I don't think - top.frames - is what you want. I
think - parent.frames - is actually what you are after. In a frame
within a frameset - top - and - parent - refer to the same object, but -
parent - is a reference to the frame containing the current
window/global object, while - top - is a reference to the topmost (or
outermost) frameset page. If your frameset page is displayed in a frame
of another frameset the - top - reference will refer to the wrong
object, while the - parent - reference will still refer to the
immediately containing frameset's global/window object.


OK. Thanks. I will try and expereiment using "top" vs. "parent".
[snip]

And... thanks for all the other info (I've saved this msg for future
reference).

Charles...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/04
Jul 23 '05 #18

P: n/a
Hi Lasse;

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:k6**********@hotpop.com...

[snip]
The location property is a property of window objects. A frame is
implemented as a window, so it has all the properties.
You can read more about the location object here:
<URL:http://devedge.netscape.com/library/...pt/1.3/referen
ce/location.html>

OK, thanks, and thanks for the link.

[snip]
Your HTML page is parsed from text into an internal represntation
called the Document Object Model (DOM), where the document is
structured as a tree.


[snip]

Thanks for the explanation --I'm beginning to understand a little more.

Am I missing something *real* obvious here?


A lot of reading :)


Don't I know it!!

Thanks again.

Charles...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/04
Jul 23 '05 #19

P: n/a
Charles Crume wrote:
"Richard Cornford" wrote:
[snip]
It isn't anything like as simple as "the object model" as only a
limited part of the browser object model is standardised, browsers
do not necessarily fully (or correctly) implement the standards that
do exist, and some provide additional features.


This is gonna make it kinda difficult to learn.

<snip>

Unfortunately, cross-browser scripting for the Internet is not easy, and
so it is not easy to learn. But things that are easy don't make for an
entertaining intellectual challenge. The main problem is that scripts
have to be written without any certainty about the environment in which
they will be executing (even whether it will be executing scripts at
all).

That is quite different form most other programming contexts, where the
environment, object model, APIs, etc, are known and (ore or less)
reliable (at least consistent). But the situation is not so bad that
browser scripting is impossible, there is a core of common browser
features that can be used (and increasingly so as the W3C DOM standards
are more widely adopted). It is just that (almost) nothing can be taken
for granted and assumed to exist in the unknown browser that will be
operating on the client side.

So the first thing that needs to be learnt for successful cross-browser
scripting is how to cope with the unknown execution environment. In the
face of the unknown you proceed with caution, testing the ground every
step of the way. Only attempting to use a browser feature once you have
verified that it exists. So, for example, wishing to assign a URL to
location object of another frame:-

if((typeof parent != 'undefined')&&(parent != window)){
// The parent reference is distinct from the current window
if(parent.frames){
// the frames collection exists on this browser.
if(parent.frames['logo']){
// The target frame is referenceable as a named member of
// the frames collection.
if(parent.frames['logo'].location){
// The parent frame has a loction object.
// Assigning to the location should be effective
parent.frames['logo'].location = URL;
}
}
}
}

In the event that the browser does not implement any of the required
objects, the above code will not attempt to act in a way that uses them,
and so it will not error. Obviously the logic of the - if - tests can be
re-arranged to more suitably/efficiently address the situation, and -
else - branches added to consider possible alternative/fall-back
approaches when features may exist to facilitate that, or to allow a
positive controlled response to failure of the browser to implement the
desired features.

(It is also usually inefficient to actually structure tests in this way,
so that they are repeated each time a feature needs to be detected. If a
frame/window has a - location - object the first time you test it it
will have one for all subsequent tests. The design of feature detecting
tests for efficiency is something that needs some consideration, and the
dynamic nature of javascript allows some interesting possibilities.)

The second major aspect of cross-browser scripting is appropriate script
design. To design a script such that it provides a positive benefit when
it is supported by the unknown browser, but does not make anything worse
when it is not. This is termed "clean degradation", and should be
implemented such that it happens under control and transparently to the
user (there is no point telling the user that their browser is
inadequate in your opinion, because they are likely to be incapable or
unwilling to do anything about that (else they probably would have)).

Clean degradation is achieved by planning for the total failure of the
script (all scripts will fail on some browsers, not least because some
browsers cannot execute scripts at all).

An example might be the use of HTML SELECT elements for navigation. It
is apparently quite common for a SELECT element to be used to list
pages, and, when an item is selected, for a script to used to navigate
the browser to a corresponding URL. But if the script fails the user is
left fiddling with SELECT element that is promising them some sort of
action, but doing nothing useful.

An alternative (and more appropriate) design might start with an HTML
list of links, contained within suitable DIV (or similar) elements, and
use DHTML techniques to modify the presentation of that list so that it
acts like a SELECT element (presenting the contained link elements as a
drop-down when activated). Now total failure of the script will only
result in the HTML list remaining in it's fully exposed form as part of
the page, the contained links will be accessible and the navigation
achievable. The worst case only impacts on how that list is presented to
the user.

The transformation of the underlying HTML would be done in such a was as
to ensure that the list remained in its original form until browser
support for the required features had been verified, and any evidence of
lack of support would just leave the script needing to exit quietly to
leave the user with a page that was completely usable (clean
degradation), but maybe falling short of the intended presentation.

Now, it is true that the DHTML option will only work in dynamic
browsers, while almost any javascript capable browser can use the SELECT
based navigation, but most browsers are dynamic and javascript enabled,
so most of the time they are equivalent. The difference comes in the
response of the two designs to failure of the script. The SELECT design
is totally dependent on javascript execution (it is useless without it),
while the DHTML version does not render the navigation dependent on
javascript, the worst case is still a viable HTML page.

When a script is designed to have a path of clean degradation to viable
underlying HTML it is always possible to employ feature detection to
ensure that a script can enhance a page when the browser can facilitate
it, without detracting from the page when it cannot.

Richard.
Jul 23 '05 #20

P: n/a
Lasse Reichstein Nielsen wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
Apart from that, detailed browser object model documentation is
fairly hard to find. Opera's, for example, mostly refers back to the
W3C standards, and doesn't mention most of the features of IE
browsers that it reproduces.


I think they *mention* them, but one would need to look up the
Microsoft documentation to see what they actually do :)
<URL:http://www.opera.com/docs/specs/#jscript>


Yes, that is the sort of documentation I am talking about; an incomplete
(didn't notice attachEvent mentioned at all) list of supported
properties, with the implication that they have been (successfully)
implemented to follow the behaviour of a version documented elsewhere.
But still, it is an improvement over the last time I looked at the opera
documentation.
<URL: http://www.litotes.demon.co.uk/dom_root.html >


Kewl!


Now that is the sarcastic/deprecating spelling of cool, isn't it?

Richard.
Jul 23 '05 #21

P: n/a
Richard Cornford wrote:
Charles Crume wrote:
<snip>
How did you know "top.frames...' is what I needed?
Even with the diversity in browser DOMs there are common features and
the - frames - collection on the global object is common to browsers
that understand what a frame is.

But to be honest I don't think - top.frames - is what you want. I
think - parent.frames - is actually what you are after. In a frame
within a frameset - top - and - parent - refer to the same object, but -
parent - is a reference to the frame containing the current
window/global object, while - top - is a reference to the topmost (or
outermost) frameset page. If your frameset page is displayed in a frame
of another frameset the - top - reference will refer to the wrong
object, while the - parent - reference will still refer to the
immediately containing frameset's global/window object.

In a single HTML page (outside a frameset) - top, parent, window and
self - all refer to the same (only) global/window object.

I didn't mention that in my previous post because I was primarily
interested in introducing Mike to the benefits for cross-browser
scripting in using the - frames - collection over assuming that a
named/IDed frame would be available as a property of the global/window
object. On the (rare) occasions when browser scripting allows a "one
method suites all" (at least all that understand frames in the first
place) solution, it saves a lot of unnecessary grief to know what that
method is as soon as possible.

<snip>

I've been thinking about what you said about the frames collection being
accessible to more browsers then the named frame. Does this logic apply
to all collections, is it true that it is always safer to use
collections than to name page elements for browser compatability?

I looked around this page and found that these elements are accessible
through collections:

http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-75708506

Document: images, applets, links, forms, anchors
Form: Elements
Select: OPTION elements
Map: Areas
Table: rows, tBodies
Table Row: cells;

Mike

Jul 23 '05 #22

P: n/a
mscir wrote:
<snip>
I've been thinking about what you said about the frames collection
being accessible to more browsers then the named frame. Does this
logic apply to all collections, is it true that it is always safer to
use collections than to name page elements for browser compatability?
If you want to use named properties of the global object to refer to
named/IDed page elements then you are skating on very thin ice, and
collection based alternative would be better. If you wanted to use named
properties of the document then you would be better off, at least in
referring to forms and IMG elements (and only in HTML DOMs as opposed to
XHTML DOMs, but you have to be quite masochistic to even consider
scripting XHTML in current browsers).

But even when named forms and IMG elements are fairly reliably available
as named properties of the document I would still use the collections
anyway. For one thing the resulting code becomes more self documenting.
Consider:-

document.x

- which doesn't say much about what - x - is. While:-

document.images.x

- or:-

document.forms.x

- makes it clear what - x - is in each case.
I looked around this page and found that these elements
are accessible through collections:

http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-75708506

Document: images, applets, links, forms, anchors
Form: Elements
Select: OPTION elements
Map: Areas
Table: rows, tBodies
Table Row: cells;


document.forms - images - applets - links - anchors, form.elements and
select.options are all part of what has become known as DOM 0. They were
first implemented in browsers that are now extinct, have been reproduced
in all subsequent HTML browser and have now been standardised as part of
the W3C HTML DOM. They are about as reliable as browser features get,
and code that uses them is both HTML DOM standard (so theoretically
future proof) and back compatible with most (if not all) HTML browsers
currently in use.

In all cases, when I suitable collection from this group exists, I would
recommend its use over any alternatives.

The collections under tables should be handled with more caution as they
first appeared in IE 4 and contemporary Netscape 4 versions do not
facilitate access to table elements. There are also some later browsers
that don't fully implement them (Opera 6, for example).

Richard.
Jul 23 '05 #23

P: n/a
Richard Cornford wrote:
If you want to use named properties of the global object to refer to
named/IDed page elements then you are skating on very thin ice, and
collection based alternative would be better.

<snip>
Thanks for explaining this Richard, this is very useful knowledge. It's
convenient having a rule of thumb.

MIke

Jul 23 '05 #24

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
Kewl!


Now that is the sarcastic/deprecating spelling of cool, isn't it?


Not the way I use it. To me, it is appreciative, although in a geeky
way. :)

/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 #25

This discussion thread is closed

Replies have been disabled for this discussion.