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


On 13 Mar, 20:53, Diego Perini <[EMAIL PROTECTED]> wrote:
> 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
>
> On 13 Mar, 07:52, Samuel Lebeau <[EMAIL PROTECTED]> wrote:
>
> > 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 :
>
> > > 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
>
> > > On Mar 13, 1:24 am, Samuel Lebeau <[EMAIL PROTECTED]> wrote:
> > >> I attached a patch (http://dev.rubyonrails.org/ticket/9394) that
> > >> fixes
> > >> IE event handlers calling order (ensure FIFO) and tends to fix
> > >>dom:loadedafter 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 actuallyloaded.
> > >> 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,
> > >>> 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/ad7e75
> > >>> ...
>
> > >>> 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
>
> > >>> On 25 Feb, 07:37, Tobie Langel <[EMAIL PROTECTED]> wrote:
> > >>>> 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
>
> > >>>> On Feb 25, 4:21 am, Diego Perini <[EMAIL PROTECTED]> wrote:
>
> > >>>>> 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-loadedjavascript 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to