Re: lynx-dev Lynx 2.7.1 and 2.8 refuse to render certain HTML documents

[David Woolley]

> > 
> > - the current code only has provision for caching the rendered version;
> 
> Yes, that's the matter under discussion.

The point here is that it is a non-trivial change.  My guess is that it 
involves essentially adding a second cache, even for a simplisitic change.
My own preference would be to re-use the original string fragments (although
the need to do things like skip newlines and excess spaces might make this
less attractive than it seems at first), which would make the change even
more complex.

> I disagree.  Several of the rendering controls are things that users
> need to be able to toggle, even if they don't know why: comment parsing,
> source charset, and DTD.

When you are talking of non-power users, I think you are talking about
the typical MSIE and Netscape user, who is used to just living with what
error recovery the browser has.

> Once the source cache existed, we could finally add a facility to figure
> this stuff out for the user.  I believe this has been mentioned before,
> as a pie-in-the-sky future idea.  I think we could almost implement it
> now.  Call it a "rendering wizard".  If a document rendered strangely
> ("hey!  this thing is blank!") the user could hit a "figure out this
> document for me" key.  It would come back with something like:

I think you would really have to do this to justify the non-power user
argument, although I believe that this would go well beyond the error
recovery in the commercial browsers.

> 
>   This document appears to have incorrect comment closure; suggest
>   setting "historic" comment parsing.

No.  If you do this, I believe, you have to do the error recovery without
explanation.  Otherwise you will get lots of questions/complaints about
the "arcane" messages.  On the other hand, you do need a mode indicator
so that people have a chance of working out what's gone wrong when it
still doesn't work like MSIE.

Actually it is very difficult from a non-sophisticated user interface
point of view; if you don't prompt them that an alternative mode might
work, they won't find the command to do it, and if you do, you'll
get complaints about Lynx producing an error message when MSIE just
displays the page "correctly"; if you do error recovery unprompted, you
may well make the wrong assumptions and make things worse (except that
MSIE is assuming that valid input is invalid, the MSIE assumption that
something that looks like HTML is HTML is an example).  Manually initiated
recovery would help an intermediate user, but not the majority of those
who would otherwise use a GUI browser.

> 
> > - caching source only has a very real effect on the performance on slow 
> >   machines, and caching both has an impact on memory (although you might be
> >   able to share the text of contiguous strings between both versions);
> 
> ???  The performance effects of source caching have everything to do
> with the machine's network connectivity; almost nothing to do with the

Bad wording, I should have written: "caching only the source....".

> 
> Lynx already caches pages in memory.  For on-disk cache, I would expect
> it to behave exactly the same as it does now, using the disk space as
> purely an adjunct to its memory.  In particular, the disk cache would
> not persist from one Lynx session to another.  The cache complexity
> issues would be exactly as unresolved as they already are in Lynx's
> rendered document cache.

OK - that becomes an implementation issue which wouldn't be understood by
the target audience, of those who are only interested in behaviour and
not technology.  I was talking of disk caching as understood (or not)
by the average MSIE or Netscape user.