- From: Gerald Oskoboiny <gerald@cs.ualberta.ca>
- Date: Wed, 11 Oct 1995 19:27:46 -0600 (MDT)
- To: www-style@w3.org
Evan Kirshenbaum writes:
> o I think that it is going to be necessary to add at least
> rudimentary numbering style for lists to level one. People keep
> asking "how do I get unbulleted lists", "how do I substitute my
> own URL for the bullet", etc. With HTML 3 now pretty much
> officially dead, it is unclear when the extra attributes on UL,
> LI, etc. will be added, and they clearly belong in a style sheet
> anyway.
I agree. If this isn't included in level one, it should at least be
specified in more detail in the "Suggested level 2 properties" section
(currently, Appendix B).
Recently on the lynx-dev mailing list, there was a proposal [1]
for adding/expanding a TYPE attribute on the <OL> tag to achieve
different numbering schemes and punctuation. If there isn't some way
to achieve the same thing with style sheets, it will be difficult
for me to convince the Lynx guys to abandon the <OL> method in favor
of a style sheet method (no matter how rough the consensus on the
specific syntax used for this in style sheets).
I think Evan's suggestion:
> Perhaps something like
>
> number-form = uppercase alpha | lowercase alpha |
> uppercase roman | lowercase roman |
> decimal |
> url : <url> |
> char : <char>
>
> or perhaps better
>
> number-pattern = <pattern>
> number-url = <url>
>
> where <pattern> is a string substituting "%A", "%a", "%I", "%i",
> "%1", "%u" for the above. This would allow specifying things like
> "(%1)" or "%a.". It would also allow the i18n extension to
> "%א" to number in Hebrew, etc. once 10646 is accepted as the
> document character set.
achieves the desired effect much more elegantly than the proposed <OL>
enhancement, which follows:
(from [1]):
| From: Walter Skorski <walt@clyde.jmp.tju.edu>
| To: lynx-dev@ukanaix.cc.ukans.edu
| Subject: Re: <OL TYPE="A">
| Date: Mon, 2 Oct 1995 15:26:52 -0400 (EDT)
|
| On Fri, 29 Sep 1995 13:29:12 -0500 (CDT),
| In message <199509291829.NAA23225@cs1.bradley.edu>,
| (archived as <http://lynx.cc.ukans.edu/lynx-dev/9509/0185.html>,)
| David Henderson <davidh@cs1.bradley.edu> wrote:
|
| DH> Hello all! I haven't seen this topic mentioned (via the Web archive,
| DH> <URL:http://lynx.cc.ukans.edu/lynx-dev/>) recently, so I guess I'll
| DH> ask it here:
|
| That's not really true, because -
|
| On Mon, 18 Sep 1995 10:48:06 -0700 (PDT),
| in message <Pine.SOL.3.91.950918101716.29727B-100000@trex>,
| (archived as <http://lynx.cc.ukans.edu/lynx-dev/9509/0085.html>,)
| "John P. Kerti" (johnk@Kwantlen.BC.CA) wrote:
|
| JK> Over the past few months we have been working on converting existing
| JK> paper documents for Web access. One probelm we ran into was the use of
| JK> multi-level numbering in our College Policies & Procedures. The
| JK> numbering in MSWord is as follows:
| JK>
| JK> 1) First Level List Item
| JK> a) Second Level List Item
| JK> b) Second Level List Item
| JK> i) Third Level List Item
| JK> ii) Third Level List Item
| JK> c) Second Level List Item
| JK>
| JK> [...] My question is, has anyone thought of incorporating code to handle
| JK> this sort of thing in Lynx?
|
| So, David, you're not alone in wanting this. I want it too - er,
| three ;-), but I kept my mouth shut about it so far. As soon as
| 2-4-FM has this, I'm upgrading.
|
| DH> Yes, this is a Netscapism, but it's one that I think would make
| DH> a good addition to Lynx.
|
| I've been thinking about this, and it may be possible to go Netscape
| one better. (Hey, since we're dealing with nonstandard standards as
| it is, why not? If Netscape can do coding first and standardization
| later, why can't Lynx?) Consider:
|
| : What if the user (HTML writer) intends the style of numbering that
| the military (and computer programmers :-) are fond of? I.e.:
|
| 1. Level one
| 1.1. Level two
| 1.2. Level two
| 1.2.1. Level three
| etc.
|
| : What if the user decides he doesn't like things ending in periods?
| I.e.:
|
| A) A: A- A.
| B) or B: or B- or whatever, instead of B.
| C) C: C- C.
|
| : What if the user (accidentally or intentionally) puts more than 26
| items in a TYPE="A" or "a" list? How should this behavior be defined?
| I see two ways to go - either "double a", "double b", ... "triple a",
| etc., or "aa", "ab", "ac", etc. The former gets unwieldy quickly, but
| is the more common usage among noncomputer types; the latter allows
| for 676 entries before requiring more than two letters, but is
| commonly perceived as confusing.
|
| Proposed solution:
|
| ORDERED_LIST_TYPE : OPT_PUNC_PREFIX TYPE_DEFINER OPT_PUNC_SUFFIX
| OPT_PUNC_PREFIX : /* null (default) */
| | NONALPHANUMERIC_CHAR OPT_PUNC_PREFIX
| /* optional: NONALPHANUMERIC_CHAR could
| * either be specified explicitly, or simply
| * defined as anything that's not a
| * TYPE_DEFINER.
| */
| TYPE_DEFINER : "1" /* 1, 2, 3, 4, 5, ... */
| | "A" "A" /* Z, AA, BB, CC, ... */
| | "A" "B" /* Z, AA, AB, AC, ... */
| | "A" /* synonym for "A" "A" (unless you throw
| * in yet another config option :-)
| */
| | "a" "a" /* z, aa, bb, cc, ... */
| | "a" "b" /* z, aa, ab, ac, ... */
| | "a" /* synonym for "a" "a" */
| | "I" /* I, II, III, IV, ... */
| | "i" /* i, ii, iii, iv, ... */
| OPT_PUNC_SUFFIX : /* null, synonym for "." */
| | NONALPHANUMERIC_CHAR OPT_PUNC_SUFFIX
|
| The output of the ordered list sequencer would be exactly as expected
| for "1", "A", "a", "I", and "i", but adds other more versatile
| options. Any suffix (e.g. "A:") is assumed to supercede the period as
| terminator; "AA" or "AB" determines how >26 would be handled; and any
| prefix indicates to prepend the previous level(s) to this level's
| sequencing, and also to supercede the previous level's suffix. To
| give a highly improbable example:
|
| <ol type="I-">
| <li>Level one item one
| <ol type="/AB:">
| <li>Level two item one
| <ol type=".1">
| <li>Level three item one
| </ol>
| <li>Level two item two
| <ol type ",aa=">
| <li>Different level three, item one
| <li>...
| <li>Different level three, item twenty-eight
| </ol>
| <li>Level two item three
| <li>...
| <li>Level two item twenty-eight
| </ol>
| <li>Level one item two
| </ol>
|
| would result in:
|
| I- Level one item one
| I/A: Level two item one
| I/A.1. Level three item one
| I/B: Level two item two
| I/B,a= Different level three, item one
| I/B,b= ...
| I/B,bb= Different level three, item twenty-eight
| I/C: Level two item three
| I/D: ...
| I/AB: Level two item twenty-eight
| II- Level one item two
|
| On Mon, 18 Sep 1995 19:24:40 -0400 (EDT),
| in message <01HVFKE07B32000AIB@SCI.WFEB.EDU>,
| (archived as <http://lynx.cc.ukans.edu/lynx-dev/9509/0093.html>,)
| Foteos Macrides <MACRIDES@SCI.WFEB.EDU> wrote:
|
| FM> HTML 3.0 has <OL CONTINUE> and <OL SEQNUM="#"> (where "#" is a
| FM> decimal number). The CONTINUE attribute causes the numbering to continue
| FM> from that of the higher OL level in the nest. [...]
|
| I'm a little confused. I made up a little test file for <ol continue>
| and ran it thru a machine running Netscape (which version I couldn't
| say), and got no visible result. Could you elaborate on exactly what
| this option is supposed to do?
|
| FM> HTML 3.0 also has <UL PLAIN> (also implemented in the Lynx2-4-FM
| FM> code set) which elininates bullets altogether, and would allow you to
| FM> do your own a versus i stuff explicitly as part are the LI string (with
| FM> to enforce multiple spaces for alignments within nest levels).
|
| (Oops - I didn't consider spacing in my example above.)
|
| While we're at it, why not add <ul type="foo">, to let the user
| specify the bullet character(s) without having to do the grunt work?
|
| On Fri, 29 Sep 1995 15:13:46 -0400 (EDT),
| in message <01HVUP15Q2IG0006DX@SCI.WFEB.EDU>,
| (archived as <http://lynx.cc.ukans.edu/lynx-dev/9509/0186.html>,)
| Foteos Macrides <MACRIDES@SCI.WFEB.EDU> wrote:
|
| FM> The problem I ran into is coordinating it with the existing
| FM> HTML 3.0 CONTINUE and SEQNUM attributes (which are implemented in the
| FM> -FM code set). My thought was to add a flag, with default TYPE=1, and
| FM> keep using numbers in the counter arrays, but check the flag for whether
| FM> to use an Arabic number, or Roman, or alphabetic characters at time of
| FM> screen output. Those could be in a tables analogously to the entity
| FM> conversion tables, and thus be handled quite fast.
|
| Hmm. How far do you intend to go with the table, and what if the HTML
| exceeds the table's limit? I don't know the speed issues involved,
| but I tend to think an algorithm is a better way to go here. I do
| agree that the internal representation should always be numeric, tho.
| ("Quick - what's XLIV plus one?" I don't think so.)
|
| P.S. to Craig: I *really* like the archive - now I can clean out my
| mail directory! Plus, I can refer people to the archive in replies
| for anyone who wants to read the whole original message! BTW, any
| chance you can hack the ListProc to add an "X-Archived-As:" to the
| header before received messages get distributed, or do you send first
| and archive later?
|
| --
| . iksrokS retlaW<>Walter Skorski .. walt@spot.jmp.tju.edu .
| Computer Administrator, Div. of Medical Genetics, Thomas Jefferson University
|
Gerald
[1] http://lynx.cc.ukans.edu/lynx-dev/9509/0205.html
--
Gerald Oskoboiny <gerald@cs.ualberta.ca> http://ugweb.cs.ualberta.ca/~gerald/
Received on Wednesday, 11 October 1995 21:28:14 UTC