Re: [jQuery] jQuery 1.1 by the end of Nov

[Alan Gutierrez]

This is a very clever approach to what will become a serious problem
for jQuery, the management of dependencies.

Playing around with YUI and YUI ext, it seems like to use a
signicant control like the grid, you must include huge swath of each
library, but not the entirety. The time it takes to figure out what
you need, exactly, would be better spent coding. Upgrades that
require new components will appear as bugs, and not dependency errors.

What drives the adoption of langages like Perl and now Ruby is the
ability to evaulate a new package quickly, and that is done by
pulling all the dependencies automatically.

A convention about plugins that runs the gambit from runtime
inclusion to deployment dependencies, with a jQuery Repository of
plugins, is an investment that pay for itself in new adoptees.

The trade off of speed versus size is ancient. There is no good
answer. It either leans toward speed or leans toward size...

..or else it leans toward tools. You could use a preprocessors and
choose between algorithms.

* Paul McLanahan <[EMAIL PROTECTED]> [2006-11-17 10:23]:
> Agreed.  We need two new standards.
> 
> 1. @requires in the docs format, which would only require a change in
> the API generating code to have it look for that (if it doesn't
> already).
> 2. A standard way and convention for specifying version numbers for
> plugins which can be read by the docs, and preferably by the JS
> itself.
> 
> I'd like for the version to have a standard location and convention in
> the code of the plugin so that I can throw an error in my plugin if
> the dev has made a mistake by including an old plugin (or none at
> all).  I'd rather alert during development, then have an obscure bug
> show up in production.  I suggest something like:
> 
> // inside block context
> var plugin = $.fn.myPlugin = function(){
> return this.each(...);
> }
> plugin.version = '0.0.1';
> 
> or
> 
> jQuery.fn.myPlugin = function(){
> arguments.callee.version = '0.0.1';
> return this.each(...);
> }
> 
> Having it in the documents comments would be good as well so it can
> show on sites like visualjquery.com... but I think it would be quite
> advantageous to be able to require version 0.0.1+ in the code. Though,
> we would need a function to check version depending on the agreed upon
> version numbering scheme.
> 
> I also agree with the recommended/custom approach for the download.
> People with the tools and knowledge are doing this now with the build
> system. Copying that system online (much like Corey did earlier in the
> thread) would be an excellent way for those with special needs for
> bandwidth or functionality to get their wish without having to install
> ant. Don't have the system on the download page, but have it linked
> from there.
> 
> On 11/17/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
> > Jörn Zaefferer wrote:
> > >> jQuery documentation should clearly illustrate which base / core
> > >> jQuery is required and dependencies should be illustrated in a
> > >> clear manor.  I think the php pear site exemplifies this, i think
> > >> this is mostly covered but could be a touch clearer.
> > >
> > > PHP PEAR is a bad example: In most cases you won't care about 5 or 50
> > > additonal php files on your server, but you can't do this with js
> > > files.
> > >
> > > I think the recommended/custom way is a good approach: API
> > > documentation and tutorials are all written with the recommended
> > > version as their base.
> > >
> > > When a single plugin has dependencies on another plugin, it must be
> > > explicitly stated somewhere. A package/requires system that
> > > automatically resolves those dependencies would be nice, but I don't
> > > think this should have a high priority.
> >
> > I would agree with Jörn, and expand that I think we need to require
> > plugins include a:
> >
> > @Requires: blahblah.js[, version: 29+]
> > @Requires: morestuff.js
> >
> > We are rapidly getting a large number of plugins and more and more of
> > them seem to be using other plugins which is really good. This will help
> > users figure out what plugins and versions they might need and it will
> > supply the info needed for some future package system to figure this out
> > also.

-- 
Alan Gutierrez - 504 717 1428 - [EMAIL PROTECTED] - http://blogometer.com/
Think New Orleans - http://thinknola.com/

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Klaus Hartl]

Paul McLanahan schrieb:
> Agreed.  We need two new standards.
> 
> 1. @requires in the docs format, which would only require a change in
> the API generating code to have it look for that (if it doesn't
> already).
> 2. A standard way and convention for specifying version numbers for
> plugins which can be read by the docs, and preferably by the JS
> itself.

Totally agreed! I couldn't even tell myself in another thread how to 
determine the version of the Tabs plugin :-)


-- Klaus

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Brandon Aaron]

On 11/17/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
> I would agree with Jörn, and expand that I think we need to require
> plugins include a:
>
> @Requires: blahblah.js[, version: 29+]
> @Requires: morestuff.js
>
> We are rapidly getting a large number of plugins and more and more of
> them seem to be using other plugins which is really good. This will help
> users figure out what plugins and versions they might need and it will
> supply the info needed for some future package system to figure this out
> also.

We are also getting a fair amount of revisions to jQuery. Plugins will
need to be very explicit about what version they are compatible with.

--
Brandon Aaron

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Paul McLanahan]

Agreed.  We need two new standards.

1. @requires in the docs format, which would only require a change in
the API generating code to have it look for that (if it doesn't
already).
2. A standard way and convention for specifying version numbers for
plugins which can be read by the docs, and preferably by the JS
itself.

I'd like for the version to have a standard location and convention in
the code of the plugin so that I can throw an error in my plugin if
the dev has made a mistake by including an old plugin (or none at
all).  I'd rather alert during development, then have an obscure bug
show up in production.  I suggest something like:

// inside block context
var plugin = $.fn.myPlugin = function(){
return this.each(...);
}
plugin.version = '0.0.1';

or

jQuery.fn.myPlugin = function(){
arguments.callee.version = '0.0.1';
return this.each(...);
}

Having it in the documents comments would be good as well so it can
show on sites like visualjquery.com... but I think it would be quite
advantageous to be able to require version 0.0.1+ in the code. Though,
we would need a function to check version depending on the agreed upon
version numbering scheme.

I also agree with the recommended/custom approach for the download.
People with the tools and knowledge are doing this now with the build
system. Copying that system online (much like Corey did earlier in the
thread) would be an excellent way for those with special needs for
bandwidth or functionality to get their wish without having to install
ant. Don't have the system on the download page, but have it linked
from there.

On 11/17/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
> Jörn Zaefferer wrote:
> >> jQuery documentation should clearly illustrate which base / core
> >> jQuery is required and dependencies should be illustrated in a
> >> clear manor.  I think the php pear site exemplifies this, i think
> >> this is mostly covered but could be a touch clearer.
> >
> > PHP PEAR is a bad example: In most cases you won't care about 5 or 50
> > additonal php files on your server, but you can't do this with js
> > files.
> >
> > I think the recommended/custom way is a good approach: API
> > documentation and tutorials are all written with the recommended
> > version as their base.
> >
> > When a single plugin has dependencies on another plugin, it must be
> > explicitly stated somewhere. A package/requires system that
> > automatically resolves those dependencies would be nice, but I don't
> > think this should have a high priority.
>
> I would agree with Jörn, and expand that I think we need to require
> plugins include a:
>
> @Requires: blahblah.js[, version: 29+]
> @Requires: morestuff.js
>
> We are rapidly getting a large number of plugins and more and more of
> them seem to be using other plugins which is really good. This will help
> users figure out what plugins and versions they might need and it will
> supply the info needed for some future package system to figure this out
> also.
>
> -Steve
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
>

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Stephen Woodbridge]

Jörn Zaefferer wrote:
>> jQuery documentation should clearly illustrate which base / core
>> jQuery is required and dependencies should be illustrated in a
>> clear manor.  I think the php pear site exemplifies this, i think
>> this is mostly covered but could be a touch clearer.
> 
> PHP PEAR is a bad example: In most cases you won't care about 5 or 50
> additonal php files on your server, but you can't do this with js
> files.
> 
> I think the recommended/custom way is a good approach: API
> documentation and tutorials are all written with the recommended
> version as their base.
> 
> When a single plugin has dependencies on another plugin, it must be
> explicitly stated somewhere. A package/requires system that
> automatically resolves those dependencies would be nice, but I don't
> think this should have a high priority.

I would agree with Jörn, and expand that I think we need to require 
plugins include a:

@Requires: blahblah.js[, version: 29+]
@Requires: morestuff.js

We are rapidly getting a large number of plugins and more and more of 
them seem to be using other plugins which is really good. This will help 
users figure out what plugins and versions they might need and it will 
supply the info needed for some future package system to figure this out 
also.

-Steve

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> jQuery documentation should clearly illustrate which base / core jQuery is
> required and dependencies should be illustrated in a clear manor.  I think
> the php pear site exemplifies this, i think this is mostly covered but
> could be a touch clearer.

PHP PEAR is a bad example: In most cases you won't care about 5 or 50 additonal 
php files on your server, but you can't do this with js files.

I think the recommended/custom way is a good approach: API documentation and 
tutorials are all written with the recommended version as their base.

When a single plugin has dependencies on another plugin, it must be explicitly 
stated somewhere. A package/requires system that automatically resolves those 
dependencies would be nice, but I don't think this should have a high priority.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Sam Sherlock]

I'm sort of stuck because I really need both.




thats the eternal trade off of development.  In the end you hope to achieve
a happy medium

as a project evolves the overall size of media/scripts/css etc tends to
grow, and can get out of hand
Some one earlier mentioned something akin to standard software installation

eg a recommended install & and customisable install (for experienced users
who know what their doing)

I recall a professor saying about software

80% of users use 20% of the software


being able to pick n choose included features and pack them into a bespoke
file is vital - which bits are used is variable - some people will be drawn
to animation for others the allure of xml dom etc will draw them to jQuery

Can jQuery plugins test for the existence of a plugin (within a site)? may
be I am being wacky :)
I was thinking that the new jQuery button could have a
class="jQueryPromoBttn" and clicking the image could demonstrate the ability
of jQuery - a div fading up in the corner of the page for example.

jQuery documentation should clearly illustrate which base / core jQuery is
required and dependencies should be illustrated in a clear manor.  I think
the php pear site exemplifies this, i think this is mostly covered but could
be a touch clearer.



On 16/11/06, Paul McLanahan <[EMAIL PROTECTED]> wrote:


I'm sort of stuck because I really need both. Speed is great and if it
were up to only me then I would agree with you guys about the
priority.  But I work for a company who hosts and maintains nearly
1500 sites.  If we adopt a JS library, file size is a large factor in
our decision due purely to the bandwidth costs.  We get hate-email
from our server guys and our VPs if file sizes go up too much;
especially because of something they see as peripheral like
javascript. A couple K means a lot to us when multiplied by the number
of daily visits we serve. I'll tell you that file size of the packed
library file was a large factor in our choosing jQuery over Prototype
for a base js library for our new sites. The other factor being of
course that it rules.

Just a thought,

Paul

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Paul McLanahan]

I'm sort of stuck because I really need both. Speed is great and if it
were up to only me then I would agree with you guys about the
priority.  But I work for a company who hosts and maintains nearly
1500 sites.  If we adopt a JS library, file size is a large factor in
our decision due purely to the bandwidth costs.  We get hate-email
from our server guys and our VPs if file sizes go up too much;
especially because of something they see as peripheral like
javascript. A couple K means a lot to us when multiplied by the number
of daily visits we serve. I'll tell you that file size of the packed
library file was a large factor in our choosing jQuery over Prototype
for a base js library for our new sites. The other factor being of
course that it rules.

Just a thought,

Paul

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Andy Matthews]

I'll agree with that as well. These days, a few extra K is nothing. I'd much
rather have it be blazing fast, even at the cost of it's ultra-lightweight
file size.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Matthew Delmarter
Sent: Thursday, November 16, 2006 1:28 PM
To: 'jQuery Discussion.'
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov


I agree - speed is probably my main concern, not a few Kb file size.

Regards,

Matthew


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Aaron
> Sent: Friday, 17 November 2006 8:24 a.m.
> To: jQuery Discussion.
> Subject: Re: [jQuery] jQuery 1.1 by the end of Nov
>
> On 11/16/06, Dave Methvin <[EMAIL PROTECTED]> wrote:
> > > The only thing I disagree with is the importance of
> winning the size war.
> >
> > Up to this point all the emphasis has been on code size. At
> some point
> > we may want to look at speed, even if it makes the code
> bigger. One example:
> > When you say $(".myclass") the following things happen:
>
> I'm glad to see speed being brought up!
>
> --
> Brandon Aaron
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
>


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Chris W. Parker]

On Thursday, November 16, 2006 11:28 AM Matthew Delmarter <> said:

> I agree - speed is probably my main concern, not a few Kb file size.

But consider that for the "average" (I'm making an assumption as to what
average is) website that utilizes jQuery they will probably be impacted
more by page weight rather than by the efficiency of the code. My intent
is just to point out why file size is important in this world of js
frameworks.

But having said that I'm all for optimization. 100%.



Chris.

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Matthew Delmarter]

I agree - speed is probably my main concern, not a few Kb file size.

Regards,

Matthew
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Aaron
> Sent: Friday, 17 November 2006 8:24 a.m.
> To: jQuery Discussion.
> Subject: Re: [jQuery] jQuery 1.1 by the end of Nov
> 
> On 11/16/06, Dave Methvin <[EMAIL PROTECTED]> wrote:
> > > The only thing I disagree with is the importance of 
> winning the size war.
> >
> > Up to this point all the emphasis has been on code size. At 
> some point 
> > we may want to look at speed, even if it makes the code 
> bigger. One example:
> > When you say $(".myclass") the following things happen:
> 
> I'm glad to see speed being brought up!
> 
> --
> Brandon Aaron
> 
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
> 


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Brandon Aaron]

On 11/16/06, Dave Methvin <[EMAIL PROTECTED]> wrote:
> > The only thing I disagree with is the importance of winning the size war.
>
> Up to this point all the emphasis has been on code size. At some point we
> may want to look at speed, even if it makes the code bigger. One example:
> When you say $(".myclass") the following things happen:

I'm glad to see speed being brought up!

--
Brandon Aaron

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Christof Donat]

Hi,

>  * jQuery.find recursively collects every node in the document
> tree and copies that list into a second array;
>  * jQuery.filter builds/compiles a regexp to get the class name,
> then builds/compiles a function to check the class name;
>  * jQuery.grep calls that function once for each element;
>  * That function calls jQuery.class.has, which builds/compiles
> a regexp to see if the class matches.

Just a suggestion: jQuery.class.has could take a regular expression as an 
optional argument. In case it is given, it can be used to see if the class 
matches.

How I would do all of that with speed in mind:

$('.classname')
  -> create a regular Expresion to compare the class
  -> walk regursively through all Elements on the page and use the regular 
 expression to check if the class matches
  -> if an Element matches, add it to the return-array

draft:

function traverse(element,callback) {
var rval = [];
if( callback.apply(element,[]) ) rval.push(element);
for( var i = 0; i < element.childNodes.length; i++ )
if( element.childNodes[i].nodeType == 1 ) 
rval.concat(traverse(element.childNodes[i],callback));
return rval;
}

