W3C home > Mailing lists > Public > www-style@w3.org > February 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 21 Feb 2014 13:43:52 -0800
Message-ID: <CAAWBYDCpwGU4vxdAiGqaETW-X4rc22-erwn3HncMuLzuftt0DQ@mail.gmail.com>
To: Xidorn Quan <quanxunzhen@gmail.com>
Cc: www-style list <www-style@w3.org>
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.

~TJ
Received on Friday, 21 February 2014 21:44:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC