Nabble - jQuery Dev List

Proposed fix for #5706 - .attr() fails with TypeError when used on foreign elements, such as SVG

2009-12-23T06:32:22Z

Please review.

http://dev.jquery.com/ticket/5706

Ticket has full description as well as two patches on github, one for jQuery, one for Sizzle. Thanks.

- Richard

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: jQuery require and script loaders

2009-12-23T04:40:45Z

Maybe I should start writing a dependency loading system... LOL

On Dec 22, 9:42 am, aHeckman <aaron.heckm...@...> wrote:

> Julian, dominoes is very nice. I like your flexible syntax for
> ordering dependencies and how you allow your configuration of named
> resources.
>
> I too just finished a loader for jQuery but it has different goals in
> mind. Namely, I wanted a loader that would do more than just
> javascript. Many jQuery plugins and jQuery-ui components have css
> stylesheet and image dependencies as well so I felt a good loader
> should handle these too. It's still early but so far it's been useful.
> You can check it out here:http://github.com/aheckmann/jQuery.use
>
> My vision is that we come together as a community and organize all of
> the jQuery components / plugins under one umbrella, and be able to
> dynamically serve all of them from a managed repo / CDN - thinkhttp://yui.yahooapis.com/combo?for the entire jQuery community.
> jQuery.use is configurable to use a file concat service like YUIs
> combo service.
>
> jQuery.use('jquery-ui-tabs', function ($) {
> $('.tabs').tabs();
>
> });
>
> On Dec 21, 9:23 pm, Julian Aubourg <aubourg.jul...@...> wrote:
>
>
>
> > OK, so I finally got time to write some docs & unit tests for my own baby...
> > and here comes Dominoes:http://code.google.com/p/javascript-dominoes/
>
> > See the Wiki pages to get an idea of what it is capable of (quite the wall
> > of text there but heh).
>
> > It is more of a general purpose "scheduler" and provides some nice features
> > like property expansion, global dependency rules, etc, etc. It is browser
> > agnostic in the spirit of sizzle.
>
> > Only 4kB minified but the google compiler breaks the code (I didn't have
> > time to investigate why).
>
> > 2009/12/21 John Resig <jere...@...>
>
> > > Hi James -
>
> > > There's definitely room for collaboration here. As I mentioned in the
> > > comments on the commit I'm planning on holding off on jQuery.require()
> > > until post-1.4 so that we can really get it right and hopefully
> > > standardize a bit. I'll ping you again after the 1.4 dust has settled
> > > and we can discuss it some more.
>
> > > --John
>
> > > On Wed, Dec 16, 2009 at 7:16 PM, James Burke <jrbu...@...> wrote:
> > > > I heard about the jQuery require that is shown as part of this
> > > > changeset:
>
> > >http://github.com/jquery/jquery/commit/998cb005fc378188b3bae319e391d1...
>
> > > > I work on Dojo's module loader, and have a new standalone (no other
> > > > library dependency) script loader here:
> > > >http://code.google.com/p/runjs/wiki/RunJs
>
> > > > The goal is to keep RunJS compatible with the goals of CommonJS
> > > > (avoiding globals mainly) but still allow for a module syntax that
> > > > works well natively in the browser. It does not use XHR calls, just
> > > > script tags. Works before page load and after page load.
>
> > > > It also handles loading regular scripts that are not coded as modules:
>
> > > > run(["some/script.js", "another/script.js"], function() {
> > > > //This callback is fired when both scripts load
> > > > });
>
> > > > For scripts that do follow the module syntax and have dependencies, it
> > > > properly traces the module dependencies and calls the module
> > > > definition functions in the correct order.
>
> > > > It would be ideal if more of the JS libraries started to standardize
> > > > on a script loader. I am happy to work out changes to RunJS if jQuery
> > > > might find it useful to use. For instance, the entry point does not
> > > > have to be called run(), I am considering switching to script() since
> > > > it handles general script loading and callbacks when scripts are
> > > > loaded.
>
> > > > It also might be good to pull out a script loader from the core jQuery
> > > > library, if only to keep the separation of concerns easier to track.
> > > > RunJS has plugins for i18n string bundle loading, and also can load
> > > > text files (like HTML snippets) via async xhr, then inline those text
> > > > files as part of a build process.
>
> > > > But I may be misunderstanding the scope of jQuery's require. In any
> > > > case, I just wanted to see if there was some common interest and if we
> > > > might be able to coordinate our efforts.
>
> > > > Thanks for your time,
> > > > James Burke
>
> > > > --
>
> > > > 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@....
> > > > To unsubscribe from this group, send email to
> > > jquery-dev+unsubscribe@...<jquery-dev%2Bunsubscribe@googlegrou ps.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-dev@....
> > > To unsubscribe from this group, send email to
> > > jquery-dev+unsubscribe@...<jquery-dev%2Bunsubscribe@googlegrou ps.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-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: Feature Request: $.ajax(): Detect json via respons e header

2009-12-23T01:56:57Z

On Wed, Dec 23, 2009 at 5:16 AM, John Resig <jeresig@...> wrote:

Is there an open ticket on this? If so I don't see a reason not to land it.

Well, if there is no safe json decoder (i.e. just eval()) it's not immediatly clear to me, that I really want this.
Yes, all the other jscripts also come from the server and are thus somehow equally trustworthy.
And the Content-Type on the HTTP header can not easily be spoofed. But I don't want jquery to evaluate some
unsafe user content (e.g. CMS, Guestbook, ... ) that wasn't ever meant to be json ...

Tobias

> Could we change the $.ajax() function to treat the server's response
> as json if dataType is unspecified and the response content-type is
> "application/json"?
>
> Thanks,
> Dave
>

Re: Feature Request: $.ajax(): Detect json via respons e header

2009-12-22T20:16:13Z

Is there an open ticket on this? If so I don't see a reason not to land it.

--John

On Tue, Dec 22, 2009 at 10:35 PM, Rick Waldron <waldron.rick@...> wrote:

> I think I hacked a copy of jquery 1.3.2 to do this... I'll take a look and
> drop you a line.
>
> -- Sent from my Palm Prē
> ________________________________
> webbiedave wrote:
>
> Hello.
>
> Could we change the $.ajax() function to treat the server's response
> as json if dataType is unspecified and the response content-type is
> "application/json"?
>
> Thanks,
> Dave
>
> --
>
> 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@....
> To unsubscribe from this group, send email to
> jquery-dev+unsubscribe@....
> 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-dev@....
> To unsubscribe from this group, send email to
> jquery-dev+unsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>

