Re: Proposal For Outline Markup Scheme For HTML 3.0

Since it's my rather quickly baked up modification of the list 
mechanisms which is being defined at present, I suppose I should 
contribute something to the debate ;-)

On 19 Jul 95 at 10:00, bstiller@prism.nmt.edu wrote:

> Outline-style lists would seem to me to be entirely a presentation
> issue. For example, collapsed lists might be specified like this:

[snip] (example deleted).

What this doesn't address is something I attempted to take on board 
from the original proposal, and which would be difficult, nay perhaps 
impossible and/or inappropriate, to implement purely using stylesheets.

Keith and his collegues proposal, whilst being basically a list at 
heart, did have one element which is missing from the current list 
metaphors, one which served effectively as a 'List Item Header'. 

Although I originally came out quite strongly against adding further 
elements, when I attempted to consider a mechanism to somehow 
implement these Item headers using stylesheets, I found myself asking 
the following questions:

1.	Is it possible, or even practical, to attempt to subclass another 
    element with some kind of standard SGML name token which 
    indicates that it is the header for the list item.

and, most importantly,

2.  Is it in fact necessary to do the above, when there is possibly 
    quite a strong argument in favour of being able to actually have 
    not only a header at the overall list level, but also a header at 
    the item level and that such a header would be not merely a 
    presentational construct, but a fairly worthy content orientated 
    one at that.

The answer to the first question is No, and a pretty unequivocal No 
at that. Yes, we could have

<LI><P class="item.header">Item Header</P>
    <P class="item.entry">This is the text</P></LI>

But the astute amongst us will notice that since we can have as many 
<P>'s as we want in <LI>, we'd probably end up using <DIV>, or 
something similar, which is really intended for much larger divisions 
in a document.

So, if it's not really practical to use classes to identify (what 
are, after all pretty strong) structural elements in this fashion, 
then we'd need to add a new element to the List Item structure.

So, I then (briefly) considered what would probably happen to 
existing "legacy" browsers, if they were presented one day with

<OL>
<LI><IH>This is the Header.<IH><P>This is the Item Text</P></LI>
</OL>

And the conclusion that I came to is that the "generosity" with which 
they are supposed to treat what they could consider as bad HTML would 
either render this as

1.     This is the Header. This is the Item Text

or, more likely

1.     This is the Header.
       This is the Item Text

(since the <P> would be interpreted, quite correctly, as commencing a new 
paragraph, and by definition, closing the prior one inferred by the 
presence of %text between LI and the new opening P - remember that 
the IH tags should just be ignored.)

So, given that I believe some kind of item header would be a proper, 
"structural", element, and therefore consistent with the principles 
guiding the development of HTML, I felt that it would be appropriate 
to suggest that this be modified as an alternative to introducing a 
whole new set of elements for outlined lists.

I next want to consider just how we intend to use the class 
attribute. I've not been on the www-html list for long, but as people 
who read my earlier posts on the subject of alternative media 
representations for table data (i.e, drawing charts instead of 
tables!), I have argued (or at least inferred) in the past that there 
are occassions when using the class attribute for some kind of purely 
presentational descriptor is almost as bad as having added a 
presentational tag to the spec. Better to use

<ADDRESS class="internet.email">Chris.Tilbury@estate.warwick.ac.uk</ADDRESS>
(to steal an oft quoted example of the use of the SGML name tokens)

than 

<ADDRESS class="purplefontgreenbackground">Chris.Tilbury@estate.warwick.ac.uk</ADDRESS>

if for no other reason than that HTML is such a massively generic 
application of SGML that people wishing to more descriptively markup 
their content (in this I include myself) will or may want to use the 
class tag for content orientated purposes rather than purely 
presentational ones.

Likewise, I'm not so sure, when we consider how generic HTML is, as 
to whether using 

<UL class="outline.expanded">
<LH>This is a complete recursive directory of drive D:</LH>
<LI><P>COMMAND.COM, 50k</P></LI>
<LI><IH>DOS</IH>
    <UL class="outline.unexpanded">
    <LI><P>QBASIC.EXE</P></LI>
    </UL></LI>
</UL>

is actually "better" HTML than using

<UL OUTLINED class="disk.directory.listing">
<LH>This is a complete recursive directory of drive D:</LH>
<LI class="disk.file"><P>COMMAND.COM, 50k</P></LI>
<LI><IH class="disk.directory.entry">DOS</IH>
    <UL class="disk.directory.listing">
    <LI class="disk.file"><P>QBASIC.EXE</P></LI>
    </UL></LI>
</UL>

What I believe we need to think carefully about is at which point in 
HTML do we consider something to be too "presentationalish" to 
implement.

I could, IMHO, make quite a case for the abolishment of both OL and UL, 
to be replaced with LIST, on the grounds that whether a list of items 
is identified as such by the presence of numeric label, or the 
presence of some kind of graphical 'dingbat' or other non-sequenced 
character, is a purely presentational issue and is as such not 
relevant to HTML.

However, playing devils advocate, there is an almost equally strong 
argument to the contrary - that being, that the fact that a list's 
items are delimited by numbers indicates that there is some kind of 
inherent "sequence" or "order" to those items, whose meaning would be 
lost or confused if they are read in any other order; whereas the 
fact that a list's items are delimited by some kind of "bullet" 
indicates that no such firm relationship exists, and the order in 
which the items are listed is less if at all important, in 
structural terms.

Similarly with expandable/collapsible lists. The fact that an item in 
a list can be "expanded" could indicate that there is additional, but 
not immediately essential, relevant information contained within that 
item (something which a UL within UL within UL does not perhaps put 
across). This could be used to great effect, perhaps even in 
non-visual environments where ceaslessly reading list upon list upon 
list embedded within each other would almost certainly be less 
effective than having some kind of indication of what the top level 
"subjects" might be, before moving on to one of these depending on a 
choice made by the user. So, in some small way, the issue of 
"expandability" of outlined lists could have some information content 
to put across - and a good deal more than TABLE's BORDER attribute, 
the ALIGN attribute, and a number of other elements which have made 
their way into the HTML 3 draft (although I know full well that just 
because it's got some dubious elements in it is no reason to add even 
more).

So, after this rather long message, where do I stand? Well, not that 
far from where I stood originally, although Keith's points on 
changing the use of LH and using CAPTION instead for a list header is 
something I agree with, if only to give more consistency between our 
"labelling" of things, be they lists, tables or figures.

Also, upon reflection, since my original modified proposal already 
calls for an attribute to indicate whether a list is 'outlined' or 
not, but provides no "hints" as to whether to expand or contract a 
sub level by default, I would also perhaps suggest that we consider 
adding two "states" to this attribute to give this hint, along the 
lines of

   <UL OUTLINE="expanded">

or

   <UL OUTLINE="collapsed">

although I am very much in two minds as to whether this would tip 
the balance against such a proposal being accepted, as the values are 
very much presentational in nature (although no more so than the 
ALIGN= values, of course).

Comments (assuming you made it this far!) are most welcome.


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 Wednesday, 19 July 1995 13:34:31 UTC