(no subject)

John C. Mallery (JCMA@ai.mit.edu)
Mon, 12 Dec 1994 03:33:59 -0500


Message-Id: <9412120857.AA15906@dxmint.cern.ch>
Date: Mon, 12 Dec 1994 03:33:59 -0500
To: patrick@voyager.gate.net,
From: JCMA@ai.mit.edu (John C. Mallery)
Subject: Re: 

At  4:50 PM 12/11/94 +0100, Patrick Stickler wrote:
>>From patrick@voyager  Sat Dec 10 10:06:52 1994
>Received: by voyager.gate.net (4.1/SMI-4.1)
>        id AA23263; Sat, 10 Dec 94 10:06:52 +0100
>Date: Sat, 10 Dec 94 10:06:52 +0100
>From: patrick@voyager (Patrick Stickler)
>Message-Id: <9412100906.AA23263@voyager.gate.net>
>To: www-html@www0.cern.ch
>Subject: Re: HTML 3.0 list DTD
>
>
> > From: michaelj@relay.relay.com (Michael Johnson)
> >
> > I'd like to suggest some changes to the DTD for lists just to clarify things
> > a little:
> >
>
>It might be far too late to change, but would it be possible to redefine
>(fix) the HTML lists altogether by defining a single structure <L> (list)
>which may be indexed (i.e. "ordered"), bulleted, dashed, etc. and if indexed,
>then with a particular type of ordinal (arabic numberal, roman numeral,
>lowercase alpha, uppercase alpha, etc.).
>
>After all, what is an "unordered list" (<UL>)? Is the browser at liberty to
>display <UL> list items in any arbitrary or random order?! And what is the
>structural difference between indexed lists and bulleted lists. Nothing
>other than whether their linear ordering is presented incrementally or
>statically (which is formatting, not structure).
>
>Comments?

Good idea.

There are a number of areas in HTML that need the abstractions consolidated.

Such consolidation will not only make the mark up cleaner and easier to use but
it will also make the implementations more transparent.  I collapsed a number of
tags into a variety of higher level abstractions in my HTML generation code.

Another candidate are the various rendition tags <b>, <i> ....

Of course,  there is now a backward compatiblity problem if 2.0 is to be
subsumed
by 3.0.

One way around this is to introduce the idea of obsolete tags.  An obsolete
tag must be
supported by conforming implementation BUT it will be phased out in a
future version
of the specification.  Implementation should use the new tags at all times
and provide
a means for warning when old tags are found in user markup.