I could if this was my only project, but it's not. At the moment development
on Traveler is a back-burner thing.
>> So turn off syntax checking except when you *need* it. You are going to
>> ship it with syntax checking turned off by default, right? Learn from
>> Netscape's error of "You are submitting a form insecurely...."
>> defaulting on. Don't annoy people unnecessarily.
>
>Not the same thing. Popping up a big dialog box is really annoying,
>sure. Although Netscape could hardly do it any other way because the
>whole reason for existence of Netscape 1.1N is to sell their secure
>server to the commercial sector. But flagging bad HTML in an Arena-like
>manner (except, getting it right ;-) is no more intrusive than a broken
>key icon, and could be left on all the time.
The syntax checking is on all the time. The syntax flagging is something
that can be turned on or off. Flagging means that it puts up a warning box
when it detects errors or unknown tags/attributes. Even if it doesn't put up
the warning box, the errors view still contains appropriate error and warning
messages. My intention is to distribute with flagging turned off, because most
people aren't going to care enough to want the warning msg popping up all the
time. And I do mean, ALL the time. I rarely encounter a page that doesn't
have at least warnings, if not outright errors. Usually the warnings are of
the form "Unknown tag <CENTER>" or "Unknown attribute CELLSPACING".
>Actually, if the browser incorporates a pukka SGML parser and checks
>against the DTD - it's not an ad-hoc bunch of error reporting from a
>custom parser, is it? - you could display the HTML 2.0 tick icon used
>by the Hal HTML validation service.[1] Or a broken HTML icon, as
>appropriate.
Perhaps unfortunately, it is indeed a custom parser. But what I did was to
create a data structure that encodes the DTD and then wrote the parser to
check syntax against this codified DTD. So it's sort of a half-way solution.
I suppose one could write another piece that would suck in a DTD and produce
a codified version. I guess you could say that the error reporting is ad-hoc,
but basically what it reports are:
Invalid tag placement (not allowed in current content model)
Invalid tag placement (specifically excluded by ancestor tag)
Missing required end tag
Unmatched end tag
Missing tag assumed (in cases where this can be done)
Expecting ">" or attribute name, found "<"
Expecting attribute name, found '"'
Unmatched quote in tag (which means it saw something like <foo "bar>
which I realize is not really an error)
It also warns of unknown tags and attributes.
One reason I use a custom parser is that I want the browser to be able to
recover from author errors such as omitting tags. For example, I wanted to
be able to insert the TABLE tag if the browser encounters a TR tag all by its
lonesome. Some of this could be done by careful investigation of allowed
context in the DTD I suppose.
Another reason for the custom parser is that I wanted to allow some tags to
remain even if they are technically not allowed by the content model, because
there are so damned many broken pages out there. My rule of thumb was that
I would be liberal in accepting invalid content only inside elements that are
in practice only font style changes, such as <EM>, <STRONG>, <H1> and so on.
To do otherwise can result in missing information. I accomplished this by
flags in the codified DTD, not by special checks in the parser. The invalid tag
placement still generates an error message.
>Does Traveller take any notice of the DOCTYPE declaration?
No, but it could if I took the time to encode the alternate DTD and to make
the browser choose the DTD depending on DOCTYPE. One reason I haven't done
so is that it sucks up DS space, and I don't want to go to large model if I
don't have to (things run slower in large model). Nor do I want to require
Win32s.
Michael Johnson
Relay Technology, Inc.