Re: [css3-lists] Too many list styles and a proposal to simplifythem

> [Original Message]
> From: Jukka K. Korpela <jkorpela@cs.tut.fi>
>
> On Sat, 13 Mar 2004, Ian Hickson wrote:
>
> > There is value in such a generic system -- the problem is that there is
a
> > huge variety of algorithms to choose from. If we introduce this, I'd
like
> > to do so in a version _after_ the current one, since it is of much less
> > value than the predefined keywords,
>
> I would say that a generic system would be _more_ valuable in many ways,
> including definiteness.
>
> It can be a simple one, or a complex one. Or preferably first a simple
> one, later extended. The simplest I can imagine is a system where you
> _enumerate_ characters to be used, e.g.
>
> ol { list-style-character: "a", "b", "c"; }
>
> (or maybe with just spaces and not commas as separators)

Definitely spaces, definitely spaces.

> (The only complexity would be a special kind of inheritance where the
> first child inherits the first value etc. And, if desired, the
> mechanism could be defined so that after the last character specified,
> "aa", "ab" etc. will be used. It takes some effort to formulate this
> rigorously and yet understandably. But it would not be very relevant,
> since any author who wants to specify his way can do it explicitly, as
> long as he knows the length of his longest list, as he should.)

I considered such a extra generic method, but I decided against
proposing it for two reasons.  First, in terms of the already given
list-styles, it didn't describe any of them.  Secondly, lists  that go
on so long usually use numbers rather than letters so specifying
such a style is largely redundant.  However, it wouldn't take much
effort to add another keyword say for example "sequential" so that:
   ol {list-style-type: sequential "ab"}
would have the markers go "a", "b", "aa", "ab", "ba", ....
( Question: Are there any existing style guides that  specify which
behavior should be used with long alphabetic lists?)

> (The values would not be limited to single characters, but I'm following
> the CSS tradition of naming properties misleadingly. :-))
>
> It requires some writing by the author, or some generating program, to
> produce the list for use with long lists. But I don't think it should be
> of primary importance to make it easy to use different alphabetic
> numbering schemes for long lists. And for long lists, the proposed keyword
> values are really problematic. Explicit enumeration is at least a way of
> specifying the "numbers" exactly as desired, as opposite to choosing
> between dozens of predefined schemes that are either loosely defined, or
> defined in a manner that the author disagrees with.

What this boils down to how this affects ease of implementation
as opposed to ease of authoring.

Implementation:
It appears to be agreed that generic methods should be available,
the only disputes that appear to exist are the manner of specification
and the timing of their introduction.  So the only affect on implementation
difficulty is the burden that additional keywords for specific algorithms
would introduce.  It's not much individually.  The coding is not difficult
and encoding each list type should take a rough average of one
hundred bytes assuming either UTF-8 or UTF-16 is used internally
by the UA.  (UTF-8 would need less space for the keywords, but for
most algorithms would need more space for the data.) 50 list types
thus imposes a 5K penalty in storage plus a small timing penalty
due to the fact that determining which valid keyword has been given
will take longer when there are more lists.  The implementation
benefit of not defining keywords for methods that can be defined
by generic methods is therefore small, but obvious.

Authoring:
Authors are likely to use only a few list style types per document.
They are likely to be working with an editing environment that
allows them to input the characters they are interested in directly.
They are also likely to know the contents of the list style type
they are interested in.  The difficulty of knowing how to specify
the type is the same between the two methods.  Document size
will be larger, on the rough order of 100 bytes per list style used.
This can be reduced if short lists are used and the character list
is also shortened to match the maximum length of the lists.  The
burden imposed on an average document is therefore small,
but noticeable.  Judged purely on the performance impact
that is imposed, it is clear that the benefit of keyword usage
is greater the more likely the keyword is used.

The only other impact that has been proposed is that mistaken
entries are less likely to be made with keywords.  I don't agree
with that.  The users of minority algorithms are less likely to be
proficient with the Latin script, whereas they are likely to be
proficient with their own script and the conventions for list marker
sequences used by it.  I don't think errors will be less common
with keywords, but they are more obvious with keywords than
with generic methods.  Even so, a reasonable level of
proofing is likely to discover the error.  Overall the spellings
argument shows a slight benefit for keywords, but not
so large as to argue for keywords for every known style
that can be described in terms of a generic method.

So, what does all this mean?
Common styles should definitely have their own keywords,
even when describable by a generic algorithm.  However,
minority styles or purely historical styles that will be rarely used
should not be given keywords.  This suggests that  most if not all
of the proposed  styles involving the Ethiopian script should be
scrapped.  Usage will be relatively  rare (Even if the prevalence
of computer use amongst users of the Ethiopian script were
approximately the same as users of the Latin script, this would
still be true.) Rather than supporting all those keywords,
a generic method would seem more practical.

The same holds for "lower-norwegian" and "upper-norwegian"
Until the 27th entry, there is no difference between them and
the Latin versions. Lists with alphabetic style and 27 or more
entries and in Norwegian I think are sufficiently rare to warrant
just using  a generic style that requires specifying the 29 letters
for those few that will need it.

Received on Sunday, 21 March 2004 13:15:53 UTC