1) I cannot find the rationale for this. Or even where this bug is
discussed. Can anyone point me to it? I am curious.
// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == selected
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for example), and
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and documenting what to expect from each would be fantastic.
Excellent, appreciate your help!
Doing a Google Code Search yields lots of interesting edge
to
the same thing, but no they don't because you removed the elements.
This makes sense to me. As far as I know, no matter how you remove
elements they are not part of the document any more. Isn't that the
point of removing them?
Devon
On Dec 14, 11:48 pm, John Resig jere...@gmail.com wrote
The case is precisely it: We do it that way because we need to support
array-like objects as well. (The docs are written in that particular
manner because saying .inArray(ArrayLikeObject) would probably just
confuse the issue.)
If the difference is between doing an extra .call() (which is slower
jQuery UI does a similar thing (overriding .remove() to generate a
.trigger(remove) event). Would something like that work for your
needs?
--John
On Mon, Dec 14, 2009 at 11:43 AM, Justin Meyer justinbme...@gmail.com wrote:
Is there a 'teardown' for plugins that can get triggered automatically
Hello -
This is done not for a technical reason but due to the fact that
submit buttons are only sent to the server if they're clicked by the
user. I highly recommend the form plugin for handling this case as
it'll bind a click handler and watch to see which submit button is
clicked and serialize
Do you have any example code that triggers this error? That would
certainly help to diagnose the problem. It looks like you're trying to
get a computed CSS value but are passing in an undefined name - why
that's happening would be good to know.
--John
On Mon, Dec 14, 2009 at 6:03 PM, pixeline
to
consider.
Devon
On Dec 13, 10:46 am, John Resig jere...@gmail.com wrote:
Actually, now that you bring this up, it would make a lot of sense to
just remove the element from the DOM first and /then/ go through and
clean up the child nodes, and finally re-inject the element again. I'm
Actually, now that you bring this up, it would make a lot of sense to
just remove the element from the DOM first and /then/ go through and
clean up the child nodes, and finally re-inject the element again. I'm
hesitant to do a cloneNode because of the inherent problems that exist
in Internet
for us we'd definitely appreciate it.
--John
On Fri, Dec 11, 2009 at 4:08 PM, John Resig jere...@gmail.com wrote:
For example:
input type=checkbox id=x readonly=readonly
$('#x').attr('readonly') === true
This is a boolean property of the element, not its attribute value.
The name attr
Hey Guys,
In case you haven't been following.
The full thread:
http://groups.google.com/group/jquery-dev/browse_thread/thread/baef5e91bd714033
My response:
http://groups.google.com/group/jquery-dev/msg/b8079000b547df15
--John
--
You received this message because you are subscribed to the
The most frequent case I've seen is $().ready() (which still works and
I plan on continuing to make work, at least for the time being). I
haven't really seen other cases being used in the wild - do you have
any examples?
--John
On Sun, Dec 13, 2009 at 8:06 PM, ajpiano ajpi...@gmail.com wrote:
Well, I have to admit that I am not too happy in which direction attr
() is going.
Adding to much magic is not simplifying the API to me.
If we (John) wont an method that can do everything (including
bindings!), than I would prefer it as an separate method (set() ?)
leaving rest of API as
When appending element A to set B the element is moved over in the DOM
into the first element in B. All subsequent elements are cloned
(therefore it's not left in position).
Also, there's no need to do what you outlined, just do:
$(div/).append( $(#old_parent).children() );
--John
On Sat, Dec
1) It still confuses properties and attributes, which is its biggest
problem. Behavior is unpredictable. This is bad.
Do you have any specific examples?
2) It looks like new code was added to call the jQuery method if the
requested attribute is in jQuery.fn. But what about attributes like
/code are all up now.
--John
On Fri, Dec 11, 2009 at 9:27 AM, John Resig jere...@gmail.com wrote:
Looking through the test suite a bit more it seems to have some pretty
good coverage. I'll see if I can rewrite it later today to fit within
the jQuery suite and then start handling the edge cases
For example:
input type=checkbox id=x readonly=readonly
$('#x').attr('readonly') === true
This is a boolean property of the element, not its attribute value.
The name attr() implies that it deals with attributes. But the code
actually gets/sets properties as the first line of business. I
Actually, the correct behavior would be to return an empty set, it
would seem, since that DocumentFragment is purely incidental.
Filed:
http://dev.jquery.com/ticket/5638
Fixed:
http://github.com/jquery/jquery/commit/65ebf57c1e5d7fa96536b66d4fcacbafad8dc1e5
--John
On Thu, Dec 10, 2009 at 4:40
The code as of when 1.4a1 came out was passing 100% in IE 6, 7, and 8.
I'm away from an IE-capable computer at the moment (traveling) so I'm
not sure if it's still the case - at least it was as of last Friday.
--John
On Wed, Dec 9, 2009 at 7:51 AM, Julian Aubourg aubourg.jul...@gmail.com
Although, certainly any page that lacks support for iframes is going
to also have significant problems running jQuery.
At this point though, I do agree - a bit too much magic.
--John
On Wed, Dec 9, 2009 at 9:24 AM, Dave Methvin dave.meth...@gmail.com wrote:
This creates a divergence between
Did you add this as a plugin? It doesn't seem like that's something
that we'd ship in jQuery core.
Glad to hear that it's really coming together, though!
--John
On Wed, Dec 9, 2009 at 11:33 AM, Julian Aubourg
aubourg.jul...@gmail.com wrote:
Another update: I added a jsonp over iframe
in again ;o)
PS: Yes,yes.. this is really me : DBJ
On Dec 9, 4:15 pm, John Resig jere...@gmail.com wrote:
The code as of when 1.4a1 came out was passing 100% in IE 6, 7, and 8.
I'm away from an IE-capable computer at the moment (traveling) so I'm
not sure if it's still the case - at least
/test/?T3=%3F%0D%0AZH1=xH2=PWD=T1=T2=YESMy+Name=meS1=abcS3=YESS4=sub1=NO#
Makes it quite difficult to pinpoint the issue, especially when, like me,
you know nothing about the internals of the event module :/
Maybe the redirection url itself can ring a bell for you?
2009/12/9 John Resig jere
Unless I'm misunderstanding something, isn't rtrim exactly as you
proposed, right now?
rtrim = /^(\s|\u00A0)+|(\s|\u00A0)+$/g,
--John
On Wed, Dec 9, 2009 at 6:54 PM, Mr Speaker mrspea...@gmail.com wrote:
Hey guys,
I was using 1.4a1 and I noticed that $.trim was killing ALL spaces
(not just
Thanks for digging in to this, Jeff - I'll look into it and see if
there's a potential solution.
--John
On Tue, Dec 8, 2009 at 12:00 PM, Jeff Adams j...@tinyfly.com wrote:
Hello everyone,
I've just added some new comments to an old bug #2551 (
http://dev.jquery.com/ticket/2551 ) that is
What? Never heard of that before...
That's because it's not true. DBJDBJ, please at least try to provide
correct information to people on this list, thanks.
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group,
The problem with this particular proposal is that it kind of throws
out the fact that Sizzle works right to left on the selector. We
currently evaluate the left-hand-side of the selector first ONLY if
there's an #id at the beginning. So we could, theoretically, get your
proposal to work but ONLY
at 4:06 PM, John Resig jere...@gmail.com wrote:
The problem with this particular proposal is that it kind of throws
out the fact that Sizzle works right to left on the selector. We
currently evaluate the left-hand-side of the selector first ONLY if
there's an #id at the beginning. So we could
Fixed the missing brace:
http://github.com/jquery/jquery/commit/97323d192f368fb8fa4ab8c77fbd7da99b049800
And changed the ordered of event support (and made sure it won't freak out):
http://github.com/jquery/jquery/commit/afaae84a7a56bcbb69cb772d9ea29766ad0a2aa6
I'll be moving ready into core
files = [ intro, core, suppport,
Thank you!
-will
On Dec 7, 2009, at 16:50 , John Resig wrote:
Fixed the missing brace:
http://github.com/jquery/jquery/commit/97323d192f368fb8fa4ab8c77fbd7da99b049800
And changed the ordered of event support (and made sure it won't freak
out):
http
Just landed the fix:
http://github.com/jquery/jquery/commit/b776e2b79a5b051fba3091b0b5057ae14950f7cc
Thanks!
--John
On Fri, Dec 4, 2009 at 10:52 PM, daltonlp dalto...@gmail.com wrote:
I hit this too. Logged as bug 5557:
http://dev.jquery.com/ticket/5557
The issue still exists in 1.4a1.
More details here:
http://blog.jquery.com/2009/12/04/jquery-14-alpha-1-released/
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send
is not declared properly.
After adding back a var at the beginning, the error in my app is
gone.
(Strangely, at the same line no semicolon at the end?)
On Dec 5, 4:44 am, John Resig jere...@gmail.com wrote:
More details
here:http://blog.jquery.com/2009/12/04/jquery-14-alpha-1-released/
--John
Personally, I find that the expression +new Date is obtuse and doesn't
really explain what is happening very well. You're creating an object
- then putting a plus next to it - to get some result. Is it a string?
a number? Whereas (new Date).getTime() is very explicit: You know that
you're getting
Yep - we've investigated the compiler as a solution for jQuery.
Unfortunately the best part (the advanced optimization settings)
require some significant changes to the code base in order to work
correctly - and even then it's not entirely clear that it'll provide a
benefit over the basic
I confirm that jQuery.isObjectLiteral(document.createElement(div)) returns
true under IE8.
I was actually just exploring issues with isObjectLiteral and extend
as you wrote this email. I'll check in to that today and hopefully
post a solution.
--John
--
You received this message because you
Yep, like I said earlier
jQuery.isObjectLiteral(document.createElement(div)) returns true in IE8
(dunno for earlier versions) but John seems to be working on it. Can't
believe how difficult to get right these type controlling codes can be.
Seems like magic to me sometimes.
I actually landed
, John Resig jere...@gmail.com wrote:
Yep, like I said earlier
jQuery.isObjectLiteral(document.createElement(div)) returns true in
IE8
(dunno for earlier versions) but John seems to be working on it. Can't
believe how difficult to get right these type controlling codes can be.
Seems
Just a heads-up: I actually removed all of the submodules from jQuery
yesterday. After talking with Yehuda I realized that we actually
didn't want submodules, we wanted atual clones of Sizzle and QUnit.
I've changed the Makefile to handle this. You can see a clean clone
here:
Phew - this is a beast of a patch indeed! In general though I'm liking
the feel of the resulting code, a lot. This would be much more
extensible, which is quite nice. I say we try to pursue this post-1.4.
In the meantime you can start to apply some of the jQuery Core Style
Guidelines to your code
This was recently fixed in the Git repository and will be in jQuery 1.4.
--John
On Sat, Nov 28, 2009 at 2:41 PM, Jeremy Chone jeremy.ch...@gmail.com wrote:
Hi,
I am hitting something quite strange. When I try to add a comment
!-- comment -- to a tr element, it either remove all the td
I'm not sure how this relates to TestSwarm but could you provide some
more information about the cross-browser nature of .text? Preferably
with proof that it works in all the browsers that jQuery supports.
If so then I don't think I'll have a problem switching to it.
--John
On Sun, Nov 29,
standard.
Regards
On Sun, Nov 29, 2009 at 9:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
On Sun, Nov 29, 2009 at 7:58 PM, John Resig jere...@gmail.com wrote:
I'm not sure how this relates to TestSwarm
well, I meant that via TestSwarm will be easy to test jQuery browsers
I can't tell you if it means it is not supported at all or if it ignored or
cause errors but AFAIK Safari 2 for Mac is not in the jQuery compatibility
list, is it?
It's not in the compatibility list but we don't want to go out of our
way to intentionally break browsers either. As it stands the
if I set it up right when I decided to checkout
the repo to do some small commits.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
Ah, git is by default CRLFing files. To turn it off:
git config core.autocrlf false
That's... interesting. Yay git
/sizzle
url = git://github.com/jeresig/sizzle.git
Anyone else had this problem?
On Nov 12, 7:46 am, John Resig jere...@gmail.com wrote:
Actually, both Sizzle and QUnit need to be pulled in dynamically
(using Git submodules). The commands needed to do that are all in the
Makefile
Oof, I'm really not sure - I wonder if it has to do with having
multiple remotes? I'm going to throw up the bat signal and see if we
can get some clarification from the Github guys.
--John
On Thu, Nov 26, 2009 at 6:13 PM, Mark Gibson jollyt...@gmail.com wrote:
Hello,
has anyone managed to
Ah, git is by default CRLFing files. To turn it off:
git config core.autocrlf false
That's... interesting. Yay git?
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to
Commented on the changeset.
--John
On Wed, Nov 25, 2009 at 4:47 PM, Robert Katić robert.ka...@gmail.com wrote:
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
doing nothing and just saying sorry that's not
supported is going to become more and more a problem the longer we
don't address it.
--Kyle
On Nov 17, 2:23 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
On Tue, Nov 17, 2009 at 8:15 PM, John Resig jere...@gmail.com wrote:
Oh
not
supported is going to become more and more a problem the longer we
don't address it.
--Kyle
On Nov 17, 2:23 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
On Tue, Nov 17, 2009 at 8:15 PM, John Resig jere...@gmail.com wrote:
Oh, just to mention, regarding your solution
1. In the jQuery specific case, if the library will adopt the script,
the library will make lazy plug-ins load based on $(document).ready(...)
possible. We need to understand that jQuery as is, is not that kind of lazy
loaded library since I assume that if a website uses jQuery,
P.S. I'm curious, is there really no way - not even some, nasty,
messy, setTimeout-based, icky one - for jQuery to guarantee that
document.ready is always triggered?
None that I know of, no. :-/
--John
--
You received this message because you are subscribed to the Google Groups
jQuery
Am I right to think that there's a similar problem with the
window.onload event?
i.e. if you're too late in binding a handler to window.onload, it will
never fire?
That is correct.
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development
Looking at the example I suspect that it's due to some sort of weird
styling/CSS issue in IE. I'll have to investigate more in order to determine
exactly what the set of circumstances is that causes the issue. I'll try to
check in on it again before 1.4 and provide a definitive answer one way or
, Jason Persampieri papp...@gmail.com wrote:
On Nov 13, 6:39 am, Scott Sauyet scott.sau...@gmail.com wrote:
On Thu, Nov 12, 2009 at 1:15 PM, John Resig jere...@gmail.com
wrote:
I think the one area that would be troublesome is in the
properties
that xhr provides (like
stable
codewise and roughly tested, I'll put it on github. OK with you?
btw, do you prefer I edit ajax.js or that I upload a plugin (which is the
format I'm using right now)?
2009/11/19 John Resig jere...@gmail.com
All of this sounds pretty good - do you have a link to the code?
(Preferably
Good suggestion, just landed it:
http://github.com/jquery/jquery/commit/3a23a5c17dd0522da06db8f36890f134f9004de6
You should mention stuff like this as comments on the commits - and file
follow-up patches through Github. It makes it super-easy to manage (on my
end, at least).
--John
On Tue, Nov
.
being document a first class node without attributes, above snippet will
make readyState behavior a bit more consistent.
Please let me know if I have missed something in the bindReady stuff.
Regards
On Tue, Nov 17, 2009 at 3:46 PM, John Resig jere...@gmail.com wrote:
Good suggestion
This seems like a reasonable request. I filed a ticket and fixed it:
http://dev.jquery.com/ticket/5525
--John
On Mon, Nov 16, 2009 at 4:18 PM, Xavi xavi@gmail.com wrote:
Hello,
Currently $(document.createTextNode(test)).text() returns empty
string. Is this expected?
Thanks,
Xavi
the events as every
other browser does.
being document a first class node without attributes, above snippet will
make readyState behavior a bit more consistent.
Please let me know if I have missed something in the bindReady stuff.
Regards
On Tue, Nov 17, 2009 at 3:46 PM, John Resig jere
It's a bit hard because implementing some of the changes because there will
be a definite performance hit (for selectors and adding/removing classes).
If it was possible to implement the changes without that happening I would
consider a good patch in.
--John
On Mon, Nov 16, 2009 at 9:15 PM, Mr
It's because Internet Explorer has serious memory leak issues with
using the traditional model. Perhaps we could use conditional comments
in this case, since it's not something that we can feature detect.
--John
On Fri, Nov 13, 2009 at 5:24 AM, 1Berto humbertun...@gmail.com wrote:
Hello,
I
The problem is that, at this point, we're going for 1.4 so it'll be
hard for us to integrate it immediately.
Although, the solution that you outline isn't completely ideal,
either. Having too many releases causes users to never upgrade, for
fear of another release coming out soon. We've found
Actually, both Sizzle and QUnit need to be pulled in dynamically
(using Git submodules). The commands needed to do that are all in the
Makefile and are run automatically before a build occurs.
--John
On Thu, Nov 12, 2009 at 8:15 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
Sizzle
Hi Dave -
This so much for pulling this together, it's very useful.
I see some definite gaps that can be closed, when looking at this (for
script/json/jsonp):
- beforeSend/ajaxSend
- dataFilter
- processData
- timeout
Now, error and ajaxError could be handled - but to a limited degree.
If
I created some tickets for the missing features:
http://dev.jquery.com/ticket/5500
http://dev.jquery.com/ticket/5501
http://dev.jquery.com/ticket/5502
--John
On Thu, Nov 12, 2009 at 9:58 AM, John Resig jere...@gmail.com wrote:
Hi Dave -
This so much for pulling this together, it's very
Regarding the abort possibility for jsonp (#5500 = #3442), this brings us
back to the idea of returning an abstraction on top of the actual xhr/script
hack/whatever.
I was curious as to why the whole ajax typology wasn't implemented with a
factory pattern: you would call something like
Is there any work being done to create a jQuery build process that
helps automate the concatenation and minifying of javascript files.
Different from what we already have? If you wish to create a version
of jQuery that has a different set of functionality (or reduced set)
you just twiddle the
Digging around it looks like we added our window unload event
unbinding logic in 1.2.2 - and I bet that that's what was causing the
problems. We actually fixed this in the latest nightlies (only unbind
in IE) so this problem should be resolved in the upcoming 1.4 release.
--John
On Thu, Nov
unchanged.
I think this behavior is not what someone would expect (I hope).
On Nov 11, 5:09 am, John Resig jere...@gmail.com wrote:
If someone wants to pass in a random object to be extended we won't
stop them. So yeah, someone could do:
jQuery.extend([1,2], [3]) and get [3,2] as a result
I've followed up in the ticket.
--John
On Wed, Nov 11, 2009 at 5:38 AM, Mr Speaker mrspea...@gmail.com wrote:
I was just reviewing an issue I submitted when multiple toggle event
handlers are bound to the same element. The issue is that the toggle
functionality uses an expando
Here's a really, really simple to fix $.ajax inconsistency that would
sure help me out:
http://dev.jquery.com/ticket/3591
Lucky for you then as that's already been fixed! :)
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To
If someone wants to pass in a random object to be extended we won't
stop them. So yeah, someone could do:
jQuery.extend([1,2], [3]) and get [3,2] as a result - not sure why you
would want to, though. I can't think of a reason to explicitly prevent
this behavior, at least.
(On a related note I've
I think it's a result of the $.ajax method's very ambitious scope. The
behavior can change quite a bit depending on the arguments, and many
argument combinations aren't valid.
http://docs.jquery.com/Ajax/jQuery.ajax#options
Just a few examples: jsonp and cross-domain json/script requests
Yeah, that test page is kind of broken right now because it's pulling
in a newer version of QUnit (one that doesn't work with the 1.3.2
suite). If you want to run the latest test suite the best way to do
that is to pull from the 1.3.2 release zip file:
I've thought about your post some more and I think this might actually
be ok. Considering that right now the only callback that is fired is
the success callback we can safely assume that people who are using
this method don't actually care about the error state - thus if we
pass in the normal
Wouldn't it still break some scripts that actually expect the data never to
be undefined?
As I mentioned before - the application would just break in a
different way. Normally it would break in that the result would never
come in - now it would throw an exception (again, that's assuming that
if
Jason, I like what you're getting at.. a lot.
I agree, I like it as well.
A completely different technique:
jQuery(jQuery.get(url)).bind(success, fn);
Then the jQuery.ajax method could call jQuery(xhr).trigger(success);
Hmm. It'd be neat if we could somehow return just jQuery(xhr) but
that's
So it seems like a couple things would fix your problems:
1) If fadeIn or fadeOut is called while a partial opacity is shown
then animate to the final state, starting from the current opacity
(right now fadeIn, in particular, won't run).
2) Make the actual time to run the animation be equal to
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 an alternative solution please feel free to modify
the gist and put your code up
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 the Google Groups
jQuery Development group.
To post to this group, send email to
happen when the mouse is
over a tooltip element that still fades out. I may be able to fix that with
mousemove.
So, if we can get these three fixed and that other issue, the jQuery UI
Tooltip would be mostly done.
Should I create a ticket for these?
Jörn
On Sun, Nov 8, 2009 at 12:06 PM, John
:57 pm, John Resig jere...@gmail.com 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 the Google Groups
jQuery
Making that change as-is would definitely seem to break code. Really
the get and post methods are meant to be simple cases, everything else
should be tackled with the ajax method.
--John
On Sunday, November 8, 2009, Mr Speaker mrspea...@gmail.com wrote:
The $.post and $.get are really handy,
Hi Jeffrey -
Really sorry about not getting back to you sooner - I've seen your
messages and you've been very patient. I'm hoping to check into this
problem more as soon as I have access to a Windows machine again (I'm
traveling at the moment).
Again, sorry, and I will keep you up to date.
/ticket/5468)
Earle.
On Nov 7, 1:05 am, John Resig jere...@gmail.com wrote:
Hmm, that does sound like a bug. Could you file a ticket and mention
the tweak that you made? Thanks!
--John
On Fri, Nov 6, 2009 at 7:16 AM, Mr Speaker mrspea...@gmail.com wrote:
I searched around
This has been discussed before but I was just curious if this would
affect anyone negatively. I'd like to make this change so that less
bubbling has to occur (both documentElement and document no longer
have to get hit).
Roughly, the line in the .live implementation would end up being changed
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 jere...@gmail.com wrote:
1. Calling closest, context argument still is not used.
I was unable
The only case where that sort-of makes sense is for custom events. I
mean, there's not much point in not-fixing the event object for some
events - might as well do it for no events then.
...unless there's something else that you were considering?
--John
On Fri, Nov 6, 2009 at 2:43 AM, Justin
Also, @robert, my solution supports the following notation, similar to
yours but using the familiar jQuery syntax (before/after DOMReady):
$.live(#mySelector, click, fn1)
.live(#mySelector, mouseover, fn2)
...;
I understand the logic behind you wanting a $.live method (for the
edge cases
#someRootTable.
--Robert
On 6. stu. 2009., at 04:56, John Resig jere...@gmail.com wrote:
$(#someRootTable).click(function(e){
$(e.target).closest(td.foo).each(function(){
// Your code goes here.
});
});
--
You received this message because you are subscribed to the Google Groups
This changed slightly in the latest nightlies - if you do $(0) it'll
be as if you did $() or $([]). As of now any false-ish value will give
you an empty jQuery set.
Considering that there is no intended behavior for passing in a number
to the jQuery object this seems fine to me.
I'm curious -
I think you're right here - I'm not completely convinced that this
distinction still needs to exist. Could you file a ticket? Thanks.
--John
On Fri, Oct 30, 2009 at 7:47 AM, Robert Katić robert.ka...@gmail.com wrote:
To be more accurate,
$([]).add( nodeList )
can not contains comment
This seems reasonable, as well. Can you file a ticket? Thanks.
--John
On Fri, Oct 30, 2009 at 2:06 AM, Robert Katić robert.ka...@gmail.com wrote:
Sorry, I posted an old version of code. Here the new one:
jQuery.fn.add = function( selector, context ) {
return this.pushStack(
( (elem = second[ i++ ]) != null ) {
first[ pos++ ] = elem;
}
}
return first;
}
--Karl
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Oct 30, 2009, at 10:31 AM, John Resig wrote:
I think you're right here - I'm not completely convinced that this
distinction
Of course, although it would simplify the $.data() implementation
(speed performances too) it would breaks compatibility with many
existent plugins. However, $.data() in 1.4 will breaks it already...
If developers want to switch to this style they're absolutely welcome
to (in fact, we already
Hi Mark -
This was intentional. We could no longer guarantee that an ID would be
attached for an element at all times (which is what was done before).
Additionally calling that method would attach an expando and object to
an empty element - even if no data needed to be stored (which is bad).
A critical part of moving to a forum is that we want one that has full
email subscription (for both threads and comments). We won't move to
something that people can't remain engaged with.
That being said, it's likely that we'll keep jquery-dev as is, this is
mostly for jquery-en and the massive
101 - 200 of 748 matches
Mail list logo
