Re: Proposal for an Outlining Markup Scheme For HTML 3.0

I wrote:
> "I think I'd be inclined to agree with Brian here. We already have a
> mechanism for creating lists, ordered or otherwise, and for creating
> entries within these lists, and encapsulating further lists within
> these entries. {snip snip} We already have three list metaphor
> elements within the DTD, <OL>, <UL>, and <DL>. Another would be
> unnecessary, IMHO."
 
In response, on the 13 Jul 95 at 10:34, KRetting@ctt.bellcore.com wrote:
> We disagree.  Sure there are already several metaphors (these
> metaphors are only a subset of the possibilities) being used by HTML
> 3.0, but one of the goals of HTML is to provide the greatest
> capability with the least codes. We feel that our proposal provides
> many new functions with a limited set of additional codes.  These
> functions include outlining a book, heirarchical representations of
> information spaces, non-hierarchical representations of information
> spaces, and a plethora of capabilities that centers around the
> ability to dynamically reveal text at the will of the user. All
> while keeping network reconnects and transactions to a minimum.
> However, we are certainly interested in seeing a proposal which
> could make use of existing tags, i.e. OL, and "wrap" them in some
> kind of outline mark-up so as to produce the effect we desire.  We
> tried this and failed. [See we aren't as smart as we think! :-)]

Before we embark any further, I'd like us all to consider these 
issues, which I feel are a rather important when discussing any new 
proposals.

The proposal as set out introduces the following new elements,

<OUTLINE>	Which would contain the outlined list.
<OH>		Which would contain each outline "header"
<OT>		Which would contain the outline "text"

Let's look at how these compare with elements already present in the 
HTML 3 draft[1]. Obviously enough, we have no <OUTLINE> element. The 
closest we can come to is one of

<OL>, <UL>, or <DL>

both of which generate lists of one form or another, and which all
have the capability to be nested within each other (although how <DL>
should behave when nested is rather unclear, since the "concept" of a 
definition does seem to rule out having further definitions within 
it.)

The next comparison comes between <LH>, the "List Header", and "OH", 
the "Outline Header". There is, however, an important different here. 
Whilst <LH> is designed to occur once within a list, like a caption, 
in the proposal made here, <OH> can be expected to appear multiple 
times. In fact, <OH> bears a far greater similarity to <LI> than it 
does to <LH>.

[Incidently, does anyone know why we've got <LH> to provide a caption 
 in a list, and <CAPTION> to provide a caption on everything else? 
 Yes, I know <LH> is supposed to put the header at the top of the 
 list, but isn't this just a presentation issue?]

What we don't appear to have is an equivalent to the <OT> item, 
except for <DD> in a definition list - since the exact behaviour of a 
cascaded <DL> is rather undefined (do not the natures and semantics, 
if not syntax, of a definition list item rule out further definition 
lists within itself?), even this is a rather tenuous comparison.

The first important point I feel should be mentioned is that some of 
these terms play quite distinct roles, but seem very similar. More 
than anything else, HTML should be simple and easy to use. 

I can see a certain degree of confusion arising between, <LH> and 
<OH>, the former representing a header, the latter representing 
something more like an item <LI>; as well as between <OT>, which 
represents descriptive text for it's preceeding header, and <DT> in a 
Definition list, which more resembles <OH> (or <LI>).

I would next like us to consider how legacy /browsers/ could handle these 
types of lists. Much is often said of attempting to ensure that 
browsers can handle legacy /documents/, but (worringly?) little 
thought sometimes appears to be given to how older browsers will 
handle modern documents.

Let us assume, for now, that we proceed with the <OUTLINE> element 
and associated components. Take an older browser, and what you'll 
have displayed would probably be a mess, and depending on the 
complexity of the outline, it could be a very large and confusing 
mess. One of the major advantages of attempting to non-destructively 
modify an existing element, or group of elements, would be that 
legacy browsers would display the information in a "basic" format, 
whilst the newer browsers would display it more fully.

The list elements are a good example of how may be able to manage 
this. If we are careful, we could develop a method of producing 
outlines that would work on both browsers capable of producing the 
collapsable/expandable view, as well as on older browsers, which 
would just render the outline in it's "most expanded" format.

So, how can we achieve this? Well, how about something like this.

<OL OUTLINED>
 <LI>
  <IH>This is the top outline level</IH>
  <P>This is the text below the header. In an Ordered or Unordered 
     Outlined list this would not be displayed until the header was 
     expanded. The enclosing of this text in the &lt;P&gt; element 
     would ensure that the text would hopefully be displayed 
     beneath the header on older, legacy browsers</P>
      <UL OUTLINED>
       <LI>
         <IH>This is the next outline level</IH>
         <P>This is the text describing it; again, note that since 
            the content.model of the &lt;LI&gt; element is flow and 
            flow includes lists, one can include multiple levels of 
            outline without extra tags being required.</P>
       </LI>
 </LI>
</OL>

Which could display as

[-]  1.    This is the top outline level

           This is the text below the header. In an Ordered or Unordered 
           list this would not be displayed until the header was 
           expanded. The enclosing of this text in the <P> element 
           would ensure that the text would hopefully be displayed 
           beneath the header on older, legacy browsers.

[+]        *   This is the next outline level

on an "intelligent" browser, as

1.    This is the top outline level

      This is the text below the header. In an Ordered or Unordered 
      list this would not be displayed until the header was expanded. 
      The enclosing of this text in the <P> element would ensure that 
      the text would hopefully be displayed beneath the header on 
      older, legacy browsers.

      *    This is the next outline level

           This is the text describing it; again, note that since the 
           content.model, of the <LI> element is flow and flow 
           includes lists, one can include multiple levels of outline 
           without extra tags being required.

on a less intelligent one.

Compared with the proposed scheme, this requires 1 additional 
element, <IH>, for Item Header:

   IH (Item Header)

   Permitted Context: Immediately following LI
   Content Model: %text

A single modification to the LI specification[2], which should not 
affect the rendering of existing lists in any way whatsoever:

   LI (List Item)

   Permitted Context: UL or OL
   Content Model: Optional Item Header (IH), followed by %flow

And the addition of a single attribute to the OL[3] & UL[4] 
specifications

   OUTLINED
     The presence of this attribute indicates to the user agent that 
     this is an "outline" list. Outline lists should be rendered as 
     an expandable/collapsable list, with the initial view of each 
     <LI> being simply the Item Header (IH) if present; otherwise, 
     the specific item should be non-expandable. User Agents should 
     provide an appropriate mechanism for expanding or contracting 
     each LI to display it's full content - in the case of visual 
     browsers, this could be by clicking on the numbering or dingbat 
     identifying the list item (which can be specified in <LI> using 
     the SRC or DINGBBAT attributes).

Personally, this is the absolute limit which I would feel could be 
encompassed within the markup without encroaching on completely
presentational issues (which I think all of this is, anyhow). 
Anything further, including indicating which levels should be 
expanded initially, and which shouldn't, should live in stylesheets.

References:

[1] <URL:http://www.hpl.hp.co.uk/people/dsr/html/CoverPage.html>
[2] <URL:http://www.hpl.hp.co.uk/people/dsr/html/listitem.html>
[3] <URL:http://www.hpl.hp.co.uk/people/dsr/html/seqlists.html>
[4] <URL:http://www.hpl.hp.co.uk/people/dsr/html/bulletlists.html>

Regards,



Chris

--
Chris Tilbury, Estates Office, University of Warwick, UK, CV4 7AL
Tel: +44 1203 523523 x2665                   Fax: +44 1203 524444
MIME mail welcomed      mailto:Chris.Tilbury@estate.warwick.ac.uk

Received on Thursday, 13 July 1995 12:42:04 UTC