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

On Wed, Sep 8, 2010 at 5:25 PM, Belov, Charles <Charles.Belov@sfmta.com> wrote:
>> Tab Atkins Jr. wrote on Wednesday, September 08, 2010 4:48 PM
>> 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.

Yes, that's what I mean.  And yeah, you'll be able to specify longer
strings, so it's good that you'll be happy.


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

Brain fart, actually.  I for some reason thought that I needed the
extra space there to ensure that there was a proper separation between
the marker and the content.  But that space is always there anyway,
even with a list-style-position:inside list-style-image.

So no, the space shouldn't have been there.


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

Screen readers shouldn't be reading the display of the list-item, but
rather the actual number.  (Even in a <ul>, I'd like to hear them
numbered if I was listening to them.  We refer a lot to "the third
bullet point" and such, after all.)


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

Right, I understand the use, I just haven't seen it in the wild.  Has
your Marketing unit ever used anything like that, or do you have
materials that show a list like that?  If there's actual usage I'll
throw it in.


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

This is covered by the counters() function, which will grab all the
in-scope instances of a particular counter (rather than just the
current most-deeply-scoped instance) and mash them together with an
infix string.

~TJ

Received on Thursday, 9 September 2010 00:58:53 UTC