[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LYNX-DEV fotemods.zip update
From: |
Foteos Macrides |
Subject: |
LYNX-DEV fotemods.zip update |
Date: |
Sun, 13 Apr 1997 19:54:23 -0500 (EST) |
An update of fotemods.zip is available in:
http://www.slcc.edu/lynx/fote/patches/
1997-04-13
* Modified the handling of BASE for resolving HREFs in relation to MAP
and AREA elements, and USEMAPs in IMG and OBJECT elements. The
formally released code was treating such links equivalently to the
handling of fragments for positioning the display to ID-ed elements
or NAME-ed Anchors, and assuming they're in the same document if the
associated HREF value begins with a '#', rather than resolving versus
the BASE, and was always resolving versus the BASE for MAP ID or NAME
attributes, and for the AREA HREFs in MAP content. We now always
resolve the MAP ID or NAME attributes versus the current stream's
address (since the MAP must be in it or we wouldn't be handling it),
but still resolve the AREA HREFs versus the BASE, if one was present.
According the original draft and the current HTML 3.2 Proposed Standard,
MAPs need not be in the same document as the IMG or OBJECT elements
which specify links to the MAPs. Because MAPs are "deferred objects",
they logically should be placed above any IMG or OBJECT elements which
reference them in the same document (as is done for SCRIPTs), but this
isn't stated in the specs, nor always done in practice. Also, there
aren't any guidelines in any specs on whether to resolve versus the
BASE or current stream's address. So for now, the code checks for
whether the absolute address when resolved versus the current stream's
address is in the LynxMaps structure, as would be true if the MAP were
placed above the IMG or OBJECT element in the same document, and uses
that if so, but otherwise uses the BASE (and authors who place the
MAPs further down in the same document should be informed about
"deferred objects" and encouraged to move them up 8-). - FM
* Fixed bug in HTML_free() for the case when LYMapsOnly is set. We
didn't create an HText structure for the stream (just scanned it for
MAPs and processed them into LYMap.c's LynxMaps structure), nor do
we want to create a blank one (as was being done) since we didn't
render the stream, nor would we have a me->target set. So we just
free any me elements that might still be allocated (though they
should have been freed already), and return rather than continuing
through the rest of the HTML_free() code. - FM
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.
;
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/11
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/12
- Re: LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/12
- LYNX-DEV fotemods.zip update,
Foteos Macrides <=
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/14
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/15
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/17
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/18
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/19
- Re: LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/19
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/20
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/21
- LYNX-DEV fotemods.zip update, Foteos Macrides, 1997/04/22