Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
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 elem.parentNode ) {
elem.parentNode.selectedIndex;
}
Hmm, I don't remember the bug off-hand but here's the reproduction:
Failing:
http://ejohn.org/files/bugs/selected/
Passing:
http://ejohn.org/files/bugs/selected/fixed.html
2) This seems like over-kill, still. Passing the second parameter will
never break things, so why not just pass it in every case?
var attr = !jQuery.support.hrefNormalized notxml special
// Some attributes require a special call on IE
? elem.getAttribute( name, 2 )
: elem.getAttribute( name );
could be simplified to:
var attr = elem.getAttribute(name,2);
Unfortunately that's not the case - I know that in older versions of
Opera if you tried to use the , 2 it would straight out crash the
browser - which is why we had to do the extra check. It's silly, of
course, since the extra argument shouldn't do anything.
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
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
attributes that we provide better alternatives for (Using .click()
instead of .attr(onclick, fn), for example).
After we tackle the attributes we should look at the most common
properties (like innerHTML, innerText, textContent, etc.) and at least
be able to tell users what to use instead or make sure that they're
supported by .attr() directly.
Also, to further illustrate why I think calling jQuery methods when
calling attr() is a bad idea, take a look at the example page our
great friend David Mark has set up (ignore the insulting url):
http://www.cinsoft.net/jquerysucks.html
Because height() tries to do so much magic, it ends up that this:
$o.attr('height',$o.attr('height'));
I was 100% serious about a ban concerning everything from CLJ. Please,
original ideas/concerns/bug reports/test cases only.
For example, writing up some tests that make sure that you can do:
var a = $(foo).attr(A);
$(foo).attr(A, a);
equals( a, $(foo).attr(A), Attributes did a round-trip and are still equal. );
Would probably be fine.
On the whole though, I'd recommend to just stop reading the group as
who knows what they will try to pull next.
actually gives wrong results. IMO, attr() should be reflexive in that
calling attr() to set a property with a value retrieved from attr()
should always maintain the same value. I just really think the whole
idea of calling methods when getting/setting attributes is bad. What
is the real basis for it?
I discussed this earlier in the thread with Robert Katić.
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
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 cases that we'll want to figure out: http://www.google.com/codesearch?hl=enlr=q=\.attr\%28%22.*%3F%22+lang%3Ajavascriptsbtn=Search Seems petty to me. There is a good test case there that illustrates the problem. I'm not going to reproduce it to shelter jQuery from CLJ. 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. Huh. Unfortunately we really don't want to deal with their bullshit, especially if they're threatening to sue us. As we're looking to transfer ownership of the code base over to the Software Freedom Conservancy we can't take code from tainted sources - and if you're unwilling to take responsibility for your code then we really won't be able to accept code submissions from you. Thankfully we can still use your help in figuring out a good situation for the attributes to be in. Looking forward to your input. Nevertheless, since attr() calls height() for both getter and setter, the real problem is that $o.height( $o.height() ) is not reliable in some cases. So perhaps the issue is there, instead of with attr(). That seems likely. I've never been a fan of head-in-the-sand. I can find the pearls of wisdom in the posts there without taking anything personally. And there is a lot of good, robust, deep stuff posted there that you won't find in blog posts or discussions here. To each his own. Naturally, it's a lot easier to not take it personally when they're not making personal insults against you and threatening to sue you. Thankfully we have people like Juriy Zaytsev that are providing useful ways of contributing to the larger community: http://thinkweb2.com/projects/prototype/ --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Making jQuery.empty over 10x faster
Devon -
Let me explain this in a different way: You're creating a duplicate
copy of the element, one which isn't tied to anything.
Another way to illustrate it:
var divs = $(div);
// .length == 10
divs.eq(0).children().length
// 3
var empty = $(div).empty();
// .length == 10
empty.eq(0).children().length
// 0
divs.eq(0).children().length
// 3
It's not actually emptying out the right elements - you have this
quantum state where you have the same elements and they're both
empty and full.
--John
On Tue, Dec 15, 2009 at 4:04 PM, Devon Govett devongov...@gmail.com wrote:
Karl, yes but this is about empty not remove, which means that the
parent of the removed elements is returned not the children
themselves. For example:
$(div.foo).empty() //returns div.foo not the children of div.foo
The element that we call empty on is not removed from the document so
returning it shouldn't be an issue. It would be an issue for the
remove function, which directly removes the element that you call it
on.
Devon
On Dec 15, 8:37 am, Karl Swedberg k...@englishrules.com wrote:
Devon, some people like to remove elements and have the option of
adding some or all of them back into the DOM at a later time.
DBJDBJ, this is just FYI since you already retracted your suggestion
to add a .detach() method, but jQuery 1.4a already has a .detach()
method. It removes elements from the DOM without removing their events
or data.
--Karl
On Dec 15, 2009, at 7:33 AM, Devon Govett wrote:
@John I would like to ask the same thing DBJDBJ did. Why would you
want to find the index of an element that no longer exists? This just
seems unintuitive. You shouldn't be able to find the index of
something not in the document. The two sets of elements did refer 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:
A major problem with your technique is that the original elements are
simply no longer part of the document.
For example:
var someElems = $(div);
// length == 10
var removed = $(div.foo).remove();
// length == 5
someElems.index( removed )
// -1 (the elements you just removed aren't found!)
This creates a problem: You now have two sets of elements that sort
of
refer to the same thing but actually aren't the same.
--John
On Mon, Dec 14, 2009 at 11:35 PM, Devon Govett
devongov...@gmail.com wrote:
I did some performance testing with the following code, and found it
to be much slower than the cloneNode method, but still often twice
as
fast as the current method.
jQuery.fn.removeAll = function() {
this.each(function() {
var nextSibling = this.nextSibling;
var parent = this.parentNode;
parent.removeChild(this);
while (this.firstChild) {
this.removeChild(this.firstChild);
}
if(nextSibling)
parent.insertBefore(this, nextSibling)
else
parent.appendChild(this);
});
};
What are the problems with the cloneNode method?
Devon
On Dec 13, 5:36 pm, Devon Govett devongov...@gmail.com wrote:
Yeah I tried that too, and it was slightly slower in most browsers
than cloneNode. The other issue with this, is that if the user
has a
slow computer, or the removal is taking a really long time, layout
problems may occur since there is no element in the DOM during the
emptying. The cloneNode method has the advantage that during the
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 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
hesitant to do a cloneNode because of the inherent problems that
exist
in Internet Explorer. I'll see if I have some time to do some perf
testing on this later today.
--John
On Sun, Dec 13, 2009 at 8:19 AM, Devon Govett
devongov...@gmail.com wrote:
Hi all,
I've just blogged about a technique that I used to make
jQuery.empty
over 10x faster in some cases. Basically, rather than
individually
removing each child element from the DOM which causes the
browser to
reflow after each one, I use a shallow cloneNode to do the job
then
copying events back over. Check out the blog post for more
details:
http://devongovett.wordpress.com/2009/12/12/how-to-make-jquery-empty-
I've included some charts
Re: [jquery-dev] Re: Array.prototype.indexOf not fully utilized in jQuery.inArray
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
than a regular function call) and doing one extra property lookup then
the property lookup seems just as reasonable.
Up to you, though. If a bug is filed and some code landed on a Github
branch (that works with non-arrays) then I'll probably just merge it
in.
--John
On Mon, Dec 14, 2009 at 12:21 PM, Markw65 mark...@gmail.com wrote:
Why is it done this way:
inArray: function( elem, array ) {
if ( array.indexOf ) {
return array.indexOf( elem );
}
for ( var i = 0, length = array.length; i length; i++ ) {
if ( array[ i ] === elem ) {
return i;
}
}
return -1;
},
rather than:
inArray: Array.prototype.indexOf ? function(elem,array) { return
array.indexOf(elem) } :
function(elem,array) { ... },
ie, why do the test every time inArray is called, rather than once,
when the library is loaded?
The only reason I can think of is that inArray is supposed to work on
array-like objects too. But the docs explicitly say Array for the
type of the argument...
Even if that case does need to be supported, presumably something like
return Array.prototype.indexOf.call(array, elem) would do the trick?
Mark
On Dec 14, 7:57 am, Brandon Aaron brandon.aa...@gmail.com wrote:
http://github.com/jquery/jquery/blob/master/src/core.js#L49http://github.com/jquery/jquery/blob/master/src/core.js#L571
--
Brandon Aaron
On Mon, Dec 14, 2009 at 4:16 AM, caii caimeic...@beyondsoft.com wrote:
Array.prototype.indexOf?
where it in JQUERY?
On Dec 14, 6:13 pm, Robert Katić robert.ka...@gmail.com wrote:
Already fixed. If Array.prototype.indexOf exists, then it is always
used.
On Dec 14, 10:38 am, helianthus project.heliant...@gmail.com 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 Array.prototype.indexOf could have
been used.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Teardown on plugins
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
(similar to that for events)?
It's extremely common, and a source of bugs when I see:
$.fn.mySuperPlugin = function(){
...code ...
$(document).click(function(e) { ...code... });
...code...
}
Yes, they should be doing adding/removing this event listener every
time their widget 'comes to life'. But there are cases where even
this doesn't work.
I think I remember John talking about this when we were discussing
jQuery Enterprise. It was something like:
$.fn.extend(pluginName,{
setup: function( ...),
teardown: function( ...)
})
In JMVC, I've hacked .remove() to enable plugins to write 'teardown'
functionality. For jQuery, when you use the fn.extend function, it
will wrap setup with something that would add teardown to something
like:
$(el).data(plugins)[pluginName] = teardown.
When remove() is called, it will get all the plugins on the current
element, and call their teardown code.
Someone would also be able to remove a single plugin like:
$(el).data(plugins)[pluginName]()
Ugly, but the case where you want to remove just one plugin is rare.
Thoughts?
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] serialize() doesn't serialize input type=submit
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 it appropriately. I have updated the wiki page to note this: http://docs.jquery.com/Ajax/serialize --John On Mon, Dec 14, 2009 at 3:00 PM, batfastad batfas...@yahoo.co.uk wrote: Hi everyone I've been testing some old sites to start using some jQuery .post goodness and I came across an oddity I decided to serialize() my form data so I don't have to specify the exact data I want posted on loads of different pages. However I notice the value of any submit buttons isn't serialized. Took me many hours to figure that out today. I have a few scripts which branch based on which submit buttons are pressed - it's perfectly acceptable to have more than one and even with different name attributes. I'm guessing it's probably a technical reason as to why submit buttons aren't serialized as it's quite different from the behaviour of regular non-JS HTML forms. Is this on any lists of planned changes for the dev gurus? Is it worth me filing something in the bugs system? One suggestion though... it's probably worth mentioning this on the wiki page for the serialize function as it's definitely not obvious that's what happens. I will create an account and do this if anyone agrees... anything to prevent others from wasting their time! Cheers, B -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] 1.4a1: need help identify an error
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 aplennev...@gmail.com wrote: Hello, I'm trying out 1.4a1 on my application. Something breaks from 1.3.2 and firebug returns this error message: name is undefined jquery-1.4a1.js Line 4047 which line is: name = name.replace( rupper, -$1 ).toLowerCase(); Can you help me see if this is due to an intended non-backward compatible change, or should i file a bug? What could this be related to? Many thanks, Alexandre -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Making jQuery.empty over 10x faster
A major problem with your technique is that the original elements are
simply no longer part of the document.
For example:
var someElems = $(div);
// length == 10
var removed = $(div.foo).remove();
// length == 5
someElems.index( removed )
// -1 (the elements you just removed aren't found!)
This creates a problem: You now have two sets of elements that sort of
refer to the same thing but actually aren't the same.
--John
On Mon, Dec 14, 2009 at 11:35 PM, Devon Govett devongov...@gmail.com wrote:
I did some performance testing with the following code, and found it
to be much slower than the cloneNode method, but still often twice as
fast as the current method.
jQuery.fn.removeAll = function() {
this.each(function() {
var nextSibling = this.nextSibling;
var parent = this.parentNode;
parent.removeChild(this);
while (this.firstChild) {
this.removeChild(this.firstChild);
}
if(nextSibling)
parent.insertBefore(this, nextSibling)
else
parent.appendChild(this);
});
};
What are the problems with the cloneNode method?
Devon
On Dec 13, 5:36 pm, Devon Govett devongov...@gmail.com wrote:
Yeah I tried that too, and it was slightly slower in most browsers
than cloneNode. The other issue with this, is that if the user has a
slow computer, or the removal is taking a really long time, layout
problems may occur since there is no element in the DOM during the
emptying. The cloneNode method has the advantage that during the
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 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
hesitant to do a cloneNode because of the inherent problems that exist
in Internet Explorer. I'll see if I have some time to do some perf
testing on this later today.
--John
On Sun, Dec 13, 2009 at 8:19 AM, Devon Govett devongov...@gmail.com
wrote:
Hi all,
I've just blogged about a technique that I used to make jQuery.empty
over 10x faster in some cases. Basically, rather than individually
removing each child element from the DOM which causes the browser to
reflow after each one, I use a shallow cloneNode to do the job then
copying events back over. Check out the blog post for more details:
http://devongovett.wordpress.com/2009/12/12/how-to-make-jquery-empty-
I've included some charts comparing the performance of jQuery 1.4's
empty and html() functions, as well as the function I've written,
and the cloneNode method out performs all other methods by a
significant amount in all browsers.
Thanks for jQuery!
Devon
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Making jQuery.empty over 10x faster
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 Explorer. I'll see if I have some time to do some perf testing on this later today. --John On Sun, Dec 13, 2009 at 8:19 AM, Devon Govett devongov...@gmail.com wrote: Hi all, I've just blogged about a technique that I used to make jQuery.empty over 10x faster in some cases. Basically, rather than individually removing each child element from the DOM which causes the browser to reflow after each one, I use a shallow cloneNode to do the job then copying events back over. Check out the blog post for more details: http://devongovett.wordpress.com/2009/12/12/how-to-make-jquery-empty-over-10x-faster/. I've included some charts comparing the performance of jQuery 1.4's empty and html() functions, as well as the function I've written, and the cloneNode method out performs all other methods by a significant amount in all browsers. Thanks for jQuery! Devon -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
Just got word from Paul Irish that David Mark is refusing to provide
an open license for his attribute test suite - in fact he's
threatening legal action against me and the Software Freedom
Conservancy if we should cop[y] one word or the tiniest aspect of the
design. Naturally, that branch with the test suite has been
completely deleted.
This attitude is why I refuse to read anything in comp.lang.javascript
and every single time I even get a whiff of what goes on over there I
completely regret it.
Matt, I definitely welcome your help or feedback to the jQuery
project, but please provide your own test cases, test suites, and bug
reports from now on - this goes for anyone else as well. As far as I'm
concerned comp.lang.javascript is completely tainted and using any
code or recommendations from them will be ignored.
This is pretty amusing, actually - threatening legal action against
others for using common-sense test cases is a sure-fire way to make
sure that no one with any sense will read or use the contents in
comp.lang.javascript again.
So it goes. If anyone that hasn't read the aforementioned thread/tests
is interested in writing up some more-comprehensive attribute tests
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() 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 string readonly.
Interesting that you expect that since that directly contradicts the
test suite that you recommended. (It requires the boolean properties
to always return true or false.) Currently (according to the suite)
the only boolean property that jQuery fails on is ismap.
But isn't the attr() method supposed to get the height _attribute_
value? If the attribute is set to 5 and I manipulate it via js, I
still want to get 5 if I look for the attribute value. Otherwise I
would just call height().
So now the attr() method either calls a jQuery method, gets/sets an
element's property, or gets/sets an element's attribute. How is a user
supposed to know what to expect? What exactly is the attr() method
intended to do, if not get/set an element's attributes?
Calling attr() becomes a crap-shoot, because you can never be sure
what it's going to do inside.
I disagree - if anything it helps to bring clarity to the API.
.attr(width) and .width() now return the same value. No reason to
try and return elem.style.width or elem.width if they're not going to
provide a consistent cross-browser value.
3) The list in jQuery.props is still incomplete
Do you have any specific examples?
cellPadding, useMap, accessKey, et al.
Out of those we already support useMap - I see a few more edge cases
in the aforementioned test suite, doesn't seem hard to integrate those
(although it hardly seems like a systemic issue in this regard).
4) The special cases list is still incomplete
Do you have any specific examples?
How about 'action'?
Ah, in that how the URL is resolved - sure, that's a reasonable fix,
just adding it to the current list of checks.
But now you have an setAttribute wrapper that causes a script error
when passed values that would work just fine with setAttribute(). This
seems like a step backwards.
It's only a backwards step if you're attempting to use .attr() as a
glorified way to set DOM 0 events - which is not really something that
jQuery is designed for nor does it encourage.
This is core functionality, and filing/patching bugs on specific
problems with individual attributes wouldn't be very helpful. In fact,
that's perhaps what lead to the method being in the state it is (with
attmpted special cases for tabindex, selected, etc). Instead, I think
someone needs to step back and identify _exactly_ what it is that attr
() is supposed to do, and then code to that standard. Kind of hard now
that you want to maintain backwards-compatibility with this kind of
hybrid functionality, though. Throwing in the hidden execution of
jquery methods when trying to retrieve attribute values just adds to
the confusion even more, and I'm not sure what exactly attr() is
trying to accomplish if that is seen as necessary.
At least looking at the current test suite results I'm not really
seeing any major systemic issues. Of the 9 currently failing tests in
Firefox 3.5 8 of them are cases where the suite is expecting a null
value when an attribute doesn't exist. A few of these I would want to
investigate more but in general I'm not seeing the need for so much
chicken-littling.
In short, constructive ways of contributing include: filing bugs,
constructing test cases, and building reproducible test suites. The
linked-to test suite definitely helps to push
[jquery-dev] Drama in jQuery-dev
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 Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] New $() behaviour
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: A recent commit - http://github.com/jquery/jquery/commit/04524287d3e0112deae570ff9247c734833431bb - changed the behaviour of $() from $(document) to $([]). This is a change that I can truly jibe with, and I think the behaviour makes sense. No one likes having to do $([]) to create an empty jQuery object. Unfortunately, no change for 1.4 has made me think will break a lot of people's code like this one. For some inane reason, people (and a lot of tutorials) really started using the $() shortcut, so the change kind of makes me somewhat uneasy. Would love to hear any other perspectives on this. Should the change stay in and be loudly shouted as a potential 1.4 transition issue, or rolled back? -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
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 much as possible consistent and well defined. 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 think that it's important to integrate it into .attr() so that we can effectively deprecate bad ways of setting DOM attributes or properties. For example, instead of doing .attr(innerHTML, some html) we can offer the much saner .attr(html, some html) same with .attr(onclick, fn) becoming .attr(click, fn) - both of these are removing the weirdness of the existing DOM APIs by providing something that's much better. Placing this in a separate function creates un-needed ambiguity. I dislike it for the same reason that I dislike having an extra .prop() method for setting just DOM object properties. We should be able to provide a unified API for setting information (called 'attr' in jQuery, mostly for legacy reasons - it actually was 'set' back when jQuery was first released) and work to meet the user's expectations based upon that. Unfortunately, for me, it seams that jQuery API is going to prefer beginner users with cost of ignoring true potentials (i.e. live()). How's that? .live() has seen considerable improvements since 1.3.2 both in the form of features (context limiting, data support), cross browser compatibility (submit, change, focus, blur, mouseenter, mouseleave), and performance (huge speed-ups to .closest() and node checking). As far as I know I've also landed every patch you've submitted to the jQuery Github fork queue. Perhaps there's something else that you're not divulging? --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] .appendTo() behaviour
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 12, 2009 at 12:11 PM, Raul DIas rauld...@gmail.com wrote:
please, enlight me.
$(A).appendTo(B) will move $(A) to selector B, which in most cases has
to be an ID or a unique identified element.
For this behaviour, what happens if B specifies multiple elements
(e.g. class, element selector)?
WIll it clone and copy $(A) ?
If so, the original $(A) will still be in the same parent?
appendTo() should accepts elements and jq objects too as it would be
more clear (and avoid) the multi-element selector problem.
Here is a behaviour that I would like to replicate in pure jQuery:
1 - Create an anonymous element:
var divContent = document.createElement(div);
or
var divContent = $(div/);
2 - move (reparent) the children from '#old_parent' to the new element
(divContent):
A - Using jQuery + DOM:
$(#old_parent).children().each(
function() {
divContent.appendChild(this);
}
);
B - Using jQuery (or how it would have being) (wont work):
$(#old_parent).children().appendTo(divContent);
Using a selector is not possible when dealing with anonymous elements.
So, am I missing something?
Can this be considered a bug?
-rsd
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] attr() is still very broken in 1.4a1
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
height or wrap? It won't retrieve the attribute value, but
instead, runs the height() or wrap() methods!
The wrap one was a mistake (the code in 1.4a1 covered too many
methods) it's since been scaled back. In the case of height, for
example, we definitely do want to get the height value as reported by
.height(), especially since it's likely to be more accurate than
trying to get elem.height.
3) The list in jQuery.props is still incomplete
Do you have any specific examples?
4) The special cases list is still incomplete
Do you have any specific examples?
5) It forces values to be strings, so I can't set attributes like attr
('onclick',function(){...}) which in theory should work just fine. In
FF, for example, el.setAttribute('onclick',function(){...}) works as
expected.
I don't think that's a case that we particularly want to support,
though. In 1.4 you can just do: .attr(click, function(){}) and it
would work (albeit tied into the full event system, which is much
better).
Referenced is a good, robust review of attribute handling with test
cases that should probably be in the jQuery test suite:
http://www.cinsoft.net/attributes.html
I don't see a particular license on those tests - are they available
under an MIT license?
Any hopes of fixing it up soon?
Specific filed bugs and test cases would certainly accelerate the process.
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] attr() is still very broken in 1.4a1
I integrated the tests in the following branch:
http://github.com/jquery/jquery/commits/attr
At first scan it looks like the majority of the ~10 failures in
Firefox relate to the suite expecting 'null' and us returning some
other false-y value. That seems like an easy enough fix.
Found two bugs in the suite:
- In the document element test it's not actually testing the document
element, but a form.
- One line has removeAttr(el, 'xyz', 'abc'); which seems to have an
unnecessary 3rd argument.
I'm not sure if I'll have time to work on this more 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 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 from there.
--John
On Fri, Dec 11, 2009 at 9:10 AM, John Resig jere...@gmail.com wrote:
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
height or wrap? It won't retrieve the attribute value, but
instead, runs the height() or wrap() methods!
The wrap one was a mistake (the code in 1.4a1 covered too many
methods) it's since been scaled back. In the case of height, for
example, we definitely do want to get the height value as reported by
.height(), especially since it's likely to be more accurate than
trying to get elem.height.
3) The list in jQuery.props is still incomplete
Do you have any specific examples?
4) The special cases list is still incomplete
Do you have any specific examples?
5) It forces values to be strings, so I can't set attributes like attr
('onclick',function(){...}) which in theory should work just fine. In
FF, for example, el.setAttribute('onclick',function(){...}) works as
expected.
I don't think that's a case that we particularly want to support,
though. In 1.4 you can just do: .attr(click, function(){}) and it
would work (albeit tied into the full event system, which is much
better).
Referenced is a good, robust review of attribute handling with test
cases that should probably be in the jQuery test suite:
http://www.cinsoft.net/attributes.html
I don't see a particular license on those tests - are they available
under an MIT license?
Any hopes of fixing it up soon?
Specific filed bugs and test cases would certainly accelerate the process.
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
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 would
expect to get back the string readonly.
Interesting that you expect that since that directly contradicts the
test suite that you recommended. (It requires the boolean properties
to always return true or false.) Currently (according to the suite)
the only boolean property that jQuery fails on is ismap.
But isn't the attr() method supposed to get the height _attribute_
value? If the attribute is set to 5 and I manipulate it via js, I
still want to get 5 if I look for the attribute value. Otherwise I
would just call height().
So now the attr() method either calls a jQuery method, gets/sets an
element's property, or gets/sets an element's attribute. How is a user
supposed to know what to expect? What exactly is the attr() method
intended to do, if not get/set an element's attributes?
Calling attr() becomes a crap-shoot, because you can never be sure
what it's going to do inside.
I disagree - if anything it helps to bring clarity to the API.
.attr(width) and .width() now return the same value. No reason to
try and return elem.style.width or elem.width if they're not going to
provide a consistent cross-browser value.
3) The list in jQuery.props is still incomplete
Do you have any specific examples?
cellPadding, useMap, accessKey, et al.
Out of those we already support useMap - I see a few more edge cases
in the aforementioned test suite, doesn't seem hard to integrate those
(although it hardly seems like a systemic issue in this regard).
4) The special cases list is still incomplete
Do you have any specific examples?
How about 'action'?
Ah, in that how the URL is resolved - sure, that's a reasonable fix,
just adding it to the current list of checks.
But now you have an setAttribute wrapper that causes a script error
when passed values that would work just fine with setAttribute(). This
seems like a step backwards.
It's only a backwards step if you're attempting to use .attr() as a
glorified way to set DOM 0 events - which is not really something that
jQuery is designed for nor does it encourage.
This is core functionality, and filing/patching bugs on specific
problems with individual attributes wouldn't be very helpful. In fact,
that's perhaps what lead to the method being in the state it is (with
attmpted special cases for tabindex, selected, etc). Instead, I think
someone needs to step back and identify _exactly_ what it is that attr
() is supposed to do, and then code to that standard. Kind of hard now
that you want to maintain backwards-compatibility with this kind of
hybrid functionality, though. Throwing in the hidden execution of
jquery methods when trying to retrieve attribute values just adds to
the confusion even more, and I'm not sure what exactly attr() is
trying to accomplish if that is seen as necessary.
At least looking at the current test suite results I'm not really
seeing any major systemic issues. Of the 9 currently failing tests in
Firefox 3.5 8 of them are cases where the suite is expecting a null
value when an attribute doesn't exist. A few of these I would want to
investigate more but in general I'm not seeing the need for so much
chicken-littling.
In short, constructive ways of contributing include: filing bugs,
constructing test cases, and building reproducible test suites. The
linked-to test suite definitely helps to push this in the right
direction. We can fix bugs based upon that and if we see systemic
issues with the method we can certainly rewrite it. Since 1.4 final
isn't out yet there is still room to make some backwards-incompatible
changes (especially if we start reporting null instead of the default
value for attributes).
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Inconsistency between 1.3.2 and 1.4a
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 PM, ajpiano ajpi...@gmail.com wrote: Not sure if this merits a ticket because it ventures off into the world of things that people don't actually do, but I figured it was at least worth a mention. in jQuery 1.3.2 var foo = $(divspanfoo/span/div).parent() // returns a DIV wrapped with jQuery, and accordingly foo.find(span).length === 1; in jQuery 1.4 var foo = $(divspanfoo/span/div).parent() // returns a DocumentFragment wrapped with jQuery, and accordingly foo.find(span).length === 0; I'm not sure if this piques anyone else's attention like it did mine. Getting to behave the same would require getting .find() to work directly on DocumentFragments instead of their .contents(), which I am less than sure is a priority. --adam -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Event module in repository
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 wrote: Just curious, do the event module unit tests pass in IE ? Acts all weird for me (including a nasty redirection) but I'm not sure if it's because of my ajax rewriting or not. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: feature request: traversing through iframes
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 what a CSS selector means and what a
jQuery selector means. Think about this code:
iframe src=http://google.com;
pThis browser doesn't support iframes, or has them disabled./p
/iframe
This css selector will make the error message bold:
iframe p { font-weight: bold }
With the proposed change, this selector would bold all the p tags in
the google.com page:
$(iframe p).css(font-weight, bold);
That's too much magic for me. The iframe contents aren't part of the
current document, they're in a document unto themselves.
As for how to make selector syntax more symmetrical with the method
syntax, how about a :contents pseudo?
$(iframe:contents p).addClass(error) === $(iframe).contents
().find(p).addClass(error)
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Ajax refactoring V2
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 transport similar to the one I had developped for my jquery-jsonp plugin (soon to be obsolete, hopefully). Made me confident enough coding a new transport and binding it to a dataType is both easy and non-intrusive. I have some refactoring to do between $.ajax and $.ajax.createRequest but we're almost there. On 8 déc, 23:56, Julian Aubourg aubourg.jul...@gmail.com wrote: Just comitted version 2 of the ajax refactoring for those interested. The tree is in sync with latest jQuery tree. No more global transport selection function: transports are now bound to dataTypes through jQuery.ajax.bindTransport( dataTypeSelector, factoryFunction ). The dataTypeSelector is a string containing dataType names separated by spaces. If you put a + sign in front of the dataType name, then the transport will be the first one to be tested for that specific dataType. For instance: jQuery.ajax.bindTransport( +json text, myTransportFactoryFunction ) ensures myTransportFactoryFunction is the first one called for a request with json dataType and the last one called for a request with test dataType. The factory function is in charge of determining if its transport is suitable for the given request (it gets the request options object as its only parameter). It can return the transport object (with a mandatory send method and an optional abort method) or nothing (or false). If it does the latter, two cases : 1) the dataType in the options object hasn't been changed, in which case the selector looks for the next transport in line 2) the dataType has been changed and the selector intelligently redirects to the transports for this new dataType. Transports are tested for the dataType and, if non was found, for the catchall * transports. An exception is raised if no transport is found. Edge cases, such as cumbersome request type detections, can be handled using jQuery.ajax.prefilter( prefilteringFunction ): you can see an example of that in transports/jsonp.js. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Event module in repository
Oof, ok - I wonder what I broke. I wonder if it's failing on this: http://github.com/jquery/jquery/commit/7d36ccfa8eb018fcf349e1f74e3a0a614385558f (Maybe the support change submit checks aren't reporting false properly in IE?) Any help remote-debugging this issue would be appreciated. --John On Wed, Dec 9, 2009 at 11:29 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: OK, I tested to be sure. Latest source tree does not pass tests in IE. 2009/12/9 DBJDBJ dbj...@gmail.com @John, never be away from an IE capable computer ;o) Just when you think you are free, they pull you 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 it was as of last Friday. --John On Wed, Dec 9, 2009 at 7:51 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: Just curious, do the event module unit tests pass in IE ? Acts all weird for me (including a nasty redirection) but I'm not sure if it's because of my ajax rewriting or not. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Event module in repository
Right, the redirection is because the live submit event is being triggered but not blocked - which means that live submit isn't working, which is why I referred to that commit (which is the only change to live submit/change since 1.4a1). --John On Wed, Dec 9, 2009 at 11:58 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: I tested quickly with the two first tests in unit/event.js but IE doesn't report any javascript error. Tests fail though. Sad thing is, if you try test all of unit/event.js, at one point, the page tries to redirect to another page: http://127.0.0.1/zend/jquery/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...@gmail.com Oof, ok - I wonder what I broke. I wonder if it's failing on this: http://github.com/jquery/jquery/commit/7d36ccfa8eb018fcf349e1f74e3a0a614385558f (Maybe the support change submit checks aren't reporting false properly in IE?) Any help remote-debugging this issue would be appreciated. --John On Wed, Dec 9, 2009 at 11:29 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: OK, I tested to be sure. Latest source tree does not pass tests in IE. 2009/12/9 DBJDBJ dbj...@gmail.com @John, never be away from an IE capable computer ;o) Just when you think you are free, they pull you 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 it was as of last Friday. --John On Wed, Dec 9, 2009 at 7:51 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: Just curious, do the event module unit tests pass in IE ? Acts all weird for me (including a nasty redirection) but I'm not sure if it's because of my ajax rewriting or not. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Trim was changed, then borked - so changed back (to original bug)
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 leading/trainling). I checked GIT and there was a fix for
it. Buuut, it looks like the fix was to return it to how it was
originally - but i think that means the bug it was trying to fix
should be reopened...
http://dev.jquery.com/ticket/4980
Here's how the code has changed:
In 1.3.2:
trim: function( text ) {
return (text || ).replace( /^\s+|\s+$/g, );
}
In 1.4a1:
rtrim = /(\s|\u00A0)+|(\s|\u00A0)+$/g,
trim: function( text ) {
return (text || ).replace( rtrim, );
},
And the new fix:
rtrim = /^\s+|\s+$/g,
trim: function( text ) {
return (text || ).replace( rtrim, );
},
I think that if the original bug was valid then rtrim should be
cahnged to:
rtrim = /^(\s|\u00A0)+|(\s|\u00A0)+$/g,
Earle.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Selected option and form reset weirdness in IE, bug #2551
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 still open from back in the 1.2 days. I just ran into it today and dug into what was really the problem. Basically if you don't add a selected attribute to one of your options and use an input type=reset or reset() IE reports some weirdness. Is this something that could be worked around in jQuery 1.4 or should it be assumed that there will always be a selected attribute? -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: What's wrong in my code?
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, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] feature request: traversing through iframes
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 the selector began with an ID - and that
seems a bit weird.
I'd be open to an alternative proposal: Simply removing the need to
have to do .contents() before calling .find(), this way you could do:
$(iframe).find(body) or $(body, iframe)
Does this work?
--John
On Tue, Dec 8, 2009 at 9:24 PM, Paul Bakaus paul.bak...@googlemail.com wrote:
Hey guys,
here's a feature request I just added as a ticket
(http://dev.jquery.com/ticket/5617). I was thinking about this for a long
time
and came to the conclusion that this really fits into Core, not into a
plugin IMHO. Useful and small enough for a broad audience.
Ticket content:
Currently, the syntax to query iframes looks like this:
$('#someIframe').contents().find('p').addClass('error')
which isn't too bad. However, I think another abstraction could really fit
into our core philosophy, which is transforming the above into this:
$('#someIframe p').addClass('error');
I think it wouldn't add much overhead to Sizzle / jQuery, a simple check if
nodeName equals iframe, and then changing the actual DOM element
representation for further queuries down the selector to the
contentDocument.
Additionally, make browsing up possible:
$(document).parent()
Yay / Nay?
--
Paul Bakaus
UI Architect @ smart.fm
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] feature request: traversing through iframes
I don't think there are other cases where find works differently than
the traditional selector.
As it stands I don't really see a way to land this change in a way
that won't A) Slow down code and B) Provide weird and inconsistent
results.
Seems like it's probably a no-go. 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 paul.bak...@googlemail.com wrote:
On Wed, Dec 9, 2009 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, theoretically, get your
proposal to work but ONLY if the selector began with an ID - and that
seems a bit weird.
I'd be open to an alternative proposal: Simply removing the need to
have to do .contents() before calling .find(), this way you could do:
$(iframe).find(body) or $(body, iframe)
Does this work?
I understand the technical implication and problem, but I still think the
ideal
solution would be the one proposed.
Making it only work for id's is pretty weird I agree, but the find()
proposal is
only slightly better. I believe that most jQuery users do not see a
difference
between
$('#elem').find('p')
and
$('#elem p')
so again, people would run against a wall when seeing $('#iframe').find('p')
and then later trying $('#iframe p'). Is there any other case where find
works
differently than another selector part?
--John
On Tue, Dec 8, 2009 at 9:24 PM, Paul Bakaus paul.bak...@googlemail.com
wrote:
Hey guys,
here's a feature request I just added as a ticket
(http://dev.jquery.com/ticket/5617). I was thinking about this for a
long
time
and came to the conclusion that this really fits into Core, not into a
plugin IMHO. Useful and small enough for a broad audience.
Ticket content:
Currently, the syntax to query iframes looks like this:
$('#someIframe').contents().find('p').addClass('error')
which isn't too bad. However, I think another abstraction could really
fit
into our core philosophy, which is transforming the above into this:
$('#someIframe p').addClass('error');
I think it wouldn't add much overhead to Sizzle / jQuery, a simple check
if
nodeName equals iframe, and then changing the actual DOM element
representation for further queuries down the selector to the
contentDocument.
Additionally, make browsing up possible:
$(document).parent()
Yay / Nay?
--
Paul Bakaus
UI Architect @ smart.fm
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
Paul Bakaus
UI Architect @ smart.fm
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] make breaks after pulling commits from GitHub
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 later today and revisit it then. Sorry about that! --John On Mon, Dec 7, 2009 at 4:56 AM, Karl Swedberg k...@englishrules.com wrote: I pulled in the latest changes this morning from the jQuery GitHub repo, but when I tried to run make it threw a couple errors: ERROR] 1:0:Compilation produced 2 syntax errors. org.mozilla.javascript.EvaluatorException: Compilation produced 2 syntax errors. at com.yahoo.platform.yui.compressor.YUICompressor$1.runtimeError(YUICompressor.java:135) at org.mozilla.javascript.Parser.parse(Parser.java:410) at org.mozilla.javascript.Parser.parse(Parser.java:355) at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:312) at com.yahoo.platform.yui.compressor.JavaScriptCompressor.init(JavaScriptCompressor.java:533) at com.yahoo.platform.yui.compressor.YUICompressor.main(YUICompressor.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:20) make: *** [dist/jquery.min.js] Error 2 In the dist folder, the jquery.min.js file is now empty and the jquery.js file is throwing an error. Any ideas? --Karl -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] make breaks after pulling commits from GitHub
I've landed commits to fix both of the aforementioned issues. (I would've done it sooner but was without Internet today - sorry!) --John On Mon, Dec 7, 2009 at 2:08 PM, Will goo...@reboot.ch wrote: FYI, there is a p in excess in Rakefile latest commit # Basic Rakefile 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/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 later today and revisit it then. Sorry about that! --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: problem with use of null in jQuery.speed
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.
- Lloyd
On Sep 22, 6:25 am, weepy jonah...@gmail.com wrote:
recently had a problem here ... on line 3968 of jquery.js
speed: function(speed, easing, fn) {
var opt = typeofspeed=== object ?speed: {
the trouble is thatspeedwas null rather than undefined and
typeofnullis object, resulting in
(opt ==null) = true , which throws errors on the following lines.
perhaps
var opt = (speed typeofspeed=== object) ?speed: {
Cheers
weepy
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] jQuery 1.4 Alpha 1 Released
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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: jQuery 1.4 Alpha 1 Released
Shamed Yehuda into fixing it: http://github.com/jquery/jquery/commit/d684122be0ce3484fb9a4ead11db98d18c5805e7 ;) Thanks for the catch! --John On Fri, Dec 4, 2009 at 9:03 PM, helianthus project.heliant...@gmail.com wrote: i guess i just found a bug? At line 3961, the filter variable 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 -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] new Date style
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 the time back. I just landed one fix: In support.js we were using (new Date).getTime() instead of our now() function that we use everywhere (save for Sizzle, which is a separate project). There is no appreciable performance difference between the two techniques - and certainly not in any quantity that would affect us more than the actual now() function call. --John On Thu, Dec 3, 2009 at 6:13 AM, Ash ash.sea...@gmail.com wrote: Grepping for 'new Date' through the jquery source shows a bit of variety in Date - Time handling. Casual question really: Is there an aim to get consistency in the code- base, or a house style on how to handle dates? Some of the variety seems to come from context and purpose: when you're optimising for code-size +new Date is great, but people shy away from using that in the middle of an expression: src/sizzle/sizzle.js: id = script + (new Date).getTime(); I know the git repo contains source from several different projects, and suspect the variation in style may reflect the average competence of project contributors. I'm probably over-analysing, but wondered if anyone else had noticed this, or checked whether +new Date performed any differently to new Date().getTime() etc. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Google JS Tools
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 optimizations. I recommend that if you wish to use the advanced compilation options that you compile jQuery + your plugins + your scripts all together into a single file - that's the use case that the closure compiler was designed for. --John On Wed, Dec 2, 2009 at 11:45 AM, mike.helgeson mike.helge...@gmail.com wrote: In case anyone is interested, I just stumbled on this product from google... http://code.google.com/closure/ With a web interface and REST API http://closure-compiler.appspot.com/home And a Firebug extension... http://code.google.com/closure/compiler/docs/inspector.html -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: $.ajax feature matrix
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 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: $.ajax feature matrix
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 the fix for it earlier today. We should be all good now. --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: $.ajax feature matrix
Well, we don't want isObject (or isJavaScriptObject or
isNativeObject) since that'll allow things like 'new String'. We
explicitly want the case where people are using {} or new Object in
their code, adding on some properties, and passing it around. It sound
like you're worried about some sort of semantic difference between
isObjectLiteral and wasDefinedUsingAnObjectLiteral - but I don't think
that really matters.
--John
On Wed, Dec 2, 2009 at 7:36 PM, Michael Geary m...@mg.to wrote:
isObjectLiteral is a really poor name for that function. It makes no sense
at all. An object *literal* is text. It's not an object until it's parsed,
and then it's not an object literal any more, it's just an Object.
Case in point: jQuery.isObjectLiteral({}) and jQuery.isObjectLiteral(new
Object) both return true. I don't think there is any way to distinguish
between a '{}' and a 'new Object', is there?
This function definitely needs to be renamed. What does it actually do? Is
its purpose to distinguish between a JavaScript object and a DOM object?
Then it could be called isJavaScriptObject or isNativeObject or some such.
Not isObjectLiteral please.
Sorry, this is one of my pet peeves - the Google Maps API documentation
describes many of its option objects as object literals, which is quite
misleading and confusing. (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 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 like magic to me sometimes.
I actually landed the fix for it earlier today. We should be all good now.
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Unable to pull qunit sizzle submodules in forked git repo
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/246949 --John On Tue, Dec 1, 2009 at 9:04 PM, Mark Gibson jollyt...@gmail.com wrote: Ok, I've just had chance to play about. I've performed a new clone: $ git clone g...@github.com:jollytoad/jquery.git Initialized empty Git repository in /home/mark/git/jquery/.git/ remote: Counting objects: 10347, done. remote: Compressing objects: 100% (3098/3098), done. remote: Total 10347 (delta 6801), reused 10279 (delta 6749) Receiving objects: 100% (10347/10347), 4.94 MiB | 1.07 MiB/s, done. Resolving deltas: 100% (6801/6801), done. $ cd jquery $ make init Grabbing external dependencies... cd: 1: can't cd to src/sizzle make: *** [init] Error 2 Both 'git submodule init' and 'git submodule update' produce no output at all! So, I tried manually adding the submodules: $ git submodule add git://github.com/jquery/qunit.git test/qunit Initialized empty Git repository in /home/mark/git/jquery/test/qunit/.git/ remote: Counting objects: 347, done. remote: Compressing objects: 100% (271/271), done. remote: Total 347 (delta 121), reused 224 (delta 75) Receiving objects: 100% (347/347), 74.04 KiB, done. Resolving deltas: 100% (121/121), done. $ git submodule add git://github.com/jeresig/sizzle.git src/sizzle Initialized empty Git repository in /home/mark/git/jquery/src/sizzle/.git/ remote: Counting objects: 895, done. remote: Compressing objects: 100% (866/866), done. remote: Total 895 (delta 576), reused 57 (delta 10) Receiving objects: 100% (895/895), 431.53 KiB | 388 KiB/s, done. Resolving deltas: 100% (576/576), done. $ git submodule init Submodule 'src/sizzle' (git://github.com/jeresig/sizzle.git) registered for path 'src/sizzle' Submodule 'test/qunit' (git://github.com/jquery/qunit.git) registered for path 'test/qunit' ...and now it works :) (was using git version 1.6.3.3, now on 1.6.5.3) - Mark 2009/11/27 Chris Wanstrath ch...@logicalawesome.com: On Thu, Nov 26, 2009 at 6:13 PM, Mark Gibson jollyt...@gmail.com wrote: Hi, has anyone managed to build jQuery from a forked repository? Here's what I did: 1. forked http://github.com/jquery/jquery to http://github.com/defunkt/jquery 2. cloned g...@github.com:defunkt/jquery.git 3. ran `make init` in my jquery clone 4. saw this output: http://gist.github.com/244143 5. ran `make init` again, saw similar output: http://gist.github.com/244144 6. deleted my local clone, re-cloned, added a `jquery` remote: http://gist.github.com/244147 7. ran `make init`, saw original output: http://gist.github.com/244149 Is that similar to what you're doing? What does running `git submodule init` then `git submodule update` manually give you? Also, what version of Git are you on? $ git --version git version 1.6.4.2 -- Chris Wanstrath http://defunkt.github.com/ -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: $.ajax feature matrix
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 to get it ready for inclusion: http://docs.jquery.com/JQuery_Core_Style_Guidelines Naturally, making sure that all the tests pass as well is a great way to make sure that the code lands. --John On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: Thanks Dave but I think I kinda figured it out! Anyway, the code has been comitted at http://github.com/jaubourg/jquery I don't have time to write everything about it down right now but you can all have a look at least. 2009/12/2 Dave Methvin dave.meth...@gmail.com OK, so I have implemented my solution: Anyway, for the time being, my branch is sitting on my harddrive. Why? Well, I've been practicing source control for years now but I have to admit I never encountered something as cryptic and unfriendly as git. So, if anyone has clear step in order to commit with this zealot, please do share before I commit suicide. I made a fork of jQuery on github btw. Julian, I'm still coming up to speed with Git on Windows myself, and stuck at trying to push my changes back to my fork on Github. I'm going to start a new thread here about it. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Cannot add a comment tag inside a TR tag
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 tags (if the comment is at the beginning of the string) or get ignored if the comment is at the end. So, let's say I have a simple table table tr id=myTr tdcell1/td tdcell2/td /tr /table Doing: $(#myTr).html(!-- refreshed row --tdnewCell1/ tdtdnewCell2/td); Will result in just newCellnewCell2 inside the tr. All tds disappeared and the guilty comment went away as well. Using innerHTML seems to work better, but I would prefer standardizing on $.html(), $.append(), ... regardless of the container tag. Thank you for any help. I run Firefox 3.0.1 on Win7/64bit. Jeremy, -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] support.scriptEval + globalEval + text property
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, 2009 at 8:50 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Hi guys,
I know there is nothing about it in the W3C specs but AFAIK the text
property seems to be a de-facto standard as innerHTML is.
Since jQuery is using test swarm I wonder if it could be cleaned/speed up a
little bit avoiding the appendChild with a document.createTextNode and using
just text property.
This will make jQuery initialization a bit faster, without a try catch plus
other specific operations in the support.js file and the globalEval smaller.
// Evalulates a script in a global context
globalEval: function( data ) {
if ( data rnotwhite.test(data) ) {
// Inspired by code by Andrea Giammarchi
//
http://webreflection.blogspot.com/2007/08/global-scope-evaluation-and-dom.html
var head = document.getElementsByTagName(head)[0] ||
document.documentElement,
script = document.createElement(script);
script.type = text/javascript;
script.text = data;
// Use insertBefore instead of appendChild to
circumvent an IE6 bug.
// This arises when a base node is used (#2709).
head.insertBefore( script, head.firstChild );
head.removeChild( script );
}
},
Regards
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] support.scriptEval + globalEval + text property
Firefox 2 + 3, Safari 3, Opera 9.6? I'm a bit confused as to what you're saying - it doesn't work at all in Safari 2 or you didn't test in Safari 2. Could you test it there, as well? --John On Sun, Nov 29, 2009 at 4:20 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: My tests: Android 1.6 OK Firefox 3.6 OK Safari 4.0.4 OK Opera 10.10 OK Chrome 4.0.249.11 IE all, text is the fallback already used in jQuery to global eval I am going to test Konqueror as well but I do think except Safari 2 which is not in the jQuery browser list, text could be considered a de-facto 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 :-) This is a test page which should show success: true if the browser is compatible. http://www.3site.eu/jstests/script.text.html Let me know if you need something else, thanks. Regards -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] support.scriptEval + globalEval + text property
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 code works, it could be simplified slightly (by only using .text) but if it's at the expense of losing functionality for a browser then I don't really think we should do it. --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Ant build
Very interesting - reading through the docs it looks like setting core.autocrlf to 'input' is pretty useful (it'll make sure that the line-endings are just LF for anyone that commits, which is what we want). Let's hope this works, I guess! http://github.com/jquery/jquery/commit/1879e8cbeef6984495ee84f482900defda0dc3f4 --John On Fri, Nov 27, 2009 at 1:42 AM, Daniel Friesen nadir.seen.f...@gmail.com wrote: Some info from google: http://www.kernel.org/pub/software/scm/git-core/docs/gitattributes.html#_checking_out_and_checking_in http://www.mail-archive.com/msys...@googlegroups.com/msg00093.html http://www.mail-archive.com/msys...@googlegroups.com/msg00088.html Looks like this can be solved in the repo itself for everyone using a .gitattributes file. Nothing new really, svn has a similar type of configuration. As I understand, in the svn world the trend is to make sure each individual developer adds a dozen or so lines to their global auto-props when they get commit access so that each and every file they create automatically gets the right props set on each of them individually. And if anyone is missing the props another commit is needed to fix any files they miss. ;) In the git world, it seams you can add one .gitattributes file with a bit of short config to affect every file in the repo and affect everyone who checks out the repo without needing to tell them Please set these personal auto-props settings in your personal global config that'll conflict with other projects you work on that want different settings than we want or you'll annoy all of us. Heh, yay git!? Now that I think about it. Did I set my 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.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? --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Ant build
Just to clarify: Java/JRE isn't required in order to do the basic build of jQuery - only to do the minified build. --John On Fri, Nov 27, 2009 at 12:35 PM, DBJDBJ dbj...@gmail.com wrote: I am (happily) using one (rudimentary) cmd file for (windows) building. It is a bit of a overkill to install the whole JRE, +ant , just to be able to concatenate jQuery files into one...With cmd file(s) one can build a real make system no ant, make, gmake, etc ... necessary. --DBJ On Nov 25, 6:56 pm, Justin Meyer justinbme...@gmail.com wrote: Only sizzle runs for some reason. Likely b/c I am using windows. Does this work for someone else using msysgit? Here's the output: -- $ make Grabbing external dependencies... Submodule 'src/sizzle' (git://github.com/jeresig/sizzle.git) registered for path 'src/sizzle' Initialized empty Git repository in c:/Development/jquery/src/ sizzle/.git/ remote: Counting objects: 895, done. remote: Compressing objects: 100% (866/866), done. remote: Total 895 (delta 570), reused 57 (delta 10) Receiving objects: 100% (895/895), 449.82 KiB | 159 KiB/s, done. Resolving deltas: 100% (570/570), done. Submodule path 'src/sizzle': checked out '3e97c27d19e18c984a29bfea89fcccadf3544f b3' Building selector code from Sizzle Building ./dist/jquery.js ./dist/jquery.js Built Building ./dist/jquery.min.js - Compressing using Minifier ./dist/jquery.min.js Built jQuery build complete. - However, the .gitmodules looks right: [submodule test/qunit] path = test/qunit url = git://github.com/jquery/qunit.git [submodule src/sizzle] path = src/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 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 lives as a copy in the jQuery repository. QUnit should be pulled in as a sort of git external, though its required only for testing, not for making a build of jQuery itself. Jörn On Tue, Nov 10, 2009 at 4:37 AM,JustinMeyerjustinbme...@gmail.com wrote: Does building with Ant work from github anymore? I'm guessing no b/c it needs to get QUnit/Sizzle. Would it be nice if you could pull in dependencies in JS like ruby's gem install, and all your building would already be done via JavaScript. Hm ... JMVC has this feature :). -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Unable to pull qunit sizzle submodules in forked git repo
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 build jQuery from a forked repository? The submodules won't pull in the clone of my forked repo, I can't work out why - 'make init' does nothing, all I get is this: Grabbing external dependencies... From g...@github.com:jollytoad/jquery * branch master - FETCH_HEAD Already up-to-date. From g...@github.com:jollytoad/jquery * branch master - FETCH_HEAD Already up-to-date. It works fine though if I clone the original repo from git://github.com/jquery/jquery.git and run 'make init'. This is my .git/config: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = g...@github.com:jollytoad/jquery.git [branch master] remote = origin merge = refs/heads/master [remote jquery] url = git://github.com/jquery/jquery.git fetch = +refs/heads/*:refs/remotes/jquery/* and .gitmodules: [submodule test/qunit] path = test/qunit url = git://github.com/jquery/qunit.git [submodule src/sizzle] path = src/sizzle url = git://github.com/jeresig/sizzle.git Any ideas? - Mark -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Ant build
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-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] jQuery.each(nodeList, ...)
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 think it is worth of consideration: 1. $.each(nodeList) is already possible and I suppose that there are individuals that are considering that action legal because NodeLists are array like things too. Unfortunately it is not always true in IE and Opera where length expando can be overwrited. 2. Using $.each, $.map and $.grep directly with NodeLists can be still useful, not only for optimizing jQuery itself. I made a patch that would fix this http://github.com/rkatic/jquery/commit/7203092c23d5ddb623495f9145d2dab3edf1c529 If this change is welcome, than I will open a ticket... -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: typo in ready event since null !== undefined
As I mentioned before - I'd *love* to have a solution for this. Any working solution for Firefox 3.6 will be happily accepted. --John On Wed, Nov 18, 2009 at 10:44 AM, Shade get...@gmail.com wrote: I just want to say that I still think that the document.readyState problem is an issue that needs further addressing than what jquery is planning to ship right now. This bug brought this topic up a few months back: http://dev.jquery.com/ticket/4889 At the time, as John said, we thought it would be ok the solution that is now in, because FF3.5 was going to finally include document.readyState, and so the number of browsers affected by the problem by the time jquery released again would be minimal... FF3 and below has to be a dwindling number now. But, now that we know that FF 3.5 still has this problem, and it only *may* end up FF3.6, and that jquery is releasing soon, I think there will be a lot of people still affected by this problem. FF3.5 will be around for a non-trivial amount of time, even if FF3.6 released today (which we know it will still be a little while). Here's the primary reason I consider this an issue worth more effort: I have been pushing this tool I built called LABjs (http://labjs.com) which is a parallel script loader. It's getting a lot of good support and reviews so far, but it suffers one major problem (and almost all loaders have this same issue): it can't be used safely to load scripts like jquery, because if it happens to load the script after the page's domready, then all $(document).ready(...) related code will sit idle and never be fired! This is a major achilles' heel for any script loader. Whether you like LABjs or not, or plan to use it or something like it or not, there are starting to be more and more places where people are trying to accelerate the loading of their pages through various techniques like dynamic script loading (XHR, etc), meaning it's going to more and more likely that jquery gets added to a page in some other way than through a normal blocking script tag. This means that this problem with it detecting domready will get more and more obvious until we find a way to solve it. Every time I have given a talk about LABjs over the last couple of months, I've mentioned this caveat but said But, at least with the next jQuery this will be fixed. But, now hearing that even with FF3.5 it won't be fixed yet, I think we need something better, even if we just do some sort of temporary hacks for a release or two until we have stable browser base where this works. I know that jQuery doesn't officially guarantee this usage but that I think is a troublesome blindsight to just ignore. It's a perfectly valid use-case for jquery (think about bookmarklets, etc), it's not at all documented very well that this problem exists, and the web is moving to more and more of various different tricks to load things in different ways, which *will* expose the problem even more. I think we should run some tests to prove whether or not Andrea's code solution addresses this problem for FF or not. Or we could revisit the code from the bug I linked, which was actually from SWFObject, 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 and a little more accepting of hackiness for the time being. I know there won't 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 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 snippet - it doesn't really solve anything (especially not for us). it does not really solve anything? That's probably why I had to implement for a little project I am working on right now ... Anyway, I posted why it make sense to implement out of the box: http://webreflection.blogspot.com/2009/11/195-chars-to-help-lazy-load... Regards -- 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 email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http
Re: [jquery-dev] Re: typo in ready event since null !== undefined
Andrea -
Your solution doesn't work for dynamically loaded scripts. If you load
jQuery after both the DOMContentLoaded and window.onload events have fired
your script will be stuck in a permanent loading state.
I'm still looking for a solution that'll work with dynamic loading (which is
what makes document.readyState so enticing).
--John
On Wed, Nov 18, 2009 at 12:21 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Dude, you wrote basically everything I have said in my post (my precedent
reply)
Put this in the top of your scripts and imho problem solved:
(function(s,o,l,v,e,d){if(s[o]==nulls[l+e]){s[v+e](d,function
e(){s[l+e](d,e,!1);s[o]=complete},!1);s[o]=loading}})(document,readyState,add,remove,EventListener,DOMContentLoaded);
I am using this trick and some revisited DOMContentLoaded emulation for a
tiny event based library I cannot show right now since it is incomplete but
above trick has been tested in every Firefox I could find here.
Regards
On Wed, Nov 18, 2009 at 3:44 PM, Shade get...@gmail.com wrote:
I just want to say that I still think that the document.readyState
problem is an issue that needs further addressing than what jquery is
planning to ship right now. This bug brought this topic up a few
months back:
http://dev.jquery.com/ticket/4889
At the time, as John said, we thought it would be ok the solution
that is now in, because FF3.5 was going to finally include
document.readyState, and so the number of browsers affected by the
problem by the time jquery released again would be minimal... FF3 and
below has to be a dwindling number now.
But, now that we know that FF 3.5 still has this problem, and it only
*may* end up FF3.6, and that jquery is releasing soon, I think there
will be a lot of people still affected by this problem. FF3.5 will be
around for a non-trivial amount of time, even if FF3.6 released today
(which we know it will still be a little while).
Here's the primary reason I consider this an issue worth more effort:
I have been pushing this tool I built called LABjs (http://labjs.com)
which is a parallel script loader. It's getting a lot of good support
and reviews so far, but it suffers one major problem (and almost all
loaders have this same issue): it can't be used safely to load scripts
like jquery, because if it happens to load the script after the page's
domready, then all $(document).ready(...) related code will sit idle
and never be fired! This is a major achilles' heel for any script
loader.
Whether you like LABjs or not, or plan to use it or something like it
or not, there are starting to be more and more places where people are
trying to accelerate the loading of their pages through various
techniques like dynamic script loading (XHR, etc), meaning it's going
to more and more likely that jquery gets added to a page in some other
way than through a normal blocking script tag. This means that this
problem with it detecting domready will get more and more obvious
until we find a way to solve it.
Every time I have given a talk about LABjs over the last couple of
months, I've mentioned this caveat but said But, at least with the
next jQuery this will be fixed.
But, now hearing that even with FF3.5 it won't be fixed yet, I think
we need something better, even if we just do some sort of temporary
hacks for a release or two until we have stable browser base where
this works.
I know that jQuery doesn't officially guarantee this usage but
that I think is a troublesome blindsight to just ignore. It's a
perfectly valid use-case for jquery (think about bookmarklets, etc),
it's not at all documented very well that this problem exists, and the
web is moving to more and more of various different tricks to load
things in different ways, which *will* expose the problem even more.
I think we should run some tests to prove whether or not Andrea's code
solution addresses this problem for FF or not. Or we could revisit the
code from the bug I linked, which was actually from SWFObject, 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 and a little more accepting of hackiness for
the time being. I know there won't 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 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 snippet - it doesn't
really
solve anything (especially not for us).
it does not really solve anything? That's probably why I had to
implement
for a little project I am working on right now
Re: [jquery-dev] Re: typo in ready event since null !== undefined
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, everything will depend on it. Accordingly, this trick inside jQuery will make everything else lazy loadable except jQuery itself ... now please find a real case scenario where jQuery is lazy loaded ... if any, that has never trusted the ready event since it cannot work in any case with the current DOMContentLoaded based implementation The last use case you mention doesn't make any sense. If jQuery is already on the page before DOM ready then the ready event has already fired and dynamically-loaded plugins (that use the ready event) will still work just fine. The use case that needs to be supported is the dynamic loading of jQuery + jQuery scripts into any given webpage at any time - regardless of if they already use jQuery. Unfortunately still looking for a Firefox solution there. As mentioned before this is something that we've never supported (because it hasn't worked) but we want to support going forward. --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: typo in ready event since null !== undefined
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 Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Re: typo in ready event since null !== undefined
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 group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Re: bug #3120
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 another - unless someone is able to do so before I get back to it. --John On Wed, Nov 18, 2009 at 6:31 PM, Bill bllfr...@gmail.com wrote: The ticket is titled Slide Effects With IE6/IE7 Lists, and the description is as follows: slideUp, slideDown functions don't reveal/hide properly on lists in IE6/IE7, while they work fine in other browsers (e.g. Firefox). Applicable to list items (li) within unordered (ul) or ordered (ol) lists. On an unstyled list in Internet Exploder, a call to slideUp results in a slideDown occurring instead. Likewise, a call to slideDown results in a slideUp. On a styled list, half of the slide goes one way, and the other half the other way. Test case with styled list: http://www.ryancramer.com/misc/jquery_slide/ Test case with unstyled list: http://www.ryancramer.com/misc/jquery_slide/no_styles.html Note that show() and hide() effects also behave differently in IE with list items than in other browsers, but the slide effects are the simplest way to demonstrate. On Nov 18, 3:28 pm, Bill bllfr...@gmail.com wrote: Hi all, Has anyone ever had to work around the jQuery bug described in ticket #3120? If so, any advice on where to get started? Any word on when this will be fixed? Regards, --Bill -- 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 email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Re: $.ajax feature matrix
of jQuery.support.crossDomainRequest (values false, standard or XDomainRequest -- detection code can be found here: http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/ --). Using filters and the new s.crossDomain computed option, it should be very easy to handle all situations (by throwing an exception or whatnot so that client code could fallback on a proxy or something). Feedbacks welcome is you see anything gross in there. -- Julian 2009/11/15 Julian Aubourg aubourg.jul...@gmail.com I looked into your code and we basically have the same approach. I'll try get the refactoring done by the middle of next week (like I said, I have social life getting in the way right now ;) ). 2009/11/15 Shade get...@gmail.com I've built two different JavaScript projects which implement a nearly identical interface to the native XHR object, including updating properties, etc, while hiding under the covers how the actual XHR happens. One is flXHR (http://flxhr.flensed.com) which actually has a jQuery plugin that adapts flXHR to be automatically selected and used by jQuery when making $.ajax calls. It relies on the XHR registry plugin of jQuery. Because flXHR exposes the identical interface to native XHR, this makes it able to be used throughout $.ajax without any changes to jquery itself. The other project isn't specifically jQuery related, but it's called 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 properties. I'd be willing to collaborate on this solution and share the tricks I used in my two projects. Let me know if this would of assistance. I definitely support trying to revamp the way the $.ajax system works to give it more extensibility. --Kyle On Nov 13, 4:38 pm, 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 readyState, responseXML, etc.). I'm not sure how you'd build this mock XHR and keep those properties up to date. On Thu, Nov 12, 2009 at 10:14 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: As an example of what I'm talking about with an real xhr as a base: - layer 0 is window.ActiveXObject ? new ActiveXObject(Microsoft.XMLHTTP) : new XMLHttpRequest() - layer 1 is a standard compliant xhr implementation that delegates to layer 0 while hiding browser incompatibilities. It listens to layer 0 through its onreadystatechange event handler and propagates the event by calling its own onreadystatechange if available I had briefly mentioned a similar idea in the other thread [1], but was rather scared of the actual implementation. I guess the question is whether there are possible state changes to the underlying XHR object that might affect the properties but that are not exposed through the onreadystatechange handler. I don't have nearly the knowledge of XHR to answer this. If there aren't any, I think this is quite a good idea. -- Scott [1]http://tinyurl.com/yl2lqjz#msg_1fa4cac00dbcedcf Well, then. I had started working on something similar, but much simpler. I had planned to intercept the return value of $.ajax and extend it with 'success' and 'error' functions. Of course, I hadn't gotten to the point of actually testing this, so who knows if it would have worked. Your solution sounds much more robust and forward thinking. Very nice. _jason- Hide quoted text - - Show quoted text - -- 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 email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Re: $.ajax feature matrix
Github works for me - and editing ajax.js (and test/unit/ajax.js) would be
ideal - that way we could just merge it directly in.
If there's any way to make your changes piece-by-piece that'd be excellent
as it would make the full scope of the changes easier to understand.
Also, don't feel entirely bad if this gets bumped until after 1.4 - it
sounds like a lot of code might be changing and I'd rather do it right,
once, then badly twice.
--John
On Wed, Nov 18, 2009 at 10:52 PM, Julian Aubourg
aubourg.jul...@gmail.comwrote:
Not yet, I'll wait to have at least one transport made (I'm working on the
xhr one atm) and all the layers tested... wouldn't like to put some code
with obvious mistakes that some rough testing will get rid of. I thought
about unit testing early, but truth is the amount of refactoring at each
iteration makes it impossible to 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 jere...@gmail.com
All of this sounds pretty good - do you have a link to the code?
(Preferably in a fork up on Github - makes it easy to do a code review.)
--John
On Wed, Nov 18, 2009 at 10:10 PM, Julian Aubourg
aubourg.jul...@gmail.com wrote:
OK, just a post to keep you all updated since I didn't get as much time
as I expected though I have progress, mind you.
Also, I recommend a good understanding of the internals of $.ajax to
follow everything.
First, let me start with some design decisions I came up with:
1) the fake XHR returned by $.ajax only emulates header related methods
abort
The rational behind the decision is as follows:
- the onreadystatechange callback was already used by jQuery internally
on the old implementation, meaning that using it was pointless if not plain
wrong.
- same goes for open send, it doesn't make sense for external code to
use them
On a sidenote, readyState could be emulated but I fail to see the point.
I *could* emulate onreadystatechange but is there really a use case for
this?
Of course, the complete(), success() error() methods are implemented.
If you do something like jQuery.ajax(options).complete(completeCallback); in
async=false mode, the completeCallback method WILL be called with correct
arguments even though the request already completed.
Each callback family handled return false; in callbacks, meaning no
further callbacks of that family will be called later on.
For backward compatibility, the complete, success error callbacks
provided in the options object are also called (they are actually added to
the list of callbacks before issuing the request).
2) I added the notion of transport which is the actual implementation
that will send the request
ajaxSettings has two new properties:
- transportSelector, a function that will take an options object and
determine what transport type is more suited for the request,
- transportDefinitions which is a hashmap of transport definitions
(obviously).
Transport definitions contains two functions:
- filter which takes the options object returns a new transport type if
it deems it more suited than itself
- factory which takes no argument returns a new transport of the
desired type
The idea in having the filter function is:
- to set s.global as false if the transport cannot ensure completion
(cross-domain script / jsonp),
- to keep differentiating code as close to the implementation as
possible. A good example are scripts which wont be handled the same if they
are cross domain or not (first will use xhr, second will use a script tag).
If s.transportDefinitions[transportType] is not an object but a function, it
is considered a filter. Following previous example, transportSelector would
just return script no matter what, and the script transport definition
would look like this:
s.transportDefinitions[script] = function (s) { return isCrossDomain(s)
? script-tag : xhr }
Filters get called until a final transportType is found, then the
corresponding transport factory gets called.
By changing transportSelector transportDefinitions, a user can
completely
I also added some options into the ajax options object beside
transportSelector transportDefinition:
- transport: which can be used to bypass transportSelector (filters
called until final type is found are not bypassed)
- transportDataType: it's the data type used to determine which transport
to use (in transportSelector), if not provided it's equivalent to dataType.
The idea came when I was refactoring and realized that it was no reason why
you couldn't ask for xml through jsonp. So you would have something like
$.ajax({ dataType: xml, transportDataType: jsonp, ...}) and the request
will be made through jsonp and the resulting json object will be parsed as
xml (I already implemented the logic
Re: [jquery-dev] typo in ready event since null !== undefined
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 17, 2009 at 6:33 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: AFAIK top window frameElement returns null and not undefined, as is for document.body when not present yet. Moreover we can use the JavaScript weird case where null == undefined but while null is static, undefined can be redefined or in any case it needs to be discovered in the scope chain. On line 857 of this event.js http://github.com/jquery/jquery/blob/master/src/event.js I can spot this: toplevel = window.frameElement === undefined; In few words and at least in my IE8 that doScroll try/catch is never performed at all since the condition if( document.documentElement.doScroll toplevel) cannot be true. Is that file part of the release? I did not check but you can quickly fix via toplevel = window.frameElement == null; Regards -- 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 email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] typo in ready event since null !== undefined
That line is intentional. It's for cases where jQuery is being dynamically
loaded and you wish to execute the ready event immediately. **We make no
guarantees about this happening in all the browsers that we support.**
(Namely this is because of the problem that you mentioned in Firefox 3.6.)
As of right now this is a forward-looking addition to the time in which
it'll work in all browsers - but it doesn't negatively affect the code
otherwise.
--John
On Tue, Nov 17, 2009 at 11:12 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
John I am not that familiar with github yet, I did a mess wven with last
PureDom for taskspeed so please forgive me ... but there is another problem
there, if I am not wrong.
Line 826 of the same file:
// Catch cases where $(document).ready() is called after the
// browser event has already occurred.
if ( document.readyState === complete ) {
return jQuery.ready();
We got a problem here, Firefox 3.6 (beta included) does not have the
readyState proeprty.
Everybody else seems to have it. There is a massive bug in MDC for this
missed property which apparently now is into HTML5
For an event handler I am creating for other reasons I have solved in this
way:
if(document.readyState == null
document.addEventListener)(function(){
document.addEventListener(DOMContentLoaded, function
DOMContentLoaded(){
document.removeEventListener(DOMContentLoaded,
DOMContentLoaded, false);
document.readyState = complete;
}, false);
document.readyState = loading;
})();
With above code we are sure that if jQuery or a plugin is evaluated after
the onload event (lazy load) Firefox will directly fire 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...@gmail.com wrote:
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 17, 2009 at 6:33 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
AFAIK top window frameElement returns null and not undefined, as is for
document.body when not present yet.
Moreover we can use the JavaScript weird case where null == undefined but
while null is static, undefined can be redefined or in any case it needs to
be discovered in the scope chain.
On line 857 of this event.js
http://github.com/jquery/jquery/blob/master/src/event.js
I can spot this:
toplevel = window.frameElement === undefined;
In few words and at least in my IE8 that doScroll try/catch is never
performed at all since the condition
if( document.documentElement.doScroll toplevel)
cannot be true.
Is that file part of the release? I did not check but you can quickly fix
via
toplevel = window.frameElement == null;
Regards
--
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 email to
jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Expected behavior of $(document.createTextNode(test)).text()
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 -- 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 email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] typo in ready event since null !== undefined
Oh, just to mention, regarding your solution snippet - it doesn't really
solve anything (especially not for us). The case that we're looking to
handle with the readyState code was when jQuery is loaded after the document
ready event has already occurred. Your snippet will be stuck in a permanent
loading state and never move to complete in this case.
As to using readyState - we added it in when we did because we were informed
that Firefox 3.5 was going to ship with it, unfortunately that wasn't the
case. Regardless, we need to pressure browsers to keep moving and this is
one way to do so. Until we drop support for Firefox 3.5 we will continue to
make no guarantees about loading jQuery dynamically.
Of course, an alternative working solution for Firefox 3.6 would be great.
--John
On Tue, Nov 17, 2009 at 11:12 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
John I am not that familiar with github yet, I did a mess wven with last
PureDom for taskspeed so please forgive me ... but there is another problem
there, if I am not wrong.
Line 826 of the same file:
// Catch cases where $(document).ready() is called after the
// browser event has already occurred.
if ( document.readyState === complete ) {
return jQuery.ready();
We got a problem here, Firefox 3.6 (beta included) does not have the
readyState proeprty.
Everybody else seems to have it. There is a massive bug in MDC for this
missed property which apparently now is into HTML5
For an event handler I am creating for other reasons I have solved in this
way:
if(document.readyState == null
document.addEventListener)(function(){
document.addEventListener(DOMContentLoaded, function
DOMContentLoaded(){
document.removeEventListener(DOMContentLoaded,
DOMContentLoaded, false);
document.readyState = complete;
}, false);
document.readyState = loading;
})();
With above code we are sure that if jQuery or a plugin is evaluated after
the onload event (lazy load) Firefox will directly fire 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...@gmail.com wrote:
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 17, 2009 at 6:33 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
AFAIK top window frameElement returns null and not undefined, as is for
document.body when not present yet.
Moreover we can use the JavaScript weird case where null == undefined but
while null is static, undefined can be redefined or in any case it needs to
be discovered in the scope chain.
On line 857 of this event.js
http://github.com/jquery/jquery/blob/master/src/event.js
I can spot this:
toplevel = window.frameElement === undefined;
In few words and at least in my IE8 that doScroll try/catch is never
performed at all since the condition
if( document.documentElement.doScroll toplevel)
cannot be true.
Is that file part of the release? I did not check but you can quickly fix
via
toplevel = window.frameElement == null;
Regards
--
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 email to
jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr
Re: [jquery-dev] jQuery and SVG
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 Speaker mrspea...@gmail.com wrote: I was investigating this bug: http://dev.jquery.com/ticket/1745 and noticed that there is also a separate patch: http://dev.jquery.com/ticket/4850 I think the patch would deal with the bug, so the perhaps the tickets should be merged... buuut, what's the general feeling on supporting SVG documents with jQuery? Is SVG out of scope? -- 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 email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Performance issues using $.ajax async
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 am using JQuery on a embedded system which use webkit as browser, i detect that jquery for asynchronously ajax calls use polling: 3620: var ival = setInterval(onreadystatechange, 13); instead of: xhr.onreadystatechange = onreadystatechange; for my scenary this has performance issues, i like to know why jquery use the first option when the second could be used. Thanks and sorry for my english. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] new version policies - specifically RE: sibling selector in 1.3.2
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 the optimal release cycle is around 2-3 months for point release, 1 year for major release. Of course we missed the 1.3.3 release, but that's mostly because the team decided to push through and go straight for 1.4, instead. --John On Fri, Nov 13, 2009 at 2:41 PM, Jason Persampieri papp...@gmail.com wrote: Pardon me for being a little late to this particular party :) I just ran in to the Broken sibling selector in 1.3.2 bug that was discovered and fixed at the end of March (7 months ago!). I've worked around it by removing the blocks of code specified in the bug report and re-minifying it. But I wonder why I had to do that. Why not release a version 1.3.3 (or 1.3.2.1) that fixes this? It's seems to be a very simple fix for a relatively major feature and could potentially save a lot of debugging time. Should *every* bug get a point release? Of course not. But 1.3.2 has been the 'latest stable release' for quite a while, no? Honestly, it may be close enough to 1.3.3 (or whatever the next big version is) for this particular issue to matter, but for future development, this would make jQuery seem even more production-ready than it already is. Just for context, I actually had to upgrade from 1.3.1 in order to fix the clone of a clone issue in IE. _jason -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Ant build
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 lives as a copy in the jQuery repository. QUnit should be pulled in as a sort of git external, though its required only for testing, not for making a build of jQuery itself. Jörn On Tue, Nov 10, 2009 at 4:37 AM, Justin Meyer justinbme...@gmail.com wrote: Does building with Ant work from github anymore? I'm guessing no b/c it needs to get QUnit/Sizzle. Would it be nice if you could pull in dependencies in JS like ruby's gem install, and all your building would already be done via JavaScript. Hm ... JMVC has this feature :). -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] $.ajax feature matrix
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 implement timeout support then we could have the error/ajaxError occur if the timeout happens - but we can't do it for malformed JSON/script/jsonp, since the browser doesn't provide us with that information. At best the script would come in, throw an exception, and then the timeout would happen a couple seconds later. If we were to make this change the timeout would have to happen automatically as well (which is different from the other request types). Cannot work with script/json/jsonp and should be documented as such: - async - contentType - ifModified - username / password - type (POST) - xhr - error/ajaxError for malformed data --John On Wed, Nov 11, 2009 at 7:55 PM, Dave Methvin dave.meth...@gmail.com wrote: Re: http://groups.google.com/group/jquery-dev/msg/70b913e489c9fc8f Here is what I came up with. I built this mostly by looking at the source to ajax.js so let me know if there is anything that looks wrong: http://spreadsheets.google.com/ccc?key=0Aj5JJFjq9rZDdC1OQjJOcmtjTmtBUVdXV2NPczE2R2chl=en Does anyone see any errors, or have suggestions on different presentation? -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] $.ajax feature matrix
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 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 implement timeout support then we could have the error/ajaxError occur if the timeout happens - but we can't do it for malformed JSON/script/jsonp, since the browser doesn't provide us with that information. At best the script would come in, throw an exception, and then the timeout would happen a couple seconds later. If we were to make this change the timeout would have to happen automatically as well (which is different from the other request types). Cannot work with script/json/jsonp and should be documented as such: - async - contentType - ifModified - username / password - type (POST) - xhr - error/ajaxError for malformed data --John On Wed, Nov 11, 2009 at 7:55 PM, Dave Methvin dave.meth...@gmail.com wrote: Re: http://groups.google.com/group/jquery-dev/msg/70b913e489c9fc8f Here is what I came up with. I built this mostly by looking at the source to ajax.js so let me know if there is anything that looks wrong: http://spreadsheets.google.com/ccc?key=0Aj5JJFjq9rZDdC1OQjJOcmtjTmtBUVdXV2NPczE2R2chl=en Does anyone see any errors, or have suggestions on different presentation? -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] $.ajax feature matrix
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 XHRFactory.get(options) which would return an abstraction with the same interface as an xhr. This would hide routing into the factory code and all the hacks into the different abstractions (including handling the replacement of ? with the callback name, creating a script tag -- or an iframe in my own implementation of jsonp--, etc, etc) and keep the ajax function clean (calling everything as if it were pure xhr no matter the situation). Each implementation that do not implement some features (like header manipulation for script hacks) would simply do nothing when those methods are called. Plus, the interface could be enhanced to handle the .bind(type,func) we talked about in the other thread (and deferred error/success/etc callback bindings). Furthermore, each implementation would be replaceable by user code (we could keep the xhr setting active, it would only act on pure xhr calls). I'd be willing to give it a try (knowing you would more than surely have to clean it up to jQuery's standards after), just let me know if I'm crazy or something. That's an interesting proposition - I'd be interested in seeing where you go with that. I think the one area that would be troublesome is in the properties that xhr provides (like readyState, responseXML, etc.). I'm not sure how you'd build this mock XHR and keep those properties up to date. --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Build Process
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 file list in the Makefile and get a fully minified result. --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] link focus lost after jquery-1.2.1 (serious accessibility problem)
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, 2009 at 6:02 PM, tam soder2...@googlemail.com wrote: Hello, With Firefox and jQuery-1.3.2 so widely spread nowadays, I would like to report a rather serious accessibility problem for all people that are dependent on keyboard navigation. With all versions after jquery-1.2.1 (js being enabled), link focus is lost in Firefox when you follow a link to another page and hit the backspace key. You can try it for yourself, e.g. on http://jquery.com/ with the Plugins link in the top menu -- once with js enabled (link focus is lost when you come back after having followed the link, and once with js disabled (link focus is still there after hitting the backspace key.) There was no problem in that respect before version 1.2.2 and it doesn't happen with jQuery (any version) disabled. Although this isn't happening in IE8 (native, on Vista32 Home Premium SP2), IE7 (IE-Tester), and Opera 9.5.1, it doesn't seem to be solely Firefox (i.e., browser) related, since it's working perfectly even in the latest Firefox version (3.5.5) with the older jQuery-1.2.2 version. Being no javascript specialist myself, I really hope someone among you developers will have a look into this. Thank you so much for your valuable time and contributions! -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Re: jQuery.extend(true, ...)
Ah yes, I see your point now. It looks like 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ć robert.ka...@gmail.com wrote:
Ah, yes, since options.nodes was already defined before extending, it
will not become jQuery(#content) (with all jQuery methods copied
inside itself), but something between jQuery(div) and jQuery
(#content) (with all jQuery methods copied inside itself). Even
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ć robert.ka...@gmail.com 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 like this:
var options = {
nodes: jQuery(div),
num: 4,
date: new Date
};
jQuery.extend(true, options, {
nodes: jQuery(#content),
num: new Number(5),
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 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 - 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 renamed isObject to isObjectLiteral.)
--John
On Tue, Nov 10, 2009 at 9:10 PM, Robert Katić robert.ka...@gmail.com
wrote:
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 = {};
} else {
clone = copy;
}
// Never move original objects, clone them
target[ name ] = jQuery.extend( deep, clone, copy );
You are going to extend with any object including a Date, a String, a
Number... (ah yes, excluding nodes).
You are going to extend (with) arrays? [1,2] and [4] to obtain [4,2].
Really?
If an object is not an array nor an object literal then extend object
with itself???
The only things to extend recursively are objects literals to me:
if ( deep copy jQuery.isObject(copy) (!src || jQuery.isObject
(src)) ) {
target[ name ] = jQuery.extend( deep, src || {}, copy );
}
Am I loosing my mind? :)
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Questions / best practices regarding toggle patch for ticket #5274
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 this.lastToggle to keep track of the current position: but it gets messed up with multiple handlers. The post here (mostly me waffling) http://groups.google.com/group/jquery-dev/browse_thread/thread/2af6983e9ef3848/badf740f841a6dc4 details the issue. I was going over the possible patch I submitted (http://dev.jquery.com/ ticket/5274) and was wondering if it's acceptable, and if not, what a better approach would be. The patch replaced this: this.lastToggle = ( this.lastToggle || 0 ) % i; ... return args[ this.lastToggle++ ].apply( this, arguments ) || false; With this: var lastToggle = ( $(this).data( 'lastToggle' + fn.guid ) || 0 ) % i; $(this).data( 'lastToggle' + fn.guid, lastToggle + 1 ); ... return args[ lastToggle ].apply( this, arguments ) || false; My questions are: is using 'lastToggle' + fn.guid as a data key acceptable? It kind of looks a bit funky... and would it be preferable to store $(this).data in a variable reference to prevent doing the $ (this) selector twice (at the cost, I think, of readability)? Thanks! Earle -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Re: Calling callback in $.post $.get on error
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 post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] jQuery.extend(true, ...)
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 renamed isObject to isObjectLiteral.)
--John
On Tue, Nov 10, 2009 at 9:10 PM, Robert Katić robert.ka...@gmail.com wrote:
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 = {};
} else {
clone = copy;
}
// Never move original objects, clone them
target[ name ] = jQuery.extend( deep, clone, copy );
You are going to extend with any object including a Date, a String, a
Number... (ah yes, excluding nodes).
You are going to extend (with) arrays? [1,2] and [4] to obtain [4,2].
Really?
If an object is not an array nor an object literal then extend object
with itself???
The only things to extend recursively are objects literals to me:
if ( deep copy jQuery.isObject(copy) (!src || jQuery.isObject
(src)) ) {
target[ name ] = jQuery.extend( deep, src || {}, copy );
}
Am I loosing my mind? :)
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Re: Calling callback in $.post $.get on error
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 don't support beforeSend, type!=GET, ifModified, dataFilter, timeout, username, password, contentType, synchronous requests, the error handler, and the ajaxSend/ajaxError events. They do support the other global ajax events and the complete/success hander, but since they don't have an xhr object that argument is passed in as undefined. Cross-domain json/jsonp are treated as scripts; they do support scriptCharset although the docs currently say it only applies to dataType=script. Since jsonp and cross-domain json requests are transformed into script tags but only under certain circumstances, it means that two requests that vary only by their url parameter can behave very differently. It all makes sense when you know about the constraints of the underlying technologies being used. Many users don't understand that plumbing, though, and it's complex to explain in the docs -- look how long it is already! I thought of one thing that might help: a matrix showing which options apply to which dataType/xdomain combinations -- I can do that. I wonder if it would be helpful to refactor the ajax functionality into two or three consistent methods with fewer exceptions. A matrix sounds awesome, I think it would help to make the functionality more specific. It seems like the issue is mostly documentation/education related, then. Things might have been clearer if we just kept jsonp separate from $.ajax, but I still think we made the right decision (we hide the specifics of the request medium, as best we can, in exchange for a simple interface). So yeah, any help on the docs here would be hugely appreciated. --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] jQuery test page is not working properly
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.3.2-release.zip --John On Tue, Nov 10, 2009 at 1:54 AM, Minwoo Park teb...@gmail.com wrote: Seems like jQuery test page is NOT working properly (http://jquery.com/ test/) - There was about 204 tests, and now only 82 tests are working. - Major browsers (IE, Firefox, Chrome) is failed for lots of tests. when I open http://view.jquery.com/tags/1.3.2/ , It seems like test directory is update Oct 28h. Any one knows about this? -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
Re: [jquery-dev] Calling callback in $.post $.get on error
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 error callback the page will still break (albeit in
a different manner).
Thus if you wanted to make proper use of the $.get or $.post with the
dual-callback functionality you would have to do:
$.get(someurl, function(data){
if ( typeof data === string ) {
// got results
} else {
// got error
}
});
Another option could be a modified error callback and actually have it
work like this:
$.get(someurl, function(data, errorMessage){
if ( data ) {
// got results
} else {
// got error
alert( errorMessage );
}
});
Thoughts on this?
--John
On Sun, Nov 8, 2009 at 12:29 PM, Mr Speaker mrspea...@gmail.com wrote:
The $.post and $.get are really handy, but seem limited in their use
for serious work because you can't tell if they fail (can you? I mean,
besides the global error handler?).
I couldn't find any discussion on this, it would be useful if you
could just call the same callback method for either success or error
and let the user play with the result:
post: function( url, data, callback, type ) {
...
return jQuery.ajax({
type: POST,
url: url,
data: data,
success: callback,
error: callback, -- same function
dataType: type
});
This would be especially useful for $.post where it's usually pretty
important that you know that an update has occurred. In the
documentation the callback code has this comment:
// NOTE: Apparently, only success is returned when you make
// an Ajax call in this way. Other errors silently fail.
So I guess there is a reason for not doing this... it would break
existing code for people who just checked for ANY return value, and I
suppose it complicates the simple $.post function a little - but it
would give these helper functions more real world uses.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Calling callback in $.post $.get on error
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 they're trying to do something directly with the object - a more
likely result is seeing null outputted somewhere).
Why not the following:
$.get(someurl, function(data) {
// got results
}, function(errorMessage) {
// got error
});
That way, actual scripts behave as usual and new ones can provide an error
callback.
Thoughts?
I'm not a huge fan of this - having dual functions being passed in as
arguments is messy and against the current jQuery conventions. I feel
like if you're passing in so many functions why not just use $.ajax
and be done with it? Especially since $.ajax is so much more explicit
any way.
Either we should find a simple solution (like what I proposed) or do
no change at all.
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Calling callback in $.post $.get on error
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 not really possible, not without breaking code, at least. --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Issues with fade animations
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 currentOpacityDiff * timeToRunAnimation (where currentOpacityDiff is a number 0 to 1). 3) Make fadeTo show an element if it's not visible. The only remaining issue is to figure out how the queueing should work. It seems like you would just still need to call .stop() before running any animation. --John On Sun, Nov 8, 2009 at 11:22 AM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Hi, I've built a testpage to document this issues with fadeIn/Out: http://jquery-ui.googlecode.com/svn/branches/labs/fadequeue/index.html As written on that page, the issues are: Without using stop(), animations just queue up, thats inacceptable With just using stop(), styles end up in the middle, screwing up the next fade, that is, stopping a fadeout half way through will cause the next fade in to not fade to 1 Using stop(false, true) will finish the animations, which worksaround the above problems, but the result is ugly, as a stopped fadeout will skip to the end, then fade in again from 0, instead of just fading in from the current opacity The crazy complicated stuff, using a mix of fadeIn/Out and fadeTo, apart from being way too complicated, has the big drawback that the fadeTo-animations take exactly as long as the others, while it usually doesn't fade from 0 to 1, but only from, say, 0.7 to 1. Adding a calculation to figure out how long the animation should be relative to the current opacity would make this just more complicated. fadeIn/Out can use opacity values defined in CSS stylesheets, while fadeTo requires the user to specify the opacity My goal for now is to create a plugin, with your help, that can be used instead of fadeIn/Out. It would not queue up animations, it would read opacity from stylesheets, just like fadeIn/Out do, and it would adjust the animation duration relative to the current opacity if a fade is stopped/reversed, so that if a fade in is stopped half-way through by a fadeout, the fadeout would only take half the specified duration, resulting in the same animation speed all the time. Based on how the plugin ends up, I hope we can port back something to jQuery Core to make that available just as easily as fadeIn/Out. Looking forward to your ideas. Jörn -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
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 there - something that covers all the test cases would be great. --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
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 jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Issues with fade animations
Absolutely - probably one ticket for each and just link back to this thread. --John On Sun, Nov 8, 2009 at 2:34 PM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: That sounds great. I think in case of my Tooltip plugin there is an additional problem, where a mouseover event doesn't 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 Resig jere...@gmail.com wrote: 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 currentOpacityDiff * timeToRunAnimation (where currentOpacityDiff is a number 0 to 1). 3) Make fadeTo show an element if it's not visible. The only remaining issue is to figure out how the queueing should work. It seems like you would just still need to call .stop() before running any animation. --John On Sun, Nov 8, 2009 at 11:22 AM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Hi, I've built a testpage to document this issues with fadeIn/Out: http://jquery-ui.googlecode.com/svn/branches/labs/fadequeue/index.html As written on that page, the issues are: Without using stop(), animations just queue up, thats inacceptable With just using stop(), styles end up in the middle, screwing up the next fade, that is, stopping a fadeout half way through will cause the next fade in to not fade to 1 Using stop(false, true) will finish the animations, which worksaround the above problems, but the result is ugly, as a stopped fadeout will skip to the end, then fade in again from 0, instead of just fading in from the current opacity The crazy complicated stuff, using a mix of fadeIn/Out and fadeTo, apart from being way too complicated, has the big drawback that the fadeTo-animations take exactly as long as the others, while it usually doesn't fade from 0 to 1, but only from, say, 0.7 to 1. Adding a calculation to figure out how long the animation should be relative to the current opacity would make this just more complicated. fadeIn/Out can use opacity values defined in CSS stylesheets, while fadeTo requires the user to specify the opacity My goal for now is to create a plugin, with your help, that can be used instead of fadeIn/Out. It would not queue up animations, it would read opacity from stylesheets, just like fadeIn/Out do, and it would adjust the animation duration relative to the current opacity if a fade is stopped/reversed, so that if a fade in is stopped half-way through by a fadeout, the fadeout would only take half the specified duration, resulting in the same animation speed all the time. Based on how the plugin ends up, I hope we can port back something to jQuery Core to make that available just as easily as fadeIn/Out. Looking forward to your ideas. Jörn -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
Nice! Just make a bug and link to your commit on your Github fork and
I'll land it (also, be sure to get the spacing right - and be sure to
use {} braces and ===).
--John
On Sun, Nov 8, 2009 at 5:19 PM, Robert Katić robert.ka...@gmail.com wrote:
Yes, it passes all these tests.
On Nov 8, 4: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 Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Calling callback in $.post $.get on error
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, but seem limited in their use
for serious work because you can't tell if they fail (can you? I mean,
besides the global error handler?).
I couldn't find any discussion on this, it would be useful if you
could just call the same callback method for either success or error
and let the user play with the result:
post: function( url, data, callback, type ) {
...
return jQuery.ajax({
type: POST,
url: url,
data: data,
success: callback,
error: callback, -- same function
dataType: type
});
This would be especially useful for $.post where it's usually pretty
important that you know that an update has occurred. In the
documentation the callback code has this comment:
// NOTE: Apparently, only success is returned when you make
// an Ajax call in this way. Other errors silently fail.
So I guess there is a reason for not doing this... it would break
existing code for people who just checked for ANY return value, and I
suppose it complicates the simple $.post function a little - but it
would give these helper functions more real world uses.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Ticket #4917
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.
--John
On Sunday, November 8, 2009, Jeffrey Kretz jeffkr...@hotmail.com wrote:
I'm very concerned about a critical issue with the Sizzle
selector of child elements.
I opened a ticket about 4 months ago:
http://dev.jquery.com/ticket/4917
Which had a potential fix for one of the two problems.
I was unable to come up with a good solution for the second problem.
Just now, I downloaded the latest nightly and tried it
again, and the problem still exists:
http://test1.scorpiondesign.com/SelectorDemo.htm
Note that in IE6/7/8 the number of child elements found are
incorrect. All other browsers are correct.
http://test1.scorpiondesign.com/SelectorDemo2.htm
This has a minor patch which improves the situation in
IE6/7/8 but doesn't totally fix it.
http://test1.scorpiondesign.com/SelectorDemo3.htm
This is the latest jQuery nightly, same problem as the first
page.
I'm sure things have been crazy busy, but I'm really hoping
that someone could look into this (at least to evaluate my suggested fix for
one of the two problems).
Thanks,
Jeffrey Kretz
--
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 javascript:_e({}, 'cvml',
'jquery-dev@googlegroups.com');.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: ajaxComplete doesn't fire on 404 (should it?)
Ah, great - thanks for the clarification and patch!
--John
On Sat, Nov 7, 2009 at 7:26 AM, Mr Speaker mrspea...@gmail.com wrote:
After some more testing I realised it was not so serious - it only
occurred when 404ing from the local filesystem. This doesn't actually
generate a 404, but an NS_ERROR_DOM_BAD_URI error which gets caught in
the try/catch. Still - anything that falls through to the catch block
will not call complete() so ajaxStop and ajaxComplete don't get fired,
and the jQuery.active count doesn't get decremented.
I've filled a ticket and diff (http://dev.jquery.com/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 for this, but couldn't find any mention of it...
which seems a bit spooky, but I'll post it anyway. In this code:
$(#complete).ajaxComplete( function(){ $(this).text(complete); });
$(#start)
.ajaxStart(function(){$(this).text(start)})
.ajaxStop(function(){$(this).text(Stop)});
$.ajax({ type:get, url:iDontExist.php });
If the request 404's, then neither the ajaxComplete or ajaxStop events
fire. In the jQuery ajax code (line 455 in 1.4pre) it says:
// Send the data
try {
xhr.send( type === POST || type === PUT ? s.data : null );
} catch(e) {
jQuery.handleError(s, xhr, null, e);
}
But nothing is done to call the complete() method. If I whack a call
to complete() in the catch block then everyone looks happy (perhaps...
I don't know if you can get the status of the request as 404?).
Anyhoo... my question is - is this expected behaviour? That is, does
ajaxComplete not fire because technically the request didn't
complete or something?
Thanks!
Earle.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Binding .live() to document.body
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 from: jQuery( this.context ) to: jQuery( this.context.body || this.context ) (Thus it would only use the body element on HTML documents, as well.) --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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
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ć robert.ka...@gmail.com wrote:
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 jere...@gmail.com wrote:
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 something similar would be
enough. Also it would speed up sorting inside liveHandler with
somethin like this:
...
elems.push({ elem: elem, fn: fn, closer: jQuery.lastCloser });
elems.sort(function( a, b ) {
return a.closer - b.closer;
});
I'd appreciate tickets/patches for both of these - they both sound
like great additions.
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Fix-less events
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 Meyer justinbme...@gmail.com wrote: The fix function is rather expensive for things like mousemove and mouseover. Can we make it possible that events won't be fixed for certain events? If you like this idea, I'll submit a patch. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
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 where, presumably, you have hundreds or thousands of
elements that you're trying to match - and you don't want to run the
initial selector). Although there's a lot that I don't like about it:
- You are now passing in a selector to a non $(...) or .foo() method.
This goes against all the conventions that the library has - when you
interact with DOM elements, stay within the jQuery set.
- The only case where this matters is in a fringe case (namely, only
when you use both a complicated selector AND run it in IE 8, since
all other browsers are using querySelectorAll) - but the existence of
the method in jQuery would remove the need to ever use the one method
that everyone should use.
- Presumably since you're in a situation where you're really caring
about performance - then why are you using .live to begin with?
Shouldn't you be binding lower in the document? This is why the
closest method was added, to make tasks like this even easier.
I would simply recommend: If you're in a situation where you're
starting with a critical number of elements on your page, enough to
ruin your pages' overall performance, then you should use a basic form
of event delegation, like so:
$(#someRootTable).click(function(e){
$(e.target).closest(td.foo).each(function(){
// Your code goes here.
});
});
Which is really what you should be doing anyway (live method or not).
--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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
If you want to limit, just do this (using the nightlies):
$(#someRootTable).click(function(e){
$(e.target).closest(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 Fri, Nov 6, 2009 at 5:22 AM, Robert Katić robert.ka...@gmail.com wrote:
$(#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 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
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] $(0) inconsistent with $(1), $(2)
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 - why were you passing in a number to the jQuery object? I could sort of, kind of, understand passing in an array of values - but just one number doesn't make sense. --John On Sat, Oct 31, 2009 at 9:16 PM, Xavier Shay xavier.s...@gmail.com wrote: $(0).get(0) Document $(1).get(0) 1 $(2).get(0) 2 Why does $(0) return a document? Is this intended behaviour? I would expect it to return 0. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: $(nodeList) and comment nodes
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 nodes only on IE. This makes it even more ambiguous, with unexpected results. Also it seams that the only expected NodeList is from an getElementsByTagName.call. I know that it is not explicitly supported by the API, but even then it seams that there are some inconsistent logic. On Oct 30, 6:28 am, Robert Katić robert.ka...@gmail.com wrote: 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? -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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 email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: $.fn.add(selector) and context
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( jQuery.unique( jQuery.merge(
this.get(),
typeof selector === string ?
jQuery( selector, context
|| this.context (this.context.ownerDocument ||
this.context)
|| this[0] (this[0].ownerDocument || this[0]) ) :
jQuery.makeArray( selector )
)));
};
On Oct 30, 6:55 am, Robert Katić robert.ka...@gmail.com wrote:
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 lusers of the xmlDoc document!
Here an optional context argument would be useful:
$(user, xmlDoc).add(lusers, xmlDoc);
But even this is not ideal for me. If the context argument is not
given (first example), which document would be used?
I suppose the obvious answer is xmlDoc.
An corrected implementation of add() would be something like this:
jQuery.fn.add = function( selector ) {
return this.pushStack( jQuery.unique( jQuery.merge(
this.get(),
typeof selector === string ?
jQuery( selector, (this.context || this[0] ||
0).ownerDocument ) :
jQuery.makeArray( selector )
)));
};
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: $(nodeList) and comment nodes
Eww... It must've been accidentally cut in the last release - but we
didn't notice because the worst case is only a minor perf hit. Well,
it makes it pretty easy to actually just remove it then! (Especially
if the only place where it's being used internally is in this
soon-to-be-stripped method.)
I'll be sure to revise the docs when I make the cut as well.
--John
On Fri, Oct 30, 2009 at 11:52 AM, Karl Swedberg k...@englishrules.com wrote:
I came across an oddity with jQuery.merge from a completely different route
-- looking through jQuery.support properties. It looks like jQuery.merge is
testing for jQuery.support.getAll, but I can't for the life of me find
anywhere in the source where jQuery.support.getAll is being defined.
Since jQuery.support.getAll is never true (because it's not defined),
comments are always excluded ( if ( elem.nodeType !== 8 ) ).
Did jQuery at one point define jQuery.support.getAll? And if so, what was it
based on?
from core.js line 442 (in github version just pulled this morning):
merge: function( first, second ) {
// We have to loop this way because IE Opera overwrite the length
// expando of getElementsByTagName
var i = 0, elem, pos = first.length;
// Also, we need to make sure that the correct elements are being returned
// (IE returns comment nodes in a '*' query)
if ( !jQuery.support.getAll ) {
while ( (elem = second[ i++ ]) != null ) {
if ( elem.nodeType !== 8 ) {
first[ pos++ ] = elem;
}
}
} else {
while ( (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 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 nodes only on IE.
This makes it even more ambiguous, with unexpected results.
Also it seams that the only expected NodeList is from an
getElementsByTagName.call.
I know that it is not explicitly supported by the API, but even then
it seams that there are some inconsistent logic.
On Oct 30, 6:28 am, Robert Katić robert.ka...@gmail.com wrote:
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?
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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 email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: $.data(elem) API changed in 1.4pre ?
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 have in jQuery core for performance advantages, in a number of places). I've done a quick search on Google Code Search and have only found a couple places where jQuery.data(elem) is used (outside of jQuery itself). Right now I'm leaning towards keeping the API change (especially since the alternative would be pretty lame - like doing jQuery.data(elem, true) or some such) but if the change is too bad then we can always reconsider. I should note that in jQuery 1.4 you can do $(elem).data() to get at the element's data, no problem (there was no API conflict for that method). --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-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.data(elem) API changed in 1.4pre ?
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). Almost universally the use of $.data(elem) was used to get at the entirety of an element's data collection - which is what is now returned from $.data(elem) instead. Looking at the tabs code it looks like they're using it to generate a unique ID (but it's not clear as to why they need $.data for this - they could, just as easily, keep a global ID counter and assign it to the element if it doesn't have one, already. There's no need to attach an entire data object just to get at that information. As it stands the next version of jQuery UI will require jQuery 1.4 so this is definitely one place where we could make that clean break. If it does become problematic, though (especially for other plugins), then we could look into ways of changing it. --John On Wed, Oct 14, 2009 at 10:24 AM, Mark Gibson jollyt...@gmail.com wrote: Hi, I've noticed that the behaviour of $.data() has changed in 1.4pre, $.data(elem) no longer returns the cache id, it returns all the data items or null. this will probably break a lot of code (already breaks jQuery UI Tabs) Is this intentional, or a bug? - Mark. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Moving away from google groups to forums?
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 flow of QA. --John On Fri, Oct 9, 2009 at 1:46 PM, seasoup seas...@gmail.com wrote: I just read in the State of jQuery'09 powerpoint presentation from the jQuery conference that the intention is to move off of google groups and to forums. I'm wondering what the thinking is here, as I much prefer Google Groups to any forums I've seen before. They offer a much more immediate response then most forums do, and it keeps things together with other google groups I'm also a member of. One less thing to bookmark and remember how to get to. How about at least keeping the Google Group and adding forums? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
