Hmm, thanks. On Aug 2, 5:07 pm, Christophe Porteneuve <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
