IFrame location.href not working!!!

A

Asra

Hello,
I have a strange problem with IFrames with regards to dynamic external
html source file loading. The external file is displayed when the page
is loaded for the first time but nothing happens on clicking the <a>
link (which should load another file in the IFrame). All the files are
present, no problem on that end! The complete code is shown below. (I
am using IE v6).

<HTML>
<HEAD>
<TITLE>Delivery On Call</TITLE>
</HEAD>


<BODY>
<a href="javascript:document.getElementById('if1').location.href='tables.htm';return(true);">
click me </a>
<IFRAME NAME="if1" ID="if1" src="LeftFrame.htm"
STYLE="border: 1px solid black; width=200px; height=200px;"></IFRAME>
</BODY>
</HTML>

Regards,
Asra
 
M

Michael Winter

I have a strange problem with IFrames with regards to dynamicexternal
html source file loading. The external file is displayedwhen the page is
loaded for the first time but nothing happens onclicking the <a> link
(which should load another file in theIFrame). All the files are
present, no problem on that end! Thecomplete code is shown below. (I am
using IE v6).

I might be wrong here (I don't use frames), but it was my understanding
that the source for an iframe was changed via the src attribute. It
certainly seems to work in my browsers (IE, Opera and Mozilla).

HTML documents should contain a DTD. See
<HEAD>
<TITLE>Delivery On Call</TITLE>
</HEAD>


<BODY>
<a
href="javascript:document.getElementById('if1').location.href='tables.htm';return(true);">
click me </a>

Never use JavaScript URIs. They have a tendancy to cause many problems.
See <URL:http://jibbering.com/faq/#FAQ4_24>. You should also check that
the DOM methods you call are available with feature testing. See
<URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html> and
<IFRAME NAME="if1" ID="if1" src="LeftFrame.htm"
STYLE="border: 1px solid black; width=200px; height=200px;"></IFRAME>

Unless you're targetting the iframe (that is <A target="if1" ...>), I
don't see much point in using the name attribute, especially as you're
accessing the element by the value of its id attribute.

Mike
 
R

Richard Cornford

Michael Winter wrote:
I might be wrong here (I don't use frames), but it was my
understanding that the source for an iframe was changed via
the src attribute. It certainly seems to work in my browsers
(IE, Opera and Mozilla).

Changing the - src - property of an IFRAME element in an HTML page is
the right way to attempt this as that IFRAME element is normally not
also the global object of the contained frame (and the W3C spec
includes - src - but not - location - on IFEAMS). However, navigating an
IFRAME by assigning to its - src - property is not very cross-browser.
Opera <= 6, for example, will allow the assignment but not navigate the
contents.

The most universally supported (including all browsers where assigning
to the IFRAME element's - src - property works) and reliable method of
navigating the contents of an IFRAME is to reference the global object
of the corresponding frame using the - frames - collection of the page
containing the IFRAME, and then assign to the - location - object in
that frame.

Unless you're targetting the iframe (that is <A target="if1" ...>),
I don't see much point in using the name attribute, especially
as you're accessing the element by the value of its id attribute.

As the most reliable cross-browser method is through the - frames -
collection, it is worth being aware the some (mostly older) browsers do
not make IDed IFRAMES named members of that collection, only NAMEd
IFRAMES. Doubling up the names and ID attributes with the same value
maximises the chances that the IFRAME contents will be accessible
through the - frames - collection as a named member.

Richard.
 
H

hugo27

Hello,
I have a strange problem with IFrames with regards to dynamic external
html source file loading. The external file is displayed when the page
is loaded for the first time but nothing happens on clicking the <a>
link (which should load another file in the IFrame). All the files are
present, no problem on that end! The complete code is shown below. (I
am using IE v6).

<HTML>
<HEAD>
<TITLE>Delivery On Call</TITLE>
</HEAD>


<BODY>
<a href="javascript:document.getElementById('if1').location.href='tables.htm';return(true);">
click me </a>
<IFRAME NAME="if1" ID="if1" src="LeftFrame.htm"
STYLE="border: 1px solid black; width=200px; height=200px;"></IFRAME>
</BODY>
</HTML>

Regards,
Asra

hugo27 Aug 07, 2004
My two cents: No matter how you go, in a link or button,
when you assign the URL (path/fileName), delimate the
= operator with spacebar spaces, like so:
<a href="javascript:document.getElementById
('if1').location.href = 'tables.htm';return(true);">
^^^
good luck Asra
hugo
 
R

Randy Webb

hugo27 wrote:

My two cents: No matter how you go, in a link or button,
when you assign the URL (path/fileName), delimate the
= operator with spacebar spaces, like so:
<a href="javascript:document.getElementById
('if1').location.href = 'tables.htm';return(true);">
^^^

It makes absolutely no difference to the browser. The only difference it
makes in that context is readability by humanrs.
 
R

Richard Cornford

hugo27 wrote:
My two cents: No matter how you go, in a link or button,
when you assign the URL (path/fileName), delimate the
= operator with spacebar spaces, like so:
<a href="javascript:document.getElementById
('if1').location.href = 'tables.htm';return(true);">
^^^

That may represent an act motivated by nothing but superstition. While
formatting aimed at promoting human comprehension is generally
advantageous, javascript is extremely tolerant of white space
distribution. The functionality of the code will not be altered because
the assignment operator is not rendered ambiguous by the absence of
white space separating it form adjacent expressions.

Richard.
 
M

Matt Kruse

Michael said:
Never use JavaScript URIs.

That's a bit extreme.

When creating objects like iframes, for example, it's very handy to use
src="javascript:func()" to populate the window with content that doesn't
involve making a trip back to the server or using a dummy url like
about:blank.
 
T

Thomas 'PointedEars' Lahn

Matt said:
That's a bit extreme.

When creating objects like iframes, for example, it's very handy to use
src="javascript:func()" to populate the window with content that doesn't
involve making a trip back to the server or using a dummy url like
about:blank.

Why do you insist using a proprietary feature
instead of the supported standards compliant one?


PointedEars
 
R

Randy Webb

Thomas said:
Matt Kruse wrote:




Why do you insist using a proprietary feature
instead of the supported standards compliant one?

Because, unlike yourself, Matt deals with reality. Thats the way things
*are*, not the way people *wish* they were.
 
M

Matt Kruse

Thomas said:
Why do you insist using a proprietary feature
instead of the supported standards compliant one?

Why do you think javascript: url's are a proprietary feature?

They're bad in href's because they don't degrade nicely at all. But when
you're creating an object using javascript, you already know js is enabled,
so it's safe to use a javascript: url.
 
T

Thomas 'PointedEars' Lahn

Matt said:
Why do you think javascript: url's are a proprietary feature?

Because they are. Convince me of the opposite by citing a document
that specifies them which deserves the designation of quasi-standard
or above.

<nitpick>They are URIs, BTW.</nitpick>


PointedEars
 
T

Thomas 'PointedEars' Lahn

Randy said:
Because, unlike yourself, Matt deals with reality.

Nonsense. It is an intrinsic property of proprietary features that they
radically change or vanish in a considerable short span of time while
standards compliant features tend to be more future-proof (because the
standardization process or its equivalent [as with the W3C] takes much
more time). Using proprietary features without alternative increases the
maintenance efforts to be expected and thus the maintenance costs in the
mid-term and in the long-term because the probability of changes to the
code due to changes in the features or its vanishing is considerably
higher than using it along with an standards compliant alternative or
sticking to standards compliant features in the first place.
Thats the way things *are*, not the way people *wish* they were.

Most recent user agents support standards compliant DOM access and
manipulation methods. The main reason is that there are only few
layout engines left to compete with each other (IE, Gecko, Opera,
KHTML, to name some).

So far for *your* reality.

BTW:
<http://dictionary.cambridge.org/define.asp?key=63524&dict=CALD>
<http://info.astrian.net/jargon/terms/p/proprietary.html>


PointedEars
 
A

Asra

Thanks a lot for your inputs. The IFrame doesn't populate by setting
the src attribute also. That is:
document.getElementById('if1').src = 'tables.htm'
also doesn't work.
Did I get your explanations correctly?
Regards,
Asra
 
M

Michael Jones

I have a strange problem with IFrames with regards to dynamic external
html source file loading. The external file is displayed when the page
is loaded for the first time but nothing happens on clicking the <a>
link (which should load another file in the IFrame). All the files are
present, no problem on that end! The complete code is shown below. (I
am using IE v6).

<HTML>
<HEAD>
<TITLE>Delivery On call</title>
</HEAD>


<BODY>
<a href="javascript:document.getElementById('if1').location.href='tables.ht
m';return(true);">
click me </a>
<IFRAME NAME="if1" ID="if1" src="LeftFrame.htm"
STYLE="border: 1px solid black; width=200px;
height=200px;"> said:
</BODY>
</HTML>

Regards,
Asra

If your aim is to create links that change the content of the iframe,
there's a much simplier way. Try the target attribute <a
href="tables.htm" target="if1">clickis meis</a>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,770
Messages
2,569,583
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top