Side navigation
#7389 closed enhancement (wontfix)
Opened November 03, 2010 02:52PM UTC
Closed July 12, 2011 03:01PM UTC
Last modified March 13, 2012 03:20PM UTC
change .selector property into .selectors array
| Reported by: | cowboy | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | selector | Version: | 1.4.3 |
| Keywords: | 1.7-discuss | Cc: | |
| Blocked by: | Blocking: |
Description
I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the .selector property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.
In fact, other than for events, I don't see the value in the current .selector property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.
I propose that the .selector string property be changed to a .selectors array property, with the .selector property reflecting the last *actual* selector string used. For example:
var elems = $('div').children('p');
elems.selector // 'p'
elems.prevObject.selector // 'div'
elems.selectors // [ 'div', '.children(p)' ]
elems.prevObject.selectors // [ 'div' ]
This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.
The .selectors array could even be an array of hashes, like so:
var elems = $('div').children('p');
elems.selector // 'p'
elems.prevObject.selector // 'div'
elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]
elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]
Of course, at this point, since you already have the simple .selector property, you could forgo the array altogether and just add a .methodname property:
var elems = $('div').children('p');
elems.selector // 'p'
elems.prevObject.selector // 'div'
elems.methodname // 'children'
elems.prevObject.methodname // 'jQuery'
Either way, a non-string-property-approach might help avoid possible confusion from people who think that the .selector property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.
Attachments (0)
Change History (18)
Changed November 03, 2010 06:09PM UTC by comment:1
| owner: | → cowboy |
|---|---|
| status: | new → pending |
Changed November 03, 2010 06:43PM UTC by comment:2
| status: | pending → new |
|---|
Benefits:
- a slightly smaller and simpler jQuery
- less end-user confusion (around both the
.selectorvalue and.livemethod behavior, or even the very simple but unexpected behavior in #6754) - with the array of hashes /
.methodnameproperty approach, the traversal/filtering methods and selectors used could be programmatically derived without complex string parsing
Changed November 03, 2010 08:01PM UTC by comment:3
| component: | unfiled → selector |
|---|---|
| priority: | undecided → low |
| status: | new → open |
I think it's pretty fair to say that the current behavior doesn't make sense in a lot of common cases. In the case of just string concatenated dom traversal stuff, it's completely useless. I think, while this is largely unimportant since no one should be relying on the .selector property, that it couldn't hurt to consider it in a future build, just so we have something that can at least be consistent.
Changed November 04, 2010 12:02AM UTC by comment:4
Hmmm, I didn't even think we documented
.selectorpublicly, but why the heck are people trying to look at it? We know it doesn't survive complex traversal or filtering methods. Saying "don't touch that" in the docs saves us the code of trying to fix it and still falling short.
Changed November 13, 2010 11:51AM UTC by comment:5
The .selector property is documented here and has been for quite some time, IIRC.
Changed April 16, 2011 10:40PM UTC by comment:6
| milestone: | → 1.7 |
|---|---|
| owner: | cowboy |
| status: | open → assigned |
Let's look at this for 1.7.
Changed April 16, 2011 10:59PM UTC by comment:7
| milestone: | 1.7 → 1.next |
|---|
Changed May 22, 2011 07:27PM UTC by comment:8
| keywords: | → 1.7-discuss |
|---|
Nominating ticket for 1.7 discussion.
Changed May 22, 2011 09:38PM UTC by comment:9
| description: | I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements. \ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place. \ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ 'div', '.children(p)' ] \ elems.prevObject.selectors // [ 'div' ] \ }}} \ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic. \ \ The `.selectors` array could even be an array of hashes, like so: \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ] \ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ] \ }}} \ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.methodname // 'children' \ elems.prevObject.methodname // 'jQuery' \ }}} \ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations. \ → I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.\ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.\ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ 'div', '.children(p)' ]\ elems.prevObject.selectors // [ 'div' ]\ }}}\ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.\ \ The `.selectors` array could even be an array of hashes, like so:\ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]\ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]\ }}}\ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.methodname // 'children'\ elems.prevObject.methodname // 'jQuery'\ }}}\ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.\ |
|---|
-1, A huge burden that will require managing entries to the array... which means all existing methods would have to bear the addition of at least one function being added to their call stack. -9001
Changed May 23, 2011 12:20AM UTC by comment:10
-1, sounds like a cheap and horrible way to construct selection... and a means to actually do terribly wrong things in general
Changed May 23, 2011 03:58AM UTC by comment:11
-1, might make selector more useful, but entirely unnecessary.
Changed May 31, 2011 04:21PM UTC by comment:12
| description: | I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.\ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.\ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ 'div', '.children(p)' ]\ elems.prevObject.selectors // [ 'div' ]\ }}}\ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.\ \ The `.selectors` array could even be an array of hashes, like so:\ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]\ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]\ }}}\ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.methodname // 'children'\ elems.prevObject.methodname // 'jQuery'\ }}}\ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.\ → I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements. \ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place. \ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ 'div', '.children(p)' ] \ elems.prevObject.selectors // [ 'div' ] \ }}} \ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic. \ \ The `.selectors` array could even be an array of hashes, like so: \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ] \ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ] \ }}} \ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.methodname // 'children' \ elems.prevObject.methodname // 'jQuery' \ }}} \ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations. \ |
|---|
-1, Not a fan of .selector at all.
Changed June 03, 2011 01:43PM UTC by comment:13
| description: | I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements. \ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place. \ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ 'div', '.children(p)' ] \ elems.prevObject.selectors // [ 'div' ] \ }}} \ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic. \ \ The `.selectors` array could even be an array of hashes, like so: \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ] \ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ] \ }}} \ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.methodname // 'children' \ elems.prevObject.methodname // 'jQuery' \ }}} \ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations. \ → I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.\ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.\ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ 'div', '.children(p)' ]\ elems.prevObject.selectors // [ 'div' ]\ }}}\ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.\ \ The `.selectors` array could even be an array of hashes, like so:\ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]\ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]\ }}}\ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.methodname // 'children'\ elems.prevObject.methodname // 'jQuery'\ }}}\ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.\ |
|---|
+1, I like this - it makes what we originally wanted to do with .selector actually possible (do all sorts of after-the-fact stack manipulation). This would be a very easy change given that we already handle all of this in pushStack.
Changed June 03, 2011 03:19PM UTC by comment:14
| description: | I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.\ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.\ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ 'div', '.children(p)' ]\ elems.prevObject.selectors // [ 'div' ]\ }}}\ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.\ \ The `.selectors` array could even be an array of hashes, like so:\ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]\ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]\ }}}\ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.methodname // 'children'\ elems.prevObject.methodname // 'jQuery'\ }}}\ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.\ → I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements. \ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place. \ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ 'div', '.children(p)' ] \ elems.prevObject.selectors // [ 'div' ] \ }}} \ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic. \ \ The `.selectors` array could even be an array of hashes, like so: \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ] \ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ] \ }}} \ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.methodname // 'children' \ elems.prevObject.methodname // 'jQuery' \ }}} \ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations. \ |
|---|
I'd encourage everyone to look at #9469 and then from there, continue discussion of the .selector property. I think combining the ideas from that ticket with this one might be the best approach.
Changed June 03, 2011 03:36PM UTC by comment:15
| description: | I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements. \ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place. \ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ 'div', '.children(p)' ] \ elems.prevObject.selectors // [ 'div' ] \ }}} \ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic. \ \ The `.selectors` array could even be an array of hashes, like so: \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ] \ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ] \ }}} \ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.methodname // 'children' \ elems.prevObject.methodname // 'jQuery' \ }}} \ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations. \ → I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.\ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.\ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ 'div', '.children(p)' ]\ elems.prevObject.selectors // [ 'div' ]\ }}}\ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.\ \ The `.selectors` array could even be an array of hashes, like so:\ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]\ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]\ }}}\ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.methodname // 'children'\ elems.prevObject.methodname // 'jQuery'\ }}}\ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.\ |
|---|
+0, no opinion, this is all internal, right?
Changed June 05, 2011 09:00PM UTC by comment:16
| description: | I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.\ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.\ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ 'div', '.children(p)' ]\ elems.prevObject.selectors // [ 'div' ]\ }}}\ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.\ \ The `.selectors` array could even be an array of hashes, like so:\ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]\ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]\ }}}\ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.methodname // 'children'\ elems.prevObject.methodname // 'jQuery'\ }}}\ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.\ → I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements. \ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place. \ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ 'div', '.children(p)' ] \ elems.prevObject.selectors // [ 'div' ] \ }}} \ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic. \ \ The `.selectors` array could even be an array of hashes, like so: \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ] \ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ] \ }}} \ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.methodname // 'children' \ elems.prevObject.methodname // 'jQuery' \ }}} \ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations. \ |
|---|
-1, I like the idea of dropping this in #9469 and I definitely don't think we should spend our cycles working on getting this "right" if it's impossible.
Changed June 06, 2011 03:58PM UTC by comment:17
| description: | I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements. \ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place. \ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ 'div', '.children(p)' ] \ elems.prevObject.selectors // [ 'div' ] \ }}} \ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic. \ \ The `.selectors` array could even be an array of hashes, like so: \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ] \ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ] \ }}} \ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.methodname // 'children' \ elems.prevObject.methodname // 'jQuery' \ }}} \ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations. \ → I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.\ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.\ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ 'div', '.children(p)' ]\ elems.prevObject.selectors // [ 'div' ]\ }}}\ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.\ \ The `.selectors` array could even be an array of hashes, like so:\ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]\ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]\ }}}\ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.methodname // 'children'\ elems.prevObject.methodname // 'jQuery'\ }}}\ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.\ |
|---|
+0
Changed July 12, 2011 03:01PM UTC by comment:18
| description: | I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.\ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.\ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ 'div', '.children(p)' ]\ elems.prevObject.selectors // [ 'div' ]\ }}}\ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.\ \ The `.selectors` array could even be an array of hashes, like so:\ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]\ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]\ }}}\ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property:\ \ {{{\ var elems = $('div').children('p');\ \ elems.selector // 'p'\ elems.prevObject.selector // 'div'\ \ elems.methodname // 'children'\ elems.prevObject.methodname // 'jQuery'\ }}}\ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.\ → I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the `.selector` property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements. \ \ In fact, other than for events, I don't see the value in the current `.selector` property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place. \ \ I propose that the `.selector` string property be changed to a `.selectors` array property, with the `.selector` property reflecting the last *actual* selector string used. For example: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ 'div', '.children(p)' ] \ elems.prevObject.selectors // [ 'div' ] \ }}} \ \ This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic. \ \ The `.selectors` array could even be an array of hashes, like so: \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ] \ elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ] \ }}} \ \ Of course, at this point, since you already have the simple `.selector` property, you could forgo the array altogether and just add a `.methodname` property: \ \ {{{ \ var elems = $('div').children('p'); \ \ elems.selector // 'p' \ elems.prevObject.selector // 'div' \ \ elems.methodname // 'children' \ elems.prevObject.methodname // 'jQuery' \ }}} \ \ Either way, a non-string-property-approach might help avoid possible confusion from people who think that the `.selector` property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations. \ |
|---|---|
| resolution: | → wontfix |
| status: | assigned → closed |
Per the 1.7 vote this isn't going to be implemented.
Other than avoiding any more confusion from people that ignore the documentation (which states “if DOM traversal methods have been called on the object, the string may not be a valid jQuery selector expression”), what sort of use cases are there for providing this?