Re: Processing instructions for style tweaks?

 > From www-html@www0.cern.ch Sat Dec  3 16:53:25 1994
 > Date: Sat, 3 Dec 1994 21:17:54 +0100
 > Reply-To: glenn@stonehand.com
 > Originator: www-html@info.cern.ch
 > Sender: www-html@www0.cern.ch
 > From: Glenn Adams <glenn@stonehand.com>
 > To: Multiple recipients of list <www-html@www0.cern.ch>
 > Subject: Re: Processing instructions for style tweaks?
 > X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
 > X-Comment: To sign off, send mail to listproc@info.cern.ch with body DEL WWW-HTML
 > Content-Length: 944
 > 
 > 
 >   Date: Sat, 3 Dec 1994 00:30:06 +0100
 >   From: patrick@voyager.gate.net (Patrick Stickler)
 > 
 >   that furthermore, browsers become
 >   strict in their parsing of HTML document instances, notifying the
 >   user/reader when a document instance is invalid (rather than trying to
 >   guess around the HTML errors).
 > 
 > In keeping with a fundamental tenet of the Internet (or at least one
 > that used to hold), the WWW should be "conservative in transmitting,
 > and liberal in receiving."  According to this view, the HTTP servers
 > should be the component which ensures that only valid HTML is transmitted.
 > 
 > So we need to bang on the server builders/providers! However, if a
 > few popular browswers validated prior to display, it would put pressure
 > on the server/data providers.
 > 
 > The practical problem with putting a validator in the browser is size
 > and performance penalties.  I think this is another argument for pushing
 > validation onto the server.
 > 
 > -- Glenn Adam
 > 
 > 


The problem with putting the burden of validation on the server is that
authors will continue to create invalid documents unaware that there
are errors in their work. This is because authors use browsers to
"check" what they write -- and if it looks OK on the screen, it must be
OK.  Unfortunately, most current browsers apply various heuristics and
tricks to work around errors in invalid document instances in order to
display as much information as possible, thereby giving the author a
false impression that their document is valid.

I don't see the general practice of folks using browsers to validate
documents changing -- since authors *do* want to check how the
information is displayed on screen, a separate step of validation will
surely be considered too cumbersome for the average author. Folks won't
want to both validate their documents with a validator/sgml parser, and
then "validate" its appearance with a browser. Also keep in mind that the
average author does not care about functional markup or valid document
instances -- all they want is to present their information organized
and formatted in a certain way, and to do so as simply as possible.

The only practical solution is to make the browser the validator. I
think that as more functionality is added to HTML, including style
sheets, etc. a full sgml parser embedded within a browser will be a
useful (if not necessary) addition and will more than compensate for
any size or performance hits (which I doubt will be too great).

 
===============================================================================
    Patrick Stickler                        Email: patrick@voyager.gate.net
    Senior Computer Systems Engineer        Phone: (407) 356-9852 Office
    Information Group                                    356-6094 Lab 1
    Martin Marietta Corporation                          356-7725 Lab 2
    MP1270, 12506 Lake Underhill Rd.                     356-5685 Lab 3
    Orlando, Florida 32825 U.S.A.           Fax:   (407) 356-8949
-------------------------------------------------------------------------------
    Don't put off for tomorrow what you can do today; because if you enjoy
    it today, you can do it again tomorrow...
===============================================================================

Received on Sunday, 4 December 1994 03:56:04 UTC