jQuery.support should be deprecated #454
Conversation
|
:bump: |
|
@usmonster Pull requests welcome! :) (which is indicated by the "help wanted" label). |
|
I'd leave I don't think it's worth documenting the |
|
@mzgol Thanks! I was waiting for that feedback before submitting a pull request. :]
...so should it be unpublished now or just deprecated for the time being? |
|
@usmonster: my 2 cents is to just deprecate it for now. |
I meant that we should document the whole |
|
Ok, should I mark it as |
|
Just checking what to put as the version in which it's deprecated.. Hesitating because I assume deprecation usually officially happens at release time? @kswedberg @mzgol |
|
I think it was deprecated in 1.9.0, although it always was pretty poorly documented on purpose and has changed several times since then. |
|
Ah, I thought we were just deprecating it right now.. At least I don't see anything in the 1.9.0 release notes about it. |
|
Ah, looks like it was moved to "unstable" status in 1.8.0: http://bugs.jquery.com/ticket/11766. Though I can just as well mark it as deprecated in 1.9.0.. thoughts, @dmethvin? |
|
Yes, it should have been marked deprecated in 1.9.0, thanks! |
|
No problem, @dmethvin! The pull request is now attached. |
|
Closed by ad3e554 |
- Loosens type of jQuery.each callback's first parameter; common subtype ? preferred to (string|number). - Deprecates jQuery.support (see jquery/api.jquery.com#454). - Adds other possible return values to jQuery.parseJSON (see jquery/api.jquery.com#492). - Loosens return type of `dataFilter` function passed to $.ajax (see jquery/api.jquery.com#492). - Updates `@see` reference to link to proper issue in old tracker. Resolves google#694.
There is some conversation on #451, but the gist is that we want to generally and more explicitly discourage the use of
jQuery.support. And according to @dmethvin, it was an oversight that it's not already listed as deprecated.Seeing as some plugins and frameworks, including jQueries UI & Mobile, currently rely on its existence (even if it is just to add their own internally-used properties to it), there may need to be some more intra-team conversation on the topic of if/when/how to eventually either list it as "removed" or unpublish it altogether from the API.
One immediate concern for the deprecation step is that there are references to it in the doc for
jQuery.cssHooksthat may need to be changed or removed accordingly (possibly in the same pull request?).Thoughts?