A recent mozillaZine article reports that John Carroll of ZDNet has issues with Firefox’s HTML rendering when compared to Internet Explorer. Specifically, he has set up a test page that uses the overflow property: Internet Explorer displays the page as Carroll intended, while Firefox and Safari don’t. As Carroll describes it,

“I have created a Web page with a fixed position left, top and bottom sidebar that surrounds a scrollable area. All regions resize to completely fill the browser when its dimensions are changed.

To make this work, I have a table which lays out the basic position of the main sections (left bar, top bar, bottom bar, content). I’ve placed a div tag inside the “content” area of the table, setting its width and height to 100% and adding automatic scrollbars by setting the “overflow” CSS attribute to “auto.”

None of this is rocket science. Some might object to the use of tables, which in CSS circles might seem SO 1990s. I couldn’t care less. Tables are easy to use, are immediately intuitive to this old HTML hand-coder, and most important, have existed since the early days of HTML. Regardless of your preferences, there is no reason they SHOULDN’T work.

In IE, the page renders properly. In Firefox, the div tag refuses to size relative to its parent table (and doesn’t provide scrollbars), which causes the bottom toolbar to disappear past the edge of the screen.”

Carroll then proceeds to take Firefox to task for not doing a better job of mimicking IE’s behavior, implementing its proprietary features, and so on. The mozillaZine article retorts that it is Firefox that is rendering the page correctly, and closes with, “We’re not sure if Carroll intends to suggest that Firefox should not only support Microsoft’s proprietary extensions but also do the wrong thing [emphasis theirs] when IE is incorrect.”

I was curious when mozillaZine claimed that Firefox’s rendering was in fact correct. Were they right about that? Carroll’s page is a confusing beast, a weird hybrid of old-skool markup with a sprinkling of advanced CSS layout and overflow rules. Lots of bizarre behaviors we could be bumping into. Fortunately, it turns out the issue is pretty simple.

Let’s begin by eliminating a couple of red herrings. First: Carroll’s impassioned defense of table-based layout is charming, but irrelevant. At first I thought his table structure mattered, but it turns out we can reproduce the effect with only one box element. For its part, the mozillaZine article also snarked that the page “barely validates as the laxest form of HTML 4.0.” Barely validates… like being barely pregnant? Anyway, it turns out that the validation issue is also irrelevant. We could easily construct an XHTML 1.1 + MathML page that exhibits the same problem.

The root problem is in Carroll’s usage of the overflow declaration. What does overflow do? Consider a box that you have constrained to be, say, 50 pixels by 50 pixels. Now let’s say you want the box to contain a long chunk of content, say, all of Deuteronomy. Unless you find a reeeally small font, your content will not fit in the box. That’s where overflow comes in. The overflow CSS declaration defines whether the box should create scrollbars, clip the text, or whatever.

Now consider what Carroll’s page does. He wants to simulate a typical framed layout, where you have a fixed sidebar, topbar, and footer, and a scrollable content pane. So he’s done the following:

1. Set overflow: auto on his scrollable section. This, he thinks, should cause scrollbars to appear for this section if the content overflows.
2. Set overflow: hidden on the BODY element. This, he thinks, should force all other sections NOT to have scrollbars on an overflow.

Except there are two problems.

First, Carroll has set the height and width of his scrollable section to “100%” instead of a fixed size. This means that the box automatically expands as large as it needs to be to contain its content. Therefore Carroll’s scrollable section always is large enough to contain all of its content; therefore overflow never kicks in; therefore the section never generates the desired scrollbars, no matter how much “Bah Humbug” text Carroll adds.

Second, by setting overflow: hidden on the BODY element, Carroll has not forced all other sections to not have scrollbars. Actually, overflow: hidden on the BODY or HTML element is a special directive. It tells the browser, “Don’t generate scrollbars for the viewport itself,” i.e. the pane that contains the overall HTML page.

Thus, Carroll has doublefucked his code. Because he doesn’t understand how overflow works, his excess content will always flow down below the viewport. Ordinarily this would be fine — the user could scroll down as usual. But Carroll has told the browser to delete his scrollbars. The end result is a completely borked web page, albeit one that works in IE.

There are three lessons to be drawn.

First, if you want to simulate a framed page, use frames. (Or use position: fixed, if you don’t care about IE.)

Second, IE’s buggy behavior is a major barrier for competing browsers. The typical web designer is not someone who dutifully reads the specs; he is someone with a mental model based on trial-and-error, mystical cargo cult coding. Does it work in IE? It does? Oh good, we’re done. If the alternative browsers can drive their marketshare high enough, this problem will start to go away. Until then, Firefox, Safari, and Opera will always be blamed for IE’s shortcomings.

