- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Tue, 4 Feb 2003 07:48:51 +0000 (GMT)
- To: w3c-wai-ig@w3.org
> For browser makers like Netscape and Microsoft, building massive pieces > of software to run on desktop machines and primarily oriented towards > visual rendering this just meant adding more error-correction code. The My impression is that NS4 and earlier aren't about error recovery, they simply have a very simplistic parser that never builds a model of the structure, but just acts on open and close tags, largely out of context. E.g. <b> turns on a bold flag and </b> turns it off, so <b><i>...</b></i> is a perfectly well defined operation for them, and buffer up tables until they see </table>, explaining their problems with unclosed tables. IE does seem to be much more about error recovery, and has the problem of building a correct structure for CSS and DOM operations, whilst still displaying <b><i>...</b></i> in the same way as NS 4.. > As people build other browsers, they want to avoid spending their life > writing error-corrections and actually put some useful features in. On But the (poorly documented) error recovery is a very good lock in property for the big browsers, and greatly increases the cost of entry to the market for new developers - a commercially desirable attribute. > In the XML world, processors are meant to stop if they run into an > error. This is to provide the robustness required for doing things like As most browsers use non-validating parsers, this only really applies to well formedness errors; missing alt attributes are not well-formedness errors. Also, the commercial pressures to do error recovery are very high, and I imagine that browsers might provide a compliant mode but will soon have an easily accessed, or even default, mode, in which they silently apply error recovery. (Even Lynx users object to the warning messages that it produces for the more badly broken pages.)
Received on Tuesday, 4 February 2003 02:55:48 UTC