Easy Reader

Like many of you, I’m sure, I hate debugging JavaScript. Really, it’s not the debugging, per se, as much as it’s using alert() to echo stuff out to the screen. It’s stupid and distracting and takes for ever if you’re debugging a lot of stuff.

For the last few months, I’ve been toying with a few different means of error reporting and echoing out debugging information, but hadn’t been really satisfied with anything I’d come up with. I used to do quite a bit of Flash work back in the day (before Dave came along and put my best efforts to shame) and always loved the Trace window. I liked that you could just echo stuff out to it and it acted as a running tally of pretty much anything you wanted to track: variable values, messages, etc. Two days ago I decided that was what I wanted for JavaScript.

I toyed with the idea of spawning a popup and tracing the info to that, but I don’t like popups. They are possibly more annoying than alert messages (well… maybe not). I decided to echo the messages out to a div on the page instead. Then feature creep set in. Before I knew it, it was a draggable, scalable window with some nifty features. Never one to be selfish, I thought other people could find a use for it too, so I’ve released it for anyone who wants it: here it is. Use it, play with it and improve on it as you see fit.

The script currently has the following features:

• the window drags & scales,
• you can output a delimeter quickly to help further organize your tracing,
• you can quickly clear the window,
• the system is very easy to implement (even for a novice DOM scripter), and
• it’s easily removable once your debugging is complete.

Special thanks go out to Aaron Boodman, whose DOM Drag was perfect for the dragging and enabled me to hook up a window stretcher pretty easily, Richard Rutter, whose Browser Stickies were also somewhat of an inspiration, and Dave, for helping me debug the scaling code.

Aside: one nice feature of the script is that, once it was operational, I was able to use it to debug itself… how cool is that?

It managed to sneak past me for a few days, but my recent interview with Jeremy Keith has made its way into the latest issue of Digital Web Magazine. In the interview we cover the impetus behind his new book, WaSP’s DOM Scripting Task Force, and Jeremy’s future as a rockstar.

On a somewhat tangential note, if you’re interested in competing at the SXSW Web Awards in March, I recommend getting your entires in soon. If you enter by Friday (October 14th), you only have to pay $10 per category which is too cheap to miss out on. If you attend, you’ll get more of Jeremy & me on “How to Bluff Your Way in DOM Scripting.”

I’ve been insanely busy building a new Rails app for a client and travelling a lot for speaking engagements. I just got back from an incredible trip to San Jose (well, Cupertino actually) where Molly, Andy and I were doing some training. I had an amazing time with both of them and it was really fun to see Andy in action (I, unfortunately, did not have the peasure of seeing him rock the audience at @media). We had a really great group of conference attendees too. I am a little saddened that this was my last stop on the WOW tour (I am missing Hawaii as it takes place on election day, but more on that later), but I have heard some rumblings that the show may go back on the road for a European leg. Fingers crossed.

Anyway, we’ve pushed a new issue of ALA out the door which includes a fantastic piece by Eric on the new ALA print stylesheet and I have a new article is in there as well: Improving Link Display for Print. It’s print mania at ALA aparently.

Anyway, I am apparently going to New Jersey today for work, so I need to get ready. Ta for now.

I just encountered a DOM implementation issue in IE which took about three hours to solve (and like a year off my life). The story goes like this:

I could not, for the life of me, figure out why a form submitted in Firefox was coming through perfectly while it was missing fields in IE. The form in question has some normal fields and some dynamically generated ones (if JavaScript is enabled). The normal stuff was coming through fine, but I was getting no values for the dynamically generated fields when the form was submitted in IE. I checked the $_REQUEST variable (I am using PHP) to see what was coming through, just to be sure.

I immediately figured it was missing name attributes, but I was using the proper syntax to create the input elements via the DOM (note: the actual JS is more generic than this)

var inpt = document.createElement('input');
inpt.setAttribute('name', 'company');

Indeed, when I looked at the page through the Web Accessibility Toolbar’s View Generated Source, it was indeed missing the name attribute:

<INPUT id=company maxLength=255
       validatefor="title" required="required">

After about another hour or two of fruitless Google-ing, I finally typed in the magic phrase (setting the name attribute in Internet Explorer) and ended up on Bennett McElwee’s blog post of the same name. Suddenly it was all clear and (as I expected) IE’s botched implementation of the DOM’s createElement function was to blame.

According to the MSDN page on the name attribute (linked and quoted in the blog entry):

The NAME attribute cannot be set at run time on elements dynamically created with the createElement method. To create an element with a name attribute, include the attribute and value when using the createElement method.

It continued with the following example:

var oAnchor =
  document.createElement("<A NAME='AnchorName'></A>");

The script “solution” Bennett posted was somewhat of a red herring, however, as Firefox would actually execute the createElement intended for IE and end up with an element named “<input name="company" />” which would be rendered on the page as

<<input name="company" />  id="company"
        maxlength="255" validatefor="title" required="required" />

Perhaps you can see why this would be problematic.

I augmented Bennett’s script slightly and renamed the function createElementWithName so I wouldn’t have to use it on every element I created in the script:

function createElementWithName(type, name) {
  var element;
  // First try the IE way; if this fails then use the standard way
  if (document.all) {
    element =
      document.createElement('< '+type+' name="'+name+'" />');
  } else {
    element = document.createElement(type);
    element.setAttribute('name', name);
  }
  return element;
}

I am not a super fan of the reference to document.all as it feels so much like browser sniffing. I am up for suggestions to improve the function if you have any ideas.

Anyway, I am posting this to hopefully save someone else from the major headache I had today.

I finally got around to reading Chris Wilson’s post about standards support in IE7 and I have to admit I am more than a little giddy. Working for an ad agency, most clients (and the majority of my coworkers) have not gotten the whole Web Standards thing, mostly because they only use IE. I can’t express how much relief I feel that IE7 is going to fall in line with most of the other browsers out there with regard to standards support.

Improvements of particular note are alpha transparency in PNGs and support for <abbr>s. When it comes to CSS, a whole host of bugs/issues have been fixed (mostly culled from Quirksmode and Position is Everything). I am left with two nagging questions, however:

1. Will the * HTML CSS hack still be supported in IE7 or will that be phased out so * HTML only affects IE6 and below?
2. Has the DOM interface been upgraded so we can run more powerful scripts in IE7?

Overall, I think this is a huge step forward. I have to hand it to Chris, the IE team and WaSP’s Microsoft Corporation Task Force for making this all a reality. A very hearty thank you goes out to all of you, you made my year.

UPDATE: A recent blog entry on IE Blog has informed us that the * HTML selector will not be supported by IE7 in “strict” mode.