Remove semi-functional .selector calculation from .pushStack()

[dmethvin]

Per discussion with ben_alman, and related to #7389 which consensus says won't happen.

The .selector property can't be reliable since there are simple ways to construct a set that can't be represented by a CSS selector. We've documented those shortcomings in the API docs for .live() and .selector but it's still a frequent source of questions and errors.

It would simplify the code for .pushStack() and its callers if it didn't try to maintain the .selector property at all, which is still in keeping with our documented use of .live() immediately after a $() set creation.

In addition we should deprecate non-core use of .selector and remove the documentation from the API site eventually.

All to be done over several versions, with sufficient advance warning in the docs before breaking anything.

[cowboy]

See my 3rd idea here: ​https://gist.github.com/1000934

[john]

Eventually we should do this, for sure, but only when we have some alternative to switch to. Right now we're using .selector inside jQuery for live so we definitely want to maintain it.

[anonymous]

A quick question:

Since .selector seems to have been removed from the docs, and .live doesn't support chaining, would it be possible to remove the .selector constructing code in .pushStack now?

[dmethvin]

Hmmm, it might. We still need to set .selector since .live() needs it, but the only other chaining I've seen in the wild is $(sel).find(sel).live(). Reopening to take a look around.

[dmethvin]

Bulk change from enhancement to feature.

[Dave Methvin]

Fix #9469. Remove semi-functional .selector property. Close gh-1006.

Saved 65 bytes.

Changeset: 69e2f068fe7d16c1ccd6cb99c6376f0d8891ea33