Third, validation is the starting point for good design, not the end goal. For any web page design, there is an enormous set of possible design problems. Validation reduces this set to a much smaller size, but does not eliminate it. As Carroll aptly demonstrates, it is easy to create a valid page that is totally screwed up. Still,validation is one of the best tools in your toolbox for eliminating basic rendering issues. Unless you are using XHTML (and at most only a couple hundred of you really are), this is by far the best practical reason to validate your pages. Probably the only practical reason. But that’s a story for another day.

Last year’s HTML House of Horror brought us the Page of the Damned, and was probably instrumental in bringing support for the MARQUEE element to Safari. What horrors will this year’s page unleash? If ye do doubt yer courage or yer strength, look nae further!

As some of you might know, my career as an experimental condensed-matter physicist ended rather abruptly in 1998. A garden-variety case of grad-school burnout… or at least, that’s what everyone was supposed to think.

The truth is that I was thrown out. When my innovative theories on the nature of spacetime came to the attention of the Institute for Theoretical Physics, the scientific orthodoxy moved quickly to silence me. I was turned out on the street, with naught but a spare cryopump and a broken dilution refrigerator to my name. They called me mad, mad! Fools! I’ve showed them all!

As anyone with even a passing acquaintance with quantum mechanics knows, probing the structure of events at the Planck scale requires tremendous power. Back-of-the-envelope calculations estimate that such experiments would require an accelerator the size of the galaxy, but such old-fashioned “reality-based physics” is no match for faith-based physics, physics forged by pure Strength and Will.

My first, failed experiments in early 2001 did have noticeable effects on the California power grid, and for that temporary inconvenience, I apologize. Despite those early setbacks, I managed to steadily lower power consumption and increase the sensitivity of the device. By the summer of 2003, I was able to probe the seething quantum foam itself. And I managed to confirm my theory that the foam resonates weakly in the wake of electromagnetic disturbances… electromagnetic disturbances from another slice of spacetime.

After another year of tuning, and the development of signal-processing algorithms the likes of which would make grown IEEE Fellows weep, I was able to detect actual electronic signals from the future. It has taken weeks of calculation, but my poor, aged G4 PowerMac has finally succeeded in decoding a fragment of an actual HTTP packet exchange. Look upon the works of the future, ye markup geeks, and despair.

Happy Halloween!

Rakesh Pai: “The Economics of XHTML” (via Anne Van Kesteren). Anne advises that when you read Rakesh’s article, you sub in “semantic HTML” for “XHTML”. That’s a good substitution, although I actually prefer “clean markup.” Making your markup more semantic is a good thing, up to a point. Once you cross a certain line, your mind begins an inevitable slide into Semantic Extremism, until eventually you’ve convinced yourself that everything should be a list item or some such nonsense.^[1] But I digress.

There have been countless articles like Rakesh’s about how XHTML clean markup will save you big bucks. Honestly, I don’t fundamentally doubt the overall theory, but it disturbs me that none of these fine articles puts out hard numbers on how much money you’ll actually save in practice. The most concrete examples in the genre so far are the “redesign articles”, wherein the author picks a large site with crufty markup, redesigns the home page with clean markup, and performs a highly naive calculation of the bandwidth saved. The best article that I know of is Mike Davidson’s interview with DevEdge, and even that piece only provides a theoretical estimate.

So let’s all put on our Business Analyst hats and ask a few questions that might be pertinent for designing an actual case study. To be sure, thinking in BizDev does not come naturally to most folks, certainly not me.^[2] So first, a short cleansing ritual, to prepare the mind for these alien thoughts:

Ph’nglui mglw’nafh Forbes R’lyeh wgah’nagl fhtagn! ROI! ROI! ROI! Aiiiiieeee!

Ah, there we go. Now, consider a largish commercial site:

• What are the actual bandwidth savings over one-month period, factoring in caching, real-world resource request patterns, etc.?

• How much does a TB of bandwidth go for these days? How much will that same TB cost three years from now?

• How much developer time does it take to refactor a complicated CMS to produce clean markup?

• How much developer time does it take to clean up legacy content? Is this archived material accessed often enough to be worth cleaning?

• Are developers who have modern skills more expensive than old-skool <font>-happy developers? (I would think so.)

• What percentage of visitors use NN 4 or IE 4? Does the revenue lost from these visitors outweigh the overall bandwidth savings?

