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 [EMAIL PROTECTED]
wrote:
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 [EMAIL PROTECTED] wrote:
No idea about v1x, but Safari 2 and 3 load CSS and JavaScript in parallel
(link and script
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
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,
thank you for the short but effective explanation about that bit...
Diego Perini
On 12 Mag, 19:22, John-David Dalton [EMAIL PROTECTED]
wrote:
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
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
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
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
--~--~-~--~~~---~--~~
You received this
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
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
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,
Ken,
On 14 Mag, 00:23, Ken Snyder [EMAIL PROTECTED] 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...
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
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
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
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
--~--~-~--~~~---~--~~
You received
Added the following updates to the event system in my fork:
Fix issue with how IE wrappers.dispatcheriterates over list of
wrappers:
http://github.com/jdalton/prototype/commit/bfa0ea8da441d53983dd4223248991b3329ab93f
Add unit tests for the wrapers.dispatcher fix :
I just looked through the code and realized we were handling the
IFrame issue :), thanks Diego for pointing that out :).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group,
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
[#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
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
21 matches
Mail list logo
