Re: why TITLE, not TITLE?

Stephanos Piperoglou wrote:
> Again, the problem lies with educating document authors. The argument is
> simple: a very, very, VERY small percentage of people use the same browser,
> browser version, OS, screen resolution, window size, image loading settings,
> font settings, appearance settings, and language settings as the author
> does, so there's no point in "validating" against your browser. 

That isn't true. Validating against your browser is better than not
validating at all which is the alternative for most people. Thus,
browsers should be able to validate. It is a crucial part of their role
in the web infosystem.

> - What is NOT required is that authors learn SGML. I haven't, for that
> matter. I have no interest in SGML other than HTML authoring, BUT a lot of
> my documents don't conform to an active DTD for various reasons. I generally
> use the 3.2 tagset, but I also use CLASS because I think CSS1 is pointless
> without it, and often I use ISO-8859-7 (Greek) characters, which will not
> validate with the 3.2 DTD. I don't know how to make my own DTD, and can't
> afford the rather incredible effort it will take to learn how to, since I
> don't require knowledge of any other SGML application. My documents are
> still useable with the vast majority of user agents, so how can I validate
> them?

You can use HTML Pro or "Cougar".
 
> b) A wide variety of DTDs or a DTD that is adaptable enough (HTML Pro, for
> instance, though a good idea, is comprised mainly of things that I don't
> want and don't want to consider valid)

So don't use them! How are you "accidently" going to insert a <FRAME >??
You know the tagset you intend to support and HTML Pro checks the
structure.
 
> c) Authoring tools that validate, and browsers that validate NOT as a
> process of parsing the document, but merely as an informative function so
> the viewer (potentially the author) can view his document but can also be
> aware that not everyone can.

Browsers should validate BOTH as a process of parsing the document AND
as an informative function. If the HTML is incorrect then the browser is
just guessing at the author's intent. If it is guessing at something the
user should know. Thus it should warn the user (through an icon, most
likely) that it doesn't really know for sure what was intended but is
guessing.
 
BTW, there is no "incredible effort" involved in learning to read and
modify DTD. I don't think that everyone should learn but anyone who
considers themselves an HTML professional could learn how to do it in a
(small) fraction of the time that it takes to learn HTML itself.
Tutorials are available on the Web and examples abound. I teach a course
on it to average folks and it takes about an hour and a half. Obviously
a motivated reader can learn much more quickly.

 Paul Prescod

Received on Monday, 12 May 1997 14:36:26 UTC