W3C home > Mailing lists > Public > www-style@w3.org > September 2010

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

From: Belov, Charles <Charles.Belov@sfmta.com>
Date: Wed, 8 Sep 2010 15:53:59 -0700
Message-ID: <E17F75B6E86AE842A57B4534F82D03769C2F29@MTAMAIL.muni.sfgov.org>
To: "www-style list" <www-style@w3.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>
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 

> 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.

> 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 zero.    

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.
> 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.

> 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".

Hope this helps,
Charles Belov
SFMTA Webmaster
Received on Wednesday, 8 September 2010 23:04:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC