- From: Glenn Adams <glenn@stonehand.com>
- Date: Tue, 13 Dec 94 09:25:22 -0500
- To: dsr@hplb.hpl.hp.com
- Cc: Multiple recipients of list <www-html@www0.cern.ch>
Date: Tue, 13 Dec 1994 11:28:48 +0100 From: Dave Raggett <dsr@hplb.hpl.hp.com> 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
Received on Tuesday, 13 December 1994 16:14:29 UTC