Hey Everyone -
> Ah, ok. I just thought the test was buggy. != is not actually defined
> by CSS3, so I went by the jQuery definition which is this:
>
> "Matches elements that either don't have the specified attribute or do
> have the specified attribute but not with a certain value."
>
> I.e. it explicitly says it matches elements w/o that attribute. Of
> course this is no standard, if you think we should use the other
> semantics I don't mind.
Obviously we can discuss this some more but my interpretation of [attr!
=value] was that it was equivalent to :not([attr=value]).
> Yes, I'm actually not sure what the status on Sizzle development is -
> but John has at least not updated the github version since posting it
> originally. Unfortunately I don't have access to IE6 or time to set up
> a virtual machine - but if you try debugging it I'd be happy to help
> with the little insight I gained last night.
I got bogged down here recently but I'm starting back up (since I want
to be able to land this for jQuery 1.3 this month). What sort of
timeline are you guys on for your 1.4 release?
> I would also vote against pushing this to a release as it stands now.
Naturally - IE support is still a minefield.
> I will have a look at the tests and confirm what is the correct
> outcome. Safari was also failing on several unit tests for me, I will
> also look at that tonight.
Let me know if the NodeList/Array mis-match exists, I can look in to
that.
> Ok, I'll start work on that too. I think I would move everything
> inside Sizzle (and submit a patch to John) and then move Sizzle into
> MochiKit.Selector. It should be easy, just a little legwork.
I was planning on just encapsulating all the functionality and
selectively exposing it where needed, specifically:
(function(){
...
var Sizzle = this.Sizzle = function(){
...
};
})();
No need to namespace the random state variables that are used
internally.
> > 8. The Sizzle result cache seems to break if people start manipulating
> > the returned arrays (using shift, pop or similar). Basically this:
>
> > return cache && doCache ?
> > (cache[ selector ] = results) :
> > results;
>
> > should become:
>
> > if (cache && doCache) {
> > cache[selector] = results.slice(0);
> > }
> > return results;
>
> Ok, I'll have a look. Otherwise this is a comment for John I guess.
That seems like a reasonable change.
> Right, I'm not sure what is best to do here. Should we rely on
> querySelectorAll where it is available - simply to have the best
> performance, or is identical semantics on all browsers more important?
> For the latter there are two ways, don't use querySelectorAll (and
> take the performance penalty) or strip out the features not supported
> by it (and take the feature penalty).
Right now there is no feature penalty to using querySelectorAll.
Sizzle just falls back to the old selector code, if qSA doesn't know
how to handle a selector. If something isn't working correctly in this
regard then it should definitely be fixed.
> This is another comment for John I guess. I don't necessarily agree
> with you though, its function was relatively clear after pasting it
> intohttp://regexpal.com/and playing with it for a minute.
I could attempt to explain it a little bit more with comments, I
guess. I'll see what I can do.
> Right, there are several "bugs" of this kind in Sizzle already.
I'll look in to the one mentioned here.
Thanks for the review guys, I appreciate it!
--John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
