Re: [css-counter-styles] Counting chars instead of symbols in pad

On Fri, Feb 21, 2014 at 2:35 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> On Sat, Feb 22, 2014 at 8:43 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Fri, Feb 21, 2014 at 1:35 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Tue, Feb 18, 2014 at 4:57 AM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>>>> The spec says that, the 'pad' counts the number of symbols, not
>>>> characters. I suggest to change it to counting characters. I have two
>>>> reasons:
>>>>
>>>> 1. It is not very useful to count symbols. There are many styles use
>>>> multi-character symbols. If people want to build a constant-width
>>>> style based on such styles with pad, they will find it impossible as
>>>> pad counts symbols.
>>>> 2. For some predefined styles, such as the Chinese ideographic styles,
>>>> it is hard to say how many symbols are there, and explicitly defining
>>>> the partition is meaningless while increases the burden of
>>>> implementation.
>>>>
>>>> Consequently, I propose changing counting symbols to counting
>>>> characters for pad.
>>>
>>> Hmm, you're right that the specially-defined styles don't have any
>>> concept of "symbols".
>>>
>>> All right, I'll change to "grapheme clusters".
>>
>> Further question on this: say the string you pass to 'pad' is multiple
>> grapheme clusters.  Should its length be counted against the pad
>> length?
>>
>> That is, given the following:
>>
>> @counter-style foo {
>>   system: override decimal;
>>   pad: 5 "abc";
>> }
>>
>> Should a counter with value 1 be rendered as "abcabcabcabc1", "abc1",
>> "abcab1", or "bcabc1"?
>>
>> * The first just finds the difference between the representation
>> length and the pad length, and appends that number of copies of the
>> pad string.
>> * The second finds the difference, divides it by the length of the pad
>> string (in grapheme clusters), floors it, then appends that many
>> copies of the pad string.
>> * The third and fourth do the same, but if there is any leftover
>> space, pad it out with substrings of the pad string, placed either at
>> the end or start.
>>
>> The first, though dumb, is also very simple.  I could add a note that
>> authors shouldn't use pad strings of more than a single grapheme
>> cluster.  The rest are all bad for various reasons - the second
>> doesn't actually pad out to the right length, the third and fourth
>> might be nonsense if the pad value is something significant that isn't
>> supposed to be displayed partially.
>
> I agree with the first method as well.

Cool, I've done so, and amended the previous warning to now talk about
using multi-grapheme cluster 'pad' symbols.

~TJ

Received on Saturday, 22 February 2014 01:00:09 UTC