calling a function from a iframe

M

mike

If I have a document like:

<script>
function mike_test()
{alert('hi');}
</script>
<iframe src="blank.html" id="my_iframe1">
</iframe>

and in blank.html I have:

<div onclick="mike_test();">
... some stuff
</div>

When I click on the div I get an error.

How do I call the function mike_test() in the parent document?

Mike
 
T

Thomas 'PointedEars' Lahn

mike said:
If I have a document like:

<script>
function mike_test()
{alert('hi');}
</script>
<iframe src="blank.html" id="my_iframe1">
</iframe>

and in blank.html I have:

<div onclick="mike_test();">
... some stuff
</div>

When I click on the div I get an error.

Of course. mike_test() is defined in another document, hence in
another global context. BTW, "an error" is hardly a viable error
_description_.
How do I call the function mike_test() in the parent document?

parent.mike_test(), provided that both documents are displayed as part
of the same second-level domain (and document.domain has been properly
set if they are part of different subdomains).

<http://www.mozilla.org/projects/security/components/same-origin.html>

BTW, you should visit and apply <http://validator.w3.org/> to your code.


PointedEars
 
R

Richard Cornford

mike said:
<script>
function mike_test()
{alert('hi');}
</script>
<iframe src="blank.html" id="my_iframe1">
</iframe>

and in blank.html I have:

<div onclick="mike_test();">
... some stuff
</div>

When I click on the div I get an error.

How do I call the function mike_test() in the parent document?

parent.mike_test();

Richard.
 
V

vallini

You could exploit the associative power of an "object" oriented
language like javascript:

parent["mike_test"]();

Everey object can be accessed via the "dot notation" or as the KEY of
an associative array, being the latter the same as an object
(particularly in Javascript, this affinity between arrays and objects
is to be stressed).

The reason you may find interesting this alternative is that its
potential can be appreciated with examples (and as such pointless but
illustrative) like:

