Réf. : Re: Outline Numbered Lists

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Réf. : Re: Outline Numbered Lists

leslie.brown

>> I work for a company, Ephox, who develop a wysiwyg HTML editor called
>> EditLive!. We have a number of law firms as clients, and they require
>> "outline numbered" lists, in the format:
>>
>> 1. Item 1
>> 1.1. subitem
>> 1.1.1. sub-sub 1
>> 1.1.2. sub-sub 2
>> 1.2. subitem 2
[...]

> This does the trick on all browsers I tested on (Opera, IE 8, Firefox,
> Safari, Chrome)
> http://devfiles.myopera.com/articles/501/nested-counters-example.html

Doesn't work in IE7.

Just a thought... if it's a "legal document" shouldn't the numbers should be part of the content and not mark-up ?
(I'm not contesting the usefulness of the idea in general.)

Les Brown
Reply | Threaded
Open this post in threaded view
|

Re: Réf. : Re: Outline Numbered Lists

Tab Atkins Jr.
On Wed, Jun 17, 2009 at 6:09 AM, <[hidden email]> wrote:

>>> I work for a company, Ephox, who develop a wysiwyg HTML editor called
>>> EditLive!. We have a number of law firms as clients, and they require
>>> "outline numbered" lists, in the format:
>>>
>>> 1. Item 1
>>> 1.1. subitem
>>> 1.1.1. sub-sub 1
>>> 1.1.2. sub-sub 2
>>> 1.2. subitem 2
> [...]
>
>> This does the trick on all browsers I tested on (Opera, IE 8, Firefox,
>> Safari, Chrome)
>> http://devfiles.myopera.com/articles/501/nested-counters-example.html
>
> Doesn't work in IE7.

While true, this is something of a non sequitur.  *Any* approach
beyond just inserting the markers into the content won't work on IE7.
A completely new approach (as Dylan suggests) won't work in current
browsers either, though.

Basically, if you need to support IE7, there is NO CSS-based solution.
 You must insert the markers into the content.  If you can ignore IE7,
then there is an existing CSS-based solution that is designed for
exactly this - the counters() construct, which combines all in-scope
counters with a given name and places a given glue string between
them.  At the moment you have to use ::before to implement it, but in
time the ::marker pseudoelement should hopefully be widely usable
instead.

~TJ

Reply | Threaded
Open this post in threaded view
|

RE: Outline Numbered Lists

Dylan Just
In reply to this post by leslie.brown

Some good points have been raised – browser support, content vs markup – but I still think the idea has merit. For sure, there are practical solutions we can employ to achieve this functionality today, but the root cause is best solved by changing the css standard.

 

It doesn’t matter if it won’t get browser support soon - by putting it in the standard we influence browser capabilities and one day solve this problem for good. i.e. in 10 years someone will be able to use this list type without employing hacks.

 

I’m basically making a feature request. :) What’s the process from here to inclusion in the standard?

 

Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

L. David Baron
On Wednesday 2009-06-17 18:12 -0400, Dylan Just wrote:

> Some good points have been raised - browser support, content vs markup -
> but I still think the idea has merit. For sure, there are practical
> solutions we can employ to achieve this functionality today, but the
> root cause is best solved by changing the css standard.
>
>  
>
> It doesn't matter if it won't get browser support soon - by putting it
> in the standard we influence browser capabilities and one day solve this
> problem for good. i.e. in 10 years someone will be able to use this list
> type without employing hacks.
>
>  
>
> I'm basically making a feature request. :) What's the process from here
> to inclusion in the standard?

It's already included in CSS 2.1, and
http://lists.w3.org/Archives/Public/www-style/2009Jun/0188.html
points to an example showing how to use the standard feature,
though, as
http://lists.w3.org/Archives/Public/www-style/2009Jun/0190.html
points out, it doesn't work in IE7.

The relevant part of the standard is
http://www.w3.org/TR/CSS21/generate.html#counters

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Reply | Threaded
Open this post in threaded view
|