Re: Feature Request: $.ajax(): Detect json via respons e header

2009-12-22T19:35:09Z

I think I hacked a copy of jquery 1.3.2 to do this... I'll take a look and drop you a line.

-- Sent from my Palm Prē

webbiedave wrote:

Hello.

Could we change the $.ajax() function to treat the server's response
as json if dataType is unspecified and the response content-type is
"application/json"?

Thanks,
Dave

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: Feature Request: $.ajax(): Detect json via response header

2009-12-22T15:17:21Z

What if we changed the JSON part of the httpData function from:

// Get the JavaScript object, if JSON is used.
if ( type == "json" )
data = window["eval"]("(" + data + ")");

to:

// Get the JavaScript object, if JSON is used.
if ( type == "json" || !type && ct && ct.indexOf("json") >= 0)
data = window["eval"]("(" + data + ")");

It's been quite helpful to me indeed, i.e., in implementing a
classical "client submits form" ---> "server processes form" --->
"server returns content (form errors) or redirect (no errors)"
approach within tabs, greatly speeding development time:

$.ajax({
type: "POST",
url: "/mformprocessor",
data: $("#mform").serialize(),
success: function(resp){
if (!empty(resp.redir) {
redirTab(resp.redir, TABS_CONTAINER_ID, 2);
} else {
setTabHTML(resp, TABS_CONTAINER_ID, 2);
}

}
});

This affords the server the ability to effect varying actions on the
client without worrying about output buffering (resp.html) and other
headache inducers. Plus, I think it's a good idea to treat the
response as json if the content-type header is json.

Might something like this be committable?

On Dec 22, 1:19 pm, webbiedave <webbied...@...> wrote:
> Hello.
>
> Could we change the $.ajax() function to treat the server's response
> as json if dataType is unspecified and the response content-type is
> "application/json"?
>
> Thanks,
> Dave

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: Feature Request: $.ajax(): Detect json via response header

2009-12-22T14:56:59Z

With the upcoming new ajax code, it should be doable.

2009/12/22 webbiedave <webbiedave@...>

Hello.

Could we change the $.ajax() function to treat the server's response
as json if dataType is unspecified and the response content-type is
"application/json"?

Thanks,
Dave

--

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@....
To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: A fix for the broken "selected" code in attr()

2009-12-22T12:57:02Z

> // Safari mis-reports the default selected property of a hidden
> option
> // Accessing the parent's selectedIndex property fixes it
> if ( name == "selected" && elem.parentNode ) {
> elem.parentNode.selectedIndex;
> }
>
> I previously made two points:
> 1) This code will not work of the <option> is in an <optgroup>
> (common)

Filed and fixed. http://dev.jquery.com/ticket/5701

> After some discussion with colleagues, ...

Heh.

> // 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;
> }
>
> with these:
>
> if (name=="selected") {
> return getOptionSelected(elem);
> }
>
> Then you'll have a more robust, feature-tested, efficient, correctly-
> documented fix to this "problem".

As it is the overhead to the existing fix is very minimal, has no
function calls, no DOM manipulation, and is only 6 lines of code (even
with the optgroup fix).

Doing a bit more research I found a very similar problem when you use
dynamically-created optgroups in IE. I found a feature detect that was
able to detect the specific logic in Webkit and IE and skip the
property accesses if not necessary.

Filed and fixed: http://dev.jquery.com/ticket/5702

> Again, though, my suggestion is to just remove it. I don't think
> generalized library code should try to normalize behavior that is not
> demanded by the specs and that can be easily corrected through proper
> HTML.

Although, I seem to remember having a very heated discussion wherein
you advocated that our position of asking users to specify a doctype
to animate element width/height to 0 in IE 6 was too extreme and that
we shouldn't be making demands of a user's markup. (Granted that is
likely the only place where we make such a demand: We just ask the
users to provide a document that validates first.)

Thanks for the pointers. In the future, filing individual
tickets/patches/test cases will be quite helpful.

--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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Feature Request: $.ajax(): Detect json via response header

2009-12-22T11:19:55Z

Hello.

Could we change the $.ajax() function to treat the server's response
as json if dataType is unspecified and the response content-type is
"application/json"?

Thanks,
Dave

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: .SlideUp() + Firefox

2009-12-22T09:34:42Z

Yes, this is a big problem. But, i don´t know a solution. I wrote two
workarounds for that.

1. disable scrolbar on body + add padding-right in the size of the
scrollbar width (has to dynamically calclated) for the time the
animation occurs. between disabling scrollbar and calling slideup has
to be a short delay, so that ff can render the disabled scrollbar
before animating.

pro:
- although this sounds very obtrusive, the delayed scrollbar change isn
´t noticed by normal users
- this could be easily generalized
con:
sometimes the bad effect still happens (if someone knows a reason for
this, plz tell me)

2. animate the scrolltop of body at the same time to scroll up

pro:
- if you make the upscrplling a little faster than the slideup, the
effect doesn´t appear

con:
- you can´t generate a generalized code to do this. (multi-colum
layout etc....)

On 22 Dez., 12:39, "Peter Wright" <Peter.Wri...@...> wrote:

> Hello,
>
> Has anyone else ever noticed a rather disgusting scrollbar redraw
> causing a page to flicker when the content shrinks in size (usually
> triggered by SlideUp())?
>
> This occurs when the document's height is reduced gradually causing the
> viewport's view to be invalid multiple times a second. so the scrollbar
> has to be redrawn to handle where the viewport's location matches the
> bottom of the page. If anyone knows of a graceful solution to implement
> handling a clean slideUp when the viewport is near the document bottom I
> would much appreciate it, perhaps something to be considered in the 1.4
> release?
>
> Kind regards,
>
> Peter Wright
> --------------------------------------------------------------------------------------------------
> This email and any attachments are confidential and are for the use of the addressee only. If you are not the addressee, you must not use or disclose the contents to any other person. Please immediately notify the sender and delete the email. Statements and opinions expressed here may not represent those of the company. Email correspondence is monitored by the company. This information may be subject to Export Control Regulation. You are obliged to comply with such Regulations
>
> The parent company of the Renishaw Group is Renishaw plc, registered in England no. 1106260. Registered Office: New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, United Kingdom. Tel +44 (0) 1453 524524
> --------------------------------------------------------------------------------------------------

