Prev: Implicit object constructor misinterpretation
Next: Creating an Object that extends Array functionality
From: Laurent vilday on 2 Nov 2009 01:44
Dr J R Stockton :
> Garrett Smith :
>
>> How can I know when an iframe has loaded?
>
> Yes. I have success with the Fram.onLoad event in FF Op Sf Cr, but not
> IE, where I seem to need to use a timeout. OTOH I suspect IE8 of lying
> to me, or of being confused [*].
>
> Flamingo wrote of a readyState property, which might be pollable.

I have no idea what Flamingo is, and also have no idea if the following
is acceptable for clj.
But here is a "solution" (with no setTimeout nor setInterval involved) I
am using since a long time with no issues (assuming, obviously, there is
no cross domain policy stuff) so far :

var frm = document.createElement('iframe');
var isLoaded = false;

function iframeOnLoad()
{
if ( !isLoaded )
{
alert('iframe content is loaded, ready to play with');
}
isLoaded = true;
}

function iframeOnReadyState()
{
if ( !isLoaded && this.readyState == "complete" )
{
iframeOnLoad();
}
}

frm.onload = iframeOnLoad;
frm.onreadystate = iframeOnReadyState;
frm.src = 'URL';

--
laurent
From: Garrett Smith on 2 Nov 2009 03:54
Dr J R Stockton wrote:
> In comp.lang.javascript message <hcj02m$62n$1(a)news.eternal-
> september.org>, Sat, 31 Oct 2009 19:42:12, Garrett Smith
> <dhtmlkitchen(a)gmail.com> posted:
>> Dr J R Stockton wrote:
>>> In comp.lang.javascript message <hcdshu$ds2$1(a)news.eternal-
>>> september.org>, Thu, 29 Oct 2009 22:11:19, Garrett Smith
>>> <dhtmlkitchen(a)gmail.com> posted:
>>>> As long as I have something to say about it, the entry will correctly
>>>> explain how to access the window object of the IFRAME.
>>>>
>>> You are supposed, as FAQ maintainer, to be sustaining something
>>> useful
>>> to the ordinary questioners, especially those who are not full-time
>>> professional JavaScript programmers.


Would an ASCII diagram for the FRAMES section help?

+--------------------------+
| window |
| * document |
| |
| <iframe src="x.jsp"> |
| +------------+ |
| | window | |
| | * document | |
| | | |
| +------------+ |
| </iframe> |
| |
| |
+--------------------------+

If a screenshot of firebug could be conceptualized in ASCII, that might
be more effective communication.

>>> However, you appear entirely unable to understand their positions
>>> and
>>> points of view. FAQ maintaining is a task for the sympathetic
>>> communicator; not for the nerd.
>>>
>> A lot of the complaints with the FAQ is too verbose, too long.
>>
>> The FAQ should not be too much of a chore to read. It should be easy
>> to understand.
>>
>> Once the document is found, the next step is to do something with that,
>> right? That is what DOM and Forms section is for.
>>
>> Things about the document seem more appropriate for "DOM and Forms", not
>> "window and frames".
>
> For the FAQ to be useful to its intended readership, its Subjects (as
> seen at the beginning) must be structured ENTIRELY from the point of
> view of the questioner, without any consideration of the structure of
> the answers.
>

There is value in structuring the FAQ by section. One can come back to
it, as a reference. It is probably boring, painful reading material,
probably even more so when introduced with "RTFFAQ"

Gerard's recent comments seems to indicate this is a problem.

> Otherwise, you're writing a nerdy document much like the majority of the
> big Flamingo book.
>
> You MUST learn how the ordinary FAQ reader will think, when seeking an
> answer.

Sure. The FAQ is for many readers, though. Ideally informative on the
surface, and a reference for much deeper research.

The FAQ should be accurate. A reader finding information that is
incorrect will discard it.

Improving or removing the worst parts should help improve readership.

>
>
>
>> Perhaps worth mentioning:-
>> | The frame must be fully loaded before its content can be accessed.
>
> I am incompletely convinced of that. When reading by timeout, I thought
> I saw signs of gaining access to an only partially-filled links array.
> Certainly they might have been deceiving signs; but the point should be
> checked in several actual browsers.
>
> If your sentence were strictly true, one could issue a frame load
> directly followed by a frame read, and the system would wait until
> loaded before executing the read.
>
> But it would be safe to write :-
> Access to frame content should not be attempted before the frame is
> fully loaded.
>
Yes, it that is better that saying must. Appending nodes during load
would be a problem (operation aborted). Reading layout information would
also not work so well.

>
>> How can I know when an iframe has loaded?
>
> Yes. I have success with the Fram.onLoad event in FF Op Sf Cr, but not
> IE,

Not Safari 2.

where I seem to need to use a timeout. OTOH I suspect IE8 of lying
> to me, or of being confused [*].
>
The nonstandard onload attribute seems to work fairly well:

// Not working in Safari 2.
f1.setAttribute("onload", "f1LoadHandler()");
if(typeof f.onload != "function" && f.attachEvent) {
f.attachEvent("onload", iframeLoadHandler);
}

Nonstandard, but onload="" works in Safari 3+ and others.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>IFRAME onload</title>
</head>
<body>
<iframe id="iFrame"
src="load-content.html"
height="100" width="100"></iframe>
<pre id="m">-</pre>
<script type="text/javascript">
var f = document.getElementById("iFrame");
f.setAttribute("onload", "iframeLoadHandler()");
if(typeof f.onload != "function" && f.attachEvent) {
f.removeAttribute("onload");
f.attachEvent("onload", iframeLoadHandler);
}
function iframeLoadHandler(){
document.getElementById("m").firstChild.data = "iframe loaded";
}
</script>
</body>
</html>
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dr J R Stockton on 2 Nov 2009 18:24
In comp.lang.javascript message <hcm6p4$5p2$1(a)news.eternal-
september.org>, Mon, 2 Nov 2009 00:54:58, Garrett Smith
<dhtmlkitchen(a)gmail.com> posted:
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <hcj02m$62n$1(a)news.eternal-
>> september.org>, Sat, 31 Oct 2009 19:42:12, Garrett Smith
>> <dhtmlkitchen(a)gmail.com> posted:
>>> Dr J R Stockton wrote:
>>>> In comp.lang.javascript message <hcdshu$ds2$1(a)news.eternal-
>>>> september.org>, Thu, 29 Oct 2009 22:11:19, Garrett Smith
>>>> <dhtmlkitchen(a)gmail.com> posted:
>>>>> As long as I have something to say about it, the entry will correctly
>>>>> explain how to access the window object of the IFRAME.
>>>>>
>>>> You are supposed, as FAQ maintainer, to be sustaining something
>>>> useful
>>>> to the ordinary questioners, especially those who are not full-time
>>>> professional JavaScript programmers.
>
>
>Would an ASCII diagram for the FRAMES section help?

No. You seem not yet to have understood that, in a FAQ, the Subject
lines should represent what a questioner is likely to want to ask,
entirely independently of the nature of any possible solutions; and the
section belonging to each Subject line should provide what a questioner
needs to know, in a manner that he can understand and see to represent a
solution that he can use.

If you want to produce a document which, as a document, is structured to
reflect the internal structure of the ECMAScript language and the
browser DOM, then you should call it something other than a FAQ and let
someone more suitable handle the FAQ.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7 8
Prev: Implicit object constructor misinterpretation
Next: Creating an Object that extends Array functionality