// 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 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 <dbj...@gmail.com>
>>>
>>>
>>>
>>>> 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 <aubourg.jul...@gmail.com>:
>>>>
>>>>> $("[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 <dbj...@gmail.com>
>>>>>
>>>>>> @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 <nadir.seen.f...@gmail.com>:
>>>>>>
>>>>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
> >
>
--
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 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
-~----------~----~----~----~------~----~------~--~---
