While reading Chris' proposal, please keep in mind the following. The
presence of the <LH> tag could obviate the need for IH as proposed by
Chris.
Chris wrote...
[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?]
Our response to that would be to suggest that <LH> be used for the purposes
that we have requested and that <CAPTION> be used as the current <LH>
does.
The LH's of nested lists can serve in place of IH. Our other modification
would be to allow the specification of a level to which expansion should
initially occur by providing a value for OUTLINED, e.g. OUTLINED=2 would
expand to the second level. We feel that relegating outline expansion
levels to a style sheet could result in an uneccessary proliferation of
style sheets. Also, the presence of an OUTLINED value would serve two
purposes; specification of a level, and the specification of the list into
collapsable form.
The beauty of Chris' approach is that any browsers which do not support
accordian/outline text would simply display the outline as fully expanded.
As would OUTLINED=0.
Finally, we once again propose that the specification indicate that
implementers should provide for automatic outline expansion when an attempt
is made to jump to an "unexpanded" anchor.
So, how about it? Can we add just one attribute to the existing HTML 3.0
markup for lists? Please! :-)
What is our next step for requesting this feature? Should we re-write our
proposal using this modified design?
Chris' redesign...[snip]
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[cut]
Keith Rettig (krettig@ctt.bellcore.com) Simon Blackwell (simonb@ctt.bellcore.com)
Keith Rettig Do Something! \\\\ KRettig@ctt.bellcore.com (@ @) ------------------------------------------------ooO-( )-Ooo-----