You forgot the evil bwhahaha laugh! :)
On May 26, 4:16 pm, Rolf -nl <[email protected]> wrote: > I see it now yes (in the source), the 'doc' is the context for Slick. > Maybe for the upcoming Moo World Domination they can use Slick to find > all non-believers and not use a browsers' document as the context but > simple insert 'world' > you know. evil sh*t > > On May 26, 4:16 am, robdb <[email protected]> wrote: > > > > > > > > > Or if you know the element is already extended or it doesn’t matter if > > the elements extended or not, the ‘true’ skips running the tests to > > see whether or not the element is extended, as well as skipping the > > actual extending of the element. Again there's probably more to it one > > of the mootoolians could extend this out??... > > > Sorry for the double post.. > > > On May 26, 12:04 pm, robdb <[email protected]> wrote: > > > > 100% Rolf, definitely always going to be an over head from a library. > > > The reason why I included the last two tests are that I was > > > interested in what the overhead is/was and I hadn't used jsperf before > > > so I maybe got a little excited :) It was a flawed test anyhow, it > > > destroyed an element every execution where as the others didn't. The > > > last 2 tests were just play, the createTextNode and docFrag where the > > > test more of interest (and fairer). Can't remember the last time I > > > injected 25 thousand new elements into an element :) > > > > Pretty sure the 'true' allows document.id to return an element that > > > hasn't been extended with the Mootool's Element methods (defaults > > > falsy). There's a third argument 'doc' as well, that allows you to > > > specify a different 'document' to reference. Is there more to it > > > mootools? :) > > > > On May 26, 7:36 am, Rolf -nl <[email protected]> wrote: > > > > > btw a bit OT, but what does the true do in document.id(var, true)? I > > > > didn't see it in the documentation and I can't find it in the source > > > > (I see/saw it being used in the source multiple times, but couldn't > > > > trace it back quickly enough) > > > > > On May 25, 11:14 pm, Rolf -nl <[email protected]> wrote: > > > > > > So with the documentFragment and createTextNode are almost as fast, > > > > > but the documentFragment is better used if you want to insert more > > > > > than one nodes (before/after) some element. Of course you could also > > > > > check with if it matters if the to-be-inserted nodes are just > > > > > textnodes or a bit more than that. > > > > > > I remember some earlier threads about jsperf though > > > > > (eg.http://groups.google.com/group/mootools-users/browse_thread/thread/bd...) > > > > > so comparing the inject/destroy vs two mentioned before is not really > > > > > a good comparison probably (I mean comparing the vanilla js with the > > > > > moo-methods is a bit "silly") > > > > > > On May 25, 3:33 pm, robdb <[email protected]> wrote: > > > > > > > Out of interest, put the above methods into jsperf. Plus a > > > > > > 'createTextNode' method clone without caching the $$ function, > > > > > > always > > > > > > going to be slower, little surprised by how much though. Apparently > > > > > > IE6 (under a virtual machine) performs better than Opera 11.10 apart > > > > > > from the Inject-Destroy method where it failed with the ol 'Object > > > > > > does not support this prop or method'. > > > > > > Didn't include the fiddle I put up previously, compared to the > > > > > > documentFragment and createTextNodemethods, it was sluggish (and > > > > > > very > > > > > > 2am not awsome...), always a little slower than 'Inject-Destroy'. > > > > > > >http://jsperf.com/docfrag-textnode-insertion > > > > > > > On May 25, 6:37 pm, Rolf -nl <[email protected]> wrote: > > > > > > > > of course, you're right > > > > > > > > On May 24, 10:51 pm, Michael Russell <[email protected]> > > > > > > > wrote: > > > > > > > > > you really don't need a fragment for that. > > > > > > > > > this: > > > > > > > > > var elements = $$('span'); > > > > > > > > elements.each(function(elm){ > > > > > > > > var fragment = document.createDocumentFragment(); > > > > > > > > fragment.appendChild(document.createTextNode('X')); > > > > > > > > elm.parentNode.insertBefore(fragment, elm.nextSibling); > > > > > > > > > }); > > > > > > > > > could just be: > > > > > > > > > var elements = $$('span'); > > > > > > > > elements.each(function(elm){ > > > > > > > > var txtNode = document.createTextNode('X') > > > > > > > > elm.parentNode.insertBefore(txtNode, elm.nextSibling); > > > > > > > > > }); > > > > > > > > > Fragments are really nice when you don't want to inject a > > > > > > > > wrapper element > > > > > > > > but want to insert n+1 nodes into the DOM. Using it will cause > > > > > > > > the browser > > > > > > > > to only re[paint/structure] the DOM once when injecting them > > > > > > > > instead of on > > > > > > > > each iteration of your elements array
