You’ll notice that Pete mentions a new web site and says “2008″. Yup, been working on it for that long. Longer, even.

The site had stayed unchanged design-wise since at least December 2005. I was kicking ideas around for a new version at least since 2006.

In early 2008, I had a conversation with Shawn, who came up with this mock:

It’s had a lot of changes since then (Alex had some ideas for simplifying the interface), but that’s basically the same as what is live now.

Part of what took so long was that early on I tried to do way too much. I later decided to drop “buy” and “pics”. They may come back later; I haven’t decided. We also drop a lot of the video categories. There were just way too many.

I’ve changed the way that “Most Popular” is determined — the top six skits were listed as the most popular for about 3 years. So now it displays the most popular from the last 2 weeks. It’s kind of interesting that way. It changes up a lot.

Anyway, for anyone interested in the nitty-gritty, the site uses YUI 2.6.0. I considered updating it for 2.8.0 or even 3.0, but I’d already Duke Nukem’ Forever’d this thing long enough. It also makes minor use of Modernizr, mostly to detect whether the browser supports h264. Eventually the site will support ogg theora too. That’s a lot of skits to convert. At the moment, Safari and Chrome will display the videos natively, while all other browsers will use flash (JW Player).

I’ve only done minimal fixes for Internet Explorer. It works in IE 6-8, though it doesn’t look as pretty. I’ll mop that up later. Maybe. See the FAQ on the new site for my attitude towards IE in general (IE 6 in particular).

Also note that the videos are much larger, screen-wise. They are 640×360 for wide and 640×480 for standard. I re-encoded almost every single Flapping Crane video, not counting outtakes, which aren’t on the new site anyway (at least not yet).

Finally, if you were bored enough to make it this long: Yes, there will be new skits. I bought a house, got married, got a dog, etc. Haven’t had a lot of time to edit videos and get this new site up, so it may be a while before any truly new skits show up. There are, however, some skits that haven’t been put up yet that I may sneak in *COUGH*toofies*COUGH*.

And yes, there will be actual new, recently shot skits up soon. Well, eventually.

Not for the reasons it drive some people nuts — as long as they’re not intrusive, I don’t mind. I don’t regularly use AdBlock, though I do use ClickToFlash in Safari for various reasons. I don’t even think that Flash ads, per se, are a problem.

I see two basic problems:

1. document.write()
2. Invalid markup

document.write()

I hate document.write(). I’m pretty sure that I am That Guy At Work Who Hates document.write() With Unreasonable And Embarrassing Passion™, but it really does limit your options and it contributes to poor page load and rendering times.

Amazingly, a quick search of my past entries here turned up very little about my disdain for document.write(), so I’ll briefly summarize the problem.

Web browsers don’t handle external scripts very well. Because of things like document.write(), the browser actually has to pause the rendering of the page. Unfortunately, if the script is long-running or the server it’s on is slow or non-responsive, this can significantly increase the apparent page load time. Several mildly misbehaving external scripts on a page can have a dramatic cumulative effect. I set up an example of this while back to demonstrate this.

This is how most ads are delivered to a page. So a single ad placed anywhere before any important content on a page can block the display of that page until the ad is displayed.

There are ways around this. One way would be to have a external javascript file called early in the page. Then ad positions on the page wouldn’t be additional external script tags — they would be calls to a function or functions in that main javascript file (I believe Google Adsense allows for something like this method, at least in some circumstances). You could even get away with document.write() in this case, though that wouldn’t be eliminating problem #2. More on that in a moment. But there is still a basic problem here — we’re down to one external script, but if its host server is unresponsive, the display of all or most of the page will be held up until it resolves or times out.

Another way would be to dynamically create script tags and append them to the document’s head. These tags would point to the external scripts. But because they’re inserted this way, the browser doesn’t have to hold up the page rendering. YUI’s Get.script() does exactly this with some handy features thrown in as well. The big problem here is that document.write() is not compatible with this method. Unfortunately, 100% of ads out there are written out with document.write() by ad servers, regardless of whether they were written that way.

