jQuery Forum

I've been trying to get a jQuery build environment set up on Windows
7. I'm using TortoiseGit and Ant, everything seems to be working fine
except when I try to push changes back to my Github fork. I get the
message "PuTTY Fatal Error: No supported authentication methods
available." I've set up the certs properly as far as I can tell, I've
tried cleaning them out and setting them up twice. Has anyone been
through this? If so, are you using different tools? Google searches on
this on the error haven't been helpful.
--

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=0Aj5JJFjq9rZDdC1OQjJOcmtjTmtBUVdXV2NPczE2R2c&hl=en
Does anyone see any errors, or have suggestions on different
presentation?
--

In preparation for the push to a new release of jQuery, I've been
cleaning up bug reports in the jQuery core bug tracker. Many tickets
languiished because they weren't actually jQuery core bugs, but
instead should have been reported on the forums or sent to the author
of the plugin. jQuery UI also has its own bug tracker, http://dev.jqueryui.com/
.
If I accidentally closed a ticket for the jQuery core code, feel free
to reopen it. Please take the opportunity to check that the ticket has
a clear test case and describes the browsers where you have been able
to reproduce the problem. In general it's a good idea to post the
problem on the forums to get a consensus on whether a bug ticket
should be opened.

In preparation for the push to a new release of jQuery, I've been
cleaning up bug reports in the jQuery core bug tracker. Many tickets
languiished because they weren't actually jQuery core bugs, but
instead should have been reported on the forums or sent to the author
of the plugin. jQuery UI also has its own bug tracker, http://dev.jqueryui.com/
.
If I accidentally closed a ticket for the jQuery core code, feel free
to reopen it. Please take the opportunity to check that the ticket has
a clear test case and describes the browsers where you have been able
to reproduce the problem. In general it's a good idea to post the
problem on the forums to get a consensus on whether a bug ticket
should be opened.

http://dev.jquery.com/ticket/4500
I think we've discussed this a few times before and it was going to be
expensive to run all the way up the tree to make elements visible in
order to determine the dimensions. If that's still the consensus I'll
close this as wontfix and update the documentation. Right now the docs
say the methods work on hidden elements, but that only applies when
the element itself is hidden, not when parents are hidden.

Re this ticket:
http://dev.jquery.com/ticket/4283
Version 1.3.x now detect documents served as XHTML+XML to be XML
documents. This means the attributes-are-sometimes-properties magic
doesn't happen in jQuery.attr. So,
$("#check").attr("checked", true);
sets an attribute named "checked" on #check but does not set the
checked property/expando.

This looks like a difficult one to fix:
http://dev.jquery.com/ticket/4087
In 1.3.x the selected nodes are moved out of the document before the
insert operation is performed. That means any inserts that depend on
the position of selected nodes won't work.
Ideas?

This has been a busy ticket:
http://dev.jquery.com/ticket/4017
I haven't see the problem myself, but you can tell by the activity
that it's causing some issues for IE users/developers. Down the ticket
a bit there's a proposed patch to add "text/plain" to the object tag,
but one person reported back that it didn't solve the issue in IE6.
Ideas?

The before/after/insertBefore/insertAfter methods require a parentNode
so that the content can be inserted relative to the element. So, $
("

unusual

").after("

case

") will fail.
http://dev.jquery.com/ticket/3940
Maybe that should just be documented? There are plenty of other ways
to solve the problem.

So in the case like $("div").find("a") where an a element can be
reached via multiple descendants, should the duplicates be removed? I
expected they would be.
http://dev.jquery.com/ticket/2490

I was looking at this ticket and just attached a test case:
http://dev.jquery.com/ticket/3827
In the test, you can uncomment the lines to have the handlers return
false and prevent the default action, which would be to toggle the
checkbox state.
In jQuery, trigger() calls the handler before the default action is
taken. The check box is in its previous state, the one before the
click. If the handler returns false and/or uses preventDefault, jQuery
will not call the DOM element's click() method. Otherwise it calls the
click method and the default action occurs. (Also, handlers attached
via a native onclick property are only called in this case.)
In native DOM, the handler appears to be called *after* the default
action has already been taken. Returning false and/or using
preventDefault seems to reverse the default action; I could even see
the checkbox appear briefly in some cases.
You can get the native DOM behavior for a click in jQuery by using '''$
("#btn")[0].click()''' rather than '''$("#btn").click()''' or '''$
("#btn")[0].trigger("click")'''.
So I think the issue boils down to: If there is a native DOM method
for a particular element (click, change, etc.) should .trigger() use
that to invoke the handlers, rather than calling the handlers and then
only calling the native DOM method if the handlers did not return
false? (There may be bubbling issues with that on some event types,
I'm not sure.) Or, should the wiki just document the fact that
manually triggered versions of native events happen at a different
time?

> As of 1.0.3 I believe you can do this with straight

> The core .height() and .width() methods are deprecated in 1.1.
Sho 'nuff, I missed that. In that case it makes sense to remove it from
dimensions.js eventually.
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

> I have left some code in the .height() and .width() methods
> to take a value to set the height or width. This behavior will
> not be documented and is to be deprecated in 1.1 but I have
> left it in for backwards compatibility. Do not rely on this
> behavior because it will be removed in the future.
The core .height() and .width() methods are also setters though. If that's
deprecated then we're back to dimensions.js having different behavior than
the core methods it replaces. Or are the core methods losing their setter
ability too?
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

>> It is a little faster to remove classes only on the rows that are

--

>> var counter = 0;

You are right, I just checked it. I am going for more coffee.

-----Original Message-----
From: discuss-bounces@jquery.com [mailto:discuss-bounces@jquery.com] On
Behalf Of Mike Alsup
Sent: Monday, January 08, 2007 9:04 AM
To: jQuery Discussion.
Subject: Re: [jQuery] jQuery 1.1a (form submit)

Wait, the whole point of this thread was that it works differently now.
Yes, the form.submit() function now fires when you call $().submit().
No, there isn't a way to turn it off.
Yes, that doesn't seem to make much sense because it will submit your form,
then call the validation function and ignore the result.
Yes, I would call that a bug.
The offending code is in event.js:
if ( element[ type ] && element[ type ].constructor == Function )
    element[ type ]();
-----Original Message-----
From: Dave Methvin [mailto:dave.methvin@gmail.com]
Sent: Monday, January 08, 2007 8:47 AM
To: 'jQuery Discussion.'
Subject: RE: [jQuery] jQuery 1.1a (form submit)

--

Give this a try.
http://methvin.com/jquery/splitter/
Oskar, it sounds like you may have solved some of the problems with IE6 I
haven't tackled yet. This version doesn't yet handle min-width and max-width
for IE6 but I plan to put it there. Maybe we could join forces on this? It
looks like you've pulled the min-width and max-width support out into its
own plugin, which would be a great way to handle it.
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/