Re: jQuery 1.4 $.param demystified

2009-12-22T09:12:34Z

Dave, I have no idea how many people are serializing complex data
structures into query strings for client-server interactions, but I
see [] in forms all the time (or in #jquery, completely fail to see []
in forms, when we're trying to help a newbie troubleshoot).

Still, this is something I've been using in jQuery BBQ entirely on the
client-side. When people ask, I do recommend that they use JSON, but
it's nice to have the ability in jQuery 1.4 to represent a somewhat
more robust data structure, cross-browser, without requiring any
extra .js files.

And despite the relative weaknesses of request params parsing, the
real benefit here is that the same method that currently works for
passing form data can be made to use for XHR, without needing anything
fancy on the server-side to handle different cases, which makes
progressive enhancement type stuff easier.

- Ben

On Dec 22, 11:23 am, Dave Methvin <dave.meth...@...> wrote:

> That helps a lot. It does seem to make sense to put the flag in
> ajaxSettings, which also keeps it out of the main jQuery namespace. My
> preference would be to avoid changing the behavior from 1.3==>1.4 by
> having traditional:true by default.
>
> Independent of PHP-compatible param naming, which I think is
> definitely useful, does any code currently use or need the ability to
> create nested complex objects in a query string? It seems like this is
> inventing a new JSON-like serialization mechanism when it might be
> better to encourage JSON use instead. There is good JSON support on
> just about all platforms, whereas we're grappling with the issues here
> of how to deal with traditional vs non-traditional params in a
> coherent way and the paint on this isn't dry yet.

Re: Re: change-event bugs in IE

2009-12-22T08:46:10Z

> I have looked into the code today and everything works fine :-). +

Excellent :) If you haven't already, I recommend checking out
test/delegatetest.html - I've been using that to do a bunch of this
change/submit/focus/blur testing and it's been very helpful.

> Altough it is a huge hack with some complexity, the code looks slick
> and straight forward.
>
> the only thing we could optimize would be:
> a) to not use .data on checkboxes too
> or
> b) to remove .data on focusout
>
> But I don´t think it is worth doing it. Do we have reasonable
> perfromance pros in time or memory here, if we remove the data async?
> (and not on unload/cleandata-actions)

Yeah, I think we're probably ok here, as well. The normal garbage
collection that we do should be sufficient, I think.

--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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: jQuery 1.4 $.param demystified

2009-12-22T08:23:30Z

That helps a lot. It does seem to make sense to put the flag in
ajaxSettings, which also keeps it out of the main jQuery namespace. My
preference would be to avoid changing the behavior from 1.3==>1.4 by
having traditional:true by default.

Independent of PHP-compatible param naming, which I think is
definitely useful, does any code currently use or need the ability to
create nested complex objects in a query string? It seems like this is
inventing a new JSON-like serialization mechanism when it might be
better to encourage JSON use instead. There is good JSON support on
just about all platforms, whereas we're grappling with the issues here
of how to deal with traditional vs non-traditional params in a
coherent way and the paint on this isn't dry yet.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: jQuery require and script loaders

2009-12-22T06:42:35Z

Julian, dominoes is very nice. I like your flexible syntax for
ordering dependencies and how you allow your configuration of named
resources.

I too just finished a loader for jQuery but it has different goals in
mind. Namely, I wanted a loader that would do more than just
javascript. Many jQuery plugins and jQuery-ui components have css
stylesheet and image dependencies as well so I felt a good loader
should handle these too. It's still early but so far it's been useful.
You can check it out here: http://github.com/aheckmann/jQuery.use

My vision is that we come together as a community and organize all of
the jQuery components / plugins under one umbrella, and be able to
dynamically serve all of them from a managed repo / CDN - think
http://yui.yahooapis.com/combo? for the entire jQuery community.
jQuery.use is configurable to use a file concat service like YUIs
combo service.

jQuery.use('jquery-ui-tabs', function ($) {
$('.tabs').tabs();
});

On Dec 21, 9:23 pm, Julian Aubourg <aubourg.jul...@...> wrote:

> OK, so I finally got time to write some docs & unit tests for my own baby...
> and here comes Dominoes:http://code.google.com/p/javascript-dominoes/
>
> See the Wiki pages to get an idea of what it is capable of (quite the wall
> of text there but heh).
>
> It is more of a general purpose "scheduler" and provides some nice features
> like property expansion, global dependency rules, etc, etc. It is browser
> agnostic in the spirit of sizzle.
>
> Only 4kB minified but the google compiler breaks the code (I didn't have
> time to investigate why).
>
> 2009/12/21 John Resig <jere...@...>
>
> > Hi James -
>
> > There's definitely room for collaboration here. As I mentioned in the
> > comments on the commit I'm planning on holding off on jQuery.require()
> > until post-1.4 so that we can really get it right and hopefully
> > standardize a bit. I'll ping you again after the 1.4 dust has settled
> > and we can discuss it some more.
>
> > --John
>
> > On Wed, Dec 16, 2009 at 7:16 PM, James Burke <jrbu...@...> wrote:
> > > I heard about the jQuery require that is shown as part of this
> > > changeset:
>
> >http://github.com/jquery/jquery/commit/998cb005fc378188b3bae319e391d1...
>
> > > I work on Dojo's module loader, and have a new standalone (no other
> > > library dependency) script loader here:
> > >http://code.google.com/p/runjs/wiki/RunJs
>
> > > The goal is to keep RunJS compatible with the goals of CommonJS
> > > (avoiding globals mainly) but still allow for a module syntax that
> > > works well natively in the browser. It does not use XHR calls, just
> > > script tags. Works before page load and after page load.
>
> > > It also handles loading regular scripts that are not coded as modules:
>
> > > run(["some/script.js", "another/script.js"], function() {
> > > //This callback is fired when both scripts load
> > > });
>
> > > For scripts that do follow the module syntax and have dependencies, it
> > > properly traces the module dependencies and calls the module
> > > definition functions in the correct order.
>
> > > It would be ideal if more of the JS libraries started to standardize
> > > on a script loader. I am happy to work out changes to RunJS if jQuery
> > > might find it useful to use. For instance, the entry point does not
> > > have to be called run(), I am considering switching to script() since
> > > it handles general script loading and callbacks when scripts are
> > > loaded.
>
> > > It also might be good to pull out a script loader from the core jQuery
> > > library, if only to keep the separation of concerns easier to track.
> > > RunJS has plugins for i18n string bundle loading, and also can load
> > > text files (like HTML snippets) via async xhr, then inline those text
> > > files as part of a build process.
>
> > > But I may be misunderstanding the scope of jQuery's require. In any
> > > case, I just wanted to see if there was some common interest and if we
> > > might be able to coordinate our efforts.
>
> > > Thanks for your time,
> > > James Burke
>
> > > --
>
> > > 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@....
> > > To unsubscribe from this group, send email to
> > jquery-dev+unsubscribe@...<jquery-dev%2Bunsubscribe@...>
> > .
> > > 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-dev@....
> > To unsubscribe from this group, send email to
> > jquery-dev+unsubscribe@...<jquery-dev%2Bunsubscribe@...>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/jquery-dev?hl=en.

