Re: why TITLE, not TITLE?

John Udall (
Fri, 09 May 1997 09:26:08 -0400

Message-Id: <>
Date: Fri, 09 May 1997 09:26:08 -0400
To: Chad Owen Yoshikawa <chad@CS.Berkeley.EDU>
From: John Udall <>
Subject: Re: why TITLE, not TITLE?
In-Reply-To: <199705090328.UAA10106@whenever.CS.Berkeley.EDU>

At 08:28 PM 5/8/97 -0700, you wrote:
>> Chad Owen Yoshikawa wrote:
>> > 'Why is it that TITLE is a required member of the HEAD element?'
>still exists without a title.  If the DTD evolves based on its use, it seems 
>that the TITLE element is certainly optional in practice.  Essentially,
>the point is that a document should still be rendered if the TITLE
>element is missing.  Given a web browser, there are two choices: break the
>parser so that it accepts invalid HTML with no TITLE element, or IMHO make
>the cleaner choice which is to make the DTD have the TITLE element be

	It is my understanding that the TITLE element has been required from the
very begining with HTML 0.x, as well as the standard HTML 2.0 and more
recent DTDs. Although I haven't been able to lay my hands on a copy of any
of the early HTML DTDs, like HTML 1.0. Having the TITLE element be required
provides a minimum amount of meta-information about the document's content. 
	They had to start with some basic requirements for what defined a minimal
HTML document, and this was what they came up with.  Every document should
have a title, just like every file should have a name.  Of course, file
naming requirements are enforced by the applications and the OS. Whereas we
have not been seeing the HTML authoring, browser or server applications
enforcing the DTD rules in the vast majority of cases.  As a result, you
get a lot of documents on the web which don't conform to any of the
standard HTML DTDs.

>(Yes, there are a lot of broken pages, and no, the DTD shouldn't adapt
>to all of these broken pages.  I'm just focusing on TITLE.)
>In the browser I'm writing, I had to make this choice, and I chose to 
>modify the DTD.  The browser's parser now accepts a superset of HTML3.2,
>The other option being to modify the parser, which would have definitely 
>involved more code :)  (and functionally, doesn't have made a difference 
>besides the fact that the browser cannot produce an error message for docs 
>with not TITLE element.)
	IMHO, this is a very poor design decision.  Authoring tools should be
strict about their conformance to DTD specs, in order to assure that the
documents created are viewable on as wide a variety of browsers as possible
(assuming that the browsers were written to conform to the available
standards), and the documents created are as enduring as possible (assuming
that the browsers are written to be backwards compatable with earlier
available standards).  At the very least, authoring tools should make it
easy for people to write documents which conform to the standards, while
making it more difficult for them to create documents which are
non-conforming. They should provide explicit warnings, if the documents are

	Browsers, on the other hand, should be as forgiving as possible of
non-standard HTML. (within reason :-)  A smart browser can deal with
non-standard HTML and display it in, what is hopefully, a reasonable
manner.  If a browser is too strict, then it runs the risk of not
displaying information content. That would be bad for both the authors and
the readers.  The authors just want to create the information and publish
it.  Readers just want to access that information, view it, and make use of
it. HTML just provides a framework to make this possible.

	Part of the problem is that web page authors have been using browsers as
validators.  They aren't meant to be used for that purpose.  This doesn't
mean that you shouldn't check your work against a variety of different
browsers. It's just that it doesn't provide validation that your document
conforms to the available standards.  This is especially true for the crowd
who say, "Well, my document looks fine in Netscape. ..."  The people at
Netscape put a lot of effort into making Navigator as tollerant as possible
of non-standard HTML. (Some might say they are too tollerant.)  The result
is a that there are a whole bunch of pages out there that look fine in a
particular version of Netscape, but look like hell on other brosers, or
even in other versions of Netscape.   People just don't seem to understand
the role or importance of standards in web page authoring (or tool
authoring for that matter).  In many cases, they just don't know that the
validation tools are out there, or the tools are just too difficult to use. 

	If you modify the DTD for your browser, you are potentially creating more
work for yourself, because everytime the DTD changes, you have to modify
the new one to conform to your modifications, instead of just being able to
drop in the new one.  Of course, somewhere in your code you will have to
take into account all of the non-conforming web-pages out there.  You have
made a decision about where to do that.  If writing a web browser were
easy, we'd all be doing it.  (Hey, now there's an idea. :-)  

	Obviously, you are making an effort to conform to the available standards
with your browser. That is very laudable. Your question appears to be more
directed at finding out why the standard is the way it is, rather than
suggesting that one should not follow the standards. I wish you the best of
luck with your project.  More power to you for making the effort to write a

BTW- Have you looked at the HTML-pro DTD?  I can't lay my hands on a URL
right now, but maybe someone else on the list could provide it.

Just my 2 cents worth,


>Finger me for my pgp public key
>Today's random buzzword: plug-and-play dilbert

John Udall,
      Programmer/Sys. Admin.
Extension Electronic Technologies Group (EETG),
Cornell Cooperative Extension,
40 Warren Hall
Cornell University,
Ithaca, New York 14853
(607) 255-8127