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

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 UTC