browsing vs validation, or, why not to make software robust

Marc Andreessen (
Wed, 18 Aug 93 18:00:23 -0500

Terry Allen writes:
> Marc, with respect, your browser puts out a lot of error messages.


> What's so hard about reporting that the document is marked up
> incorrectly---even if you don't report all SGML errors?
> For example, I recently found that one of our editors, an
> experienced typographer, had created a set of heads that
> looked like this:
> <H2>foo</H3>
> Because they looked okay in Xmosaic, she didn't bother to
> parse the document.

Clearly Mosaic's fault. I can smell it coming.......

> But she had an illegal, ambiguous, construction. Can't your parser
> tell when it hits something like this?

........and there it is.

Why can't the document be validated via standard validation
mechanisms? Why must the display mechanism be overloaded as the
authoring mechanism as well?

OK, this is confusing me. When I'm at O'Reilly I meet people who tell
me, wow, Mosaic is wonderful, it handles anything you throw at it
without complaining, it's the most robust thing I've ever seen (as
close to verbatim as I can remember). Now, someone else from O'Reilly
is telling me the exact opposite. Huh???

> Of course, it is good practice for publishers (that means all of us
> if we put up files at our sites) always to parse their files before
> archiving them.


Folks, don't complain to us because Mosaic is robust. Come on.

For the record: the really big reason Mosaic does not report errors
and will not in the forseeable future is because DOING SO WOULD
REQUIRE WORK and we have our hands full doing other, more important
things (better widgetry and HTML+, fill-out forms, HTTP/1.0 and WAIS,
bugfixes, support, etc.). The other reason, which isn't even coming
into play because of the first reason but which otherwise would, is
that Mosaic is a browsing environment, not an authoring tool.

This, to me, looks like a prime opportunity for O'Reilly to put one of
its people on writing, distributing, and supporting a small,
efficient, and user-friendly HTML-lint.