The making of QuirksMode.org

I wrote this page for the launch of QuirksMode.org in autumn 2003. I will continue to improve my site, but I won't update this page after each improvement. That'd be too much work.

On this page I explain how and why I created QuirksMode.org as it is. I go through all my decisions in detail, mainly for the sake of my less experienced readers. I think an extended example like this one will teach you what sort of decisions you're making when creating a website, and what the consequences of these decisions are.

You don't have to agree with everything I've decided, but if you disagree please wonder why you disagree, and try to formulate an alternative. (Please don't send me any mails with alternatives, though. I'll probably ignore them because I'm happy with the site as it is)

This page is less exciting for advanced web developers who have taken many such decisions before. Nonetheless I hope a small detail somewhere may catch your eye. I have also hidden some browser incompatibility gems for your pleasure.

Business case

In the past I had three main sites and a host of smaller ones. The main sites were the JavaScript Section, the CSS 2 Tests and my Dutch Freelance site. In addition I had a separate official homepage which served no purpose, a directory of random tests, an XML/XSL example on my old employer's web server (which, as far as I know, is the earliest example of client side XSL), and separate sites dedicated to the Thidrekssaga and vegetables and intertextuality. Finally, my browser notes were part of the JavaScript Section for historical reasons, but they also gave much CSS information. Strictly speaking they should be located in both sections or in neither of them.

When I wanted to announce a new external article, I had to update four homepages (main, JS, CSS, freelance) in addition to my Publications page (located, for no good reason, in the JavaScript directory) and any technical page the article might apply to.

I rarely bothered. In practice I treated the JavaScript homepage as the homepage of my entire system of sites and announced new articles only there. That doesn't work in the long run, though.

It was a mess. My sites definitely needed rigorous restructuring.

Client requirements

So I received myself as a client and stated my requirements to myself. I needed one site that contained all the web development information I offered and that had only one homepage.

I was happy with the internal structure of the JavaScript and freelance sites, though I decided to split the JavaScript Section into three: JavaScript, W3C DOM and browsers. I was less happy with the CSS 2 Tests structure, but it only needed an update, not a complete restructuring.

Basically I just needed an extra layer of links to "JavaScript", "CSS 2" etc., preferably presented in an 'intuitive' way.

Surprisingly, this problem cost me two months to solve. When I decided to expand my old two-level navigation script to a three-level one, I wondered why I didn't think of it before.

Meanwhile the new design of my site and business cards had become available and I'd found the perfect domain name. I could start working.

Target audience

My primary audience consists of web developers, beginner, advanced or expert. They come to find answers to browser compatibility problems. This audience needs to quickly find its way among the more than 150 technical pages on this site, which made a long, structured list with links to all pages mandatory. In addition, there must be short descriptions of the pages somewhere.

My secondary audience consists of prospective clients. Their requirements are easy to satisfy, too. They need one prominent link on the homepage which leads to my Freelance section. Within this section they need a few pages of information and a portfolio, linked to each other. Finally, this audience needs a simple way to contact me.

Key decisions

I quickly took some key decisions.

  1. For a perfect QuirksMode experience, a browser should support CSS2 and the W3C DOM. Older browsers would see a far plainer site, though the content would have to remain accessible.
  2. I reaffirmed my decision not to bother with the validation circus. Instead I'd check the site in the Five Modern Browsers: Explorer 5+ Windows, Explorer 5 Mac, Mozilla, Safari and Opera, and change my code until it worked in as many of them as possible. That's what I've done ever since I make websites.
  3. I knew in advance that even the modern browsers wouldn't perfectly support everything I wanted to use. Too Bad for those browsers, though the content should remain accessible. I especially worried about Explorer Mac. It isn't really up to advanced W3C DOM scripting.
  4. I would continue to use frames. I explain my reasons in detail on the separate Why frames? page.
    As a courtesy to frame haters there would have to be a 'No frames' link somewhere.
  5. I would change as little file names as possible, even though the older ones are quite ugly and non-descriptive. Nonetheless changing them would also force me to change an unknown number of links leading to them.
  6. I'd concentrate on 1024x768 and larger resolutions. My site would be just about usable at 800x600, but not at 640x480. Fortunately my target audience mostly has modern, large monitors.
    Besides, switching to the No Frames version would help users with older monitors.
  7. I did not wish to use any of the fashionable hacks for hiding a CSS declaration from one browser, with the single exception of @import against extreme cases of Netscape 4. I want all browsers to use the same set of style declarations. It keeps my code clean and simple, and I've always created CSS in this way.
  8. I would add some nifty scripts: the navigation, the breadcrumb generator in the top frame. I toyed with the idea of a cross-frame font size switcher, but in the end decided not to bother. You can enlarge font sizes in almost all browsers, and I could expect even the average Explorer Windows visitor to be aware of that fact.
  9. All overhead scripts, even the simpler ones that do not require the W3C DOM, would work only in the newest browsers. I was sick and tired of endless workarounds to marginally include Netscape 4 or Explorer 4.
    This restriction would not apply to the scripts that form the content of the site, of course.
  10. I would not use a content management system. I don't need it. I work faster in the HTML source code than in some system with a vague interface and endless forms.

Navigation and accessibility

So I would continue to use a navigation frame and extend the two-level system to a three-level one. This navigation frame would only be visible in W3C DOM compatible browsers.

One of my pet theories is that a site should have several navigation systems that work side by side. Thus the user can use the system he likes best. In addition, this allows me to restrict one of the navigation systems to advanced browsers only. The other system will work in any browser and will prevent accessibility problems.

So I had to think about accessibility and create a second navigation system.

This site's subject is CSS and JavaScript, and it is nearly impossible to appreciate the content without a browser that supports CSS and JavaScript. I don't think blind users with obscure screen readers or kids with the latest and greatest mobile phones will visit this site in great flocks.

In fact I worry about only two accessiblity issues:

  1. Is the site accessible to older JavaScript browsers? Users should be able to test scripts in, for instance, Netscape 3.
  2. Is the site accessible to Lynx? I can imagine a busy web developer starting up Lynx to quickly grab a bit of code from my site.

The answer to both is "Yes, though with difficulty". The frameset is only available in W3C DOM browsers. All other browsers get a simple "Enter here" link that leads them to the homepage. This link is meant only for older browsers.

Once older browsers arrive on my homepage they plug into the secondary navigation system. The homepage contains links to the tables of contents of all sections, and these tables contain links to all content pages in their sections. Simple to understand, easy to implement. In addition these tables of content allow me to describe my pages more fully, something for which there is no room in the navigation frame.

This secondary navigation system also keeps the site accessible when users of modern browsers opt for the No frames version. Finally, some users will like it better than my navigation frame, even though they remain within my frameset.

The secondary navigation system is less usable than the primary one since it doesn't offer a sitemap-like overview of my site. That can't be helped, though. JavaScript is meant for adding usability to a site, and a browser without (sufficient) JavaScript will miss some of the nice extras.

One problem remained. Should a content page contain any structural links back to, for instance, the homepage? Should users of old browsers see links at end of a page or not? If so, I'd have to hard-code these links.

Instinctively I said No. I wanted a page footer all right, but I wanted to maintain it in JavaScript. Was that unfair to users of old browsers? After some more thinking I said No again. Every page is accessible for testing or code grabbing purposes. The site as a whole, though, is less accessible. A subtle distinction, and it saved me a lot of work.

Besides, there's always the good old Back button.

The framework

I'd taken enough decisions, I could start working. For starters, I had to create the frameset, the top frame, the navigation page and a few content pages. Fortunately I had plenty of content available.

Frameset

I wrote a JavaScript document.write() routine that only works in W3C DOM compatible browsers for creating the frameset. As I said I count frames as an advanced effect, so I deliberately excluded older browsers.

I added a simple link leading to the homepage.

Content page template

Then I created one content page to serve as a template for the other 200. Making a good content page template is trickier than it seems. You have to create a structure that will withstand the ages (well, years), that offers room for functionalities you haven't yet conceived, and that accomodates that one page on your site that is totally different from the others.

Besides, I had inherited nearly 200 pages of content and wasn't particularly eager to radically change every single one of them by hand. Fortunately most of these pages used the same ur-template, though there were regional differences between my sites. The Freelance site used another system, but it contained only fifteen pages worth of content. Trivial.

Way back in 1998 I had decided to use h2 for my page titles. The original reason was that I found unstyled h1's too large. I thought about switching to h1's but in the end decided not to, partly to annoy people who maintain that any page must start with a h1.

After the page title come the headers, which were all properly marked up with h3's. After the headers come the sub-headers and for historical reasons they were marked up with h5. Back in 1998 I'd decided on a h4 with a Home link at the bottom of each page. A year later I needed sub-headers, and as an emergency measure I decided on h5 to avoid having to update more than 40 pages. I never changed this odd system in my old sites, but now that I'd have to update all pages anyway, I could just as well switch all h5's to h4's.

That took care of the headers. After the page title comes Last Modified information. I used to have a block of script to generate it on every page. This was ugly, so it had to go. Instead I created a simple <div id="header"> that would contain header information, among which Last Modified.

Thinking structurally, I immediately added a <div id="footer"> as the last element of the template page. I wasn't yet sure what header and footer information I'd need, but at least each page contained structural blocks ready to receive whatever information I deemed necessary. I'd use JavaScript for actually generating the content.

Side note:
I started out with a header p instead of a div. I can't really remember why I did this originally, but the reason I changed it is worth noting. During an experiment I generated a block of navigation in the header. This block was marked up by a div and was appended to a p. All browsers showed it perfectly, only Explorer on Windows threw a very weird error.
After protracted thinking I decided that Explorer on Windows was protesting against structurally invalid markup. Everyone knows (and I'd forgotten) that a p may not contain other block level elements, but Explorer Windows, supposedly the least standards compatible browser, was the only one to refuse my bad code.
I changed the p to a div and the error was gone. Later on I decided not to generate the block of navigation after all, but it had done its duty by revealing a weak spot in my template.

After the header comes a separate block with browser compatibility information. I used to use li's for marking up the lines of information, but switched to the more logical p's. Otherwise I wanted it to henceforth float right. CSS being perfect for such a restyle job, I expected no difficulties.

Then the actual content. It was already marked up with p's, some ul/li's where necessary, pre's for the code examples, and a simple system of CSS classes perfected during five years.

I added the following classes:

Finally I added references to quirksmode.css and quirksmode.js, as yet empty files that would once contain the entire presentation and behaviour layers of all content pages. I don't much like multiple css and js files when one of each will serve, so I decided to stick with these two.

I copied a few old pages into this new template for some navigation tests.

Navigation

Although I'd decided to renew the old "display navigation" by extending it from two to three levels, I had to completely rewrite it. The old script was dirty, it required endless id's and ugly inline event handlers. Besides, my 'You are here' functionality required every page to have a load and unload event handler, which I'd coded directly in the body tag. Remove.

Even worse, every single internal link in my old JavaScript Section had its own mouseover and mouseout event handler, which powered the cross-frame mouseover script. Back in 1998 a cross-frame mouseover script had a high wow-factor, but meanwhile its value has decreased rather drastically. Remove.

High time for some structural thinking. In the navigation frame, I needed associated labels and blocks of content. Clicking on the label opens or closes the content block. In addition I didn't want to see one single event handler in the entire HTML page.

Structurally the navigation page would consists of div's containing the labels or the links and/or other div's. The current fashion of li's for navigations has never appealed to me, and users with older browsers will never see the navigation frame so it doesn't have to be quite that backwardly compatible.

No br's between the links! In the navigation frame the links are block level elements. Whole herds of browsers don't support a {display: block}, but they won't ever see the frame.

The navigation frame needed a second functionality: the link leading to the page the user is currently viewing has to have a special style. "You are here"

I used to use load and unload event handlers which sent an ID of the page to a central script in the frameset. This script searched for an image in the navigation frame with the same ID (well, actually name) and changed its src. Remove.

Did I really need page ID's and stuff? No, I didn't. After all each page has a unique location.href. Search for the link leading to that href and you've found your target.

Safari turned out to have problems with this part of the script. Too Bad, and I notified Apple. Usually they solve such bugs within a few months.

Thus the navigation frame always keeps track of the current content page, even when the user clicks on Back or Forward. I like it that way.

Unfortunately Opera 7 turned out to be very obnoxious. It does not execute an onload or onunload event handler when you use Back or Forward because of an error in the page reload functionality. Impossible to solve, and I notified Opera.

After deciding all this the rest was easy. I explain my solution on the Navigation: display page.

As an afterthought I added the "Clean up navigation" link and script, which closes all navigation blocks and then plugs in to the "You are here" script to open the link to the current page.

Finally I added a "No frames" link that loads the current content page into the top frame, thus destroying my frameset.

As a counterweight I added the reverse functionality to non-framed pages by writing a link back to the frameset into the page header (you see? it's good to define these structures beforehand). See the Customized Framesets page for the technical details.

The top frame

The top frame was easy. It needed my logo and the breadcrumbs. I definitely wanted a breadcrumb trail that shows the actual path the user has taken through my site. It had to be dynamically generated through JavaScript, any other solution would be far too complicated.

For the breadcrumbs I added another bit of code to quirksmode.js. It sends the page location and the page title to a script in the top frame, which builds a new link element from this information and appends it to the breadcrumb div. I added functionality to avoid double links and a 'Clear breadcrumbs' script and it was ready.

When I'd placed my logo I wanted a little sentence below it that deplored the need for browser incompatibility sites. I decided on a fake Descartes quotation, then added William the Silent and Bob Dylan, then acquired a taste for fake quotations and added many more.

I hope you find them funny. They're supposed to be as close to the original quotation as possible, especially in the rhythm of the (English) sentence, and they're supposed to satirically comment on some aspect or another of our little web development world. I like the Sartre quotation best.

When you click on the div a script selects a new not-quite-random quote and writes it into the innerHTML of the div.

CSS

High time for some style. I was adding styles all the time while creating the content template and the navigation, but when the structure and behaviour layers had solidified I could focus my full attention on the presentation layer.

A little quiz before we continue:
Did you notice which selector, used in 99% of the CSS sites, is not used on this page? Don't look at the solution immediately, first find out which common effect you're missing. I didn't miss it until I was deeply involved in moving the content, and then I decided not to bother.

As I said I didn't want to use any CSS hack, except for @import. When I was otherwise ready, I'd look at the site in Netscape 4 and move any style that gives it trouble to the imported style sheet. Simple, efficient, and it retains just the tiniest bit of style for this poor old dinosaur.

There would be plenty of browser incompatibilities. I knew that in advance, but some of them took me completely by surprise nonetheless.

position: fixed

First of all I created a block containing the two special navigation links: "Clean up navigation" and "No frames". I gave it position: fixed and put it at the bottom of the navigation frame. I fully well knew Explorer 6 doesn't support this declaration. Too Bad, I thought, it'll default to position: static and that's OK, too.

I wasn't prepared for its behaviour when I used my display script, though. The block didn't really turn out to be static, but only to appear static. It reacted when I changed of the display of the element just before it (the 'Odds and ends' section), but not when I changed any of the other blocks. Very weird. I decided to leave it that way since initially I didn't see a simple solution without CSS hacks. Besides, the effect is annoying but not disastrous.

I thought of a simple solution much later: place the HTML of the footer at the top of the page. By then, though, I had already decided this behaviour would become a showcase of Explorer 6 bugginess. Besides, placing a footer at the top of a page is not logical.

Form styles

I added styles for form fields, among which the :focus pseudo-class and special styles for all buttons:

input[type=submit], input[type=reset], input[type=button], button {
	background-color: #B2B9C6;
	color: #000000;
}

input:focus, select:focus, textarea:focus {
	background-color: #ffffff;
}

Once again Explorer 6 doesn't support these styles. Too Bad, the forms are perfectly usable without them.

Subtlety

I made the first letter of the intro paragraph float left and double in size.

p.intro:first-letter {
	font-size: 200%;
	float: left;
	margin: 0;
	padding: 0;
	margin-right: 5px;
}

The only disadvantage was that on pages with a very short intro paragraph, the element after the intro paragraph would be influenced by the float, too, and that was ugly. I am rather proud of my subtle solution:

p.intro + * {
	clear: left;
}

Explorer 6 Too Bad etc.

Mozilla and float

A Mozilla 1.4 bug, for a change. Above I said I wanted to float all divs containing browser information right. No problem:

div.floater {
	float: right;
	[yaddah yaddah]
}

Initially this worked fine in Mozilla. When I moved pages that contained more than one floater to the new template, though, I saw that, except for the first floater on the page, Mozilla displays the first line of the paragraph after the floater through the floater. Resizing the window causes the bug to disappear.

Besides, I use Mozilla as my browser when I'm writing content instead of testing code. I often reload the content frame to see my latest changes. From time to time Mozilla crashes. I must have sent a hundred crash reports back to the Project. I suspect a connection to the float bug, but haven't yet investigated it.

Bug ridden crash prone piece of junk

The most serious temptation to use CSS hacks came next. Some content pages have code examples with very long lines, and since the examples are marked up with pre's they generate ugly horizontal page scrollbars.

Suddenly I knew the solution: pre {overflow: auto}! It'll generate horizontal scrollbars only for pre's that needs them.

Simple, workable, to the point. Even Explorer 6 supports it, although it's too fast in showing vertical scrollbars, which I didn't want. I used a Microsoft proprietary declaration without a qualm. This is no CSS hack, any browser could support it.

pre {
	color: #732264;
	[yaddah yaddah]
	width: 90%;
	overflow: auto;
	overflow-y: hidden;
}

Disaster struck. Explorer 5 on Mac hid all content of all pre's! Every single code example on my entire site was illegible for any Explorer Mac user! And no, the overflow-y was not the culprit, it was the normal overflow itself that misfired disastrously.

This was definitely an unpleasant development. Initially I sighed and removed the overflow, true to my "No Hacks!" dictum. Then I looked at the hideous horizontal page scrollbars again, spent an hour in random CSS fiddling and went to bed feeling very unsatisfied. The next day I caved in. Hold nose, insert hack.

pre {
	color: #732264;
	[yaddah yaddah]
	width: 90%;
}

/* IE5 Mac hack \*/

pre {
	overflow: auto;
	overflow-y: hidden;
}

/* End IE5 Mac hack */

I was annoyed at Explorer Mac. Pretty soon I became exasperated, and shortly after that I seriously contemplated browsericide.

I'd noticed before that Explorer 5.2 Mac sometimes crashed when I reloaded my entire site. After the overflow disaster I was in the mood for serious Explorer 5 Mac bashing, so I dived deeply into the crashing problem to get the raw materials for some sarcastic remarks.

Explorer 5.2 Mac didn't crash sometimes when I reloaded my entire site, it crashed every time. Every single time. Always.

The crash seemed to be mostly caused by my generic W3C DOM detection.

var W3CDOM = (document.getElementsByTagName && document.createElement);

What to do? I vaguely tried some lines of code that didn't work, and decided to let it rest for the moment.

Then Explorer Mac crashed again, and not on a reload, either. At first I couldn't remember what I had clicked on, but the horrible truth soon became too clear to bear: it crashed on the "No frames" link in the navigation frame.

What wonders of modern JavaScripting are hidden behind this deceptively simple link?

top.location.href = parent.content.location.href;

Netscape 2 supports this! And Explorer 5.2 Mac crashes on it. The crash has something to do with my JavaScript generated framesets, but that didn't matter. No other browser crashed on it, therefore Explorer 5.2 Mac was a bug ridden crash prone piece of junk.

Solution

A harsh hand was needed. No more silk cross-browser gloves. Create a new variable to denote and demean this pathetic bit of software that forces me to use a browser detect:

var bugRiddenCrashPronePieceOfJunk = (
	navigator.userAgent.indexOf('MSIE 5.2') != -1
	&&
	navigator.userAgent.indexOf('Mac') != -1
);

Change the "No frames" script:

if (top.bugRiddenCrashPronePieceOfJunk)
{
	alert('Sorry, but your buggy, crash-prone\npiece of junk misnamed a browser\ncrashes on this simple script, believe it or not.\nTherefore I disabled it.');
	return;
}
top.location.href = parent.content.location.href;

Place a warning on the homepage:

if (top.bugRiddenCrashPronePieceOfJunk)
{
	document.write('<p class="accent"><b>BEWARE, IE 5.2 Mac user!</b><br>Do <b>not</b> press the <code>Refresh</code> button.');
	document.write('If you do, the bug ridden crash prone piece of junk you\'re using <b>crashes</b>.</p>');
}

I hope an Explorer 5.2 Mac user complains. I'll tell him exactly what I think of his browser.

Content

Then came the time to move almost 200 content pages to their new home. It was the time to revise all markup, go through all content, remove dead links, rewrite vague sentences, mark pages in need of an update, and generally clean up. It took me close to three months.

The compatibility tables, especially, were in need of standardization. Back in 2000 I started out with a few simple tables, then added the W3C DOM ones, then added many more. There were all subtly different in markup and presentation.

First I created a key to the Tables, to force myself to use standard categories of browser bugginess. Then I updated every single compatibility table on my site. That was quite a lot of work, especially because some of them had to be significantly revised to incorporate new browser versions (of which there are far too many nowadays, incidentally).

Of course, two weeks after I'd finished the tables, but before the site went live, Mozilla, Opera and Safari released new versions. I decided I'd put enough effort into this site for the moment, and I didn't update the tables.

Language

Then came the language problem. On my previous sites I'd been very strict in writing English only, with the result that I sometimes got English mails from Dutch speakers. My first step was to add a Dutch text to the Contact page, stating clearly that people can mail me in Dutch, too.

I wondered if I should allow French and German, which I can read and somewhat speak but not easily write. In the end decided against them, partly because I'd have to learn the French and German words for 'browser incompatibility', 'preload script', 'empty text node', 'usability disaster' and 'page reflow', which aren't in any dictionary, and I'd have to remember their genders in both languages, too.

Conversely, my Freelance site was available only in Dutch (in case you're wondering, Dutch has borrowed the word 'freelancer' from English). I liked the texts I wrote for it and my Dutch clients deserve a Dutch site. Besides, I hate translating texts, and especially my own. Somehow the translation turns out OK but significantly differs from the original text.

Publications was the only mixed language page, since it contained links to Dutch and English articles, and I'd written short comments on each in the same language as the article.

Maybe I'd get some foreign clients if I'd advertise myself in English. Besides, if I'd retain Dutch on the Freelance pages, should the link texts in the navigation frame be in Dutch, too? That'd be odd, with all other link texts being English.

A client came to the rescue. He needed a Dutch/English site, and we quickly agreed to get rid of the stupid flags generally used for language switching (English being symbolized by the Union Jack, not by the Stars and Stripes. We are Europeans, after all). But if we wouldn't use the flags, what would we use?

I devised the following solution: On the homepage the Dutch and English welcome texts would be shown side by side. Each text had a "Lees meer"/"Read more" link. Naturally the user would click the link in the language of his choice. I would capture this click (and in fact any click on one of the languages), and enlarge the chosen language while making the other one smaller. Thus I wrote my Bilingual Pages script.

Soon I implemented it on my own site, taking my Publications page as an example. It worked fine, and I hurriedly converted all Dutch pages to bilingual ones.

One problem remained: the Dutch/English links in the navigation frame. I added a bit to the Bilingual Pages script that goes through all links in the frame and searches for the custom nl or en attributes. It sets the text of the link to the correct language.

<a href="about/publications.html"
	nl="Mijn publicaties"
	>My publications</a>

Finally I added the lang attribute to the HTML tags of all pages

<html lang="en">

and lang="nl" to any container of Dutch text.

Odds and ends

Belatedly I discovered <link> tags. While playing with Mozilla's preferences I found out that it can display an extra toolbar that allows you to follow <link> tags to their destination.

In case you're wondering, it's under View => Show/Hide => Site Navigation Bar

My Introduction to Events consists of 10 pages that I originally wrote as one long article. These pages are almost the only ones on this site that have a clear relation to a Previous or Next page. Therefore I experimented a bit:

<link rel="prev" href="introevents.html">
<link rel="next" href="events_early.html">

And it worked: Mozilla showed these links in its special toolbar. Opera did, too, by the way. Unfortunately this functionality turned out not to work in my frameset. Remove it? It's structural information, and users outside my frameset would profit from it. So I left them in, I even added Up and Intro links to nearly all pages on my site.

Nonetheless I was disappointed that browsers didn't show the nice new functionality in my frames. Then I kicked myself for not getting it sooner and wrote a simple script that reads out all <link> tags except for the stylesheet ones, converts their content to <a> elements and writes them into the footer of my pages. I'd been right all along: I needed a footer.

I was in the mood for even more navigation so I added the Table of Contents script that generates a linked table of contents based on the h3 and h4 page headers. It had been on my wish list for years.

I devised a new popup script that, as I call it, 'adds popup behaviour' to a link. I immediately thought of a second application. For years I'd wanted a way to say "every link with a class="external" should have a target="ppk". Since I went through all links on a page anyway, what would be simpler than

var x = document.getElementsByTagName('a');
for (var i=0;i<x.length;i++)
{
	if (x[i].className == 'external')
		x[i].target = 'ppk';
}

Snags

At the last moments I encountered some snags. I suddenly had good ideas for viewport test scripts. I'd wanted to research this obscure area of web development for years, so I spent about a week on these tests, time I couldn't spend on any other part of my site.

Then a good friend of mine broke his collarbone and I had to help him getting around. No problem, but it once again cut into my development time.

In August I'd promised to get the new site online in "September, maybe October". October was running out fast, I was getting tired of obscure CSS and JavaScript problems and rigid cross browser testing.

I'd wanted to rewrite the modern browsers pages and a few test pages, most importantly the W3C DOM vs. innerHTML benchmark tests. I also wanted to go through all 200 content pages again and give them a last good check.

I decided to postpone these last updates. The site had better be ready, because I was going to put it online and spread the news.

So at the tail end of October 2003, nearly six months after starting the redesign process, QuirksMode.org went online. I hope you like it.