RE: Outline Numbered Lists

> Say we create an
> additional list-style-type called outline.  How exactly does this
> work? Does it automatically gather and concatenate all previous
> outline lists?  What happens if you nest lists with not all of them
> being outline, like:
> <ol type=outline>
>  <ol type=upper-roman>
>    <ol type=outline>
> ...

> Does the inner outline grab from the outer outline?  Does it grab from
> the upper-roman in the middle?  Or does it start a new outline
> entirely?

Point taken, but this is a corner case and more complex than the use cases I'm talking about. As we're talking about a simple shortcut, of course you sacrifice some control and these scenarios arise. But, all you need to do is specify one sensible behaviour as the default, and if the user wants something different, they can use counters. 

I think the best option is: 
- Firstly, use list-style-outline:outline, instead of a new list-style-type (see below)
- If the parent is outlined, grab whatever the parent's marker is and append to it.
- If the parent isn't outlined, start a new list.

All of the requests we've seen have been for lists with numbers and dots like this:
1.
1.1.
1.1.1.

Which would be solved by:
<ol style="list-style-outline:outline;">
<ol>
<ol>

Beyond that, I don't think it really matters what we decide for the corner cases.

I think that a list-style-outline:outline would be better than a new list-style-type, as it means we can do outlines for different list-style-types. E.g. it'd let you do:
1.
1.a.
1.a.i.
1.a.ii.

That gives a lot of flexibility with just a simple binary attribute combined with what's already available in list-style-type.

It's good that there are solutions that just work now, I'm looking to the future for a simpler way to define this common list type. The ambiguities and corner cases can all be resolved by just choosing an option - in most real-world cases they don't matter, and when they do, the counters option is there to provide any additional flexibility you need.

Received on Friday, 19 June 2009 02:03:38 UTC