$ = function(param) {
if( /^[#][a-zA-Z][a-zA-Z0-9]*$/.test(param) )
return [document.getElementById(param.substr(1))];
if( /^[a-zA-Z][a-zA-Z0-9]*$/.test(param) )
return document.getElementsByTagName(param);
if( /^[.][a-zA-Z][a-zA-Z0-9]*$/.test(param) ) {
var checkclass = param.substr(1);
checkclass = Regexp
( '^'+checkclass+'$|^'+checkclass+' | '+checkclass+' | 
'+checkclass'+$ );

return traverse(document,function() {
return checkclass.test(this.className);
});
}
// ...
}

Of course this is not fully functional, but the idea should be clear.

Christof

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Corey Jewett]

Glad to hear it worked for somebody. This is really just a  
repurposing of the existing build system. It uses the same packing  
routines as the current build does.

If John wants to move it over to the main site I'd be more than happy  
to at least have it out there as another option.

Corey


On Nov 16, 2006, at 6:35 AM, Karl Swedberg wrote:

> On Nov 15, 2006, at 4:26 AM, Corey Jewett wrote:
>
>> Just throwing a little fuel on the fire. If anybody cares give this a
>> whirl -- build your own custom jQuery.
>>
>> Maybe I'll figure out how to do plugins if anyone is interested.
>>
>> http://corey.jquery.com/cgi-bin/make.cgi
>>
>> Corey
>
> Corey,
>
> that is a very cool tool. what a great one-stop shop for jQuery
> developers to build their source! Especially useful, I'm sure, for
> people who can't access SVN because of firewall restrictions.
>
> Just for kicks, I built 1.0.3 with no additional core fragments in
> "Lite" mode, which removes /* */ comments. Then I stripped out all
> single-line comments and empty lines. With the introductory licensing
> comments still included, the file came to 838 lines of code and 28k
> -- uncompressed!
>
> Cheers,
> Karl
> ___
> Karl Swedberg
> www.englishrules.com
> www.learningjquery.com
>
>
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Dave Methvin]

> The only thing I disagree with is the importance of winning the size war.

Up to this point all the emphasis has been on code size. At some point we
may want to look at speed, even if it makes the code bigger. One example:
When you say $(".myclass") the following things happen:

 * jQuery.find recursively collects every node in the document
tree and copies that list into a second array;
 * jQuery.filter builds/compiles a regexp to get the class name,
then builds/compiles a function to check the class name;
 * jQuery.grep calls that function once for each element;
 * That function calls jQuery.class.has, which builds/compiles
a regexp to see if the class matches.

The last step is in an inner loop, so it really hurts. For a document with
1000 elements, the (nested) call to jQuery.class.has compiles the same
regexp 1000 times! Special-case handlers can hoist that out of the loop and
simplify the code paths significantly, but it adds more code. Plus you have
to decide how many special cases you want to optimize. Are lone classes and
ids enough? If so, something like this may do it.

var m = selector.match(/^(\w*|\*?)\.(\w+)$/;
if ( m ) {
  var els = context.getElementsByTagName(m[1]||"*");
  var pat = new RegExp("(^|\\s)" + m[2] + "(\\s|$)"); 
  for ( var i=0; i < els.length; i++ )
 if ( pat.test(els[i].className)
   ret.push(els[i]);
  return ret;
}
var m = selector.match(/^#(\w+)$/);
if ( m && context == document ) {
  var el = document.getElementById(m[1]);
  return el? [ el ] : [];
}


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Alex Cook]

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Jörn Zaefferer"
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov

With the above at hand, do we really need all those shortcuts or macrso 
anymore? By using on(), un(), trigger(), css() and attr() the API is pretty 
clean and easy to learn, and the different in necessary code to type is 
minimal. And it's still extremely easy to write your own macros if needed.

--
Jörn Zaefferer

--

I'd second this.  I tend to use .bind, .attr, and .css more then the macros 
myself, so this would be peachy for me.  I'm not sure if it's the way I learned 
jQuery or what, but those functions are pretty simple to learn and have just 
stuck with me.

-ALEX

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Alex Cook]

On Nov 15, 2006, at 4:26 AM, Corey Jewett wrote:

> Just throwing a little fuel on the fire. If anybody cares give this a
> whirl -- build your own custom jQuery.
>
> Maybe I'll figure out how to do plugins if anyone is interested.
>
> http://corey.jquery.com/cgi-bin/make.cgi
>
> Corey

That's exactly the type of system I had in mind.  Well done Corey.

-ALEX


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Dave Methvin]

> So what?
>
> Rename bind() to on(), unbind() to un()? What about trigger?
> Leave it?

I would vote for all of that, with a compat plugin of course.

> Would you rather screw shortcuts like click() completely? 
> on("click", function) isn't that much longer then click(function)
> anyway. It would help removing any ambiguity: on("unload")
> is pretty clear, un("load") too.

I think it's more confusing to have an exception for .click than to just use
.on("click", fn) but I'm not fanatic about it.

> With the above at hand, do we really need all those shortcuts
> or macros anymore? By using on(), un(), trigger(), css() and
> attr() the API is pretty clean and easy to learn, and the
> different in necessary code to type is minimal. And it's still
> extremely easy to write your own macros if needed.

>From John's last post it sounded like they were already on their way out. It
will be interesting to see how much code that saves. It certainly is going
to simplify the documentation by a factor of two or three.




___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Karl Swedberg]

On Nov 16, 2006, at 11:02 AM, Michael Geary wrote:

> .on() sounds like a winner to me. Not sure about .un(), but I don't  
> have a
> better idea - and .un() is certainly better than .no().
>
>> To me, click is a verb and it's not intuitive to be setting a
>> click handler with the word click.
>
> Same here. Especially when the function is overloaded so that .click 
> () [with
> no args] *is* a verb, i.e. it triggers the click event. Nasty!

Well, that all makes sense to me. Glad to hear that hover() and toggle 
() will stay, though. Thanks, guys.

Karl
___
Karl Swedberg
www.englishrules.com
www.learningjquery.com


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> > I am not a fan of "bind" either, I'm sure it was inherited 
> > from the other frameworks that use it. I would prefer .on() 
> > and .un() (or perhaps .no()? ) because they're short and a 
> > bit more intuitive.
> 
> .on() sounds like a winner to me. Not sure about .un(), but I don't have a
> better idea - and .un() is certainly better than .no().
> 
> > To me, click is a verb and it's not intuitive to be setting a 
> > click handler with the word click. 
> 
> Same here. Especially when the function is overloaded so that .click()
> [with
> no args] *is* a verb, i.e. it triggers the click event. Nasty!

So what?

Rename bind() to on(), unbind() to un()? What about trigger? Leave it?

Would you rather screw shortcuts like click() completely? on("click", function) 
isn't that much longer then click(function) anyway. It would help removing any 
ambiguity: on("unload") is pretty clear, un("load") too.

With the above at hand, do we really need all those shortcuts or macrso 
anymore? By using on(), un(), trigger(), css() and attr() the API is pretty 
clean and easy to learn, and the different in necessary code to type is 
minimal. And it's still extremely easy to write your own macros if needed.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Michael Geary]

> > But, I would be sad to see .click, .hover,  and .toggle go away, if 
> > they are among the "helper" functions you plan to put into a an 
> > external plugin. They just make so much more sense than "bind" to 
> > people new to programming/javascript/jQuery.

> I am not a fan of "bind" either, I'm sure it was inherited 
> from the other frameworks that use it. I would prefer .on() 
> and .un() (or perhaps .no()? ) because they're short and a 
> bit more intuitive.

.on() sounds like a winner to me. Not sure about .un(), but I don't have a
better idea - and .un() is certainly better than .no().

> To me, click is a verb and it's not intuitive to be setting a 
> click handler with the word click. 

Same here. Especially when the function is overloaded so that .click() [with
no args] *is* a verb, i.e. it triggers the click event. Nasty!

-Mike


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> I understand the desire for small file size. I think it would be nice  
> if all of the un- and one- events could instead be put into an  
> argument or something like that instead of having a separate function  
> for each one.
> 
> But, I would be sad to see .click, .hover,  and .toggle go away, if  
> they are among the "helper" functions you plan to put into an  
> external plugin. They just make so much more sense than "bind" to  
> people new to programming/javascript/jQuery.

I'd strip all those shortcuts and add a little macro function. The default 
built would call that function with, say, click. Hover and toggle are special 
cases anyway that don't use bind directly, they shouldn't be removed.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Dave Methvin]

> But, I would be sad to see .click, .hover,  and .toggle go away, 
> if they are among the "helper" functions you plan to put into a
> an external plugin. They just make so much more sense than
> "bind" to people new to programming/javascript/jQuery.

I am not a fan of "bind" either, I'm sure it was inherited from the other
frameworks that use it. I would prefer .on() and .un() (or perhaps .no()? )
because they're short and a bit more intuitive.

To me, click is a verb and it's not intuitive to be setting a click handler
with the word click. 

Since .hover and .toggle are not simple mapping of events they have to stay,
or at least be handled some way other than bind.


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Karl Swedberg]

On Nov 15, 2006, at 4:26 AM, Corey Jewett wrote:

> Just throwing a little fuel on the fire. If anybody cares give this a
> whirl -- build your own custom jQuery.
>
> Maybe I'll figure out how to do plugins if anyone is interested.
>
> http://corey.jquery.com/cgi-bin/make.cgi
>
> Corey

Corey,

that is a very cool tool. what a great one-stop shop for jQuery  
developers to build their source! Especially useful, I'm sure, for  
people who can't access SVN because of firewall restrictions.

Just for kicks, I built 1.0.3 with no additional core fragments in  
"Lite" mode, which removes /* */ comments. Then I stripped out all  
single-line comments and empty lines. With the introductory licensing  
comments still included, the file came to 838 lines of code and 28k  
-- uncompressed!

Cheers,
Karl
___
Karl Swedberg
www.englishrules.com
www.learningjquery.com



___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Karl Swedberg]

On Nov 15, 2006, at 12:32 AM, John Resig wrote:

> I definitely agree. I'm going to propose this course of action:
>
> 1) Strip out all "helper" functions into an external plugin.
> 2) Change the official (in SVN) plugins to no longer use the helpers.
> 3) Change all docs to no longer use the helpers.
>
> This will clear up documentation and reduce the filesize (win-win!)

I understand the desire for small file size. I think it would be nice  
if all of the un- and one- events could instead be put into an  
argument or something like that instead of having a separate function  
for each one.

But, I would be sad to see .click, .hover,  and .toggle go away, if  
they are among the "helper" functions you plan to put into an  
external plugin. They just make so much more sense than "bind" to  
people new to programming/javascript/jQuery.

  Just my $.02

Karl

___
Karl Swedberg
www.englishrules.com
www.learningjquery.com


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[agent2026]

Hey, if 'mine's smaller' is important to you...

:)

Adam



malsup wrote:
> 
> Great input, Adam.  Stay out of lurk mode.
> 
> The only thing I disagree with is the importance of winning the size war.
> 
> Mike
> 
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
> 
> 

-- 
View this message in context: 
http://www.nabble.com/jQuery-1.1-by-the-end-of-Nov-tf2631987.html#a7378726
Sent from the JQuery mailing list archive at Nabble.com.


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Mike Alsup]

Great input, Adam.  Stay out of lurk mode.

The only thing I disagree with is the importance of winning the size war.

Mike

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[agent2026]

John Resig wrote:
> 
> I third this.
> 
> While the main "package" will be a little bit heftier, I think it'll
> be much more beneficial (and saner to answer questions, in general).
> 
> --John
> 


I'll even pop out of lurk mode to join this camp.  I think your main sell
should be the full package.  After this I would prefer to see something
along the lines of an online 'standard install' vs 'custom install' screen
similar to application install dialogs.  This gives those with less/no
experience a chance to peek into the custom options, get scared because they
don't understand them, then go back to safety of the 'standard install'. 
Customizers can then choose what they want:

[grayed out check box, checked] - Core

[live check box, checked] - Ajax

[live check box, checked] - FX

[live check box, checked] - Helper Functions Bundle


Now, don't forget the title of this thread as well.  All this multiple,
custom, pre-packaged, bundle talk seems pretty likely to blow your suggested
deadline out of the water.  Add holidays, new year, plus the amount of work
required and my guess is you looking at Q1 2007, or even Q2.  Keep it
simple, make it better, streamline it, keep it updated - leave the drastic
changes for 2.0.  Apple vs Dell, as someone said.

As for size, 20K is sort of the magic number for me.  With the power jQuery
provides I'd easily go to 25K, so I'm along the lines of 'better product
justifies a few more bytes' and wouldn't worry so much about 'beating the
other guys' in file size.  Maybe you can justify stripping out the helper
functions, but sometimes some basics are nice to have - like the simple
browser check.

I'm fairly new to jQuery, and I can tell you one of the best things about it
is that whenever a new challenge arises for me, or even a basic function, I
say to myself 'I bet I can do that with jQuery'.  I would hate to see that
disappear in a sea of requirements for different packages and plugins.


Adam

-- 
View this message in context: 
http://www.nabble.com/jQuery-1.1-by-the-end-of-Nov-tf2631987.html#a7375528
Sent from the JQuery mailing list archive at Nabble.com.


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[John Resig]

> I could probably do a run through of the code and
> reduce the size of the download by a couple hundred KB, no problem.

couple hundred BYTES! That'd be one heck of an optimization!

--John

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[John Resig]

> Personally, 19k is tiny to me compared to the others out there.  Even 25k
> would be tiny still.  However, I think the form handling is something that
> makes sense to rely on a plugin.

My personal goal for jQuery is to have it be smaller in size
(compressed) than Prototype (compressed) and MooTools (compressed).

These are the current numbers:

Prototype:
19239 bytes (1.4.0)
25393 bytes (1.5.0_rc1)

MooTools (with Function, Array, String, Element, Fx, Dom, Ajax,
Window, Fxpack, Fxutils, and Fxtransitions selected):
19128 bytes (rev 83)

jQuery:
19019 bytes (1.0.3)
19098 bytes (SVN)

As you can see, jQuery's size is getting really close to Prototype
1.4.0 and Mootools. I could probably do a run through of the code and
reduce the size of the download by a couple hundred KB, no problem.
Just squeezing beyond that point will require that something be
removed.

--John

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[John Resig]

> > Fully agree! Providing a full release for newbies and as reference
> > for documentation on the one hand and a custom build for further
> > needs should be just fine. As soon as you are familiar enough with
> > jQuery tp use the custom build, you won't worry about missing methods
> > referenced in the documentation because you removed them on your own.
>
> I second that.

I third this.

While the main "package" will be a little bit heftier, I think it'll
be much more beneficial (and saner to answer questions, in general).

--John

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> What exactly do you mean when you say the handler doesn't know which 
> argument is passed via trigger versus bind? Can you give me an example 
> of this so I can better understand the problem?

I try. I take my tooltip plugin as an example, because I can avoid binding 
stuff to DOM elements.

Currently, the individual tooltip settings are saved as a property on each 
tooltipped element:
.each(function() {
this.tSettings = settings;
})

That is ugly and may leak memory. Therefore I'd change to current bind to pass 
the settings:
.bind(mouseover, handle, settings);

