In an answer to a Stack Overflow question I enumerated all the ways I knew to get the "first children" of a jQuery object.
I had originally suggested that .children().first() wouldn't be very efficient because it requires jQuery to first build the list of all children, and then create a new jQuery object that only contains the first element.
So I wrote a plugin which uses .firstElementChild if available or iterates over the children directly otherwise. In the former case the plugin effectively becomes:
$.fn.firstChild = function() {
return this.map(function() {
return this.firstElementChild;
});
};
Curiously, I've found via jsperf that on Chrome 25 this is actually slightly slower than .children().first() although it's 50% - 130% faster in Firefox and Safari.
The real question is why is $(body).firstChild() from my plugin still 15x slower than just $(body.firstElementChild)? The latter is incredibly fast, but not portable. What is it about the chaining here that completely kills the performance?
These functions currently _only_ return HTMLElement nodes, as do .children(), .siblings(), etc. The only function that can obtain text nodes is .contents().
AFAIK the only jQuery traversal function which accepts a function in place of a selector is .filter() itself.
It might be very useful if all those traversal functions that allow a "filter selector" also permitted an explicit filter function, and when supplied then consider _all_ nodes, and not just HTMLElements.
Whilst debugging some third party code that was no longer working under 1.6.1, we discovered that this code:
var id = $el.attr('id');
where $el has no id attribute would return an empty string under 1.5.2, but now returns undefined.
Is this apparent change documented anywhere? It's not explicitly mentioned as far as I can see in the 1.6.x release notes.
It looks like maybe this is because the old pre 1.6 code would fall through on the undefined attribute to the always-existing-but-empty property value.
In this question on Stackoverflow, I suggested use of $.Deferred()
My original fiddle for a solution used a separate callback function which just called def.resolve().
However I then remembered that I've seen other code simply pass "def.resolve" as a callback in its own right. I tried this instead, and it works (see http://jsfiddle.net/Nyg4y/3/).
This got me wondering - how does this work? As I understand it for this to work at all the value 'def.resolve' must be specific to 'def'.
This suggests that it is actually a (reference to a) closure holding a reference to 'def' in its scope. Is my understanding correct, and if so is this behaviour guaranteed?
In our application we've noticed that hovering over the 'x' close button dialog box causes the browser status to show '.../path/#' in the status bar, or in Chrome make that appear as a popup in the bottom left.
When adding extra buttons to the title bar I've used a <div> instead of <a href="#"> and then added this to our CSS to make sure we get the right cursor.
*[role="button"] {
cursor: pointer;
cursor: hand;
}
Is there any particular reason (accessibility?) why the current code uses that <A> tag?