Re: [css3-lists] of lists and castles

On Sun, Apr 24, 2011 at 11:28 PM, John Daggett <jdaggett@mozilla.com> wrote:
> My guess is that this has been touched on before but I think the
> current CSS3 Lists spec is focusing on the wrong aspect of the what is
> needed to improve lists in CSS.  In the context of ordered lists in
> CSS, I don't think we need to push CSS to support all possible
> numbering systems.  I've worked on internationalized number formatting
> in applications before and the possible variations are as numerous as
> the day is long. This makes it very hard to choose the "right" set of
> common styles to support universally.  You can see the variety just by
> comparing some of the styles supported in the MS Office specs that
> Koji referenced [1] to the ones listed currently in the spec (and in
> Mozilla's implementation [2]).  Supporting the union of the two could
> easily double the size of the spec.
>
> I think it would be better to focus on making the extension mechanism
> (i.e. @counter-style) as simple as possible to allow *simple* extended
> list styles and not require user agents to support a long list of
> default formats that may or may not be what users in a given locale
> prefer in a given context.

So, @counter-style is already as simple as possible, really.  (I could
potentially remove non-repeating, but it does serve a purpose.)  Look
at most of the predefined styles - they're almost all the bare minimum
of 'type' + 'glyphs', with a few changing the suffix (there will also
be a few changing the negative sign, once I get around to that
update).

I agree that internationalized number formatting is potentially a
rathole from which I'd never emerge.  That's why I'm not going there -
I'm very nearly done compiling everything I want; I just need to work
a little bit more on South Asian and Greek styles.

The whole point of defining @counter-style was to ensure that I didn't
*have* to choose the "right" set of styles to define; I could just
define what I thought was a pretty decent set, and let the authors
fill in the rest as needed.


> Specifically, I think section 4.3
> ("Complex counter styles") should be dropped completely and the list
> of required @counter-style rules reduced significantly or eliminated.

Who are you trying to optimize the "simplicity" for by dropping these?
 There are only a handful of styles in 4.3 - a single ethiopian style
and the family of longhand CJK styles - and the list of predefined
styles are very nearly free for the UA to support, once they implement
the @counter-style rule at all.

I don't think that significantly reducing or eliminating the list of
predefined styles would be simpler for authors.  It would just mean
that anyone who wanted to use their own local-script list style to
number their lists would have to look up @counter-style and define it
for themselves.  It's not a huge burden, but it is a burden, and I
think the calculus of benefit argues for predefining a useful chunk of
styles.


> I think describing number formatting in general (i.e. beyond the use
> in simple lists) is a worthy task but not something that really
> belongs in a CSS rec.  I think a W3C Note or a Unicode Technical Note
> would be a better place for this work.  I don't see any real use for
> numbers that run into the trillions in the context of lists.

I generally agree.  Supporting up to the trillions is just a bit of
completionism, really; once you have the algorithm to do up to 10k or
so, the rest is basically no effort.  It's not like browsers will
support numbering up that high, anyway - iirc, the 2.1 testsuite
showed that many implementations used a signed 16-bit value for
counters anyway.

I am strongly uninterested in describing general number formatting, as
that is much more complicated than my current system would allow.  I'd
have to add a lot more complexity to do that, which I don't think is
necessary or good.

~TJ

Received on Monday, 25 April 2011 15:22:48 UTC