Re: LYNX-DEV fotemods.zip update

[Foteos Macrides]

Klaus Weide <address@hidden> wrote:
>On Sat, 19 Apr 1997, Foteos Macrides wrote:
>[...]
>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.)

        That's fine.  I've already posted messages, here as well as
in reply to CC's of messages among the currently active developers,
that I do not want to be considered an active developer at this point,
that, as stated in the 00README for http://www.slcc.edu/lynx/fote/patches/
fotemods.zip simply contains mods or bug fixes that I've made in the Lynx
code I personally use and am making generally available in compliance with
the GNU GPL, and that the currently active developers are free to consider
them, but should feel free to ignore any or all of them for the devel code.
I have no beef with you and what you've been doing, Klaus, indeed, I
applaud it, but I see no basis for TD's snotty remarks about me being
"off marching in his own direction", nor any need for him wasting his time
making wrong guesses about what would help me "cut down" on my time. ;(


>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() ?

        There are two purposes for that macro.  One is to allocate
an HText structure for the rendering if it hasn't already been
allocated, but its primary purpose is to skip calls for setting the
style if they aren't needed.  I added the if() for cases in which it's
being called simply to ensure an allocation.  I didn't move that to the
top, because some of the elements can need execution of "hacker's code"
before calling the formal style-setting functions.

        I removed the me->inUnderline checks in HTML_start_element()
and HTML_end_element() because they were redundant with the code I
had added to initialize the me->foo elements when allocating or
freeing that structure, and to do a pseudo-wind-down now that the
emphasis tags are declared SGML_EMPTY and the wind-down I had added
in SGML_free() doesn't consider them.  Also, removing them and relying
only on the other initializations reduces the chances of being tripped
up by bad HTML.  By the way, I haven't yet had a single serious or
even semi-serious problem due to bad HTML, now that I am using those
mods.  I suspect all that backup code I had add for v2.7 in HTML_free()
to ensure default alignments are reset may not be needed now that
you've found an old "off by one" bug in the handling of the DIV/CENTER
nesting depth index, but haven't looking into that.


>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.

        A "deferred object" is one which needs to be analyzed, but
not used until something else in the document needs it.  If the
MAP ID had been taken seriously by the HTML-WG, back when it was
written as a purely Informational ID, instead of being included
in the May 1996 so-called HTML 3.2 draft simply by reference to
the at that point long expired Informational ID, it surely would
have been made a HEAD element, like SCRIPT.  Note that OBJECT
can be made a deferred object by including a DECLARE attribute,
but must be a BODY element in the DTD because that's what it
actually is most of the time, and so it also would be a good
idea to put deferred OBJECTs at the top of the BODY.

        I thought I had answered your other question previously.
The Fielding URL draft clearly applies to fragments used for
positioning within the document.  But fragments pointing to MAPs
are not necessarily in the same category.  They could be handled
equivalently if there were a requirement that an absolute URL be
used as the HREF value if it is not in the same document, which
there isn't, nor that they be placed at the top of the BODY.  The
Netscape bug requires that they be in the same document, but no
other browsers require that, and so it's unclear whether to resolve
versus the BASE if one is present.  If you always resolve versus
the current stream's address, and the MAP isn't there, that will
fail.  The way I dealt with the ambiguity in the Lynx code I'm
personally using, and making generally available via fotemods.zip,
reflects my approach for minimizing the risk of a complete failure,
but, again, it's fine with me if you take a different approach in
the devel code.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;