I’ve tried overriding document.write(). Last I checked, it actually works in Firefox:


(function(){
var els = document.getElementsByTagName('*'),
el = els[els.length - 1];
adURL = 'http://ad-server.com/blah';
document.write = function(str) {
if (typeof str != 'undefined') {
var newEl = document.createElement('span');
newEl.innerHTML = str;
var nodes = newEl.childNodes;
while (nodes.length) {
el.parentNode.appendChild(nodes[0]);
}
}
}
YAHOO.util.Get.script(adURL, {
onSuccess: function(){document.write = dwrite;}
});
})();


Guess how that pans out in IE?

(Yes, there are some flaws in the above code, but it was proof-of concept.)

And no, the defer attribute does not work when using document.write() and should be avoided anyway.

Invalid Markup

This problem is actually a consequence of problem #1. document.write() allows you to just toss arbitrary text and markup onto the page. There’s nothing to stop you from slapping this onto an otherwise nice page:


document.write('<div>Tacos</div>');


This can utterly destroy a page’s layout. All it takes is one bad ad to toss in one unmatched tag and a page’s layout will look like it got punched in the face and set on fire. The same thing could happen using innerHTML. However, using DOM methods avoids this problem:


var div = document.createElement('div');
adSpan.appendChild(div);
div.appendChild(document.createTextNode('Tacos'));


Yes, that appears to be more work. If your gripe with this solution is that you have to type more, please allow me to do to your face what a stray closing div can do to a page.

Mistakes can be made when doing it this way, but it eliminates an entire category of error that can sometimes be fairly difficult to track down. Even if you made 100% sure that your ad doesn’t output invalid html, all it takes is one person in the chain to do a bad copy & paste job to hose it up. It happens. It costs money and wastes time. It also makes me want to make the streets run red with the blood of my enemies.

Iframes, sadly, are not a solution to this problem. While it would contain the bad markup, they make certain type of ads hard or impossible to do. There is also a very long-standing Firefox bug in which iframes magically swap contents with each other.

What Can Be Done?

So where can we go from here? I wish I knew. I don’t think it’s realistic to expect that everyone writing ads out there change the way they write them. Maybe someone with Google’s clout could do this, but I can’t imagine that that would end well even for Google.

To make matters worse, whether the ad author avoids document.write() or not is actually irrelevant at this point because ad servers like DoubleClick actually take your ad code and document.write() it — leading to the silly (but common):


document.write('<noscript>Blah blah blah</noscript>');


Overriding document.write() would be a good intermediate step if it worked in IE, but it doesn’t.

This really is a serious problem. I can’t imagine how much potential revenue is lost to slow rendering pages as a result of ads which were supposed to generate revenue in the first place, not to mention the actual money spent on tracking down bad ads that are hosing up a page’s layout.

I put it under a BSD license, so feel free to do what you want with it.

yGetMan is a simple queue manager for YUI’s Get.script. If you request a script that’s already been loaded, it doesn’t attempt to re-load that script. Whether this is useful to you depends on your environment and circumstances.

See it in action here.

Here it is: yGetMan. Also, minified. Comments in there explain usage.

Also, if someone creates a mascot — a Get Man, if you will — I will make a big deal out of this and celebrate with a big plate of spaghetti.

There’s a temptation, I think, to go overboard with JS when manipulating elements on a page. Many tasks can be more simply handled with a combination of JS and CSS.

For example, let’s say you have a simple unordered list:

<ul id="happyList">
  <li><a href="tacos.html">Tacos</a></li>
  <li><a href="burritos.html">Burritos</a></li>
  <li><a href="enchiladas.html">Enchiladas</a></li>
  <li><a href="tamales.html">Tamales</a></li>
  <li><a href="chalupas.html">Chalupas</a></li>
  <li><a href="antacids.html">Antacids</a></li>
</ul>


