DOMContentLoaded for IE

[Diego Perini]

Don't know if you already tried the doScroll("left") trick,
many frameworks already implemented it, YUI and
jQuery to name some, but Mootools have it in SVN
and tools like sIFR already uses it.

I proposed this to solve the fact that IE is missing
such useful native method. I know many methods
exists, each method having his own advantages
and disadvantages. This trick is not different in
that respect but it has some tasty advantages.

This is a link to the original code and trick:

http://javascript.nwbox.com/IEContentLoaded/

And here you can find a tentative test case / tester if you
want to try out your own code / modifications:

http://javascript.nwbox.com/IEContentLoaded/tester.php

The current pre-loaded javascript is only for IE, but you
may paste your code in the text area and see if
it fires correctly in your preferred browser.

Sorry for the colors...and shortness in general.

Diego Perini

[Tobie Langel]

Hi,

I'm all for it myself.

I even had implemented it for 1.6.0.2 and had to revert because it was
making our tests fail.

The problem is that the doScroll technique can trigger the dom:loaded
event *after* window.onload, notably on short pages. Delegating to
window.onload in that case doesn't work, as it's not ordered in IE...
so that's the first thing to solve.

Not impossible, of course, so any implementation that passes our
current tests is more than welcomed.

Best,

Tobie

[Diego Perini]

Tobie,
current implementations in other libraries are not complete,
everybody opted for a slightly different/shorter approach,
without really understand IEContentLoaded completeness.

You were one between the few that realized that the "doScroll()"
method is not enough by itself, there are edge cases where it still
does not fit the bill. I have had a hard time trying to explain this.

All my trick does is just for IE, just to make the point clear to
others...

Firing before the "onload" event but after all nodes are in is a very
difficult task for IE, nearly impossible just by reading it out,
however
let's split the tasks in two separate objectives for a moment:

1) absolutely precede the "window.onload" event
2) all elements should have loaded and be "scriptable"

Probably, by taking them separately, both objectives have been
reached several times in really different ways. Having both
objectives at the exact same time is much more difficult.
A native method is perfect, but IE does not exposes it.

The complete "hack" relies on more parts, not just the "doScroll()",
the frameworks named above, all opted for only implementing the
"doScroll()" part of the complete IEContentLoaded I worked on.

The original code I linked to in my previous post provides also an
"onreadystatechange" event to avoid those possible situations
you described; it is fired when the document "complete" state
is reached.

In my tests this always fire before window "onload", probably just
few milliseconds before, but that is always ensured (and Dojo
king Alex Russell has already said that long ago).

So I use both methods in combination, ("onreadystatechange"
event plus "doScoll('left')" trick on "document.documentElement")
both call the same "init()" to ensure user's handlers only fire once.

The situation you described may be engaged by several triggers,
namely when the server sends "Transfer-Encoding: chunked" content
and page is very long, or when small page are cached and you land
on those pages by means of the back/forward browser buttons.

I know there are many more quirks, but I would like to see the test
case were this is failing. Do you think you can cut out for me the
interesting part of it and post here so I can give it a try ?

Diego Perini

[Diego Perini]

Tobie,
the following is a patch to current "event.js" in Prototype 1.6.x
that should do the trick for primary documents:

--- event.js.orig 2008-03-10 18:39:44.000000000 +0100
+++ event.js 2008-03-10 19:06:49.000000000 +0100
@@ -308,12 +308,23 @@
}

} else {
- document.write("<script id=__onDOMContentLoaded defer src=//:><\/
script>");
- $("__onDOMContentLoaded").onreadystatechange = function() {
+ // trying to always fire before onload
+ document.onreadystatechange = function() {
if (this.readyState == "complete") {
this.onreadystatechange = null;
fireContentLoadedEvent();
}
};
+ (function() {
+ try {
+ // throws errors until after ondocumentready
+ document.documentElement.doScroll("left");
+ } catch(e) {
+ setTimeout(arguments.callee, 50);
+ return;
+ }
+ // no errors, fire
+ fireContentLoadedEvent();
+ });
}
})();

iframes must be handled differently, and there are Opera and
Safari improvements that you may be interested too, see here
for an explanation of the problem and a solution:

