Re: [css3-lists] Specifying new list-types

On Wed, Sep 8, 2010 at 3:53 PM, Belov, Charles <Charles.Belov@sfmta.com> wrote:
> Tab Atkins Jr. wrote on Wednesday, September 08, 2010 2:19 PM
>
> (various snips here and there)
>
>> 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.
>
> Basically, I like this, provided I can declare multiple list
> formats to support varying list schemes that I encounter in my
> work and which might co-exist on the same page.
>
> I'm guessing
>    @list [name] {
> ...
>    }
> handles that by letting me specify different names in different
> declarations.

I'm not sure what you mean.  I *think* you're asking if you can put
several different @list blocks in your page to declare several
different list type?  If so, then yeah.  Use as many @list blocks as
you want.


>> 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
>> ...".
>
> That would be me.

Ah, cool.  I didn't want to go to the effort to look up that email.


>> 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: ".";
>> }
>
> With regard to glyphs, are they space-delimited? Would it be possible
> to specify multi-character "glyphs," including those that include
> spaces, e.g.,
>
>    glyphs: zero one two three four five six seven eight nine;
>    infix: " ";
>    suffix: ".";
>
> to produce a list:
>
>     one.
>     two.
>     three.
>     four.
>     five.
>     six.
>     seven.
>     eight.
>     nine.
>     one zero.

Yes, they're space delimited.  Right now I'm thinking that you can
just supply the character(s) directly if they fit certain rules
(probably just "whatever makes an ident, and also numbers"), and you
can use strings instead if you want anything outside of that.
However, I might just say you always have to use strings, for
simplicity.  I can go either way based on what implementors prefer.


> As well as "prefix" which would allow for:
>
>    prefix: "(";
>    suffix: ").";
>
> This is just an example for illustration -- I can think of
> marketing uses, but those aren't usually composed in HTML --
> but there may be legitimate use cases for multi-character
> glyphs, such as Hebrew numbering.

Oh, yeah, forgot to mention the prefix property.  Yeah, I'm throwing
that in there precisely for the use-case you're pointing out:

@list paren-decimal {
  type: numeric;
  glyphs: 0 1 2 3 4 5 6 7 8 9;
  prefix: "(";
  suffix: ") ";
}

Which will produce:

(1) The first item!
(2) The second item!
(3) The third item!

(There's currently a parenthesized-decimal list-type in the Lists spec
which will just be ported over as a non-repeating type, but it uses
actual Unicode characters.  It boggles my mind that these exist.)


>> 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.)
>
> This presents potential issues for screen-reader software.

How so?


>> 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.
>
> What about repeating?  Binary would go "0 1 0 1 0 1".

Is there any real need for repeating?  It's an easy thing to do, but I
don't think I've ever seen a repeating list marker used in the wild.

~TJ

Received on Wednesday, 8 September 2010 23:49:20 UTC