[css3-lists] Specifying new list-types

Heya all.  We discussed at the FtF that I'd be taking over editorship
of the CSS3 Lists module.  I'll be doing some cleanup and
clarifications to make everything good and accurate, but I wanted to
discuss one particular relatively large change I was planning to make,
which I mentioned offhand during the ftf.

Right now, the module has a long list of various list-types.  From
what I understand a lot of these were just added because Hixie *could*
(binary?), rather than any specific use-case, but I believe that many
of them truly are quite useful.

Nearly all of these list-types use a small set of simple behaviors to
define themselves.  This behavior can be extracted and given a little
bit of syntax, and then used to define the list-types directly in UA
style-sheets.

This has a few benefits.  First, this unifies the definition of all
the list-types in a machine-readable manner, making mistakes in
implementation much less likely.  Second, this exposes the essential
machinery of list-types to authors, who can then use it very simply to
define lists of *any* type.  For example, some time ago an author
requested that we add to the module a particular list-style used by
Microsoft Word, where the list proceeds as "A B ... Z AA BB ... ZZ AAA
BBB ...".  This is very trivial to specify as a symbolic list-type
that uses the letters A-Z as the symbols.  If this can be done by
authors, it removes a lot of the impetus on us to search out and
define necessary list-types.  Third, it allows the less-important list
types like binary to be represented with basically no implementation
effort - once an impl has put together the machinery to parse a
list-style declaration, adding binary to the browser is just a matter
of copying one more declaration from the spec to the UA style sheet.

A basic declaration would look like this:

@list decimal {
  type: numeric;
  glyphs: 0 1 2 3 4 5 6 7 8 9;
  suffix: ".";
}

In my current writeup, there are 7 values for 'type', each
corresponding to a group of list-styles in the current draft.

numeric - The list uses the provided glyphs in order, then composes
new markers according to the 'numeric' algorithm as specified in the
spec.  (The first glyph is a zero value, which means the first marker
used in most situations is actually the second glyph provided,
corresponding to the value of 1.  Binary numeric would go "1 10 11 100
101 110 111 1000...")

alphabetic - Same as numeric, but it composes new markers using the
'alphabetic' algorithm.  (No zero value - the first marker generated
after running out is just a double of the first glyph, then the first
and second, first and third, etc..  Binary alphabetic would go "0 1 00
01 10 11 000...")

symbolic - Same as numeric, but it composes new markers using the
'symbolic' algorithm. (When you run out, just cycle through the glyphs
again, using gradually higher multiples of the glyph. Binary symbolic
would go "0 1 00 11 000 111 0000...")

"string" - Just use the provided string as the marker for all values.
(This allows you to specify arbitrary characters as bullets for
unordered lists, which has been requested by authors.)

non-repeating - Use the provided glyphs in order.  Don't synthesize
new markers when you run out, just fallback to whatever the fallback
list-type is.

additive - Basically, the greedy roman numerals algorithm.  Rather
than just giving a list of glyphs, you have to give a list of
glyph/weight pairs, with the weights in descending order.  Grab the
first glyph you can who's weight is under the value you're trying to
synthesize, and append it to the marker-so-far.  Subtract the glyph's
weight from the target value, and start over.  This is actually useful
for a lot more than just roman numerals - several of the
language-based list-types currently sitting in the "algorithmic"
section (armenian, for example) are just simple additive systems.

cjk - The cjk algorithm.  I believe the constraints needed to specify
this from the bottom-up are too complex, so instead I'm just
addressing it as a special-case.  There are a bunch of list-types that
all use this same pattern but with different glyphs, so it's
worthwhile.

If I recall correctly, these seven types cover *every* list-style type
currently in the spec* except for ethiopian-numeric (listed in the
'algorithmic' section, confusingly).  I don't know if that type is
important enough for us to truly care about and just establish as the
lone special "algorithmic" type that is defined only by the spec, not
by an @list block, or if we should just drop it.  I can go either way.

It also doesn't quite cover the meaning of the "glyph" types in the
current module, which defined a specific named shape which can be
presented either by an appropriate character, if the system has a
supporting font on it, or just synthesized directly by the UA.  These
should just be special-cased to achieve this - authors can use the
string type to provide their own versions if they know a particular
character they want for a bullet, for example.


There are a few other properties allowed in @list for completeness.
The 'additive-glyphs' and 'cjk-glyphs' properties are alternatives to
'glyphs' with a different syntax specialized for those types.  The
'range' property lets you specify a particular range of numbers that
the list-type is designed for; outside of that range it uses the
fallback type instead (this is especially necessary for the additive
types - trying to synthesize 1e20 with roman numerals will kill the
browser as it attempts to generate a hundred terabytes of "M"s).
Finally, the 'fallback' property lets you specify the name of another
list-type to be used when the current type can no longer synthesize
glyphs, either because the value is outside its range or you're using
a non-repeating type outside its defined range.

Thoughts?  Objections?

~TJ

* Though feedback that Sylvain passed on a little while ago states
that there is a difference in how cjk lists are numbered in formal and
informal contexts, so there may need to be an additional type for
that.

Received on Wednesday, 8 September 2010 21:19:43 UTC