[Top][All Lists]

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

Re: "mailto:" + EXTERN wishlist [lynx-dev]

From: Klaus Weide
Subject: Re: "mailto:" + EXTERN wishlist [lynx-dev]
Date: Sat, 12 Jun 1999 12:13:44 -0500 (CDT)

On Mon, 7 Jun 1999, Vlad Harchev wrote:

> On Sat, 12 Jun 1999, Klaus Weide wrote:
> > On Sun, 6 Jun 1999, Vlad Harchev wrote:
> > >  We can extend the syntax of EXTERNAL command - for example %s will still 
> > > be  
> > > substituted with url, and %t substituted with value of the TITLE 
> > > attribute. Of
> > > course this will complicate handling, but this worth it.
> > 
> > The more fundamental problem is how to make the TITLE survive from HTML_*
> > to links[].  The question how to handle TITLE *attributes* (not <TITLE>
> > elements) better came up recently in connection with <LINK> elements.
>  It's implementable. In lynx_help/lynx_url_support.html there is a description
> of "mailto:"; variations supported by lynx. The obsolete (but still
> supported) one is
>       href="mailto:address@hidden";
> so we can create such urls and store them in links[] if there is TITLE
> attribute of 'A' element, and then extract subject when EXTERNAL is invoked.

It's not obsolete - on the contrary, it is now allowed by RFC which
extends the mailto: syntax (in an incompatible way to the old
specification, thus the bias in the Lynx documentation against it).

You are proposing a terrible hack here: Messing up a perfectly fine URL,
valid according to old and new spec, to become something valid only
according to new spec.  Also there are lots of special cases that would
have to be ironed out (URL escaping, what if subject is specified in both
forms, what if URL has some other ?keyword=..., etc..)

Moreover this would only work for mailto: URLs, not for other cases where
TITLE also may be useful.

>  This leads to another technique - don't add fields to the links[], but append
> specific strings to urls for futher use (not only for mailto urls).

Maybe it doesn't have to be added directly to links[], but to the HTLink
struct to which links[n] points in some indirect way.


reply via email to

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