Note to self:

<%#Container.DisplayIndex % 2 == 0 ? "odd" : "even"%>

As a follow up to my previous post on a dummy JavaScript console object, some thoughts on refining it;

if(console === "undefined") {
    var console = {
        log: function() {}
    }
}

Also one additional method could be:

console = console || { log: function() {} }

But, I haven’t yet tested it out properly to see possible brainfarts. Also, don’t forget to include other methods you may depend upon, such as info, warn or error.

Remember, you can attach actions to events by assigning an anonymous function to said event.

Before this, yes, I know, this is basic, but I’ve a post coming on the subject on my way of learning things. :D

Example: Let’s open up an image from a link, and preload the image before displaying it and using jQuery to display, because I’m lazy with vanilla JS;

var preload-image = new Image();
preload-image.onload = function() {
    var image = $("#image");
    image.attr("src", "goatse.jpg").show();
}
preload-image.src = "goatse.jpg";

We could probably add a delete statement to remove the unwanted and then unused image tag;

EDIT: Thanks for Antti S. for reminding me that you can’t delete variables declared with var, so instead just null it;

preload-image = null;

This is a note to self -post, so I can refer to this in the (hopefully not so) near future, when thinking about XPath selectors, especially selectors like preceding-sibling and following-sibling. Especially what has been confusing to me, until I managed to figure it out, how those two selectors work (yes, I am lazy to RTFG). So here, have a table;

What I erred this with that thought preceding-sibling::MyNode[last()] would select the immediate previous sibling of the current node, as in the logic of take all preceding nodes and select the last, counting from the first up to the immediate sibling of the current node, when the real logic behind this was much simpler; depending on the context—whether you use preceding or following—dictates the direction; e.g. the immediate sibling will always be first on the list.

Which of course means, preceding-sibling::MyNode[1].