Hi,

> I realize that, but do you all think that this is the expected
> behavior?

Yes.  To me, as Maarten pointed out, this:

    $('foo').select('div.div_a > span.span_a')

is equivalent to this CSS selector:

    #foo div.div_a > span.span_a

which says to select all "span_a" spans that are direct children of
any "div_a" div that is a descendant of #foo.  That latter criterion
would not include #foo even if #foo is a div.div_a, because #foo is
not a descendant of itself.

I would find the other behavior surprising.  Again, I can understand
how you (and apparently others) got there, but that's not the behavior
I would be expecting.
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available


On Mar 9, 12:16 am, Marc Liyanage <liyan...@gmail.com> wrote:
> On Mar 8, 5:34 pm, Quleczka <qulec...@gazeta.pl> wrote:
>
> > On 8 Mar, 14:51, Marc Liyanage <liyan...@gmail.com> wrote:
>
> > > From my experiments I get the impression that the select() context
> > > element and all of its ancestors are completely taken out of the
> > > selector match calculation.
>
> > Exaclty :)
>
> > It selects from elements INSIDE of given one. So it can find only 2
> > elements because first one is not considered as matching the rule
> > 'div.div_a > span.span_a' cause first div is the one you use to call
> > select function.
>
> I realize that, but do you all think that this is the expected
> behavior?
>
> I would not expect the implementation to *select* elements outside of
> the context scope, but I would definitely expect it to consider such
> elements for the *selector evaluation*. In my mind, the selector
> evaluation is absolute and independent of the context node, only
> considering the structural relationships.
>
> In this case, the first span
>
> 1.) *has* a parent div.div_a after all, and that is what the selector
> says (and this part has nothing to do with the context element), and
> 2.) it *is* a descendant of the select() context element
>
> so I think it should be selected.
>
> The implementation as it is now mixes up these two things, in a way
> that is really suprising for me. I'm not saying it's wrong, but if
> this is intended, I think the documentation should mention that the
> context node does influence the selector evaluation.
>
> @Tobie
>
> I just read what Resig wrote and this is interesting:
>
> > This is due to the fact that element-rooted queries are handled by "finding 
> > all the elements that match the given selector -- rooted in the document -- 
> > then filtering by the ones that have the specified element as an ancestor." 
> > This is completely unacceptable. Not only is it not intuitive [...]
>
> To me this is *exactly* the way I would have expected it to work. I
> guess what's intuitive for one person is surprising for the next :-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to