Re: Bug in jQuery.val() in beta 1.4a2

2009-12-22T06:39:36Z

On Dec 22, 1:05 am, John Resig <jere...@...> wrote:
> Just to clarify then, since jQuery already covers cases 2-4 as you're
> expecting it to and case #1 currently fails - and that case is
> decidedly not what this thread discussion started as.

I'm just pointing out several test cases that should be handled
correctly, possibly added to the test suite.

> > <select id="x">
> > <option value="1">Dummy</option>
> > <option value="">Empty</option>
> > </select>
> > $('#x').val('')
> > should select the second option.
> Agreed.

Broken in 1.4.1a2, but now corrected I see.

> > <select id="x">
> > <option value="x">z</option>
> > <option value="y">x</option>
> > </select>
> > $('#x').val('x')
> > should select the first option only.
> Yep, as it does in 1.4.

Yes, but it didn't in 1.3.2.

> > <select multiple id="x">
> > <option value="x">z</option>
> > <option value="y">x</option>
> > </select>
> > $('#x').val('x')
> > should select the first option only, IMO. It's kind of ambiguous and
> > jQuery should define what it wants to do.
> Yep, as it does in 1.4.

Yes, but it didn't in 1.3.2.

> In fact, 1.4 removes the ambiguity completely
> by only using the value with the val method, which is much better.

I agree, but it is a change in the API and may make it difficult for
some to upgrade (it removes functionality). The wandering API
sometimes makes it difficult to upgrade jQuery versions, which is why
I have some projects stuck on 1.2.6 and one that was just recently
upped from 1.1.2! :(

Matt Kruse

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: jQuery 1.4 $.param demystified

2009-12-22T05:21:59Z

Ok, so $.param is explicitly called in $.fn.load, $.fn.serialize and
$.ajax.

I really like the idea of adding "traditional" as a property in the
$.ajaxSettings data object, as well as making it a second, optional
argument to $.param. This is something I had considered at one point,
but never implemented. I don't see any benefit to adding a
"traditional" argument to $.fn.serialize, because form input names
should always explicity include any necessary [], to allow for
graceful dedgradation.

How does this commit look?

http://github.com/cowboy/jquery/commit/4ea851e08841447ba3550dc54785b3c026a5560f

* $.ajaxSettings.traditional defaults to false, changeable by
$.ajaxSetup({ traditional: true });
* $.fn.load and all other $.ajax XHR methods use the
$.ajaxSettings.traditional property to determine their behavior, which
can be overridden with $.ajax options.
* $.param behavior defaults to the value of
$.ajaxSettings.traditional but can be overridden by a second, optional
argument.

I also like the idea that "traditional" is false by default. It's
relatively easy for anyone upgrading to 1.4 to set $.ajaxSetup
({ traditional: true }); in their code if they are encountering
encoding issues, but for beginner PHP and Rails users (which seems to
represent a substantial portion of the jQuery community) starting on
1.4, this will be one less AJAX question that they need to ask.

Either way, it would be trivial to make the "traditional" flag to
default to true, just as long as there *is* a traditional flag.

Perhaps it would be useful to break down how request params are
deserialized, by server / framework.. anyone?

- Ben

On Dec 21, 9:56 pm, Dave Methvin <dave.meth...@...> wrote:

> > Does this mean that the default mechanism now changed, so that code
> > which used to work will silently start failing?
>
> Yeah, I have some concerns about this. It's great to have $.param
> facilitate PHP-friendly serialization, but I'd like to see the default
> reversed to avoid breaking existing code.
>
> > The argument that "this helps PHP" could be countered by "this hurts
> > java servlets", where request.getParameterValues("a") already returns
> > an array for a (as in jQuery < 1.4), but needs to change for jQuery
> > 1.4.
>
> This also breaks existing server ASP code, which already understands
> that multiple params with the same name should be turned into an
> array.
>
> Just another thought here; the flag being added is global, but it's
> quite possible a page may be communicating with different hosts that
> have different requirements. If different plugins have different needs
> then it could get really messy having them bang around the same global
> flag.
>
> Either as an alternative or addition to a global flag, .ajaxSettings,
> the .ajax() options parameter, .param(), .serialize() and
> serializeArray() could support an optional argument to decide how to
> serialize the data.

Re: Bug in jQuery.val() in beta 1.4a2

2009-12-22T04:29:35Z

John,

I think that this is a very common way to set the selection, and might
end up breaking people's code when they upgrade to jQuery 1.4. People
probably figured out that you could set the selection with either
property and used this in their code. When these people upgrade to
jQuery 1.4, their code will break and they won't know why! People
have a different value property and display value all the time. It
seems weird that their code will work when either one of these
properties is defined but not both.

Devon

On Dec 22, 2:05 am, John Resig <jere...@...> wrote:

> Just to clarify then, since jQuery already covers cases 2-4 as you're
> expecting it to and case #1 currently fails - and that case is
> decidedly not what this thread discussion started as.
>
> > Consider the following cases:
>
> > #1)
> > <select id="x">
> > <option value="1">Dummy</option>
> > <option value="">Empty</option>
> > </select>
>
> > $('#x').val('')
> > should select the second option.
>
> Agreed.
>
> > #2)
> > <select id="x">
> > <option value="x">z</option>
> > <option value="y">x</option>
> > </select>
>
> > $('#x').val('x')
> > should select the first option only.
>
> Yep, as it does in 1.4.
>
> > #3)
> > <select id="x">
> > <option value="x">y</option>
> > <option>y</option>
> > </select>
>
> > $('#x').val('y')
> > should select the second option only.
>
> Yep, as it does in 1.4.
>
> > #4)
> > <select multiple id="x">
> > <option value="x">z</option>
> > <option value="y">x</option>
> > </select>
>
> > $('#x').val('x')
> > should select the first option only, IMO. It's kind of ambiguous and
> > jQuery should define what it wants to do.
>
> Yep, as it does in 1.4. In fact, 1.4 removes the ambiguity completely
> by only using the value with the val method, which is much better. To
> Devon: The change was very much intentional, as it was the case was
> far too ambiguous and it was causing other problems to pop up. A very
> explicit note will be made in the 1.4 release notes concerning this
> change.
>
> Revisiting the logic for getting the select val it looks like the ||
> this.text was a holdover from trying to fix an IE 6 bug: If you don't
> specify a value it'll supply "" as the value instead of the option
> text. I've re-worked the logic to work uniformly in all browsers.
>
> Filed and fixed:http://dev.jquery.com/ticket/5697
>
> I also went through the logic for .val() on checkboxes and radios -
> the revised logic there definitely didn't make sense, especially since
> this.value will never be empty (not specifying a value will just
> result in a value of "on" - and specifying an empty value is a case we
> want to hit).
>
> Filed and fixed:http://dev.jquery.com/ticket/5698
>
> Of course, it would be easy if that was the case but Webkit returns ""
> if you don't specify a value attribute, instead of "on".
>
> Filed and fixed:http://dev.jquery.com/ticket/5699
>
> --John

Re: change-event bugs in IE

2009-12-22T04:02:28Z

I have looked into the code today and everything works fine :-). +

