Re: [css-counter-styles] implementation of complex cjk counter styles

On Thu, Jan 16, 2014 at 9:16 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Jan 14, 2014 at 8:00 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>>
>> You said "if any of the digit markers are preceded by the digit 1, and
>> that digit is not the first digit of the number, remove the digit".
>> Doesn't it mean that, for 1,000,000, the first digit one will be
>> preserved? And also it may be a little strange to use "一千" instead of
>> "千" for 1,000.
>
> Yes, this has *always* been the case.  1e3 has always been written as
> 一千 according to this algorithm.
>
> I just noticed, though, that this is inconsistent with how the
> informal japanese and korean-hanja styles are specified in their
> @counter-style block and the example table. UGH.

Maybe it does not matter a lot as rules for numbers less than 10,000
is defined above.

>> In my latest implementation which has been accepted by Mozilla, the
>> rule for Japanese informal can be described as: if any of the digit
>> markers other than "千" are preceded by the digit 1, remove the digit.
>> If there is only one group, and "千" is preceded by the digit 1, remove
>> the digit.
>
> Ugh.  It's not your fault, but I'm extremely frustrated that when I
> ask 5 people for how to write a numbered list in CJK styles, I get 10
> contradictory answers. >_<

I can understand it. I believe the problem isn't that we really have
many different methods to write such numbers, but is that we have
never thought about the full rules seriously.

In my opinion, it could be helpful to list more different examples
that make people easier to check, and the correctness could also be
checked according to result of search engines. If any of numbers has
alternative forms, the preference could also be listed for each form.
Then put the standard to CR and ask user-agents to implement according
to the examples with a recommended (but not compulsory) generating
algorithm. After that, we could modify the recommended algorithm
according to the feedback from implementators, so that new
implementators could have an easy path to follow.

The core suggestion is that, we can replace the "must" in "they must
be implemented as described here" with "may". I think it is not
necessary to define a standardized algorithm for them, or it will be
hard to modify in the future when some new errors get uncovered. And I
do not think developers will be badly frustrated when they find there
are minor differences in these numbers between implementations.

Xidorn Quan

Received on Thursday, 16 January 2014 06:22:59 UTC