On Wed, Oct 8, 2008 at 4:12 PM, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > 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.
I'm used to XPath semantics, which seem to require existence. Now, if everybody else use a different interpretation, that is of course ok with me. > 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 run IE 6 in CodeWeavers CrossOver Mac. Quite nice to have the full battery of browsers available... (except IE 7 though) > Yes. If the benchmark tests are to be trusted, that simply means that > the trunk version (which should behave like Prototype did, although > they may have changed the selector engine in Prototype now) is > incorrect. I'll look into what tests are failing and what the > standards have to say about them. If it really is incorrect, all the > more reason to move to a new implementation. Naturally, but I would have to fix the old implementation for the 1.4 release. Or not include it at all. Or document it as "experimental". Or something. >> 6. There seems to be an unnecessary whitespace change in >> MochiKit/MochiKit.js. > > There are? The only change I can see is the reording of submodules - > since Selector now depends on Style I had to switch their order. Or do > you mean packed/MochiKit/MochiKit.js? My bad. I got confused by the web diff view in Trac. > That is probably a mistake, it should definitely be in the docs. I > will fix this in the trunk. Great, thanks! >> 9. Note that when testing $$ in Safari, you are really only using the >> built-in support for document.querySelectorAll (unless that function >> throws an error). So adding or modifying functionality requires that >> the query is checked before using document.querySelectorAll. > > 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). What I was trying to say is that if querySelectorAll returns a result that is inconsistent with the JS implementation, then we're in trouble. If it throws an error (as it presumably does when using non-standard stuff), we already fallback to the JS-implementation, so that should work. We really need to make sure that our test suite has good test coverage. Then if we encounter issues in Safari, we can handle those by searching for those patterns in the query before calling querySelectorAll. >> 10. I'm not afraid of regexps, but the "chunker" one in the code is >> just ridiculous. It is much too dense to be in any kind of production >> code without proper comments and/or explanations as to its function >> and use. > > This is another comment for John I guess. I don't necessarily agree > with you though, its function was relatively clear after pasting it > into http://regexpal.com/ and playing with it for a minute. Possibly. But I'd still like some comments... :-) BTW, John. I saw your recent Sizzle commit and commented it on github. Cheers, /Per --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
