zelph.com

Steve over at Slayeroffice just posted an update to one of his “favelets” that I sent to him. So I thought I’d do a quick write-up on how it came to be (as I’m really lacking in content these days).

We are big fans of his Favelet Suite over at Sprint, and use it daily. One of the favelets is the Mouseover DOM Inspector (MODI) that we used more then the rest to get a nice quick look at how our CSS based pages are laying out by using the background color that MODI provides.

A favelet (or Bookmarklet as we usually call them here… same thing) that I had always wanted to make was one that showed the parent structure of the element you moused over. When I finally got some time, I thought that tweaking Steve’s MODI favelet would be a natural fit. So I snagged the parent structure parsing code from our Sprint IFR implementation and slapped it into a copy of MODI. After a little tweaking to actually spit out the parent structure, instead of just walk up it, it was working pretty good. Added the Height/Width while I was at it and called it good.

A few weeks later I was working on another project and was regularly trying to find the X,Y of a given element (X,Y finding thanks to PPK over at quirksmode.org). Eventually the lightbulb went off and I just added it to the MODI script that was fast becoming the one stop shop for everything we needed.

After using that for a while I finally decided to offer it up to Steve to add to his own script, so that others could use the new features as well. The update that I sent him was added today and now I can go back to just needing his Suite, and can remove a bookmark from my toolbar.

Many thanks to Steve for the great resource that he provides in the Favelet Suite (and naturally each individual Favelet). I know it has saved us a lot of time in various circumstances, and it’s an honor to be able to contribute to it.

Comments(1)

One line to rule them all,
one line to find them.
One line to bring them all,
and in the function bind them.

The “One Line”:

if(!foo.nodeName) foo = document.getElementById(foo);

Imagine you make, borrow or steal a function that does “something” to a given element. The function is setup to require the ID of the element in question, so that you can do ye ole “getElementById” (gEBI from now on) on it to then do whatever spiffy thing you want to do to it.

But what if you already had already done a gEBI on this element, and the result of that is sitting in a variable just waiting to be used… why should you waste resources doing it all over again, and have a second variable with all the same information.

Or… reverse it. Your function is expecting a gEBI’d var but you pass just the ID. It won’t have the information it needs.

Enter the “One Line.” What the code does is check to see if the variable that was passed has an attribute (nodeName) of a gEBI’d variable (if(!foo.nodeName)). If it does then it goes merrily on it’s way. If it doesn’t, then it must have just been an ID so the line does a gEBI on it so we can do what we want to do to it (foo = document.getElementById(foo);). It sets the results of the gEBI to the same variable the ID was, so the code below it is none the wiser. Whichever thing you send to it, after this line you will have the same thing to work with.

Now granted… in a perfect world all your functions will be written ever so neatly and you will always remember what to send to them or it would always be one or the other. But since we are such a generous community, and are always sharing new ideas, I’m sure your .js files are a hodge podge of functions from various people, and even various scripts that you have written previously and pulled into a new one. The One Line levels the playing field.

So to sum up… this one line of code makes it so you don’t have to worry about what you send to your function. Either an ID or a gEBI’d var will work.

A really lame example of a function that changes your text to red:

function redText(theText){
   theText.style.color = "#f00";
}

In the above, it is looking for a gEBI’d variable to apply the style to. So it won’t work if you just pass the ID.

function redText(theText){
   if(!theText.nodeName) theText= document.getElementById(theText);
   theText.style.color = "#f00";
}

Using the One Line, it can now accept either an ID or a gEBI’d variable. Everyone is happy

One line to rule them all,
one line to find them.
One line to bring them all,
and in the function bind them.

Comments(1)

Kudos to Chevrolet for their recent XHTML/CSS overhaul. The code is extremely clean, and they get extra brownie points for going for (and achieving) XHTML Strict compliance.

After France (who is always in the know) pointed me to the overhaul, I (naturally) went poking through their code and they are doing some sweet stuff. Much of it required by the strict standard not allowing things like “onclick” attributes in the code, they use the DOM to parse through all anchor tags on a page to create popup code, status bar messages, and more.

One thing I found weird is that they do the following at the top of each page:

if (!document.getElementById || !document.createTextNode) { window.location.replace('/upgrade/'); }

This is presumably to redirect older browsers to their upgrade page. While I can understand doing this from a standpoint of locking down your audience to your selected/supported browsers, part of the advantage of an XHTML design is that older browsers can view the site in is “degraded” form and still be able to get the information they are looking for just without the bells and whistles. This snippet of code basically eleminates that “feature” of an XHTML design, and locks those users out.

That minor confusion aside, this is a great looking rewrite of the site and whoever did the job (inside employees or vendor) are to be commended for their great job. They have been able to implement many things that we have pondered at Sprint (parsing in popup code onload, etc) and it will be intersting to see how things shake out for them over time and what others have to say about their implementation.

Edit:
After posting this I went poking around my own site and saw that Chris Moritz made a comment on my Sprint IFR article. Wonder if they were pondering using IFR for the Chevy redesign?? Oh, and got Chris’ name from a Digital Web mention of the redesign.

Edit 2:
From another mention (in portuguese) we meet antother developer (search for “thew”) who mentions yet another developer, Dave, who has a site. Hopefully Dave will put up some kind of a write-up on the launch.

Comments(4)

Someone much geekier then I, wrote the Jabberwocky in ActionScript. This is pure genious. I can only dream of being cool enough (and geeky enough) to make up something like this. Kudos to whoever runs turdhead.com for coming up with such beauty.

ActionScript is fairly similar to JavaScript, and if you know any programming language you will be able to appreciate the majority of what is going on, just maybe not the fine details. But If you know the poem well enough you may be able to get a good enough kick out of it if you are even slightly techy/geeky.

Found via /.

Jabberwocky text to compare to

Comments(0)

Introduction

This lengthy article is here to describe the process of how Shaun Inman’s IFR technique came to be used on Sprint.com and SprintPCS.com. This is my first write-up of the process involved in implementing a major new standard, and I didn’t take the notes I should have along the way… so please bear with me.

(Read the article)

Comments(5)