- 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