here is no (for now) symmetry between
attr("height", ...) and attr("height")
I am afraid, that I will not be the only confused one...
On Dec 17, 7:50 am, Robert Katić wrote:
> > > If we have
>
> > > $(xml).find("foo").attr("height",
> > If we have
>
> > $(xml).find("foo").attr("height", "180cm")
>
> > then you would expect calling elem.setAttribute() and not .height(), I
> > hope.
> > If so, there is a bug in jQuery.attr()...
>
> So we could disable it on XML documents - but regardless, that is
> definitely th exception.
I h
I would note some problems (2):
If we have
$(xml).find("foo").attr("height", "180cm")
then you would expect calling elem.setAttribute() and not .height(), I
hope.
If so, there is a bug in jQuery.attr()...
Other think to take in consideration is that
$("div").attr("click", function(){ /*..*
9 at 4:16 AM, caii wrote:
> > Array.prototype.indexOf?
> > where it in JQUERY?
>
> > On Dec 14, 6:13 pm, Robert Katić wrote:
> >> Already fixed. If Array.prototype.indexOf exists, then it is always
> >> used.
>
> >> On Dec 14, 10:38 am, helianthus w
Already fixed. If Array.prototype.indexOf exists, then it is always
used.
On Dec 14, 10:38 am, helianthus wrote:
> This occurs when using jQuery.fn.index, which utilizes jQuery.inArray.
> Since the jQuery object does not have an indexOf method, it falls back
> to the for loop approach, while Arra
> I disagree. Being able to set all the (useful) properties of a DOM
> element via a single object structure can be very useful - and I see
> no reason not to overload the existing .attr() behavior if it already
> covers most of the functionality well and if there are no conflicts. I
> especially t
> I think one of the core problems is understanding what attr() is
> intended to do. Clearly it is not just a get/setAttribute wrapper.
> Clearly it is not just meant to access the properties of elements. It
> is a mixture of several different ways to access "attributes" of an
> element, and it app
Well, I already had proposed this a month ago in the discussion
http://groups.google.com/group/jquery-dev/browse_frm/thread/588fe6d162845290/
(message #6).
There you will see that my solution (http://gist.github.com/227508)
was almost same as your, and that John at #12 was of idea that that
was ea
Now that jQuery.makeArray(nodeList) is supported correctly, maybe it
is wanted to make that also for jQuery.each, jQuery.map and
jQuery.grep.
There are mainly two reasons why I think it is worth of consideration:
1. $.each(nodeList) is already possible and I suppose that there are
individuals tha
Thanks to http://dev.jquery.com/ticket/3995
On 15 stu, 11:22, DBJDBJ wrote:
> I noticed this by accident (I had a bug in some speed tests)
> If i give them both an array of size 1e5, the latest one is twice as
> fast as 1.2.6 ?
>
> var A[1e5], j=1e5; while(j--) A[j] = j ;
>
> $140(A), exits (on
this may have gotten
> munged in the overhaul done by Yehuda.
>
> If you want to make a patch with some good test cases I'll happily land it.
>
> --John
>
> On Wed, Nov 11, 2009 at 3:27 AM, Robert Katić wrote:
> > Ah, yes, since options.nodes was already defined before
worse.
I have to suppose that the author was drunk when he was writing it. :)
Am I missing something?
On Nov 11, 8:16 am, Robert Katić wrote:
> I don't get your point. I am talking about what is extended
> recursively, not what is passed as argument.
>
> If you have something l
licitly prevent
> this behavior, at least.
>
> (On a related note I've renamed isObject to isObjectLiteral.)
>
> --John
>
> On Tue, Nov 10, 2009 at 9:10 PM, Robert Katić wrote:
> > Wat a hell is going here?
>
> > // Recurse if we're merging object valu
Wat a hell is going here?
// Recurse if we're merging object values
if ( deep && copy && typeof copy === "object" && !copy.nodeType ) {
var clone;
if ( src ) {
clone = src;
} else if ( jQuery.isArray(copy) ) {
clone = [];
} else if ( jQuery.isObject(copy) ) {
clone = {};
}
> PS: I do not see that Robert solution fails on empty function? aka :
> function () { }
I think no one said that. I said that "classes" with no methods
(prototype with no properties) are not supported by my solution.
var Class = function(){};
var obj = new Class();
isObject( obj ) // true!
Cla
isObject a lot (http://gist.github.com/158651).
So, I will suppose that unit test is wrong, for now, and I added an
another patch to http://dev.jquery.com/ticket/5474 that corrects it.
On Nov 8, 11:31 pm, John Resig wrote:
> Thanks!
>
>
>
> On Sunday, November 8, 2009, Robert Katić
I opened a ticket: http://dev.jquery.com/ticket/5475
On Nov 8, 12:50 am, Robert Katić wrote:
> oops: "evaluated without context"
>
> On Nov 8, 12:48 am, Robert Katić wrote:
>
> > I detect only now that in closest method the selector is evaluated
> > without
http://dev.jquery.com/ticket/5474
On Nov 8, 2:13 pm, John Resig wrote:
> > constructor property is often changed.
> > I hope you want isObject(jQuery()) == false.
>
> Yep, and that'll work as we expect it to. The one case where it won't
> is if you do obj.constructor = Object;
>
> If anyone think
Yes, it passes all these tests.
On Nov 8, 4:57 pm, John Resig wrote:
> > I thing so, but not sure 100%. This seam a good task for TestSwarms.
>
> Well, we can do that eventually - but in the short term: Does it work on IE?
>
> --John
--
You received this message because you are subscribed to th
http://browsershots.org/http://bender.fesb.hr/~robert/scripts/isObjectLiteral.html
Let's see...
On Nov 8, 4:42 pm, Robert Katić wrote:
> I thing so, but not sure 100%. This seam a good task for TestSwarms.
>
> On Nov 8, 4:38 pm, John Resig wrote:
>
> > >http://gist.gi
I thing so, but not sure 100%. This seam a good task for TestSwarms.
On Nov 8, 4:38 pm, John Resig wrote:
> >http://gist.github.com/229254
>
> Does this handle all the tests on that page? and in IE 6/7/8 as well?
>
> If so, let's land it.
>
> --John
--
You received this message because you are
http://gist.github.com/229254
On Nov 8, 2:13 pm, John Resig wrote:
> > constructor property is often changed.
> > I hope you want isObject(jQuery()) == false.
>
> Yep, and that'll work as we expect it to. The one case where it won't
> is if you do obj.constructor = Object;
>
> If anyone thinks of
/^function Object/.test( jQuery().constructor ) == true
You don't need to explicitly set constructor to change it.
Redefining prototype, constructor is automatically altered (==Object).
On Nov 8, 2:13 pm, John Resig wrote:
> > constructor property is often changed.
> > I hope you want isObject(j
> Right now the:
> return /^function Object/.test( obj.constructor );
>
> solution works the best but it doesn't work in Opera Mini (which
> doesn't have function decompilation) - nor is it particularly fast.
constructor property is often changed.
I hope you want isObject(jQuery()) == false.
--
Native functions in IE is not handled correctly by isFunction either,
but it was decided that that cases are not significant...
On Nov 8, 12:23 pm, DBJDBJ wrote:
> This version of isObject, in IE returns true, when tested with
> window.alert ...
>
> --DBJ
--
You received this message because yo
Maybe something like http://gist.github.com/229188 would be enough.
On Nov 7, 12:57 am, John Resig wrote:
> Yehuda was working through that code and didn't get a chance to finish
> it up. Yehuda, any thoughts?
>
> --John
>
> On Sat, Nov 7, 2009 at 12:05 AM, lrbabe wrote:
> > In the current imple
oops: "evaluated without context"
On Nov 8, 12:48 am, Robert Katić wrote:
> I detect only now that in closest method the selector is evaluated
> without selector.
> I am not sure which context is more correct: (context || this.context)
> or it have to be a document?
>
&
situation.
On Nov 7, 5:58 pm, John Resig wrote:
> I've already landed the commits - looks great - thanks! (I'll close
> the ticket once my network stops flaking out.)
>
> --John
>
> On Sat, Nov 7, 2009 at 5:47 PM, Robert Katić wrote:
> > I opened a ticket:http://d
I opened a ticket: http://dev.jquery.com/ticket/5470
with link on commit.
Commit also includes context inside liveHandler (it is a too small
change to make a separate commit).
Component is "unfiled". Please tell me if I made mistakes opening this
ticket.
On Nov 6, 3:01 pm, John Resig wrote:
> >
Regarding improving live(), I would note two things about liveHandler:
1. Calling closest, context argument still is not used.
I was unable to find the proper ticket. Would I open one?
2. Storing "how much a parent is close to an element" with data API is
an big overhead. An jQuery.lastCloser or
e goes here.
> });
> });
>
> Still pretty simple and requires no additional functionality. I may
> just write this up as an example and add it to the live and closest
> docs.
>
> --John
>
>
>
> On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić > wrote:
>>
st("td.foo", this).each(function(){
> // Your code goes here.
> });
> });
>
> Still pretty simple and requires no additional functionality. I may
> just write this up as an example and add it to the live and closest
> docs.
>
> --John
>
>
>
> On Fr
$("#someRootTable").delegate("td.foo", "click", function(e){
// Your code goes here.
});
Would be easer and safer because the event will be handlet only by
"td.foo" elements inside "#someRootTable".
--Robert
On 6. stu. 2009., at 04:56, John Resig wrote:
> $("#someRootTable").click(functi
ot;,"click", func).
>
> It almost makes too much sense :).
>
> On Nov 5, 6:31 pm, Robert Katić wrote:
>> I wonder why there would be an $.live with document as the only
>> interesting context.
>>
>> Something like
>>
>> $(document
I wonder why there would be an $.live with document as the only
interesting context.
Something like
$(document).zombi(selector, type, ...)
would be more flexible (I know, "zombi" is not nice, but I have no
inspirations about a more suitable name).
To avoid to repeat selector on multiple bindi
Well if $() is same as $([]), then instead of
if ( !selector ) {
return this;
}
in $.fn.init, we can put
if ( selector == null ) {
return this;
}
This would eliminate the $(0) "unexpected" behavior.
On Nov 1, 3:28 pm, John Resig wrote:
> This changed slightly in the latest nightlies - if
while ( (elem = second[ i++ ]) != null ) {
> > first[ pos++ ] = elem;
> > }
> > }
> > return first;
> > }
>
> > --Karl
> >
> > Karl Swedberg
> >www.englishrules.com
> >www.learningjquery.com
>
> > On Oct 30, 2009
Ticket: http://dev.jquery.com/ticket/5434
On Oct 30, 3:33 pm, John Resig wrote:
> This seems reasonable, as well. Can you file a ticket? Thanks.
>
> --John
>
> On Fri, Oct 30, 2009 at 2:06 AM, Robert Katić wrote:
> > Sorry, I posted an old version of code. Here the new one
> I think it should make the following expression evaluate to true:
>
> object && object.constructor === Object
> ( I'm not sure if it's strict enough, but what I mean is that the
> object should be constructed by Object )
This is technically a more complex problem then you think.
There was an Joh
even then
it seams that there are some inconsistent logic.
On Oct 30, 6:28 am, Robert Katić wrote:
> jQuery.merge() is the only function that discards comment nodes (?).
>
> This means that
>
> $( nodeList )
>
> can contains comment nodes, but
>
> $([]).add( nodeList
> var hash = { a: 1, b: 2 }
>
> $.map( hash, function( val, key ) {
> if( key === 'a')
> return { c: 3, d: 4 };
> else
> return val;
>
> });
>
> And now hash is { c: 3, d: 4, b: 2 }. It doesn't conflict with
> anything.
Can you explain which objects you expect would extend
> But making map() functions work on hashes makes sense, so why rule
> them out?
There are at least three reasons why this is not a good idea:
1. $.map() is not a real "general purpose" map function. If callback
returns an array then its items will be values because in same cases
it is convenient
is.context && (this.context.ownerDocument ||
this.context)
|| this[0] && (this[0].ownerDocument || this[0]) ) :
jQuery.makeArray( selector )
)));
};
On Oct 30, 6:55 am, Robert Katić wrote:
> Using $.fn.add(selector) the context property remains the s
Using $.fn.add(selector) the context property remains the same.
It's ok, but the given selector will be applied always with the
default context (document).
This is not correct for me if we are using jQuery with xml documents
for example.
$("user", xmlDoc).add("lusers");
There is no way to add
jQuery.merge() is the only function that discards comment nodes (?).
This means that
$( nodeList )
can contains comment nodes, but
$([]).add( nodeList )
can not.
Why such different behaviors?
Is the jQuery.makeArray() more appropriate to filter comment nodes?
Am I missing something here?
ind of array, and I figure it'd be appropriate to
> let $.map() also work for it.
>
> On Oct 30, 3:20 am, Robert Katić wrote:
>
> > Be warned that $.map() is designed to work on a sequence of DOM
> > elements. Although it would work with other values too, callback
> >
Be warned that $.map() is designed to work on a sequence of DOM
elements. Although it would work with other values too, callback
results are not handled as you probably expect: null and undefined
values are discarded and arrays are merged to the final array.
In your case an classic for(key in obj)
Be warned that $.map() is designed to work on a sequence of DOM
elements. Although it would work with other values too, callback
results are not handled as you probably expect: null and undefined
values are discarded and arrays are merged to the final array.
In your case an classic for(key in obj)
ta object creation, then $.data(elem) is certainly my favorite
candidate (with no name and data arguments).
On Oct 18, 11:38 am, Robert Katić wrote:
> I played a little on some variations of $.data() API and concluded
> with these:
>
> $.data(elem, readOnly) ->http://pastebin.com/f323b
in IE. Also
> via new Number the behavior is a bit more standard (Firefox and other like)
>
> On Sun, Oct 18, 2009 at 1:27 AM, Robert Katić wrote:
>
>
>
> > If I was not clear enough here are some codehttp://pastebin.com/m14c0aa3b
>
> > PS: For now, I am not sure if
yet, but if we consider $.data() a "low
level" part of API, then I prefer firs version.
Opinions?
On Oct 18, 2:57 am, Robert Katić wrote:
> Yes there is a big error in my code. Here is new
> onehttp://pastebin.com/d66929de4
>
> On Oct 18, 1:27 am, Robert Katić wrote:
>
>
Yes there is a big error in my code. Here is new one
http://pastebin.com/d66929de4
On Oct 18, 1:27 am, Robert Katić wrote:
> If I was not clear enough here are some codehttp://pastebin.com/m14c0aa3b
>
> PS: For now, I am not sure if new Number(...) is necessary and that it
> is
If I was not clear enough here are some code http://pastebin.com/m14c0aa3b
PS: For now, I am not sure if new Number(...) is necessary and that it
is safe enough.
On Oct 18, 1:05 am, Robert Katić wrote:
> I am certainly in favor to that that $.data(elem) returns data object
> instead
I am certainly in favor to that that $.data(elem) returns data object
instead of id.
I would like that $.data() will not handle getting/setting too, but
then we would probably consider how to handle getting without
generating the data object. Maybe an $.data(elem, true) to get data
object without
Hi Andrea. Nice solution.
Using array instead of object is a nice speed boost (at least on Fx
3.5).
However, I suppose that an _index will not be necessary in jQuery.
Honestly I consider that $.data() would be exactly as your $.proxy()
(the simpler one).
Now that $.data returns the data object of
Ticked opened: http://dev.jquery.com/ticket/5303
On Sep 17, 5:31 pm, Robert Katić wrote:
> ?
>
> On Aug 27, 4:32 am, Robert Katić wrote:
>
> > I suppose it is rear to use multiple namespaces to unbind aneventand
> > that it is the reason why no one spotted t
if ( obj.jquery )
//obj is an jQuery object
jquery property gives the jQuery version, that is always an non empty
string
On Sep 18, 1:50 am, lrbabe wrote:
> mmmh... overwriting the constructor property doesn't sound like a
> great idea to me.
> What about all the code that has been written b
?
On Aug 27, 4:32 am, Robert Katić wrote:
> I suppose it is rear to use multiple namespaces to unbind aneventand
> that it is the reason why no one spotted this bug (I spotted it by
> examining code, not by using the feature).
>
> This is the problem:
>
> $("div")
I suppose it is rear to use multiple namespaces to unbind an event and
that it is the reason why no one spotted this bug (I spotted it by
examining code, not by using the feature).
This is the problem:
$("div").bind("click.aaa.bbb", function(){...});
$("div").unbind("click.a.bbb"); //this is un
I suppose it is rear to use multiple namespaces to unbind an event and
that it is the reason why no one spotted this bug (I spotted it by
examining code, not by using the feature).
This is the problem:
$("div").bind("click.aaa.bbb", function(){...});
$("div").unbind("click.a.bbb"); //this is un
Actually the ticket about .get(-1) (http://dev.jquery.com/ticket/4188)
(opened by me), have changes about eq(-1) too.
I was wondering why it was ignored.
On Aug 14, 2:19 pm, John Resig wrote:
> I don't see why not - we already support .get(-1), .eq(-1) makes sense. Want
> to file a feature ticke
Test http://pastebin.com/m5279ff23
jquery.ns.js http://pastebin.com/m36dd0f2
Testing it on other browsers
http://browsershots.org/http://bender.fesb.hr/~robert/scripts/test-jquery.ns.js.html
--~--~-~--~~~---~--~~
You received this message because you are subscribed
l take a look when I have time this weekend.
>
> You think you might be up for a collaborative effort and maybe
> throwing some ideas back and forth? Most likely off-list.
>
> On Aug 14, 3:21 am, Robert Katić wrote:
>
> > @tres
>
> > You made me thinking about na
system would be, than I
> suggest to look jQuery UI"
>
> Look, man, that really is unnecessary. I am sorry if I insulted you.
>
> On Aug 13, 12:24 pm, Robert Katić wrote:
>
> > Tres, I know that you are not insulting me purposely.
> > Unfortunately that means that you
system would be, than I
> suggest to look jQuery UI"
>
> Look, man, that really is unnecessary. I am sorry if I insulted you.
>
> On Aug 13, 12:24 pm, Robert Katić wrote:
>
> > Tres, I know that you are not insulting me purposely.
> > Unfortunately that means that you
n jQuery, I think our
> end result should be to further the development and future of the
> library as a team, not individuals. Just because we aren't part of the
> core team doesn't mean we aren't a team.
>
> Please, back to the actual topic...
>
> On Aug 13, 11:49
his can very well
> be applied to the jQuery namespace.
>
> http://www.dustindiaz.com/namespace-your-javascript/, another way for
> private members, but similar in practice
>
> As for who expects .dialog() to return a namespace rather than display
> something: When you call jQuery, what
@DBJ
I am not sure who expects that $('div').dialog() gives a namespaces
instead of creating or displaying something..
On Aug 13, 1:29 am, DBJDBJ wrote:
> The big picture
>
> // this is so much more right
> $('div').dialog().open();
> // than this
> $('div').dialog('open');
>
> In more than one
@tres
An plugin/widget system is about widgets, not DOM elements.
If you have to extend jQuery adding some DOM related stuff, you will
continue to add that stuff to jQuery or jQuery.fn directly or with
extend().
Closures are great to make "private" things, but it requires that
"public" functions
I think you are right that jQuery needs an widget system, but $
(..).dialog().open() does not look better than $(..).dialog('open') to
me,
Namespaces doesn't fit well within jQuery. Implementation would be
really dirty.
I made an my solution for plugin authoring with inheritance
http://bender.fes
Tvoj english uopste nije los ...
>
> -- DBJ
>
> On May 14, 6:17 am, Robert Katić wrote:
>
> > I suppose you ALWAYS use delegation to define an is-a class
> > relationship.
> > If so, I am sorry for you.
>
> > Inheritance is an easier way to define an is-a re
There is no need to take in consideration eventual length updates;
that slows considerably, and it is not garanted in any/each native
implementation:
https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_Objects/Array/ForEach
On May 21, 5:39 pm, Andrea Giammarchi
wrote:
> IE8? o
I suppose you ALWAYS use delegation to define an is-a class
relationship.
If so, I am sorry for you.
Inheritance is an easier way to define an is-a relationship.
Unfortunately it is often overused.
Unfortunately changes to super-class can easily break sub-classes,
specially in script languages wh
I made some drastic changes to the my solution (http://bender.fesb.hr/
~robert/jquery.plugin.js).
Some examples included.
I am conscious that it would be more elegant to provide this._super
feature, but i think it would make debugging more hard ('finally'
without 'catch' is not well supported by
e "new" operator, you
will use "$" static method to create an instance...
Hope this short intro will make my solution more clear to understand.
On May 5, 3:30 am, John Resig wrote:
> It's not completely clear what your code does or how it would be used, from
> looki
After some readings on the "A Modest Proposal: jQuery Enterprise"
discussion at
http://groups.google.com/group/jquery-dev/browse_frm/thread/1ec4dca6e02616d6#,
it is clear that jQuery needs an own widget system that will expose an
standard way to write widgets/plugins. This need is more evident on
ow point in the catch, and not the
> original location.
>
> Additionally, using setTimeout is no good because the return results
> from the functions need to be handled synchronously.
>
> --John
>
> On Wed, Mar 25, 2009 at 12:32 AM, Robert Katić wrote:
>
> > What
you will implement something that will not throw
ALL errors, because it would hide some errors if an required third-
part plug-in already throws some.
If it is too hard to ensure all throws, than I certainly prefer the
current solution.
> --John
>
> On Wed, Mar 25, 2009 at 12:32 AM,
What about this:
function runHandlers(){
var h;
try {
while ( (h = handlers.shift()) ) {
h();
}
} catch (e) {
setTimeout(runHandlers);
throw e;
}
}
var handlers = [
function(){
throw "A";
},
function(){
throw "B";
}
];
This one will throw both (all)
I am wondering if it would be necessary to check if (i in object) too,
in future (with i < length). I hope not :).
On Mar 17, 2:29 pm, John Resig wrote:
> Would you be open to filing a bug on this? Thanks.
>
> What a stupid behavior on the part of IE.
>
> --John
>
> On Tue, Mar 17, 2009 at 3:35
This is more nicer (less confusions with parenthesis):
$('input[value='+$(this).text()+']').eq(0).remove();
Also, this has the advantage to preserve the query in the chain:
$('input[value='+$(this).text()+']')
.eq(0)
.remove()
.end()
.slice(1)
.addClass('.survived');
Also this wo
This is more nicer (less confusions with parenthesis):
$('input[value='+$(this).text()+']').eq(0).remove();
Also, this has the advantage to preserve the query in the chain:
$('input[value='+$(this).text()+']')
.eq(0)
.remove()
.end()
.slice(1)
.addClass('.survived');
On Mar 11, 5:
> eq: function( i ) {
> var el = [ this[ i<0 ? i+this.length : i] ];
> if (el[0] === undefined) el.length = 0;
> return this.pushStack( el, 'eq', i );
> };
Yes, I supposed it was an mistyping. Now this is safe in case of "out
of range" but is not in case with an undefined value as ele
:
>
> eq: function( i ) {
> var el = [ this[ i<0 ? i+this.length : i] ];
> if (el[0] === undefined) el.length = 0;
> return this.pushStack( el, 'eq', i );
>
> };
>
> It doesn't seem possible to pass the undefined object along. Anyone
> doing that?
nt). Does these are supported or not is not relevant here, I
think.
I would like to have an John opinion if we have to support undefined
values inside an jquery object, and would it be dangerous to break
this support.
>
> On Mar 3, 5:47 pm, Robert Katić wrote:
>
> > > jQ
> jQuery([undefined])[0] === jQuery([])[0]
Yes, but
jQuery([undefined]).length !== jQuery([]).length
> eq() always returns a single element, so you'd only need to allow null/
> NaN/""/etc to pass through, I guess:
In the current implementation, eq(i) returns the value (not only
nodes) at
Since no one is correcting me, I will do it myself, again :)
We always have to pass an array to pushStack because it will ensure
that the value will not processed as an selector or html or document,
but simply as an array with values to set.
eq: function( i ) {
var j = i < 0 ? +i + this.leng
Yes, I made an writing error. The second case (!his[i]) would return
an jquery with the not-true value instead of an empty one. This was
the reason of Ricardo's not entirely correct solution, I suppose.
On Mar 2, 10:10 pm, Robert Katić wrote:
> I figured out (unfortunately not before)
k( el || [], 'eq', i )
>
> }
>
> No loss of performance with this one.
>
> - ricardo
>
> On Mar 2, 6:10 pm, Robert Katić wrote:
>
> > I figured out (unfortunately not before) that the main reason why the
> > current implementation uses slicing is to e
I figured out (unfortunately not before) that the main reason why the
current implementation uses slicing is to ensure correct behavior in
case of "index out of range" and in case of !this[i].
Here proposed solutions will not return an empty jquery in that cases,
but an jquery with the document el
resorting to get (and without
> affecting performance) by using a ternary:
>
> jQuery.fn.eq = function( i ) {
> return this.pushStack( this[i<0 ? i+this.length : i], 'eq', i )
>
> }
>
> cheers,
> - ricardo
>
> On Feb 28, 8:42 pm, Robert Katić wrote:
An slightly slower but more robust solution would be:
eq: function( i ) {
return this.pushStack( this.get(i), 'eq', i )
}
The main difference is that the ret.selector would preserve the
initial index (relative if negative).
On Feb 28, 9:44 pm, Robert Katić wrote:
> If
If this solution seems ok, I would update the ticket
http://dev.jquery.com/ticket/4188.
On Feb 28, 8:50 pm, ricardobeat wrote:
> Nice catch, that makes sense. Added it to the test page, it has no
> significant impact on performance.
>
> cheers,
> - ricardo
>
> On Feb 27,
Since .get(-1) will be supported, eq(-1) would be supported too (?).
So your implementation needs some extra code:
eq: function( i ) {
if ( i < 0 )
i += this.length;
return this.pushStack( this[i], 'eq', i )
}
However this solution would be still faster then the one on
http://de
If I am not wrong, 'push', 'sort' and 'splice' functions are used only
in Sizzle (before the jQuery obj returns to the user), so it would be
safe to redefine those in plugins. Am I wrong?
On Feb 23, 10:19 pm, prefect wrote:
> I upgraded to jQuery 1.3.2 this evening, and was surprised by a weird
@John
jQuery uses some Sizzle internal details to gain some performance
enhancements.
If so, it is ok to me, but is it so much faster to pass jQuery empty
instance to Sizzle to avoid an $.fn.setArray call? I suppose that
array operations are pretty faster on Array instances.
On Feb 23, 10:24 pm,
ticket about this enhancement on
http://dev.jquery.com/ticket/4188.
On Feb 19, 8:46 pm, Justin Beasley wrote:
> I agre with this course of action also. I think it offers the best of
> both worlds, plus an extra dose of clarity.
>
> On Jan 26, 3:27 pm, Robert Katić wrote:
>
&g
I founded an error in my code.
Instead of
array.splice(i--, 1);
goes
array.splice(i, 1);
On Feb 17, 8:59 am, Robert Katić wrote:
> To ensure order and uniqueness with XML and non current documents too,
> we have to ensure that the NodeList "allSort" is the correct one.
&
To ensure order and uniqueness with XML and non current documents too,
we have to ensure that the NodeList "allSort" is the correct one.
Maybe something like this:
function sortNodes( array ) {
if ( array.length === 0 )
return;
if ( allSort && allSort._document !=
duplicates too. Am I corect?
On Feb 16, 3:04 pm, Robert Katić wrote:
> Maybe I was not clear. I don't think it is wrong to live results
> unsorted if given as argument (if it was planed), but then we can take
> this in consideration to do optimizations...
>
> On Feb 16, 2:53 pm,
1 - 100 of 118 matches
Mail list logo