Let’s say that you only want 3 items to show by default, and you want a “More” link at the bottom that will expand the list to show the rest.

There’s a few ways you could approach this. People may be tempted to put an onclick event onto the “More” link, then have that call a function that toggles the visibility of each element after the third. Something like:


var happy = document.getElementById('happyList');
var items = happy.getElementsByTagName('li');
function showLinks() {
  for (var i=3; i < items; i++) {
    items[i].style.display = 'list-item';
  }
}
function hideLinks() {
  for (var i=3; i < items; i++) {
    items[i].style.display = 'none';
  }
}


That would work (though I haven’t actually tested this particular js), but it’s definitely the crappy way, for a number of reasons. First, there’s no need for two functions, though that’s beside the point of this post. Second, we’re running through a for() loop every time each function is called.

Instead of something like that, the way I’d do it is to first set up this CSS:


#happyList.collapsed li {
  display: none;
}
#happyList.collapsed li.alwaysShow {
  display: list-item;
}


Then, you put a class of ‘alwaysShow’ on the first three list item elements, either in the html itself or with javascript:


function assignShow() {
  var happy = document.getElementById('happyList');
  var items = happy.getElementsByTagName('li');
  for (var i=0; i < items.length && i < 3; i++) {
    items[i].className = 'alwaysShow';
  }
}


Now, when the ul has a class of ‘collapsed’, only the first three items show:


function toggleList() {
  var happy = document.getElementById('happyList');
  if (happy.className == 'collapsed') {
    happy.className = '';
  } else {
    happy.className = 'collapsed';
  }
}


Or, more succinctly:

function toggleList() {
  var happy = document.getElementById('happyList');
  happy.className = happy.className ==
    'collapsed' ? '' : 'collapsed';
}


Then, either in HTML or using javascript, you can add an element with the “More” text and attach an event to it that calls toggleList().

I’m being a little vague on details here. My main point is that it’s preferable to lean on CSS as much as possible. It helps to avoid micromanaging elements.

I had to tackle this somewhat recently. The solution is silly, but it works.

The problem is that an iframe can’t communicate with its parent if they’re on different domains. For example, let’s say I put an iframe here on povert.com. The iframe could be pointing to, say, flappingcrane.com. Povert.com can’t access any useful information about the iframe, and vise-versa.

The solution is to have the iframed content (in this case flappingcrane.com) iframe something else from the original domain. So you could set up a file on povert.com called yaygo.html. Then flappingcrane.com iframes that, with a GET query. That GET query should contain any information you want to communicate to the parent (povert.com). Since yaygo.html is on povert.com, it can refer to povert.com with parent (though, since they’re different domains, it can’t do anything useful) and to flappingcrane.com with parent.parent. Because they’re on the same domain (even with the intermediate flappingcrane.com iframe), it can do something useful — like pass values from the GET query to a function:


parent.parent.setFunProps(iframeid, width, height, tacoflavor);


setFunProps() can then take those values and do what it wants with it (resize the iframe, whatever).

Another tidbit. If you give a name attribute to an iframe, that iframe’s contents can access the name with window.name. You can’t access window.id though, unfortunately. Either are handy for identifying to the parent document what iframe is requesting a resize, though there are other crappier ways to do it (passing its own url to match against iframe src, for example).

UPDATE: As I mention in my comment below, you can see an example of this at http://povert.com/fun/iframe/.

UPDATE (Oct 28, 2009): Looks like it doesn’t work in any version of IE now. It’s possible that Microsoft saw this as a security hole and fixed it.

Also, I’ve revamped the Flapping Crane RSS feed. This sucker now has MP4 videos that are good for watching on TV (with Apple TV or probably XBox 360) or on an iPhone. Haven’t tested it on other iPods. May not work on them.

Finally, I’m in the process of compressing new versions of all our old videos and uploading them to Amazon’s S3. This should allow for faster downloads.

I haven’t flipped the switch on S3 yet, and probably won’t for a while. I want to get as many vids on there as possible.

