[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev New <BR> collapsing patch

From: Larry W. Virden
Subject: Re: lynx-dev New <BR> collapsing patch
Date: Mon, 17 Aug 1998 03:59:09 -0400

From: Philip Webb <address@hidden>
> 980816 Dave Eaton wrote:
> > On Sun, 16 Aug 1998, Philip Webb wrote:
> >> (2) there is no `valid, correct' behaviour, since the specs are broken;
> > I think you can see a number of us dissagree with you
> > that the spec is "broken" and believe current Lynx behavior is "correct",
> it's not clear that anyone other than you disagrees
> the specs are inconsistent & unclear;
> if they do, they should offer some analysis of the specs themselves.

No - some of us see that it is not going to do any good to argue the matter,
since this is NOT the W3C HTML mailing list.  THAT's where the argument
over validity of the specifications go.

Since we don't care to drag this obviously doomed from the start thread
on any further, we've chosen to shut up, hoping the time honored tradition
of the net of letting threads die out due to lack of attention would
pay off.

Unfortunately, there are times when that tradition fails and someone decides
to invoke the 'silent majority must agree with me' argument.  Here's one
person from the silent majority who agrees with Dave Eaton.

> i've reviewed the thread(s) & don't see a majority:
>   for keeping current behaviour as default: yourself, LV, MW, NHE (4);
>   for not collapsing <BR><BR> by default: AG, DH, JM, DW, me (5).

As I have mentioned before, I am for keeping the current lynx behavior.

> no-one has addressed the real-life state of affairs
> in which the typical document author has very little knowledge of HTML
> & very little time or inclination to learn about its finer points.

I vote against trying to accomodate all the files written by authors
without knowledge of HTML that are out there - I've seen too much
trash.  I don't mean that lynx should refuse to handle them - proper
error handling should result in _something_ being output.  But I am
technically against changing lynx to make the default be to display
bad html correctly at the 'expense' of incorrectly handling what is
_technically_ correct, based on the current literal interpretation
of the specs.  If there are felt to be inconsistencies in the specs,
then I am in favor of the discoverer of those inconsistencies changing
the HTML specifications to clarify, while the code writing folk do the
best they can to accomodate some sort of consistent behavior in lynx.
Having lynx change the way various things display each release, with
the exception of fixing outright bugs, seems to me to be a bad precedence.
It makes the job of convincing the public to include code for proper
lynx display that much harder.

Larry W. Virden                 INET: address@hidden
<URL:> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]