Thanks to Anne Van Kesteren for inspiring the HTML House of Horror. I’m not sure if he really meant to inspire it, but life is funny like that. So read on… if you dare!

Introduction

Several years ago, my roommate Sam was playing around with a language he called “HTML”. The great thing about HTML, I thought, was the power it gave you over the screen. Just reload the page and presto! Words, colors, images, fonts — you name it. It was sooo much cooler than the “real” languages I had struggled with in college. I didn’t know how to turn the screen red in C++, but darned if it weren’t easy in HTML.

I still remember downloading and embedding my first image in a page, a tacky little dancing Santa animated GIF. “Check this out!” I said. Sam seemed kind of impressed, but not sufficiently so. Hmmm, I thought. Okay then, let’s try this BACKGROUND attribute…

Suddenly, the screen flooded with dancing Santas. That was the day I learned: with great power comes great responsibility.

The <blink> tag

Once upon a time, Netscape and Internet Explorer fought for the hearts and minds of HTML coders in what became known as the browser wars. Although the conflict ended long ago, the battlefield is still strewn with landmines, otherwise known as proprietary tags. The theory was that by adding whizzy new features available only in the Netscape (or IE) browser, developers would flock to that “platform”. Sadly, judging by the number of “best viewed in IE 4” messages that still litter the web today, the theory was pretty sound.

The Netscape-proprietary <blink> tag… well, makes text blink. Microsoft never implemented this tag in Internet Explorer. One might attribute this decision to Microsoft’s sensibility and good taste, but given their response to the <blink> tag, this explanation seems unlikely. Of the billions of pages on the public web today, there are only two sites in existence that make effective use of the <blink> tag:

• The Problem With Music by Steve Albini
• The UNIX-Haters Handbook login screen

Other than that, it’s all crap.

Although the <blink> never made it into the HTML standard, it still lives on to this day in Gecko-based browsers such as Netscape 7 and Mozilla. And although the tag itself is forbidden, have no fear! The CSS standard continues to provide the World Wide Web with critical blinking functionality, in the form of the CSS declaration text-decoration: blink. Inquiring minds might wonder — what happens if you declare the following CSS rule?

  blink {
    text-decoration: none;
  } 

On Mozilla/Mac, the result is as you would expect. I haven’t tested this markup on other platforms, but my theoretical model predicts that your system will just, like, explode. Don’t say I didn’t warn you.

The <marquee> tag

The Microsoft-specific <marquee> tag scrolls a selection of markup across the screen. Essentially, the <marquee> tag creates a 100% wide div with text creeping across the screen from right to left, or left to right. There are a large number of attributes for the <marquee> tag: you can change the width, the alignment, the scrolling speed, the scrolling delay, and even the scrolling direction (right to left or left to right).

And if that’s not enough shiny animated goodness for you, you can of course style the <marquee> tag with CSS. For some reason IE5/Mac ignores the width property, but you can still muck with the padding, font, and color to your heart’s content. Furthermore, IE4+ allows you to marquee-up arbitrary chunks of markup, not just text. If we need to have a table or bulleted list sliding across the screen, we can build it. We Have The Technology.

Note bene: nesting <marquee> tags is not recommended.

A Most Horrifying Discovery

And now we come to the most horrifying discovery of all. Mozilla supports the <marquee> tag. Let me repeat that — Mozilla supports the <marquee> tag. In other words, the following markup is now possible:

  <marquee>
      <blink>Night Of The Living Dead</blink>
  </marquee>

Back in 1997, the line of demarcation was clear: Netscape supported <blink>, Internet Explorer supported <marquee>, and that was the end of the story. But today in 2003, we have a browser that supports blinking marquee text. Yes, only in the fiendish laboratory that is the Gecko Rendering Engine is such a crime against humanity even possible.

There are those who believe that there are lines that should never be crossed. There are those who believe that there are Secrets Man Was Not Meant To Know.

