W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: [css3-lists] remove "Complex Counter Styles" and "Optional Extended Counter Styles" sections

From: John Daggett <jdaggett@mozilla.com>
Date: Sun, 27 Nov 2011 03:34:03 -0800 (PST)
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
Message-ID: <1422234520.642.1322393643097.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
fantasai wrote:

> > I think section 12, "Optional Extended Counter Styles" should be marked
> > with a similar issue about whether it makes sense to spec out "optional"
> > features such as these.
> 
> Whether to have section 12 and whether to mark it optional was already
> discussed and resolved in May.
> 
>     - RESOLVED: Define cjk longhand list numbering up to 100,000
>                 with fallback to cjk-decimal beyond, allow UAs to
>                 implement longhand beyond that limit, put definition
>                 for that in informative appendix.
> 
> http://lists.w3.org/Archives/Public/www-style/2011May/0234.html

As HÃ¥kon has already pointed out, that discussion focused on different
alternate ways of defining this feature, *not* on whether it should
be in the spec or not.  Specifically, a straw poll was taken on this
subject:

>  fantasai: So we could spend the rest of the call talking about databases,
>              or we could resolve on what to do
>    1) Define cjk counter up to 10^16 (full definition that we have ready to
>       go, more than counter hardware limits in place now)
>    2) Definte them up to 10,000
>    3) Definte them up to 100,000
>    4) Put both definitions in the spec, allow UA to implement either, and
>       mark full definition at-risk to see what ppl implement in CR

Especially since this is defined as an *optional* feature, I think
the issue is whether this is really worth the time and effort of the WG
to verify that this is really functionality needed in CSS or not.  I think
we should be focusing on improving the functionality of small lists, not
working on solving the "big list" problem.

> > I feel strongly that in the context of simple lists it doesn't
> > make sense to be proposing this, as either a required or optional
> > feature.  At a minimum I think it should be pushed out to the next
> > version of the module, the working group's time would be much
> > better spent reviewing, refining and working out the fine details
> > (along with tests!!!!) of @counter-style and the other proposals
> > for simple lists.
> 
> What is the point of pushing it out to the next level if the spec
> work is already done and the feature is marked at-risk?

It's a question of focus, I don't think we should include *optional*
features that are relatively complex unless those features are needed
for a clear purpose.  We shouldn't be writing smorgasbord specs that
include a whole bunch of features just to wait and see who implements
what after CR.  We should be working on focused specs that solve
clear use cases.  I simply don't feel this set of features are important
to work on at this point.

Regards,

John Daggett
Received on Sunday, 27 November 2011 11:34:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT