Re: RE dtd2.html
Bill Janssen <janssen@parc.xerox.com>
Message-id: <Qg1DpX0B0KGW0vnLYy@holmes.parc.xerox.com>
Date: Thu, 27 May 1993 10:41:55 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: terry@ora.com, Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: RE dtd2.html
Cc: www-talk@nxoc01.cern.ch
In-reply-to: <9305270930.AA15764@manuel.hpl.hp.com>
References: <9305270930.AA15764@manuel.hpl.hp.com>
Excerpts from ext.WorldWideWeb: 27-May-93 Re: RE dtd2.html
Dave_Raggett@hplb.hpl.hp (3410)
> > + I am not sure that STRONG, B, I, and U are desirable as
> > elements. These formatting characteristics ought to
> > get applied to elements on the basis of their meaning.
> > But that's a rather SGML point of view; you may wish
> > to allow this slop room for WWW.
> I don't like them either. They are present in HTML to support
> importing (scanned) documents for which a filter has no way of deciding
> the original meaning.
This justification doesn't sound terribly good. If we can't infer the
meaning of the font changes, perhaps translating the scanned document to
HTML is inappropriate; perhaps the scanned document should be stored in
TeX or Postscript or GIF, depending on what other image characteristics
of the document seem important. Or perhaps the font change information
should simply be discarded on conversion to HTML, as it does not
translate to meaning.
Or perhaps the right way to think of these is to apply the output rules,
in reverse. That is, the user can specify how <EMPH> is to be formatted
on output; similarly, perhaps the user could specify how bold font is to
be interpreted on input.
Bill