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]").
>>>>>>>
>>>>>>> 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
-~----------~----~----~----~------~----~------~--~---
