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 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 DO
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 f
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 feat
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 hav
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 maili
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
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 documentat
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 t
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 surpr
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
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 funct
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
pack
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
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 th
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 th
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 1
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:
> J
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
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 files
ne. 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
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
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(o
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 f
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
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!
I
> 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, o
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 th
> 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 conte
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 availa
> 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 l
> > 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 documenta
> 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
> > 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 han
er 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
;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] jQu
ay?
>>
>> 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"
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 argum
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 additi
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 m
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 d
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
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)...
> > 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.
>
> > 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
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
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 t
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 i
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 l
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 a
> 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" w
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*
L 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 n
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
t
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
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
>>
> 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.
Cu
> > 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
> 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 MooT
> 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/d
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 pack
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/
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@j
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 helpe
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,
tha
> 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 w
> 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
> > 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
> > 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
>
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.
>
>
> 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
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 exac
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
clea
> 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 re
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
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
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
bject: 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
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 w
ay, 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]
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 th
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
> 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 yo
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
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 prefera
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
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 whic
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 figu
94 matches
Mail list logo
