On 23 Giu, 20:39, "Ariel Flesler" <afles...@gmail.com> wrote:
> > > > .imagesReady()
> > > The only way to achieve this would be to bind an onload event to every
> > > single image on the page (including ones including in stylesheets?) -
> > > this isn't needed. Overwhelmingly "image ready" corresponds to
> > > $(window).load();
> > In Opera this is not necessary for example, you can setup a
> > mini "delegation" of the "load" event on images like this:
> > document.addEventListener('load', fn, true);
> I don't understand... imagesReady is equal to window.onload, why worrying
> about each image's load event ?
In the same way as for images, in Opera, when a style is loaded
it will trigger a "load" event on the document. So having this
capability can avoid using the much hated setTimeout
and will give the browser more time to render.
Unfortunately this expected (to me) behavior is only offered by Opera
to my knowledge. There were talks about Safari also supporting that
capturing bit on "load" events but I haven't tested it lately.
> > Delegation friends...delegation is the key, this is like CSS does.
> What do you mean ? I don't know much about the CSS engine, in what way does
> it use delegation ?
> While I agree that delegation is THE way, I don't see the application to
> this matter.
> Cheers Diego
CSS is a way of pre-declaring properties values that will be
applied to a set of elements matching the selector declaration.
Delegation is a way of pre-declaring behavior that will be
applied to a set of elements matching the selector declaration.
In both cases it is not mandatory the elements exists at the time
those declarations are parsed. They will be applied in-time as
soon as the elements are loaded or later inserted in the DOM.
If we can ensure the width/height of the element are read inside
a delegated handler we also ensure no events can be generated
on that element until the element is completely rendered.
This avoids accessing non existing elements/properties and the
errors generated in those cases,
On Sun, Jun 22, 2008 at 11:16 PM, John Resig <jere...@gmail.com> wrote: > IMO - I think we should "morph" document ready into being completely > safe (even if it is, potentially, late) - firing after all stylesheets > are loaded.
> Additionally we should provide the old "document ready" functionality > (maybe something like $(document).early(...)) that fires right when > the DOM is ready. We'll continue to promote the use of document ready > (it being the safest and easiest way to achieve your desired result) > while providing information on early for advanced users.
Hi John (and all),
Thanks for the responses. From a users point of view the above functionality would be great & would tie in with the way the rest of jQuery "just works" without having to know the intimate details of how different browsers run javascript.
Let me know if you need more information about how this defect affects real world applications.
To me it makes the most sense if document ready will wait for
stylesheets, as it seems counter-intuitive (especially to new users!)
that many of the jquery functions will not work correctly on document
ready when they should return dimensions and such. I'm not a
marketeer, but I think even from this point of view it will be good
for jquery as a major library to 'just work'. I can imagine there's a
lot of jobs (for more advanced users!) which are useful to execute on
DOM ready, restricting oneselves to operations not requiring CSS to be
loaded, for instance. For that I'd propose (which is done earlier,
IIRC) to add:
$.domReady
We then have "document ready", "dom ready" and "window load". This
seems adequite to me, even in the light of the above discussion. Above
all, this won't break any existing code (quite the opposite) against a
slight performance loss on those browsers which fire dom ready before
CSS is loaded.
Most important is that, whatever decision will be made, document ready
will behave exactly in the same way (from the outside) in all
supported browsers.
John,
I noticed that by moving the "LINK" tag before the scripts
will let the example work in both FF3 and Safari 3.1.
I mean in both browser I get correct with / height.
Is this something that can help solve this problem
flickering and FOUC ?
--
Diego Perini
On 23 Giu, 19:19, "John Resig" <jere...@gmail.com> wrote:
> There's no point in this - scripts execute synchronously - you could
> just do setTimeout(..., 1); to get the same effect.
> > .imagesReady()
> The only way to achieve this would be to bind an onload event to every
> single image on the page (including ones including in stylesheets?) -
> this isn't needed. Overwhelmingly "image ready" corresponds to
> $(window).load();
> > Forcing .ready() to also include a check for style is dangerous and
> > will slowdown the initialization.
> How do you mean? We already do this in Opera and Safari - and we have
> to start doing it (or something similar) for Firefox 3. All three of
> them no longer wait until stylesheets are loaded before firing the
> event.
Actually, it probably is - that's a good discovery, Diego. Can you check and see how it works in Opera, as well? If this works then we can simply specify that the JavaScript be included after the stylesheets, if you want to access their styles.
On Tue, Jun 24, 2008 at 11:13 AM, Diego Perini <diego.per...@gmail.com> wrote:
> John, > I noticed that by moving the "LINK" tag before the scripts > will let the example work in both FF3 and Safari 3.1. > I mean in both browser I get correct with / height.
> Is this something that can help solve this problem > flickering and FOUC ?
>> There's no point in this - scripts execute synchronously - you could >> just do setTimeout(..., 1); to get the same effect.
>> > .imagesReady()
>> The only way to achieve this would be to bind an onload event to every >> single image on the page (including ones including in stylesheets?) - >> this isn't needed. Overwhelmingly "image ready" corresponds to >> $(window).load();
>> > Forcing .ready() to also include a check for style is dangerous and >> > will slowdown the initialization.
>> How do you mean? We already do this in Opera and Safari - and we have >> to start doing it (or something similar) for Firefox 3. All three of >> them no longer wait until stylesheets are loaded before firing the >> event.
The other thing to notice is that nearly all browsers except IE
have events for the iframes on the main document, and I
believe there is a reason for their existence:
document.addEventListener('DOMFrameContentLoaded', fn, false); //
maybe true instead of false ??
I will do more tests as I am back, anyway the fact that this
behavior is user tunable may give us a chance of succeeding,
at least with some extra docs explaining this.
--
Diego Perini
On 24 Giu, 18:22, "John Resig" <jere...@gmail.com> wrote:
> Actually, it probably is - that's a good discovery, Diego. Can you
> check and see how it works in Opera, as well? If this works then we
> can simply specify that the JavaScript be included after the
> stylesheets, if you want to access their styles.
> --John
> On Tue, Jun 24, 2008 at 11:13 AM, Diego Perini <diego.per...@gmail.com> wrote:
> > John,
> > I noticed that by moving the "LINK" tag before the scripts
> > will let the example work in both FF3 and Safari 3.1.
> > I mean in both browser I get correct with / height.
> > Is this something that can help solve this problem
> > flickering and FOUC ?
> >> There's no point in this - scripts execute synchronously - you could
> >> just do setTimeout(..., 1); to get the same effect.
> >> > .imagesReady()
> >> The only way to achieve this would be to bind an onload event to every
> >> single image on the page (including ones including in stylesheets?) -
> >> this isn't needed. Overwhelmingly "image ready" corresponds to
> >> $(window).load();
> >> > Forcing .ready() to also include a check for style is dangerous and
> >> > will slowdown the initialization.
> >> How do you mean? We already do this in Opera and Safari - and we have
> >> to start doing it (or something similar) for Firefox 3. All three of
> >> them no longer wait until stylesheets are loaded before firing the
> >> event.
Diego Perini wrote: > I noticed that by moving the "LINK" tag before the scripts > will let the example work in both FF3 and Safari 3.1.
With the talk of resource loading, Steve Souders' recent IO talk (and the cuzillion tool) might be enlightening. It covers several script loading methods and how css (and inline script) placement affects loading and synchronicity.
This is a great find. It seems to fix my problems here in Safari. I
feel like an idiot to never have thought of this before... It still
seems like an unreasonable demand to ask people to change their markup
for things to work properly, but at least I don't need to nasty $
(window).load 'fix' anymore.
Cheers!
On Jun 24, 4:13 pm, Diego Perini <diego.per...@gmail.com> wrote:
> John,
> I noticed that by moving the "LINK" tag before the scripts
> will let the example work in both FF3 and Safari 3.1.
> I mean in both browser I get correct with / height.
> Is this something that can help solve this problem
> flickering and FOUC ?
> --
> Diego Perini
> On 23 Giu, 19:19, "John Resig" <jere...@gmail.com> wrote:
> > > .scriptsReady()
> > There's no point in this - scripts execute synchronously - you could
> > just do setTimeout(..., 1); to get the same effect.
> > > .imagesReady()
> > The only way to achieve this would be to bind an onload event to every
> > single image on the page (including ones including in stylesheets?) -
> > this isn't needed. Overwhelmingly "image ready" corresponds to
> > $(window).load();
> > > Forcing .ready() to also include a check for style is dangerous and
> > > will slowdown the initialization.
> > How do you mean? We already do this in Opera and Safari - and we have
> > to start doing it (or something similar) for Firefox 3. All three of
> > them no longer wait until stylesheets are loaded before firing the
> > event.
Just noticing this thread, but I can confirm this behavior. Dijit has made it a recommended "best practice" to put styles above script to eliminate what we describe as our 'css race condition'. Initially, it seemed related to embedded @import rules in CSS (themes) ... It seemed to only effect Safari, but at the time we'd adopted the 'fix' FF3 hadn't been released. And while it may seem unreasonable to ask people to change their markup, the problem is real, and browser related, and only effects a small subset of use cases (I suspect jQuery UI will want to take note here too, Paul?) where components are dependent on having calculated styles available. It is a trivial workaround, and probably not worth the additional timers or polling / etc. Documenting the issue with an explanation as to why would be sufficient, imho.
> This is a great find. It seems to fix my problems here in Safari. I > feel like an idiot to never have thought of this before... It still > seems like an unreasonable demand to ask people to change their markup > for things to work properly, but at least I don't need to nasty $ > (window).load 'fix' anymore.
> Cheers!
> On Jun 24, 4:13 pm, Diego Perini <diego.per...@gmail.com> wrote:
>> John, >> I noticed that by moving the "LINK" tag before the scripts >> will let the example work in both FF3 and Safari 3.1. >> I mean in both browser I get correct with / height.
>> Is this something that can help solve this problem >> flickering and FOUC ?
>> -- >> Diego Perini
>> On 23 Giu, 19:19, "John Resig" <jere...@gmail.com> wrote:
>>>> .scriptsReady()
>>> There's no point in this - scripts execute synchronously - you could >>> just do setTimeout(..., 1); to get the same effect.
>>>> .imagesReady()
>>> The only way to achieve this would be to bind an onload event to every >>> single image on the page (including ones including in stylesheets?) - >>> this isn't needed. Overwhelmingly "image ready" corresponds to >>> $(window).load();
>>>> Forcing .ready() to also include a check for style is dangerous and >>>> will slowdown the initialization.
>>> How do you mean? We already do this in Opera and Safari - and we have >>> to start doing it (or something similar) for Firefox 3. All three of >>> them no longer wait until stylesheets are loaded before firing the >>> event.
Thanks for chiming in Peter. I think this will be a good thing to set forward for people to follow. We generally don't like to dictate the markup of a document but this is a case it would seem that the overhead (and the fact that we generally won't be able to manipulate the document prior to it being displayed).
On Wed, Jun 25, 2008 at 8:23 AM, Peter Higgins <phigg...@gmail.com> wrote:
> Just noticing this thread, but I can confirm this behavior. Dijit has > made it a recommended "best practice" to put styles above script to > eliminate what we describe as our 'css race condition'. Initially, it > seemed related to embedded @import rules in CSS (themes) ... It seemed > to only effect Safari, but at the time we'd adopted the 'fix' FF3 hadn't > been released. And while it may seem unreasonable to ask people to > change their markup, the problem is real, and browser related, and only > effects a small subset of use cases (I suspect jQuery UI will want to > take note here too, Paul?) where components are dependent on having > calculated styles available. It is a trivial workaround, and probably > not worth the additional timers or polling / etc. Documenting the issue > with an explanation as to why would be sufficient, imho.
> Regards, > Peter Higgins
> Yereth wrote: >> Diego,
>> This is a great find. It seems to fix my problems here in Safari. I >> feel like an idiot to never have thought of this before... It still >> seems like an unreasonable demand to ask people to change their markup >> for things to work properly, but at least I don't need to nasty $ >> (window).load 'fix' anymore.
>> Cheers!
>> On Jun 24, 4:13 pm, Diego Perini <diego.per...@gmail.com> wrote:
>>> John, >>> I noticed that by moving the "LINK" tag before the scripts >>> will let the example work in both FF3 and Safari 3.1. >>> I mean in both browser I get correct with / height.
>>> Is this something that can help solve this problem >>> flickering and FOUC ?
>>> -- >>> Diego Perini
>>> On 23 Giu, 19:19, "John Resig" <jere...@gmail.com> wrote:
>>>>> .scriptsReady()
>>>> There's no point in this - scripts execute synchronously - you could >>>> just do setTimeout(..., 1); to get the same effect.
>>>>> .imagesReady()
>>>> The only way to achieve this would be to bind an onload event to every >>>> single image on the page (including ones including in stylesheets?) - >>>> this isn't needed. Overwhelmingly "image ready" corresponds to >>>> $(window).load();
>>>>> Forcing .ready() to also include a check for style is dangerous and >>>>> will slowdown the initialization.
>>>> How do you mean? We already do this in Opera and Safari - and we have >>>> to start doing it (or something similar) for Firefox 3. All three of >>>> them no longer wait until stylesheets are loaded before firing the >>>> event.
John,
I could only test Opera 9.27 currently and I get the same results,
no way to test 9.5 now but believe this has not changed in Opera,
having styles before scripts let's Opera correctly read the
width and height of the elements.
For me it is an expected behavior, the order we use to define
the style is also the order in which the browsers applies them,
and the order in which we should read style properties have
to follow this, we can read style only after having set it.
It wasn't that obvious initially but it is much clearer now.
--
Diego Perini
On 24 Giu, 18:22, "John Resig" <jere...@gmail.com> wrote:
> Actually, it probably is - that's a good discovery, Diego. Can you
> check and see how it works in Opera, as well? If this works then we
> can simply specify that the JavaScript be included after the
> stylesheets, if you want to access their styles.
> --John
> On Tue, Jun 24, 2008 at 11:13 AM, Diego Perini <diego.per...@gmail.com> wrote:
> > John,
> > I noticed that by moving the "LINK" tag before the scripts
> > will let the example work in both FF3 and Safari 3.1.
> > I mean in both browser I get correct with / height.
> > Is this something that can help solve this problem
> > flickering and FOUC ?
> >> There's no point in this - scripts execute synchronously - you could
> >> just do setTimeout(..., 1); to get the same effect.
> >> > .imagesReady()
> >> The only way to achieve this would be to bind an onload event to every
> >> single image on the page (including ones including in stylesheets?) -
> >> this isn't needed. Overwhelmingly "image ready" corresponds to
> >> $(window).load();
> >> > Forcing .ready() to also include a check for style is dangerous and
> >> > will slowdown the initialization.
> >> How do you mean? We already do this in Opera and Safari - and we have
> >> to start doing it (or something similar) for Firefox 3. All three of
> >> them no longer wait until stylesheets are loaded before firing the
> >> event.
> I could only test Opera 9.27 currently and I get the same results, > no way to test 9.5 now but believe this has not changed in Opera, > having styles before scripts let's Opera correctly read the > width and height of the elements.
Apart from $(window).height() (and .width(), probably). In 9.5 that returns the height of the document, not the viewport. That's probably a different issue though :)
