> The problem with removing all the helper methods is that
> some are very heavily used (especially val and click).
> While that may reduce jQuery's file size, it will increase
> the size of many plugins and pages that use jQuery.
I don't think it will increase plugins or user code by more than a few
characters:
Old: .click(fn)
New: .on("click", fn)
It also eliminates a line or two of runtime checks in the core code, since
the current name overloading has to be disambiguated ("Is it setting click
handlers or triggering them?") on each call.
> Moving out of core may be a good idea if file size really is
> that important ...
It's not just a question of file size, but of namespace pollution,
consistency, and documentation complexity.
> ...it would still be good if these (or at least the most
> used ones) were still part of the default download...
I have a feeling that the compat plugin will have to be part of the standard
1.2 distribution given how many people currently use things like .click()
and .val(). The long term goal is to remove and un-document them from the
core, making them eventually optional; plugin writers should not assume they
are part of the core because that will create a dependency on the compat
plugin and lead to bloat.
> $( "div" ).bind( "click", function() {
> doClick();
> }, {amount: 1} );
It would be more layout-friendly if the function could be the last argument,
since there may be several lines of code in the bound function. The object
at the end "gets lost" in the code layout. You could check for
arguments.length and decide whether there was an object in the second
argument or not. I can live with either one though.
> $().bind("click", function(event, bindData, triggerData) { ... });
This one gets my vote. It saves the cost of extending the event object and
eliminates the risk of clobbering a name in the original event
object--although clobbering some original event properties could be
considered a feature I guess. Just a thought about triggerData: if the
trigger cutoff ("amount" above) is in there, what effect would it have if
the handler modifies that? (I'm just trying to separate intended from
unintended effects.)
> I wonder if it would help to extend [ css() and attr() ] to
> allow getting of multiple properties at once. A possible
> implementation would accept an array of String and returns
> a key/value object, with the values of the array as the keys.
I proposed .attrs() but that was to solve a problem that got solved in
another way. Given the push to shrink and simplify the core, I'd wait until
we find a nail needing that hammer. :-)
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