Altough it is a huge hack with some complexity, the code looks slick
and straight forward.

the only thing we could optimize would be:
a) to not use .data on checkboxes too
or
b) to remove .data on focusout

But I don´t think it is worth doing it. Do we have reasonable
perfromance pros in time or memory here, if we remove the data async?
(and not on unload/cleandata-actions)

On 21 Dez., 22:26, John Resig <jere...@...> wrote:

> I just landed your change:http://github.com/jquery/jquery/commit/209751fcbd8a42eef68df44c875763...
>
> The best way to get further changes in is to make a fork of jQuery on
> Github, commit your changes to your fork, and then do a pull request.
> I'll see that right away and will be able to help you. It's also
> generally a good practice to have tickets to go along with your
> changes so that we can tie it back to a central point of discussion.
>
> Thanks for your help!
>
> --John
>
> On Mon, Dec 21, 2009 at 4:19 PM, alexander farkas
>
> <a.farkas...@...> wrote:
> > This is great. I ´m awaiting jQuery 1.4 eagerly. : -). After I wrote
> > the script I found two bugs in my script. Didn´t know, that you
> > already grabbed the code. But you only corrected one of them.
>
> > change the following line in the beforeactivate-handler:
> > return jQuery.data( elem, "_change_data", getVal(elem) );
>
> > to something like this:
>
> > jQuery.data( elem, "_change_data", getVal(elem) );
> > //for FF strictmode, if you want (code won´t be ever run in ff):
> > return undefined;
>
> > If you leave it, the other way and the data for a unchecked checkbox
> > is collected, the event will be prevented, wich breaks keyboard
> > handling.
>
> > + One other thing:
>
> > I would build the new jQuery-Version and make some more tests on this,
> > using your delegatetest.html. If i find something, should I fill a
> > bug, add the fix in this post or what is your preferred way?
>
> > On 21 Dez., 21:34, John Resig <jere...@...> wrote:
> >> I poured over your patch all morning/afternoon and made a number of
> >> changes, but finally landed it in jQuery core:http://github.com/jquery/jquery/commit/5dc6b7ce3469eaadb37a151d449e8d...
>
> >> We now completely override the change event in IE, even for binding to
> >> form elements. This gives us full parity with other browsers (yay!).
>
> >> Thanks again, Alexander!
>
> >> --John
>
> >> On Mon, Dec 21, 2009 at 9:52 AM, alexander farkas
>
> >> <a.farkas...@...> wrote:
> >> > the url to the testcase, fix and diff:
> >> >http://www.protofunc.com/scripts/jquery/change-event/fixed-change.html
>
> >> > On 21 Dez., 15:50, alexander farkas <a.farkas...@...>
> >> > wrote:
> >> >> I looked in the current implementation of the change event and found
> >> >> some bugs in the IE specific code. The most obvious bugs were:
>
> >> >> 1. change-event bugs in conjunction with live:
> >> >> - the change event on radios happens to early (before the state is
> >> >> changed to checked)
> >> >> - the change event on radios also occurs, if the user only focuses it
> >> >> without changing it´s state (keyboard navigation or but untestet
> >> >> readonly-property)
> >> >> - the change event occurs also on disabled/readonly checkboxes
> >> >> - the change event on text-input and textarea never occurs (reason:http://groups.google.com/group/jquery-dev/browse_thread/thread/270483...)
>
> >> >> 2. change-event bugs in conjunction with bind
> >> >> - most change events are doubbeld (normal change + computed change
> >> >> including the bugs mentioned above)
>
> >> >> I tried to fix these issues you can find the demos + an uniffied diff
> >> >> @http://www.protofunc.com/scripts/jquery/change-event/fixed-
> >> >> change.html
>
> >> >> To see the difference you have to use IE (6-8) with a console.log.
>
> >> >> Due to the fact, that the change-event in IE is vehemently broken. We
> >> >> can completely intercepting it. This also allowes us to not only fix
> >> >> the ovbious things like the bad change event on checkboxes/
> >> >> radiobuttons. it also allowes us to fix the accessibility issue with
> >> >> the change event on select-elements.
>
> >> >> The code is a quickfix so it needs a little love.
>
> >> > --
>
> >> > 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@....
> >> > To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> >> > 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-dev@....
> > To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> > For more options, visit this group athttp://groups.google.com/group/jquery-dev?hl=en.

.SlideUp() + Firefox

2009-12-22T03:39:23Z

.SlideUp() + Firefox

Hello,

Has anyone else ever noticed a rather disgusting scrollbar redraw causing a page to flicker when the content shrinks in size (usually triggered by SlideUp())?

This occurs when the document's height is reduced gradually causing the viewport's view to be invalid multiple times a second. so the scrollbar has to be redrawn to handle where the viewport's location matches the bottom of the page. If anyone knows of a graceful solution to implement handling a clean slideUp when the viewport is near the document bottom I would much appreciate it, perhaps something to be considered in the 1.4 release?

Kind regards,

Peter Wright

--------------------------------------------------------------------------------------------------
This email and any attachments are confidential and are for the use of the
addressee only. If you are not the addressee, you must not use or disclose the
contents to any other person. Please immediately notify the sender and
delete the email. Statements and opinions expressed here may not
represent those of the company. Email correspondence is monitored by
the company. This information may be subject to Export Control
Regulation. You are obliged to comply with such Regulations

The parent company of the Renishaw Group is Renishaw plc, registered in
England no. 1106260. Registered Office: New Mills, Wotton-under-Edge,
Gloucestershire, GL12 8JR, United Kingdom. Tel +44 (0) 1453 524524
--------------------------------------------------------------------------------------------------

Re: Re: Bug in jQuery.val() in beta 1.4a2

2009-12-21T23:05:39Z

Just to clarify then, since jQuery already covers cases 2-4 as you're
expecting it to and case #1 currently fails - and that case is
decidedly not what this thread discussion started as.

> Consider the following cases:
>
> #1)
> <select id="x">
> <option value="1">Dummy</option>
> <option value="">Empty</option>
> </select>
>
> $('#x').val('')
> should select the second option.

Agreed.

> #2)
> <select id="x">
> <option value="x">z</option>
> <option value="y">x</option>
> </select>
>
> $('#x').val('x')
> should select the first option only.

Yep, as it does in 1.4.

> #3)
> <select id="x">
> <option value="x">y</option>
> <option>y</option>
> </select>
>
> $('#x').val('y')
> should select the second option only.

Yep, as it does in 1.4.

> #4)
> <select multiple id="x">
> <option value="x">z</option>
> <option value="y">x</option>
> </select>
>
> $('#x').val('x')
> should select the first option only, IMO. It's kind of ambiguous and
> jQuery should define what it wants to do.

Yep, as it does in 1.4. In fact, 1.4 removes the ambiguity completely
by only using the value with the val method, which is much better. To
Devon: The change was very much intentional, as it was the case was
far too ambiguous and it was causing other problems to pop up. A very
explicit note will be made in the 1.4 release notes concerning this
change.

Revisiting the logic for getting the select val it looks like the ||
this.text was a holdover from trying to fix an IE 6 bug: If you don't
specify a value it'll supply "" as the value instead of the option
text. I've re-worked the logic to work uniformly in all browsers.

Filed and fixed: http://dev.jquery.com/ticket/5697

I also went through the logic for .val() on checkboxes and radios -
the revised logic there definitely didn't make sense, especially since
this.value will never be empty (not specifying a value will just
result in a value of "on" - and specifying an empty value is a case we
want to hit).

Filed and fixed: http://dev.jquery.com/ticket/5698

Of course, it would be easy if that was the case but Webkit returns ""
if you don't specify a value attribute, instead of "on".

Filed and fixed: http://dev.jquery.com/ticket/5699

--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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

jQuery.extend(true,...) may have some bugs...discussion please?

2009-12-21T22:07:09Z

I was using objects as custom data structures for class initialization ( meaning var myWidget = new Widget( { foo: 'bar' } ) ), and I needed to be able to build up a master configuration that was the combination of all of the different sources. The idea is that I would use configuration 'fragments' that were pre-defined in order to specify desired behavior.

So far, sounds like I should use $.extend(), right?

Problem is, I wanted it to merge them. So, if there is a property of the object that is itself an object, I want the properties of the copy to be merged in with ( as a deep copy ) the target. For example: $.extend( { foo: { a: 'a' } }, { foo: { b:'b' } } ) should yield { foo: { a:'a',b:'b' } }.

Still sounds like $.extend, just with the optional deep copy function turned on, right? $.extend(true,...)

But what if one of the properties is an array? If I have an array of, for example, event listeners already defined, and the incoming object defines ANOTHER array, what should it do? Naturally, it should merge the two arrays, making one larger array, right?

And that's where $.extend falls down for me.

So, because $.extend couldn't quite do what I wanted, I knew I had to write my own. Which I did. And I also created a bunch of test cases which define my idea of what the object-merge function should do. My function passes all of those tests. Yeah! So, I then pointed those tests at $.extend(true,...). It passes 10 out of 25 tests. Hmmm...

So, I'm recommending that we have a discussion about $.extend(true,...) and whether or not it's failure to meet my expectations is a bug, or an unreasonable expectation. To that end, I have attached my qunit test file, and my custom merge() function definition. I would really appreciate it if people would look over the test cases that I created, and weigh in on whether or not the expected behavior is a reasonable thing to expect out of $.extend(true,...), and if not, why not?

Anyone have any thoughts?

--
John Arrowwood
John (at) Irie (dash) Inc (dot) com
John (at) Arrowwood Photography (dot) com
John (at) Hanlons Razor (dot) com
--
http://www.irie-inc.com/
http://arrowwood.blogspot.com/
Marie von Ebner-Eschenbach - "Even a stopped clock is right twice a day."

test.extend.js (15K) Download Attachment
merge.js (6K) Download Attachment

Re: Bug in jQuery.val() in beta 1.4a2

2009-12-21T21:01:19Z

On Dec 21, 10:32 pm, John Resig <jere...@...> wrote:
> > Agreed, the change is broken! Wasn't there a test case for the above
> > scenario?
> The previous technique was definitely not the right one to use. Cases
> were coming up where the same string was being used for the value and
> the text in different places and it couldn't figure out what to
> select.
> See the previous discussion/ticket/changeset:http://groups.google.com/group/jquery-dev/browse_thread/thread/74dddc...

Looks like the quick code changed wasn't thought through enough. The
correct algorithm needs to be decided on, rather than quick-fixing a
bug report. It shouldn't matter whether a situation "makes sense" or
whether someone would actually do it in practice. The specs are very
specific about how controls should function under all scenarios,
whether it "makes sense" or not.

Selecting options based on their text, regardless of value, seems to
make the method results confusing. Because you aren't actually setting
the value, then, you're setting some unknown value that corresponds to
the text value that you have matched.

Consider the following cases:

#1)
<select id="x">
<option value="1">Dummy</option>
<option value="">Empty</option>
</select>

$('#x').val('')
should select the second option.

#2)
<select id="x">
<option value="x">z</option>
<option value="y">x</option>
</select>

$('#x').val('x')
should select the first option only.

#3)
<select id="x">
<option value="x">y</option>
<option>y</option>
</select>

$('#x').val('y')
should select the second option only.

#4)
<select multiple id="x">
<option value="x">z</option>
<option value="y">x</option>
</select>

$('#x').val('x')
should select the first option only, IMO. It's kind of ambiguous and
jQuery should define what it wants to do.

Matt Kruse

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: Re: Bug in jQuery.val() in beta 1.4a2

2009-12-21T20:32:18Z

>> I can see why this optimization was done, but I think that this will
>> cause problems for a lot of people!
>
> Agreed, the change is broken! Wasn't there a test case for the above
> scenario?

The previous technique was definitely not the right one to use. Cases
were coming up where the same string was being used for the value and
the text in different places and it couldn't figure out what to
select.

See the previous discussion/ticket/changeset:
http://groups.google.com/group/jquery-dev/browse_thread/thread/74dddc2dd2195859

--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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: Bug in jQuery.val() in beta 1.4a2

2009-12-21T20:18:27Z

On Dec 21, 9:21 pm, Devon Govett <devongov...@...> wrote:
> I have found a bug in the jQuery.val() function.
> ...
> to the following in jQuery 1.4:
> this.selected = jQuery.inArray( this.value || this.text, values ) >= 0;

Indeed, this is a (probably unnoticed) change in logic.

Consider this:

<select id="x">
<option value="1">Dummy</option>
<option value="">Empty</option>
</select>

$('#x').val('') ==> Will not select the second option!

> I can see why this optimization was done, but I think that this will
> cause problems for a lot of people!

Agreed, the change is broken! Wasn't there a test case for the above
scenario?

Matt Kruse

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: IRC

2009-12-21T20:18:01Z

#jquery-dev isn't very active - amusingly the most active place for
jQuery dev discussion is #jquery-ot (for off-topic discussion). I hang
out in there a bunch as does a bunch of people who make the yayQuery
podcast, and others interested in jQuery.

Although, I'm sure they'll try to kneecap me now for mentioning that
the channel exists.

Naturally #jquery is still the best place for general Q&A.

--John

On Mon, Dec 21, 2009 at 10:14 PM, Julian Aubourg
<aubourg.julian@...> wrote:

> I know, it'll sound silly but I've been hanging in the jquery-dev chan for
> some time now and nobody talks :P
>
> Or am I being modded by Chanserv?
>
> --
>
> 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@....
> To unsubscribe from this group, send email to
> jquery-dev+unsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>

Bug in jQuery.val() in beta 1.4a2

2009-12-21T19:21:28Z

Hi,

I have found a bug in the jQuery.val() function. When you are trying
to set the value of a select to a particular value, jQuery goes
through all of the options in the list and checks their value and text
properties for the passed value, checking the matched item. In jQuery
1.4, this looks like it has been optimized from the following in
jQuery 1.3.2 on line 471:

this.selected = (jQuery.inArray( this.value, values ) >= 0 ||
jQuery.inArray( this.text, values ) >= 0);

to the following in jQuery 1.4:

this.selected = jQuery.inArray( this.value || this.text, values )
>= 0;

This does a single lookup which is great but you get very different
results. For example, I might have an option with a different value
property than the display text. For example:

<option value="lbs">pounds</option>

In jQuery 1.3 I could set the selected option with either:

$("select").val("lbs");
or:
$("select").val("pounds");

However jQuery 1.4 used the first found property (value or text) and
doesn't search both. So using my example, the following would work:

$("select").val("lbs");
but not:
$("select").val("pounds");

because both properties are found, and only the first one is searched.

I can see why this optimization was done, but I think that this will
cause problems for a lot of people!

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-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

IRC

2009-12-21T19:14:43Z

I know, it'll sound silly but I've been hanging in the jquery-dev chan for some time now and nobody talks :P

Or am I being modded by Chanserv?

Re: jQuery 1.4 $.param demystified

2009-12-21T18:58:26Z

I forgot to mention, I can put together a patch for 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-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: jQuery 1.4 $.param demystified

2009-12-21T18:56:29Z

> Does this mean that the default mechanism now changed, so that code
> which used to work will silently start failing?

Yeah, I have some concerns about this. It's great to have $.param
facilitate PHP-friendly serialization, but I'd like to see the default
reversed to avoid breaking existing code.

> The argument that "this helps PHP" could be countered by "this hurts
> java servlets", where request.getParameterValues("a") already returns
> an array for a (as in jQuery < 1.4), but needs to change for jQuery
> 1.4.

This also breaks existing server ASP code, which already understands
that multiple params with the same name should be turned into an
array.

Just another thought here; the flag being added is global, but it's
quite possible a page may be communicating with different hosts that
have different requirements. If different plugins have different needs
then it could get really messy having them bang around the same global
flag.

Either as an alternative or addition to a global flag, .ajaxSettings,
the .ajax() options parameter, .param(), .serialize() and
serializeArray() could support an optional argument to decide how to
serialize the data.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: jQuery require and script loaders

2009-12-21T18:23:31Z

OK, so I finally got time to write some docs & unit tests for my own baby... and here comes Dominoes:
http://code.google.com/p/javascript-dominoes/

See the Wiki pages to get an idea of what it is capable of (quite the wall of text there but heh).

It is more of a general purpose "scheduler" and provides some nice features like property expansion, global dependency rules, etc, etc. It is browser agnostic in the spirit of sizzle.

Only 4kB minified but the google compiler breaks the code (I didn't have time to investigate why).

2009/12/21 John Resig <jeresig@...>

Hi James -

There's definitely room for collaboration here. As I mentioned in the
comments on the commit I'm planning on holding off on jQuery.require()
until post-1.4 so that we can really get it right and hopefully
standardize a bit. I'll ping you again after the 1.4 dust has settled
and we can discuss it some more.

--John

On Wed, Dec 16, 2009 at 7:16 PM, James Burke <jrburke@...> wrote:
> I heard about the jQuery require that is shown as part of this
> changeset:
> http://github.com/jquery/jquery/commit/998cb005fc378188b3bae319e391d1b7881b7ad2
>
> I work on Dojo's module loader, and have a new standalone (no other
> library dependency) script loader here:
> http://code.google.com/p/runjs/wiki/RunJs
>
> The goal is to keep RunJS compatible with the goals of CommonJS
> (avoiding globals mainly) but still allow for a module syntax that
> works well natively in the browser. It does not use XHR calls, just
> script tags. Works before page load and after page load.
>
> It also handles loading regular scripts that are not coded as modules:
>
> run(["some/script.js", "another/script.js"], function() {
> //This callback is fired when both scripts load
> });
>
> For scripts that do follow the module syntax and have dependencies, it
> properly traces the module dependencies and calls the module
> definition functions in the correct order.
>
> It would be ideal if more of the JS libraries started to standardize
> on a script loader. I am happy to work out changes to RunJS if jQuery
> might find it useful to use. For instance, the entry point does not
> have to be called run(), I am considering switching to script() since
> it handles general script loading and callbacks when scripts are
> loaded.
>
> It also might be good to pull out a script loader from the core jQuery
> library, if only to keep the separation of concerns easier to track.
> RunJS has plugins for i18n string bundle loading, and also can load
> text files (like HTML snippets) via async xhr, then inline those text
> files as part of a build process.
>
> But I may be misunderstanding the scope of jQuery's require. In any
> case, I just wanted to see if there was some common interest and if we
> might be able to coordinate our efforts.
>
> Thanks for your time,
> James Burke
>
> --
>
> 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@....
> To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
> 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-dev@....
To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: Re: too much recursion error - jQuery 1.4a2

2009-12-21T15:38:40Z

Thanks for the link Mike, I'll check in to this. I'm starting to
wonder if it has to do with the recent .one() rewrite.

--John

On Mon, Dec 21, 2009 at 6:33 PM, Mike Alsup <malsup@...> wrote:

>> Huh, haven't seen anything like this, off-hand. Do you have a page
>> that we can look at?
>
> http://dev.jquery.com/ticket/5688
>
> --
>
> 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@....
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
>
>
>

Re: too much recursion error - jQuery 1.4a2

2009-12-21T15:33:02Z

> Huh, haven't seen anything like this, off-hand. Do you have a page
> that we can look at?

http://dev.jquery.com/ticket/5688

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

Re: Re: unusual bug with .attr("size")

2009-12-21T15:26:49Z

That's not the right nightly file - the current nightly is here:
http://code.jquery.com/jquery-nightly.js

But even that is trailing a bit, the latest build is:
http://code.jquery.com/jquery-1.4a2.js

--John

On Mon, Dec 21, 2009 at 6:10 PM, weepy <jonahfox@...> wrote:

> I was using the nightly
>
> here's some HTML u can copy and paste to reproduce
>
> <script src='http://code.jquery.com/nightlies/jquery-nightly.js'></
> script>
> <div id=x></div>
> <p>This should log: 1,1,undefined, 40</p>
> <div id=output></div>
> <script>
> $().ready(function(){
> console.log($("#x").attr("size"))
> $("#x").attr("size", 40)
> console.log($("#x").attr("size"))
>
> console.log($("#x").attr("zize"))
> $("#x").attr("zize", 40)
> console.log($("#x").attr("zize"))
> })
> </script>
>
>
>
> On 21 Dec, 16:45, John Resig <jere...@...> wrote:
>> What version of jQuery 1.4? This sounds like an issue that was fixed in 1.4a2.
>>
>> --John
>>
>>
>>
>> On Mon, Dec 21, 2009 at 5:29 AM, weepy <jonah...@...> wrote:
>> > Worked with 1.3.2
>>
>> > now .attr("size") returns 1 whether it's been set or not
>>
>> > $("x").attr("size") => 1
>>
>> > $("x").attr("size", 40)
>>
>> > $("x").attr("size") => 1
>>
>> > and no attribute seems to appear on the element.
>>
>> > --
>>
>> > 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@....
>> > To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
>> > 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-dev@....
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
>
>
>

Re: unusual bug with .attr("size")

2009-12-21T15:10:15Z

I was using the nightly

here's some HTML u can copy and paste to reproduce

<script src='http://code.jquery.com/nightlies/jquery-nightly.js'></
script>
<div id=x></div>
<p>This should log: 1,1,undefined, 40</p>
<div id=output></div>
<script>
$().ready(function(){
console.log($("#x").attr("size"))
$("#x").attr("size", 40)
console.log($("#x").attr("size"))

console.log($("#x").attr("zize"))
$("#x").attr("zize", 40)
console.log($("#x").attr("zize"))
})
</script>

On 21 Dec, 16:45, John Resig <jere...@...> wrote:

> What version of jQuery 1.4? This sounds like an issue that was fixed in 1.4a2.
>
> --John
>
>
>
> On Mon, Dec 21, 2009 at 5:29 AM, weepy <jonah...@...> wrote:
> > Worked with 1.3.2
>
> > now .attr("size") returns 1 whether it's been set or not
>
> > $("x").attr("size") => 1
>
> > $("x").attr("size", 40)
>
> > $("x").attr("size") => 1
>
> > and no attribute seems to appear on the element.
>
> > --
>
> > 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@....
> > To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> > For more options, visit this group athttp://groups.google.com/group/jquery-dev?hl=en.

Re: too much recursion error - jQuery 1.4a2

2009-12-21T13:42:40Z

Links to test pages:

http://dl.dropbox.com/u/11686/bl/test-jQuery-1.4a1.html
http://dl.dropbox.com/u/11686/bl/test-jQuery-1.4a2.html

The pages are identical other than the version of jQuery they're
using. I stripped out all of the page content and extraneous
JavaScript. I still get a "too much recursion" error on line 1486 in
the error console when I use jQuery 1.4a2. The same page using jQuery
1.4a1 instantiates the tabs as expected.

Thanks,

Aaron

On Dec 21, 1:01 pm, John Resig <jere...@...> wrote:

> Huh, haven't seen anything like this, off-hand. Do you have a page
> that we can look at?
>
> --John
>
> On Mon, Dec 21, 2009 at 3:03 PM, Aaron <floo...@...> wrote:
> > I'm using jQuery 1.4a2 with jQuery UI 1.7.2. Creating tabs worked with
> > jQuery 1.3.2 as well as 1.4a1. Attempting to run $('#tabs').tabs()
> > with 1.4a2 results in a 'too much recursion' error. I'm not doing
> > anything fancy - just instantiating the tabs with a couple options.
> > Firebug reports the problem is on line 1486 in the Proxy function,
> > though I don't know enough about the internals of jQuery to verify if
> > this is indeed the case.
>
> > Has anyone else experienced this issue or does anyone have an idea of
> > what might be going on?
>
> > --
>
> > 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@....
> > To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> > For more options, visit this group athttp://groups.google.com/group/jquery-dev?hl=en.