Not yet - will have something up for testing very soon.
--John
On Fri, Dec 18, 2009 at 3:15 PM, Steven Black wrote:
> Any way to test-drive this before it goes live? Mostly just curious.
>
> **--** Steve
>
> On Dec 18, 12:05 am, John Resig wrote:
>> We've already
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 all
t; 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
>>
>> We've already exp
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 wrote:
> I have entered bug #5670 for this issue. Details a
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 ge
Maxwell wrote:
>>
>> I think .has() should return a bool, :has() 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
> Actually, the compelling reason is that the specified attribute height
> will quickly lose sync with the actual height of the element.
>
>
>
> $("iframe").height( 1 ).attr("height")
> // 100... but it's height isn't 100 any more.
>
> Getting the current, "computed", value is much more useful and
> 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
ple use the wrong
> method?
> 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.
&g
I would be much more convinced if there were examples where:
1) People were legitimately using inline-specified height/width and in
a way that was different from specifying the value in pixels and in
way that was superior to using CSS.
2) The returned result from .height() (not .attr('height'), sin
> 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
definite
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, like
om 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 wrote:
>> That's not true - readyList is set to null inside of jQuery.ready()
>> once the queue has been emptied (the
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
wrote:
> At line 223 of core.js,
> readyList is an array, which will nev
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 wrote:
> Hello,
>
> I have found a bug in the focus() function in jQuery 1.4. The focus()
> function simply does no
solve my problem?
>
> On Wed, Dec 16, 2009 at 3:57 PM, John Resig 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'
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
site you referenced several times (that
>> i will not copy/paste here), I second a move to 100% ban all references,
>> along with the newsgroup you cited. I realize you feel as though ignoring
>> certain sources might leave you in the dark, but my advice would be to try
>> an
cause 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
>>
>> >
> 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 edg
> 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
> 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 == "
; emptying process nothing is removed from the screen and so things
>> don't look weird. I know this is an edge case, but it is something to
>> consider.
>>
>> Devon
>>
>> On Dec 13, 10:46 am, John Resig wrote:
>>
>>
>>
>> > Actually,
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
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
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 wrote:
> Is there a 'teardown' for plugins that can get triggered automatically
> (similar to that
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
t
As is the case with any API change in a major jQuery release (1.x
releases are major jQuery releases) we always document the results and
we always provide a backwards compatibility plugin. This has suited us
very well in the past and should continue to serve us well for the 1.4
release.
--John
> 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 AP
> I will take a look at this when I get a chance. I'm not going to copy
> his code, but if there are any similarities then he can sue me.
>
> 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 jus
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 wrote:
> A recent commit
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 Goog
rehensive attribute tests
for us we'd definitely appreciate it.
--John
On Fri, Dec 11, 2009 at 4:08 PM, John Resig wrote:
>> For example:
>>
>>
>> $('#x').attr('readonly') === true
>>
>> This is a boolean property of the element,
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 Explor
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:
$("").append( $("#old_parent").children() );
--John
On Sat, Dec
> For example:
>
>
> $('#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 would
> expect to get back the strin
Good catch, fixed:
http://github.com/jquery/jquery/commit/5197ac9fc8aa71c2ebc0d7217f41a3679eb1b902
--John
On Fri, Dec 11, 2009 at 11:35 AM, Steven Parkes wrote:
> Commit
> http://github.com/jquery/jquery/commit/542099a278e79dce38e814e7e7b448a1b73df82f
>
> (Make sure that we're doing proper fo
today but if
anyone is interested, the tests/code are all up now.
--John
On Fri, Dec 11, 2009 at 9:27 AM, John Resig 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 jQu
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 from there.
--John
On Fri, Dec 11, 2009 at 9:10 AM, John Resig wrote:
>> 1) It sti
> 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
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
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 wrote:
> Hello everyone,
>
> I've just added some new comments to an old bug #2551 (
> http://dev.jquery.com/ticket/2551 ) that is still open from
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 wrote:
> Hey guys,
>
> I was using 1.4a1 and I noticed that $.trim was killing ALL spaces
> (not just leading/trainli
.0.1/zend/jquery/test/?T3=%3F%0D%0AZ&H1=x&H2=&PWD=&T1=&T2=YES&My+Name=me&S1=abc&S3=YES&S4=&sub1=NO#
>
> Makes it quite difficult to pinpoint the issue, especially when, like me,
> you know nothing about the internals of the event module :/
>
free, they pull you in again ;o)
>>
>> PS: Yes,yes.. this is really me : DBJ
>>
>> On Dec 9, 4:15 pm, John Resig 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
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
wrote:
> Another update: I added a jsonp over iframe transport similar to the
> one
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 wrote:
> This creates a divergence between what a CSS selector me
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 wrote:
> Just curious, do the
It's funny because I actually
thought about this issue a while back, hoping to try and find a way to
make this simpler, but was unable to think of a good solution. Guess
we're stuck with what we have, for now.
--John
On Tue, Dec 8, 2009 at 11:14 PM, Paul Bakaus wrote:
>
>
> On
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 if
> 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,
e for building jQuery
> 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/97323d192f368fb8fa4ab8c7
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 la
Just landed the fix:
http://github.com/jquery/jquery/commit/b776e2b79a5b051fba3091b0b5057ae14950f7cc
Thanks!
--John
On Fri, Dec 4, 2009 at 10:52 PM, daltonlp wrote:
> I hit this too. Logged as bug 5557:
>
> http://dev.jquery.com/ticket/5557
>
> The issue still exists in 1.4a1.
>
> - Lloyd
>
gt; 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 wrote:
>> More details
>> here:http://blog.jquery.com/2009/12/04/jquery-14-alpha-1-relea
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
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 t
ng. (Maps newbies sometimes think they *have* to use
> an object literal and can't use an object that they build on the fly.)
>
> -Mike
>
> On Wed, Dec 2, 2009 at 3:36 PM, John Resig wrote:
>>
>> > Yep, like I said earlier
>> > jQuery.isObjectLiteral(doc
> 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 l
> 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 y
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 optimizat
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
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:
http://gist.github.com
> 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 t
list, text could be considered a de-facto
> standard.
>
> Regards
>
>
> On Sun, Nov 29, 2009 at 9:14 PM, Andrea Giammarchi
> wrote:
>>
>>
>> On Sun, Nov 29, 2009 at 7:58 PM, John Resig wrote:
>>>
>>> I'm not sure how this relates to TestSwarm
>
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, 200
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 wrote:
> Hi,
>
> I am hitting something quite strange. When I try to add a comment
> "" to a element, it either remove all the
> tags (if the comment is at the begin
complete.
>> -
>> However, the .gitmodules looks right:
>>
>> [submodule "test/qunit"]
>> path = test/qunit
>> url = git://github.com/jquery/qunit.
auto-props right when I setup my
> new laptop ages ago? I retired from major MediaWiki development before
> then so I don't remember 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.fries
> 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 jquery-...@googlegroup
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 wrote:
> Hello,
> has anyone managed to build jQuery from a
Commented on the changeset.
--John
On Wed, Nov 25, 2009 at 4:47 PM, Robert Katić 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 think it is worth o
I've updated the page. Thanks for the heads-up.
--John
On Fri, Nov 20, 2009 at 3:51 PM, Karl Swedberg wrote:
> thanks for the heads up, John. I'll try to update it this weekend, unless
> someone else gets there first.
>
> --Karl
>
>
> Karl Swedberg
> www.englishrules.com
> www.lear
cope with. Once I have something 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
>
> All of this sounds
gt; jXHR (http://mulletxhr.com).
>>>
>>> The reason I mention these two projects is that they seem to be doing
>>> exactly what is being suggested with this mockXHR object. I use a
>>> couple of tricks to make that happen, including emulating updating
>>&g
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
an
> 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"
> 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
>
>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 jQuer
and see
>> if it can provide a temporary hack fix. Or we can find something
>> else.
>>
>> But I just don't think there simply is no answer -- there has to be a
>> way for jquery to detect if domready is already passed. We may just
>> need to be more creative an
be a nice elegant solution to this
> problem, but I think 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 Giam
gt; 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 wrote:
>
>>
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 wrote:
> Hello,
>
> Currently $(document.createTextNode("test")).text() returns empty
> string. Is this expected?
>
> Thanks,
> Xavi
>
> --
>
> Y
ttributes, 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 wrote:
>
>> Good suggestion, just landed it:
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
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
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 that
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 wrote:
> Hello,
>
> I am using JQuery on a
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 12,
> 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
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 wrote:
> Hi Dave -
>
> This so much for pulling this together, it's very use
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 we
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
wrote:
> Sizzle lives as a copy in the jQuery
> 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.
I've followed up in the ticket.
--John
On Wed, Nov 11, 2009 at 5:38 AM, Mr Speaker 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 this.lastToggle to keep track
>> date: new Date
>>
>> });
>>
>> then options.node would be the same jQuery("#content") object but now
>> with all jQuery methods copied inside itself, options.num will remain
>> 4, options.date remain unchanged.
>>
>> I think this behavi
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:
http://jqueryjs.googlecode.com/files/jquery-1.
> 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 reque
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
101 - 200 of 1010 matches
Mail list logo
