This is a problem for example when trying to collect text in different elements. The texts will not be in the original document order, they will be randomly ordered. It will also be difficult to build test units.

Another reason they are fast is the kind of check they do is really minimal. An example “nodeName” could be lower or upper case, or “className” can contain white-spaces (LF and CR too), or elements ID in FORMS may be easily overwritten by bad HTML code.

However I would very like have James lend me his optimizations. :-)

Good job James, keep up improving your code.

I have also disabled caching in IE.

Is maintaining a cache worth the reduction in DOM mutation speed?

@LeoHorie:
Sorry about that. I noticed that I had no comments there, just thought they were all coming here:) It is a brand new blog, I will look into this and fix it. Thanks for your comments though!

@LeoHorie, @rizqi, @TNO:
Great thought, however @TNO is right innerHTML is not very performant and unfortunately takes so much time that it would be faster (in most cases) to not use caching at all.

@JohnResig:
response to #2: Thank you for making me aware of this. I obviously was a bit naive with respect to licensing and how this works in the Open Source community. Since, I had modified the code and provided reference to your original source I incorrectly thought that was enough. I will add your copyright to these two sections of code. Is this ok?

response to #3: I made some last minute optimizations, just prior to releasing, and apparently this broke some things in Opera, and Safari. Currently the release fails 9 tests in Safari, and 3 tests in opera. I am planning another release that will address these bugs as well as the caching issue for IE on Saturday or Sunday.

Take aways for me are:
- That I should never introduce and release optimizations or otherwise without testing again in all browsers (I already know this, however I was in a whirlwind of excitement to release and unfortunately compromised this important development principle).

- The test suite should contain some dynamic DOM changes, this would have uncovered the IE caching issue for me earlier.

@Everyone: Thanks for all of the posts and interest! Already the feedback has been more than I had hoped for and Peppy will be much better for it.

As for the cache invalidation, there was a question on StackOverflow related to it and one of the ideas that popped up was to check the onpropertychange event in IE. Have you guys (John/James) or anyone else tried playing with that?

Either this document has some issues with the english language, or, it’s just as stupid as it reads.

1) Unfortunately that doesn’t work as you would expect it to. Imagine a div that contains a single bold element – then you do this: div.innerHTML = “foo“; (that should be an italic element). This won’t effect the * length. Currently there is no way to construct a reliable caching behavior in IE. If someone finds a technique then I’d love to hear about it.

2) That’s fine – glad to see that you’ve picked the BSD license, as well! I wasn’t trying to bit nitpicky, but it’s something good to be aware of when writing and releasing open source code. (As far as the specific code goes I was referring to the two portions at the bottom of the code base.)

3) That’s great to hear about the test suite, as well! A quick run shows it passing in Firefox 3 but failures popping up in Safari 3.1, WebKit nightly, and in Opera 9.5 (just the browsers that I had on hand).

@heswell: Well, Sizzle isn’t released yet. Hence the large “—- It’s a work in progress! Not ready for use yet! —-” notice – although I’ll be releasing it under the MIT license once it’s complete.