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]").
>>>>>
>>>>> Results in :
>>>>>
>>>>> selector := "'#people [name]" // space in the middle
>>>>> context := DOMDocument
>>>>>
>>>>> After call to $() finsihes, and plugins can start using this properties.
>>>>> Above is wrong and should be :
>>>>>
>>>>> selector := "[name]"
>>>>> context := "#people " // space on the end
>>>>>
>>>>> This might seem as some nitpicking, but it is actually extrmely important.
>>>>> Because if context is always given , jQuery enabled pages will be faster.
>>>>> In some case much faster. So the context syntax should be crystal
>>>>> clear and consistent.
>>>>>
>>>>> 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:
>>>>>
>>>>> $("'#people") // dom document default context
>>>>> $("[name], "#people") //single id
>>>>> $("[name]", domNode ) // element given as context
>>>>>
>>>>> I see no reason for anything else to act as context.
>>>>> This would be (as I also already said ;) excellent start for people to
>>>>> understand how to structure their pages and why. And why are properly
>>>>> strucutred pages faster to traverse with jQuery( selector, context )
>>>>> calls.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2009/3/25 Julian Aubourg <[email protected]>:
>>>>>
>>>>>
>>>>>> $("[name]","#people") is equivalent to $("#people
>>>>>>
>>>>>>
>>>>> [name]").
>>>>>
>>>>>
>>>>>> Please note the spacing.
>>>>>> It then means every element with a name attribute BELOW the element of
>>>>>>
>>>>>>
>>>>> id
>>>>>
>>>>>
>>>>>> "people".
>>>>>> $("#people[name]") means the element of id "people" with a name
>>>>>>
>>>>>>
>>>>> attribute.
>>>>>
>>>>>
>>>>>> So, YES, this is quite different.
>>>>>> 2009/3/25 DBJ <[email protected]>
>>>>>>
>>>>>>
>>>>>>> @Daniel
>>>>>>>
>>>>>>> You confuse me ;o)
>>>>>>>
>>>>>>> Aa I said : A quick sample I have made (quickly) is here:
>>>>>>> http://jsbin.com/avowu/edit
>>>>>>>
>>>>>>> Please use it now. It is extremely simple and it shows what is going
>>>>>>> on inside jQuery, regarding : this.selector and this.context.
>>>>>>>
>>>>>>> So when I say: $("[name]", "#people"); I can (and you) can see that
>>>>>>> inside jQuery selector (aka this.selector) is : "'#people[name]"
>>>>>>>
>>>>>>> So I am not "thinking" on this one I am just passing it on. This is
>>>>>>> also very confusing:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Thinking that $("[name]", "#people"); is the same as
>>>>>>>>
>>>>>>>>
>>>>> $("#people[name]");
>>>>>
>>>>>
>>>>>>>> is wrong on multiple levels.
>>>>>>>>
>>>>>>>>
>>>>>>> This is how I understood jQuery documentation describes the context,
>>>>>>> but this is not
>>>>>>> apparently how this.selector value is defined inside ... This might be
>>>>>>> "wrong on multiple levels" bi this is the value of this.selector , as
>>>>>>> we can clearly see.
>>>>>>>
>>>>>>> Also you say :
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> $("[name]", $("#people")); actually means $("#people [name]");
>>>>>>>>
>>>>>>>>
>>>>>>> Are you actually saying this is the proper usage? Ok, but why is than
>>>>>>> the "improper" usage allowed? If it is imporper that is. But the
>>>>>>> question (for the last snippet) is what is then the value of the
>>>>>>> this.slector going to be, when used by a plugin ? Currently it is :
>>>>>>> "#people [name]"
>>>>>>>
>>>>>>> Also, why are we in this mess ? Can we have consistent documentation
>>>>>>> and implementation that is folllowing it? Something like :
>>>>>>>
>>>>>>> "Context type can be a dom node or an jQuery instance. Everything else
>>>>>>> throws an exeception if passed as a context to the jQuery() function"
>>>>>>>
>>>>>>> This would be a really good start to the discussion on what is
>>>>>>> actually a "context" ;o)
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>>
>>>>>>> 2009/3/25 Daniel Friesen <[email protected]>:
>>>>>>>
>>>>>>>
>>>>>>>> Context is either a dom node, a document, or recently a jQuery object
>>>>>>>> with the like. Context is merely used for establishing a dom node as
>>>>>>>>
>>>>>>>>
>>>>> a
>>>>>
>>>>>
>>>>>>>> parent, and in the case of a document is necessary to know what
>>>>>>>>
>>>>>>>>
>>>>> document
>>>>>
>>>>>
>>>>>>>> to use to create new nodes for.
>>>>>>>> Thinking that $("[name]", "#people"); is the same as
>>>>>>>>
>>>>>>>>
>>>>> $("#people[name]");
>>>>>
>>>>>
>>>>>>>> is wrong on multiple levels. $("[name]", $("#people")); actually
>>>>>>>>
>>>>>>>>
>>>>> means
>>>>>
>>>>>
>>>>>>>> $("#people [name]"); and the contex is not meant to be used that way.
>>>>>>>> In fact trying to think that way makes things confusing and reduces
>>>>>>>>
>>>>>>>>
>>>>> code
>>>>>
>>>>>
>>>>>>>> readability because you are mixing up order. If you want to build
>>>>>>>> queries like this then I'd recommend you push for the inclusion of my
>>>>>>>> alternate proposed format:
>>>>>>>> $("#selector", "[selector]", ".selector", ...);
>>>>>>>> Which makes proper sense since you are building up selectors in order
>>>>>>>> (even has potential performance benefits if someone is adventurous
>>>>>>>>
>>>>>>>>
>>>>> since
>>>>>
>>>>>
>>>>>>>> I'd explicitly say to not rely on any consistent return for .end()
>>>>>>>>
>>>>>>>>
>>>>> when
>>>>>
>>>>>
>>>>>>>> using it). It's even more useful when you throw widget objects into
>>>>>>>>
>>>>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>>>> mix.
>>>>>>>>
>>>>>>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
>>>>>>>>
>>>>>>>> DBJDBJ wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> My question/comment : What is a CONTEXT LOGIC in jQ ? I think it
>>>>>>>>> should be : dom node inside which is the result set to be found?
>>>>>>>>> The dom node inside which is jQuery to use the selector given.
>>>>>>>>>
>>>>>>>>>
>>>>> Default
>>>>>
>>>>>
>>>>>>>>> is document.
>>>>>>>>>
>>>>>>>>> If I read it right , jQ doc says that context type can be (only?)
>>>>>>>>>
>>>>>>>>>
>>>>> dom
>>>>>
>>>>>
>>>>>>>>> node or jQuery instance. So I expected that if I give context as a
>>>>>>>>> string it will be takens as selector for the jQuery, which will
>>>>>>>>> eventualy spill out a single dome node to be used as a context. And
>>>>>>>>> that
>>>>>>>>> way one can speed up her code, because querying inside the known dom
>>>>>>>>> element must be quicker than querying inside the whole document,
>>>>>>>>>
>>>>>>>>>
>>>>> each
>>>>>
>>>>>
>>>>>>>>> time. finding on the branch is faster that finding from the root of
>>>>>>>>> the tree.
>>>>>>>>>
>>>>>>>>> But it seems that if string is given as a context , the selector
>>>>>>>>>
>>>>>>>>>
>>>>> get's
>>>>>
>>>>>
>>>>>>>>> it as a prefix and context is a dom document ? So :
>>>>>>>>>
>>>>>>>>> $("[name]", "#people") is the same as saying
>>>>>>>>>
>>>>>>>>>
>>>>> $("#people[name]",
>>>>>
>>>>>
>>>>>>>>> document ) , because jQ makes it into this.
>>>>>>>>>
>>>>>>>>> While one might expect the above to be translated to : $("[name]",
>>>>>>>>> document.getElementById("people") ) , which could considerably speed
>>>>>>>>> up the slection ...
>>>>>>>>>
>>>>>>>>> A quick sample I have made (quickly) is here:
>>>>>>>>> http://jsbin.com/avowu/edit
>>>>>>>>>
>>>>>>>>> // context is correctly reported by jQ
>>>>>>>>> $("[name]", document.getElementById("people")).formula( log ) ;
>>>>>>>>>
>>>>>>>>> // this.context is reported by jQ as HTMLDocument ?
>>>>>>>>> // this.selector is prefixed with context
>>>>>>>>> $("[name]", "#people") ;
>>>>>>>>>
>>>>>>>>> Is this "by design" ? Maybe jQ does this :
>>>>>>>>>
>>>>>>>>> 1 :: jQuery("#people").find("[name]")
>>>>>>>>> 2 :: this.context = "#people" + "[name]"
>>>>>>>>>
>>>>>>>>> So that plugins can see the context which actually was used ? So the
>>>>>>>>> line :
>>>>>>>>> $("[name]", "#people")
>>>>>>>>> after all IS actually making things faster ? And I am (or I was)
>>>>>>>>> confused with the value of this.context and this.selector, available
>>>>>>>>> to me inside a plugin ? But then I think I can;t be right here,
>>>>>>>>> because it would be much better to have the selector and context, as
>>>>>>>>> originaly
>>>>>>>>> given by the user :
>>>>>>>>>
>>>>>>>>> 1 :: this.context = "#people" ; this.selector = "[name]" ;
>>>>>>>>> 2 :: jQuery(context).find(selector)
>>>>>>>>>
>>>>>>>>> After this plugins will see the original selector and context.
>>>>>>>>> Provided my assumptions are correct.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>> Dusan Jovanovic
>>>>>>> http://dbj.org
>>>>>>> -------------------------
>>>>>>> "html e-mail is expensive" ™
>>>>>>>
>>>>>>> This email originates from Dusan B. Jovanovic. It, and any
>>>>>>> attachments, may contain confidential information and may be subject
>>>>>>> to copyright or other intellectual property rights. It is only for the
>>>>>>> use of the addressee(s). You may not copy, forward, disclose, save or
>>>>>>> otherwise use it in any way if you are not the addressee(s) or
>>>>>>> responsible for delivery. If you receive this email by mistake, please
>>>>>>> advise the sender and cancel it immediately. Dusan B. Jovanovic may
>>>>>>> monitor the content of emails within its network to ensure compliance
>>>>>>> with its policies and procedures. Any email is susceptible to
>>>>>>> alteration and its integrity cannot be assured. Dusan B. Jovanovic
>>>>>>> shall not be liable if the message is altered, modified, falsified, or
>>>>>>> edited.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Dusan Jovanovic
>>>>> http://dbj.org
>>>>> -------------------------
>>>>> "html e-mail is expensive" ™
>>>>>
>>>>> This email originates from Dusan B. Jovanovic. It, and any
>>>>> attachments, may contain confidential information and may be subject
>>>>> to copyright or other intellectual property rights. It is only for the
>>>>> use of the addressee(s). You may not copy, forward, disclose, save or
>>>>> otherwise use it in any way if you are not the addressee(s) or
>>>>> responsible for delivery. If you receive this email by mistake, please
>>>>> advise the sender and cancel it immediately. Dusan B. Jovanovic may
>>>>> monitor the content of emails within its network to ensure compliance
>>>>> with its policies and procedures. Any email is susceptible to
>>>>> alteration and its integrity cannot be assured. Dusan B. Jovanovic
>>>>> shall not be liable if the message is altered, modified, falsified, or
>>>>> edited.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
