Re: LYNX-DEV CENTER in PRE

[David Woolley]

> isn't allowed inside <PRE>.  This is a nonconforming document, and any
> rendering of it comes under error recovery.  

Also, the only other reasonable error recovery tactics are:

- look ahead for an unmatched </pre> and assume that it matches the
  outstanding <pre>;

- assume that there was no -%block in the DTD.

In either case, there is then the question as to whether or not PRE
mode is suspended during the CENTER, and if not, what  does it mean to
have both PRE and CENTER modes on (format the PRE and centre the result,
or centre each line individually - I suspect the latter is what the
invalid code was trying to achieve, but the former would destroy less
of the formatting (e.g. ASCII graphics) associated with the PRE block).

The centre-whole-block approach is like tables in that you cannot position
even the first line until you have seen all of the block, so a one pass
renderer would probably have to ignore the CENTER mode.  As I said, the
centre-lines-independently approach seems to be violating the spirit of
PRE even more than allowing CENTER within it.

Note that it is still possible to get both PRE and CENTER active, as
DIV is a catch all and has no content restrictions.  However, there is
not the the strength of request to centre in this case, and it is more
reasonable to ignore it, although it might be reasonable to centre the
block as a whole.  (I don't think that it was really the intention that
they be combined, but HTML is based SGML, and SGML is about logical
structure and is showing the strains when also used to provide physical
formatting.  I think PRE was originally seen as a sort of escape from 
HTML, and has largely been ignored by all the extension, even though
they potentially interact.)

The lookahead case is an example of the more general class of global
error recovery tactics.  These can get quite complex and may still not
work well, when what one actually should be using is the source code of
Netscape/MSIE, rather than the DTD, if you want to produce Netscape/MSIE
compatible results, rather than correct ones.  E.g. you have to treat 
some tags as updating global state, and some end tags not causing a stack
pop, but simply doing a complementary change to the global state.

Moreover, once you start a lookahead, you have to stop incrementally
rendering, or be prepared to back it out and try again.  Lynx doesn't
currently incrementally render, which seems a pity, given that it uses
a one pass renderer, so the internal model must be created incrementally.
It could be made to do so, and most GUI ones already do so, although most
pages frustrate this by immediately going into table mode.  To gain the 
benefit of incremental rendering, you must:  make your error recovery
not look ahead; abandon incremental mode on the first error (thus 
making most real pages not render incrementally); or duplicate the bugs
in the primary target browser for the page.