Just a note on that last bit pradador: I changed it to false and it
broke the selector feature when using dom traversal, like getParent
('blah') no longer worked when parent is really blah.someClass, even
though it should.I think this is something requiring further investigation, but hopefully unit tests would prevent breakage like this. On Apr 3, 11:52 am, pradador <[email protected]> wrote: > Looks good but there's one bit that I'm not sure about. > > return (parsed) ? Selectors.Utils.filter(this, parsed, {}) : true; > > That statement returns true if you pass an invalid selector. For > example, $('myDiv').match('()*mootools'); returns true even though the > selector is whacked. I think this should be changed to return false. > > On Apr 3, 8:41 am, Jacob <[email protected]> wrote: > > > > > Ok, so I think I found the root of the problem here. If I pass an > > element as the thing to match, this method still fires > > > Selectors.Utils.parseTagAndID(selector); > > > which throws an error since this method assumes "selector" is a > > string. > > > I have no idea how this assumption was reached, but by putting an > > extra switch to test for the $type() of the selector, I was able to > > avoid calling this entire section of code. > > > Now my .match() method looks like: > > > match: function(selector){ > > if (!selector) { > > return false; > > } else if (selector === this) { > > return true; > > } else if ($type(selector) === "string"){ > > var tagid = Selectors.Utils.parseTagAndID(selector); > > var tag = tagid[0], id = tagid[1]; > > if (!Selectors.Filters.byID(this, id) || > > !Selectors.Filters.byTag > > (this, tag)) return false; > > var parsed = Selectors.Utils.parseSelector(selector); > > return (parsed) ? Selectors.Utils.filter(this, parsed, {}) : > > true; > > } > > return false; > > > } > > > Am I totally missing something here, or does this sound reasonable? > > > On Apr 3, 9:41 am, Jacob <[email protected]> wrote: > > > > +1 > > > Thanks for all the help! > > > So, does this mean a mootools committer needs to file this as a bug, > > > or should/can I? > > > > Also, on a small selector tangent, I think there is a bug with > > > the :contains() pseudo selector. For example, lets say you have this > > > markup: > > > > <a href="foo" title="A link">Click Me</a> > > > > So a selector like this should work: $$('a:contains(Click Me)') , > > > right? It doesnt for me. Only this works: $$('a:contains(Click)') . > > > > Same thing for attribute selectors. This doesnt work: $$("a[title=A > > > link]"). Rather, I have to do this: $$("a[title*=A link]"). > > > > I wrote a post about this a couple months back. Is this a bug too? > > > Does it need to be logged? > > > > I would like to be more helpful in documenting these types of things. > > > > Thanks > > > Jacob > > > > On Apr 3, 6:01 am, daKmoR <[email protected]> wrote: > > > > > On Apr 3, 10:37 am, Tom Occhino <[email protected]> wrote: > > > > > > I think we should probably tweak match to return false as the base > > > > > case... If you pass no selector or an undefined / null selector, it > > > > > would make sense to return false imo.. > > > > > +1
