Re: LYNX-DEV HTMLerised options -- questions thereon

[Al Gilman]

  From: "James M. Mastros" <address@hidden>
  Subject: LYNX-DEV HTMLerised options -- questions thereon
  Date: Thu, 2 Jan 1997 17:39:34 +0000 ()

    I am going to try HTLMerising the 'o'ptions screen, and I have some
  questions.
    
  2)  Where are non-standard (e.g. LYNX*:) URL schemes properly defined?

In the online H)elp under

 Linkname: Supported URLs
 Filename:
        http://www.crl.com/~subir/lynx/lynx_help/lynx_url_support.html


  3)  I was thinking that I would add a LYNXOPT: scheme in the form
  
I was thinking that it could be embedded in the existing cgi-escape
scheme via a reserved path.  This is already set up to work with 
forms.

  LYNXOPT:optname=value -- set "optname" to the value "value" 
  
Why would you want to introduce this irregular syntax?

  LYNXOPT: -- show the main options screen 
  
  LYNXOPT:optname -- toggle the value of "optname"
  
  LYNXOPT:__postdata__ -- use the data in the POSTed form to set the options
  (meant to be called from the page generated by "LYNXOPT") (underscores in
  case a "postdata" option is defined sometime)
  
  Does anybody see any big problems /w this.
  
Not big problems, but I think that there are better ways to communicate
with the user so as to minimize errors.

The syntax flavors above read like an obsolete user interface.  It would
be better to fold all HTML-encoded options designations under urlencoded
post data from a form so that toggling can be presented to the user
as a checkbox, select-from-discrete-range as radio buttons, etc.

  4)  Can anybody think of any security risks (I would use the pre-existing
  functions for changing the options, so I would think any security issues
  would be addressed those functions)
  
Security is not so much the issue as leaving an inoperable Lynx
configuration.

What I would like eventually is that a user's spelling of an URL
for HELPFILE etc. be checked out to be usable before the user
commits to saving the new election.  With Lynx running, this
can be checked out.

  5)  What are the valid combinations for comment processing?
  
All four combinations of the Boolean flags {Historical_comments,
Minimal_comments} are legal.  On the other hand, Historical
overrides Minimal; you can have them both turned on but in that
case what you get is Historical.  If both flags are false, SGML
comment syntax is followed.

Al Gilman
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;