- From: Chris Tilbury <C.J.Tilbury@estate.warwick.ac.uk>
- Date: Thu, 13 Jul 1995 17:41:20 BST
- To: www-html@www10.w3.org
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 <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
Received on Thursday, 13 July 1995 12:42:04 UTC