A little status report. On Wed, Oct 8, 2008 at 18:07, Per Cederberg <[EMAIL PROTECTED]> wrote: > What I was trying to say is that if querySelectorAll returns a result > that is inconsistent with the JS implementation, then we're in > trouble. If it throws an error (as it presumably does when using > non-standard stuff), we already fallback to the JS-implementation, so > that should work.
Ah yes. Right, the fallback seems to work. The problem on Safari was indeed that it returns a NodeList object but is treated as an array. I simply added a call to convert it to an array. As for the incorrectness in the current MochiKit.Selector module in trunk, these are the tests in the SlickSpeed benchmark that fail or return an incorrect number of elements: div p MK trunk returns 142 elements while others return 140 (both numbers are reported incorrect though). The *set* of elements is the same, but MK repeats some elements, which is of course not correct. This seems to happen in the situation where one has <div><div><p>...</p></div></div>. If one forgets about performance, this is trivial to fix in MK - but a reasonably performing one might be more tricky. div ~ p MK returns 4120 (!) elements here where others return 183 (both numbers are again considered wrong by SlickSpeed). This is clearly a bug div, p, a div.example, div.note This fails in MK trunk, and rightly so, as it does not support multiple selectors in one string. Multiple selectors should be passed by using an array argument to findDocElements. h1[id]:contains(Selectors) This fails, as :contains(..) is not supported. p:contains(selectors) This returns an invalid number of elements (presumably all p elements) since :contains is not selected. Prototype has the same behavior p:nth-child(2n) This fails as 2n is not recognized, should be easy to fix (just interpret as 2n+0). p:nth-child(n) Fails, and frankly I don't understand the reasoning here (what does this mean?). Should be interpreted as (1n+0) I guess. p:only-child returns wrong number of results, but then again - so do all the others. Perhaps SlickSpeed is incorrect (the empty string) Fails with an error, which I think is better than returning all elements as some libraries do. Could be handled as a special case but I don't see the need. cheers, Arnar --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