Inside my "handle" function, I could now access the settings, and change this:
handle = function(event) {
if( this.tSettings.delay ) [...]

to:
handle = function(event, settings) {
if( settings.delay ) [...]

So far so good, but now I have an additional requirement: I need to trigger the 
handle event when I want to display the tooltip, eg. to display a message for 
an invalid form element. Because the event's mouse position can't be used to 
position the element, I need to pass an additional argument to indicate the 
position where the tooltip should appear.

Something like this:
$(invalidElement).trigger("mouseover", objectWithPositionInformation);

To rewrite my handler:
handle = function(event, settings, triggerOption) { ...

Now what if the handler is used with another event, and no "settings" is 
passed? How to decide what inside which parameter?

I'd prefer a solution where this question is absolutely clear. One solution 
would be to put that data into the event object:

handle = function(event) {
  // use event.bind to access settings, use event.trigger to access 
triggerOption...

The big drawback: That additional data has to be cleared after the handler was 
executed to prevent memory leaks. But that can pose a problem when the data is 
accessed inside a closure...

I hope that makes the problem clear. Any ideas?

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Blair Mitchelmore]

What exactly do you mean when you say the handler doesn't know which 
argument is passed via trigger versus bind? Can you give me an example 
of this so I can better understand the problem?

-blair

Jörn Zaefferer wrote:
>> The way I coded the trigger and handle functions in my system it worked 
>> like this (or at least it should. This is untested but theoretically 
>> sound and the way I intended for it to work).
>>
>> $().click(fn1,arg1,arg2);
>> $().click(fn2,arg3,arg4);
>> // someone clicks there
>> // fn1 runs with arguments [event,arg1,arg2]
>> // fn2 runs with args [event,arg3,arg4]
>> $().trigger('click');
>> // fn1 runs with args [event,arg1,arg2]
>> // fn2 runs with args [event,arg3,arg4]
>> $().trigger('click',arg5,arg6);
>> // fn1 runs with args [event,arg1,arg2,arg5,arg6]
>> // fn2 runs with args [event,arg3,arg4,arg5,arg6]
>>
>> To me this is the least surprising result, would you agree?
>
> No. The general idea of passing arguments via trigger and bind is to 
> modularize code. Think of a big system where you can't rely on closures. Or 
> where you want to pass arguments to a plugin via trigger. The event handler 
> maybe implemented by the user, while the argument to bind are coming from 
> plugin code and may change.
>
> With your implementation, the handler had no idea how to identify which 
> argument was passed via bind and which via trigger, but that is important.
>
> --
> Jörn Zaefferer
>
> http://bassistance.de

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Chris W. Parker]

On Wednesday, November 15, 2006 9:47 AM "Jörn Zaefferer" <> said:

> Fully agree! Providing a full release for newbies and as reference
> for documentation on the one hand and a custom build for further
> needs should be just fine. As soon as you are familiar enough with
> jQuery tp use the custom build, you won't worry about missing methods
> referenced in the documentation because you removed them on your own.

I second that.

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Enrique Meléndez]

Ok , here goes my point of view:

My ideal Jquery first objectives are:

1. Writing Javascript code should be fun (CORE got it! Chainability, ...)
2. Resolve compatibility issues/behaviors with W3C Standards and browsers:
DOM, CSS + selectors, Javascript, XHTML, EVENTS and XMLHTTPRequest. So, for
that exist:
- DOM, 
- CSS [+ Dimensions plugin is included here as expected behavior], 
- EVENTS, 
- and little part of AJAX

but, please, avoiding redundances - just css(), attr(), bind(), etc.. - and
only CSS selectors... (trying to be written in an Standard way)

Above are ('problematic') features implemented in almost all browsers. So
that be part of the "lite" version.

Now new features, not implemented in main browsers at the same level (or at
all), which uses Jquery itself, in an "expanded" version:

1. Special selectors: XPath (working with XML), Customs,... 
2. Effects (animations)
3. Manipulating FORMS
4. Manipulating AJAX
4,5. Manipulating XML (AJAX+XPATH..??)??
5. shortcuts??? for css(), attr(), bind()
6. Plug-ins (in individual modules)

That's all, folks!

Enrique Meléndez Estrada



___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> I don't see why there can't be both.  
> 
> 'Hey, new to jQuery? Download this, take it for a spin, see what
> everyone is raving about!'
> 
> 'Developers, familiar with jQuery? Fine tune your build however you
> want, just click here...'
> 
> It's all about how we position the system and how we educate new users.

Fully agree! Providing a full release for newbies and as reference for 
documentation on the one hand and a custom build for further needs should be 
just fine. As soon as you are familiar enough with jQuery tp use the custom 
build, you won't worry about missing methods referenced in the documentation 
because you removed them on your own.

--
Jörn Zaefferer

http://bassistance.de

> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Tuesday, November 14, 2006 9:42 PM
> To: jQuery Discussion.
> Subject: Re: [jQuery] jQuery 1.1 by the end of Nov
> 
> I have to say I absolutely *hate* the "build your own" library thing.
> First, when trying a new library, I don't often know what I need, so I
> end up downloading one set of files (click, click, click) only to
> discover I needed something else (click, click, click, click) then two
> weeks later I want something ELSE (click, click, click, click, click).
> 
> I say, find a standard set of things that should be included in jquery
> (personally, I'd ditch the effects stuff, as they're so minimal it'd be
> better to just pawn those elsewhere) and focus on the expression engine.
> That's jquery's bread and butter.
> 
> One simple download link, and a nice page where developers can find
> plugins.
> 
> -----Original Message-
> From: Jason Yeckel <[EMAIL PROTECTED]>
> Sent: Wed, November 15, 2006 12:03 am
> To: jQuery Discussion. 
> Subject: Re: [jQuery] jQuery 1.1 by the end of Nov
> 
> I think over all do a mootools like download / interface jquery lib 
> download were the user can pick and choose components.
> 
> Just to be fair the only reason it has two was to make perl regex users 
> happy :) I do use the perl regex though lol.
> 
> 
> Jason Y
> www.purepressure.com
> 
> 
> dave.methvin wrote:
> > John Resig wrote:
> >   
> >> Right now, the jQuery compressed build is teetering around 18-19KB, I
> >> really want to try and cut this down. Any thoughts on particular
> >> features that should be extracted into a plugin?
> >>
> >> 
> > I know the macros don't account for _that_ much core code but they do
> > complicate the documentation significantly. We have nice short names
> like
> > .attr and .css yet those represent the most-macroed properties. Then
> we end
> > up with (justifiable IMO) situations where valuable names like
> .height() are
> > taken by the .css("height") macro to save five--count 'em--five
> characters.
> > The same goes for the event macros, I think they account for more than
> half
> > the names in the API documentation at this point and they end up
> creating
> > situations like .unload() that are pretty hard to explain.
> >
> > I would like to see jQuery take more of a Perl path than a PHP one,
> using a
> > small number of consistent and powerful concepts plus the ability to
> extend
> > things with plugins. Perl has one simple consistent regexp operator;
> PHP has
> > two completely different regexp engines, each served by a dozen or
> more
> > differently named functions.
> >
> >
> >   
> 
> 
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
> 
> 
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
> 
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Alex Cook]

I don't see why there can't be both.  

'Hey, new to jQuery? Download this, take it for a spin, see what
everyone is raving about!'

'Developers, familiar with jQuery? Fine tune your build however you
want, just click here...'

It's all about how we position the system and how we educate new users. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 9:42 PM
To: jQuery Discussion.
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov

I have to say I absolutely *hate* the "build your own" library thing.
First, when trying a new library, I don't often know what I need, so I
end up downloading one set of files (click, click, click) only to
discover I needed something else (click, click, click, click) then two
weeks later I want something ELSE (click, click, click, click, click).

I say, find a standard set of things that should be included in jquery
(personally, I'd ditch the effects stuff, as they're so minimal it'd be
better to just pawn those elsewhere) and focus on the expression engine.
That's jquery's bread and butter.

One simple download link, and a nice page where developers can find
plugins.

-Original Message-
From: Jason Yeckel <[EMAIL PROTECTED]>
Sent: Wed, November 15, 2006 12:03 am
To: jQuery Discussion. 
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov

I think over all do a mootools like download / interface jquery lib 
download were the user can pick and choose components.

Just to be fair the only reason it has two was to make perl regex users 
happy :) I do use the perl regex though lol.


Jason Y
www.purepressure.com


dave.methvin wrote:
> John Resig wrote:
>   
>> Right now, the jQuery compressed build is teetering around 18-19KB, I
>> really want to try and cut this down. Any thoughts on particular
>> features that should be extracted into a plugin?
>>
>> 
> I know the macros don't account for _that_ much core code but they do
> complicate the documentation significantly. We have nice short names
like
> .attr and .css yet those represent the most-macroed properties. Then
we end
> up with (justifiable IMO) situations where valuable names like
.height() are
> taken by the .css("height") macro to save five--count 'em--five
characters.
> The same goes for the event macros, I think they account for more than
half
> the names in the API documentation at this point and they end up
creating
> situations like .unload() that are pretty hard to explain.
>
> I would like to see jQuery take more of a Perl path than a PHP one,
using a
> small number of consistent and powerful concepts plus the ability to
extend
> things with plugins. Perl has one simple consistent regexp operator;
PHP has
> two completely different regexp engines, each served by a dozen or
more
> differently named functions.
>
>
>   


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> Even if it is 10-15 lines, it's still lines I, and most developers,
> will never ever use. jQuery should be for the everyday basics, and the
> plug-ins are there to extend the base.

The expression engine is the most important part about jQuery, and that provide 
more then just a single "right" way to solve things. Someone who was worked a 
lot with XML knows XPath very good, but may have no idea about CSS. By 
supporting both, jQuery could attract a much bigger audience.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Andre Lewis]

I think that when newcomers find JQ, their default experience should pretty inclusive, i.e., definitely Ajax and Effects. That way, people won't be frustrated by the "I saw it in the API but can't get it to work" factor, and will be more likely to continue on to discover more jQuery goodness.
How about something like this for the download page. Offer the two ends of the spectrum, and awareness that jQuery scales up and down. I'm making the specifics up, but you get the idea:== Getting Started? ==
Download jQuery Full Version, includes Ajax, Effects, etc . . . Size: 21K. You can always remove components you don't need later to make the _javascript_ smaller!== Need a lightweight, ninja-fast DOM and Events toolkit? ==
Download jQuery Core. Size: 10K== Need something more or less?  ==jQuery scales up and down with your needs. You can selectively add or remove components (Form Serializer, etc.), and leverage a thriving plugin community. Learn more here.

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Rik Lomas]

Even if it is 10-15 lines, it's still lines I, and most developers,
will never ever use. jQuery should be for the everyday basics, and the
plug-ins are there to extend the base.


On 15/11/06, Brian Miller <[EMAIL PROTECTED]> wrote:
> I'm not suggesting bloat here, Rik.  I think that, at the very least,
> support for $('myns|whatever') is core stuff, and is doable without a lot
> of code.  Since it's about the basic functionality of selection, I think
> that it's one of the few things that *shouldn't* be a plugin.
>
> I won't have time to actually take a crack at it for a few days, but I'd
> appreciate it if someone could demonstrate just how much space such an
> addition would take up.  I can't see it being more than like 10-15 lines
> or so, but I've been wrong before.  :)
>
> - Brian
>
>
> > Without sounding rude, I don't think I would ever use this and I don't
> > think most developers would either. We need jQuery to be small and
> > flexible, not a huge bloated framework like some of the other
> > libraries (that I will leave nameless)... Maybe extending jQuery, or
> > building a plug-in may be the way round this?
>
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
>


-- 
Rik Lomas
http://rikrikrik.com

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Glen Lipka]

Just a thought:You could put up a survey online asking:1. What should the maximum size of jQuery be with these modules (list current)?  [enter number]2. Which modules do you think could be abstracted out of the core into plugins to save space? [checkboxes]
3. etc.Of course, this info doesn't make it a "vote", it's just good to get a read of the audience.Personally, 19k is tiny to me compared to the others out there.  Even 25k would be tiny still.  However, I think the form handling is something that makes sense to rely on a plugin.
Glen
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Brian Miller]

I'm not suggesting bloat here, Rik.  I think that, at the very least,
support for $('myns|whatever') is core stuff, and is doable without a lot
of code.  Since it's about the basic functionality of selection, I think
that it's one of the few things that *shouldn't* be a plugin.

I won't have time to actually take a crack at it for a few days, but I'd
appreciate it if someone could demonstrate just how much space such an
addition would take up.  I can't see it being more than like 10-15 lines
or so, but I've been wrong before.  :)

- Brian


> Without sounding rude, I don't think I would ever use this and I don't
> think most developers would either. We need jQuery to be small and
> flexible, not a huge bloated framework like some of the other
> libraries (that I will leave nameless)... Maybe extending jQuery, or
> building a plug-in may be the way round this?


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Yehuda Katz]

Yep. I used my patch to write an additional plugin that allowed:$("div[&height>10]")which allows selectors based on CSS attributes. It'd be really easy to extend jQuery to include any other type of selector, as long as you built the appropriate RegExp parser. And it's only 43 *bytes*
-- YehudaOn 11/15/06, "Jörn Zaefferer" <[EMAIL PROTECTED]> wrote:
> > Without sounding rude, I don't think I would ever use this and I don't> > think most developers would either. We need jQuery to be small and> > flexible, not a huge bloated framework like some of the other
> > libraries (that I will leave nameless)... Maybe extending jQuery, or> > building a plug-in may be the way round this?>> Yes, that would be nice. But currently there is no hook to use custom
> selectors (other than `:something`, as>  demonstrates).>> For me it's ok if this feature is not in the core as long as it can be
> used as a plugin.Yehuda Katz proposed a patch for the parser that would allow custom expressions. And it was quite small.--Jörn Zaeffererhttp://bassistance.de
--Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer___
jQuery mailing listdiscuss@jquery.comhttp://jquery.com/discuss/-- Yehuda Katz
Web Developer | Wycats Designs(ph)  718.877.1325
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> > Without sounding rude, I don't think I would ever use this and I don't
> > think most developers would either. We need jQuery to be small and
> > flexible, not a huge bloated framework like some of the other
> > libraries (that I will leave nameless)... Maybe extending jQuery, or
> > building a plug-in may be the way round this?
> 
> Yes, that would be nice. But currently there is no hook to use custom
> selectors (other than `:something`, as
>  demonstrates).
> 
> For me it's ok if this feature is not in the core as long as it can be
> used as a plugin.

Yehuda Katz proposed a patch for the parser that would allow custom 
expressions. And it was quite small.

--
Jörn Zaefferer

http://bassistance.de
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> > Personally, I'm noticing a lot of requests for XML namespace selection
> in
> > the parser.  Can we get that into 1.1?  Apperently, making $('myns:div')
> > would raise holy hell because it would clash with the pseudos, but
> > $('myns|div') might be doable.
> 
> +1 for namespace selection.
> 
> In one of my current projects, we added custom attributes to form
> elements to use them as widgets.
> 
> As jQuery doesn't allow this kind of selection, we were forced to
> invalidate our XHTML. God killed a kitty.
> 
> I wouldn't like to do it again.

No need to harm any more kitten while avoiding namespaces: Take a look at the 
metadata plugin, it promotes valid markup without namespaces.

You are free to choose from three types of metadata: "class" (now default), 
"attr" and "elem".

For example, when using the default "class", you'd write your metadata this way:



Inside the brackets any javascript syntax is valid. By using types attr or 
elem, you can specify the same data in different places: attr uses custom 
(invalid) attributes, elem extra elements (eg. script).

--
Jörn Zaefferer

http://bassistance.de
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Choan C. Gálvez]

