Message-Id: <199503101959.OAA21018@ebt-inc.ebt.com> Date: Fri, 10 Mar 1995 15:08:56 -0500 To: email@example.com From: firstname.lastname@example.org (Steven J. DeRose) Subject: Re: Browsers and syntax errors (Was: Captions for Figures...) At 9:50 AM 3/10/95 +0500, Phillip M. Hallam-Baker wrote: >>Making browsers forgiving about HTML syntax errors, instead of giving >>good user feedback, is probably the gravest error committed by the >>browser writers. > >Making the browsers tolerant is essential. Otherwise they would fail on all >sorts of unexpected bugs in automated scripts. Synthesising correct HTML all >the time is very tricky. > Would you say the same thing about C compilers? That they should not report syntax errors, but just make the best of it and go on? One could make it really easy to write C if the compliers automatically opened and closed curly braces and parens for you. It would also greatly increase the chance that the result will be *wrong*. Of course a browser shouldn't crash on finding an error -- but silence is worse (the pain is just delayed a little). Current example: Perhaps the most common, trivial tag minimization in SGML is to use "</>" as a generic end-tag: "close whatever the last thing was that's still open". But a certain famous client's parser writer apparently didn't bother with it, which led to my whole document coming out in huge type when i did: <h1>the title</> no error message, no "</" showing up as data, no nothing. the browser found the end-tag and decided it was markup, not data, then did who knows what? If i'd been using a system that parsed HTML correctly, my file would work, yet i'd get tons of mail from people complaining how stupid it looked in browser x. conclusion: don't crash, but also don't patronize the authors by not telling them when they screwed up (better yet, create editing software that makes it easy to do things right, and hard to do them wrong).