Re: DOMContentLoaded event and iframes

On 2010-01-25 04:28:22 +0100, Boris Zbarsky <[email protected]> said:

> 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