• How much does it cost to employ other techniques to speed up your site, such as enabling conditional gzip compression? Comparing these techniques with a total redesign, which ones are the cheapest?

I don’t have the answers to these questions. But I do suspect that any web design shops that can answer these questions (with non-foofy numbers) basically have a license to print money.

1. If we all lived in Web Designer City, a metropolis bustling with architects and bricklayers, professors and artists, hustlers and street vendors, you would be the guy staggering down the street, muttering to himself.

2. Business persons tend to ask questions that either A) make no sense or B) are so hard that any response you get back is almost certainly a lie. Or if we’re feeling charitable, a “Wild Ass Guess.”

It’s been interesting to see the back–and–forth discussion between CSS guru Eric Meyer and lead Safari developer Dave Hyatt on Apple’s proposed Dashboard extensions to HTML. At first Eric nearly hit the boiling point, but he is now working constructively with Dave to help him extend HTML in as safe a manner as possible. I’m glad they’re working together on this, because this is pretty important to get right. HTML could certainly use enhancement, but we can’t afford to implement these enhancements and in so doing FUBAR validation entirely.

The really exciting thing about Dashboard is that Apple clearly intends Dashboard widgets to be as easy to write as possible. This is one of the main reasons that they’re targeting HTML, as opposed to XHTML exclusively. Dave points out that:

“First, it was suggested that the widgets be written in XML rather than HTML and that all of the new tags and attributes be namespaced. However, this would have dramatically increased the complexity of crafting Dashboard widgets. People know how to write HTML, but most of those same people have never written an XML file, and namespaces are a point of confusion.”

This has of course drawn out legions of Markup Experts to snigger that XHTML isn’t so hard, Apple should do things properly in XHTML, Apple is just being “lazy”, how dare they muck with rotten old legacy HTML, any developer worth their salt can write XML, et cetera. For amusement, I bounced around the web this morning checking out these arguments. I validated five pages in a row. One hundred percent were serving up their arguments as non-well-formed XHTML.

Replication of this experiment is left as an exercise for the reader. In the meantime, I’m thinking of taking up watercolor painting.

For a long time I had been mostly indifferent to the nascent Atom syndication format. True, Atom was taking the right approach in formalizing its specification and developing comprehensive test suites. But I was still thinking, why bother adding an Atom feed when I already had perfectly fine RSS feeds? In other words, “What does Atom add that RSS can’t already do?”

That was my mindset until a few weeks ago, when Mark Pilgrim delivered a well-needed sharp blow to the kidneys to that whole idea. This is when I got religion. Of course, I really should have gotten religion well before that, but I’m a slow learner.

So I was all rarin’ to go, ready to put up an Atom feed, when another post by Mark brought me up short. In his instructions on “How to make a good ID in Atom“, Mark advised against using your HTTP permalink URI as an ID, recommending Tag URIs (yuck!) instead. Then Tim Bray chimed in, saying that permalink URI as an Atom ID is probably fine, but if you don’t want to use that, you can construct a NewsML URN (yuck again!) Not to be outdone, Bill de Hora said, “Never mind the URI.” Permalinks — heck, domains themselves — are transient, so… use Tag URIs. But wait, Tag URIs (at least the way Mark constructs them) contain domains! Pretty soon my brain started to hurt, and I decided to back off and think about this later. Then things got busy at work, time passed, life went on. I probably would have forgotten about the whole thing, except I a few days ago I noticed a task in iCal: “Make Atom feed.” Stupid iCal.

So it’s back to thinking about Atom IDs. Each entry in an Atom feed must have a globally unique, unchanging ID that is also a valid URI. The idea is that Atom applications should be able to identify feed entries uniquely, even if your entries get resyndicated or published in several places at once. However we choose to generate our Atom IDs, we are duty-bound to ensure that they don’t change after creation and that we don’t accidentally clobber someone else’s Atom IDs.

Okay, so what can we use that’s unique and unchanging?

• My domain of goer.org is unique — I own it, and no one else who’s publishing feeds should be using it. (Bill would say that I’m just renting my domain, but as we’ll see, that doesn’t really matter.)

• The creation timestamp of each entry is unchanging.^[1]

Together, the two form a globally unique, unchanging event. For example, on May 10, 2004 at 9:56pm and 30 seconds PST, the site goer.org posted the entry, “Supercharge Your Outlook Performance!” Now, the domain goer.org is not unchanging — I could easily lose it. The creation timestamp is not unique — there’s an excellent chance someone posted something on May 10, 2004 at 9:56pm and 30 seconds PST. But put the two together, and we have the makings of a simple but robust Atom ID:

https://www.goer.org/2004/05/10/21/56/30/PST/

Note that this is not the permalink to that entry. The permalink is https://www.goer.org/2004/May/index.html#10. The Atom ID takes the domain and appends the timestamp components, separated by forward slashes. I used forward slashes because I know that forward slashes can be used to make valid HTTP URIs. (Tag URIs and NewsML URNs seem weird and scary to me, so I decided to stick with familiar HTTP URIs.) Thus, the Atom ID is a valid HTTP URI, even though it doesn’t point directly to an HTTP resource. Based on my cursory reading on HTTP URIs, I think this is okay. (If I’m wrong about that — if it is incorrect to design an HTTP URI that does not point directly to an HTTP resource — let me know.)

For another example, consider my HTML tutorial. The permalink for the entry on classes and IDs is https://www.goer.org/HTML/intermediate/classes_and_ids/. However, the creation timestamp was August 21, 2002 at 12:34pm and 03 seconds PST. Thus, the corresponding Atom ID would be https://www.goer.org/2002/08/21/12/34/03/PST/.

I’m trying to think of scenarios where this scheme would fail. It doesn’t matter if my permalinks change. The domain and creation timestamp are still the same. Nor does it matter if I lose my domain name. I couldn’t produce future entries with the same domain, but the entries I already produced would still be valid, and I could certainly produce new entries with a new domain name.

For example, let’s say that on January 1, 2005, I’m getting married. Because I’m such a forward-thinking, progressive guy, I’m not asking my wife to change her last name — in fact, I’ve decided to change my last name to hers. Henceforth I am to be known as “Evan Goer Nahasapeemapetilon.” And to really drive the point home to friends and family, I’m dumping goer.org for a more appropriate domain name. So now to the really important question: what does that do to my Atom entries? Well, all posts before January 1, 2005 would have the form https://www.goer.org/YYYY/MM/DD/HH/MM/SS/PST, while all posts after January 1, 2005 would have the form http://nahasapeemapetilon.net/YYYY/MM/DD/HH/MM/SS/PST. Old entry IDs are unaffected, and all IDs are still unique.

Okay, but what if someone else takes over goer.org? In order to have a collision, the following would have to happen:

1. The new owner decides to publish an Atom feed, AND
2. They happen to use the exact same format I do, with the exact same separators, AND
3. They decide to publish entries that were created in the past, before they owned goer.org, AND
4. Some of those entries have creation timestamps equal to some of mine, down to the second, AND
5. The old entries have never been published as Atom entries before, because otherwise they would already have an Atom ID, and Atom IDs are unchanging, remember?

The other scenario I thought of is, what about a gigantic site that produces many thousands of entries a day? In that case, we do start to have a non-trivial chance of having two entries with the same creation timestamp. However, the Reuters and eBays of this world can certainly afford to generate some sort of extra identifier to ensure uniqueness. Fortunately, the average weblogger wouldn’t need to add this extra machinery.

Okay, let’s sum up: to make a good Atom ID, construct an HTTP URI using domain + creation timestamp. Anyone see any problems with this scheme? If not, I’ll forge ahead with Atom in a few days. One Atom feed will provide entry summaries, while the other will be the first goer.org feed ever to provide full-content goodness. Yum!

1. In this inertial reference frame, anyway.

Dave Shea institutes a form of comment moderation; predictable firestorm ensues. Dave also redesigned his site. switching to black text on a white background, with plenty of whitespace. The default font also looks bigger and clearer to me, although that could be an illusion — I haven’t really looked at the old and new stylesheets side by side. Overall, I think it looks great, but I’m biased towards higher contrast and larger fonts. I’ve been thinking about writing a song about this, actually…

I like big TEXT and I cannot lie
You other designers can’t deny…

Eh, well, it needs some work.

In Other Markup-related News: Peter-Paul Koch has a great article on cleaning up inline JavaScript in favor of using simple DOM hooks instead. Good stuff. Often irascible but always entertaining, Peter-Paul Koch is like the Joe Clark of JavaScript. You have to give PPK credit — if he finds it necessary to add a non-standard replace attribute to his code, he’ll do it, and the hell with validation if it gets in the way of his work. In this day and age, this is quite the bold position. After all, these days the issues seem to revolve around such things as the semantic meaning of the <div> element and how many <h1> elements can dance on the head of a pin are allowed on a single webpage. Heck, you can’t even kinda sorta make the suggestion that maybe simple structure tables might be useful under some circumstances without getting lambasted by markup purists. So you’ve got to respect someone who uses their markup to actually, you know, solve problems. PPK, my hat is off to you.

It always has seemed kind of silly to discuss markup so often, and not allow people to use inline links in their comments, for crying out loud. So I’ve opened up a small subset of HTML elements. The new system allows links and a number of inline elements such as <em> and <code>. I would have liked to open up elements such as <pre> and <blockquote>, but… eh. It’s a long story. Anyway, the upshot is that instead of saying,

Evan, your “commentary” on <marquee> and <blink> (https://www.goer.org/HTML/examples/htmlhorror1.html) was in *wretched* taste.

you can now say,

Evan, your “commentary” on <marquee> and <blink> was in wretched taste.

How exciting! I almost opened up the style attribute, so that you all could chew me out in large, red Comic Sans MS. But bold will have to do.

Aaaanyway. Since this entry is so short, here are a few amusing physics links I’ve collected over the last few days.

• Chad Orzel: Scattered Thoughts on Physics Pedagogy. Chad, Chad, you’re teaching engineers. Why are you tangling yourself in knots? Just teach V=IR by rote, hand out A’s like candy, keep a low profile, collect tenure, everybody’s happy. Sheesh, I really should have stuck with academia. It ain’t exactly brain surgery. [Via J. Bradford DeLong.]

• From TechCentralStation, the same magazine that brings us Instapundit’s ruminations on how Luddites are holding back “molecular manufacturing”, we find this article on global warming. It’s replete with gems such as:

  “Take, for instance, the “average global temperature,” which is the primary statistic offered as evidence of global warming. The problem with this statistic is that it has no physical meaning. Temperature is not a thermodynamic variable that lends itself to statistical analysis, nor does it measure a physical quantity.”

  Oh, dear. Bear in mind that I have met hardcore Ayn Rand libertarians who do understand thermodynamics, some of whom have even gone on to earn doctorates in physics. So I think it’s just TechCentralStation. [Via J. Bradford DeLong. For an economics professor, he’s quite the clearinghouse for physics links. Maybe he should read up on Quantum Finance.]

• Understanding Research Papers. For the record, “correct within an order of magnitude” is a perfectly acceptable answer in astrophysics.

Quite a storm of activity going on over at Dave Hyatt‘s developer weblog.

Dave is clearly annoyed with the difficulty of parsing broken HTML. It’s an extremely hard problem to solve, and not very well-defined. It must be even more frustrating to have to be judged against the quirky behavior of the dominant browser. And Dave is exactly right about Safari’s XML parser: it must be “Draconian“. Otherwise, by definition it’s not an XML parser. (The more interesting question is whether one should actually use an XML parser to parse XHTML.)

All of this kerfluffle has generated various proposals for solving the problem of broken XHTML. Presumably the web would be a better place if all XHTML files were well-formed and therefore parseable with a standard XML parser. But the reality is that about 75% of XHTML home pages are invalid, and over 90% of XHTML sites have at least one invalid page.^[1] So how do we improve the situation?

One commenter on Dave’s weblog said that he dreamed about a “fascist” browser, one that would refuse to display any page with any errors. Unfortunately, a recent weblogs.mozillazine.org server error swallowed that comment forever. It seems that the Great Spirits of the Internet have spoken. Fascist browser: bad idea. Let us never speak of it again.

A friendlier variation on this proposal is to design a browser that still displays a malformed XHTML page, but provides some sort of obtrusive error message. The basic idea is that the users will then know about the errors, the website will receive a flood of complaints, the designers will fix the page, and XHTML quality will improve. As Dave puts it:

“Many people suggested that there be a built-in validator in the browser that could show the errors to the developer. The validators basically break down into two types: obtrusive validators and unobtrusive validators.

If the validator is unobtrusive, then I would argue that it won’t receive sufficient usage to make a difference. If the browser doesn’t impose a penalty of some kind, then there will be no incentive for the author to correct mistakes.”

Never before has the gulf between developer and end user been more stark.

I’m hoping this is simply the result of sheer frustration on Dave’s part. That at some level, he realizes how quickly this “feature” will destroy Safari. In a sense, it’s kind of reassuring. Proves he’s human.^[2]

Unfortunately, I don’t think any browser could survive pulling such a stunt. Maybe Internet Explorer could… after all, IE users have been trained for years to ignore annoying technical messages, and most of them don’t know how to change their browser anyway. It would be a close one, at least. Actually, here’s a clever evil plan. If we could somehow convince the IE development team that the “helpful fascist” browser was a good idea, we’d be in a win-win situation. Because either:

• XHTML quality would magically improve all over the web, OR
• Firebird and Opera would capture 50% of the Windows browser market.

Oops, did I say that last part out loud? Damn. Being an evil mastermind is harder than I thought.

1. Note that the XHTML 100 does not distinguish between well-formedness errors and validity errors. However, I can assure you that very few sites were invalid but well-formed. Most of the failed sites generated a torrent of errors of all kinds.

2. Although we really ought to run Dave through the Voight-Kampff Empathy Test, just to be sure.

Mark Pilgrim: “Thought Experiment“. It’s not a thought experiment, actually. It’s Jacques Distler‘s reality.

Here’s a short story for you all. My company makes a large suite of J2EE software, mostly for banks and insurance companies. Our software uses XML all over the freaking place. We use XML for our configuration files, XML to communicate from our machines to our customer’s machines, and so on. Machines happily consuming XML from other machines. It works just fine, thanks.

One example of where we are using XML is in our workflow engine. A workflow contains tasks, chained together in a kind of graph. If you change the shape of the graph or the nature of the tasks, you change the work that the end users (the customer service representatives) have to do. Tasks and workflows can be in various states, they can connect to each other in certain ways, they can branch due to logical conditions, they can contain timing information, they can be routed to specific users or groups… and on and on it goes. As you might expect, the XML that represents a workflow is rather baroque.

Fortunately, we provide a nice GUI interface that allows you to quickly create tasks and assemble them into a workflow. Like the workflow engine, the GUI interface can read our proprietary workflow XML format. But instead of running the workflow, the GUI merely displays it in graphical form. Anything you can do by editing XML files, you can do by using the GUI interface. Huzzah!

Unfortunately, one of my newly-adopted manuals both A) lists every element and attribute of our workflow XML format and B) describes how to use the XML in detail, with many code examples. By placing this information in our public documentation, we have accidentally encouraged our customer engineers to muck with the workflow XML format by hand. This has caused exactly the sort of problems you would expect. And this is why I spent a good chunk of last week stripping out all of this information from our public documentation. The information will partly move into the schema, partly be reserved for internal documentation. If our customers need this information, they can get it. But we won’t be broadcasting the message, “Look! It’s XML! Open it in vi and have at it!” quite so loudly.

The more I have to deal with XML, the more convinced I grow that XML is for machine-to-machine communication only.

Yes, the goer.org Matrix stylesheet is back, baby!^[1]

This Halloween, Marnie and I carved jack-o-lanterns and everything, but no trick-or-treaters showed up at all. It sucks living in an apartment building. We even left a little trail of jack-o-lanterns leading up the door, but no dice. I think we probably scared off the kids, if anything. “Now son, don’t go trick-or-treating at the place of the Evil Apartment People… they’re just trying to lure you in to their laboratory.” Anyway, now between my birthday cake and the uneaten candy, I have a serious excess of chocolate in the house. I guess I’ll take the candy to work, where it will be appreciated by a rather different set of costumed children.^[2]

Anyway. I’m trying to stay off this Markup stuff for a little while, but I couldn’t let this pass. Late last week Dave Hyatt^[3] decided to add support for the <marquee> element to Safari (presumably in the upcoming Safari 1.2). Coincidence? I think not. Oh sure, in his comments Dave mumbled something about wanting to support certain prominent Asian websites where <marquee> has proved popular, blah blah blah. But we all know what the real reason was. Now if Dave would just add support for the <blink> tag, Safari would surpass Mozilla and reach the exalted ranks of Opera, the only browser in the world currently able to display the Page of the Damned in all its unholy glory. You don’t want Opera to beat Safari on this point, do you Dave? Especially after they said those mean things about Safari…

Ah, there’s nothing more fun than stirring up trouble on a Monday morning. You know, this site really is becoming a repository of pure evil. People are already starting to use the Page of the Damned as an example of the <marquee> element; soon I’ll completely corner the competitive <marquee> market, just as I have for cursed frogurt. Yes… everything is proceeding as I have forseen.

1. Not seeing the new stylesheet? Take the red pill, reload the page… and free. Your. Mind.

2. Must keep the demonic engineers well-fed with sugar… or there will be… trouble…

3. I’m never sure — is Dave the lead Safari rendering engine developer? The only Safari rendering engine developer? Or just the only famous one?