Easy Reader

With all of the travelling I was doing last week, I forgot to mention that some of the sites Dave & I have worked at Cronin and Company on took home WebAwards from the Web Marketing Association. We took home two “Outstanding Website” awards (think silver) for our sites for Middlesex Hospital and the Drink-Drive-Lose Ad Challenge. I was perticularly stoked as I was the designer of both sites and single-handedly built the Ad Challenge site which had a lot of complex application-level code behind it. We also took home a “Standard of Excellence” award (think bronze) for the site we built for Garelick Farms’ Over the Moon Milk product launch. I’m not a big fan of that site’s design (not because it wasn’t mine), but I love the game Dave built.

I was also a judge of the WebAwards (as I have been for the last few years and, no, I did not judge any sites I was involved with) and I have to say I was very pleased to see more sites moving to web standards. Out of the 15 or so I judged in the initial round, there were at least two or three that were well on their way to being exemplary in the standards world (compared to 0 only two years ago). Like most marketing-related awards, Flash always seems to trump standards, but it seems like developers are starting to cue into the standards trend more and more every year.

This year I also had the privilege of judging the Best of Show. I was pulling for Project Rebirth but National Geographic ended up taking home the top prize for Inside the Mafia which was also in my top 3 picks.

All in all, this years WebAwards were pretty good to us (and a step up from the two “Standard of Excellence” awards we pulled last year for Ride4Ever and Bertucci’s Restaurants). I look forward to next year’s competition as well as the one at SXSW, where we hope to go from finalist to winner this year.

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.

Yeah, I’m weighing into the debate on the ALA redesign. I have to say I agree with Jon and Jeremy regarding the fixed 1024px width. My little 2¢ to add to this discussion is that I think more designers should consider the wonderous world of CSS switching based on browser width (see Rammstein or the slightly better implementation on Drink-drive-lose.com’s Ad Challenge). Using this technique, users can view your site at their most comfortable screen resolution and you can still have a nicely designed page for them (fixed or liquid… or both). Can you say zoom layouts? I knew you could.

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.