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

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.

- Xidorn Quan

Received on Friday, 21 February 2014 22:36:23 UTC