Re: folding elements

• Mail folder: WWW Talk Jan 94-present
• Next message: Didier.Courtaud: "Paper version of an HTML document"
• Previous message: Rob McCool: "ACCESS CONTROL PROBLEM in NCSA httpd"
• Maybe in reply to: Pei Y. Wei: "Re: folding elements"

Errors-To: listmaster@www0.cern.ch
Date: Fri, 25 Mar 1994 09:57:59 --100
Message-id: <7876*phillips@cs.ubc.ca>
Errors-To: listmaster@www0.cern.ch
Reply-To: phillips@cs.ubc.ca
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: George Phillips <phillips@cs.ubc.ca>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: folding elements
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2389

Of course, you can do folding with a server hack.  See
http://www.cs.ubc.ca/inmenu/top/- for an example.  You'll
also see that a round-trip for each unfolding is not a lot
of fun.  More to the point, the current proposals can't
do what my hack does because the conditional text (the list
to in-line) and the condition toggle (the triangle-thingy)
are separate.  I'd suggest going to a more general mechanism
by having some sort of tag to set conditions and and another
tag to display or supress stuff based on a condition.

Condition setting can be done by leveraging off FORMs support.
Add an INTERNAL keyword to indicate the new role.  Use a
new container tag that can test values of the NAMEd variables
of a form.  An expandable menu might look like this:

    <FORM INTERNAL><INPUT TYPE=checkbox NAME=menu1></FORM>
    Some Foods
    <WHEN NAME=menu1 VALUE=yes>
      <UL>
        <LI> Grapes
        <LI> Cheetos
      </UL>
    </WHEN>

The INTERNAL status of the form would make the browser update
as soon as something was done to it.  We could adopt the convention
that INPUTs outside of any <FORM></FORM> pair are INTERNAL.  Here's
another example:

    Show me hello in 
    <INPUT TYPE=radio NAME=lang VALUE=en>English
    <INPUT TYPE=radio NAME=lang VALUE=au>Australian
    <INPUT TYPE=radio NAME=lang VALUE=ca>Canadian
    <P>
    <WHEN NAME=lang VALUE=en> 'Morning, old chap. </WHEN>
    <WHEN NAME=lang VALUE=au> G'day, mate. </WHEN>
    <WHEN NAME=lang VALUE=ca> Hello, eh. </WHEN>

Besides expanding lists, you could use this to do delayed image
loading, forms that only show what needs to be filled out and
other useful stuff (single page hangman?).

You still can't exactly reproduce what my menu hack does.  SELECT almost
does it.  Perhaps a version of SELECT that only allows you to step
sequentially through a bunch of options:

    <SEQUENCE NAME=menu1>
      <OPTION VALUE=closed><IMG SRC=closed.gif ALT=")">
      <OPTION VALUE=open><IMG SRC=open.gif ALT="v">
    </SEQUENCE>

SEQUENCE would create a selectable area which would cycle through
the options when selected.  In this case it's really only a cosmetic
advantage over a check box.  It could be useful in conventional
forms.  Whatever.

You might consider this a step onto the slipperly slope of making
HTML into a turing-complete language.  Maybe.  From my late night
viewpoint, it seems worth the risks.