Glenn Adams writes:
> 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.
This argument is nonsense. Arena is able to detect markup errors trivially,
and the real (but not very hard) work is in being able to recover from
errors.
Tell me Dave, what is the memory footprint for a fully validating SGML
parser on a Windows 3.1 platform; what performance penalty will be paid
on a 386/25Mhz Windows machine for doing a full validation prior to
displaying a document?
I didn't say it is or is not trivial to detect markup errors and/or
recover from them. I said "putting a validator" [by which I mean a
full validating SGML parser] into a browser would be a signficant
penalty. I stand by this opinion. If, on the other hand, you mean
by "validator" a gutted, HTML-specific parser capable of little other
than error detection, then you are certainly correct. However, given
the trend towards including more SGML functionality, it will be hard
to maintain in a small profile -- soon you will end up with a full
SGML parser.
I still think that servers should validate their documents prior to
transmitting them, thus relieving browsers of the burden [of course
some minimal error detection recover will still be necessary in the
browser, but not full validation capabilities.]
Regards,
Glenn Adams