Here’s what I’ve got so far (line breaks added for *cough* legibility):


<SCRIPT LANGUAGE=JSCRIPT>
eval("document.write('<!--[IF LT IE 9]>
<STYLE>*LI#BLUENAV{
_ZOOM:1!IMPORTANT*BACKGROUND-COLOR:
PAPAYAWHIP!IMPORTANT<![ENDIF]--></STYLE>
<BASEFONT SIZE=30 COLOR=YELLOWGREEN FACE=GEORGIA>
<TABLE CELLPADDING=10 CELLSPACING=10 BORDER=20>
<TD><U><TABLE><S><LI ID=BLUENAV>
<FONT FACE=VERDANA STYLE=FONT-SIZE:LARGE>
<B><CENTER><MARQUEE BGCOLOR=MISTYROSE WIDTH=50%>
Tacos</MARQUEE><BR>
<IMG ALIGN=LEFT SRC=SPACER.GIF WIDTH=200 HEIGHT=20>')")
</SCRIPT><NOSCRIPT><A HREF=HTTP://MICROSOFT.COM>
<FONT FACE=COURIER COLOR=SADDLEBROWN>
YOU&NBSP;NEED&NBSP;INTERNET&NBSP;EXPLORER&NBSP;TO&NBSP;
EXPERIENCE&NBSP;THIS&NBSP;WEB&NBSP;SITE&NBSP;
AS&NBSP;INTENDED


To see it in action, click here. You’ll need IE, of course. It wouldn’t be as crappy otherwise.

Key points:

• <script> has a LANGUAGE attribute. And it’s JSCRIPT, for fun.
• Elements are closed only when absolutely necessary
• No quotes around element attributes
• Nearly everything in uppercase
• eval()
• document.write()
• Needlessly nested (and otherwise unnecessary) tables
• Not a <tr> to be found.
• Insane colors: PapayaWhip, MistyRose, YellowGreen and SaddleBrown
• <basefont> and <font>
• <li> without a <ul> or <ol>
• <noscript> — some people may argue with me about this one, but it’s certainly not an indicator of whether the viewer is using IE
• Pointless use of &nbsp;
• <marquee>
• <u>, <s>, <b> and <center>
• IE conditional comments (useful, but crappy nonetheless)
• * and _ CSS hacks
• !important
• Improperly formatted (but working) css
• Opening <style> tag inside conditional comment, closing tag outside.
• No DOCTYPE
• No attempt at an even reasonably structured HTML document — no <html>, no <head>, no <body>, etc.
• Oh, and SPACER.GIF doesn’t exist, of course. That’s a double-whammy, actually. Spacer images blow.

One of our programmers wrote a script which grabbed some external data and formatted it into a table. Straightforward stuff. He opted for the W3C DOM method. I advised against it, simply because that route is a pain when it comes to IE 6 in my experience.

For those of you who don’t know, it’s kind of similar to writing normal HTML, except it’s done dynamically. So you typically start by creating a node:

yaytable = document.createElement("table");

Even if you don’t know javascript but you know some HTML you can pick it up. You then create the row:

yayrow = document.createElement("tr");

and the cell for the data that goes in one of the columns:

yaycell = document.createElement("td");

Then you create the node that contains whatever data you want to put in there:

yaydata = document.createTextNode("Whee!");

Then you can slap them all together:

yaycell.appendChild(yaydata);
yayrow.appendChild(yaycell);
yaytable.appendChild(yayrow);
document.body.appendChild(yaytable);

So far, so good. In firefox, this results in:

<table><tr><td>Whee!</td></tr></table>

Yay, a dynamically generated table. Now, there’s an easier way to do this — one that makes a lot of us web guys a little ill:

document.body.innerHTML += "<table><tr><td>Whee!</td></tr></table>";

A lot quicker. But it’s not part of the standard, and it comes with its own drawbacks.

Anyway, like I said, he used the first method. It’s a neat way to do it. You can, for example, do something like — yayrow.style.backgroundColor = ‘red’; — or something later on. Using the innerHTML way, you really just have to rewrite the string, which is inconvenient.

A quick note — I’m sure that this simple example would probably work in IE 6. However, in his case, it did not work. I’m really not sure why. You could look at the dom in IE and see the table in there, along with all of the data. You could pull up a javascript console and output the contents of (for example) yaytable.innerHTML and you could see it. But it wasn’t visible on the page. It worked fine in Firefox, of course.

He struggled with it for a good long time. I won’t say how long. Eventually I told him that since it was a quick job, he really should go the easy route, propriety be damned. It would have taken all of 10 minutes, if that.

Still, he had spent a lot of time on it. Understandably, he wasn’t ready to scrap it.

I eventually figured out a way to do it. It’s ironic and stupid. Basically, tack something like this on to the end of the previous code:

crap = yaytable.innerHTML;
yaytable.innerHTML = crap;

And, I shit you not, it worked. I think I know why, but it still doesn’t explain why there was a problem in the first place.

Anyway, I guess the point in all this is that yeah, there is a “right” way to do things. And it should work. And people who haven’t spent nearly every day for years struggling to get IE 6 to do even the simplest things scoff when you tell them to not expect reasonable behavior from it. I get that from people all the time. Luckily, sometime after I turned 26 or so, I stopped caring when people thought I was an idiot. If you prove me wrong, yay. Makes my life easier.

When you’re creating something for a client, 99% of the time they don’t care how you do it. They just want it done. And sometimes it’s not worth the effort to try to do it the right way.

Not that there isn’t value in trying, of course. There is. I plan on figuring this out, in fact. It’s probably something very simple that I’m overlooking, even though several people looked at this problem. It could be due to a lot of factors. I don’t know.

I ran into a similar problem a while back with flapping crane. Check out line 149 of scripts.js sometime for a laugh (hint — use View Source). It’s in the loadSkit() function.

Update: Yay, I think I found a fix. IE seems to require a TBODY tag. Quick example:

yaytable = document.createElement("table");
yaytbody = document.createElement("tbody");
yayrow = document.createElement("tr");
yaycell = document.createElement("td");
yaydata = document.createTextNode("Whee!");
yaycell.appendChild(yaydata);
yayrow.appendChild(yaycell);
yaytbody.appendChild(yayrow);
yaytable.appendChild(yaytbody);
document.body.appendChild(yaytable);

From the spec:

The TBODY start tag is always required except when the table contains only one table body and no table head or foot sections. The TBODY end tag may always be safely omitted.

Am I reading that wrong? More info.

One note for anyone who has to deal with XML cross-browser issues: Gecko browsers (Firefox, Mozilla, etc) count things like newlines and spaces in an XML file as nodes. While it adheres to spec, it is (as far as I can tell) lame and asinine. So, to filter them out, create an array something like this, assuming xmlTags is an XML object:

for (i=0;i<xmlTags[i].length;i++) {
    if ( ( xmlTags[i].nodeType != 3 ) && ( xmlTags[i].nodeType != 8 ) ) {
      xmlData[xmlTags[i].nodeName] = trim(xmlTags[i].firstChild.data);
    }
}

The key part is checking the node type. Type 3 and 8 are for text nodes and comment nodes. This only works because the nodes I care about are element nodes.

My original plan was to just check for the return value of xmlTags[i].firstChild, but this way seems better.

P.S. — Sorry, here’s trim():

function trim(text) {
  try {
    return text.replace(/^\s*(.*?)\s*$/g, '$1');
  }
    catch (e) {
      return text;
    }
}

I was checking up on A List Apart tonight and came across an article I had missed — Bye Bye Embed. Published a full month after I had written about it here. Bah. I coulda made it into A List Apart.

Anyway, I did things a little differently (I don’t nest <object> tags), and the author is more informed about the subject. Still, kind of cool.