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

> Tab Atkins Jr. wrote on Wednesday, September 08, 2010 4:48 PM
> 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)
> >
> > 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.

Good.  That is what I was asking.
 
> >> 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.

I only save the few CSS topics I'm concerned with.  I'd guess you 
don't have that option.
 
> >> 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.

I assume by implementors you mean the folks that build browsers.
As long as I have the flexibility to specify a longer string, I'm
pretty flexible as to how you implement it.
 
> > 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: ") ";
> }

Was that trailing space supposed to be in there?  Why would ") " 
take a trailing space and "." not?
 
> Which will produce:
> 
> (1) The first item!
> (2) The second item!
> (3) The third item!
> 
> >> "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?

The character needs to have a pronunciation.  Of course, that may be
an issue with other list types as well, now that I think of it.

This might only be an actual issue were the Webdings, Windings or 
Zapf Dingbats fonts to be used, as they get read as the a-z character
they stand in position for.  Now that I'm thinking about it, that's 
probably not a glyph issue, but a font issue (and thus doesn't apply
to [css3-lists] discussions.

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

I'm thinking of lists like

* first item
# second item
* third item
# fourth item

or

* first item
# second item
@ third item
* fourth item

Not saying this is a real-life case, just illustrating.

Again, this would probably be a marketing use (I'm in our 
Marketing unit, so I tend to think about such things) rather
than day-to-day office use.

While we're talking about this, what about legal numbering?

1
    1.1
    1.2
    1.3
2
    2.1
    2.2
        2.2.1
        2.2.2

(real-life example is Word Outline numbering)

infix might be applicable here, except that here it is an infix
between levels, not between characters in a composed string at 
the same level.  I don't really have a use for infix within the
same list level; that was just trying to be flexible.

It is of course reasonable for scope control to restrict to 
real-life examples, as opposed to creating a maximally 
flexible system that could allow for creativity (since 
marketing whimsy would probably be expressed using means 
other than HTML, e.g., images, Flash).

Hope this helps,
Charles Belov
SFMTA Webmaster

Received on Thursday, 9 September 2010 00:29:55 UTC