On 11/15/06, Rik Lomas <[EMAIL PROTECTED]> wrote:
> Without sounding rude, I don't think I would ever use this and I don't
> think most developers would either. We need jQuery to be small and
> flexible, not a huge bloated framework like some of the other
> libraries (that I will leave nameless)... Maybe extending jQuery, or
> building a plug-in may be the way round this?

Yes, that would be nice. But currently there is no hook to use custom
selectors (other than `:something`, as
 demonstrates).

For me it's ok if this feature is not in the core as long as it can be
used as a plugin.


> On 15/11/06, Choan C. Gálvez <[EMAIL PROTECTED]> wrote:
> > On 11/15/06, Brian Miller <[EMAIL PROTECTED]> wrote:
> > > Personally, I'm noticing a lot of requests for XML namespace selection in
> > > the parser.  Can we get that into 1.1?  Apperently, making $('myns:div')
> > > would raise holy hell because it would clash with the pseudos, but
> > > $('myns|div') might be doable.
> >
> > +1 for namespace selection.
> >
> > In one of my current projects, we added custom attributes to form
> > elements to use them as widgets.
> >
> > As jQuery doesn't allow this kind of selection, we were forced to
> > invalidate our XHTML. God killed a kitty.
> >
> > I wouldn't like to do it again.
-- 
Choan

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Rik Lomas]

Without sounding rude, I don't think I would ever use this and I don't
think most developers would either. We need jQuery to be small and
flexible, not a huge bloated framework like some of the other
libraries (that I will leave nameless)... Maybe extending jQuery, or
building a plug-in may be the way round this?


On 15/11/06, Choan C. Gálvez <[EMAIL PROTECTED]> wrote:
> On 11/15/06, Brian Miller <[EMAIL PROTECTED]> wrote:
> > Personally, I'm noticing a lot of requests for XML namespace selection in
> > the parser.  Can we get that into 1.1?  Apperently, making $('myns:div')
> > would raise holy hell because it would clash with the pseudos, but
> > $('myns|div') might be doable.
>
> +1 for namespace selection.
>
> In one of my current projects, we added custom attributes to form
> elements to use them as widgets.
>
> As jQuery doesn't allow this kind of selection, we were forced to
> invalidate our XHTML. God killed a kitty.
>
> I wouldn't like to do it again.
> --
> Choan
> 
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
>


-- 
Rik Lomas
http://rikrikrik.com

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Choan C. Gálvez]

On 11/15/06, Brian Miller <[EMAIL PROTECTED]> wrote:
> Personally, I'm noticing a lot of requests for XML namespace selection in
> the parser.  Can we get that into 1.1?  Apperently, making $('myns:div')
> would raise holy hell because it would clash with the pseudos, but
> $('myns|div') might be doable.

+1 for namespace selection.

In one of my current projects, we added custom attributes to form
elements to use them as widgets.

As jQuery doesn't allow this kind of selection, we were forced to
invalidate our XHTML. God killed a kitty.

I wouldn't like to do it again.
-- 
Choan


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Brian Miller]

Personally, I'm noticing a lot of requests for XML namespace selection in
the parser.  Can we get that into 1.1?  Apperently, making $('myns:div')
would raise holy hell because it would clash with the pseudos, but
$('myns|div') might be doable.

Can we make $('myns:div') work if there's no pseudo matching :div ?

Just a thought.

- Brian


> Hi Everyone -
>
> I want to start a discussion about the features that should go into
> (or be removed from) the upcoming 1.1 release. I'd like to shoot for a
> release by the end of this month.
> Let me know if you have any ideas.
>
> --John



___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> The way I coded the trigger and handle functions in my system it worked 
> like this (or at least it should. This is untested but theoretically 
> sound and the way I intended for it to work).
> 
> $().click(fn1,arg1,arg2);
> $().click(fn2,arg3,arg4);
> // someone clicks there
> // fn1 runs with arguments [event,arg1,arg2]
> // fn2 runs with args [event,arg3,arg4]
> $().trigger('click');
> // fn1 runs with args [event,arg1,arg2]
> // fn2 runs with args [event,arg3,arg4]
> $().trigger('click',arg5,arg6);
> // fn1 runs with args [event,arg1,arg2,arg5,arg6]
> // fn2 runs with args [event,arg3,arg4,arg5,arg6]
> 
> To me this is the least surprising result, would you agree?

No. The general idea of passing arguments via trigger and bind is to modularize 
code. Think of a big system where you can't rely on closures. Or where you want 
to pass arguments to a plugin via trigger. The event handler maybe implemented 
by the user, while the argument to bind are coming from plugin code and may 
change.

With your implementation, the handler had no idea how to identify which 
argument was passed via bind and which via trigger, but that is important.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Blair Mitchelmore]

And to correct myself, my system didn't do that and it will not do that. 
In fact the arguments sent into the trigger call have precedence and in 
retrospect that makes some semblance of sense to me. So my below trigger 
example actually does this:

$().trigger('click',arg5,arg6);
// fn1 runs with args [event,arg5,arg6,arg1,arg2]
// fn2 runs with args [event,arg5,arg6,arg3,arg4]

NB. My system doesn't actually do that... I thought I had rewritten that 
section but I hadn't. I will later today but for now I'm off to lectures...

-blair


Blair Mitchelmore wrote:
> Well hello right back Jörn!
>
> Jörn Zaefferer wrote:
>> Hi Blair!
>>
>>> Since this has come up again, I thought I'd mention - despite my distate 
>>> for plugin pimping - my own event++ system ( 
>>> http://jquery.offput.ca/event++ ) I wrote which could be used as the new 
>>> system. It can handle additional arguments sent to the event simply by 
>>> adding arguments to the event bind function call. It can also handle 
>>> limiting the number of event occurrence to run but as the first argument 
>>> to bind, click, et. al. It also handles scope arbitration using the 
>>> final argument provided to the event bind function call. There's a 
>>> little more detail available at the link above but regardless it seems 
>>> like it's a system people would appreciate and it barely adds any code 
>>> complexity to the current system.
>> Thanks, I'll keep that in mind.
>>
>> It looks like there were some changes to the event system since you wrote 
>> your system, we have to be careful with those.
>>
>> The additonal scope looks interesting, but rather useless. Do you have an 
>> example where that is really helping instead of only brain-twisting?
>>
>> Please don't get me wrong, but that scope seems to be way too geeky.
>>
>> By the way: We could simply allow Arrays and Objects for additonal argument: 
>> If it is a number, it's the amount of events to handle, otherwise its a 
>> pass-through argument.
>>
>> Remains the question on how to actualy pass the additonal stuff, because:
>> var x = $(...).bind("click", handler, args);
>> x.trigger("click", moreArgs);
>>
>> How to write the handler?
>>
>> var handler = function(event, bind, trigger) {
>>   // do something with bind and trigger, we have to list bind also when 
>> using only trigger
>> };
>>
>> var handler = function(event) {
>>   // do something with event.bind and event.trigger, they contain the data 
>> passed to bind and trigger, if any
>> };
>>
>> I'd prefer the second approach. Documenting callback parameters is difficult 
>> anyway.
>>
>> --
>> Jörn Zaefferer
>>
>> http://bassistance.de
> Yeah scope modification is really only useful when you're writing a 
> large object oriented system and you are writing event functions within 
> the object that is using it and want to write the code using 'this' to 
> make it explicit that you are referencing the object. I agree it's very 
> rare for most web development but including in the system wouldn't be 
> much of a bother and it would be a boon for OO obsessed coders out there.
>
> The way I coded the trigger and handle functions in my system it worked 
> like this (or at least it should. This is untested but theoretically 
> sound and the way I intended for it to work).
>
> $().click(fn1,arg1,arg2);
> $().click(fn2,arg3,arg4);
> // someone clicks there
> // fn1 runs with arguments [event,arg1,arg2]
> // fn2 runs with args [event,arg3,arg4]
> $().trigger('click');
> // fn1 runs with args [event,arg1,arg2]
> // fn2 runs with args [event,arg3,arg4]
> $().trigger('click',arg5,arg6);
> // fn1 runs with args [event,arg1,arg2,arg5,arg6]
> // fn2 runs with args [event,arg3,arg4,arg5,arg6]
>
> To me this is the least surprising result, would you agree?
>
> -blair

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Blair Mitchelmore]

Well hello right back Jörn!

Jörn Zaefferer wrote:
> Hi Blair!
>
>> Since this has come up again, I thought I'd mention - despite my distate 
>> for plugin pimping - my own event++ system ( 
>> http://jquery.offput.ca/event++ ) I wrote which could be used as the new 
>> system. It can handle additional arguments sent to the event simply by 
>> adding arguments to the event bind function call. It can also handle 
>> limiting the number of event occurrence to run but as the first argument 
>> to bind, click, et. al. It also handles scope arbitration using the 
>> final argument provided to the event bind function call. There's a 
>> little more detail available at the link above but regardless it seems 
>> like it's a system people would appreciate and it barely adds any code 
>> complexity to the current system.
>
> Thanks, I'll keep that in mind.
>
> It looks like there were some changes to the event system since you wrote 
> your system, we have to be careful with those.
>
> The additonal scope looks interesting, but rather useless. Do you have an 
> example where that is really helping instead of only brain-twisting?
>
> Please don't get me wrong, but that scope seems to be way too geeky.
>
> By the way: We could simply allow Arrays and Objects for additonal argument: 
> If it is a number, it's the amount of events to handle, otherwise its a 
> pass-through argument.
>
> Remains the question on how to actualy pass the additonal stuff, because:
> var x = $(...).bind("click", handler, args);
> x.trigger("click", moreArgs);
>
> How to write the handler?
>
> var handler = function(event, bind, trigger) {
>   // do something with bind and trigger, we have to list bind also when using 
> only trigger
> };
>
> var handler = function(event) {
>   // do something with event.bind and event.trigger, they contain the data 
> passed to bind and trigger, if any
> };
>
> I'd prefer the second approach. Documenting callback parameters is difficult 
> anyway.
>
> --
> Jörn Zaefferer
>
> http://bassistance.de
Yeah scope modification is really only useful when you're writing a 
large object oriented system and you are writing event functions within 
the object that is using it and want to write the code using 'this' to 
make it explicit that you are referencing the object. I agree it's very 
rare for most web development but including in the system wouldn't be 
much of a bother and it would be a boon for OO obsessed coders out there.

The way I coded the trigger and handle functions in my system it worked 
like this (or at least it should. This is untested but theoretically 
sound and the way I intended for it to work).

$().click(fn1,arg1,arg2);
$().click(fn2,arg3,arg4);
// someone clicks there
// fn1 runs with arguments [event,arg1,arg2]
// fn2 runs with args [event,arg3,arg4]
$().trigger('click');
// fn1 runs with args [event,arg1,arg2]
// fn2 runs with args [event,arg3,arg4]
$().trigger('click',arg5,arg6);
// fn1 runs with args [event,arg1,arg2,arg5,arg6]
// fn2 runs with args [event,arg3,arg4,arg5,arg6]

To me this is the least surprising result, would you agree?

-blair

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

Hi Blair!

> Since this has come up again, I thought I'd mention - despite my distate 
> for plugin pimping - my own event++ system ( 
> http://jquery.offput.ca/event++ ) I wrote which could be used as the new 
> system. It can handle additional arguments sent to the event simply by 
> adding arguments to the event bind function call. It can also handle 
> limiting the number of event occurrence to run but as the first argument 
> to bind, click, et. al. It also handles scope arbitration using the 
> final argument provided to the event bind function call. There's a 
> little more detail available at the link above but regardless it seems 
> like it's a system people would appreciate and it barely adds any code 
> complexity to the current system.

Thanks, I'll keep that in mind.

It looks like there were some changes to the event system since you wrote your 
system, we have to be careful with those.

The additonal scope looks interesting, but rather useless. Do you have an 
example where that is really helping instead of only brain-twisting?

Please don't get me wrong, but that scope seems to be way too geeky.

By the way: We could simply allow Arrays and Objects for additonal argument: If 
it is a number, it's the amount of events to handle, otherwise its a 
pass-through argument.

Remains the question on how to actualy pass the additonal stuff, because:
var x = $(...).bind("click", handler, args);
x.trigger("click", moreArgs);

How to write the handler?

var handler = function(event, bind, trigger) {
  // do something with bind and trigger, we have to list bind also when using 
only trigger
};

var handler = function(event) {
  // do something with event.bind and event.trigger, they contain the data 
passed to bind and trigger, if any
};

I'd prefer the second approach. Documenting callback parameters is difficult 
anyway.

--
Jörn Zaefferer

http://bassistance.de
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Blair Mitchelmore]

I actually probably should have explicitly showed the syntax for my 
event number handling technique. I used an optional first argument which 
defined that. If the first argument isn't a number then it doesn't need 
to worry about that and just goes through with a regular event bind.

$().click(3,fn1); // fn1 called on the first three clicks
$().click(fn2); // fn2 called on every click

Using this techniques allows you to have arbitrary additional arguments 
without having to worry about it accidentally triggering a 
repeat-limited event.

-blair

Blair Mitchelmore wrote:
> Since this has come up again, I thought I'd mention - despite my distate 
> for plugin pimping - my own event++ system ( 
> http://jquery.offput.ca/event++ ) I wrote which could be used as the new 
> system. It can handle additional arguments sent to the event simply by 
> adding arguments to the event bind function call. It can also handle 
> limiting the number of event occurrence to run but as the first argument 
> to bind, click, et. al. It also handles scope arbitration using the 
> final argument provided to the event bind function call. There's a 
> little more detail available at the link above but regardless it seems 
> like it's a system people would appreciate and it barely adds any code 
> complexity to the current system.
>
> -blair
>
> Kolman Nándor wrote:
>> What about using an object instead of an array?
>>
>> bind("click", handler, 1, {x: 1});
>> bind("click", handler, {x: 1});
>> ...
>>
>> Nandi
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Jörn 
>> Zaefferer"
>> Sent: Wednesday, November 15, 2006 1:22 PM
>> To: jQuery Discussion.
>> Subject: Re: [jQuery] jQuery 1.1 by the end of Nov
>>
>>>> Dunno how to handle the current oneEvents like oneclick: Extending bind
>>> with an additonal parameter for the number of events to handle before the
>>> handler should be removed would be one way, another to add a bindAmount() or
>>> binds().
>>>
>>> Allowing a number of events to be defined before handler is removed 
>>> would be very cool!
>> I'm just not sure how this should be integrated into the existing API: Add a 
>> new method, add parameter to bind? How to combine this with additional 
>> parameters that are to be passed to the handler?
>>
>> Consider these:
>> bind("click", handler) // normal
>> bind("click", handler, 1) // only once
>> bind("click", handler, 5) // five times
>> bind("click", handler, [true, 5, "stuff"]) // pass additional argument to 
>> handler
>> bind("click", handler, true, 5, "stuff") // pass additonal arguments to 
>> handler
>> bind("click", handler, 1, [true, 5, "stuff"]) // ...
>> bind("click", handler, 1, true, 5, "stuff") // ...
>>
>> I think the best approach would be to pass additional arguments always as an 
>> Array. That allows the implementation to check for the type of the third and 
>> fourth argument: If it's a number, use it as amount, if it is an array, use 
>> it as additonal arguments.
>>
>> --
>> Jörn Zaefferer
>>
>> http://bassistance.de

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Blair Mitchelmore]

Since this has come up again, I thought I'd mention - despite my distate 
for plugin pimping - my own event++ system ( 
http://jquery.offput.ca/event++ ) I wrote which could be used as the new 
system. It can handle additional arguments sent to the event simply by 
adding arguments to the event bind function call. It can also handle 
limiting the number of event occurrence to run but as the first argument 
to bind, click, et. al. It also handles scope arbitration using the 
final argument provided to the event bind function call. There's a 
little more detail available at the link above but regardless it seems 
like it's a system people would appreciate and it barely adds any code 
complexity to the current system.

-blair

Kolman Nándor wrote:
> What about using an object instead of an array?
>
> bind("click", handler, 1, {x: 1});
> bind("click", handler, {x: 1});
> ...
>
> Nandi
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Jörn 
> Zaefferer"
> Sent: Wednesday, November 15, 2006 1:22 PM
> To: jQuery Discussion.
> Subject: Re: [jQuery] jQuery 1.1 by the end of Nov
>
>>> Dunno how to handle the current oneEvents like oneclick: Extending bind
>> with an additonal parameter for the number of events to handle before the
>> handler should be removed would be one way, another to add a bindAmount() or
>> binds().
>>
>> Allowing a number of events to be defined before handler is removed 
>> would be very cool!
>
> I'm just not sure how this should be integrated into the existing API: Add a 
> new method, add parameter to bind? How to combine this with additional 
> parameters that are to be passed to the handler?
>
> Consider these:
> bind("click", handler) // normal
> bind("click", handler, 1) // only once
> bind("click", handler, 5) // five times
> bind("click", handler, [true, 5, "stuff"]) // pass additional argument to 
> handler
> bind("click", handler, true, 5, "stuff") // pass additonal arguments to 
> handler
> bind("click", handler, 1, [true, 5, "stuff"]) // ...
> bind("click", handler, 1, true, 5, "stuff") // ...
>
> I think the best approach would be to pass additional arguments always as an 
> Array. That allows the implementation to check for the type of the third and 
> fourth argument: If it's a number, use it as amount, if it is an array, use 
> it as additonal arguments.
>
> --
> Jörn Zaefferer
>
> http://bassistance.de

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Kolman Nándor]

What about using an object instead of an array?

bind("click", handler, 1, {x: 1});
bind("click", handler, {x: 1});
...

Nandi

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Jörn Zaefferer"
Sent: Wednesday, November 15, 2006 1:22 PM
To: jQuery Discussion.
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov

> > Dunno how to handle the current oneEvents like oneclick: Extending bind
> with an additonal parameter for the number of events to handle before the
> handler should be removed would be one way, another to add a bindAmount() or
> binds().
> 
> Allowing a number of events to be defined before handler is removed 
> would be very cool!

I'm just not sure how this should be integrated into the existing API: Add a 
new method, add parameter to bind? How to combine this with additional 
parameters that are to be passed to the handler?

Consider these:
bind("click", handler) // normal
bind("click", handler, 1) // only once
bind("click", handler, 5) // five times
bind("click", handler, [true, 5, "stuff"]) // pass additional argument to 
handler
bind("click", handler, true, 5, "stuff") // pass additonal arguments to handler
bind("click", handler, 1, [true, 5, "stuff"]) // ...
bind("click", handler, 1, true, 5, "stuff") // ...

I think the best approach would be to pass additional arguments always as an 
Array. That allows the implementation to check for the type of the third and 
fourth argument: If it's a number, use it as amount, if it is an array, use it 
as additonal arguments.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> > Dunno how to handle the current oneEvents like oneclick: Extending bind
> with an additonal parameter for the number of events to handle before the
> handler should be removed would be one way, another to add a bindAmount() or
> binds().
> 
> Allowing a number of events to be defined before handler is removed 
> would be very cool!

I'm just not sure how this should be integrated into the existing API: Add a 
new method, add parameter to bind? How to combine this with additional 
parameters that are to be passed to the handler?

Consider these:
bind("click", handler) // normal
bind("click", handler, 1) // only once
bind("click", handler, 5) // five times
bind("click", handler, [true, 5, "stuff"]) // pass additional argument to 
handler
bind("click", handler, true, 5, "stuff") // pass additonal arguments to handler
bind("click", handler, 1, [true, 5, "stuff"]) // ...
bind("click", handler, 1, true, 5, "stuff") // ...

I think the best approach would be to pass additional arguments always as an 
Array. That allows the implementation to check for the type of the third and 
fourth argument: If it's a number, use it as amount, if it is an array, use it 
as additonal arguments.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Klaus Hartl]

> Dunno how to handle the current oneEvents like oneclick: Extending bind with 
> an additonal parameter for the number of events to handle before the handler 
> should be removed would be one way, another to add a bindAmount() or binds().

Allowing a number of events to be defined before handler is removed 
would be very cool!


-- Klaus

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> > Right now, the jQuery compressed build is teetering around 18-19KB, I
> > really want to try and cut this down. Any thoughts on particular
> > features that should be extracted into a plugin?
> > 
> I know the macros don't account for _that_ much core code but they do
> complicate the documentation significantly. We have nice short names like
> .attr and .css yet those represent the most-macroed properties. Then we
> end
> up with (unjustifiable IMO) situations where valuable names like .height()
> are taken by the .css("height") macro to save five--count 'em--five
> characters. The same goes for the event macros, I think they account for
> more than half the names in the API documentation at this point and they
> end
> up creating situations like .unload() that are pretty hard to explain.
> 
> I would like to see jQuery take more of a Perl path than a PHP one, using
> a
> small number of consistent and powerful concepts plus the ability to
> extend
> things with plugins. Perl has one simple consistent regexp operator; PHP
> has
> two completely different regexp engines, each served by a dozen or more
> differently named functions.

Totally agree! The API contains way too much "convience" methods that makes it 
more complicate to find something. A more consistent approach, with only the 
css-method to access styles should be much more convinient on the long term.

There was the idea to provide a shortcut generator in the core and remove most 
default shortcuts. I think the proposed usage looked like this:

$.shortcut({
  css: ["height", "width"],
  attr: ["title"],
  bind: ["click"],
  unbind: ["click"]
});

That would create shortcuts available as height() and width(), title(), 
click(), oneclick(), onemouseover() and unclick(). Without them, you have to 
use the plain methods, eg. css("height"), attr("title"), bind("click") or 
unbind("click").

Dunno how to handle the current oneEvents like oneclick: Extending bind with an 
additonal parameter for the number of events to handle before the handler 
should be removed would be one way, another to add a bindAmount() or binds().

Extending bind() is troublesome because we want to extend that anyway to allow 
additonal arguments passed to the event handler.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> This just seems likely to generate a lot of extra support problems on  
> the mailing list. Can't we just leave it up to people to build their  
> own if they really want to cut it down below 20K?

Good idea! Provide the "full" package, including DOM, event, FX and AJAX, as 
default, and give a little more experienced users an easy way to cut it down to 
what they really need.

That would prevent any problems where the default built does not include stuff 
mentioned in docs, examples or tutorials.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

 Original-Nachricht 
Datum: Tue, 14 Nov 2006 16:24:12 -0500
Von: Rey Bango <[EMAIL PROTECTED]>
An: "jQuery Discussion." 
Betreff: Re: [jQuery] jQuery 1.1 by the end of Nov

> The main suggestion I would have is that if you remove something, make 
> it available in either a plugin or some archived form to allow folks to 
> take advantage of new features while not breaking their existing apps.
> 
> The serialization code for example, could be removed but should be 
> accessible in some way for some form of backwards compatibility.

The idea of maintaining the 1.0+ line is just this compatibility. To be able to 
evolve jQuery AND keeping it small, we need to break compatibility at some 
point.

--
Jörn Zaefferer

http://bassistance.de
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> I was just thinking the same thing. 
> Would this be possible? 
> 
> The file names would need to be consistent so that a plug in could require
> jquery+ajax+forms.js or something like that. Version numbers could get
> tricky.

Another point: It would be nice to see from the filename if the content is 
already compressed or not. I thought about creating a new file extension for 
compressed files, eg. ".jsc" (java script compressed). It wouldn't matter if 
editors aren't linked to that extension, the source isn't readable anyway. But 
I wonder if webservers set the right content type when sending that file, and 
if that can cause any trouble.

--
Jörn Zaefferer

http://bassistance.de
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Oliver Boermans]

Strip the redundancy - excellent idea.

On 15/11/06, John Resig <[EMAIL PROTECTED]> wrote:
> 1) Strip out all "helper" functions into an external plugin.
> 2) Change the official (in SVN) plugins to no longer use the helpers.
> 3) Change all docs to no longer use the helpers.

Towards the top of this thread I was in the 'make ajax a plugin' camp.
Simply because I have got huge value out of JQuery without touching
it. Of course I may feel differently once I have got a taste of that
AJAX magic :)

After reading all the talk about custom builds and the like I'm
leaning towards making the sensible decisions upfront. Trimming the
options, clicks and head scratching when downloading JQuery. Think
more Apple less Dell.

That is not an argument against a custom JQuery building gizmo as an
optimisation tool. Just a vote towards shielding regular users from
any need to use it to make their JQuery just work.

Otherwise every tutorial intended to show how easy something is - will
need to be prefixed with a JQuery configuration spec!

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jörn Zaefferer]

> I'm personally not sure that the entire ajax.js should be part of the
> core.  jQuery to me is about DOM searching and manipulation.  Its Ajax
> features are excellent, but I wouldn't cry at all if I had to include
> the ajax "plugin" or "official extension" or whatever you'd like to
> call it, only when I needed it.  I've actually done this on several
> occasions when I wanted to save some bandwidth and I wasn't using any
> of the ajax features. I've commented out ajax.js from build.xml and
> packed my own ajax-free jQuery and it works great.  It only saves
> around 3k packed, but that's significant when we're talking about <20k
> total. I realize that the politics surrounding not having the "ajax"
> buzzword included in the library by default are a significant issue in
> regards to developer addoption and jQuery marketing in general.  But
> it would further the goal of file size, and it really is pereferial to
> the overall goal of jQuery.

That is a good point. It would be great to have a small core, consisting of DOM 
selection/manipulation and the event system. Everything else, including ajax 
and fx modules, is optional.

To make this applicable, a nice build system that allows you to choose basic 
and extended plugins and create both normal and compressed files, without the 
burden of SVN and ant, would be necessary.

--
Jörn Zaefferer

http://bassistance.de
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Mika Tuupola]

On Nov 14, 2006, at 23:46, [EMAIL PROTECTED] wrote:

> Perhaps a download configuration tool similar to what is offered  
> with the interface plug-in? Allowing the user to choose the modules  
> he/she needs, thus creating their customized "baseline" JQuery file  
> on the fly, would be great!

IMO a bit annoying to use since with those I cant just easily wget  
the source.

-- 
Mika Tuupola
http://www.appelsiini.net/~tuupola/



___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Corey Jewett]

Just throwing a little fuel on the fire. If anybody cares give this a  
whirl -- build your own custom jQuery.

Maybe I'll figure out how to do plugins if anyone is interested.

http://corey.jquery.com/cgi-bin/make.cgi

Corey


On Nov 14, 2006, at 9:32 PM, John Resig wrote:

> I definitely agree. I'm going to propose this course of action:
>
> 1) Strip out all "helper" functions into an external plugin.
> 2) Change the official (in SVN) plugins to no longer use the helpers.
> 3) Change all docs to no longer use the helpers.
>
> This will clear up documentation and reduce the filesize (win-win!)
> I'm going to persue this avenue long before having mutlitple builds
> (which only tends to complicate the matter).
>
> --John
>
> On 11/14/06, Blair McKenzie <[EMAIL PROTECTED]> wrote:
>> I've been thinking the same thing actually. The messiness of three  
>> functions
>> for every event (bind, unbind, and trigger) outweighs the  
>> convenience. I
>> think that all these macros should be spun out into a plugin so  
>> that they
>> can still be included for backwards compatibility when necessary.
>>
>> Blair
>>
>>
>> On 11/15/06, dave.methvin <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> John Resig wrote:

 Right now, the jQuery compressed build is teetering around  
 18-19KB, I
 really want to try and cut this down. Any thoughts on particular
 features that should be extracted into a plugin?

>>> I know the macros don't account for _that_ much core code but  
>>> they do
>>> complicate the documentation significantly. We have nice short  
>>> names like
>>> .attr and .css yet those represent the most-macroed properties.  
>>> Then we
>> end
>>> up with (justifiable IMO) situations where valuable names  
>>> like .height()
>> are
>>> taken by the .css("height") macro to save five--count 'em--five
>> characters.
>>> The same goes for the event macros, I think they account for more  
>>> than
>> half
>>> the names in the API documentation at this point and they end up  
>>> creating
>>> situations like .unload() that are pretty hard to explain.
>>>
>>> I would like to see jQuery take more of a Perl path than a PHP  
>>> one, using
>> a
>>> small number of consistent and powerful concepts plus the ability to
>> extend
>>> things with plugins. Perl has one simple consistent regexp  
>>> operator; PHP
>> has
>>> two completely different regexp engines, each served by a dozen  
>>> or more
>>> differently named functions.
>>>
>>>
>>> --
>>> View this message in context:
>> http://www.nabble.com/jQuery-1.1-by-the-end-of-Nov- 
>> tf2631987.html#a7351892
>>> Sent from the JQuery mailing list archive at Nabble.com.
>>>
>>>
>>> ___
>>> jQuery mailing list
>>> discuss@jquery.com
>>> http://jquery.com/discuss/
>>>
>>
>>
>> ___
>> jQuery mailing list
>> discuss@jquery.com
>> http://jquery.com/discuss/
>>
>>
>>
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[ke han]

On Nov 15, 2006, at 4:17 AM, John Resig wrote:

> Hi Everyone -
>
>
> For example: Since the 'form' plugin already does serialization really
> really well (much better  than jQuery's serialization). I'm tempted to
> remove the serialization plugin from core and just defer everyone to
> using the form plugin.

I need methods to serialize field values on an individual basis or a  
group which is not encapsulated in a form or for a subset of fields  
in a form.  The Form plugin only exposes serialization on an entire  
form basis.

thanks, ke han

>
> Also, stuff like .height() and .width() could be removed in favor of
> using the (more powerful) methods of the same name in the 'Dimensions'
> plugin.
>
> Let me know if you have any ideas.
>
> --John
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Yehuda Katz]

I'd recommend merging in the patch that makes it easy to add in custom parsers. If I recall correctly, it added 41 bytes to the uncompressed copy of jQuery.-- YehudaOn 11/14/06, 
John Resig <[EMAIL PROTECTED]> wrote:
Hi Everyone -I want to start a discussion about the features that should go into(or be removed from) the upcoming 1.1 release. I'd like to shoot for arelease by the end of this month.I know that Joern already has some event code, ready to be committed -
and I have the "non-destructive jQuery" code ready to go. Brandonmentioned that he wants to rewrite the jQuery.attr() in time forrelease too.No significant features are going to be added to this release, think
of it as jQuery 1.0++.Right now, the jQuery compressed build is teetering around 18-19KB, Ireally want to try and cut this down. Any thoughts on particularfeatures that should be extracted into a plugin?
For example: Since the 'form' plugin already does serialization reallyreally well (much better  than jQuery's serialization). I'm tempted toremove the serialization plugin from core and just defer everyone to
using the form plugin.Also, stuff like .height() and .width() could be removed in favor ofusing the (more powerful) methods of the same name in the 'Dimensions'plugin.Let me know if you have any ideas.
--John___jQuery mailing listdiscuss@jquery.comhttp://jquery.com/discuss/
-- Yehuda KatzWeb Developer | Wycats Designs(ph)  718.877.1325
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Danial Tzadeh]