RE: Outline Numbered Lists

Dylan Just
> It's already included in CSS 2.1... The relevant part of the standard
is
> http://www.w3.org/TR/CSS21/generate.html#counters

Counters are a great general solution and very flexible, but I think
they're over-complicated for this common list type. A new
list-style-type value or list-style-outline:outline would be much
simpler for someone to code by hand, and easier for us to set in a
wysiwyg editor.

Compare:
ol { counter-reset: item }
ol li { display: block }
ol li:before { content: counters(item, ".") " "; counter-increment: item
}

To
ol { list-style-type:outline-numbered; }

or
ol { list-style-outline:outline; }


Our product is a wysiwyg editing component for CMSs, and we usually have
to put formatting in inline styles, rather than in a stylesheet, which
we usually don't have control over. As such, we set list types as, e.g.
<ol style="list-style-type:decimal">, based on what the user selected in
a dialog. This is not easy to do for the outline-numbered counters
solution.

If we were to apply counters with inline styles, going on the above CSS:
- We'd have to put "counter-reset: item" on each ol in that style. This
introduces complications in adding nested lists and list items.
- We'd have to put "display:block" on each ol - I'm not even really sure
why this is required.
- Then there's the issue of the "li:before" - I'm not aware of a way to
add pseudo-class styles inline.

So, this means we'd have to add to the stylesheet, which is problematic
for us, but let's roll with it for a minute.

We'd have to tell customers to manually add in this outline list style.
Ideally, this style would be applied like this: <ol class="outline">.
So, then, what would the stylesheet entry be?

ol.outline { counter-reset: item }
ol.outline li { display: block }
ol.outline li:before { content: counters(item, ".") " ";
counter-increment: item }

The only problem with this is inheritance (maybe i'm doing something
wrong?). I have to add the class="outline" to each <ol> in the nested
list (tested in Firefox 3). Again, this is do-able, but it's just one
more complication.

With the new list-style-type value or list-style-outline:outline
suggestion, all we'd have to do is change one css attribute on the <ol>.


For the list-style-type, we'd add an "outline numbered" option to our
list type dialog. For the list-style-outline, we'd add an "outline"
checkbox to the dialog. The editing model and the resultant content is
very simple.



Reply | Threaded
Open this post in threaded view
|

Re: New work on fonts at W3C

Chris Wilson-12
In reply to this post by L. David Baron
On Tue, 16 Jun 2009 Ian Hickson <[hidden email]> wrote:
>On Tue, 16 Jun 2009, Levantovsky, Vladimir wrote:
>> The important point is that we seem to agree we need a universally
>> supported web font wrapper that would allow to put "signs and fences" to
>> reduce a risk of font piracy to a level that would be acceptable for
>> font foundries.
>
>FWIW, I don't think there is anything resembling consensus on this point.

Consensus from whom, and how are we counting?

>If today's font foundries aren't willing to trust their customers, they
>will be replaced by companies that are.

That's a rather scorched-earth philosophy.  How many talented font hinters (read: people capable of making readable body-text-size screen fonts) do you think there are in the world?

I read this idea as a realization that hey, TTF/OTF was not designed for this scenario; maybe it doesn't actually give enough information FOR this scenario.  You know, rather than dismissing out of hand the idea that maybe a more targeted, cooperatively designed solution might need to be developed.

-Chris

Reply | Threaded
Open this post in threaded view
|

Re: New work on fonts at W3C

davelab6
2009/6/18 Chris Wilson <[hidden email]>:
>
> That's a rather scorched-earth philosophy.  How many talented font
> hinters (read: people capable of making readable body-text-size screen
> fonts) do you think there are in the world?

It seems that most non-MS computers do not make use of hinting in fonts?

Reply | Threaded
Open this post in threaded view
|

Re: New work on fonts at W3C

Aryeh Gregor-2
In reply to this post by Chris Wilson-12
On Wed, Jun 17, 2009 at 7:47 PM, Chris Wilson<[hidden email]> wrote:

