Comments for sstephenson's prototype  

I'm going to rewrite this function entirely. I might not even need it.

You're right. I'll fix the behavior of getOffsetParent instead.

This fixes a quirk where getBoundingClientRect doesn't return proper offsets for the BODY tag. The margin of error is weird but predictable (something like 8px off horizontally and 12px off vertically).

That bug is convenient here, but getOffsetParent should probably do the right thing and return the BODY element on IE6. I remember that it was once fixed but it was reverted to clean up a 1.6.0.3 release.

Could still use the logic behind the bug to test but perhaps there's a better way. What quirk does this fix?

@dperini What about:

function isRootElement(element) { 
  return element.tagName.toUpperCase() === 'HTML'; 
}
// is BODY a root element?
if (document.documentElement.clientWidth === 0) {
  isRootElement = function(element){ 
    return element.tagName.toUpperCase() === 'BODY'; 
  };
}

However, I think this won't really work with multiple documents (where an element whose tagName is "HTML" might not be a root ancestor of an element in question).

I dig the suggested "isRootElement" name !

This is only a problem in IE browsers so I still think that for those browsers a load time feature test is better.
FT should check which one of HTML or BODY is considered the actual "root" element in that browser and in that specific page.
In IE I have successfully used the "compatMode" property or "DOCTYPE" sniffing using "systemId" and "publicId" properties of "doctype" object.

This is pretty slow and eats memory. The sugar is not worth perf. loss here, imo. Can we replace this with — var nodeName = element.nodeName.toUpperCase(); return nodeName === 'BODY' || nodeName === 'HTML'? I would also rename this method to — isRootElement, following CSS terminology.

I have a version around where I also added the "data" & "callback" functionality to the match() method.

Looking to the above adapter, I was wondering if it could be really useful to have something like this:

NWDom.match(element, selector, results, Element.extend);

results will be augmented and callback invoked only if element matches. Seems a good shortcut to me.

What do you think ?

Agreed, or even Legacy.Selector, Legacy being a namespace for legacy stuff.

Doesn't Legacy sound ambiguous? Why not name it LegacySelector?

@tobie @kangax - 10x for explanations, actually my fail was understanding how NW.select works, and I thought that only NW.select could be used without callback and results.

I would go with results.push(Element.extend(element)) too.

@RStankov Element.extend is essentially Prototype.K (function returning first argument) in browsers that support host objects' prototype extensions.

It is, actually. It's an empty function.

or even results.push(Element.extend(element)) which is used throughout the framework

element = Element.extend(element) still works if it's a proxy.

I'm wondering if Element.extend could be skipped, and used only if current browser doesn't support element prototype extensions ?

This closing parenthesis breaks the link sorry, here it is again : http://github.com/samleb/prototype/commit/caa2bf02b2ef641d1583ccbdb170d7baccb7788b

The fruit of a git reset HEAD missing ^. So sorry.

Good stuff.

@tobie here is his project link http://github.com/dperini/nwmatcher