I'm a PHP programmer and I had used Prototype + Sc. extensively before. One thing I like about JQuery is that I can use it for my daily coding pretty easy, while concentrating on PHP part. When I want to trigger a button to slide down a menu all I need is JQ, if more fancy action needed I use other plugins (will need time to search and try). So simply JQuery at its current state saves me much time, with just a 20k. Regarding the size reduction, I wouldn't loose any of Ajax+FX as I am using them both daily, but go for some stricly JS side helper functions that most of the non-JS programmers won't use.
Danial
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[jshedd]

I have to say I absolutely *hate* the "build your own" library thing. First, 
when trying a new library, I don't often know what I need, so I end up 
downloading one set of files (click, click, click) only to discover I needed 
something else (click, click, click, click) then two weeks later I want 
something ELSE (click, click, click, click, click).

I say, find a standard set of things that should be included in jquery 
(personally, I'd ditch the effects stuff, as they're so minimal it'd be better 
to just pawn those elsewhere) and focus on the expression engine. That's 
jquery's bread and butter.

One simple download link, and a nice page where developers can find plugins.

-Original Message-
From: Jason Yeckel <[EMAIL PROTECTED]>
Sent: Wed, November 15, 2006 12:03 am
To: jQuery Discussion. 
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov

I think over all do a mootools like download / interface jquery lib 
download were the user can pick and choose components.

Just to be fair the only reason it has two was to make perl regex users 
happy :) I do use the perl regex though lol.


Jason Y
www.purepressure.com


dave.methvin wrote:
> John Resig wrote:
>   
>> Right now, the jQuery compressed build is teetering around 18-19KB, I
>> really want to try and cut this down. Any thoughts on particular
>> features that should be extracted into a plugin?
>>
>> 
> I know the macros don't account for _that_ much core code but they do
> complicate the documentation significantly. We have nice short names like
> .attr and .css yet those represent the most-macroed properties. Then we end
> up with (justifiable IMO) situations where valuable names like .height() are
> taken by the .css("height") macro to save five--count 'em--five characters.
> The same goes for the event macros, I think they account for more than half
> the names in the API documentation at this point and they end up creating
> situations like .unload() that are pretty hard to explain.
>
> I would like to see jQuery take more of a Perl path than a PHP one, using a
> small number of consistent and powerful concepts plus the ability to extend
> things with plugins. Perl has one simple consistent regexp operator; PHP has
> two completely different regexp engines, each served by a dozen or more
> differently named functions.
>
>
>   


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[John Resig]

I definitely agree. I'm going to propose this course of action:

1) Strip out all "helper" functions into an external plugin.
2) Change the official (in SVN) plugins to no longer use the helpers.
3) Change all docs to no longer use the helpers.

This will clear up documentation and reduce the filesize (win-win!)
I'm going to persue this avenue long before having mutlitple builds
(which only tends to complicate the matter).

--John

On 11/14/06, Blair McKenzie <[EMAIL PROTECTED]> wrote:
> I've been thinking the same thing actually. The messiness of three functions
> for every event (bind, unbind, and trigger) outweighs the convenience. I
> think that all these macros should be spun out into a plugin so that they
> can still be included for backwards compatibility when necessary.
>
> Blair
>
>
> On 11/15/06, dave.methvin <[EMAIL PROTECTED]> wrote:
> >
> >
> > John Resig wrote:
> > >
> > > Right now, the jQuery compressed build is teetering around 18-19KB, I
> > > really want to try and cut this down. Any thoughts on particular
> > > features that should be extracted into a plugin?
> > >
> > I know the macros don't account for _that_ much core code but they do
> > complicate the documentation significantly. We have nice short names like
> > .attr and .css yet those represent the most-macroed properties. Then we
> end
> > up with (justifiable IMO) situations where valuable names like .height()
> are
> > taken by the .css("height") macro to save five--count 'em--five
> characters.
> > The same goes for the event macros, I think they account for more than
> half
> > the names in the API documentation at this point and they end up creating
> > situations like .unload() that are pretty hard to explain.
> >
> > I would like to see jQuery take more of a Perl path than a PHP one, using
> a
> > small number of consistent and powerful concepts plus the ability to
> extend
> > things with plugins. Perl has one simple consistent regexp operator; PHP
> has
> > two completely different regexp engines, each served by a dozen or more
> > differently named functions.
> >
> >
> > --
> > View this message in context:
> http://www.nabble.com/jQuery-1.1-by-the-end-of-Nov-tf2631987.html#a7351892
> > Sent from the JQuery mailing list archive at Nabble.com.
> >
> >
> > ___
> > jQuery mailing list
> > discuss@jquery.com
> > http://jquery.com/discuss/
> >
>
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
>
>
>

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Larry Garfield]

On Tuesday 14 November 2006 15:17, John Resig wrote:
> I'm almost inclined to agree. When planning out the structure for the
> new documentation I realized that the 'Ajax' section was really more
> of a "Design Methodologies/Cookbook" section, more than anything else.
> Whereas the core dom/css is more of a toolset of functionality.
>
> That being said - Ajax functionality is used a lot. If it were
> extracted, I'd want to have a special jquery+ajax build to go along
> with it.

I see nothing wrong with multiple "standard" builds for those not up to 
building their own compressed libraries.  

"Core" - Minimal stripped version
"Standard" - More or less what it is now, including Ajax
"Advanced" - Throw in some of the more useful plugins (by some definition of 
useful, but probably including the forms handling stuff and dimensions and 
possibly Interface; I leave this to others to figure out).
Or Build Your Own! - Link to instructions on how to roll your own 
cherry-picked compressed library.

80% of people will just grab Standard, those that are very size conscious will 
get Core, those who like lots of bells and whistles for no effort get 
Advanced, and heavy-duty developers will build to order.

Excuse me while I go back to lurking. :-)

-- 
Larry Garfield  AIM: LOLG42
[EMAIL PROTECTED]   ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Jason Yeckel]

I think over all do a mootools like download / interface jquery lib 
download were the user can pick and choose components.

Just to be fair the only reason it has two was to make perl regex users 
happy :) I do use the perl regex though lol.


Jason Y
www.purepressure.com


dave.methvin wrote:
> John Resig wrote:
>   
>> Right now, the jQuery compressed build is teetering around 18-19KB, I
>> really want to try and cut this down. Any thoughts on particular
>> features that should be extracted into a plugin?
>>
>> 
> I know the macros don't account for _that_ much core code but they do
> complicate the documentation significantly. We have nice short names like
> .attr and .css yet those represent the most-macroed properties. Then we end
> up with (justifiable IMO) situations where valuable names like .height() are
> taken by the .css("height") macro to save five--count 'em--five characters.
> The same goes for the event macros, I think they account for more than half
> the names in the API documentation at this point and they end up creating
> situations like .unload() that are pretty hard to explain.
>
> I would like to see jQuery take more of a Perl path than a PHP one, using a
> small number of consistent and powerful concepts plus the ability to extend
> things with plugins. Perl has one simple consistent regexp operator; PHP has
> two completely different regexp engines, each served by a dozen or more
> differently named functions.
>
>
>   


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Blair McKenzie]

I've been thinking the same thing actually. The messiness of three functions for every event (bind, unbind, and trigger) outweighs the convenience. I think that all these macros should be spun out into a plugin so that they can still be included for backwards compatibility when necessary.
BlairOn 11/15/06, dave.methvin <[EMAIL PROTECTED]> wrote:
John Resig wrote:>> Right now, the jQuery compressed build is teetering around 18-19KB, I> really want to try and cut this down. Any thoughts on particular> features that should be extracted into a plugin?
>I know the macros don't account for _that_ much core code but they docomplicate the documentation significantly. We have nice short names like.attr and .css yet those represent the most-macroed properties. Then we end
up with (justifiable IMO) situations where valuable names like .height() aretaken by the .css("height") macro to save five--count 'em--five characters.The same goes for the event macros, I think they account for more than half
the names in the API documentation at this point and they end up creatingsituations like .unload() that are pretty hard to explain.I would like to see jQuery take more of a Perl path than a PHP one, using a
small number of consistent and powerful concepts plus the ability to extendthings with plugins. Perl has one simple consistent regexp operator; PHP hastwo completely different regexp engines, each served by a dozen or more
differently named functions.--View this message in context: http://www.nabble.com/jQuery-1.1-by-the-end-of-Nov-tf2631987.html#a7351892
Sent from the JQuery mailing list archive at Nabble.com.___jQuery mailing listdiscuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[dave.methvin]

John Resig wrote:
> 
> Right now, the jQuery compressed build is teetering around 18-19KB, I
> really want to try and cut this down. Any thoughts on particular
> features that should be extracted into a plugin?
> 
I know the macros don't account for _that_ much core code but they do
complicate the documentation significantly. We have nice short names like
.attr and .css yet those represent the most-macroed properties. Then we end
up with (unjustifiable IMO) situations where valuable names like .height()
are taken by the .css("height") macro to save five--count 'em--five
characters. The same goes for the event macros, I think they account for
more than half the names in the API documentation at this point and they end
up creating situations like .unload() that are pretty hard to explain.

I would like to see jQuery take more of a Perl path than a PHP one, using a
small number of consistent and powerful concepts plus the ability to extend
things with plugins. Perl has one simple consistent regexp operator; PHP has
two completely different regexp engines, each served by a dozen or more
differently named functions.


-- 
View this message in context: 
http://www.nabble.com/jQuery-1.1-by-the-end-of-Nov-tf2631987.html#a7351892
Sent from the JQuery mailing list archive at Nabble.com.


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Blair McKenzie]

I think the idea of the package builder is so that 'standard' plugins can also be offered.BlairOn 11/15/06, Paul McLanahan <
[EMAIL PROTECTED]> wrote:I agree that it should be as simple as possible for the end user, if
only for our sanity because of the potential for increased supportrequests. I think the most simple and easy solution is to prominentlydisplay the (recommended) download, and have 4 other options forpeople who know exactly what they need:
1. jquery.js (recommended) (everything packed)2. jquery-ajax.js (core + ajax packed)3. jquery-fx.js (core + fx packed)4. jquery-lite.js (core packed)5. jquery-src.js (everything not packed)
I think almost everyone can get what they need from those 5 options,and making the full package the recommended download should minimizethe "function not defined" questions from new users. I'm thinking now
that a download builder might be overkill.  With only 4 main configoptions, why build something when prebuilding all combos is sotrivial.  I saw a comment above that suggested that the DOM part ofthe core was something to be included or excluded as well, but I don't
think that at all.  The DOM traversal and manipulation and eventhandling IS the core of jQuery.  Exclude DOM handling, and you've notgot much left.I also really like, and have been thinking about the idea of defining
requirements in plugins. Most plugins I've either written or plan towrite will require (or at least utilize if it's available) John'sMetadata plugin. The Dimensions, Center, and Form plugins are alsooften required for others to work. I haven't thought it through enough
to post a proposal, but my first thoughts were to wonder whetherincluding a requirements list in the docs specification would beenough, or whether it will require some code to actually check. Myleanings at the moment are that the documentation solution is the way
to go with probably a @required and @recommended specification thatwould include a list of name:url pairs. I don't see a point in havinga real method defined in the core for saying that what you need isn't
there.  If a plugin requires a function that may or may not beincluded, then the docs should be the first place a Dev should look.Plus the fact that it's trivially easy to check for a function youneed in your plugin and throw an error if it's not there. I would like
to hear more thoughts on this, but perhaps we should start a newthread and keep this one going on John's original questions.Paul___jQuery mailing list
discuss@jquery.comhttp://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Paul McLanahan]

I agree that it should be as simple as possible for the end user, if
only for our sanity because of the potential for increased support
requests. I think the most simple and easy solution is to prominently
display the (recommended) download, and have 4 other options for
people who know exactly what they need:

1. jquery.js (recommended) (everything packed)
2. jquery-ajax.js (core + ajax packed)
3. jquery-fx.js (core + fx packed)
4. jquery-lite.js (core packed)
5. jquery-src.js (everything not packed)

I think almost everyone can get what they need from those 5 options,
and making the full package the recommended download should minimize
the "function not defined" questions from new users. I'm thinking now
that a download builder might be overkill.  With only 4 main config
options, why build something when prebuilding all combos is so
trivial.  I saw a comment above that suggested that the DOM part of
the core was something to be included or excluded as well, but I don't
think that at all.  The DOM traversal and manipulation and event
handling IS the core of jQuery.  Exclude DOM handling, and you've not
got much left.

I also really like, and have been thinking about the idea of defining
requirements in plugins. Most plugins I've either written or plan to
write will require (or at least utilize if it's available) John's
Metadata plugin. The Dimensions, Center, and Form plugins are also
often required for others to work. I haven't thought it through enough
to post a proposal, but my first thoughts were to wonder whether
including a requirements list in the docs specification would be
enough, or whether it will require some code to actually check. My
leanings at the moment are that the documentation solution is the way
to go with probably a @required and @recommended specification that
would include a list of name:url pairs. I don't see a point in having
a real method defined in the core for saying that what you need isn't
there.  If a plugin requires a function that may or may not be
included, then the docs should be the first place a Dev should look.
Plus the fact that it's trivially easy to check for a function you
need in your plugin and throw an error if it's not there. I would like
to hear more thoughts on this, but perhaps we should start a new
thread and keep this one going on John's original questions.

Paul

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Kevin Scholl]

Corey Jewett wrote:

> The problem with all this is that 4 js files totaling 20K is will  
> typically make your page load slower than 1 20K JS file.

Yes, but this isn't a problem with the manner in which the interface 
plug-in download works. It combines the chosen modules on the fly, then 
packs them as a single js file. As John said, though, I can see where 
this is complicated and would take time.

In the short term, I'm all for various combinations from which to 
choose. It's obvious from the responses thus far that there is a great 
variety in how people are using JQuery. For example, someone stated that 
they want the Ajax module first and foremost, and don't need fx. I'm 
quite the opposite. Others fall all along the line. So maybe a 
half-dozen different packages is the way to go, until such time that a 
good, stable package builder can be implemented.

Kevin


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Stephen Woodbridge]

I think that the point that I am trying to make is that we create some 
number of prepackaged files. Each prepackaged file is completely 
standalone and does not require any other jQuery files to be requested. 
We decide what functionality set gets bundled into each package and 
describe that functionality maybe in a comparison table with check marks 
for included functionality.

Then the average user that does not want to download all the build tools 
and figure out how to edit the make files to select whatever 
functionality they might think they need and then broke it because they 
forgot some dependency, etc. etc. can simply look at the check list and 
pick the pre-packaged file that covers what they need.

This means that the user loads ONE jQuery file, that size of it depends 
on which package they choose. This makes the chooses limited, clear, and 
that means there is a high probability of success from the user's point 
of view - This is good. I just think that we should make it as easy as 
possible for the new user to jump in and use jQuery. If we can provide a 
good simple fast dynamic packaging system then great! This is an 
alternative that is easy to implement a good compromise and requires 
minimal training to use.

