Re: Parsing methods

Lee Daniel Crocker (lcrocker@calweb.com)
Wed, 10 Jul 1996 18:21:54 -0700 (PDT)


Message-Id: <199607110121.SAA17148@web1.calweb.com>
Subject: Re: Parsing methods
To: www-html@w3.org
Date: Wed, 10 Jul 1996 18:21:54 -0700 (PDT)
From: "Lee Daniel Crocker" <lcrocker@calweb.com>

----- Forwarded message from Lee Daniel Crocker -----

From lcrocker Wed Jul 10 18:21:22 1996
Subject: Re: Parsing methods
To: murray@spyglass.com (Murray Altheim)
Date: Wed, 10 Jul 1996 18:21:22 -0700 (PDT)
From: "Lee Daniel Crocker" <lcrocker@web1.calweb.com>
In-Reply-To: <v0211010aae09ffbf5c1a@[140.186.34.50]> from "Murray Altheim" at Jul 10, 96 09:03:21 pm
Reply-To: Lee Daniel Crocker <lee@piclab.com>
Organization: Piclab (http://www.piclab.com/)
X-Mailer: ELM [version 2.4 PL25 ME8b]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1319      

> Inconsistent behavior can be much more than an annoyance, it could cost
> someone a lot of money, or worse. And even valid markup is not necessarily
> what the author intended, but validation usually points out the errors.

Absolutely, I'm not arguing again validation in any way.  Quite the
contrary.  Anyone using HTML for mission-critical applications and
not validating it is asking for disaster.  I want all HTML to be
clean and valid, but the reality is that as long as it _can_ be
written by humans, it will be, and mistakes will be made.  I think
it is better for the standard itself to explicitly deal with as many`
of those mistakes as it possibly can.

> You can't make parsing rules about how to consistently handle inconsistent
> content. If the browser developer has to guess as to what broken markup
> means, how can anyone be sure that two developers make the same guess?

If it's in the standard, they don't have to guess.  What I'm saying
is that the standard can--and should--clearly specify what a reader
should do with certain things it expressly forbids writers from
creating.  That is not "inconsistent", it's just robust.  There is
no reason that the standard can't acknowledge the reality of human
error in the creation of HTML, and specify the most graceful way to
deal with common cases.


----- End of forwarded message from Lee Daniel Crocker -----