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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Original-Nachricht
Datum: Tue, 14 Nov 2006 16:24:12 -0500
Von: Rey Bango [EMAIL PROTECTED]
An: jQuery Discussion. discuss@jquery.com
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
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
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
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
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
.
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
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
-
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
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
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
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
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
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
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
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
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
Yep. I used my patch to write an additional plugin that allowed:$(div[height10])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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
] 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
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
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
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
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
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
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
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
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
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
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
://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
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:
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
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
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. discuss@jquery.com
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov
I think over all
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
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
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
74 matches
Mail list logo
