Response title
This is preview!
- Screen name: borgar.net
- Website:
borgar.net's Profile
3 Posts
9 Responses
0
Followers
Activity Trend
Last 30 days
- Last 30 days
- Date Interval
From Date : To Date :
Loading Chart...
Show:
- Expanded view
- List view
Private Message
- 03-Nov-2010 12:02 PM
- Forum: Developing jQuery Core
This ticket reports the problem that closest on unattached fragments crashes on attribute selectors:- $('<div>ff</div>').closest('#foo'); // => []
- $('<div>ff</div>').closest('.foo'); // => []
- $('<div>ff</div>').closest('strong'); // => []
- $('<div>ff</div>').closest(':input'); // => []
- $('<div>ff</div>').closest('[lang]'); // => TypeError
Every other selector seems to work fine though. It's closed with the argument:You can't call closest() on a document fragment that hasn't actually been appended into the DOM. [...] This is not a jQuery bugWhy not? The docs don't mention that restriction (I may have missed it). And there doesn't seem like there is any obvious technical reason why not?Also, if this is the reality, is there a recommended method of testing if a jQuery collection is attached to the document to avoid crashes in my plugins? (What if some elements in a collection are attached but not others?)- 02-Feb-2010 08:53 AM
- Forum: Developing jQuery Core
It seems that 1.4 exposed a new $.getText utility function, which breaks my translation plugin. Or rather: My translations plugin - which uses $.getText - breaks $.text because it overwrites an undocumented $.getText function, which $.text depends on.Some questions:1. Why is this function not documented?2. Why doesn't jQuery refer internally to getText function rather than jQuery.getText? Is this to save on the closure?3. Why is this function not consistently named like other jQuery utlity functions?- $.extend => $.fn.extend
- $.data => $.fn.data
- $.each => $.fn.each
- $.map => $.fn.map
- $.find => $.fn.find
vs.- $.getText => $.fn.text
Is there any reason not to use $.text == $.fn.text?Admittedly, I am moaning over this for purely selfish reasons: Namely, because I would like to keep my plugin working consistently with other getText interfaces in the world and not have to namespace it into something like $.i18n.getText (although I probably will).But wouldn't it make more sense to use $.text, instead of the already well established standard name for a translation service?I've just filed a bug with ajax context which, in a nutshell, is that a clone of the context object is passed into the callbacks rather than the object itself. This pretty much makes the object read-only.
Current code:
- ajax: function( origSettings ) {
- var s = jQuery.extend(true, {}, jQuery.ajaxSettings, origSettings);
- var jsonp, status, data,
- callbackContext = s.context || s,
Looking at this, it has just occurred to me that jQuery.ajax is unnecessarily deep cloning the context object, which is a big literal object "namespace".
Isn't this a potential scaling problem; since the need for context correlates with the context object's complexity? (bigger namespace => more need for context => more to extend => slower ajax calls).
Perhaps a better way to handle this is to remove the context property reference of origSettings while extend does it's work?
In any case, I guess my question is: Is this something that is a real concern and will get addressed, or do I rethink the way I shape my namespaces?- «Prev
- Next »
Moderate user : borgar.net
© 2012 jQuery Foundation
Sponsored by 
and others.
