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 <[email protected]> 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 <[email protected]> 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 <[email protected]>:
>
> >>>> 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 
> >>>>> <[email protected]>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 would forbid such a construct and would only lead to a less 
> >>>>>> elegant and
> >>>>>> less efficient solution.
>
> >>>>>> I'm a great fan of contexts and use them as often as I can. They are as
> >>>>>> good as the power of expression we have to express them. Reduce that 
> >>>>>> and you
> >>>>>> can be sure no one will ever use contexts again, at least not in a
> >>>>>> real-world web application where ids are far less used than classes.
>
> >>>>>> To me, the rational behind contexts within jQuery is crystal clear. Why
> >>>>>> reduce it to a getElementById wrapper?
>
> >>>>>> 2009/3/26 DBJ <[email protected]>
>
> >>>>>>> This is, of course, true and fine. Exactly the purpose of the context.
> >>>>>>> To define the starting node BELLOW which it will look further. Fine.
> >>>>>>> It is only that this is not what current documentation is saying :
>
> >>>>>>>http://docs.jquery.com/Core/jQuery#expressioncontext
>
> >>>>>>> At least NOT clearly and NOT unambigously...
>
> >>>>>>> On top of that jQuery.selector and jQuery.context in this case are not
> >>>>>>> what was originaly passed but what was processed inside jQ
>
> >>>>>>> So:
>
> >>>>>>> $("[name]","#people") which is equivalent to $("#people
> >>>>>>>  [name]").
>
> ...
>
> 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 [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to