Don't use 1.49mb large GIF animations as background images...
co;dr = cpu overheated; didn't read
I'd also like to see some benchmarks to back up the assertion that this is faster. The DOM modification events are generally accepted as slow and it seems like this is leaving a handler attached for the duration of the page's existence.
I used this a lot when developing a Chrome extension for Facebook because i can identify when an HTML element is created via ajax.
You can do $(document).ready(), why not, the admittedly syntax sugared, $("div#main").ready().
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMNodeI...
They have been deprecated because they perform poorly:
> Firefox, for example, when it realizes that a mutation event has been turned on, instantly goes into an incredibly-slow code path where it has to fire events at every single DOM modification. This means that doing something like .innerHTML = "foo" where it wipes out 1000 elements would fire, at least 1000 + 1 events (1000 removal events, 1 addition event).
http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0072....
> Mutation Events are widely acknowledged as “slow” in terms of the real performance degradation that occurs on websites that use them heavily for tracking changes to the DOM
You say it’s faster, but fail to provide any numbers / a jsPerf test case. I’m sure it’s faster to execute `waituntilexists()` initially, but if you take into account it uses an 5ms interval in which it traverses the DOM for the same elements over and over again until they’re finally found, it seems it probably has a negative impact on performance overall.
What’s wrong with event delegation anyway?
It uses getElementById to traverse the DOM and it is said to be the faster selector in javascript.
But your code should be faster -because you are polling at the 5ms interval!
* I could test it myself, but I expected to have in the article detailed information on the different possible states the document can have when my callback is called. The questions I know the answer when waiting for the whole document to be loaded : Is it half loaded ? What is the DOM state ? Is completely loaded ? If not, have the document JavaScript code been entirely ran ? and so on. This kind of question left unanswered often lead to hard bites.
* why using "itself" ? I would have used a "sensible default" : when no context is given, use the waited DOM object instead of an arbitrary value (document), and use something else when it is explicitly given. The "itself" thing should be left as an internal flag IMHO.
2) When i am writing javascript is very common for me to use the global object (window) as the context; so in my case is not a good idea to use the HTML element as context by default.
I'd like to know if there is any performance hit though, NodeInserted fires on basically on every single fraction of page creation.
/Cufon.DOM.ready(function() {/ /$(window).load(function () {/ /$(document).ready(function() {/ /Cufon.DOM.ready(function() {/
And now is 40% faster
