Discussion:
DOMContentLoaded event and iframes
WakA
2010-01-24 19:05:36 UTC
Permalink
I've noticed that the DOMContentLoaded event also fires for iframes
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
2010-01-24 19:38:34 UTC
Permalink
Post by WakA
I've noticed that the DOMContentLoaded event also fires for iframes
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?
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
2010-01-24 20:52:45 UTC
Permalink
Post by Boris Zbarsky
Post by WakA
I've noticed that the DOMContentLoaded event also fires for iframes
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?
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
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
2010-01-24 21:24:00 UTC
Permalink
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
2010-01-25 00:42:26 UTC
Permalink
Post by 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".
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.
Post by Boris Zbarsky
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?
Post by Boris Zbarsky
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
2010-01-25 03:28:22 UTC
Permalink
Post by WakA
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.
Post by WakA
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).
Post by WakA
Post by Boris Zbarsky
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).
Post by WakA
If iframe is just regular DOM then why isn't it counted as such?
What do you mean by "regular dom"?
Post by WakA
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
2010-01-25 14:28:53 UTC
Permalink
Post by Boris Zbarsky
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.
Post by Boris Zbarsky
Post by WakA
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.
Post by Boris Zbarsky
Post by WakA
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.
Post by Boris Zbarsky
Post by WakA
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
2010-01-25 15:46:59 UTC
Permalink
Post by WakA
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.
Post by WakA
Post by Boris Zbarsky
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

Loading...