The jQuery-dev mailing list has had a fantastic run, lasting about 4
years! However all discussion has since moved over to the new jQuery
forum:
http://forum.jquery.com/developing-jquery-core
I will be closing the list effective immediately. If you have any
questions relating to the development
Yes, we've moved to the new forum:
http://forum.jquery.com/
And this issue has already been fixed and will be in 1.4.2:
http://dev.jquery.com/ticket/5851
--John
On Wed, Feb 3, 2010 at 6:02 PM, tg @oh tg.oh44...@gmail.com wrote:
I have some code that works in jquery 1.3.2 but does not in
Yeah, moderation has been turned off, the team has all moved over to
using the forums. Considering that there really hasn't been any
worthwhile posts here in a few days I'll probably just shut this list
down.
--John
On Fri, Jan 29, 2010 at 12:11 PM, Sidney San Martín s...@sidneysm.com wrote:
Hello All -
After much deliberation the jQuery team has decided to close down the
Google Groups that we've been using for project discussion and move to
a unified forum instead.
The new forum can be found here:
http://forum.jquery.com/
More information about our decision to move can be found
Great, and John has now committed the fix. Let's hope 1.4.1 is not too
far away! ;)
It'll be out by Friday.
--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
That isn't really something that we can globally assure. We frequently
create disconnected nodes and fragments before eventually inserting
them into the document. Not to mention that delaying the insertion of
the HTML will cause a double page reflow to occur, slowing things down
even further.
I just pushed a fix for this (adding 'l' to the var declaration). Good
catch! (I'd link to Github but it appears to be down.)
--John
On Mon, Jan 18, 2010 at 11:08 AM, philipp:s suter.phil...@gmail.com wrote:
There is a bug on line 2392 and 2411: var is missing:
for ( var i = 0, l =
or BOTH the general and dev groups
combined?
/Kevin
On Jan 16, 6:32 am, John Resig jere...@gmail.com wrote:
It sounds like confirmation emails are still being sent out - it also
sounds like they're having some server troubles at the moment, making
the confirmation email/login process a bit
Replied over in the forum.
--John
On Sun, Jan 17, 2010 at 4:53 PM, Steven Black ste...@stevenblack.com wrote:
(Re-posted here since there is currently zero traction on the new
forum)
I have a question about code in ajax.js that is crashing for me in
both FF (latest) and IE (latest).
It sounds like confirmation emails are still being sent out - it also
sounds like they're having some server troubles at the moment, making
the confirmation email/login process a bit troublesome. I would
recommend being patient while they get this sorted out.
--John
On Sat, Jan 16, 2010 at
Good catch. Filed and fixed:
http://dev.jquery.com/ticket/5838
--John
On Fri, Jan 15, 2010 at 7:47 PM, Donald @ White Whale
donaldwhitewh...@gmail.com wrote:
I read the 1.4 release notes but am a little confused about the
following. I'd guess it's related to the ability to specify ajax
It's not really clear what it should call - maybe it should only call
the complete request and neither the error or success. When I looked
into it recently some browsers called success and some called nothing
(Opera). I normalized it to success across the board but I'm open to
further debate.
It looks like you're using a really old version of delegatetest.html -
you should make sure that you're current.
--John
2010/1/15 Mattias Hallström matt...@problem.se:
Hi,
I have read a lot that you have solved the problem that IE doesn't
bubble for select.
But we can' get it to work, and
I actually landed your recommended change just now:
http://github.com/jquery/jquery/commit/199a721103b17c18dea7a9abaeb79866ef4a7f51
--John
On Fri, Jan 15, 2010 at 2:00 PM, Justin Meyer justinbme...@gmail.com wrote:
I found another way of doing it that is rather sneaky. Maybe someone
else
So we talked about this and it really seems like we should try to
provide a better interface (like the 'remove' event used in jQuery
UI). I'm going to come back to this issue once 1.4.1 is out so we can
discuss it more.
--John
On Wed, Jan 13, 2010 at 10:35 AM, Justin Meyer
Make sure you're using the latest version of jQuery (or even 1.4),
that's already been fixed.
--John
On Fri, Jan 15, 2010 at 5:26 PM, Rick Waldron waldron.r...@gmail.com wrote:
I have searched high and low, but cant find another reference to
jQuery.fnAttr anywhere in jQuery... Nor can I find
Good catch, removed:
http://github.com/jquery/jquery/commit/6618ff0b0abe38a0914d8afe0a2b271c977adf6b
--John
On Fri, Jan 15, 2010 at 2:04 PM, Sean Catchpole
littlecoold...@gmail.com wrote:
When reading the jquery 1.4 source code I noticed that inside the
buildFragment function the variable
...@gmail.com wrote:
Whoops! That was definitely from rc1
Thanks :)
But seriously... what was it for?
On Fri, Jan 15, 2010 at 5:41 PM, John Resig jere...@gmail.com wrote:
Make sure you're using the latest version of jQuery (or even 1.4),
that's already been fixed.
--John
On Fri, Jan 15, 2010
Yeah, removed that earlier today. Must've been a copy-paste snafu.
--John
On Fri, Jan 15, 2010 at 2:24 PM, Sean Catchpole
littlecoold...@gmail.com wrote:
While reading the jQuery 1.4 source code I've noticed that the
following is written twice. Is there any documentation on making
patches
You can just use the traditional style of serialization. Just set:
jQuery.ajaxSettings.traditional = true;
--John
On Thu, Jan 14, 2010 at 3:03 AM, Ishbir ishbi...@gmail.com wrote:
How to replicate the problem-
1. Create a form with an input field, the name of which includes
[ and ]. For
Umm, hmm, that line:
div.appendChild(document.createElement('Comment').data=)
isn't anywhere in jQuery.
What's actually at that line is (which was also in 1.3.2):
div.appendChild( document.createComment() );
Is your script getting malformed in some way?
--John
On Wed, Jan 13, 2010 at 7:01
Hello -
This is due to the fact that we removed the ability to bind data()
(and thus events) to object, embed, and applet elements in 1.4.
Allowing it was causing uncatchable exceptions to be thrown when used
along with with Java applets.
The commit:
-to-the-destruction-of-the-system/
And something *much* closer to jQuery users :
http://cafe.elharo.com/programming/in-praise-of-draconian-error-handling-part-1/
1.5 perhaps ...
On Jan 13, 4:26 pm, John Resig jere...@gmail.com wrote:
Hello -
This is due to the fact that we removed the ability to bind data
. This is resulting in a
window.thisObject showing up after using bind or one. Should be
an easy fix.
On Jan 3, 8:56 am, John Resig jere...@gmail.com wrote:
Oh, good point - I forgot that this was a more recent change. Still,
it'll be good to maintain the old API here.
Alright, I'll try to land
it failed validation once, then tab back and put in a correct
email and tab to the password it won't clear the failed validation.
so I can't submit the form.
On Jan 12, 12:54 pm, John Resig jere...@gmail.com wrote:
I'm having a hard time confirming this. I went to your test page,
viewed
Since I'm having trouble reproducing the problem can you let me know
what happens when you use this copy of jQuery 1.4rc1 instead?
http://ejohn.org/files/tmp-jq14-abort.js
Thanks.
--John
On Tue, Jan 12, 2010 at 3:22 PM, blizzard tylerwor...@gmail.com wrote:
Thank you Scott, that's exactly
Oh, ok - that helps to clear some things up. Try this:
http://ejohn.org/files/tmp-jq14-abort-2.js
--John
On Tue, Jan 12, 2010 at 3:42 PM, blizzard tylerwor...@gmail.com wrote:
Ok, I updated the script. Now is says that xhr is null at line 4970.
On Jan 12, 2:39 pm, John Resig jere
That has always been in there - we'll probably end up tweaking our
build script to just remove it but for the time-being it's not hurting
anything.
--John
On Tue, Jan 12, 2010 at 1:28 PM, TomaP pia...@gmail.com wrote:
Hi,
I had a look at Jquery 1.4 RC and found that code :
line 3170 :
Yep, I just landed it:
http://github.com/jquery/jquery/commit/61983cbf176c599687c36ffbf4b64ae8697486a3
--John
On Tue, Jan 12, 2010 at 4:46 PM, blizzard tylerwor...@gmail.com wrote:
got it. that works perfectly now. will this be fixed in the final
version?
On Jan 12, 2:56 pm, John Resig
vista and win 7.
Can anyone else confirm that they see this problem too?
On Dec 17 2009, 9:08 pm, John Resig jere...@gmail.com wrote:
Hi Geoffrey -
I saw your bug pop up and while I haven't had time to dig into the
test case yet I do agree about the suckage. I hope to be able to
investigate
It was intentional in that in the places where we use it we weren't
concerned with properties bleeding through from prototypes. I will
make a note of it in the documentation and we can re-examine this
after 1.4 is out.
http://api.jquery.com/jQuery.isEmptyObject/
--John
On Tue, Jan 12, 2010 at
I noticed that you commented out the 1.4 script on your test page -
could you perhaps make a reduced test case that I can take a look at?
I would greatly appreciate it.
--John
On Tue, Jan 12, 2010 at 12:03 PM, Zack Kitzmiller
zackkitzmil...@gmail.com wrote:
.ajaxComplete doesn't work?
I
This was an intentional change. We found that when doing a deep extend
on non-objects (and I mean that in the plain object and plain
array sense) a lot of unexpected behavior was encountered. We only
deep extend plain objects and plain arrays now (those that match
jQuery.isPlainObject or
.
Ralph
On Tue, Jan 12, 2010 at 4:14 PM, Mark Fraser goo...@mfraz.orangehome.co.uk
wrote:
On Tuesday 12 Jan 2010 21:04:38 John Resig wrote:
Hmm, a bit vague - do you have an example? Also what browser did you
see this effect in?
Sorry,
Go to http://www.digitalia.be/software/slimbox2
I'm not sure if a fix for it will land before 1.4, unfortunately,
although I will make an attempt to fix it soon after.
And just to clarify: It looks like this issue is in the current
version of jQuery (1.3.2) as well, per the test case.
--John
On Tue, Jan 12, 2010 at 11:52 AM, matiasnu
Never heard of sending a body with a DELETE. Reading more it doesn't
seem like something that you should really rely upon:
http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request
That being said the fix was really quite simple:
Already been fixed. jQuery 1.4rc1 will be out today with the fix in it.
--John
On Mon, Jan 11, 2010 at 11:21 AM, Kelvin Luck kel...@kelvinluck.com wrote:
Hi,
I've had a few reports from users of my plugins that
$(window).bind('unload') causes an too much recursion error in Firefox.
Are
Yep, I confirmed it on my own and came to a similar conclusion:
http://github.com/jquery/jquery/commit/5a0ac24e35c07fe4be22df828e6b909fe65237b9
The events fire in the same order in IE 8 and in other browsers with
my change. Thanks for the test case!
--John
On Mon, Jan 11, 2010 at 12:13 PM,
Good catch. Filed and fixed.
http://dev.jquery.com/ticket/5785
Also, in the future, you may want to use the new .unwrap() method
which is designed for this exact purpose:
c.children.unwrap();
(Although unwrap uses replaceWith so you would've hit the same bug, it
seems. Glad it's fixed!)
--John
Seemed simple enough so I fixed it. Thanks for the heads-up.
--John
On Fri, Jan 8, 2010 at 11:35 AM, Marc Diethelm b...@chic-happens.ch wrote:
I want to bring attention to two possible patches for bug #3552.
They have been in Trac for 10 months now... Can someone please have a
look and
Thanks, nice interview. And, yes, agree with John, the devices
selection is key. Also, IMO 3rd party browsers should not be a
priority (focusing on the device default browser would bring a better
reach)
I use to think similarly to you but Opera has such a dominant position
in the mobile space
Any mobile browser part of the jQuery test suite?
Not yet, no.
Any roadmap on the subject?
Yes! We've already collected a number of mobile devices from
manufacturers and will be integrating them into our test suite after
1.4 is out.
--John
--
You received this message because you are
does, is my answer to that.
Thanks for reading ... DBJ
On Jan 6, 2:16 pm, John Resig jere...@gmail.com wrote:
How are you hitting this issue in jQuery? jQuery never uses
JSON.stringify, only JSON.parse.
We don't really like overwriting native methods - especially ones that
we don't use
Browsers don't provide height/width information for elements when
they're display: none (or within a display: none element). There is no
workaround for it - other than making the element not display: none.
Sorry :-/
Naturally, if an alternative is ever developed for retrieving the
height/width of
btw, I also saw you landed an auto-fetching for script (FYI, I
synchronized the rewrite with latest changes, including javascript
auto-execution) but I believe it is just plain wrong to let the server
decide of what should be executed client-side (especially with cross-domain
xhr getting more
On Thu, Jan 7, 2010 at 11:04 AM, Douglas Crockford
doug...@crockford.com wrote:
I strongly recommend that you not compromise on safer.
Unfortunately we're in the very challenging position now where
introducing the use of window.JSON will absolutely break some
jQuery-using applications - and will
attempts at sending JavaScript back and
having it execute when we're expecting JSON).
http://github.com/jquery/jquery/commit/308d6cdad023da190ace2a698ee4815ed8dad9c5
--John
On Thu, Jan 7, 2010 at 11:55 AM, John Resig jere...@gmail.com wrote:
On Thu, Jan 7, 2010 at 11:04 AM, Douglas Crockford
That's all nice dandy for json. But the javascript getting executed
solely on server saying so problem still remains. The fact you had to
change the synchronous request tests is a clear proof of the problem to me:
existing code will break (no issue if documented), existing code will face a
How are you hitting this issue in jQuery? jQuery never uses
JSON.stringify, only JSON.parse.
We don't really like overwriting native methods - especially ones that
we don't use - to fix bugs.
--John
On Wed, Jan 6, 2010 at 12:46 AM, Leeoniya leeon...@gmail.com wrote:
for some reason my github
XMLHttpRequest();
}
return null;
}
--Sam
2010/1/5 Matt m...@thekrusefamily.com
On Dec 31 2009, 1:52 pm, John Resig jere...@gmail.com wrote:
Landed and closed:http://dev.jquery.com/ticket/5735
John, good to see this change in jQuery.
Another ajax area that needs attention is the xhr creation
jQuery is already in the Software Freedom Conservancy (they host all
our finances, for example). The code base, however, is not - that's
going to take a significant amount of time and legal work to make it
happen. /Maybe/ it might happen this year, but that's really hard to
foresee. To your client
I would definitely need to see proof of cloneNode being faster than
createElement before moving forward with something like this
(especially in IE).
Although, I'm a bit hesitant landing a change like this, wholesale -
mostly because we're looking at better templating solutions for after
1.4 and
As I've mentioned before, the problem isn't generating the file - it's
the fact that the CDN caches everything out the wazoo and it's really
hard to force all the leaf nodes to update in an automated fashion.
Once we figure that out we'll be able to do nightlies in a more-timely
fashion.
--John
doesn't work in 1.3.2. It just throws an error expecting
the proxy to be a function, not an object.
On Dec 31 2009, 12:39 am, John Resig jere...@gmail.com wrote:
jQuery has already solved this problem internally using our
jQuery.event.proxy method - and, in fact, if I were to land a
jQuery.bind
Oops, heh, I think that was leftover from testing. Fixed!
--John
On Sat, Jan 2, 2010 at 10:30 PM, Mike Taylor miketa...@gmail.com wrote:
The other day I cloned a fresh repo and, as I was in a ruby state of
mind, built jquery using `rake` rather than the usual `make`. To my
surprise, I
The stop() method doesn't really work that way (it would have to
behave synchronously for that to be the case). You'll have to do one
stop() at the start of the test block and then either do only one
async test or just keep a counter of the number of tests that've
completed and only run the
test suite previously. But I can live with that for the moment.)
Thanks again,
Karel
On Jan 3, 7:00 pm, John Resig jere...@gmail.com wrote:
The stop() method doesn't really work that way (it would have to
behave synchronously for that to be the case). You'll have to do one
stop
AM, Matt m...@thekrusefamily.com wrote:
On Dec 30, 10:58 pm, John Resig jere...@gmail.com wrote:
Interesting, I've, also, seen the = null; proposal before, but not the
= function(){}; one. Doing some poking around I found mention of it
here:http://www.ilinsky.com/articles/XMLHttpRequest/#bugs-ie
Both reasonable requests - landed the changes:
http://github.com/jquery/jquery/commit/6cf981eea20695987b4f7341f80442a7cf8271eb
Thanks!
--John
On Thu, Dec 31, 2009 at 4:39 AM, candlerb b.cand...@pobox.com wrote:
On Dec 31, 3:29 am, John Resig jere...@gmail.com wrote:
Umm, hmm - is perfectly
Is there any reason you are keeping jQuery.event.proxy around? I
didn't see it used anywhere.
Internally it's not used anymore - but considering that we were using
it in a bunch of places in core, it's very likely that there are a
bunch of plugins using it as well. No reason to cause
Do you have a test page that repeatedly makes ajax calls to exploit
the memory leak issue?
Yes.
A .7% increase in memory use doesn't raise any red flags to me, it
could just be how IE handles the new code differently. You'd have to
repeat the test many times and watch Drip to see if the
in the thread?
--John
On Thu, Dec 31, 2009 at 12:39 AM, John Resig jere...@gmail.com wrote:
So I definitely agree that having a single, one-off, API addition (to
bind and live) is kind of lame - especially when it conflicts with the
jQuery way of defining the methods (having a non-callback
Umm, hmm - is perfectly valid shell - used for redirecting both
stdout and stderr simultaneously:
http://www.gnu.org/software/bash/manual/bashref.html#Redirections
http://dsl.org/cookbook/cookbook_5.html#SEC57
Also - why is there an empty src/sizzle directory? That shouldn't be
there to begin
We just introduced this and it'll be in 1.4:
http://github.com/jquery/jquery/commit/fbc73d45b487dd863886c7fd3f0af1fd4dec261b
Just specify a jsonpCallback to $.ajax and it will always hit the same URL.
--John
On Wed, Dec 30, 2009 at 11:33 AM, JimO j...@thisismyworld.org wrote:
My applications
Interesting, I've, also, seen the = null; proposal before, but not the
= function(){}; one. Doing some poking around I found mention of it
here:
http://www.ilinsky.com/articles/XMLHttpRequest/#bugs-ie-leak
I just experimented around with the change and posted it into a separate branch:
Seems like a reasonable request. A bug report + Github-based patch
(with test case) would be greatly appreciated (and landed right away).
--John
On Wed, Dec 30, 2009 at 9:00 PM, Richard D. Worth rdwo...@gmail.com wrote:
I just tracked down an issue that was causing the jQuery UI Datepicker to
So I definitely agree that having a single, one-off, API addition (to
bind and live) is kind of lame - especially when it conflicts with the
jQuery way of defining the methods (having a non-callback argument
being last).
I sat down and wrote up a quick jQuery.bind() but found one critical
issue
I have looked into the code today and everything works fine :-). +
Excellent :) If you haven't already, I recommend checking out
test/delegatetest.html - I've been using that to do a bunch of this
change/submit/focus/blur testing and it's been very helpful.
Altough it is a huge hack with some
// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == selected elem.parentNode ) {
elem.parentNode.selectedIndex;
}
I previously made two points:
1) This code will not work of the option is in
Is there an open ticket on this? If so I don't see a reason not to land it.
--John
On Tue, Dec 22, 2009 at 10:35 PM, Rick Waldron waldron.r...@gmail.com wrote:
I think I hacked a copy of jquery 1.3.2 to do this... I'll take a look and
drop you a line.
-- Sent from my Palm Prē
It should be resolved now.
http://github.com/jquery/jquery/commit/0d5bd174614fa278826ac464342f17c0ae56
--John
On Mon, Dec 21, 2009 at 7:22 AM, weepy jonah...@gmail.com wrote:
Calling animate with empty hash prevents that element from animating
again
$(#piece_1).animate({top:200}) =
$()
$(html)
$( document )
All three of those things point to different things so it doesn't make
sense to have it be a singleton.
The first gives you an empty set, the second is a set containing the
document element, the third is a set containing the document.
The only case we could
What version of jQuery 1.4? This sounds like an issue that was fixed in 1.4a2.
--John
On Mon, Dec 21, 2009 at 5:29 AM, weepy jonah...@gmail.com wrote:
Worked with 1.3.2
now .attr(size) returns 1 whether it's been set or not
$(x).attr(size) = 1
$(x).attr(size, 40)
$(x).attr(size) = 1
I agree with the other poster - this is relatively low priority,
although you can feel free to file a bug report and we can definitely
check in to it, likely post-1.4.
--John
On Mon, Dec 21, 2009 at 1:42 PM, helianthus
project.heliant...@gmail.com wrote:
Here is the test case:
I poured over your patch all morning/afternoon and made a number of
changes, but finally landed it in jQuery core:
http://github.com/jquery/jquery/commit/5dc6b7ce3469eaadb37a151d449e8d36571d1894
We now completely override the change event in IE, even for binding to
form elements. This gives us
Huh, haven't seen anything like this, off-hand. Do you have a page
that we can look at?
--John
On Mon, Dec 21, 2009 at 3:03 PM, Aaron floo...@floodle.org wrote:
I'm using jQuery 1.4a2 with jQuery UI 1.7.2. Creating tabs worked with
jQuery 1.3.2 as well as 1.4a1. Attempting to run
Very good point. I added some additional tests to the delegation suite
and I've come to the same conclusion as you: implementing
focusin/focusout across all browsers gives us much better parity.
I've landed the new code here:
Thanks for the link Mike, I'll check in to this. I'm starting to
wonder if it has to do with the recent .one() rewrite.
--John
On Mon, Dec 21, 2009 at 6:33 PM, Mike Alsup mal...@gmail.com wrote:
Huh, haven't seen anything like this, off-hand. Do you have a page
that we can look at?
#jquery-dev isn't very active - amusingly the most active place for
jQuery dev discussion is #jquery-ot (for off-topic discussion). I hang
out in there a bunch as does a bunch of people who make the yayQuery
podcast, and others interested in jQuery.
Although, I'm sure they'll try to kneecap me
I can see why this optimization was done, but I think that this will
cause problems for a lot of people!
Agreed, the change is broken! Wasn't there a test case for the above
scenario?
The previous technique was definitely not the right one to use. Cases
were coming up where the same string
Just to clarify then, since jQuery already covers cases 2-4 as you're
expecting it to and case #1 currently fails - and that case is
decidedly not what this thread discussion started as.
Consider the following cases:
#1)
select id=x
option value=1Dummy/option
option value=Empty/option
We're pulling in the Google Closure compiler now, instead of YUIMin,
so it's possible that there's something wrong happening there. Looking
through the README I don't see anything about a particular set of
version requirements - maybe it is limited to JDK 5? Although I'm
using 1.6 here on OS X and
I read through the thread again last evening, and mulled it over last
night, and I now agree that there is just too much room for confusion
(at least at this point) especially since .attr() has always behaved
in a particular manner. We can re-explore the issue once we have a
better grasp of how
Not yet - will have something up for testing very soon.
--John
On Fri, Dec 18, 2009 at 3:15 PM, Steven Black ste...@stevenblack.com wrote:
Any way to test-drive this before it goes live? Mostly just curious.
**--** Steve
On Dec 18, 12:05 am, John Resig jere...@gmail.com wrote:
We've
What about (i)frames?
In that case just use the jQuery inside the (i)frame. I'm fine punting
on that as well. Optimized for the very-most-common case.
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send
?
I could see the usefulness of having .attr('height') return the actual
attribute value in cases where, for example, I needed to see whether the
current height of an element is less than or greater than the height set by
the attribute.
--Karl
On Dec 17, 2009, at 11:29 AM, John Resig wrote
Like Karl said, I have had cases where I want to compare the current
height of an element with what was specified. I've also had cases
where height=x were hard-coded in the html and I wanted to access
the value (without having control over the html to use css, just
injecting script into the
Actually, the compelling reason is that the specified attribute height
will quickly lose sync with the actual height of the element.
iframe height=100.../
$(iframe).height( 1 ).attr(height)
// 100... but it's height isn't 100 any more.
Getting the current, computed, value is much more
() should be combined with
:contains() (the finished filter named :contains()), and .contains() should
go away.
That seems to make the most sense to me, anyways.
On Thu, Dec 17, 2009 at 9:20 AM, Karl Swedberg k...@englishrules.com
wrote:
On Dec 16, 2009, at 11:14 PM, John Resig wrote:
People
We've already exported all the data and we're in the process of
putting together the final details of our new solution (we're
switching to Zoho Discussion). We're planning on making the switch
over the holiday break and will make the final push on Jan. 4th. We'll
have plenty more details when we
Hi Geoffrey -
I saw your bug pop up and while I haven't had time to dig into the
test case yet I do agree about the suckage. I hope to be able to
investigate the issue some more, soon.
--John
On Thu, Dec 17, 2009 at 2:24 PM, Geoffrey geoffreykjqu...@gmail.com wrote:
I have entered bug #5670
... I guess that
means no more gmail or is there a way to get the messages sent to our
mailbox automagically?
Anyway, kudos for the efforts, switching from one discussion system to
another is always a nightmare.
2009/12/18 John Resig jere...@gmail.com
We've already exported all the data
as though ignoring
certain sources might leave you in the dark, but my advice would be to try
and steer clear of bad information.
On Tue, Dec 15, 2009 at 3:22 PM, Matt m...@thekrusefamily.com wrote:
On Dec 15, 11:32 am, John Resig jere...@gmail.com wrote:
I think
I'm curious to hear if this has been resolved in jQuery 1.4a1, it may be.
http://code.jquery.com/jquery-nightly.js
I should note that in your case you're not actually creating an XML
fragment - you're creating a bunch of unknown HTML elements.
--John
On Wed, Dec 16, 2009 at 3:02 PM, jarrowwx
, 2009 at 3:57 PM, John Resig jere...@gmail.com wrote:
I'm curious to hear if this has been resolved in jQuery 1.4a1, it may be.
http://code.jquery.com/jquery-nightly.js
I should note that in your case you're not actually creating an XML
fragment - you're creating a bunch of unknown HTML
Thanks for the test case, this is actually already fixed and in the
latest nightly:
http://code.jquery.com/jquery-nightly.js
--John
On Wed, Dec 16, 2009 at 9:54 PM, Devon Govett devongov...@gmail.com wrote:
Hello,
I have found a bug in the focus() function in jQuery 1.4. The focus()
That's not true - readyList is set to null inside of jQuery.ready()
once the queue has been emptied (the logic hasn't changed from when
the ready method was in event.js).
--John
On Wed, Dec 16, 2009 at 9:06 PM, helianthus
project.heliant...@gmail.com wrote:
At line 223 of core.js,
readyList
after switching from 1.4a1 to 1.4a2...
and removing that check fixed it.
I guess I have to check again what broke my code then.
On Dec 17, 11:25 am, John Resig jere...@gmail.com wrote:
That's not true - readyList is set to null inside of jQuery.ready()
once the queue has been emptied
People are use to using .has()? It was only just added - at the same
time as .contains() as well.
I'll mull over the .contains() discrepancy. I may just punt it and
push people towards .has() anyway.
Looking at .has() now I'm not 100% sure why it's filtering and not
just returning a boolean,
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()...
So we could disable it on XML documents - but regardless, that is
definitely th
1 - 100 of 748 matches
Mail list logo