Anyone that has the willing to dig into the tools can probably figure 
out how to make a custom package to fit their needs or to optimize the 
package to their special requirements.

-Steve

Corey Jewett wrote:
> The problem with all this is that 4 js files totaling 20K is will  
> typically make your page load slower than 1 20K JS file. There are a  
> couple reasons:
> 
> 1) round trip time per each additional requests for each file.  
> Roughly equivalent to ping lag + server processing time. I wouldn't  
> be surprised if this was an extra 250 millis per request.
> 
> 2) the HTTP RFC suggests a maximum of 4 open connections from a  
> client to a server. More files == larger backlog of files == poorer  
> utilization of broadband connections.
> 
> 3) HTTP pipelining (assuming it's even turned on, which it frequently  
> isn't since it wastes server resources) can theoretically mitigate  
> #2, but will not do much for #1. It'll cut out repeated setup and  
> teardown of TCP stacks.
> 
> 4) I haven't done any recent research on it, but don't browsers tend  
> to cache JS files anyway?
> 
> Now having said all that, if you still want to whittle down the file  
> size, can I make a vote to maybe yank serialization, but nothing  
> else. From the response so far it appears that there's a pretty even  
> split between people who use/don't FX and/or AJAX. Meaning that  
> pulling either one out is sure to screw up the other half.
> 
> I could get on board with releasing several packages, as somebody  
> suggested:
> 
> JQuery: src/jquery + src/events + src/fx + src/ajax
> JQuery-fx-only: src/jquery + src/events + src/fx
> JQuery-ajax-only: src/jquery + src/events + src/ajax
> Jquery-dom-only: src/jquery + src/events
> JQuery-lite: src/jquery
> 
> This just seems likely to generate a lot of extra support problems on  
> the mailing list. Can't we just leave it up to people to build their  
> own if they really want to cut it down below 20K?
> 
> Corey
> 
> 
> 
> On Nov 14, 2006, at 2:22 PM, Stephen Woodbridge wrote:
> 
>> John,
>>
>> That is why I think some prepackaged packages might work better in the
>> short term.
>>
>> Longer term we might want to have plugins define a requires  
>> statement so
>> that is would be easier for a build system to pull in all the required
>> modules.
>>
>> -Steve
>>
>> John Resig wrote:
>>> I'm all for the custom build feature - in fact it was one of the  
>>> first
>>> things included on the jQuery home page when it first launched  
>>> back in
>>> Jan. (I removed it at the 1.0 launch, because it was broken).
>>>
>>> My biggest worry about having custom builds is that if a user sees
>>> something in the documentation (e.g. .height()) and then it doesn't
>>> work at all, that'll cause a lot of confusion. Figuring out what
>>> package everything is in. It is for this reason that I think any sort
>>> of package system has to be documented very explicitly so that people
>>> know what they're getting in to.
>>>
>>> This would also require that all demos, tutorials, and plugins use  
>>> the
>>> lowest comon denominator of code (which will require a lot of
>>> rewriting). In all, it's very tricky, and something that we'll  
>>> want to
>>> consider carefully.
>>>
>>> --John
>>>
>>> On 11/14/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
 I think that it would be great if we had a few bundled "flavors"  
 like:

 jQuery-minimal.js
 jQuery-lite.js
 jQuery-standard.js
 jQuery-heavy.js

 This way we get the benefit of claiming all the features and can  
 claim
 "starting at only xx bytes" based on the packed size of the minimal
 flavor. Providing a other flavors makes it easy for uses to grab a
 package o

Re: [jQuery] jQuery 1.1 by the end of Nov

[Benjamin Sterling]

Fairly new to Jquery, but from what I see already, the amount of code that
needs to be written is very minimal when using jquery.  I am currently
converting about 5 js files totaling about 1000+ lines of js code to utilize
jquery and already took one js file the was 549 lines (uncompressed) and 12k
to about 223 lines and about 4k.  Point is, if the jquery file is 20k or
even a little more, the amount of code that would be saved is a good trade
off in my mind.

Now granted, that is my sites situation.  Some sites may be using jquery
only for the toggle.  So maybe there should be a lite version for those
people.

Just my two cents.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Corey Jewett
Sent: Tuesday, November 14, 2006 8:33 PM
To: jQuery Discussion.
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov

The problem with all this is that 4 js files totaling 20K is will  
typically make your page load slower than 1 20K JS file. There are a  
couple reasons:

1) round trip time per each additional requests for each file.  
Roughly equivalent to ping lag + server processing time. I wouldn't  
be surprised if this was an extra 250 millis per request.

2) the HTTP RFC suggests a maximum of 4 open connections from a  
client to a server. More files == larger backlog of files == poorer  
utilization of broadband connections.

3) HTTP pipelining (assuming it's even turned on, which it frequently  
isn't since it wastes server resources) can theoretically mitigate  
#2, but will not do much for #1. It'll cut out repeated setup and  
teardown of TCP stacks.

4) I haven't done any recent research on it, but don't browsers tend  
to cache JS files anyway?

Now having said all that, if you still want to whittle down the file  
size, can I make a vote to maybe yank serialization, but nothing  
else. From the response so far it appears that there's a pretty even  
split between people who use/don't FX and/or AJAX. Meaning that  
pulling either one out is sure to screw up the other half.

I could get on board with releasing several packages, as somebody  
suggested:

JQuery: src/jquery + src/events + src/fx + src/ajax
JQuery-fx-only: src/jquery + src/events + src/fx
JQuery-ajax-only: src/jquery + src/events + src/ajax
Jquery-dom-only: src/jquery + src/events
JQuery-lite: src/jquery

This just seems likely to generate a lot of extra support problems on  
the mailing list. Can't we just leave it up to people to build their  
own if they really want to cut it down below 20K?

Corey



On Nov 14, 2006, at 2:22 PM, Stephen Woodbridge wrote:

> John,
>
> That is why I think some prepackaged packages might work better in the
> short term.
>
> Longer term we might want to have plugins define a requires  
> statement so
> that is would be easier for a build system to pull in all the required
> modules.
>
> -Steve
>
> John Resig wrote:
>> I'm all for the custom build feature - in fact it was one of the  
>> first
>> things included on the jQuery home page when it first launched  
>> back in
>> Jan. (I removed it at the 1.0 launch, because it was broken).
>>
>> My biggest worry about having custom builds is that if a user sees
>> something in the documentation (e.g. .height()) and then it doesn't
>> work at all, that'll cause a lot of confusion. Figuring out what
>> package everything is in. It is for this reason that I think any sort
>> of package system has to be documented very explicitly so that people
>> know what they're getting in to.
>>
>> This would also require that all demos, tutorials, and plugins use  
>> the
>> lowest comon denominator of code (which will require a lot of
>> rewriting). In all, it's very tricky, and something that we'll  
>> want to
>> consider carefully.
>>
>> --John
>>
>> On 11/14/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
>>> I think that it would be great if we had a few bundled "flavors"  
>>> like:
>>>
>>> jQuery-minimal.js
>>> jQuery-lite.js
>>> jQuery-standard.js
>>> jQuery-heavy.js
>>>
>>> This way we get the benefit of claiming all the features and can  
>>> claim
>>> "starting at only xx bytes" based on the packed size of the minimal
>>> flavor. Providing a other flavors makes it easy for uses to grab a
>>> package of features without having to deal with build issues.
>>>
>>> -Steve
>>>
>>> John Resig wrote:
>>>> Hi Everyone -
>>>>
>>>> I want to start a discussion about the features that should go into
>>>> (or be removed from) the upcoming 1.1 release. I'd like

Re: [jQuery] jQuery 1.1 by the end of Nov

[Corey Jewett]

The problem with all this is that 4 js files totaling 20K is will  
typically make your page load slower than 1 20K JS file. There are a  
couple reasons:

1) round trip time per each additional requests for each file.  
Roughly equivalent to ping lag + server processing time. I wouldn't  
be surprised if this was an extra 250 millis per request.

2) the HTTP RFC suggests a maximum of 4 open connections from a  
client to a server. More files == larger backlog of files == poorer  
utilization of broadband connections.

3) HTTP pipelining (assuming it's even turned on, which it frequently  
isn't since it wastes server resources) can theoretically mitigate  
#2, but will not do much for #1. It'll cut out repeated setup and  
teardown of TCP stacks.

4) I haven't done any recent research on it, but don't browsers tend  
to cache JS files anyway?

Now having said all that, if you still want to whittle down the file  
size, can I make a vote to maybe yank serialization, but nothing  
else. From the response so far it appears that there's a pretty even  
split between people who use/don't FX and/or AJAX. Meaning that  
pulling either one out is sure to screw up the other half.

I could get on board with releasing several packages, as somebody  
suggested:

JQuery: src/jquery + src/events + src/fx + src/ajax
JQuery-fx-only: src/jquery + src/events + src/fx
JQuery-ajax-only: src/jquery + src/events + src/ajax
Jquery-dom-only: src/jquery + src/events
JQuery-lite: src/jquery

This just seems likely to generate a lot of extra support problems on  
the mailing list. Can't we just leave it up to people to build their  
own if they really want to cut it down below 20K?

Corey



On Nov 14, 2006, at 2:22 PM, Stephen Woodbridge wrote:

> John,
>
> That is why I think some prepackaged packages might work better in the
> short term.
>
> Longer term we might want to have plugins define a requires  
> statement so
> that is would be easier for a build system to pull in all the required
> modules.
>
> -Steve
>
> John Resig wrote:
>> I'm all for the custom build feature - in fact it was one of the  
>> first
>> things included on the jQuery home page when it first launched  
>> back in
>> Jan. (I removed it at the 1.0 launch, because it was broken).
>>
>> My biggest worry about having custom builds is that if a user sees
>> something in the documentation (e.g. .height()) and then it doesn't
>> work at all, that'll cause a lot of confusion. Figuring out what
>> package everything is in. It is for this reason that I think any sort
>> of package system has to be documented very explicitly so that people
>> know what they're getting in to.
>>
>> This would also require that all demos, tutorials, and plugins use  
>> the
>> lowest comon denominator of code (which will require a lot of
>> rewriting). In all, it's very tricky, and something that we'll  
>> want to
>> consider carefully.
>>
>> --John
>>
>> On 11/14/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
>>> I think that it would be great if we had a few bundled "flavors"  
>>> like:
>>>
>>> jQuery-minimal.js
>>> jQuery-lite.js
>>> jQuery-standard.js
>>> jQuery-heavy.js
>>>
>>> This way we get the benefit of claiming all the features and can  
>>> claim
>>> "starting at only xx bytes" based on the packed size of the minimal
>>> flavor. Providing a other flavors makes it easy for uses to grab a
>>> package of features without having to deal with build issues.
>>>
>>> -Steve
>>>
>>> John Resig wrote:
 Hi Everyone -

 I want to start a discussion about the features that should go into
 (or be removed from) the upcoming 1.1 release. I'd like to shoot  
 for a
 release by the end of this month.

 I know that Joern already has some event code, ready to be  
 committed -
 and I have the "non-destructive jQuery" code ready to go. Brandon
 mentioned that he wants to rewrite the jQuery.attr() in time for
 release too.

 No significant features are going to be added to this release,  
 think
 of it as jQuery 1.0++.

 Right now, the jQuery compressed build is teetering around  
 18-19KB, I
 really want to try and cut this down. Any thoughts on particular
 features that should be extracted into a plugin?

 For example: Since the 'form' plugin already does serialization  
 really
 really well (much better  than jQuery's serialization). I'm  
 tempted to
 remove the serialization plugin from core and just defer  
 everyone to
 using the form plugin.

 Also, stuff like .height() and .width() could be removed in  
 favor of
 using the (more powerful) methods of the same name in the  
 'Dimensions'
 plugin.

 Let me know if you have any ideas.

 --John
>>
>> ___
>> jQuery mailing list
>> discuss@jquery.com
>> http://jquery.com/discuss/
>
>
> ___
> jQuer

Re: [jQuery] jQuery 1.1 by the end of Nov

[Mike Alsup]

> I'm all for the custom build feature - in fact it was one of the first
> things included on the jQuery home page when it first launched back in
> Jan. (I removed it at the 1.0 launch, because it was broken).

John,

If you're intent on moving stuff out of core, I'd rather it be the fx
functions than the ajax functions.  I use the ajax functions on every
project but only occasionally dabble in the fx stuff.  I see that more
as fluff.

Regarding core's serialization functionality, the form plugin actually
calls the core method (jQuery.param) for serialization once it has
figured out what to serialize.  In addition, its usage is pattern is
slightly different because it's context is always the containing
object.

Mike

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Stephen Woodbridge]

John,

That is why I think some prepackaged packages might work better in the 
short term.

Longer term we might want to have plugins define a requires statement so 
that is would be easier for a build system to pull in all the required 
modules.

-Steve