http://groups.google.com/group/jquery-dev/browse_thread/thread/ad7e754c0a10f88a/

If you are interested in my dev site I have a "tester.php" that may
be useful if you need to dig deeper in the problem, however the
reason an event is still needed is because a javascript timer is
still unpredictable even if we set it's timeout to 0ms.

Regards,

Diego

[Samuel Lebeau]

I attached a patch (http://dev.rubyonrails.org/ticket/9394) that fixes
IE event handlers calling order (ensure FIFO) and tends to fix
dom:loaded after window.onload issue.
It uses document.doScroll as you suggested and waits for stylesheets
to load on Opera / non-nightly WebKit.
Test for event handlers calling order pass on all platforms, but I
didn't had much time to test if stylesheets are actually loaded.
I guess this should do the trick as it's inspired by jQuery whose
implementation is working fine.

Best,
Samuel Lebeau

Le 12 mars 08 à 18:02, Diego Perini a écrit :

[Tobie Langel]

Hi Diego,

Thank you very much for the feedback so far.

I'd love to hear your comments on Samuel's proposed patch.

Best,

Tobie

> >http://groups.google.com/group/jquery-dev/browse_thread/thread/ad7e75...

[Samuel Lebeau]

Diego, feel free to complete/modify the patch I submitted if you find
something missing or incorrect.
This was just an attempt to concretise all that was said here and on
jQuery group.

It would be great if we could find a way to actually test this
stylesheet issue, for instance by using jstest.rb's SlowServlet
serving a stylesheet file with some special rule...

Regards,

Samuel

Le 13 mars 08 à 02:17, Tobie Langel a écrit :

[Samuel Lebeau]

I just tried this very hacky test using SlowServlet, it confirms
implementation is working, at least with one external stylesheet...

Best,

Samuel

Index: test/unit/event.html
===================================================================
--- test/unit/event.html (revision 9011)
+++ test/unit/event.html (working copy)
@@ -7,6 +7,7 @@
<script src="../../dist/prototype.js" type="text/javascript"></
script>
<script src="../lib/unittest.js" type="text/javascript"></script>
<link rel="stylesheet" href="../test.css" type="text/css" />
+ <link rel="stylesheet" href="/slow/?Content-Type=text
%2Fcss&amp;responseBody=%23styleSheetTest+%7B+position%3A+absolute%3B+
%7D%0A" type="text/css" />
<style type="text/css" media="screen">
/* <![CDATA[ */
#testcss1 { font-size:11px; color: #f00; }
@@ -27,6 +28,7 @@
<p id="inner">One two three <span id="span">four</span></p>
</div>
<div id="container"><div></div></div>
+<p id="styleSheetTest"></p>

<!-- Tests follow -->
<script type="text/javascript" language="javascript" charset="utf-8">
@@ -219,6 +221,13 @@
assert(eventResults.windowLoad.contentLoaded,
"windowLoad.contentLoaded");
}},

