kangax (Juriy Zaytsev)

How come some of these variables are lowercased and others — uppercased?

Makes sense. Thanks for explanation.

Might be better to use pseudo-constant instead of a comment.

Why explicit comparison?

Why check for window and then fall back to this if it's undefined? Isn't it a global code? Wouldn't this be enough — typeof exports !== 'undefined' ? exports : this or even this.exports || this (not sure what exports is)

@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).

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.

Expandos lead to page reflows in IE? That's news to me. Diego, do you have any more information about this?

But can we rely on this being spec-compliant? : )

Is this actually related to the case of tagNames?

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

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.

@tobie, both links are here — http://twitter.com/kangax/status/4617283006

Would be nice to mention what descendantOfreturns when given same element — element.descendantOf(element); // true or false?

Isn't "0", "1" access deprecated? We should mention it here.

Is this "broken" line here on purpose (setAttribute('class', ...) will fail in IE)? If it is, it would make sense to mention it in a comment (since someone can actually copy-paste this "old way" and end up with broken functionality).

Do we want to make multiple class addition part of public api? e.g.: someElement.addClassName('foo bar');

This is not exactly true. "html will always be last element" only if original element is contained within document. Orphaned elements, for example, might not have "html" as the last member of their ancestors; they might not even have parent node in the first place ;)

@GarrettS Yeah, I have local repository on my machine where I can do any changes (sometimes even few commits). It's really convenient to be able to edit things locally — its fast and flexible, I can stop in the middle of editing and then continue later, etc.

Once done, I push it to origin/master (github), ssh to my server and pull from there (there's same repo there too, of course, although only ever used for pulling).

I am assigning the onload to global object for a test page. That test does not go into production. The user is the developer who is running the test. The failure of global onload not firing would be something that that user would be interested in.

But why does it matter if code is in production or not? We don't use "document.all" or sniffing in dev. environment, we still use best practices, don't we?

Essentially, that says (in code) that the WindowProxy is the global object.

Yep, window == Global seems to be an inherent assumption in all browsers. If browser was to break that, it would break most of the web. Btw, speaking of inner/outer windows (that we couldn't figure out before), here's an article describing them in more details — https://developer.mozilla.org/En/SpiderMonkey/Split_object

That's a very weak inference. If clients is Gecko, does it mean it supports "MozTransform"? Most likely not. Testing for presence of certain style is trivial and is more robust.

Same with IE sniff further down. Need to test presence of filter, not user agent.

Btw, theoretically, we don't know if native trim considers all of the — \x20, \t, n, \r, \f as whitespace — which means that it would be safer to feature test it first. E.g.:

if (String.prototype.trim && '\x20\t\n\r\f'.trim().length === 0)
  trim = String.prototype.trim;
}
else {
  ...
}

But this might be just overly paranoid : )

Wouldn't it be less repetitive (and more maintainable) to store \t\n\f\r\x20 in a string and then use that string everywhere for regex building? Or am I missing something?

No unit tests?

This will not match something like ".foo-bar", even though it's just as simple as ".foo" : )

Perhaps, /^[.#]?[-\w]+$/ ?

The link you listed is 404.

That's because github erroneously appended ")" to the link itself. It's http://yura.thinkweb2.com/test.html

Garrett, never mind me. I just realized that I was talking about Palm Pre all this time : / I do see that Blackberry returns false even in my own test. Sigh...

githubsource bookmarklet might come handy. Thanks.

Could you explain how "assign a global onload is not harmful" when you assign it as undeclared variable (onload = ...)? I am, btw, not aware of cases where global onload doesn't fire.

The comment has since been removed.