Re: lynx-dev New <BR> collapsing patch

[Nelson Henry Eric]

>   for keeping current behaviour as default: yourself, LV, MW, NHE (4);

Actually I would favor having the "tag-soup" way of thinking as
the default, i.e., not collapsing multiple BRs as the default,
just as I supported Fote's parsing routines as the default.  The
reason being that users who don't understand the HTML are going
to clamor "bug", while those who do, or are die-hard purists, will
also know how to compile, configure or toggle Lynx for their needs.

That does not mean I don't want the option of having behavior
which follows the standard.  Quite the contrary, I believe one of
the great strengths of Lynx is that it has to a large degree a
respect for acknowledged standards.  Just as I fought for keeping
both Klaus's and Fote's parsing routines, I think we should keep
both "follows standards" and "follows real world convention" ways of
handling this problem markup, BR.

The problem I have with the patch that was submitted is that it
would remove the "follows standards" option.  This to me is
unacceptable.  Also, for one problem tag, the overhead of adding
a three-way toggle seems unreasonable.  IMHO, what needs to be
tweaked is the "follows real world convention" part of the code
to do what the majority of those people want, i.e., if COLLAPSE_BR_TAGS
is set to FALSE and the behavior that most of the people who want
that treatment of BR is not quite right, then change THAT logic,
don't change the logic for COLLAPSE_BR_TAGS=TRUE.

> no-one has addressed the real-life state of affairs

Fote addressed that ages ago; I see no difference in your arguments
from those presented in the past.  There is a mechanism in both
userdefs.h and lynx.cfg to chose between logic that follows the
standard and one that *trys to guess* the way the "general public"
will interpret how BR should be handled.

I will state my position again so that it is not misunderstood:
        1) Making the "intuitive" or "general public" interpretation
           the default might be a good idea in the sense that it
           lessens some of the "there's a bug" noise.
        2) Taking out or mangling code which follows the recognized
           standards is unacceptable.
        3) In any change made to Lynx, a careful evaluation of the
           benefit of the new code versus the overhead in terms of image
           size, no matter how small, should be made.

> but if you believe more than a very tiny minority of document authors
> have the slightest knowledge of or interest in such things,
> you simply don't live in the real world:

If what you say is true, then the Internet is in a sad state of affairs.
I would hope that document authors have pride in what they present.  When
they don't, I begin to question the value of the content itself.

> the solution is simple: a run-time configurable choice (needs programming)
> or at least changing the  lynx.cfg  default to match real-life out there.

No problem with this whatsoever.  What you may find, however, is that
trying to "match real-life out there" may not be so simple.  When that is
found to be the case, argue over how *that* code can best match the majority
of the people's ways of thinking.  Don't fool with code that is designed to
follow a recognized standard.

__Henry