Hey, I can't believe this thread is so long... There's just no way we won't extend prototypes on elements, I think. It's at the core of what we do.
Andrew Red a écrit : > Now, what I understand about "F.SpecificElementExtensions", it doesn't > necessarily return the right value when it should. That's the fact. Sounds weird, and you're welcome to submit a reproduceable case and the matching tested patch to the Trac. > Then, second question, what I understand about $$(), it returns a > plain array with unextended elements (if IE is used, for instance). Is Actually this is incorrect. $$ branches out to either the browser's native DOM Level 3 XPath support or its internal matcher. Both do return actual JS arrays. If in the former case, it doesn't bother extending the results, because it doesn't need to: DOM 3 XPath is supported only on browsers (Opera, FF, WebKit) that happen to feature HTMLElement.prototype, so we're pretty much in the clear: the only sore point you might hit is tag-specific extensions on Opera, which would require an extra $ call. In the latter case (custom JS matcher), elements are extended as their internal duplicates are filtered out, in Selector.handlers.unique. So all extensions, be they generic or tag-specific, are guaranteed. This applies in MSIE and Safari, and only causes delay in MSIE (if your $$ resultset is very large). 'HTH -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" 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/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
