Proposal -- Foldable Anchor Inclusion

<HTML>
<HEAD>
<TITLE>Proposal -- Foldable Anchor Inclusion</TITLE></HEAD>
<BODY>

<H1>Proposal -- Foldable Anchor Inclusion</H1>

This is a proposal to add a new folding capability to HTML 3.0 by
adding a new value for the EFFECT attribute of an 'A' element.  (for
background on EFFECT please consult <a
href="http://info.cern.ch/hypertext/WWW/MarkUp/HTMLPlus/htmlplus_14.html">
the relevant part of the HTML+ spec</a>).
The proposed new value is <b>Indent</b> or <b>Foldable</b> or
<b>Fold</b> (in decending order of my preference).  It means that the
retrieved document should be rendered in place within the current
document, indented one level (the width of this indentation would be a
browser preference).  Foldable tags within the new subdocument should
be indented even further when they are unfolded, producing a natural
outline structure.  This capability represents a sort of
user-controlled client-side include mechanism which is similar to the
way images are now included by user-click in some web browsers for
Macs and PCs with slow net connections.  Note that this proposal is
backward-compatible with HTML 2.0, since browsers that don't
understand the EFFECT tag would just display the foldable item as a
normal link.

<h2>Refolding</h2>

Browsers which support this should be expected to provide a way to
"refold" a subdocument which had been "unfolded", thereby returning to
a shorter displayed document.  Note that the browser history is not
enough; I may retrieve a document with A and B folded, then unfold A,
unfold B, then finally refold A; this is a new state I haven't seen
before in my window history.  

<h2>Why Put This Property on the Anchor?</h2>

Many documents may stand on their own right, and may also be
appropriate for indented inclusion in other documents.  It's not
really a property of the included document whether it's appropriate
for inclusion, but a choice that should be made by the author of the
including document when authoring the anchor.

<h2>Why Indent?</h2>

The point of the indentation is to indicate the extent of the
subdocument.  This could be indicated instead by changebars, by
different background colors in the client, or by a closing hrule.
Perhaps <b>NoIndent</b> should be an alternative EFFECT?

<h2>Title</h2>

The included documents will usually have a title, which the user
probably wants to see.  I suggest that browsers show the title only if
it is at all different from the link text that led to the included
document.  This is because that link text will still be on the display
at the top of the title.  I would suggest that other information from
the included document's head (if any), such as links, be displayed in
the subdocument's extent just as they are normally shown at the top
(or bottom) of the primary document.

<h2>Client / User-Interface Implementation</h2>

One model for how to display this is the Macintosh System 7 triangles
placed to the left of foldable items.  These look like '&gt;' when
something is folded, and 'V' when it is unfolded.  This model is nice
because it would allow the link text to be separately active as a
hotlink to visit the document on its own page (or in a new window per
browser preference or user mouse-button-choice).  An alternative is to
have the link active in a special way, so that it toggles whether its
subdocument is folded.  This has the disadvantage that it changes the
semantics of a link that might look similar to other links, so the
appearance should probably be different (different color or bold
underline, for example).  I prefer the former (triangle)
implementation, or some other symbol if Apple has the triangle
copyrighted or the mechanism patented.

<h2>Annotations</h2>

This mechanism would provide good support for displaying annotations
in the context of the original document, where the annotations were
also documents in their own right (and thus could be themselves
annotated, etc.)  Note that the annotations *could* be referenced in
the original document, or they could be applied on the server side by
a program that uses a comment map to include them after appropriate
paragraphs, or they could be retrieved by a client from a separate
annotation server and displayed conditionally based on user
preferences and/or group permissions.  In any case, the folding
in-context display capability will be useful whether annotations
appear in the middle of a document or at its end.

<h2>Other Uses</h2>

This folding mechanism would also be useful for code browsers and
taxonomy browsers, where the subdocument is computed by running a
script or program or doing a database query.  Finally, this may be a
good way to present long structured documents as folded tables of
contents.  In fact, certain clients may choose to offer a "folded"
view of a standard HTML document that uses existing HTML document tag
structure to fold sections under their headings, paragraphs under
their first lines, HTML+ figures under their captions, etc.  This
"folded view" capability is independent of the proposed change to the
HTML 3.0 spec, but would be value-added that could leverage off the
browser programming that implements compliance with the proposed
attribute addition.

<h2>Comments</h2>

I invite comments on this proposal to be posted to the www-html
mailing list or mailed to me at <a
href="mailto:torrance@ai.mit.edu">torrance@ai.mit.edu</a>.

<address><a
href="http://www.ai.mit.edu/people/torrance/torrance.html">Mark
Torrance</a> </address>

Received on Tuesday, 26 July 1994 19:41:17 UTC