additions...

…web design…

only IE needs DOCTYPE…

Choosing the right DOCTYPE and marking up web documents in accordance with it, is an important matter. To most browsers it is only the markup quality that matters though, as only IE/win is lost if the DOCTYPE is missing on top of a document and this has little to do with the markup – it is CSS support that intentionally gets lost in IE.

IE is the only browser I'm avare of that makes a clear distinction between what it supports in which mode. This mode-gap seems to be widen with each new IE version release, rather than being closed as it does in “good browsers”.

I use the term “good browsers” about browsers that are upgraded often and given improved markup and CSS support. Clearly, IE/win has not been amongst the “good browsers” for a long time – the last 10 years or so, and there are no real signs that this will change any time soon – rather the opposite.

DOCTYPE controls degree of CSS support in IE…

All major browsers switch to standards mode if they find a proper DOCTYPE to switch on. Nothing new here, but if that crucial DOCTYPE is wrong or missing, good browsers and IE take different routes.

Since the DOCTYPE was never meant to act as a mode-switch trigger, the branching between IE and the good browsers shouldn't come as a surprise. The good browsers never really needed a mode-switch, they only need markup and styling in accordance with W3C standards. Only IE creates problems if the DOCTYPE is missing.

New versions of the good browsers provide the same CSS support whether they find a DOCTYPE to switch on or not, as it is only their sets of CSS defaults and a few handling-rules that get switched. So mode-switching takes effect, but we can use the entire CSS arsenal to style elements as we see fit, regardless of which modes these browsers are in.

It doesn't matter in this context that the new, short, HTML 5 DOCTYPE is introduced because they needed a compact mode-switch – and for no other reason. Good browsers still don't need it, but IE sure does.

of course there are mode differences…

If the web developer/designer/front-end coder doesn't take steps to avoid or level out mode differences, then of course these differences will show up when comparing a document, a web page, that is triggering standard mode vs. the same page in quirks mode. The fact that the page featured in those two links appears pretty identical in both modes proves the point I'm making; that DOCTYPE switching doesn't matter much in itself if the designer/front-end coder knows what he is doing.

To make sure you get the point: I haven't done anything special to the pages linked in as demos. They are two identical copies of the English-language homepage on this site, and that page, and the copies, is styled the way it has been since it was created. All I have done is to change the DOCTYPE or remove it in the demos, and add some suitable text to the headlines.

mode-independent styling:

I have always found it most efficient and time-saving to style as close to mode-independent as CSS standards allow for, and then build up and enhance the appearance as far as the latest CSS standards and browser-support can take me. Box-model differences and most else is thereby pretty much leveled out to begin with, and what's left of mode-differences is barely noticeable unless I want them to be.

In quirks mode IE7 and later versions are picking up IE6 styles, and since IE6 is intentionally kept in quirks mode anyway the result is quite predictable in both modes in later IE versions. Consequently: no extra fixing or version-hacking necessary for IE.

The result of this appearant “mode madness” is that when a web document is styled in a mode-independent way, most, if not all, will appear the same in the good browsers, regardless of which mode they're switched to.

Of course; in-depth knowledge about standards and browsers is the key here, but professional or semi-professional web developers/designers shouldn't have problems with that. The “occasional homepage designer” may get a bit lost between standards and modes thought, so she, or he, better stick a proper DOCTYPE on top and try to follow standards.

to recapitulate:

What comes up on screens in the good browsers is almost entirely up to the standards-aware designer, and the DOCTYPE makes no real difference. IE on the other hand switces back to a reduced CSS support pretty equivalent to that of old IE5.5 if the DOCTYPE is missing, and most of what has been added to CSS specs since the year 1999 will be lost on it. In good old Microsoft tradition nearly all other improvements made to later versions will be lost too, so standards don't mean much to IE in quirks mode.

Although it is possible to make our creations look quite acceptable in IE6, 7, 8 etc. when these versions are thrown back into quirks mode, our designs probably won't look as they do in the good browsers unless we aim quite a few workarounds at IE. No wonder so many designers say standards don't work, since IE ignores same standards.

draw the line after IE6…

