additions…
…web design…
Internet Explorer 6 works best in Quirks mode…
Ok, I wrote that headline, and I stand by it. Now it's time to “swim”, or rather explain why. Of course, there's no way to avoid those personal preferences.
I am not saying that “you can make IE6 work best in Quirks mode”. I have no idea what kind of web designer or coder you are – if at all, and how much in-depth knowledge and experience you have. I'm making a statement that is correct from where I stand, and I'll list up some of the conditions.
- we have to style our layouts in such a way as to avoid all major box-model problems, and the need for hacks to fix them.
- we have to combine Quirks mode in IE6, with Standard compliant, or Strict, mode in more capable browsers.
The above is pretty simple to achieve, so I'll say my “conditional statement” is sound and will therefore carry on with the basics needed to make it work and expand on why I want it to work.
box-model differences…
I never bother about minor deviations caused by browsers/versions and modes for any single element. There will be some deviations anyway, regardless of what degree of “pixel-perfection” one aims for. Instead, I make sure all elements “look right” – together, in each supported browser/version/mode all by itself.
Make note: this is all about web design, where most factors are under the influence of User-options anyway. “Pixel-perfect” designs tend to lose some under that influence, and the more “pixel-perfect” they are, the more they tend to lose.
There's a slight difference between this page in Quirks mode and Strict mode in IE6. A couple of pixels in width/height on the “box”, equivalent to border-width to be precise. I never design in such a way that that becomes a problem, and I always test in IE6 in both modes.
I don't declare side-paddings on elements – boxes – that have declared width. Instead, I declare side-margins on non-sized elements inside those sized boxes – like paragraphs, lists and so on.
I make the most out of fluid and/or elastic designs, by declaring some side-margins on non-sized elements in percentages, so they'll adjust to available space on narrow windows. Combining such a side-margin on one side – usually the left side, with a percentage-width for the element, is one variation that works well in most cases.
mode switching…
Keeping IE6 in Quirks mode while all the good browsers are in Standard compliant mode is no problem. IE6' own built-in bugs and my preferred choice of DocType, make that happen “automatically”.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
The xml declaration above the XHTML DocType Declaration, will throw IE6 back into Quirks mode, in line with its predecessors – IE5.0 and 5.5 – where it belongs with all its bugs.
See Serving XHTML 1.0 and The XML declaration for more on the subject.
All Standard compliant browsers – including IE7 – will read the DocType Declaration and interpret our markup and CSS accordingly. That's the whole idea, as it is only IE6 that is too weak with regards to W3C standards.
Don't bother to tell me that IE6 has a Strict mode. IE6 has a Quirks mode that is not following any standard but Microsoft's own. IE6 also has a “not very standard compliant mode” that isn't up to much, and which has more bugs than the most flee ridden stray dog.
For those designers/coders who prefer to write their markup in accordance with an HTML Doctype, the following will achieve the same “throw back into Quirks mode” in IE6.
<!-- --> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict //EN" "http://www.w3.org/TR/html4/strict.dtd">
However, the comment above the DocType declaration may create a problem, in that IE7, IE8, and who knows how many future IE versions, will now also be thrown back into Quirks mode. Maybe some designers/coders want that to happen, but I most certainly do not.
Thus, I stick to the XHTML DocType Declaration with the xml declaration on top, so IE7 can at least try to line up with the Standard compliant browsers – in Strict mode. IE7 may have limited success when fed standard-compliant stuff, but it's sure better than IE6.
The next version: IE8 works reasonably well in “standards compliant” mode, actually. We just have to make sure IE8 stays in that mode..
why throw IE6 into Quirks mode..?
I have a mixed set of reasons, and it's all based on extensive testing. Mostly it is caused by a wish for less, and less complicated, hacking in order to make my designs work reasonably well in all IE5+versions.
pros:
- IE6 handles most markup and CSS identical in both modes.
- the “box model” problem is not a real problem.
- IE6 needs quite a few hacks, workarounds and/or avoidances in both modes, but most often a few less when in Quirks mode.
- little need to correct IE6 separate from IE5.0 and 5.5, as they have mostly the same bugs when they are running in the same mode.
- no need for 'conditional comments' in order to serve separate stylesheets to each IE5+version. I dislike 'conditional comments', although I may still use them (or something similar) at times.
I could write a much longer and more detailed list – with plenty of examples, but the above is the essense of a few years testing and comparison between IE6 and other IEversions on one side, and most other browsers available to me on the other.
There are also a few reasons related to the way I prefer to write my markup. The XHTML DocType on top of this, and other pages, didn't get there by accident. It's my preference, and I know the meaning of true XHTML.
more pros:
- I like the extra demands for flawless and well-formed markup, where there are no such thing as optional tags. Thus, XHTML is what I write in accordance with, even though I have to serve it as text/html so IE can render it.
- I will not create “tailor-made” markup/solutions for old IE versions – if it can be avoided. IE should have to do with some “fixes” to cure its worst bugs and weaknesses.
- I don't discuss “the semantics” of different W3C standards for different use. I use the parts that makes most sense – to me. That means enforced well-formedness, as in XHTML, amongst other things. The xml declaration follows naturally.
Anything wrong with my reasons for doing what I do? Of course: IE6 still doesn't act like a good browser should – regardless of what I do, so maybe my solution isn't perfect. Let's see now...
possible cons, maybe:
- some workarounds, like javascript and IE-expressions, are mode-dependent. One has to choose the right workaround depending on mode, or use mode-independent workarounds.
- some playroom for minor box-model differences must often be calculated in. A couple of pixels difference here and there may ruin the day for a “print-on-web” designer.
- some designers may feel so sorry for IE6 and its “not very standard compliant mode” that they may flame those who prefer its more reliable Quirks mode.
I think that last point on the cons list weigh a lot for many. Who wants to get flamed for wanting to make things work? Oh, well... I'm quite insensitive to anything but ice-cold logic, so I'll just carry on – regardless of the heat.
conclusion…
After adding all pros and subtracting all cons, the result I'm getting does point in favor of keeping IE6 in Quirks mode – for ever. IE7 is doing fine in Standard mode, and later IE-versions are yet to be tested.
That “thing” (IE6) is pretty stable now anyway – and is slowly disappearing, so I can play around with it until it's time to delete it from the list of supported browsers.
Update [08.mar.2008]: My mostly mode-independent and progressive design methods with
IE6 in Quirks mode, seems to hit right with future development of IE/win.
IE/win will handle my creations more or less identical in all modes anyway.
I can keep on designing this way well into the future, and be able to take advantage of whatever standard-support
improvement they manage to get into those future IE-versions.
sincerely 
Hageland 17.jun.2006
last rev: 18.feb.2009
additions…
