Last weekend, while rearranging upstairs bedrooms to prepare a nursery for our son (he’s due in less than 3 months!), I found myself looking at my old G4 iMac. It’s the one with the goose neck and the dome base. This one has a nice 21″ screen. It’s got a problem now where it’s a pain to turn it on, but it’s otherwise in great condition. It’s still a stunning computer.

Seven years ago, I moved from Flagstaff, AZ to the midwest. Things weren’t going so well. I talked my parents into buying that iMac for me. It wasn’t cheap — along with Final Cut Express it was around $1,600.

My interest then was video editing. But it was more than that. For years I was a UNIX nerd. Linux in particular. I still have a soft spot for it (I use Terminal.app and vi every day). But Mac OS X took it to an entirely new level. They somehow managed to combine UNIX underpinnings with solid UI and UX. It was, and still is, amazing.

But, as I said, my interest was in video editing. Through this, I eventually re-connected with an old friend from middle school and started an internet comedy group. We made very few waves (there were some very small ones), but the personal implications were far-reaching. I got a job at IB (where I worked for 5 years) through a recommendation from several of the guys. Shawn officiated my wedding with Kelly. These are people I never would have known if the state of tech on the Mac had been less awesome. They’re all good friends (and we still miss you, Eric).

My current employment can be traced back to it as well. Not because I use a Mac at work (I do), but because the Mac re-ignited an interest in computing for me. Keep in mind, I was not a fan of the mac in the pre-OS X days. It might have been a decent OS, but it was severely lacking in many respects. OS X, though, was a breath of fresh air. It was a technically competent OS with a nice, even wonderful front-end. People forget just how shitty GUIs were 15 years ago.

I still own a shirt that says, “I dig Mac OS X”.

I carry around 2, sometimes 3 iOS devices every day. Which is ridiculous, of course.

I remember thinking, back in 2008, how strange it was that just a year before I didn’t have EVERYTHING at my fingertips. The iPhone and iPad have drastically altered my lifestyle. I can’t even imagine life without them now. I use my iPhone more than I’ve ever used any computer or phone. Or any device, really.

iPhone, and iPod Touch and iPad have had such a huge effect on the market that it’s really hard to gauge. People lately have taken to saying that there’s no tablet market: there’s an iPad market. And it’s true. Apple is so far ahead of everyone else that it’s a bit embarassing. They’ll all catch up eventually, but right now the competition is completely incompetent.

So. Here’s one guy who managed to create and shepherd some seriously world-changing technology. I didn’t even mention iPods or MacBooks. He’s probably going to die long before his time. But a large part of modern life is shaped by what Steve Jobs has done. He changed the world for the better.

Here’s wishing him the best.

I think that’s a fantastic idea. I’ve thrown together some JS to do this. It’s available here. As a happy bonus, it allows for a range of sentences and it doesn’t require a page reload to highlight parts. The sentence selection, however, is terrible. So if anyone has any suggestions, please fork and put in a pull request.

My code does allow highlighting some stuff while jumping to another part, which I think is pretty neat. That is, “Read starting here, but really pay attention to this.”

(Also, Ken: No, you’re a nerd)

The last few months have been fairly trying. Two friends of mine have killed themselves since July. One was a partner in Flapping Crane, and the other was a childhood friend I haven’t talked to for a very long time. I went to Eric’s funeral. Couldn’t bring myself to go to Nick’s.

My dad sometimes tells stories about friends who killed themselves. It always seemed so alien to me before. I guess as you get older and meet more people, the chances of someone you know killing themselves goes up. Those are just the odds. That doesn’t make it easier to deal with. But it does help explain it, sort of.

There’s been some other crap that’s made life a bit stressful, but I won’t talk about it here, because I like being mysterious, like a squirrel with a cape. Why does he have that cape? Does he realize how badass it makes him look? Squirrels are nuts, yo.

I’m currently mulling wiring my house with Cat 6. Probably going to do it through air ducts, with a wiring closet in the basement. Seems like a nice way to avoid some of the more confusing pitfalls of wireless.

This Thursday, the wife and I are going to a live(ish) Riff Trax show, which should be a blast. Friday night, my dad and I are going to enter a poker tournament. I fully expect to last at least 15 minutes, though I’m possibly being overly optimistic.

It’s raining outside now. Dig that sound.

Anyway, I’m using it on a new version of flappingcrane.com to get around the downside to a recent security fix in Safari.  I wanted to have the icons for skits that have already been watched by the user to be translucent.  That’s normally a very easy thing to do using CSS:


.skitIcon a:visited {
opacity: 0.5;
-moz-opacity: 0.5;
}


However, there’s kind of a clever security problem with this.  In a nutshell, I can list a bunch of links on a page and give some CSS property to visited links.  Then if you visit the page, a script can examine those links and see which ones have those properties, thus telling me which of those sites you have visited.

A recent version of Safari disabled styling on the :visited pseudo-element for this very reason.

Anyway, this is less of a concern on something like Flapping Crane.  We can track what skits you watch, how much of them you watch, how often you pause them, etc.  While that might creep some people out (we only track hits or plays, but I’m sure many, many video sites track a lot more), there’s no serious security issue with that.  I can tell that you’ve watched “Bugles” 145 times (weirdo), but I can’t tell what other creepy web sites you visit.

So, while we can keep track of what client IP has watched what, there are a variety of reasons why I really don’t want to do that in order to style a few links.  One, I like to keep DB interactions to a minimum (hah).  Two, it makes for some clunky, ugly interactions that seem like overkill for a little opacity effect.

I’m sure you can see where I’m going with this.

When you watch a skit (again, on the new site I’m working on), if your browser supports localStorage, it’ll record that you’ve watched it.  Since it’s stored in your browser, there’s no need for querying the database.  Then, when listing out the skit icons, ones that have been viewed get a “watched” class.  Any CSS I want can be applied to that.

This is nothing that couldn’t be accomplished by a variety of other means, but it is nice to have such a remarkably simple way of doing it.  I haven’t decided if I’m going to put in a way to do it with cookies, which have more limitations.

First the C guys can’t imagine writing in assembly anymore, but C++’s vtable dispatch is still just too slow to consider. Then the C++ guys look back with chagrin at the bad-old-days of rolling their own half-assed object systems in C, but Java is dismissed as a ridiculous pig. Still later, the Java guys sneer at pointers and manual memory management, but JavaScript is ridiculed as a toy “scripting” language for validating web forms. And on and on.

It’s true.

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.

Twitter has ruined my ability to write more than a handful of words at a time.