Re: LYNX-DEV <base href> change hurts me badly

[Foteos Macrides]

root <address@hidden> wrote:
>Will Mengarini wrote:
>(NB: Lots of editing for length.  Please read original if you have not.)
>> 
>> When I tried to load the file under 2-7, I got a display "Alert!: HREF
>> in BASE tag is not an absolute URL."
>> 
>> That, however, is only the first problem.  It seems to me that the
>> way I used <base href> is very useful & desirable.  
>>
>> Even if the new <base href> discipline does solve a problem
>> in real life, it's likely to also create other problems,
>> so it might be wiser for the old behavior to be the
>> default, & the "right thing" to be an option in lynx.cfg.
>> 
>> Here's a snippet from the beginning of one of these
>> HTML files.  The comment describes the creation of the
>> original HTML file; the file below is modified from that.
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>[...]
>> <base href="http://www.cs.utah.edu/csinfo/texinfo/emacs18/";>
>This is the only correct use of base; it sets the context other HREFs should
>be looked at in.  Since the BASE sets what context everything is relitave
>to, what would IT be relitive to?
>
>> <LI><A NAME="SEC1" HREF="emacs_1.html#SEC1">Preface</A>
>> <LI><A NAME="SEC2" HREF="emacs_2.html#SEC2">Distribution</A>
>> <base href="/~/emacs_toc.utah.htm">
>Is this "http://www.cs.utah.edu/csinfo/texinfo/emacs18/~/emacs_toc.utah.htm";?
>That is what it would be if it were parsed according to the BASE above it,
>wich is what is techinicly correct.  Or, should this be
>"file://u/s/seldon/~/emacs_toc.utah.htm", as it would be if it were relitive
>to the URL the document was retreived via.  Perhaps, as 2.7 is trying to
>point out, you should have said "file://~seldon/emacs_toc.utah.htm"

        1) Also note that only LI or LH elements are allowed at those
           points in a UL or OL block.  Even if BASE were legal in
           the BODY, it couldn't be positioned there (though Lynx's
           "error recovery" will handle that error).

        2) The "error recovery" Lynx uses for invalidly partial URL
           values of HREFs in BASE elements is not the "standard" URL
           resolving.  It's, indeed, "error recovery", i.e., a series
           of "Fote guesses" about what the "information provider" intended.
           Fortunately, from some people's perspective, and unfortunately,
           from other people's perspective, the sequequence of guesses
           usually does yield an absolute URL corresponding to what the
           "information provider" intended.  That's why it seemed important
           to include an alert, i.e, so nobody would start using the
           "error recovery" as a "feature".

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