would like to contribute with my NWMatcher selector engine if deemed
adequate for the task. Would probably need a rewrite to fit style.

I hope there is no need to say that Samuel Lebeau already did it in
part, he rewrote it in a way that is probably more adequate to
Prototype and has a more semantic look and functionality (see Bouncer
link above in kangax post). I admit NWMatcher currently try to achieve
and fix to much problems for IE. But that's life.

Probably the only drawback in Samuel code is that so many calls will
add a bit of extra time, also the advantage is that he made possible
to avoid the "new Function()" constructor. I use that to compile CSS
selectors to javascript function matchers, reduced to the most compact
form, with the results I got it's hard to say "new Function()" is a
bad thing, but this seems a debatable argumentation.

I wouldn't go in a speed comparison with others, I prefer to shine in
compliance and specs, and if there is space add tasteful things.

Currently NWMatcher passes 190 of the 192 tests that Samuel kindly did
setup for me, it is in the GIT repository (in /test).

- support for XML and generic "namespaced" attributes
- return a "document ordered" node list as required by specs (as
querySelectorAll does)
- coerces white spaces in class names to a single space before
comparison (as for specs)
- compare upper and lowercase tag names, since in the DOM both cases
may exists or be created
- full support for attribute selector, fixing most of the bugs bound
to getAttribute on IE
- takes care of other bugs especially those related to comment nodes
and forms
- supports all the new CSS3 "nth" selectors and the "of-type" variant
- support ":not" ":empty" and most of the common pseudo selector
- it has a configurable caching system (disabled by default on IE)
- it uses "querySelectorAll" where available (currently only Safari)
- offers a fast "match(element, selector)" method very useful in event
- it is easy enough to expand and maintain, again thanks to Samuel for
the help with this

Well the list will look ugly, but is just a fast write down of the
features I remember.

Let me know if I can help with extra informations about it.

Diego Perini

On 23 Ott, 01:59, Tobie Langel <[EMAIL PROTECTED]> wrote:
> Proper benchmarking (i.e. something more reliable than slickspeed)
> would be very useful for making such a decision.
> Furthermore, I'd hate 1.6.1 to be delayed by such a change, especially
> given the fact that there's more important stuff to handle first (like
> the bug backlog, or dropping DOM element extension).
> Best,
> Tobie
> On Oct 22, 11:06 pm, Nick Stakenburg <[EMAIL PROTECTED]> wrote:
> > Sizzle[1] is probably closer to a stable release, John mentioned
> > releasing it before the end of the month. Looking at those benchmarks,
> > having something similar wouldn't hurt (1.6.1?).
> > [1]
> > --
> > Nick
> > On 22 okt, 15:58, Simon <[EMAIL PROTECTED]> wrote:
> > > Hi everyone,
> > > recently I heard about Peppy (, a new
> > > selector engine that is definetly one of the fastest around (http://
> > >
> > > I was wondering if there was a main reason why prototype is so slow
> > > compared to it, is it all about extending resulting nodes or is it
> > > that our engine is a bit obsolete. Plus, is there actually some people
> > > in charge of the rewritting of this module and if not, is there a
> > > possibility to port some routine of Peppy to Prototype to benefit from
> > > it?
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to