The docs say all that is needed: "By default, if no context is specified, $() looks for DOM elements within the context of the current HTML document. If you do specify a context, such as a DOM element or jQuery object, the expression will be matched against the contents of that context."
The speed difference I mentioned is insignificant for most jQuery users, you'll start optimizing other stuff way before that. I don't understand what you're arguing either, there is no sensible reason to enforce the context argument. Everyone can see that it's the "current HTML document" by default, and it's expected behavior. "Ah yes, and jQ "next" needs to stop the abundance of $(selector) calls, and enforce $(selector, scope ) calls." Why, what's the advantage? Performance is not always better, and that would bloat code a lot, why would you want to type 'document' over and over? "introduce selection scoping" - what would that be? $(selector).find (stuff) is already supported. jQuery is constantly optimized for every possible use case, not just "well balanced" DOM trees. Guaranteeing that is beyond the grasp of a JS framework, good development practices should be left out of the documentation. cheers, - ricardo On Mar 30, 4:33 am, DBJDBJ <dbj...@gmail.com> wrote: > @Thanks Ricardo, this is actually very on the topic ;o) > > I do not understand what is beiong argued here? If anything ? My > assertions are certainly not "horrible lies"? I knew this speed > difference , (and Daniel should know by now ...) > > We just need jQ "next" to sort out the lack of explanation in the > docs, arround context. > And to introduce selection scoping > And to support the explanations with examples of well balanced dom > document trees.And their goodnes for faster web. > Ah yes, and jQ "next" needs to stop the abundance of $(selector) > calls, and enforce $(selector, scope ) calls. > > I have done some R7D here, on the subject:http://x.dbjsystems.com/blog/?p=86 > > Thanks ... > > On Mar 29, 12:52 am, Ricardo <ricardob...@gmail.com> wrote: > > > A bit off-topic: actually in 1.3.2, due to the bottom-up filtering > > approach, $('#foo').find('.someclass') is about 3x faster than $ > > ('#foo .someclass'). See for yourself:http://jquery.nodnod.net/cases/273/run > > (enable firebug) > > > Some improvements to that have been landed a few weeks back, it was > > even worse. But in other situations the single string selector is > > faster, it depends on the selector complexity and size of the DOM. > > > cheers, > > - ricardo > > > On Mar 27, 7:09 pm, Daniel Friesen <nadir.seen.f...@gmail.com> wrote: > > > > Context is not scope! > > > > Context's purpose is not to narrow down querying. It is perfectly valid > > > to use a selector without context. Context's purpose is for sorting out > > > document context. > > > > You're telling me that my $('#foo .someclass'); selectors are slow > > > because they don't have context, which is a horrible lie. > > > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) > > > > DBJDBJ wrote: > > > > Can we just have next jQuery(selector, context) version throw an > > > > exception, > > > > IF context argument is not jQ instance or dom element exception will > > > > be thrown. As simple as that. > > > > > I would even suggest going even further. Throw an exception if context > > > > argument is not given. > > > > Make context mandatory. And make it right. > > > > > Otherwise people will start blaming jQuery for slow pages, instead of > > > > sorting out their lazy $(selector) calls without any context given > > > > to act as a SCOPE to narrow down the querying of the dom document > > > > tree ... > > > > > On Mar 26, 3:04 pm, Daniel Friesen <nadir.seen.f...@gmail.com> wrote: > > > > >> Example 1 is invalid jQuery. > > > > >> Example 2's speed comparison to Example 3 is trivial. In fact Example 2 > > > >> has an advantage to it. Do remember IE6's bug with getElementById, > > > >> jQuery's selectors have code to fix that bug. > > > > >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)DBJ wrote: > > > > >>> // jq132-vsdoc.js, line # 145 > > > >>> return jQuery(context).find(selector); > > > > >>> From this one might draw following Conclusions : > > > > >>> C1: if context is not a dom document jQ will find things faster > > > >>> because the scope of the search is narrow(er) > > > >>> C2: if context above is a single dom node (aka element) jQ will > > > >>> find things the fastest, please refer to: jq132-vsdoc.js, line > > > >>> # 107 > > > > >>> (please everyone use this structure in a discussion : > > > >>> <body> > > > >>> <span id='people'> > > > >>> <span id='person' name='john' ></span> > > > >>> <span id='person' name='bad robot' ></span> > > > >>> <!-- and so on --> > > > >>> </span> > > > >>> </body> > > > >>> ) > > > > >>> We are in the royal mess because we have no crystal clear and > > > >>> unambigious terminology here. On top of that one important term is > > > >>> missing: > > > >>> SCOPE. > > > > >>> Right now we have this (by now apparently) ambiguous term: CONTEXT. > > > >>> Sometimes it is (acts like, is used for) scope and sometime it does > > > >>> not. > > > > >>> 1 :: $("[name]", "#people" ) // CONTEXT > > > >>> (internaly: selector := "#people [name]", context := document ) > > > > >>> 2 :: $("[name]", $("#people") ) // SCOPE > > > >>> (internaly: selector := "[name]", context := element with id 'people' > > > >>> ) > > > > >>> 3 :: $("[name]", document.getElementByID("people") ) // SCOPE > > > >>> (internaly: selector := "[name]", context := element with id 'people' > > > >>> ) > > > > >>> Do we all agree with the above? If not we have to, I think. > > > > >>> Furthermore. Line 3:: above is the fastest possible $() , because it > > > >>> boils down to : > > > >>> $( document.getElementByID("people")).find("[name]") ; > > > > >>> This provides immediate and narrow scope for Sizzle to work in. > > > >>> (reminder: jQuery.find = Sizzle ) > > > > >>> And last but not the least >:o) > > > > >>> Please refer to : jq132-vsdoc.js, line # 100 > > > > >>> What am I asking for is to enforce this in jQuery. Nothing much and > > > >>> nothing else. So : > > > > >>> $( selector:string, context:string ) > > > > >>> Should be forbidden. should throw an exception. > > > > >>> The non-enforcing style of jQuery sometimes bears no fruit. The above > > > >>> line is now possible, same as just saying : $() , because jQuery > > > >>> authors think it is a "good thing" not to slap junior or senior but > > > >>> lazy jQuery users, when they do these kind of coding. > > > > >>> But. It is a fact that companies are using jQuery. The more they use > > > >>> it, the more problems they have with code that uses context in a wrong > > > >>> way. And. 90% of coders actualyl use no context at all. The badly > > > >>> written code mushroms and slows things down exponentially. One way out > > > >>> if that (mess?) would be to enforce proper usage of context and define > > > >>> the term SCOPE. Explain it to people and gently force them to use it. > > > > >>> 2009/3/26 Daniel Friesen <nadir.seen.f...@gmail.com>: > > > > >>>> I disagree. First thing to note is there are two definitions of > > > >>>> context. > > > >>>> jQuery(selector).context; And jQuery(selector, context); > > > > >>>> They are two different things which overlap just a bit. > > > >>>> jQuery(selector).context; Is the document context. It is the only > > > >>>> "context" that is stored in jQuery. > > > > >>>> jQuery(selector, context); Is a node/document context for the query. > > > >>>> It's primary purpose is to establish document context so that jQuery > > > >>>> knows what document (current document, an iframe, another frameset) > > > >>>> to > > > >>>> perform selectors in and use when constructing new document nodes to > > > >>>> insert. It does have the ability to be used to limit the scope of a > > > >>>> query, however that is unintuitive and makes programs confusing to > > > >>>> read. > > > > >>>> Your pagination example would be better handled in a different way: > > > >>>> $('.pagination .pagelist'); // jQuery selectors are not single-level. > > > >>>> Don't think everything needs to be separated into contexts. Most of > > > >>>> the > > > >>>> time it doesn't > > > >>>> var pagination = $('.pagination'); > > > >>>> $(pagination).find('.pagelist'); // $(selector, context); is just an > > > >>>> alias to $(context).find(selector); don't abuse it in ways that don't > > > >>>> make sense > > > >>>> pagination.find('.pagelist'); // Your use of another jQuery selector > > > >>>> is > > > >>>> completely unnecessary anyways, you already have a jQuery object just > > > >>>> use .find > > > > >>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) > > > > >>>> chris thatcher wrote: > > > > >>>>> I'm trying to follow this thread but it's a little loose so > > > >>>>> apologies if I'm > > > >>>>> missing the point. > > > > >>>>> The only thing I want to disagree with is the last point. it > > > >>>>> doesnt matter > > > >>>>> whether the context is a class or id. The context's function is to > > > >>>>> reduce > > > >>>>> the scope of the selectors search, and the primary reason for that > > > >>>>> is simply > > > >>>>> performance. > > > > >>>>> I know there are many signatures for $, but when providing a > > > >>>>> selector and > > > >>>>> context the primary goal is to reduce the scope of the current > > > >>>>> selector. > > > >>>>> There are plenty of cases where the context is a large set of nodes. > > > > >>>>> For example I might need to modify a portion of the dom that > > > >>>>> represents a > > > >>>>> pagination interface that is provided at the top and bottom of the > > > >>>>> interface. So I create a contect based on the class representing > > > >>>>> the > > > >>>>> interface. Say > > > > >>>>> var pagination = $('.pagination'); > > > > >>>>> Then to update a potion of that sub-dom I would do somthing like: > > > > >>>>> myCustomUpdate($('.pagelist', pagination)); > > > > >>>>> This saves jquery from having to seach the entire document for > > > >>>>> elements > > > >>>>> with the class 'pagelist', a big win. Instead the selector only > > > >>>>> looks under > > > >>>>> the element array represented by the context array for my variable > > > >>>>> 'pagination'. > > > > >>>>> Does this help you? can we talk in very general examples to help > > > >>>>> illuminate > > > >>>>> the cases you are concerned about? > > > > >>>>> Thatcher > > > > >>>>> On Wed, Mar 25, 2009 at 8:53 PM, Julian Aubourg > > > >>>>> <aubourg.jul...@gmail.com>wrote: > > > > >>>>>>> In my mind context (as I said but I will repeat ;) should be only > > > >>>>>>> dom > > > >>>>>>> node, or single id string. If given by user. So these will be only > > > >>>>>>> three valid forms: > > > > >>>>>> I so disagree with this. If we're talking efficient pages here, > > > >>>>>> you HAVE to > > > >>>>>> authorise a jQuery object as context. > > > >>>>>> Say you have a list of items with elements within you wanna bind > > > >>>>>> click > > > >>>>>> handlers to. A nice way (and AFAIK efficient, both in term of > > > >>>>>> performance > > > >>>>>> AND memory consumption) to do so would be like this: > > > > >>>>>> var items = $(itemSelector); > > > >>>>>> $(subElementSelector1,items).click(function() {...}); > > > >>>>>> $(subElementSelector2,items).click(function() {...}); > > > >>>>>> ... > > > >>>>>> $(subElementSelectorN,items).click(function() {...}); > > > > >>>>>> Your idea of having only *1* dom node or to limit context > > > >>>>>> expressions as id > > > >>>>>> only > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