+ testDocumentContentLoadedEventWaitsForStylesheetsToBeLoaded:
function() { with(this) {
+ if (document.location.port == 4711)
+ assert(eventResults.contentLoaded.externalStyleSheetLoaded);
+ else
+ info("This test must be used through WEBrick. Please run
'rake test_units'")
+ }},
+
testEventStopped: function() { with(this) {
var span = $("span"), event;

@@ -253,7 +262,8 @@
document.observe("dom:loaded", function(event) {
eventResults.contentLoaded = {
endOfDocument: eventResults.endOfDocument,
- windowLoad: eventResults.windowLoad
+ windowLoad: eventResults.windowLoad,
+ externalStyleSheetLoaded: $
('styleSheetTest').getStyle('position') == 'absolute'
};
});

Le 13 mars 08 à 07:52, Samuel Lebeau a écrit :

[Diego Perini]

Tobie,
I had a first look at Samuel patch and these are my
thoughts (I have a very low knowledge of Prototype):

- the stylesheets should be detected correctly, it
seems OK to me both in Webkit and Opera, I used a
"capturing" load event in Opera but that was just
my taste, a loop after DOMContentLoaded is enough,

- the IE part is missing the "onreadystatechange" event
and as I said that is probably the most important part,
a problem I see in Samuel patch being that the call to
fireContentLoadedEvent() is inside the try/catch block
and that will hide useful errors to developers, should
be moved down a couple of lines out of that try block,

- fixing the order of Events in IE requires more code,
building a hash of events requires making a copy of
them with slice() before entering the for loop, this
avoids problem when the hash grows or shrinks, this
will happen when you add/remove events from inside
other event handlers.

Hope to see the best implementation in Prototype.

Cheers

Diego

[Diego Perini]

Samuel,
on Opera the stylesheet fix is in some way documented
somewhere, just don't remember where...but the "disabled"
property seemed a good hook to me when I answered that post.

For the reasons about using the "onreadystatechange" event,
enable "Staus Bar" writing if you are using IE 7, and
then run this small code (IE only obviously):

[script type="text/javascript"]
document.onreadystatechange = function () {

if (this.readyState == 'complete') {

status += ' * ' + event.type;
}
};

window.onload = function () {
status += ' * ' + event.type;
};

(function () {
try {
document.documentElement.doScroll('left');
} catch(e) {
setTimeout(arguments.callee,0);
return;
}
status += ' * doScroll';
})();
[/script]

I used the status bar to log the event sequence
because the "alert()" will just obfuscate things.

If you look at the output of the above you will
see that my "doScroll" method will always fire
last, the first always being "readystatechange".

If you now insert an image in the above code or
make the page much longer, than "doScroll" will
fire as first instead. Not always though...

This is the reason the "onreadystatechange" method
used in combination is essential. Without it you
cannot ensure the "dom:loaded" will fire before
"onload" as various tickets already confirms.

And don't look to others implementation, I tried
hard to explain this to them too, unfortunately
english is not my native language so I may have
explained this wrong, or they have evidences
I am wrong but haven't show me where.

I may look a bit paranoid in adding this, nobody
write empty pages, it seems an edge case that will
never show up in real world, however, trust me a
page without images is enough to destroy our
expectations very soon. B/F buttons too.

The "IEContentLoaded" will help with many of these
"magic" IE situations, we just need to use all the
pieces, not just part of it.

Thank you for your time listening...cooperation is king.

Diego Perini

[Diego Perini]

Samuel / Tobie,

Don't know if everything was cleared in our latest conversations
or there are further doubts or problems implementing this.

I would like to know if something has stopped this and
if I can do something else on the subject.

Thank you.


Diego Perini

> > >>dom:loadedafter window.onload issue.

> > >>>>> The current pre-loadedjavascript is only for IE, but you

[Tobie Langel]

Hi Diego,

Thanks for your feedback.

Actually, yes, the move to git + lighthouse has slowed things down
quite a bit. And a couple of bug fixes in events slowed things even
more.

Afaik, JDD has a port of your patch in his own repositiory (http://
github.com/jdalton/prototype/tree/master/src/event.js).

Would you mind letting us know if it's fit for core ?

Thanks,

Tobie

[Diego Perini]

Tobie,
for now the following is the easy test that shows how previous version
of prototype where firing the "dom:loaded" event in the wrong order in
Internet Explorer, that was my main concern about, the version I could
"rake" up from "jdalton" git (with kind help from Samuel) did produce
correct results, here is the test:

<script type="text/javascript" src="prototype.js"></
script>
<script type="text/javascript">
/*
* these events will still be available to IE applications
* they are not affected, and will normally fire before
* listeners/observers
*/
if (Prototype.Browser.IE) {

document.onreadystatechange = function () {
if (this.readyState == 'complete') {

document.body.innerHTML += ' * ' + event.type + '<br />';

status += ' * ' + event.type;
}
};
}

window.onload = function (event) {
event = event || window.event;
document.body.innerHTML += ' * ' + event.type + '<br />';

status += ' * ' + event.type;
};

/*
* IEContentLoaded test (Prototype implementation)
*/
Event.observe(document, 'dom:loaded', function () {
document.body.innerHTML += ' * dom:loaded<br />';
status += ' * dom:loaded';
});
</script>

If you run this script "as is" in IE, or adding the bare minimum
required tags the result are the same, it seems browsers will add
these automatically for HTML files. You can also add as much text you
want to the file the result should remain the same, so the "size" of
the page does not affect the test while it is text only...as soon as
you add an image things changes and the order is OK even in previous
versions of prototype if used with IE for this task.

I say this because this is one of the reasons this behavior (and the
infamous IE "Operation Aborted") has remained hidden and seemed
unsolvable for so long time, another reason is that only lately we
have started to see an overload of these hooks, pages where probably
not so complex as today and they didn't need all that interaction.
Anyway I would like to stress this is not the only situation where we
need the "onreadystatechange" fall back. The setTimeout/setInterval is
often not enough alone in situations where the users press the
backward/forward buttons, the reload/refresh keys or access the same
functions by using buttons shortcuts or menu items. The
"onreadystatechange" is what saves us most of the time from these
cached hits.

One issue I am having with "jdalton" git sources is that I get an
extra "dataavailable" event along with the expected "load" event, by
looking at the sources I found this is deliberately done on all
":" (custom) events. I am going to believe you are actually
implementing the "force bubble" for events that does not normally
bubble...nice you added this capability.

Did I understand correctly the sources and the issue I am seeing ?
(createEvent/createEventObject/initEvent/fire/dispatchEvent) sounds ??

Thank you for explaining/expanding,

--
Diego Perini

[John-David Dalton]

Hi All,

I haven't read all the posts, but I have applied Samleb's patch which
uses the doScroll jQuery method and fixes the first-in-first-out
order.

I have also fixed the window onload triggering before dom:content
loaded and fixed the multiple window resize calls for IE.

I have tested the patch and it seems to work for me.
I have used it in my current applications without issue.

Using the doScroll approach seems to also fix the seemingly random IE7
fail with the current 1.6.0.2 implementation.

- JDD

[John-David Dalton]

[#9394] window "onload" executing before all of the "contentloaded"
observers are executed:
http://dev.rubyonrails.org/ticket/9394

Patch 1
http://github.com/jdalton/prototype/commit/4d4ca98fa6f8994b873984f1485c5b496fadecb8

Patch 2
http://github.com/jdalton/prototype/commit/038aca8ed75a65a3438ec52a4c2f93a5b1efaada

Patch 3
http://github.com/jdalton/prototype/commit/dada5cee7e8a959dee2ea82961981ee2261130a8

Unit Tests
http://github.com/jdalton/prototype/commit/527dc7ea92f98cff14b43153a4ac3500cee51527

Changelog
http://github.com/jdalton/prototype/commit/253332aec4c9e4a97630eeb2d3f8b367696fc24e

-- Also --

[LH#64] Safari now has DOMContentLoaded event, use it:
http://prototype.lighthouseapp.com/projects/8886/tickets/64-safari-now-has-domcontentloaded-event-use-it

Patch
http://github.com/jdalton/prototype/commit/1b7289aef2fc86dc584be83aa8717158c3e15fce

Changelog
http://github.com/jdalton/prototype/commit/c29474cd439d5c3b9766f7d9da7e07d1428794bc


I think jQuery handles the iframe issue via using "parent" or "top" or
something.
We should probably do the same (I am not familiar with the issue and
haven't had time to read up on it)

- JDD

[Nick Stakenburg]

> Using the doScroll approach seems to also fix the seemingly random IE7
fail with the current 1.6.0.2 implementation.

I see the IE Operation Aborted a lot. Using insert on document.body
throws it randomly, happens more often on pages with a script tag
right before the closing body tag, like when Google analytics is used.
Inserting to the top works however, so insert before firstChild works,
appendChild throws the operation aborted. The current implementation
isn't accurate enough.

Didn't investigate this further, switching to doScroll fixes it. Hope
it's something for 1.6.0.3.

---
Nick

On 11 mei, 06:20, John-David Dalton <John.David.Dal...@gmail.com>
wrote:

[John-David Dalton]

Nick,

A little OT (non-related to Prototype) but here is more info on your
issue of IE operation aborted.
I had to patch it for the PHP framework we use.

Fix IE "Operation Aborted" bug by inserting script elements at the
bottom of the body element.
http://www.ryangrant.net/archives/internet-explorer-cannot-open-the-internet-site-operation-aborted-google-map-api/
http://weblogs.asp.net/infinitiesloop/archive/2006/11/02/Dealing-with-IE-_2600_quot_3B00_Operation-Aborted_2600_quot_3B002E00_-Or_2C00_-how-to-Crash-IE.aspx

- JDD

[Nick Stakenburg]

Thanks John.

My point is that dom:loaded should ensure a successful appendChild on
document.body in all cases, not throwing the random IE Operating
Aborted. Using the scroll approach ensures this, it's more accurate
then the current implementation and will prevent having to use those
workarounds.


On 12 mei, 03:26, John-David Dalton <John.David.Dal...@gmail.com>
wrote:

> Nick,
>
> A little OT (non-related to Prototype) but here is more info on your
> issue of IE operation aborted.
> I had to patch it for the PHP framework we use.
>
> Fix IE "Operation Aborted" bug by inserting script elements at the

> bottom of the body element.http://www.ryangrant.net/archives/internet-explorer-cannot-open-the-i...http://weblogs.asp.net/infinitiesloop/archive/2006/11/02/Dealing-with...
>
> - JDD

[Diego Perini]

Nick,
happy to see the doScroll fit your needs too.

I also noticed in your previous message you said:

>Inserting to the top works however, so insert before firstChild works,

You did realize too that this is the most clean way when applicable,
adding widget to a page shouldn't require the use of a DOMReady
notification. Other situations requires that though.

I would add that, as currently is, on IE this method can be called
several time, even later on in the loading process, or even after
the window.onload event. It will always be able to check if the
DOM is ready and this is a bonus if for example "lazy loading"
is used. It can probably be used too with big DOM changes.

Thank you for your comments about my trick, hope it can
do for Protoype next version.


Diego Perini

On 12 Mag, 16:02, Nick Stakenburg <nickstakenb...@gmail.com> wrote:
> Thanks John.
>
> My point is that dom:loaded should ensure a successful appendChild on
> document.body in all cases, not throwing the random IE Operating
> Aborted. Using the scroll approach ensures this, it's more accurate
> then the current implementation and will prevent having to use those
> workarounds.
>
> On 12 mei, 03:26, John-David Dalton <John.David.Dal...@gmail.com>
> wrote:
>
> > Nick,
>
> > A little OT (non-related to Prototype) but here is more info on your
> > issue of IE operation aborted.
> > I had to patch it for the PHP framework we use.
>
> > Fix IE "Operation Aborted" bug by inserting script elements at the

> > bottom of the body element.http://www.ryangrant.net/archives/internet-explorer-cannot-open-the-i......
>
> > - JDD

[Diego Perini]

Tobie / Samuel,
this is the second test case I promised about the DOMContentLoaded
patch that Samuel kindly assembled. Since it is bigger than the
previous
test I prefer to temporarily publish the tests on my site:

http://javascript.nwbox.com/IEContentLoaded/prototype/tester.html
http://javascript.nwbox.com/IEContentLoaded/prototype/tester.php

You can grab a compressed archive of all the tests (including the
one I sent previously) here:

http://javascript.nwbox.com/IEContentLoaded/prototype/prototype-domloaded.tar.gz

Please let me know if there is something that should be commented,
your implementation of the doScroll technique is the most complete
and functional up to now.

It really take in consideration many more cases including
a nice fall back to "onreadystatechange" for iframes in IE.

Also I obviously vote for inclusion (if my vote is valid), I stress
that
somebody can explain me why I am getting back an event of type
"dataavailable" from an observer registered on "DOMContentLoaded".

--
Diego Perini


On 9 Mag, 04:09, Tobie Langel <tobie.lan...@gmail.com> wrote:

[John-David Dalton]

Diego Perini,

in IE "dom:loaded" is a custom event, custom event use the
"ondataaviable" event as a vessel to ride the event bubble and other
things.
that is why you see that. use event.eventName instead of
event.eventType.

- JDD

[John-David Dalton]

Added the following updates to the event system in my fork:

Fix issue with how IE wrappers.dispatcher"iterates over list of
wrappers:
http://github.com/jdalton/prototype/commit/bfa0ea8da441d53983dd4223248991b3329ab93f

Add unit tests for the wrapers.dispatcher fix :
http://github.com/jdalton/prototype/commit/2008f6afe2a92d023f557300e4475f70f5162ca6

Increase speed of wrappers.dispatcher() :
http://github.com/jdalton/prototype/commit/fb073dd6a24f0d8242cc7b402c76beaac25a4f3a

Add proceed variable to the arguments.callee.defer call in the
addEventDispatcher for the window "load" event:
http://github.com/jdalton/prototype/commit/de8bda109963bcd7b92e0d7a480c3954fc6c24b8

- JDD

[John-David Dalton]

I just looked through the code and realized we were handling the
IFrame issue :), thanks Diego for pointing that out :).

[Diego Perini]

John-David,
thank you for the short but effective explanation about that bit...


Diego Perini


On 12 Mag, 19:22, John-David Dalton <John.David.Dal...@gmail.com>
wrote:

[John-David Dalton]

Diego,

Is line 394 ok with a specific check for Opera?
http://github.com/jdalton/prototype/tree/master/src/event.js#L394
I heard Opera 9.5b doesn't have that issue (but I think that may be
getting to granular).
My main goal with the browser sniff is to avoid unnecessary iterations
of the dom on browsers that don't require that check.

Also is the stylesheet check needed for safari on line 422 as well?

Thanks,
JDD

[Diego Perini]

JD,
the Opera adjustment is probably a "miss-correction" by me originated
from this discussion thread:

http://groups.google.com/group/jquery-dev/browse_thread/thread/ad7e754c0a10f88a/

I said "miss-correction" mainly because the only current specification
I know about this is HTML5 which does not require style sheets to be
completely loaded to meet "DOMComplete" state in their specifications.

However developers meeting those flashy problems requested for a
solution in Opera.

After these test it has been added to Safari branch too in jQuery. I
am not sure newer Safari having native "DOMContentLoaded" (>=525) will
need that. I believe that check is good and will not make problem in
any browser, it will introduce few milliseconds delay for sure, so I
fully understand what you try to optimize...

I believe the last comment in the following related thread by
"liorean" says something too (having a separate CSSLoaded event):

http://my.opera.com/nicomen/blog/2007/07/08/domcontentloaded-gotcha-with-external-stylesheets

As you said we probably don't need this kind of "granularity".

Take a look at at the following small modification to line # 386:

if (timer) window.clearInterval(timer);

if (timer) timer=window.clearInterval(timer);

to "undefine" the cleared timer, I understand the previous line in the
code would protect this from happening but in the world of events I
learned the hard way to take precautions over certainty and started to
always be paranoid working with them...If you say we are forced to
trust all browsers are single-thread, we don't need that safeguard,
anyway I completely trust you can make the right choice.

I hope not to let you with more concerns than answers. My "tests" say
everything is working as it should for the "dom:loaded" part.


--
Diego Perini


On 13 Mag, 15:15, John-David Dalton <John.David.Dal...@gmail.com>
wrote:
> Diego,
>
> Is line 394 ok with a specific check for Opera?http://github.com/jdalton/prototype/tree/master/src/event.js#L394

[John-David Dalton]

Thanks Diego,

Good catch on the timeout, clearing the timer variable is probably the
right way to go :)
So maybe we I should remove the Opera check considering other browsers
may support the HTML 5 spec as well.

- JDD

[Diego Perini]

JD,
the Opera check should be considered a user feature request
to avoid the annoying flash in some situations. Since it does
not do any harm, I would leave it in to make users happy;
HTML5 specs leave that decision to implementors.

Later on, that part could be removed when it can be confirmed
that newer Opera versions have fixed that flashy behavior.
I haven't incurred much in that problem myself anyway.

--
Diego Perini


On 13 Mag, 19:50, John-David Dalton <John.David.Dal...@gmail.com>
wrote:

[John-David Dalton]

Ahh ok,
And Safari also shows this flashy behavior?

[Ken Snyder]

Diego Perini wrote:
> ...

>
> I believe the last comment in the following related thread by
> "liorean" says something too (having a separate CSSLoaded event):
>
> http://my.opera.com/nicomen/blog/2007/07/08/domcontentloaded-gotcha-with-external-stylesheets

> ...
+1 for a separate CSSLoaded event. I'm not seeing why dom:loaded should
have to have anything to do with external files. Not waiting for
external files seems like the whole point of using dom:loaded as opposed
to window onload.

[Diego Perini]

JD,
I currently use Safari but I never noticed those flash.

Seems both Safari and Konqueror use a different render engine
which is not affected by this small graphic annoyance.

Unfortunately I don't have a good test case for this behavior
and I don't have previous versions of Safari to try, newer
versions using "DOMContentLoaded" are probably waiting
for CSS too.

Also the color flashes you may have seen in the in the second test
case I have linked above is something that is part of the test itself.
There should be no flash on IE out of these tests.

The above tests where originally designed for the IE problem, lately
I converted them to be somehow useful for other browsers too.

--
Diego Perini


On 13 Mag, 23:02, John-David Dalton <John.David.Dal...@gmail.com>
wrote:

[Diego Perini]

Ken,

On 14 Mag, 00:23, Ken Snyder <kendsny...@gmail.com> wrote:
> Diego Perini wrote:
> > ...
>
> > I believe the last comment in the following related thread by
> > "liorean" says something too (having a separate CSSLoaded event):
>

> >http://my.opera.com/nicomen/blog/2007/07/08/domcontentloaded-gotcha-w...

> > ...
>
> +1 for a separate CSSLoaded event. I'm not seeing why dom:loaded should
> have to have anything to do with external files. Not waiting for
> external files seems like the whole point of using dom:loaded as opposed
> to window onload.

I have to agree with you...

Good points, but limited to the specs, we should balance a bit and
remember
our user base too. Specifications set the guide lines and just impose
some
requirements, it was not in their intentions to limit our intents into
solving
issues we may encounter.

Having a separate "CSSLoaded" requires a cross-browser implementation,
it may be easy but I haven't investigated further out of Safari /
Opera,
the "disabled" property of style sheets should exists in all browsers,
what scares me a bit are the difference with which a stylesheet
may be implemented: in-line style, LINKed style, @import...

Remember that the main issue and bugs here are IE related,
the rest are just extra bonus worth a look while we are at it.

--
Diego Perini

[John-David Dalton]

I think that the css:loaded would probably be the best way to go so it
doesnt delay the dom:loaded event
Opera uses the "disabled" approach (what if a style sheet it set to
disabled in the html though?)
and Safar used the "length" approach.

The length approach may cause issues with "import" as this test page
points out (the length is reported as 5 (because of the import) and
there are only 4 stylesheet elements
http://www.quirksmode.org/dom/tests/stylesheets.html

- JDD

[Diego Perini]

Too many combinations, probably better split that CSSLoaded.

I asked Mark Wubben of sIFR to comment here, he may have
much more experience with this specific graphic lag and may
give more bits about Safari/Opera still needing this or not.

--
Diego Perini


On 14 Mag, 19:57, John-David Dalton <John.David.Dal...@gmail.com>
wrote:

[Diego Perini]

Ok,
Mark answered to me directly, here is what he says about
his experience with this stylesheet related behavior in sIFR:

>On Tue, May 20, 2008 at 11:17 AM, Mark Wubben <ma...@novemberborn.net> wrote:
> No idea about v1x, but Safari 2 and 3 load CSS and JavaScript in parallel
> (<link> and <script> elements are not blocking the parsing of the document).
> This means that the DOM could be finished before the CSS is loaded. The
> trick I use in sIFR is to poll for a certain style property on an element I
> inject into the document. This, of course, does require one to place that
> property in the correct stylesheet.
>

So relying on external stylesheets being loaded seems risky
and to stay cross-browser I would leave that to a specific method
if one can be found.

My method to detect stylesheets are already loaded in Opera
was based on events by using the "load" event capture phase,
this is different from how it was later implemented in jQuery,
were a setTimeout has been used instead, then the same
was applied to Safari too.

To resume, I believe the best is leave stylesheet detection out
of "dom:loaded" (as some already suggested) and just hope one
day all browser will agree on that.

Actually the fix that was needed was to ensure "dom:loaded"
fires before the "onload" event in all browser without throwing
the "Operation aborted" on IE.


--
Diego Perini

[Diego Perini]

JDD,
just a minimal note...more of a remember.

I had a look back to your git sources and
if it is still considered applicable I noticed
that the "timer" variable is not yet cleared,
and since you seemed to agree...

--
Diego Perini

On 13 Mag, 19:50, John-David Dalton <John.David.Dal...@gmail.com>
wrote: