Why QuirksMode?

I have selected the name of this site with particular care. To me 'Quirksmode' has two meanings. First of all it refers to the well known quirkiness of all browsers, even the most modern ones. Secondly it refers to 'Quirks Mode' vs. 'Strict Mode', and hence the entire standardization effort.

Browser quirks need documentation, which is why I started this site, and why you read it. I don't have to explain how annoying they can be. Defeating, or at least understanding, browser quirks is the most important purpose of this site.

Quirks mode

The second meaning of 'QuirksMode' is more subtle. As you may have noticed, I do not display the (often surprisingly ugly) icons that proudly proclaim use of valid XHTML and CSS. That's because my pages don't use valid XHTML and CSS (not that I'm aware of, at least).

Ignoring the validation circus is a deliberate decision. I feel it needs some clarification.

If I'd use, for instance, the XHTML 1.0 Strict doctype on my site I'd do two things:

  1. I'd claim to have written valid XHTML 1.0 Strict
  2. I'd switch most modern browsers to their 'Strict Mode' interpretation of CSS.

I wish to do neither, for three reasons.

Reason 1: Restrictive format

I don't write valid XHTML, not because I want to continue old-style tag soup coding but because I find the available formats too restrictive.

For instance, all (X)HTML flavours omit the <wbr> tag. Why? It's extremely useful in large and tight compatibility tables. I see no reason to stop using it.

More important to me is the fact that no (X)HTML flavour allows the use of custom attributes. Using custom attributes is an excellent way to start separating behaviour from content. We've succesfully separated presentation and content by the use of CSS. Now it's time to take the next logical step.

I want a simple, clean method of adding behaviour to HTML elements. Custom attributes are excellently suited for this purpose. I can easily add them to any HTML element. A script using the getAttribute() method finds the relevant elements for me and adds a little behaviour.

For instance, to add popup behaviour to a link I do:

<p>See also the <a href="../key.html" type="popup"
	>key</a> to my compatibility tables.</p>

Note the type="popup" attribute. One of my scripts automatically searches for all links with this attribute and adds the popup script to them. (See the popup page for a more complete explanation)

This solution keeps my code squeakily clean because I don't have to write the clumsy event handling code old fashioned popups require. In addition, it makes for perfect accessibility. If the script doesn't work for whatever reason, a click on the link opens the page in the existing window instead of in a new one.

Oh yes, and it works in all modern browsers.

This technique does not conform to the standards because no (X)HTML flavour allows me to use custom attributes. Therefore I find myself unable to use standards compatible (X)HTML, or to claim I do. Therefore I don't use any doctype.

Reason 2: Doctype switching

Unfortunately I cannot yet give a full account of my reasons to abhor and avoid doctype switching. Below I give some of my thoughts on this subject, but these notes are neither complete nor convincing.

When I first heard of doctype switching I was shocked, and when browser after browser added support for this dubious undertaking I was appalled. In a rare moment of misguided unity the combined browser vendors solemnly doubled the number of browsers I should run my tests in.

A browser in Strict Mode is not quite the same as in Quirks mode. So I'd have to test every single script and every single CSS test against two modes per browser, which required me to double the amount of test pages (which wasn't small to begin with). I refused. Therefore this site uses only Quirks Mode.

It doesn't impact JavaScript. I absolutely refuse to consider even the possibility of a doctype (which gives information about the XHTML, and nothing else) having any influence whatsoever on JavaScript. Explorer 6 Windows stolidly ignores me, but fortunately the other browsers seem to shy away from committing similar atrocities.

For CSS the case is less clear. Doctype switching was invented to facilitate stricter CSS interpretation, so testing all CSS in both modes in all browser makes some sense. Although at present this site uses only Quirks Mode tests, I have reluctantly come to the conclusion that I'll have to double the amount of test pages. It hasn't happened yet, but I concede the need to do it.

I started doing it in the Viewport experiments. They use Strict Mode throughout to make sure Explorer 6 behaves like the other browsers (or rather, honestly tries to behave like the other browsers). But this is the sole area of web development where Strict and Quirks mode differ significantly, and only in one browser.

I have other reasons to dislike the whole idea behind and concept of doctype switching, but I haven't yet found the time to write a coherent article on this complicated matter. For the moment my argument is incomplete. I'll write the piece one day, though, and then you can judge for yourself.

Reaction

A reader sent this reaction:

Stick with one mode (doctype or not), and you don't need to worry about the other. Mode selection is predictable and chosen completely by the page author.

This is undeniably true. Any website will use either Quirks or Strict Mode, not both. Nonetheless, you first have to select a mode. To make a responsible choice, ideally you'd have to know all the differences between the two modes in all browsers. That makes a comparision mandatory.

In addition, this site is supposed to help web developers with making such choices. Therefore, all experiments and code examples on this site should be in both modes, so that anyone can test any example in both modes and ponder the differences. This means a lot of extra work for me, and that's my practical objection.

As I said, I'm going to add Strict mode CSS examples, in a while, when I have the time.

Reason 3: Standards orthodoxy

My third reason to refuse the validation circus is the most personal and least technical one. It's an emotional matter. My rationality has taken a holiday.

To me, the standards and (especially) the way we should implement them have taken on the insufferable air of a dogmatic, uncreative religion that only exists to enforce its arbitrary rules about what to do and how to think, ministered by a self-proclaimed caste of bigot priests.

That's unfair.

I know. It is appallingly unfair to the serious workers in the field. It only applies to standards zealots. Nonetheless this image of a moloch that destroys creativity is the first thing that comes to my mind when I hear 'web standards'. I suspect other web developers occasionally have similar emotions.

Standards compatibility does not preclude creativity.

I know. CSS has great creative potential, and I absolutely love it. Eric Meyer's fascinating css/edge experiments, Literary Moose's thought-provoking CSS Destroy oddities and Dave Shea's beautiful CSS Zen Garden show that we stand on the brink of amazing progress. When the JavaScript W3C DOM adds its full potential to this already powerful mix, the Web will be renewed many times over.

CSS and the DOM are W3C standards. In fact, W3C has invented both.

I know. But as yet nobody, not even W3C, knows how to use these technologies to their maximum potential. We stand at the beginning of a fascinating quest. Like many other web developers, I want to extend the new technologies beyond their current capabilities. I want to invent new ways of creating web sites while striving for simplicity of coding and maximum browser compatibility.

And then, when I've got a great new CSS or DOM idea that may change the way we look at websites, and that actually works in most browsers, a stupid self-righteous priest who'll never have an original idea even if he lives to be a hundred years comes along and exclaims "It's not in the standards! Naughty boy!".

That's my nightmare. Standards to constrain me, beyond criticism, orthodox, eternally boring.

The custom attributes technique is a good example. It's powerful, it's cross browser, it's simple, and it does not comply with the XHTML standard. Therefore I cannot follow the XHTML standard.

I demand the right to judge the web standards, to praise but also to criticize, to ignore silly stuff when possible, to cross arbitrarily defined borders, because I'm better at making web sites than the standards' creators.

I demand the right to think for myself.