> I disagree. Being able to set all the (useful) properties of a DOM
> element via a single object structure can be very useful - and I see
> no reason not to overload the existing .attr() behavior if it already
> covers most of the functionality well and if there are no conflicts. I
> especially think that it's important to integrate it into .attr() so
> that we can effectively deprecate "bad" ways of setting DOM attributes
> or properties. For example, instead of doing .attr("innerHTML", "some
> html") we can offer the much saner .attr("html", "some html") same
> with .attr("onclick", fn) becoming .attr("click", fn) - both of these
> are removing the weirdness of the existing DOM APIs by providing
> something that's much better.Rethinking, maybe I was too hard with objections, and your arguments are mostly valid. However, there are some problems (for me) that are brought by introducing attrFn. Firstly, you are using attrFn "magic" with XML documents too. I hope it is not intentional. Secondly, you are exposing attrFn to jQuery. This would be dangerous if used by users that would be able to overwrite and break attr() very easily. In production scenario it would be very bed. At the end, I would be more careful by filling attrFn (i.e. data, append, prepend). > Placing this in a separate function creates un-needed ambiguity. I > dislike it for the same reason that I dislike having an extra .prop() > method for setting just DOM object properties. We should be able to > provide a unified API for setting information (called 'attr' in > jQuery, mostly for legacy reasons - it actually was 'set' back when > jQuery was first released) and work to meet the user's expectations > based upon that. Well, I am not a fan of adding set() (or similar) either. > How's that? .live() has seen considerable improvements since 1.3.2 > both in the form of features (context limiting, data support), cross > browser compatibility (submit, change, focus, blur, mouseenter, > mouseleave), and performance (huge speed-ups to .closest() and node > checking). Certainly it wasn't in my intention to diminish the great job done in that area. However I am not a fan of the current live() API because it is not giving full control to me (see http://groups.google.com/group/jquery-dev/browse_frm/thread/1240ad6bc98693af#). For that reason I am generally using manual delegation instead of live (). > As far as I know I've also landed every patch you've > submitted to the jQuery Github fork queue. Perhaps there's something > else that you're not divulging? If I am still not divulging something, it is because it is still only a vague idea or it is not good enough to me (I am lazy). Although I am not liking everything in the API, I haven't pushed patches (making pull request) that would change the API. If I will do that, that will be only after discussing it, and with your agreement. Of course. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
