lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV fotemods.zip update


From: Klaus Weide
Subject: Re: LYNX-DEV fotemods.zip update
Date: Sat, 19 Apr 1997 13:06:15 -0500 (CDT)

On Sat, 19 Apr 1997, Foteos Macrides wrote:

> 1997-04-19
> * Changed the inappropriate StrAllocCat() to StrAllocCopy() for
>   loading the XLOADIMAGE_COMMAND in LYReadCFG.c. - PC
> 
> 
>       Note that this bug fix is needed for the current devel code as well.

...and will be added.

I have not added some of your recent changes, because I either disagree
with them, or don't understand them properly.  (and, a third possibility,
I didn't get around to it.)

A question to improve the understanding: you have made many changes in
HTML.c involving adding the following (and sometimes replacing previous
checks for me->inUnderline)

+       if (!me->text)
+           UPDATE_STYLE;

What is the purpose of those, and how much are they related to or caused
by the "extension of the FORM hack to other elements", or independent
of it? 

If the purpose is to always make sure a (possibly empty) document is
created, why is this done separately for the cases in the switch, instead
of once and for all at the beginning of HTML_{start,end}_element() ?

I do not agree that some of the changes you made for the USEMAP handling
are a good idea, or do not see how they are useful.  Specifically, that
USEMAP references to MAPs are now treated differently depending on
whether the MAP precedes or follows the USEMAP seems unintuitive and
inconsistent.  I am not familiar with the theory of "deferred objects",
and that may require that the MAP precedes the USEMAP; however, the 
Lynx implementation never required that AFAICS, so I don't see why
we should introduce any dependency on that.  Fote, you have gone to
some effort to make HTML.c comply to an understanding of the Fielding
URL draft for all HREF's etc. ("URL references starting with '#' are
always to the current doc.").  Now you deviate from that path for 
USEMAP attributes, and I don't like to follow :).  Maybe you can
point out realistic cases where this would increase the chance that
USEMAPs are found where they are intended to be found.

To other readers, this discussion refers onluy to cases where USEMAPs
are in documents with a BASE tag pointing to some other document (maybe
the original net version from which a local copy was made).  The change
I am referring to could them make a difference about whether Lynx goes
out to the net to get the MAP, or gets it from the current doc.

  Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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