<script>
window["I'm quite cute a name for a variaBle ain't it guys? I think so,
yeah!"]=
function(){alert("hi");}

window["I'm quite cute a name for a variaBle ain't it guys? I think so,
yeah!"]();
</script>

Then from your iframe

parent["I'm quite cute a name for a variaBle ain't it guys? I think so,
yeah!"]();


BTW, you should NOT and NEVER NEVER NEVER visit and apply
<http://validator.w3.org/> to your code AT ALL.

Rather, check here (halfway of the file) how many sites do NOT validate
and couldn't care LESS about it (from CNN to Google, from Amazon to
Yahoo, from Altavista to AOL, from Lycos to Intel, from Logitech to
NBC, from Oracle to Sun, from Monster com to Tucows com, from Nokia to
American Express, plus hundreds more: none validates in the LEAST, ALL
have been browsed, used, and successfully viewed by HUNDREDS OF
MILLIONS of browsers, and PROSPER and make LOTS of bucks):
http://www.unitedscripters.com/spellbinder/internetexplorer.html

Forget about validation, it's UTTERLY pointless.
 
M

mike

Ok, cool.

I like this best: parent.mike_test(); because I don't have to put those
quotes in.

I change my code to:

<script>
function mike_test(event)
{
alert('hi');
x = window.event.clientX;
}
</script>
<iframe src="blank.html" id="my_iframe1">
</iframe>

and in blank.html I have:

<div onmousedown="parent.mike_test(event);">
... some stuff
</div>

You see in my function called mike_test() I passed the event I clicked
on but I get an error "Object required" and really what I want to be
able to do is drag that window around the screen.

Any thoughts on that?
 
R

Richard Cornford

You could exploit the associative power of an "object"
oriented language like javascript:

parent["mike_test"]();

Could, but there would be absolutely no point here.
Everey object can be accessed via the "dot notation" or
as the KEY of an associative array,

The alternatives are dot notation property accessors and bracket
notation property accessors. Javascript objects are not "associative
arrays", they are only at best slightly reminiscent of them in allowing
named properties to be added to all objects at runtime. It is misleading
to label javascript's objects "associative arrays" because individuals
familiar with associative arrays in languages that do implement they may
develop expectations that will not be true of javascript's objects. The
significant examples of these are that associative arrays will have a
length property that reflects the number of properties added, and that
prior to adding any properties associative arrays will be empty. Neither
of these is true of javascript's objects.
being the latter the same as an object

Up to the point where javascript objects are dissimilar to associative
arrays.
(particularly in Javascript, this affinity between arrays
and objects is to be stressed).

It should be appreciated that javascript only has one Object type and as
Arrays are objects they are also instances of that Object type.

BTW, you should NOT and NEVER NEVER NEVER visit and
apply <http://validator.w3.org/> to your code AT ALL.
<snip>

This advice is bogus and utterly wrong. HTML validity is more critical
to the practice of scripting web browsers than it is in any other area
of web development. The aspect of HTML validity that is significant is
structural validity; the correct placement and nesting of HTML elements.
The other aspect of HTML validity, the use of valid attributes, is less
important.

When presented with structurally invalid HTML browsers engage in 'error
correction'. This 'error correction' process impacts upon the creation
of the document object model that is made available to the browser for
scripting.

Structurally valid HTML mark-up has a tree-like structure, the DOM also
has a tree-like structure and valid HTML can be directly translated into
a DOM structure following well-known and documented rules. The rules
applied to structurally invalid HTML mark-up are decided upon by the
authors of individual browsers and mostly remain proprietary secrets of
the manufacturers of those browsers. As a result there is little chance
that any two browsers will be applying the same rules wen doing
error-correction. And as the rules that are actually used impact upon
the DOM structure created that structure can vary considerably between
browsers.

To illustrate this the following is an HTML page with a script describes
the DOM actually created with the short section of invalid HTML mark-up
within the DIV at the bottom of the page. The script outputs HTML-like
formatted text. The output string is generated, and replaces the page,
when the "Test" button is pressed. Elements are shown as opening and
closing tag pairs with their children indented. Elements without child
nodes are displayed as single tags.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function showDom(){
var div = document.getElementById('testDiv');
var st = '<pre>'+listNodeStart(div);
st += showChildren(div, '\t');
st += listNodeEnd(div, '');
st += '<\/pre>';
document.write(st);
document.close();
}
function showChildren(el, ind){
var node, st = '';
for(var c = 0;c < el.childNodes.length;++c){
node = el.childNodes[c];
if(node.nodeType == 1){
st += ind+listNodeStart(node);
//st += (el == node.parentNode)?'':'*';
st += showChildren(node, (ind+'\t'));
st += listNodeEnd(node, ind);
}
}
return st;
}
function listNodeStart(el){
return ('&lt;' + el.nodeName +
((el.type)?(' type=\"' + el.type+'\"'):'')
+ '&gt\n');
}
function listNodeEnd(el, ind){
return (el.childNodes.length?
(ind+'&lt;/' + el.nodeName +'&gt\n'):'');
}

</script>
</head>
<body>

<div id="testDiv">
<table>
<tr><td>Header</td></tr>
<form action="">
<tr><td><input type="text" value=""></td></tr>
<tr><td><input type="text" value=""></td></tr>
<tr><td><input type="submit" value="Submit"></form></td></tr>
<tr><td>Footer</td></tr>
</table>
</div>

<input type="button" value="Test" onclick="showDom();">
</body>
</html>

The structural faults in the invalid HTML are that a FORM element has
been made a child of a TABLE (or a TBODY, by implication) and that the
closing tag for the FORM is inside a TD and so not at the same level as
its opening tag. This is a direct reproduction of some examples of
invalid HTML use that have been posted to this group along with
questions about problems interacting with the associated DOM using
scripts.

Having made the test case we can see what sort of DOM structures some
common web browsers create from it:-

IE 6.0.2800.116:-

<DIV>
<TABLE>
<TBODY>
<TR>
<TD>
</TD>
</TR>
<FORM>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="submit">
</TD>
</TR>
</FORM>
<TR>
<TD>
</TD>
</TR>
</TBODY>
</TABLE>
</DIV>

- Internet explorer has decide to leave the FORM element as an incorrect
child of the (implied) TBODY but it has re-located the end of the form
to outside of the TR in which the FORM's closing tag was placed (that is
the minimum that has to be done in order to create a structure of
objects from the mark-up).

Mozilla 1.6 Gecko/20040113

<DIV>
<TABLE>
<TBODY>
<TR>
<TD>
</TD>
</TR>
<FORM>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="submit">
</TD>
</TR>
<TR>
<TD>
</TD>
</TR>
</TBODY>
</TABLE>
</DIV>

- Mozilla has applied some more extream correction. The FORM elements
itself has no childNodes. Though Mozilla has still left the FORM in an
invalid location.

Opera 8.5 Build 7700

<DIV>
<TABLE>
<TBODY>
<TR>
<TD>
</TD>
</TR>
<CAPTION>
<FORM>
</FORM>
</CAPTION>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="submit">
</TD>
</TR>
<TR>
<TD>
</TD>
</TR>
</TBODY>
</TABLE>
</DIV>

- Opera has don something very odd, it has added a CAPTION element to
TBODY and moved the FORM inside of that. Again the INPUT elements are no
longer decendants of the FORM.

This shows that the error correction preformed by 3 different browsers
turns invalid mark-up into three structuraly divergent DOMs. But the
situation is worse than that because you don't have to change the
invalid mark-up much to see even more diversity in the DOM.

Taking another example of invalid mark-up that has been posted to the
group, and replacing the contents of the DIV above with:-

<table>
<tr><td>Header</td></tr>
<tr><td><form action=""><input type="text" value=""></td></tr>
<tr><td><input type="text" value=""></td></tr>
<tr><td><input type="submit" value="Submit"></form></td></tr>
<tr><td>Footer</td></tr>
</table>

- where the FORM element now starts within one TD and ends in a TD
belonging to another row. The browsers now create:-

Mozilla 1.6 Gecko/20040113

<DIV>
<TABLE>
<TBODY>
<TR>
<TD>
</TD>

</TR>
<TR>
<TD>
<FORM>
<INPUT type="text">
</FORM>

</TD>
</TR>
<TR>
<TD>
<INPUT type="text">
</TD>

</TR>
<TR>
<TD>
<INPUT type="submit">
</TD>
</TR>

<TR>
<TD>
</TD>
</TR>
</TBODY>
</TABLE>
</DIV>

- Mozilla is now willing to recognise the first INPUT as a child of the
form, but again the other two INPUTS are no longer descendants of the
FORM.

Opera 8.5 Build 7700

<DIV>
<TABLE>
<TBODY>
<TR>
<TD>
</TD>
</TR>
<TR>
<TD>
<FORM>
<INPUT type="text">
</FORM>
</TD>
</TR>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="submit">
</TD>
</TR>
<TR>
<TD>
</TD>
</TR>
</TBODY>
</TABLE>
</DIV>

This time Opera's results are much like Mozilla's. But:-

IE 6.0.2800.116:-

<DIV>
<TABLE>
<TBODY>
<TR>
<TD>
</TD>
</TR>
<TR>
<TD>
<FORM>
<INPUT type="text">
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="submit">
</TD>
</TR>
</FORM>
</TD>
</TR>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="submit">
</TD>
</TR>
<TR>
<TD>
</TD>
</TR>
</TBODY>
</TABLE>
</DIV>

- IE has decided that the entire FORM should be contained in the TD
where its opening tag appeared, but has doubled-up the following
children of the TBODY inside the FORM. What it has done is break the
tree-ness of its DOM as now two TRs are both child nodes of the FORM and
of the TBODY. Further testing of the TR elements shows that their -
parentNode - properties refer to the FORM and not the TBODY.

So the result is that structurally invalid HTML mark-up produces a
different DOM structure in each of the three browsers tested, and that
variations in the structural invalidity may radically alter the DOM
structure produced by individual browsers.

This contrasts with the handling of the valid HTML:-

<form action="">
<table>
<tr><td>Header</td></tr>
<tr><td><input type="text" value=""></td></tr>
<tr><td><input type="text" value=""></td></tr>
<tr><td><input type="submit" value="Submit"></td></tr>
<tr><td>Footer</td></tr>
</table>
</form>

- which, in all three browsers, produces the structurally identical DOM
(disregarding optional text nodes):-

<DIV>
<FORM>
<TABLE>
<TBODY>
<TR>
<TD>
</TD>
</TR>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="text">
</TD>
</TR>
<TR>
<TD>
<INPUT type="submit">
</TD>
</TR>
<TR>
<TD>
</TD>
</TR>
</TBODY>
</TABLE>
</FORM>
</DIV>

And since error-correction produces different results in the first three
browsers testing it is likely to produce different results again in the
next three browsers (anything else would be pure coincidence). While all
(even minimally) DOM standard browsers can be expected to produce
consistent and known DOM structures when presented with valid HTML
mark-up.

For pure HTML authors validity may not matter much, as they don't need
to worry about what is going on under the hood, and the authors of
trivial scripts don't necessarily have to concern themselves with it
either. But as soon as scripting gets to the point of having to interact
with the DOM those scripting invalid mark-up face a chaos of browser
dependent variation in DOM structures that will make their task more
difficult than it needs to be, and particularly so if they attempt to
create anything to work in more than a couple of browsers. So the
consequences of attempting to script invalid mark-up is an entire level
of additional complexity that can be entirely avoided by something as
simple as validating HTML mark-up.

The recommendations to script authors, especially if they ever
anticipate writing anything beyond the mundane, is to work only with
structurally valid HTML mark-up. So testing with an HTML validation is a
reasonable practice and any document passing such a validation will be
structurally valid.

Richard.
 

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

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,578
Members
45,052
Latest member
LucyCarper

Latest Threads

Top