> On Tue, 16 Jun 2009 Ian Hickson <[hidden email]> wrote:
>>On Tue, 16 Jun 2009, Levantovsky, Vladimir wrote:
>>> The important point is that we seem to agree we need a universally
>>> supported web font wrapper that would allow to put "signs and fences" to
>>> reduce a risk of font piracy to a level that would be acceptable for
>>> font foundries.
>>
>>FWIW, I don't think there is anything resembling consensus on this point.
>
> Consensus from whom, and how are we counting?

I assume he means consensus from relevant parties, e.g.: web page
authors, browser authors, font authors, W3C members.  I don't think
it's safe to say that all browser implementers, especially, currently
agree that "we need a universally supported web font wrapper that
would allow to put 'signs and fences' to reduce a risk of font piracy
to a level that would be acceptable for font foundries".

I previously quoted a post by David Baron, one of Mozilla's core
developers, which suggested that OpenType/TrueType should be tried
before introducing new font formats.  John Daggett has posted in this
thread suggesting the same, and he's apparently the one who wrote web
font support for Firefox (at least, he's the assignee for bug 70132).
Anne van Kesteren from Opera, again in this very thread, suggested
pretty much the same thing, that maybe OpenType/TrueType is good
enough and we should wait and see.

Possibly more to the point, Mozilla, Apple, Google, and Opera are all
including OpenType/TrueType support in current or soon-to-be-released
versions of their browsers, and are not supporting other formats.
This seems to indicate that they think OpenType/TrueType support would
be of significant utility by itself, given the effort they had to
invest to get it working.

I think it's fair to conclude that there is not currently consensus
among browser implementers that it's clear yet that a new font format
is needed.  Unscientifically, it seems to me that most browser
implementers feel the opposite, in fact.  So I'd say Ian's statement
is fair.  There does seem to be consensus among font foundry
representatives that a new format is needed, and consensus among
Microsoft representatives, from what I've seen.

Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

Giovanni Campagna
In reply to this post by Dylan Just
2009/6/18 Dylan Just <[hidden email]>:

>> It's already included in CSS 2.1... The relevant part of the standard
> is
>> http://www.w3.org/TR/CSS21/generate.html#counters
>
> Counters are a great general solution and very flexible, but I think
> they're over-complicated for this common list type. A new
> list-style-type value or list-style-outline:outline would be much
> simpler for someone to code by hand, and easier for us to set in a
> wysiwyg editor.
>
> Compare:
> ol { counter-reset: item }
> ol li { display: block }
> ol li:before { content: counters(item, ".") " "; counter-increment: item
> }
>
> To
> ol { list-style-type:outline-numbered; }
>
> or
> ol { list-style-outline:outline; }

When using tool, only the tool developers have to deal with CSS
complexities, general authors just click a few buttons

>
> Our product is a wysiwyg editing component for CMSs, and we usually have
> to put formatting in inline styles, rather than in a stylesheet, which
> we usually don't have control over. As such, we set list types as, e.g.
> <ol style="list-style-type:decimal">, based on what the user selected in
> a dialog. This is not easy to do for the outline-numbered counters
> solution..

You could output a style fragment as a scoped style element inside the
main container (see the HTML5 redefinition of style element), or you
could output the stylesheet in a CMS specific data structure. This is
an implementation issue, I guess.

> If we were to apply counters with inline styles, going on the above CSS:
> - We'd have to put "counter-reset: item" on each ol in that style. This
> introduces complications in adding nested lists and list items
I don't see how... "counter-reset" is especially for nested lists

> - We'd have to put "display:block" on each ol - I'm not even really sure
> why this is required
Actually, there are two ways to go:
- keep "display:list-item" (the default for <li>) and use "::marker"
instead of "::before" (two colons for pseudo-elements!)
- use "display:block", preventing the generation of "::marker" pseudo-element
using "display:list-item" sets ::marker to "content:
counter(listitem,<value of list-style-type>)", so it would be rendered
twice if ::before is also used

> - Then there's the issue of the "li:before" - I'm not aware of a way to
> add pseudo-class styles inline.

You cannot.

> So, this means we'd have to add to the stylesheet, which is problematic
> for us, but let's roll with it for a minute.
>
> We'd have to tell customers to manually add in this outline list style.
> Ideally, this style would be applied like this: <ol class="outline">.
> So, then, what would the stylesheet entry be?
>
> ol.outline { counter-reset: item }
> ol.outline li { display: block }
> ol.outline li:before { content: counters(item, ".") " ";
> counter-increment: item }
>
> The only problem with this is inheritance (maybe i'm doing something
> wrong?). I have to add the class="outline" to each <ol> in the nested
> list (tested in Firefox 3). Again, this is do-able, but it's just one
> more complication.

What about
ol.outline, ol.outline ol { counter-reset:item }
ol.outline > li, ol.outline ol > li { display: block }
ol.outline > li:before, ol.outline ol > li:before { content:
counters(item, ".") " "; counter-increment: item }

> With the new list-style-type value or list-style-outline:outline
> suggestion, all we'd have to do is change one css attribute on the <ol>.

Changing "style" or changing "class" is not that different


Giovanni

Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

Tab Atkins Jr.
In reply to this post by Dylan Just
On Wed, Jun 17, 2009 at 6:37 PM, Dylan Just<[hidden email]> wrote:
> Our product is a wysiwyg editing component for CMSs, and we usually have
> to put formatting in inline styles, rather than in a stylesheet, which
> we usually don't have control over. As such, we set list types as, e.g.
> <ol style="list-style-type:decimal">, based on what the user selected in
> a dialog. This is not easy to do for the outline-numbered counters
> solution.

As Giovanni suggested, you can used <style scoped>, defined in HTML5,
relatively soon.  I don't know which browsers, if any, support it yet,
but it'll appear at least as quickly as a few new properties for a
list-style.

Alternately, just make sure that the component being editted is
wrapped in a <div> with a suitably unique ID (perhaps using a guid),
then just insert a normal <style> and preface all your rules with that
#id to manually scope them.  That will work interoperably today.

> If we were to apply counters with inline styles, going on the above CSS:
> - We'd have to put "counter-reset: item" on each ol in that style. This
> introduces complications in adding nested lists and list items.

As noted, this isn't necessary if you use a <style> block properly.

> - We'd have to put "display:block" on each ol - I'm not even really sure
> why this is required.

As Giovanni notes, it's there to prevent generation of ::marker, as
not everyone supports it yet.  display:block and ::before have greater
interop at the moment.  In time you'll be able to drop the li rule
entirely and just use the ol and li::marker rules.

> - Then there's the issue of the "li:before" - I'm not aware of a way to
> add pseudo-class styles inline.

Yup, you can't.  So you just have to use a <style> properly.

> We'd have to tell customers to manually add in this outline list style.

Perhaps.  I don't know how your tool works.  Can't you just make this
one of the choosable options?  There's no reason for the users of your
tool to know the internals behind the list display.

> Ideally, this style would be applied like this: <ol class="outline">.
> So, then, what would the stylesheet entry be?
>
> ol.outline { counter-reset: item }
> ol.outline li { display: block }
> ol.outline li::before { content: counters(item, ".") " ";
> counter-increment: item }
>
> The only problem with this is inheritance (maybe i'm doing something
> wrong?). I have to add the class="outline" to each <ol> in the nested
> list (tested in Firefox 3). Again, this is do-able, but it's just one
> more complication.

If you want them to automatically inherit, then add a "ol.outline ol"
selector to each of those three blocks (I notice that Giovanni also
noted this).  That means, though, that you'll probably need to mark
all your non-outline lists specially to shut down the production of
the outline counter.

> With the new list-style-type value or list-style-outline:outline
> suggestion, all we'd have to do is change one css attribute on the <ol>.

True, but most of your problems seem to arise from implementation
issues on your end, not a failing of CSS.  The difference is pretty
small, and shouldn't require your users to understand that a
difference even exists.

> For the list-style-type, we'd add an "outline numbered" option to our
> list type dialog. For the list-style-outline, we'd add an "outline"
> checkbox to the dialog. The editing model and the resultant content is
> very simple.

You should be able to present an identical interface to your users
with the existing CSS abilities.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

Brad Kemper
The reason Tab says "properly" (if you don't mind me saying so, Tab),  
is because separation of style and content is really one of the key  
tenets of this group.


On Jun 18, 2009, at 9:36 AM, Tab Atkins Jr. wrote:

> As noted, this isn't necessary if you use a <style> block properly.
>
>> [...]
> Yup, you can't.  So you just have to use a <style> properly.


Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

Tab Atkins Jr.
On Thu, Jun 18, 2009 at 11:49 AM, Brad Kemper<[hidden email]> wrote:

> The reason Tab says "properly" (if you don't mind me saying so, Tab), is
> because separation of style and content is really one of the key tenets of
> this group.
>
> On Jun 18, 2009, at 9:36 AM, Tab Atkins Jr. wrote:
>> As noted, this isn't necessary if you use a <style> block properly.
>>
>>> [...]
>>
>> Yup, you can't.  So you just have to use a <style> properly.

Oh geez, I didn't even realize that I might have been offensive with that.  >_<

But yeah, Brad's got my meaning.  Using @style is really something
that should be avoided if at all possible, for several reasons, one of
which is that @style rules can't represent all of CSS, as you found
out with this counter issue.

And hey, Ian (editor of HTML5) even seriously considered removing
@style almost entirely, leaving it only on <font> (which itself would
be retained only for the purpose of having @style on it) so that the
'taint' of <font> would spread to @style and it could be removed
completely from a later version of HTML.  Enough people complained,
though, that he reverse that position, put @style back, and just
removed <font> entirely.  There's really a lot of anti-@style
sentiment, though.

~TJ

Reply | Threaded
Open this post in threaded view
|

RE: New work on fonts at W3C

Chris Wilson-12
In reply to this post by Aryeh Gregor-2
I did not claim that there WAS consensus amongst browser vendors.  In just as unscientific a manner, I would say that ranked by market share, your statement about browser vendors is false (as Microsoft has vehemently argued AGAINST TTF/OTF as that format).  I asked, however, in order to establish from whom Ian was looking for consensus, and how he was ranking their feedback.

I think there is non-unanimous consensus among font vendors that TTF/OTF linking is not a good enough solution.

Seems like getting some measure of consensus on how to enable commercial fonts - that is, consensus that includes browser vendors AND font vendors - would be a good thing.

-Chris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Aryeh Gregor
Sent: Thursday, June 18, 2009 7:20 AM
To: Chris Wilson
Cc: [hidden email]
Subject: Re: New work on fonts at W3C

On Wed, Jun 17, 2009 at 7:47 PM, Chris Wilson<[hidden email]> wrote:

> On Tue, 16 Jun 2009 Ian Hickson <[hidden email]> wrote:
>>On Tue, 16 Jun 2009, Levantovsky, Vladimir wrote:
>>> The important point is that we seem to agree we need a universally
>>> supported web font wrapper that would allow to put "signs and fences" to
>>> reduce a risk of font piracy to a level that would be acceptable for
>>> font foundries.
>>
>>FWIW, I don't think there is anything resembling consensus on this point.
>
> Consensus from whom, and how are we counting?

I assume he means consensus from relevant parties, e.g.: web page
authors, browser authors, font authors, W3C members.  I don't think
it's safe to say that all browser implementers, especially, currently
agree that "we need a universally supported web font wrapper that
would allow to put 'signs and fences' to reduce a risk of font piracy
to a level that would be acceptable for font foundries".

I previously quoted a post by David Baron, one of Mozilla's core
developers, which suggested that OpenType/TrueType should be tried
before introducing new font formats.  John Daggett has posted in this
thread suggesting the same, and he's apparently the one who wrote web
font support for Firefox (at least, he's the assignee for bug 70132).
Anne van Kesteren from Opera, again in this very thread, suggested
pretty much the same thing, that maybe OpenType/TrueType is good
enough and we should wait and see.

Possibly more to the point, Mozilla, Apple, Google, and Opera are all
including OpenType/TrueType support in current or soon-to-be-released
versions of their browsers, and are not supporting other formats.
This seems to indicate that they think OpenType/TrueType support would
be of significant utility by itself, given the effort they had to
invest to get it working.

I think it's fair to conclude that there is not currently consensus
among browser implementers that it's clear yet that a new font format
is needed.  Unscientifically, it seems to me that most browser
implementers feel the opposite, in fact.  So I'd say Ian's statement
is fair.  There does seem to be consensus among font foundry
representatives that a new format is needed, and consensus among
Microsoft representatives, from what I've seen.

Reply | Threaded
Open this post in threaded view
|

RE: New work on fonts at W3C

Chris Wilson-12
In reply to this post by davelab6
Really?  That was not my understanding.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dave Crossland
Sent: Thursday, June 18, 2009 1:14 AM
To: Chris Wilson
Cc: [hidden email]
Subject: Re: New work on fonts at W3C

2009/6/18 Chris Wilson <[hidden email]>:
>
> That's a rather scorched-earth philosophy.  How many talented font
> hinters (read: people capable of making readable body-text-size screen
> fonts) do you think there are in the world?

It seems that most non-MS computers do not make use of hinting in fonts?

Reply | Threaded
Open this post in threaded view
|

RE: Outline Numbered Lists

Dylan Just
In reply to this post by Giovanni Campagna
These workarounds are great, but they are all complicated. Yes,
separation of style and content is a good thing, but the 'style'
attribute is a practical necessity when you don't have access to the
stylesheet or a <style> block - this is simply a constraint placed upon
us by most CMS vendors. In most cases, we only have access to edit the
contents of the <body>. Stylesheets are generally managed by an entirely
different subsystem.

Even with the workarounds available, and regardless of content vs style,
it would still be useful to have a simple css attribute as a 'shortcut'
to set this common style. If I can set a normal bulleted/numbered list
with one css attribute, why do I need 3-8 to create an outline numbered
list?

Counters and ::before provide useful flexibility for general cases. What
I'm suggesting is a simple shortcut for a common use case.


Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

Tab Atkins Jr.
On Thu, Jun 18, 2009 at 5:23 PM, Dylan Just<[hidden email]> wrote:
> These workarounds are great, but they are all complicated. Yes,
> separation of style and content is a good thing, but the 'style'
> attribute is a practical necessity when you don't have access to the
> stylesheet or a <style> block - this is simply a constraint placed upon
> us by most CMS vendors. In most cases, we only have access to edit the
> contents of the <body>. Stylesheets are generally managed by an entirely
> different subsystem.

You can put <style> in the <body>. <style scoped> is *only* sensical
when placed in the <body>.

> Even with the workarounds available, and regardless of content vs style,
> it would still be useful to have a simple css attribute as a 'shortcut'
> to set this common style. If I can set a normal bulleted/numbered list
> with one css attribute, why do I need 3-8 to create an outline numbered
> list?

Because normal lists don't have to refer to surrounding lists to know
how to display.  There's no need to specify which lists to refer to,
nor how to combine the lists together to form a new marker.

Also, where'd you get the 3-8 figure from?  The example given in the
first reply takes 4, and if you can assume ::marker support you can
drop one (the list-style-type:none rule) to do it in 3.

> Counters and ::before provide useful flexibility for general cases. What
> I'm suggesting is a simple shortcut for a common use case.

I don't believe the issue *is* simple, though.  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?

These sorts of issues are automatically answered by the existing
solution.  If you use the same counters for both of the outline lists,
then they concatenate.  The middle list doesn't interfere at all.  If
you use different counters, they won't.

I'm open to being convinced that there's a good way to solve this
without ambiguity, but honestly the counters-based solution is pretty
simple once you know that counters exist, and as it *already works*,
I'm happy with it.

~TJ

Reply | Threaded
Open this post in threaded view
|

RE: Outline Numbered Lists

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

Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

fantasai
Dylan Just wrote:
>
> 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.

This is an interesting case right here, one you can't do with counters().
counters() can only take one counter-style, and it has no way of looking
up what styles have been used previously.

We could maybe introduce a new counter-style, I'll call it 'auto' for now,
that, when it looks up a counter instance, associates the element's
list-style-type with the counter and uses that style for that counter.
Not exactly sure how to describe the counter instance's relationship to
the relevant element, but I /think/ that should be possible. dbaron?

(I can see it being useful even with counter(); you can change the style
of the counter without fiddling with the content property that sets it.)

~fantasai

Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

Giovanni Campagna
2009/6/19 fantasai <[hidden email]>:

> Dylan Just wrote:
>>
>> 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.
>
> This is an interesting case right here, one you can't do with counters().
> counters() can only take one counter-style, and it has no way of looking
> up what styles have been used previously.

You can do it with "creative selectors", ie manually referencing all
counters and relative style at all nesting level. Horrible but
working.

> We could maybe introduce a new counter-style, I'll call it 'auto' for now,
> that, when it looks up a counter instance, associates the element's
> list-style-type with the counter and uses that style for that counter.
> Not exactly sure how to describe the counter instance's relationship to
> the relevant element, but I /think/ that should be possible.

Uhm... If I understand it correctly, a value of "auto" uses, for each
counter in scope with that name, the "list-style-type" of the element
which last incremented it (regardless of the type used in counter() /
counters() on that element or associated pseudo-elements).

So the example becomes:
ol {
list-style-type: cycle(decimal,lower-alpha,lower-roman);
}
ol > li::marker {
content: counters(list-item,auto,".");
}

with the following assumptions
- cycle() and ::marker are supported
- list-item counter is automatically reset by ol
- li is "display:list-item"

> (I can see it being useful even with counter(); you can change the style
> of the counter without fiddling with the content property that sets it.)

Actually, it is a must, if you want to reduce ::marker magic to a
default stylesheet.

> ~fantasai
>
>

Giovanni

Reply | Threaded
Open this post in threaded view
|

Re: Outline Numbered Lists

Tab Atkins Jr.
In reply to this post by Dylan Just
On Thu, Jun 18, 2009 at 9:02 PM, Dylan Just<[hidden email]> wrote:

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

That sounds pretty good, actually.  So then list-style-outline would
be inherited, obviously, so that it cascades down to the children
<ol>s.  Cool.

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

Yup, sounds nice.  I know I've seen books use mixtures of counter
types for their outlines (my mind seems to recall upper-roman being
mixed with lower-roman).

On Fri, Jun 19, 2009 at 2:17 AM, fantasai<[hidden email]> wrote:

> Dylan Just wrote:
>>
>> 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.
>
> This is an interesting case right here, one you can't do with counters().
> counters() can only take one counter-style, and it has no way of looking
> up what styles have been used previously.
>
> We could maybe introduce a new counter-style, I'll call it 'auto' for now,
> that, when it looks up a counter instance, associates the element's
> list-style-type with the counter and uses that style for that counter.
> Not exactly sure how to describe the counter instance's relationship to
> the relevant element, but I /think/ that should be possible. dbaron?
>
> (I can see it being useful even with counter(); you can change the style
> of the counter without fiddling with the content property that sets it.)

Now that I look at the counters section of CSS2 again, I'm actually
surprised this doesn't already exist.  I would have expected that it
did.

(This thread, btw, has been massively helpful to me, as I had to idea
that the counters section of the spec had been implemented so widely.
I get to start using it now, glee!)

~TJ