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 <P> 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 <LI> 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