W3C home > Mailing lists > Public > www-style@w3.org > October 2002

Re: Lists Module Comments (Technical Note)

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 17 Oct 2002 16:53:08 +0000 (GMT)
To: Daniel Yacob <locales@geez.org>
Cc: "kode@hotbox.ru" <kode@hotbox.ru>, "w3@hotbox.ru" <w3@hotbox.ru>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <Pine.LNX.4.21.0210171408050.10805-100000@dhalsim.dreamhost.com>

On Thu, 17 Oct 2002, Daniel Yacob wrote:
> 
> http://www.ethiopic.org/w3c/css/WD-css3-lists-20020220-comments.html

This is a very interesting document. The working group will be
releasing a more recent version of the lists module in the very near
future which already addresses many of the issues you raise, but I
will answer some of your points here.

The first issue you raise is that the CSS3 Lists module does not give
algorithms for each of the numbering systems. This has been corrected
in the current internal draft; every single numbering system has a
complete and comprehensive algorithm detailing the exact mechanism by
which the numbers are to be generated, including exceptions, UNICODE
codepoints, trailing suffixes, and so on.

A side effect of this change is that any new list style types proposed
have to be accompanied by an exact algorithm, in English, detailed
enough that someone with no knowledge of any numbering system, of
UNICODE, or of bidirectionality can implement the numbering system
completely. (All strings are generated in logical order; it is assumed
that a UNICODE bidi algorithm is then applied to the generated
string.)

Unfortunately, you do not provide detailed algorithms for your
cyrillic and ethiopic numbering styles and therefore they cannot be
added to the CSS3 Lists module at this stage. I considered adding the
coptic style, but could not fully understand the provided sample code
from a quick glance, and therefore decided to wait for a more easily
understandable description in English for this style as well.

Having said that, you shall be pleased to know that several ethiopic
systems have been added to the module, including the ethiopic-numeric
system, and your suggested names have been used.

The 'list-style-items' and '@list' ideas are intriguing, but as
proposed they are not powerful enough to describe even some of the
simpler list styles, and making them more powerful would almost
certainly require large burdens on implementations without
significantly helping authors. Similarly, the 'list-style-end'
property doesn't even come close to describing the possible different
systems (it doesn't even differ between the repeating mechanisms of
'lower-alpha' and 'decimal', for instance).

In practice, for simple non-repeating systems such as textual
ordinals, there already exists a solution, as you point out:

   li:nth-child(1)::marker { content: 'First'; }
   li:nth-child(2)::marker { content: 'Second'; }
   li:nth-child(3)::marker { content: 'Third'; }
   li:nth-child(4)::marker { content: 'Fourth'; }

This doesn't solve the problem for counters, which also use the list
style type system, but I think that problem is best addressed in the
context of the 'counter()' expression in the Generated Content module.

Some of your glyph codepoints appear to be incorrect. In partcular,
your codepoints for 'disc' (U+25CF BLACK CIRCLE) and 'circle' (U+25CB
WHITE CIRCLE) are debatable. When preparing the next version of the
spec, I used U+2022 BULLET and U+25E6 WHITE BULLET respectively.
Unfortunately, I could find no square bullets in UNICODE, so I used
the same codepoints as you for 'square' and 'box'.

I have added the binary, octal, and hexadecimal list style types on
your suggestion.

I have added lower- and upper- armenian, however I have conflicting
information for the character(s) to use for 7000. Are you sure that
the 7000 digit (U+0582/U+0552) should be combined with the 600 digit
(U+0578/U+0548)?

I have added the lower- and upper- norwegian styles. The problem about
the trailing '.' suffix being incorrect for norwegian is solved by
explicitly giving the suffix required for each list style type.

Regarding deprecation, I have no intention of deprecating any of the
styles. The glyphs systems ('disc', 'box', etc) are not necessarily
directly mapped to UNICODE; the mapping for these glyphs is only
illustrative. UAs may render the glyphs themselves using custom
painting routines to achieve prettier typographic effects.

Even if the glyphs were directly mapped to UNICODE codepoints, the
list style type keywords are a lot more user friendly than specifying
codepoints on the 'content' property of a pseudo-element.

The same applies to decimal-leading-zero. While it is indeed possible
to use a combination of :nth-of-type, counter expressions,
pseudo-elements and the 'content' property to achieve the same effect,
it is my belief that zero-padding for these values is used often
enough that it deserves a special keyword. The implementation burden
is trivial.

Similarly, while 'text-transfrom' could be used on the ::marker
pseudo-element to change the 'lower-*' types to 'upper-*' types, this
would be less efficient for implementations and harder to use.

The suggestion that we drop 'lower-latin' and 'upper-latin' is
interesting, and may be considered further.

For the other types that you list -- 'hebrew', 'georgian',
'cjk-ideographic', 'simp-chinese-formal', 'simp-chinese-informal',
'trad-chinese-formal', 'trad-chinese-informal', 'japanese-formal',
'japanese-informal', 'arabic-indic', 'persian', 'devanagari',
'gurmukhi', 'gujarati', 'kannada', 'malayalam', 'bengali', 'tamil',
'telugu', 'thai', 'lao', 'myanmar', 'khmer', 'urdu', and 'oriya' --
these types shall all be kept as the current draft now lists complete
algorithms for all of them.

Note that since it is possible that the marker pseudo-element will be
re-used for footnote, endnote, and other markers, it is currently back
to being named '::marker'.

Finall, regarding profiles, the issue has not yet been fully
investigated. It is likely that the module will not provide any
explicit profile for different media beyond the existing CSS1 and Full
profiles. The CSS Mobile Profile specifiction may be updated or
re-released at a future date with further CSS3 values, but this is out
of scope of the CSS3 Lists module.

Thank you very much for your input, it is greatly appreciated. I look
forward to reading your comments once the next version of the CSS3
Lists module is released, which should occur within one or two weeks.

Cheers,
-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 17 October 2002 12:53:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:16 GMT