This is in addition to the Sizzle selector engine patch which I posted a little bit ago (and which I'll be making an updated version of very soon).
The patches are as follows:
append.patch: Use DocumentFragment in .domManip. This is a large overhaul of .domManip (and moves some of the logic into jQuery.clean). The result is that manipulation code (append/prepend/etc.) is about 15x faster. During this overhaul I made a change to how scripts are executed. Roughly it means that scripts that are brought in as a string and inserted are executed - but scripts that exist as DOM nodes are not. This will solve the common problem wherein a script that already exists in the page will be dual-executed. Let me know if this affects your code - I suspect we'll learn more during the beta, as well.
append-2.patch: Just in case, this is the same patch as above, but with the old-style of functionality intact.
closest.patch: This adds a new method: .closest(selector). You can think of it as .firstSelfOrAncestor. This has been a commonly requested function and it will make implementing delegation code trivial.
domready.patch: An overhaul of the ready code, removing the the "wait for stylesheets to load" logic. I did a bunch of testing on this and it really appears as if it's impossible to get proper stylesheet loading detection implemented (I wanted to have a "cssready" event for 1.3, but it's not looking likely). Instead we need to back off and simply provide normal DOM ready functionality in .ready(). This means that we need to educate users to include their stylesheets before their scripts in order for them to be accessible in time for DOM ready.
multi-namespace.patch: This adds multiple-namespace support to events. Previously you could only do it with one namespace e.g. .bind("click.foo") or .trigger("click.foo"). The patch allows you to use any number of namespaces e.g. .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
selector.patch: Adds a new internal property that keeps track of the selector chain. $("div").find("span").filter(":hidden").parent().selector == "div span.filter(:hidden).parent()". This is meant to be used by plugins (like liveQuery), primarily. The implementation of selectors like .parent() will be coming in a follow-up patch along with Sizzle.
strict.patch: Makes it so that we pass strict mode in Firefox 3. Only a few minor tweaks necessary.
I have the following patches coming: - Landing Sizzle - Landing .parent()/.filter()/etc. selector implementation. - Native event delegation - Removing the remaining uses of jQuery.browser
> This is in addition to the Sizzle selector engine patch which I posted
> a little bit ago (and which I'll be making an updated version of very
> soon).
> The patches are as follows:
> append.patch: Use DocumentFragment in .domManip. This is a large
> overhaul of .domManip (and moves some of the logic into jQuery.clean).
> The result is that manipulation code (append/prepend/etc.) is about
> 15x faster. During this overhaul I made a change to how scripts are
> executed. Roughly it means that scripts that are brought in as a
> string and inserted are executed - but scripts that exist as DOM nodes
> are not. This will solve the common problem wherein a script that
> already exists in the page will be dual-executed. Let me know if this
> affects your code - I suspect we'll learn more during the beta, as
> well.
> append-2.patch: Just in case, this is the same patch as above, but
> with the old-style of functionality intact.
> closest.patch: This adds a new method: .closest(selector). You can
> think of it as .firstSelfOrAncestor. This has been a commonly
> requested function and it will make implementing delegation code
> trivial.
> domready.patch: An overhaul of the ready code, removing the the "wait
> for stylesheets to load" logic. I did a bunch of testing on this and
> it really appears as if it's impossible to get proper stylesheet
> loading detection implemented (I wanted to have a "cssready" event for
> 1.3, but it's not looking likely). Instead we need to back off and
> simply provide normal DOM ready functionality in .ready(). This means
> that we need to educate users to include their stylesheets before
> their scripts in order for them to be accessible in time for DOM
> ready.
> multi-namespace.patch: This adds multiple-namespace support to events.
> Previously you could only do it with one namespace e.g.
> .bind("click.foo") or .trigger("click.foo"). The patch allows you to
> use any number of namespaces e.g.
> .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
> selector.patch: Adds a new internal property that keeps track of the
> selector chain.
> $("div").find("span").filter(":hidden").parent().selector == "div
> span.filter(:hidden).parent()". This is meant to be used by plugins
> (like liveQuery), primarily. The implementation of selectors like
> .parent() will be coming in a follow-up patch along with Sizzle.
> strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
> a few minor tweaks necessary.
> I have the following patches coming:
> - Landing Sizzle
> - Landing .parent()/.filter()/etc. selector implementation.
> - Native event delegation
> - Removing the remaining uses of jQuery.browser
> > This is in addition to the Sizzle selector engine patch which I posted
> > a little bit ago (and which I'll be making an updated version of very
> > soon).
> > The patches are as follows:
> > append.patch: Use DocumentFragment in .domManip. This is a large
> > overhaul of .domManip (and moves some of the logic into jQuery.clean).
> > The result is that manipulation code (append/prepend/etc.) is about
> > 15x faster. During this overhaul I made a change to how scripts are
> > executed. Roughly it means that scripts that are brought in as a
> > string and inserted are executed - but scripts that exist as DOM nodes
> > are not. This will solve the common problem wherein a script that
> > already exists in the page will be dual-executed. Let me know if this
> > affects your code - I suspect we'll learn more during the beta, as
> > well.
> > append-2.patch: Just in case, this is the same patch as above, but
> > with the old-style of functionality intact.
> > closest.patch: This adds a new method: .closest(selector). You can
> > think of it as .firstSelfOrAncestor. This has been a commonly
> > requested function and it will make implementing delegation code
> > trivial.
> > domready.patch: An overhaul of the ready code, removing the the "wait
> > for stylesheets to load" logic. I did a bunch of testing on this and
> > it really appears as if it's impossible to get proper stylesheet
> > loading detection implemented (I wanted to have a "cssready" event for
> > 1.3, but it's not looking likely). Instead we need to back off and
> > simply provide normal DOM ready functionality in .ready(). This means
> > that we need to educate users to include their stylesheets before
> > their scripts in order for them to be accessible in time for DOM
> > ready.
> > multi-namespace.patch: This adds multiple-namespace support to events.
> > Previously you could only do it with one namespace e.g.
> > .bind("click.foo") or .trigger("click.foo"). The patch allows you to
> > use any number of namespaces e.g.
> > .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
> > selector.patch: Adds a new internal property that keeps track of the
> > selector chain.
> > $("div").find("span").filter(":hidden").parent().selector == "div
> > span.filter(:hidden).parent()". This is meant to be used by plugins
> > (like liveQuery), primarily. The implementation of selectors like
> > .parent() will be coming in a follow-up patch along with Sizzle.
> > strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
> > a few minor tweaks necessary.
> > I have the following patches coming:
> > - Landing Sizzle
> > - Landing .parent()/.filter()/etc. selector implementation.
> > - Native event delegation
> > - Removing the remaining uses of jQuery.browser
> This is in addition to the Sizzle selector engine patch which I posted
> a little bit ago (and which I'll be making an updated version of very
> soon).
> The patches are as follows:
> append.patch: Use DocumentFragment in .domManip. This is a large
> overhaul of .domManip (and moves some of the logic into jQuery.clean).
> The result is that manipulation code (append/prepend/etc.) is about
> 15x faster. During this overhaul I made a change to how scripts are
> executed. Roughly it means that scripts that are brought in as a
> string and inserted are executed - but scripts that exist as DOM nodes
> are not. This will solve the common problem wherein a script that
> already exists in the page will be dual-executed. Let me know if this
> affects your code - I suspect we'll learn more during the beta, as
> well.
> append-2.patch: Just in case, this is the same patch as above, but
> with the old-style of functionality intact.
> closest.patch: This adds a new method: .closest(selector). You can
> think of it as .firstSelfOrAncestor. This has been a commonly
> requested function and it will make implementing delegation code
> trivial.
> domready.patch: An overhaul of the ready code, removing the the "wait
> for stylesheets to load" logic. I did a bunch of testing on this and
> it really appears as if it's impossible to get proper stylesheet
> loading detection implemented (I wanted to have a "cssready" event for
> 1.3, but it's not looking likely). Instead we need to back off and
> simply provide normal DOM ready functionality in .ready(). This means
> that we need to educate users to include their stylesheets before
> their scripts in order for them to be accessible in time for DOM
> ready.
> multi-namespace.patch: This adds multiple-namespace support to events.
> Previously you could only do it with one namespace e.g.
> .bind("click.foo") or .trigger("click.foo"). The patch allows you to
> use any number of namespaces e.g.
> .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
> selector.patch: Adds a new internal property that keeps track of the
> selector chain.
> $("div").find("span").filter(":hidden").parent().selector == "div
> span.filter(:hidden).parent()". This is meant to be used by plugins
> (like liveQuery), primarily. The implementation of selectors like
> .parent() will be coming in a follow-up patch along with Sizzle.
> strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
> a few minor tweaks necessary.
> I have the following patches coming:
> - Landing Sizzle
> - Landing .parent()/.filter()/etc. selector implementation.
> - Native event delegation
> - Removing the remaining uses of jQuery.browser
Today I use only jQuery throughout my projects. But reglib has gotten
my attention. This selector patch is to make livequery able to do the
'behind the scenes' functionality in a reglib delegation like way?
This would be awesome.
I was thinking of doing that, but I've got only the time to read
reglib once and, as it seems to me, their way is a little bit the
reverse way as jQuery selector works. Am I right? I plan to dive into
this further.
John,
Is this idea already in the works? Or you plan to provide this
selector.patch naively for someone to eventually contribute to
livequery?
On Dec 16, 6:32 pm, "John Resig" <jere...@gmail.com> wrote:
> This is in addition to the Sizzle selector engine patch which I posted
> a little bit ago (and which I'll be making an updated version of very
> soon).
> The patches are as follows:
> append.patch: Use DocumentFragment in .domManip. This is a large
> overhaul of .domManip (and moves some of the logic into jQuery.clean).
> The result is that manipulation code (append/prepend/etc.) is about
> 15x faster. During this overhaul I made a change to how scripts are
> executed. Roughly it means that scripts that are brought in as a
> string and inserted are executed - but scripts that exist as DOM nodes
> are not. This will solve the common problem wherein a script that
> already exists in the page will be dual-executed. Let me know if this
> affects your code - I suspect we'll learn more during the beta, as
> well.
> append-2.patch: Just in case, this is the same patch as above, but
> with the old-style of functionality intact.
> closest.patch: This adds a new method: .closest(selector). You can
> think of it as .firstSelfOrAncestor. This has been a commonly
> requested function and it will make implementing delegation code
> trivial.
> domready.patch: An overhaul of the ready code, removing the the "wait
> for stylesheets to load" logic. I did a bunch of testing on this and
> it really appears as if it's impossible to get proper stylesheet
> loading detection implemented (I wanted to have a "cssready" event for
> 1.3, but it's not looking likely). Instead we need to back off and
> simply provide normal DOM ready functionality in .ready(). This means
> that we need to educate users to include their stylesheets before
> their scripts in order for them to be accessible in time for DOM
> ready.
> multi-namespace.patch: This adds multiple-namespace support to events.
> Previously you could only do it with one namespace e.g.
> .bind("click.foo") or .trigger("click.foo"). The patch allows you to
> use any number of namespaces e.g.
> .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
> selector.patch: Adds a new internal property that keeps track of the
> selector chain.
> $("div").find("span").filter(":hidden").parent().selector == "div
> span.filter(:hidden).parent()". This is meant to be used by plugins
> (like liveQuery), primarily. The implementation of selectors like
> .parent() will be coming in a follow-up patch along with Sizzle.
> strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
> a few minor tweaks necessary.
> I have the following patches coming:
> - Landing Sizzle
> - Landing .parent()/.filter()/etc. selector implementation.
> - Native event delegation
> - Removing the remaining uses of jQuery.browser
The event delegation code that we're landing (and what we've been
planning on landing for a long time) is going to be very similar to
what's in reglib.
In 1.3 you will be able to do:
$("div.menu li > a").live("click", function(e) { ... });
in reglib the equivalent would be:
reg.click("div.menu li > a", function(e) { ... });
On Tue, Dec 16, 2008 at 6:50 PM, Iraê <i.bra...@gmail.com> wrote:
> This is awesome, as always.
> Today I use only jQuery throughout my projects. But reglib has gotten
> my attention. This selector patch is to make livequery able to do the
> 'behind the scenes' functionality in a reglib delegation like way?
> This would be awesome.
> I was thinking of doing that, but I've got only the time to read
> reglib once and, as it seems to me, their way is a little bit the
> reverse way as jQuery selector works. Am I right? I plan to dive into
> this further.
> John,
> Is this idea already in the works? Or you plan to provide this
> selector.patch naively for someone to eventually contribute to
> livequery?
> On Dec 16, 6:32 pm, "John Resig" <jere...@gmail.com> wrote:
>> Hi Everyone -
>> This is in addition to the Sizzle selector engine patch which I posted
>> a little bit ago (and which I'll be making an updated version of very
>> soon).
>> The patches are as follows:
>> append.patch: Use DocumentFragment in .domManip. This is a large
>> overhaul of .domManip (and moves some of the logic into jQuery.clean).
>> The result is that manipulation code (append/prepend/etc.) is about
>> 15x faster. During this overhaul I made a change to how scripts are
>> executed. Roughly it means that scripts that are brought in as a
>> string and inserted are executed - but scripts that exist as DOM nodes
>> are not. This will solve the common problem wherein a script that
>> already exists in the page will be dual-executed. Let me know if this
>> affects your code - I suspect we'll learn more during the beta, as
>> well.
>> append-2.patch: Just in case, this is the same patch as above, but
>> with the old-style of functionality intact.
>> closest.patch: This adds a new method: .closest(selector). You can
>> think of it as .firstSelfOrAncestor. This has been a commonly
>> requested function and it will make implementing delegation code
>> trivial.
>> domready.patch: An overhaul of the ready code, removing the the "wait
>> for stylesheets to load" logic. I did a bunch of testing on this and
>> it really appears as if it's impossible to get proper stylesheet
>> loading detection implemented (I wanted to have a "cssready" event for
>> 1.3, but it's not looking likely). Instead we need to back off and
>> simply provide normal DOM ready functionality in .ready(). This means
>> that we need to educate users to include their stylesheets before
>> their scripts in order for them to be accessible in time for DOM
>> ready.
>> multi-namespace.patch: This adds multiple-namespace support to events.
>> Previously you could only do it with one namespace e.g.
>> .bind("click.foo") or .trigger("click.foo"). The patch allows you to
>> use any number of namespaces e.g.
>> .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
>> selector.patch: Adds a new internal property that keeps track of the
>> selector chain.
>> $("div").find("span").filter(":hidden").parent().selector == "div
>> span.filter(:hidden).parent()". This is meant to be used by plugins
>> (like liveQuery), primarily. The implementation of selectors like
>> .parent() will be coming in a follow-up patch along with Sizzle.
>> strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
>> a few minor tweaks necessary.
>> I have the following patches coming:
>> - Landing Sizzle
>> - Landing .parent()/.filter()/etc. selector implementation.
>> - Native event delegation
>> - Removing the remaining uses of jQuery.browser
I would rather shoot for something that's a little more idiomatic to
jQuery. For example jQuery already has a way to figure out if an
element contains a selector: "div:has(a)".
Thus, I think a better result would be:
$("div").has("a") // true
$(document).has("div") // true
$(document).has(document.getElementsByTagName("div")[0]); // true
>> This is in addition to the Sizzle selector engine patch which I posted
>> a little bit ago (and which I'll be making an updated version of very
>> soon).
>> The patches are as follows:
>> append.patch: Use DocumentFragment in .domManip. This is a large
>> overhaul of .domManip (and moves some of the logic into jQuery.clean).
>> The result is that manipulation code (append/prepend/etc.) is about
>> 15x faster. During this overhaul I made a change to how scripts are
>> executed. Roughly it means that scripts that are brought in as a
>> string and inserted are executed - but scripts that exist as DOM nodes
>> are not. This will solve the common problem wherein a script that
>> already exists in the page will be dual-executed. Let me know if this
>> affects your code - I suspect we'll learn more during the beta, as
>> well.
>> append-2.patch: Just in case, this is the same patch as above, but
>> with the old-style of functionality intact.
>> closest.patch: This adds a new method: .closest(selector). You can
>> think of it as .firstSelfOrAncestor. This has been a commonly
>> requested function and it will make implementing delegation code
>> trivial.
>> domready.patch: An overhaul of the ready code, removing the the "wait
>> for stylesheets to load" logic. I did a bunch of testing on this and
>> it really appears as if it's impossible to get proper stylesheet
>> loading detection implemented (I wanted to have a "cssready" event for
>> 1.3, but it's not looking likely). Instead we need to back off and
>> simply provide normal DOM ready functionality in .ready(). This means
>> that we need to educate users to include their stylesheets before
>> their scripts in order for them to be accessible in time for DOM
>> ready.
>> multi-namespace.patch: This adds multiple-namespace support to events.
>> Previously you could only do it with one namespace e.g.
>> .bind("click.foo") or .trigger("click.foo"). The patch allows you to
>> use any number of namespaces e.g.
>> .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
>> selector.patch: Adds a new internal property that keeps track of the
>> selector chain.
>> $("div").find("span").filter(":hidden").parent().selector == "div
>> span.filter(:hidden).parent()". This is meant to be used by plugins
>> (like liveQuery), primarily. The implementation of selectors like
>> .parent() will be coming in a follow-up patch along with Sizzle.
>> strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
>> a few minor tweaks necessary.
>> I have the following patches coming:
>> - Landing Sizzle
>> - Landing .parent()/.filter()/etc. selector implementation.
>> - Native event delegation
>> - Removing the remaining uses of jQuery.browser
> This is in addition to the Sizzle selector engine patch which I posted
> a little bit ago (and which I'll be making an updated version of very
> soon).
> The patches are as follows:
> append.patch: Use DocumentFragment in .domManip. This is a large
> overhaul of .domManip (and moves some of the logic into jQuery.clean).
> The result is that manipulation code (append/prepend/etc.) is about
> 15x faster. During this overhaul I made a change to how scripts are
> executed. Roughly it means that scripts that are brought in as a
> string and inserted are executed - but scripts that exist as DOM nodes
> are not. This will solve the common problem wherein a script that
> already exists in the page will be dual-executed. Let me know if this
> affects your code - I suspect we'll learn more during the beta, as
> well.
> append-2.patch: Just in case, this is the same patch as above, but
> with the old-style of functionality intact.
> closest.patch: This adds a new method: .closest(selector). You can
> think of it as .firstSelfOrAncestor. This has been a commonly
> requested function and it will make implementing delegation code
> trivial.
> domready.patch: An overhaul of the ready code, removing the the "wait
> for stylesheets to load" logic. I did a bunch of testing on this and
> it really appears as if it's impossible to get proper stylesheet
> loading detection implemented (I wanted to have a "cssready" event for
> 1.3, but it's not looking likely). Instead we need to back off and
> simply provide normal DOM ready functionality in .ready(). This means
> that we need to educate users to include their stylesheets before
> their scripts in order for them to be accessible in time for DOM
> ready.
> multi-namespace.patch: This adds multiple-namespace support to events.
> Previously you could only do it with one namespace e.g.
> .bind("click.foo") or .trigger("click.foo"). The patch allows you to
> use any number of namespaces e.g.
> .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
> selector.patch: Adds a new internal property that keeps track of the
> selector chain.
> $("div").find("span").filter(":hidden").parent().selector == "div
> span.filter(:hidden).parent()". This is meant to be used by plugins
> (like liveQuery), primarily. The implementation of selectors like
> .parent() will be coming in a follow-up patch along with Sizzle.
> strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
> a few minor tweaks necessary.
> I have the following patches coming:
> - Landing Sizzle
> - Landing .parent()/.filter()/etc. selector implementation.
> - Native event delegation
> - Removing the remaining uses of jQuery.browser
Maybe I got it wrong, but I think the main idea was to create a method that could be used several times, if needed, to test the elements existance, say, on a variable pointing to a jQuery object... for example, if you need to test an array element several times during a processing, and, if at some point it relates to a non-existant element, it's removed from the list, thus preventing a memory leak. I thought about this situation because I already passed by one of this kind, but maybe I'm thinking of something that may not be that necessary to everyone, though...
Just synthetizing the discussion on the group thread, this is the difference between the first and the last implementations of the method - during a 1000 iterations test -:
- First implementation: 451ms on my machine (using traversal);
- Last: 43ms on my machine (using native code to test document elements supporting also iframes and XML).
Thank you :-)
Diogo
P.S.: Someone has told me jQuery might have some native implementation in some future Firefox version... maybe just a silly rumour? Nevertheless, it would be interesting how one would put hands on the FF C source code and insert a fast as hell jQuery in it... :-)
> I would rather shoot for something that's a little more idiomatic to
> jQuery. For example jQuery already has a way to figure out if an
> element contains a selector: "div:has(a)".
> Thus, I think a better result would be:
> $("div").has("a") // true
> $(document).has("div") // true
> $(document).has(document.getElementsByTagName("div")[0]); // true
> --John
> On Tue, Dec 16, 2008 at 4:37 PM, Diogo Baeder <diogobae...@gmail.com> wrote:
>>> This is in addition to the Sizzle selector engine patch which I posted
>>> a little bit ago (and which I'll be making an updated version of very
>>> soon).
>>> The patches are as follows:
>>> append.patch: Use DocumentFragment in .domManip. This is a large
>>> overhaul of .domManip (and moves some of the logic into jQuery.clean).
>>> The result is that manipulation code (append/prepend/etc.) is about
>>> 15x faster. During this overhaul I made a change to how scripts are
>>> executed. Roughly it means that scripts that are brought in as a
>>> string and inserted are executed - but scripts that exist as DOM nodes
>>> are not. This will solve the common problem wherein a script that
>>> already exists in the page will be dual-executed. Let me know if this
>>> affects your code - I suspect we'll learn more during the beta, as
>>> well.
>>> append-2.patch: Just in case, this is the same patch as above, but
>>> with the old-style of functionality intact.
>>> closest.patch: This adds a new method: .closest(selector). You can
>>> think of it as .firstSelfOrAncestor. This has been a commonly
>>> requested function and it will make implementing delegation code
>>> trivial.
>>> domready.patch: An overhaul of the ready code, removing the the "wait
>>> for stylesheets to load" logic. I did a bunch of testing on this and
>>> it really appears as if it's impossible to get proper stylesheet
>>> loading detection implemented (I wanted to have a "cssready" event for
>>> 1.3, but it's not looking likely). Instead we need to back off and
>>> simply provide normal DOM ready functionality in .ready(). This means
>>> that we need to educate users to include their stylesheets before
>>> their scripts in order for them to be accessible in time for DOM
>>> ready.
>>> multi-namespace.patch: This adds multiple-namespace support to events.
>>> Previously you could only do it with one namespace e.g.
>>> .bind("click.foo") or .trigger("click.foo"). The patch allows you to
>>> use any number of namespaces e.g.
>>> .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
>>> selector.patch: Adds a new internal property that keeps track of the
>>> selector chain.
>>> $("div").find("span").filter(":hidden").parent().selector == "div
>>> span.filter(:hidden).parent()". This is meant to be used by plugins
>>> (like liveQuery), primarily. The implementation of selectors like
>>> .parent() will be coming in a follow-up patch along with Sizzle.
>>> strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
>>> a few minor tweaks necessary.
>>> I have the following patches coming:
>>> - Landing Sizzle
>>> - Landing .parent()/.filter()/etc. selector implementation.
>>> - Native event delegation
>>> - Removing the remaining uses of jQuery.browser
Oops, John, sorry, I think I misunderstood your message... did you mean
implementing a "has" method by using native "contains" and
"compareDocumentPosition"? If yes, it seems much more reasonable, since it
can be applied to other nodes than document.documentElement or
someElement.ownerDocument...
On Wed, Dec 17, 2008 at 5:42 PM, Diogo Baeder <diogobae...@gmail.com> wrote:
> Hi, John,
> Maybe I got it wrong, but I think the main idea was to create a method that
> could be used several times, if needed, to test the elements existance, say,
> on a variable pointing to a jQuery object... for example, if you need to
> test an array element several times during a processing, and, if at some
> point it relates to a non-existant element, it's removed from the list, thus
> preventing a memory leak. I thought about this situation because I already
> passed by one of this kind, but maybe I'm thinking of something that may not
> be that necessary to everyone, though...
> Just synthetizing the discussion on the group thread, this is the
> difference between the first and the last implementations of the method -
> during a 1000 iterations test -:
> - First implementation: 451ms on my machine (using traversal);
> - Last: 43ms on my machine (using native code to test document elements
> supporting also iframes and XML).
> Thank you :-)
> Diogo
> P.S.: Someone has told me jQuery might have some native implementation in
> some future Firefox version... maybe just a silly rumour? Nevertheless, it
> would be interesting how one would put hands on the FF C source code and
> insert a fast as hell jQuery in it... :-)
> John Resig escreveu:
> Diogo -
>> I would rather shoot for something that's a little more idiomatic to
>> jQuery. For example jQuery already has a way to figure out if an
>> element contains a selector: "div:has(a)".
>> Thus, I think a better result would be:
>> $("div").has("a") // true
>> $(document).has("div") // true
>> $(document).has(document.getElementsByTagName("div")[0]); // true
>> --John
>> On Tue, Dec 16, 2008 at 4:37 PM, Diogo Baeder <diogobae...@gmail.com>
>> wrote:
>>> Great ones, John!
>>> What about "isOrphan()" or "inDOM()" methods, to prevent uneeded JS
>>> processing for non-existant elements, as discussed before?:
>>>> This is in addition to the Sizzle selector engine patch which I posted
>>>> a little bit ago (and which I'll be making an updated version of very
>>>> soon).
>>>> The patches are as follows:
>>>> append.patch: Use DocumentFragment in .domManip. This is a large
>>>> overhaul of .domManip (and moves some of the logic into jQuery.clean).
>>>> The result is that manipulation code (append/prepend/etc.) is about
>>>> 15x faster. During this overhaul I made a change to how scripts are
>>>> executed. Roughly it means that scripts that are brought in as a
>>>> string and inserted are executed - but scripts that exist as DOM nodes
>>>> are not. This will solve the common problem wherein a script that
>>>> already exists in the page will be dual-executed. Let me know if this
>>>> affects your code - I suspect we'll learn more during the beta, as
>>>> well.
>>>> append-2.patch: Just in case, this is the same patch as above, but
>>>> with the old-style of functionality intact.
>>>> closest.patch: This adds a new method: .closest(selector). You can
>>>> think of it as .firstSelfOrAncestor. This has been a commonly
>>>> requested function and it will make implementing delegation code
>>>> trivial.
>>>> domready.patch: An overhaul of the ready code, removing the the "wait
>>>> for stylesheets to load" logic. I did a bunch of testing on this and
>>>> it really appears as if it's impossible to get proper stylesheet
>>>> loading detection implemented (I wanted to have a "cssready" event for
>>>> 1.3, but it's not looking likely). Instead we need to back off and
>>>> simply provide normal DOM ready functionality in .ready(). This means
>>>> that we need to educate users to include their stylesheets before
>>>> their scripts in order for them to be accessible in time for DOM
>>>> ready.
>>>> multi-namespace.patch: This adds multiple-namespace support to events.
>>>> Previously you could only do it with one namespace e.g.
>>>> .bind("click.foo") or .trigger("click.foo"). The patch allows you to
>>>> use any number of namespaces e.g.
>>>> .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo").
>>>> selector.patch: Adds a new internal property that keeps track of the
>>>> selector chain.
>>>> $("div").find("span").filter(":hidden").parent().selector == "div
>>>> span.filter(:hidden).parent()". This is meant to be used by plugins
>>>> (like liveQuery), primarily. The implementation of selectors like
>>>> .parent() will be coming in a follow-up patch along with Sizzle.
>>>> strict.patch: Makes it so that we pass strict mode in Firefox 3. Only
>>>> a few minor tweaks necessary.
>>>> I have the following patches coming:
>>>> - Landing Sizzle
>>>> - Landing .parent()/.filter()/etc. selector implementation.
>>>> - Native event delegation
>>>> - Removing the remaining uses of jQuery.browser
|
