On 19 Jul 95 at 10:00, [email protected] 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">[email protected]</ADDRESS>
(to steal an oft quoted example of the use of the SGML name tokens)
than
<ADDRESS class="purplefontgreenbackground">[email protected]</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:[email protected]