lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV v2.6FM update


From: Foteos Macrides
Subject: Re: LYNX-DEV v2.6FM update
Date: Tue, 28 Jan 1997 18:26:12 -0500 (EST)

root <address@hidden> wrote:
>Foteos Macrides wrote:
>> 
>> 01-27-97
>[...]
>> * Modified the code for submission of form content with TYPE="image" NAME-ed
>>   INPUTs that have a VALUE (or ALT) to "fake" a 0,0 coordinate pair, as when
>>   a VALUE (or ALT) is absent, instead of sending a single name=value pair.
>>   Requests that using a name=value pair in such cases to indicate that the
>>   submission was from a text client or GUI with image handling turned off
>>   be included in the HTML specifications keep falling on deaf ears, so we
>>   may as well "fake" something closer to what the CGI scripts are expecting,
>>   and hope that the script interprets 0,0 as an indicator that the user did
>>   not see the image and make a conscious choice within it.
>[...]
>>
>>                              Fote
>
>Perhaps sending -1,-1 would be better, since that way you would get an error
>message rather than some random page if the CGI isn't lynx aware?

        Getting an error message 99.999% of the time by sending -1,-1 isn't
any better than getting it 99.999% of the time by sending name=value, and
has the disadvantage of the script having no way to know that it isn't
really an error.  I've never seen TYPE="image" used as a real image map.
It's usually used for the "pizzaz" of an image instead of textual button,
and the script thus doesn't care about the coordinates.  It's also used,
as in the wbs.net case that brought on this issue, because the WebMaster
apparently doesn't understand enough about the CGI protocol and its
integration with HTML to do it properly, and instead used a form based
kludge (see below).


>In any case, it is rather a mute point, since if the writer of the page
>wished to be lynx-friendly, using a client-side imagemap would be the way to
>go.

        That wouldn't fit with the wbs.net's TABLE-ular page design.
What they're using is a FORM start tag around a TABLE (and sometimes
invalidly interdigitating, i.e, putting the FORM end tag before the
TABLE end tag, sigh...), and then using TYPE="image" INPUTs simply
to have a ?searchpart appended to indicate to the script which
INPUT was used to submit the form, e.g.:

[...]
<form action="http://wbs.net/webchat3.so"; method="get">

<table width=600 border=0 cellpadding=0 cellspacing=0>
[...]
<tr>
<td valign=bottom>
<input type=image name="whoson"
src="http://images.wbs.net/wbs3/auto/whoson_sm.gif";
align=bottom width=74 height=30 border=0
ShouldBe-value="Who's On"
alt="Who's On">
</td>
[...]

        So when you "push" that button, the browser sends:

        http://wbs.net/webchat3.so?whoson.x=[x coord]&whoson.y=[y coord]

and the webchat3.so script is parsing it's QUERY_STRING environment variable
for "whoson.x" (and ignoring the rest) to return the document for whoson.
The script could just as well have parsed for "whoson", and it would have
worked the way they have it now, for Lynx v2.4 - v2.6.

        BUT, the RIGHT why to do that, avoiding the needless additional
overhead for browsers to handle FORM/TABLE embeddings, is to forget
about forms and NAME-ed INPUTS, simply use:

<a href="http://wbs.net/webchat3.so/whoson";><img
src="http://images.wbs.net/wbs3/auto/whoson_sm.gif";
align=bottom width=74 height=30 border=0
alt="Who's On"></a>

and have the the webchat3.so script check its PATH_INFO environment
variable for "/whoson".  It would display identically to what they
have now, and would work properly for ever browser since the beginning
of the Web.  If effect, they've "reinvented the wheel" as an "oval"
form based kludge.   But their heart is in the right place. :) :)


>I also have two questions, one on a slightly related issue:
>
>1> What is the best way to provide text names on the page you get from a
>[USEMAP] link?  Ideally, you could still use the standard "put the <map>
>block at the end of the page" method and non-lynxes would ignore the text
>names.  Using ALT=... on <AREA> tags would probably be the most sensical
>method.

        I may not understand your question.  The ALT attributes in AREA
tags are used as the link names in the formatted, textual representation
of the image map.  A GUI with image handling on will instead inline the
image, and correlate the x,y coordinates of a "click" with other attributes
in the AREA tag to select the HREF for submission.  In Lynx, the ALT
or a TITLE attribute in the IMG tag with USEMAP will be used as the
link name for invoking the formatted texual display, with ALT having
a higher priority than TITLE, if both are present.  The TITLE, or
ALT if a TITLE attribute is absent, will be used as the title and
H1 of the formatted textual display.  Lynx also will check for a
TITLE attribute in the MAP start tag, and use that as the title and H1.
The latter is a nicer way to do it if you have all your MAPs collected
into a file separate from your documents (which Netscape still does not
support, though, AFAIK).


>2> Is it possible to have lynx execute <applet>, etc. links.  That is,
>provide a images-links like thing for <applet>,<object>,etc. that would
>execute the content as if it was a normal <a> link.  

        Lynx resolves a URL for the APPLET source, and will make it a
link if you have clickable_images toggled on.  It will inline the APPLET
content (intended for APPLET disabled or incapable browsers) if there
is any.  It uses the APPLET start tag's ALT, if there is one, or an
"[APPLET]" pseudo-ALT, as the link name for actual APPLET's resolved
URL.  That gets you the source, if you want it, but if parameters
were specified, there's no way at present to get those passed to
a helper app.  The relevant code is under  case HTML_APPLET:  in
HTML_start_element() of src/HTML.c if you want to try some schemes
for retaining and passing parameters to a helper app. 

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

reply via email to

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