John Resig wrote:
> I'm all for the custom build feature - in fact it was one of the first
> things included on the jQuery home page when it first launched back in
> Jan. (I removed it at the 1.0 launch, because it was broken).
> 
> My biggest worry about having custom builds is that if a user sees
> something in the documentation (e.g. .height()) and then it doesn't
> work at all, that'll cause a lot of confusion. Figuring out what
> package everything is in. It is for this reason that I think any sort
> of package system has to be documented very explicitly so that people
> know what they're getting in to.
> 
> This would also require that all demos, tutorials, and plugins use the
> lowest comon denominator of code (which will require a lot of
> rewriting). In all, it's very tricky, and something that we'll want to
> consider carefully.
> 
> --John
> 
> On 11/14/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
>> I think that it would be great if we had a few bundled "flavors" like:
>>
>> jQuery-minimal.js
>> jQuery-lite.js
>> jQuery-standard.js
>> jQuery-heavy.js
>>
>> This way we get the benefit of claiming all the features and can claim
>> "starting at only xx bytes" based on the packed size of the minimal
>> flavor. Providing a other flavors makes it easy for uses to grab a
>> package of features without having to deal with build issues.
>>
>> -Steve
>>
>> John Resig wrote:
>>> Hi Everyone -
>>>
>>> I want to start a discussion about the features that should go into
>>> (or be removed from) the upcoming 1.1 release. I'd like to shoot for a
>>> release by the end of this month.
>>>
>>> I know that Joern already has some event code, ready to be committed -
>>> and I have the "non-destructive jQuery" code ready to go. Brandon
>>> mentioned that he wants to rewrite the jQuery.attr() in time for
>>> release too.
>>>
>>> No significant features are going to be added to this release, think
>>> of it as jQuery 1.0++.
>>>
>>> Right now, the jQuery compressed build is teetering around 18-19KB, I
>>> really want to try and cut this down. Any thoughts on particular
>>> features that should be extracted into a plugin?
>>>
>>> For example: Since the 'form' plugin already does serialization really
>>> really well (much better  than jQuery's serialization). I'm tempted to
>>> remove the serialization plugin from core and just defer everyone to
>>> using the form plugin.
>>>
>>> Also, stuff like .height() and .width() could be removed in favor of
>>> using the (more powerful) methods of the same name in the 'Dimensions'
>>> plugin.
>>>
>>> Let me know if you have any ideas.
>>>
>>> --John
> 
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[John Resig]

I'm all for the custom build feature - in fact it was one of the first
things included on the jQuery home page when it first launched back in
Jan. (I removed it at the 1.0 launch, because it was broken).

My biggest worry about having custom builds is that if a user sees
something in the documentation (e.g. .height()) and then it doesn't
work at all, that'll cause a lot of confusion. Figuring out what
package everything is in. It is for this reason that I think any sort
of package system has to be documented very explicitly so that people
know what they're getting in to.

This would also require that all demos, tutorials, and plugins use the
lowest comon denominator of code (which will require a lot of
rewriting). In all, it's very tricky, and something that we'll want to
consider carefully.

--John

On 11/14/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
> I think that it would be great if we had a few bundled "flavors" like:
>
> jQuery-minimal.js
> jQuery-lite.js
> jQuery-standard.js
> jQuery-heavy.js
>
> This way we get the benefit of claiming all the features and can claim
> "starting at only xx bytes" based on the packed size of the minimal
> flavor. Providing a other flavors makes it easy for uses to grab a
> package of features without having to deal with build issues.
>
> -Steve
>
> John Resig wrote:
> > Hi Everyone -
> >
> > I want to start a discussion about the features that should go into
> > (or be removed from) the upcoming 1.1 release. I'd like to shoot for a
> > release by the end of this month.
> >
> > I know that Joern already has some event code, ready to be committed -
> > and I have the "non-destructive jQuery" code ready to go. Brandon
> > mentioned that he wants to rewrite the jQuery.attr() in time for
> > release too.
> >
> > No significant features are going to be added to this release, think
> > of it as jQuery 1.0++.
> >
> > Right now, the jQuery compressed build is teetering around 18-19KB, I
> > really want to try and cut this down. Any thoughts on particular
> > features that should be extracted into a plugin?
> >
> > For example: Since the 'form' plugin already does serialization really
> > really well (much better  than jQuery's serialization). I'm tempted to
> > remove the serialization plugin from core and just defer everyone to
> > using the form plugin.
> >
> > Also, stuff like .height() and .width() could be removed in favor of
> > using the (more powerful) methods of the same name in the 'Dimensions'
> > plugin.
> >
> > Let me know if you have any ideas.
> >
> > --John

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Stephen Woodbridge]

I think that it would be great if we had a few bundled "flavors" like:

jQuery-minimal.js
jQuery-lite.js
jQuery-standard.js
jQuery-heavy.js

This way we get the benefit of claiming all the features and can claim 
"starting at only xx bytes" based on the packed size of the minimal 
flavor. Providing a other flavors makes it easy for uses to grab a 
package of features without having to deal with build issues.

-Steve

John Resig wrote:
> Hi Everyone -
> 
> I want to start a discussion about the features that should go into
> (or be removed from) the upcoming 1.1 release. I'd like to shoot for a
> release by the end of this month.
> 
> I know that Joern already has some event code, ready to be committed -
> and I have the "non-destructive jQuery" code ready to go. Brandon
> mentioned that he wants to rewrite the jQuery.attr() in time for
> release too.
> 
> No significant features are going to be added to this release, think
> of it as jQuery 1.0++.
> 
> Right now, the jQuery compressed build is teetering around 18-19KB, I
> really want to try and cut this down. Any thoughts on particular
> features that should be extracted into a plugin?
> 
> For example: Since the 'form' plugin already does serialization really
> really well (much better  than jQuery's serialization). I'm tempted to
> remove the serialization plugin from core and just defer everyone to
> using the form plugin.
> 
> Also, stuff like .height() and .width() could be removed in favor of
> using the (more powerful) methods of the same name in the 'Dimensions'
> plugin.
> 
> Let me know if you have any ideas.
> 
> --John
> 
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Geoffrey Knutzen]

I was just thinking the same thing. 
Would this be possible? 

The file names would need to be consistent so that a plug in could require
jquery+ajax+forms.js or something like that. Version numbers could get
tricky.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 1:47 PM
To: jQuery Discussion.
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov

Perhaps a download configuration tool similar to what is offered with the
interface plug-in? Allowing the user to choose the modules he/she needs,
thus creating their customized "baseline" JQuery file on the fly, would be
great!

Kevin

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/


___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[kscholl . jq]

Perhaps a download configuration tool similar to what is offered with the 
interface plug-in? Allowing the user to choose the modules he/she needs, thus 
creating their customized "baseline" JQuery file on the fly, would be great!

Kevin

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Paul McLanahan]

On 11/14/06, John Resig <[EMAIL PROTECTED]> wrote:
> That being said - Ajax functionality is used a lot. If it were
> extracted, I'd want to have a special jquery+ajax build to go along
> with it.

I think that would be an excellent compromise.  It's actually what I
have pre-built for myself. I have 1 jquery.js and 1 jquery-ajax.js,
both of which are packed and ready to be copied into a project.  I
think it would be great to have that choice for everyone right from
the home page. Or even have a jQuery download generator like the one
for Interface. That way the marketing efforts could claim the smallest
file size of the no-ajax file, and also claim that jQuery "includes"
ajax without being untruthful.

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Rey Bango]

The main suggestion I would have is that if you remove something, make 
it available in either a plugin or some archived form to allow folks to 
take advantage of new features while not breaking their existing apps.

The serialization code for example, could be removed but should be 
accessible in some way for some form of backwards compatibility.

Just my 2 cents.

Rey...

John Resig wrote:
> Hi Everyone -
> 
> I want to start a discussion about the features that should go into
> (or be removed from) the upcoming 1.1 release. I'd like to shoot for a
> release by the end of this month.
> 
> I know that Joern already has some event code, ready to be committed -
> and I have the "non-destructive jQuery" code ready to go. Brandon
> mentioned that he wants to rewrite the jQuery.attr() in time for
> release too.
> 
> No significant features are going to be added to this release, think
> of it as jQuery 1.0++.
> 
> Right now, the jQuery compressed build is teetering around 18-19KB, I
> really want to try and cut this down. Any thoughts on particular
> features that should be extracted into a plugin?
> 
> For example: Since the 'form' plugin already does serialization really
> really well (much better  than jQuery's serialization). I'm tempted to
> remove the serialization plugin from core and just defer everyone to
> using the form plugin.
> 
> Also, stuff like .height() and .width() could be removed in favor of
> using the (more powerful) methods of the same name in the 'Dimensions'
> plugin.
> 
> Let me know if you have any ideas.
> 
> --John
> 
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
> 

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Chris W. Parker]

On Tuesday, November 14, 2006 12:17 PM John Resig <> said:

> I know that Joern already has some event code, ready to be committed -
> and I have the "non-destructive jQuery" code ready to go. Brandon
> mentioned that he wants to rewrite the jQuery.attr() in time for
> release too.

I hope one feature he is adding is that it will return an array of
attributes+values if no data is passed to it.

> For example: Since the 'form' plugin already does serialization really
> really well (much better  than jQuery's serialization). I'm tempted to
> remove the serialization plugin from core and just defer everyone to
> using the form plugin.
> 
> Also, stuff like .height() and .width() could be removed in favor of
> using the (more powerful) methods of the same name in the 'Dimensions'
> plugin.

Both sound like excellent ideas.

> Let me know if you have any ideas.

I don't think it should be modularized too much because then you have
two issues:

1. New people don't know what core plugins to get (unless it's clearly
explained when/why a plugin may be needed on the site).
2. Claiming a small base install is pointless if there's almost zero
functionality.

"Our cars get 100MPG! (As long as there are no passengers and no gravity
and no friction.)"

And lastly...

jQuery is great. I tried to do some stuff with MochiKit but was
compeletly confused (and the list wasn't very friendly either). Now in a
few weeks of experimenting I'm almost familiar with it enough to do
whatever I want (doesn't mean everything, just what *I* want).



Chris.

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[John Resig]

I'm almost inclined to agree. When planning out the structure for the
new documentation I realized that the 'Ajax' section was really more
of a "Design Methodologies/Cookbook" section, more than anything else.
Whereas the core dom/css is more of a toolset of functionality.

That being said - Ajax functionality is used a lot. If it were
extracted, I'd want to have a special jquery+ajax build to go along
with it.

--John

On 11/14/06, Paul McLanahan <[EMAIL PROTECTED]> wrote:
> I'm personally not sure that the entire ajax.js should be part of the
> core.  jQuery to me is about DOM searching and manipulation.  Its Ajax
> features are excellent, but I wouldn't cry at all if I had to include
> the ajax "plugin" or "official extension" or whatever you'd like to
> call it, only when I needed it.  I've actually done this on several
> occasions when I wanted to save some bandwidth and I wasn't using any
> of the ajax features. I've commented out ajax.js from build.xml and
> packed my own ajax-free jQuery and it works great.  It only saves
> around 3k packed, but that's significant when we're talking about <20k
> total. I realize that the politics surrounding not having the "ajax"
> buzzword included in the library by default are a significant issue in
> regards to developer addoption and jQuery marketing in general.  But
> it would further the goal of file size, and it really is pereferial to
> the overall goal of jQuery.
>
> Paul
>
> On 11/14/06, John Resig <[EMAIL PROTECTED]> wrote:
> > Hi Everyone -
> >
> > I want to start a discussion about the features that should go into
> > (or be removed from) the upcoming 1.1 release. I'd like to shoot for a
> > release by the end of this month.
> >
> > I know that Joern already has some event code, ready to be committed -
> > and I have the "non-destructive jQuery" code ready to go. Brandon
> > mentioned that he wants to rewrite the jQuery.attr() in time for
> > release too.
> >
> > No significant features are going to be added to this release, think
> > of it as jQuery 1.0++.
> >
> > Right now, the jQuery compressed build is teetering around 18-19KB, I
> > really want to try and cut this down. Any thoughts on particular
> > features that should be extracted into a plugin?
> >
> > For example: Since the 'form' plugin already does serialization really
> > really well (much better  than jQuery's serialization). I'm tempted to
> > remove the serialization plugin from core and just defer everyone to
> > using the form plugin.
> >
> > Also, stuff like .height() and .width() could be removed in favor of
> > using the (more powerful) methods of the same name in the 'Dimensions'
> > plugin.
> >
> > Let me know if you have any ideas.
> >
> > --John
> >
> > ___
> > jQuery mailing list
> > discuss@jquery.com
> > http://jquery.com/discuss/
> >
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
>

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Olivier Percebois-Garve]

I second this. Often I'm including jquery only in order to use $() +
event handling + DOM manipulation.
I like the Ajax feature, but I use it only marginally. 

Olivvv

Paul McLanahan wrote:

  I'm personally not sure that the entire ajax.js should be part of the
core.  jQuery to me is about DOM searching and manipulation.  Its Ajax
features are excellent, but I wouldn't cry at all if I had to include
the ajax "plugin" or "official extension" or whatever you'd like to
call it, only when I needed it.  I've actually done this on several
occasions when I wanted to save some bandwidth and I wasn't using any
of the ajax features. I've commented out ajax.js from build.xml and
packed my own ajax-free jQuery and it works great.  It only saves
around 3k packed, but that's significant when we're talking about <20k
total. I realize that the politics surrounding not having the "ajax"
buzzword included in the library by default are a significant issue in
regards to developer addoption and jQuery marketing in general.  But
it would further the goal of file size, and it really is pereferial to
the overall goal of jQuery.

Paul

On 11/14/06, John Resig <[EMAIL PROTECTED]> wrote:
  
  
Hi Everyone -

I want to start a discussion about the features that should go into
(or be removed from) the upcoming 1.1 release. I'd like to shoot for a
release by the end of this month.

I know that Joern already has some event code, ready to be committed -
and I have the "non-destructive jQuery" code ready to go. Brandon
mentioned that he wants to rewrite the jQuery.attr() in time for
release too.

No significant features are going to be added to this release, think
of it as jQuery 1.0++.

Right now, the jQuery compressed build is teetering around 18-19KB, I
really want to try and cut this down. Any thoughts on particular
features that should be extracted into a plugin?

For example: Since the 'form' plugin already does serialization really
really well (much better  than jQuery's serialization). I'm tempted to
remove the serialization plugin from core and just defer everyone to
using the form plugin.

Also, stuff like .height() and .width() could be removed in favor of
using the (more powerful) methods of the same name in the 'Dimensions'
plugin.

Let me know if you have any ideas.

--John

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/


  
  
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

  




___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Re: [jQuery] jQuery 1.1 by the end of Nov

[Paul McLanahan]

I'm personally not sure that the entire ajax.js should be part of the
core.  jQuery to me is about DOM searching and manipulation.  Its Ajax
features are excellent, but I wouldn't cry at all if I had to include
the ajax "plugin" or "official extension" or whatever you'd like to
call it, only when I needed it.  I've actually done this on several
occasions when I wanted to save some bandwidth and I wasn't using any
of the ajax features. I've commented out ajax.js from build.xml and
packed my own ajax-free jQuery and it works great.  It only saves
around 3k packed, but that's significant when we're talking about <20k
total. I realize that the politics surrounding not having the "ajax"
buzzword included in the library by default are a significant issue in
regards to developer addoption and jQuery marketing in general.  But
it would further the goal of file size, and it really is pereferial to
the overall goal of jQuery.

Paul

On 11/14/06, John Resig <[EMAIL PROTECTED]> wrote:
> Hi Everyone -
>
> I want to start a discussion about the features that should go into
> (or be removed from) the upcoming 1.1 release. I'd like to shoot for a
> release by the end of this month.
>
> I know that Joern already has some event code, ready to be committed -
> and I have the "non-destructive jQuery" code ready to go. Brandon
> mentioned that he wants to rewrite the jQuery.attr() in time for
> release too.
>
> No significant features are going to be added to this release, think
> of it as jQuery 1.0++.
>
> Right now, the jQuery compressed build is teetering around 18-19KB, I
> really want to try and cut this down. Any thoughts on particular
> features that should be extracted into a plugin?
>
> For example: Since the 'form' plugin already does serialization really
> really well (much better  than jQuery's serialization). I'm tempted to
> remove the serialization plugin from core and just defer everyone to
> using the form plugin.
>
> Also, stuff like .height() and .width() could be removed in favor of
> using the (more powerful) methods of the same name in the 'Dimensions'
> plugin.
>
> Let me know if you have any ideas.
>
> --John
>
> ___
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
>

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

[jQuery] jQuery 1.1 by the end of Nov

[John Resig]

Hi Everyone -

I want to start a discussion about the features that should go into
(or be removed from) the upcoming 1.1 release. I'd like to shoot for a
release by the end of this month.

I know that Joern already has some event code, ready to be committed -
and I have the "non-destructive jQuery" code ready to go. Brandon
mentioned that he wants to rewrite the jQuery.attr() in time for
release too.

No significant features are going to be added to this release, think
of it as jQuery 1.0++.

Right now, the jQuery compressed build is teetering around 18-19KB, I
really want to try and cut this down. Any thoughts on particular
features that should be extracted into a plugin?

For example: Since the 'form' plugin already does serialization really
really well (much better  than jQuery's serialization). I'm tempted to
remove the serialization plugin from core and just defer everyone to
using the form plugin.

Also, stuff like .height() and .width() could be removed in favor of
using the (more powerful) methods of the same name in the 'Dimensions'
plugin.

Let me know if you have any ideas.

--John

___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/