- From: Belov, Charles <Charles.Belov@sfmta.com>
- Date: Wed, 8 Sep 2010 15:53:59 -0700
- 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 declarations. > 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. two. three. four. five. six. seven. eight. nine. 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