[thelist] Always use a DOCTYPE

[MRC]

Mark,

> I think we're getting away from the point that a DOCTYPE of some
> description is required, and it's omission prompts a browser to handle
> the page in the best way it can using a built-in set of rules. I'd be

    I don't think that we've gotten away from that point. In fact, that has
been implicit in my argument that for an HTML document, a doctype need not
include a system identifier to be considered valid.

> very surprised it NN6 and IE6 render a page identically if there's no
> DOCTYPE included, just because this sends the relevant browser into
> "quirks mode". Can the internal handling of pages with no DOCTYPE be
> identical in Netscape, IE, Mozilla and Opera? Sounds unlikely to me.

    Absolutely no. But my point is that even in "standards-compliant" mode,
these same browsers will render a page differently -- sometimes quite
differently.
    An additional point: there is nothing particularly magical about a
browser's "standards-compliant" mode if one's concern is avoiding
browser-rendering differences. And that the importance of writing
spec-compliant code should not be confused with -- or married to -- some
need to engage a browser's "standards-compliant" rendering mode. If you can
do both, that is fantastic. But it may not always be ideal, and the two
should not be inextricably linked.

>
> >     It is almost inconceivable that any major web browser -- or any
> > minor
> > one, for that reason -- will cease to render html pages altogether
> > because
> > they fail to include a doctype declaration (which is, of course, invalid
> > html).
>
> I can easily see this being the case when browsers get to the stage of
> rendering XML, as the rules of XML are totally strict and (as far as I'm
> aware) can't be hacked by omitting a preliminary XML declaration. XHTML
> is simply the first major step on the road to XML, which is what many
> developers are overlooking.

    I agree. But XML is not HTML. And clearly XHTML places additional
restrictions on coding practices that are not present in HTML. If one
chooses to code in XHTML, it is important to be aware of this, and to
understand that you may not have the same latitude to write spec-compliant
code that will also render as desired across different makes and models of
browsers.

> > Also keep in mind that the "quirks" mode can be triggered in most
> > browsers _without_ writing non-compliant html.
>
> If you're writing compliant HTML and presenting it with compliant CSS,
> why is there a need to use a "quirks mode" to display the page? The only
> reason that I can see is to attempt an identical cross-browser layout,
> which can't be achieved anyway due to the fact that user preferences
> involving Javascript, user style sheets and image settings often kill a
> layout anyway.

    Obviously, identical layouts are rarely possible in a cross-browser
environment. But one very sensible reason to write compliant code while
triggering the browser's "quirks" mode may be to avoid the sometimes
more-exasperating quirks of the various browsers' "standards-compliant"
modes.
    IMO, switching off a browser's "standards-compliant" mode is a
workaround, not an ideal solution. There are definite drawbacks to doing it
(e.g., you lose the standards-based CSS box model in IE 6), but there can
also be benefits, depending on the hurdle one faces.

James Aylard