IE6 is so weak on standards that we may as well leave IE6 in quirks mode for ever and work around its weaknesses in that mode. The internal mode-gap is relativly small in IE6 anyway, and the added bonus is that our creations will probably work reasonably well in even older IE versions in case one comes around.

IE7 is almost as weak as IE6, but it is generally easier to fix IE7 with its slightly improved CSS support in standards mode, than to force it into something that looks right in quirks mode. Thus, we should give IE7 a chance and let it switch to standard mode on a proper DOCTYPE, if at all possible.

IE8 is a “mixed beast”, with a really wide mode-gap between what appears as two separate engines. IE8 beta2 seems to have an acceptable CSS2.1 support when in standards mode, but its CSS support is several years behind the good browsers even in that mode and it is almost impossible to work around its many weaknesses and shortcomings without adding something extra.

For the average web page it doesn't really matter which mode IE8 switches to since we have to support the older IE versions for years to come anyway. However, for somewhat improved control over design one should let IE8 switch to full “super-standard mode” on a proper DOCTYPE. IE8 may actually do reasonably well in standards mode, if we don't challenge it with anything advanced from the latest CSS specs or get lost in Microsoft CSS Vendor Extensions.

conclusion: add quality-control…

We should of course keep the DOCTYPE on top of our documents once we have gone to all the trouble of putting it there and marked up our creations in accordance with it, styled to perfection and checked that all is well across browser-land. Taking the DOCTYPE out at this stage would be foolish, despite the fact that only IE needs it. After all: some out here actually use IE, for whatever reason.

However, it is the quality of our work that really matters, not the presence of a DOCTYPE. We can get around all rendering problems in the good browsers without having a DOCTYPE, but once our work fails the addition of a DOCTYPE is unlikely to do much good – although it may certainly make a difference.

If web designs fail in good browsers, it is time to add proper quality-control to the design-work chain. Designs fail because they're not created for the right media using the right tools and methods, so going through every inch of ones creation from code-level and up is a good starting-point.

improving basic understanding / quality-control:
  • Learning to build a better web the right way through web standards will make life and work easier for designers/developers/front-end coders on all levels.
  • Knowing what each browser supports and how it supports it, is basic knowledge that must be upgraded as new browser versions arrive. Catching up on older Web browser standards support overviews to begin with, certainly won't hurt.
  • Having a somewhat correct and easy to understand CSS reference within “one-click reach”, is always useful.

Of course, proper quality-control should have been implemented from the start, but that means we have to introduce more logic and basic understanding into the minds of those involved at a much earlier stage. However, getting something useful into the human mind before there's an urgent need for it, is most often much harder than introducing or improving procedures when problems pile up. Of course, introducing something that works is most often futile at such a late stage too, but let's not go into that…

The human mind is a confusing matter … better avoided.
— Molly 'the cat'

Personally I prefer to have quality-control procedures in place at all stages, and to check resulting rendering and behavior both with and without a DOCTYPE – in addition to general stress-testing. This means there's not all that much that can go wrong when it's time to launch – at least not much I do not already know about, which usually means saved time and less frustration.

Since I normally use an XHTML 1.0 doctype I also check that it will actually work as intended when I'm serving my creations as application/xhtml+xml, as otherwise the DOCTYPE would be wrong and all quality control have failed. Can't have such failures even if most documents are served as text/html to cater for IE.

Proper quality control does pay off in the long run – even when dealing with IE.

sincerely  georg; sign

Hageland 21.sep.2008
last rev: 02.oct.2008

additions...

Once you've checked the quality of your work, you can ditch the doctype declaration.
Good browsers got no real need for it.
— Georg

internal demos:

Of course, if you want Internet Explorer to behave itself, you're gonna need that doctype.
IE7, and later versions, can't do much without it.
— Georg

Get IE7 – and get lost.
external info:

No, I don't use “CSS reset” in any form.
I declare what I need when and where I need it, and not before or anywhere else.
— Georg

Apart from the odd single-pixel differences across browser-land, there aren't any really problematic differences that warrant browser-hacking – except in Internet Explorer of course.
— Georg

I don't think visitors compare or care about rendering-differences between browsers.
Therefore I don't care much about differences either, as long as it looks and behaves alright in all browsers on my support-list.
— Georg

addition to:

about…
…2008