And then there are those who forge boldly onward on paths where more timid souls dare not tread. In the interest of Science,^[1] I have have painstakingly constructed the most horrifying web page ever written. Behold! The Page of the Damned!^[2] (view source) Those of you with a Gecko-based browser will see the Page of the Damned in all its glory; anyone using a lesser browser will be shielded from the horror. So if you do doubt your courage, or your resistance to video-induced epileptic seizures, come no further. Either way, may you forgive me for my crimes, and may the W3C have mercy on my soul.

Happy Halloween!

1. Mad Science!

2. The Page of the Damned uses no JavaScript. It does use a smidge of CSS, but only because the <basefont> tag doesn’t seem to work in Mozilla. Also, to my great disappointment, Mozilla doesn’t support the direction attribute of the <marquee> tag. So in theory the page could have been even more horrifying, but we make do with the tools we have.

“Rest assured, I was on the Internet within minutes, registering my disgust throughout the world.”

So far, this week has not been a great week, technology-wise.

First, this week’s award for Kookiest Third-Party Documentation goes to JUnit.org, for their rather creative Javadoc description for TestSuite.createTest(). Umm, guys, the traditional we-don’t-give-a-rat’s-ass-about-our-Javadoc Javadoc would have been something like, “TestSuite.createTest(): Creates a test.” Better to be random and pointless than simply pointless, I suppose.

Second, a special shout-out to Dell for designing their hardware such that you can’t buy 3rd-party memory. Let’s see, $210 for two sticks of PC100 RAM.^[1] At least now my system can handle amazing feats of computational wizardry… such as running Netscape and FrameMaker at the same time.

But the real winner of this week’s sweepstakes is the <object> tag. The problems with this tag are well-known. Yes, it has terrible support in modern browsers. Yes, it is the only replacement for the <img> tag in XHTML2… still. And no, the situation is not going to improve significantly until about the year 2006. But you’ve heard about all that. I’d like to share with you my particular episode of <object> tag pain.

The trouble started when I decided to play around with SVG. I dutifully downloaded the Adobe SVG plugin, and soon I was off to the races.

So how do you embed SVG in a web page? In theory, you could do it inline… if you served up a pure XHTML page with the right MIME-type, and a carefully constructed DOCTYPE, to the right browser, on every third Sabbath after Simchat Torah. But even the foolhardy don’t bother with this strategy. No, the accepted method uses the <object> tag, like so:

<object type="image/svg+xml" data="/path/to/image.svg"
    width="400" height="400">
  <img src="/path/to/image.gif" width= "400" height="400" 
    alt="description" />
</object>

The <object> tage embeds the SVG image, while the old-fashioned <img> tag provides a fallback GIF image for older browsers. Elegant, right? Only problem is that this markup crashes my copy of Safari every single time.

The problem is with the type attribute, which specifies the MIME-type of the SVG file. If the attribute is present, Safari crashes. If you delete it, Safari works just fine, but IE 5.2 for Mac no longer displays the object. Apparently IE5.2 needs the MIME-type explicitly defined. (This might also be the case for IE/Win, but I haven’t tested this yet.) Note that both browsers have interesting and quirky behavior. Safari is perfectly happy to display the SVG image if there is no type attribute at all or a totally made-up value (such as “foo/bar“. However, a wrong MIME-type (“text/html“) causes Safari to A) not display the image and B) bring a Finder window to the foreground. (?!) IE5.2, on the other hand, refuses to display the object if the attribute is absent or if the MIME-type is totally made up… but it does display the image if you provide any MIME-type that it understands, such as text/html. Meanwhile, Mozilla displays the image in all circumstances.

But don’t fret! You know what works for all three browsers, every single time, with no crashing or quirks whatsoever?

<embed src="/path/to/image.svg" width="400" height="400">

Yeah, I need a drink too.

1. Seriously, who do these Dell guys think they are? Apple?