DOMContentLoaded event and iframes
WakA
embedded inside a document. Is it possible to ignore or incorporate the
DOM of these iframes so the event fires only if the "top" document's
DOM is loaded or only if all DOM content including that of the iframes
is loaded?
Regards,
Chris
Boris Zbarsky
Possible in what sense? The web depends on current DOMContentLoaded
behavior, so it's not exactly subject to change in a shipping browser
that needs to browse the web, but if you're doing something custom you
can change it, of course....
-Boris
WakA
Naturally, I'm not expecting or even hoping for a change in the
codebase or behavior in order to achieve this. If I wanted to fry an
egg using my browser i'm sure this would be "possible" in some way. ;)
I was mostly looking to DOMContentLoaded as a way to supplant a load
event (that only fires after all the potentially big content has been
loaded). My expectation for the behavior of DOMContentLoaded was thus
of a load event minus all the nonDOM content, but this turned out not
to be since the "whole" page is not fully loaded and waiting for
iframes to load whilst the DOMContentLoaded event is already fired.
Ideally I guess I'm looking for something like a (theoretical)
DOMAllContentLoaded event. Unfortunately we don't live in a theoretical
world and I'm not sure of the benefit of such an event for most users
anyway as my knowledge of this field is sadly limited.
Anyway, if there is a way to achieve this without keeping track of DOM
myself I would love to hear about it.
Chris
Boris Zbarsky
> Naturally, I'm not expecting or even hoping for a change in the codebase
> or behavior in order to achieve this. If I wanted to fry an egg using my
> browser i'm sure this would be "possible" in some way. ;) I was mostly
> looking to DOMContentLoaded as a way to supplant a load event (that only
> fires after all the potentially big content has been loaded). My
> expectation for the behavior of DOMContentLoaded was thus of a load
> event minus all the nonDOM content, but this turned out not to be since
> the "whole" page is not fully loaded and waiting for iframes to load
> whilst the DOMContentLoaded event is already fired.
Well... An <iframe> is in fact "non-DOM content".
The precise definition of DOMContentLoaded is "when parsing of the page
is done".
> Ideally I guess I'm looking for something like a (theoretical)
> DOMAllContentLoaded event
Defined how?
-Boris
WakA
> On 1/24/10 3:52 PM, WakA wrote:
>> Naturally, I'm not expecting or even hoping for a change in the codebase
>> or behavior in order to achieve this. If I wanted to fry an egg using my
>> browser i'm sure this would be "possible" in some way. ;) I was mostly
>> looking to DOMContentLoaded as a way to supplant a load event (that only
>> fires after all the potentially big content has been loaded). My
>> expectation for the behavior of DOMContentLoaded was thus of a load
>> event minus all the nonDOM content, but this turned out not to be since
>> the "whole" page is not fully loaded and waiting for iframes to load
>> whilst the DOMContentLoaded event is already fired.
>
> Well... An <iframe> is in fact "non-DOM content".
I'm not sure I would consider iframe non-DOM content. What's going on
archtitecturally? As far as I can see the DOM just gets expanded with a
#document node. Also,
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html
defines an HTMLIFrameElement.
>
> The precise definition of DOMContentLoaded is "when parsing of the page
> is done".
Which begs the question of when parsing of the page is done? If iframe
is just regular DOM then why isn't it counted as such?
>
>> Ideally I guess I'm looking for something like a (theoretical)
>> DOMAllContentLoaded event
>
> Defined how?
When parsing simply wait for all objects parsing an iframe to report
DOMAllContentLoaded (or use another faster method internally), then let
it issue a DOMAllContentLoaded itself. That should traverse nicely with
OO. Come to think of it, I don't think that's entirely impossible to
implement in javascript from the outside.
Chris
Boris Zbarsky
> I'm not sure I would consider iframe non-DOM content. What's going on
> archtitecturally?
You kick off a network load, just like you do for <img>, <object>,
<embed>. When the data arrives it's handled somehow; how depends on the
exact data.
> Also, http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html
> defines an HTMLIFrameElement.
Yes, but I assumed by "non-DOM" you meant "things that don't end up in
the DOM of the page" (like the data of images, etc).
>> The precise definition of DOMContentLoaded is "when parsing of the
>> page is done".
>
> Which begs the question of when parsing of the page is done?
UA-dependent; typically right after the parser reads the last byte from
the netowrk stream. The ordering of this with other network loads is
undefined (could happen in any order).
> If iframe is just regular DOM then why isn't it counted as such?
What do you mean by "regular dom"?
> When parsing simply wait for all objects parsing an iframe to report
> DOMAllContentLoaded (or use another faster method internally), then let
> it issue a DOMAllContentLoaded itself.
So just like onload but blocking on a smaller set of events, presumably.
Which events? All <iframe>s and <object>s? What about <embed>? What
about <img src="something.svg">?
-Boris
WakA
> You kick off a network load, just like you do for <img>, <object>,
> <embed>. When the data arrives it's handled somehow; how depends on
> the exact data.
That makes sense ofcourse.
>> Which begs the question of when parsing of the page is done?
>
> UA-dependent; typically right after the parser reads the last byte from
> the netowrk stream. The ordering of this with other network loads is
> undefined (could happen in any order).
Right, I shouldn't have tried using parsing in a non-strict sense. But
then why is the event not called DOMContentParsed? I realize this is
splitting hairs but loading for me has a broader meaning than parsing.
>> If iframe is just regular DOM then why isn't it counted as such?
>
> What do you mean by "regular dom"?
Part of the DOM specification.
>> When parsing simply wait for all objects parsing an iframe to report
>> DOMAllContentLoaded (or use another faster method internally), then let
>> it issue a DOMAllContentLoaded itself.
>
> So just like onload but blocking on a smaller set of events,
> presumably. Which events? All <iframe>s and <object>s? What about
> <embed>? What about <img src="something.svg">?
The svg made me chuckle. It's too bad img src doesn't support svg yet
:( But I see your point.
Embed apparently isn't officially part of the DOM specificiations so I
guess I wouldn't include this in a blocking. Iframes, period. Objects
supporting the same content as iframes, so i'm guessing that's only
html related? This goes to the point of not discriminating against HTML
DOM that happens to be located elsewhere than in the original document.
It seems to me to be part of the document regardless. Whether this
agrees with the spirit of DOM I wouldn't know.
Chris
Boris Zbarsky
> Right, I shouldn't have tried using parsing in a non-strict sense. But
> then why is the event not called DOMContentParsed?
<shrug>. Read https://bugzilla.mozilla.org/show_bug.cgi?id=109760 and
you'll have as much information as anyone other than jst. ;)
Note that at the time the event effectively waited for scripts and
stylesheets to load, since those blocked the parser.
>> What do you mean by "regular dom"?
>
> Part of the DOM specification.
The iframe element, sure. What happens inside it may or may not be.
-Boris