Christof Donat schrieb:
> As I have shown, a solution does not need much code and doesn't make anything
> else noticably slower. I guess that with the existing infrastructure in
> jQuery the code would even be shorter.
>
Right, I got that wrong. Your modifications concern only the special
cas
Hi,
> But as it is quite easy to solve this without IDs, we shouldn't bother
> with a flawed workaround.
I have not yet been in a situation where I would have needed that, but it is a
question of "least surprise". In case I would use a construct like
$('#myid',context), I would be very surprise
Brandon Aaron schrieb:
> IDs are supposed to be unique per the spec. jQuery shouldn't have to
> hack/deal with invalid markup.
>
The idea does not rely on invalid markup, but rather on a dynamic
structure involving IDs: By searching for IDs within a context, you can
apply stuff to them only wh
Hi,
> IDs are supposed to be unique per the spec. jQuery shouldn't have to
> hack/deal with invalid markup.
jQuery has a context-parameter:
asdf
$('#42',known) -> should find one element
asdf
$('#42',known) -> should find no elements but currently does find one
Christof
IDs are supposed to be unique per the spec. jQuery shouldn't have to
hack/deal with invalid markup.
--
Brandon Aaron
On 10/10/06, Christof Donat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > > Well, you might whant to work with an element only if it is inside
> > > another one, which you already have:
>
Hi,
> > Well, you might whant to work with an element only if it is inside
> > another one, which you already have:
>
> Unfortnuately, getElementById exists only for the document object,
> therefore you can't just say context.getElementById(...). I think this
> is the reason why jQuery can't help
Christof Donat schrieb:
>>> It's as if when the id selector is passed then the $ method just uses a
>>> document.getElementById.
>>>
>> Well IDs are supposed to be unique throughout the entire document (i.e.
>> there can be one and only one element in the entire document with an ID of
>> "my
Yes, I was debugging a problem and it turns out one of my developers was indeed trying to find an non-unique ID within a context. But it always retrieved the first element with that ID in the document. It was immediately clear what it was doing.
As for $(".myClass", myContext); being faster than
Hi,
> Because if the size of your markup is large then this
>
> $("#myId", myContext);
>
> may actually be slower then this
>
> $(".myClass", myContext);
It depends on what the browser does for getElementById().
If the browser walks through all the elements in your document to find the ID,
then
Hi,
> > It's as if when the id selector is passed then the $ method just uses a
> > document.getElementById.
>
> Well IDs are supposed to be unique throughout the entire document (i.e.
> there can be one and only one element in the entire document with an ID of
> "myId"), so why shouldn't it simpl
> From: Brendan O'Brien
>
> I have a somewhat related observation. I have discovered
> that when selecting by ID, the context parameter does not
> matter. In other words, these two statements are
> functionally equivalent:
>
> $("#myId");
> and
> $("#myId", myContext);
>
> It's as if when t
On 10/9/06, Brendan O'Brien <[EMAIL PROTECTED]> wrote:
It's as if when the id selector is passed then the $ method just uses a document.getElementById.Well IDs are supposed to be unique throughout the entire document (i.e. there can be one and only one element in the entire document with an ID of "
I have a somewhat related observation. I have discovered that when selecting by ID, the context parameter does not matter. In other words, these two statements are functionally equivalent:$("#myId");
and$("#myId", myContext);It's as if when the id selector is passed then the $ method just uses a
Thanks for all your responses. I actually do all the things that you mentioned: reusing the jQ object, chaining, setting a context, etc. Actually it would be helpful to have some performance analysis on the different kinds of queries, such as searching by ID, by element, class name, attribute, xpat
yes, that would help quite a bit, since jquery would only need to look once.
On 10/7/06, Jacky <[EMAIL PROTECTED]> wrote:
> Would caching the jQuery object a help too? Sometimes you just can't
> keep the chain.
>
> e.g. var jqObj = $("#abc");
>
> On 10/8/06, Karl Swedberg <[EMAIL PROTECTED]> wrote
Would caching the jQuery object a help too? Sometimes you just can't
keep the chain.
e.g. var jqObj = $("#abc");
On 10/8/06, Karl Swedberg <[EMAIL PROTECTED]> wrote:
> On Oct 7, 2006, at 3:39 PM, George Adamson wrote:
>
> > An easy performance booster is to use the second param in $() to set a
>
On Oct 7, 2006, at 3:39 PM, George Adamson wrote:
> An easy performance booster is to use the second param in $() to set a
> context for the search. Eg: $("DIV.myClass", myParentElement).
> Perhaps this
> is what you meant when you mentioned 'getting a parent element' ?
>
> Chaining methods is h
Saw you had no responses so here's a couple of suggestions...
An easy performance booster is to use the second param in $() to set a
context for the search. Eg: $("DIV.myClass", myParentElement). Perhaps this
is what you meant when you mentioned 'getting a parent element' ?
Chaining methods is
Hi. I'm building a highly dynamic application based using jQuery extensively. I have a set of templates with predefined markup, which is retrieved and modified using jQuery CSS queries. However, as the markup size increases the queries are becoming considerably slow. I've tested some different ways
19 matches
Mail list logo
