Let's Build the Web We Want
For some searches on both Bing and Google, the top result is enhanced with additional data. For simplicities’ sake (and because I’m selfish) I’m going to focus on one search for my personal site to compare the two.
Google’s result for my site looks like this:
Continue reading “Google’s Sitelinks vs. Bing’s Deep Links + D-Card”
And I made a web/tech one that might be of interest.
I’m not sure how useful the lists actually are, but it felt like it was worth a shot if just to make sense of my own following list. Feel free to shout out interesting people I missed in the comments. Most of the people on the list are folks I follow, but I’d be happy to add new folks if they’re interesting- and I know there are plenty of people out that that are interesting that I don’t follow 🙂 I’m especially interested in CSS/HTML/JavaScript/Web Performance types, but I’m down for any web technologies.
Don’t ask why I’m poking around the wayback machine (that would spoil the surprise,) but if you’ve been around as long as I have and want to reminisce, or never got to experience Web 1.0 as a developer and want to see what all the complaints are about, you should really take a look at Netscape’s JavaScript documentation from 1999.
Here’s one that will confuse the hell out of anyone who started doing this after maybe 2003:
Continue reading “Netscape’s Javascript Documentation From 1999 (document.layers!)”
Conditional Compilation is a handy, Internet Explorer specific method for forking bits of JavaScript. The nice thing about it is that real browsers don’t notice it at all. It just looks like a comment block to any non-IE browser. Which saves the rest of the world from even having to if (IE) { } else { } . I like that.
Anyway, we use it to fix some of IE’s shortcomings. One standard pattern is using it to fake the :hover pseudo-class on inputs in IE6. Something like this:
//IE6 HOVERS simplified//
//this would be a bit different in protection
//but you can see the idea
/*@cc_on @*/
/*@if (@_win32)
var inputElements = document.getElementsByTagName("input");
var test = inputElements.length;
for (var i=0; i<test; i++) {
if (inputElements[i].getAttribute("type") == "submit"){
inputElements[i].onmouseover = inputElements[i].onfocus = function(){
addClass(this, "hover");
}
inputElements[i].onmouseout = inputElements[i].onblur = function(){
removeClass(this, "hover");
}
};
};
/*@end @*/
//END IE6 HOVERS//
I saw this tweet yesterday and was reminded , once again, of how misunderstood the return value of a DOM method like document.getElementsByTagName is. Normally, it doesn’t matter that folks don’t really understand the return value fully, because most of the time the code just works. Where it breaks is interesting, so it’s worth taking a look at it in a little bit of depth.
Typically people do things like this:
var anchors = document.getElementsByTagName('a');
for (var i = 0; i < anchors.length; i++) {
anchors[i].addEventListener("click", beAwesome, false)
}
Common pattern. Get a list of the anchors on the page, loop through and add an event to each.
If asked, I’d be willing to bet most people would assume that the list they’re interacting with is an Array. It’s got a length and you can index it- that’s got to be an Array, right?
Surprise! 🙂
Continue reading “The JavaScript NodeList and You. Watch Where You Point That Thing, Soldier”