Changing the "SRC" attribute of a frame

[Lasse Reichstein Nielsen]

Re: Changing the "SRC&qu ot; attribute of a frame

"Charles Crume" <cc@charlescrum esoftware.com> writes:
[color=blue]
> However, and perhaps I have not articulated my difficulty in understanding
> this adequately, but I do not see any info on the "location.h ref" property
> that you used in:
>
> top.logo.locati on.href='images/ccs_logo.gif';[/color]

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.netscap e.com/library/manuals/2000/javascript/1.3/reference/location.html>
[color=blue]
> Where does "location" come from?[/color]

It is a property of window objects.
[color=blue]
> Where does "href" come from?[/color]

It is a property of Location objects.
[color=blue]
> This site, as well as all the others I've looked at, show the "SRC"
> attribute (property??) to be what holds the URL.[/color]

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 HTMLFrameElemen t. 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).
[color=blue]
> Am I missing something *real* obvious here?[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Lasse Reichstein Nielsen]

Re: Changing the &quot;SRC&qu ot; attribute of a frame

Randy Webb <hikksnotathome @aol.com> writes:
[color=blue]
> 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.[/color]
[color=blue]
> top.window.css_ logo.href="some OtherPage.html" ;[/color]

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";
[color=blue]
> Thats assuming the name of the frame window is css_logo[/color]

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

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Charles Crume]

Re: Changing the &quot;SRC&qu ot; attribute of a frame

Hi Richard;

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
news:c7ko8a$1gj $1$8300dec7@new s.demon.co.uk.. .

[snip]
[color=blue]
> 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.[/color]

OH CRAP :-( This is gonna make it kinda difficult to learn.

[color=blue][color=green]
> > How did you know "top.frames ...' is what I needed?[/color]
>
> 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.[/color]

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

[color=blue]
> 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.[/color]

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

[Charles Crume]

Re: Changing the &quot;SRC&qu ot; attribute of a frame

Hi Lasse;

"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
news:k6zmarxe.f sf@hotpop.com.. .

[snip]
[color=blue]
> 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:
>[/color]
<URL:http://devedge.netscape.com/library/...pt/1.3/referen
ce/location.html>

OK, thanks, and thanks for the link.

[snip]
[color=blue]
> 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.[/color]

[snip]

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

[color=blue][color=green]
> > Am I missing something *real* obvious here?[/color]
>
> A lot of reading :)[/color]

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

[Richard Cornford]

Re: Changing the &quot;SRC&qu ot; attribute of a frame

Charles Crume wrote:[color=blue]
> "Richard Cornford" wrote:
> [snip][color=green]
>> 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.[/color]
>
> This is gonna make it kinda difficult to learn.[/color]
<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.frame s){
// the frames collection exists on this browser.
if(parent.frame s['logo']){
// The target frame is referenceable as a named member of
// the frames collection.
if(parent.frame s['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.

[Richard Cornford]

Re: Changing the &quot;SRC&qu ot; attribute of a frame

Lasse Reichstein Nielsen wrote:[color=blue]
> "Richard Cornford" <Richard@litote s.demon.co.uk> writes:
>[color=green]
>> 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.[/color]
>
> 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>[/color]

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.
[color=blue][color=green]
>> <URL: http://www.litotes.demon.co.uk/dom_root.html >[/color]
>
> Kewl![/color]

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

Richard.

[mscir]

Re: Changing the &quot;SRC&qu ot; attribute of a frame...

Richard Cornford wrote:[color=blue]
> Charles Crume wrote:
> <snip>[color=green]
>>How did you know "top.frames ...' is what I needed?[/color][/color]
[color=blue]
> 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.[/color]
<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-HTML/html.html#ID-75708506

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

Mike

[Richard Cornford]

Re: Changing the &quot;SRC&qu ot; attribute of a frame...

mscir wrote:
<snip>[color=blue]
> 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?[/color]

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.
[color=blue]
> 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;[/color]

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.

[mscir]

Re: Changing the &quot;SRC&qu ot; attribute of a frame...

Richard Cornford wrote:
[color=blue]
> 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.[/color]
<snip>
Thanks for explaining this Richard, this is very useful knowledge. It's
convenient having a rule of thumb.

MIke

[Lasse Reichstein Nielsen]

Re: Changing the &quot;SRC&qu ot; attribute of a frame

"Richard Cornford" <Richard@litote s.demon.co.uk> writes:
[color=blue][color=green]
>> Kewl![/color]
>
> Now that is the sarcastic/deprecating spelling of cool, isn't it?[/color]

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

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'