Re: [css-counter-styles] About space between bullet and content

On Tue, Apr 29, 2014 at 9:19 AM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> On Tue, Apr 29, 2014 at 3:15 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> On Sat, Apr 26, 2014 at 11:14 PM, Xidorn Quan <quanxunzhen@gmail.com>
>> wrote:
>> > During implementing of this spec, one thing we noticed that is not
>> > mentioned
>> > in the document is the space between bullet and content. Though I do not
>> > think it is something necessary to be covered in spec, dbaron has a
>> > different opinion.
>> >
>> > Currently, for list-style-type defined before this spec, Gecko use
>> > padding-end: 0.5em on bullet to separate bullet with content, and
>> > WebKit/Blink seem to append a space character to the bullet. However,
>> > since
>> > this spec introduces arbitrary suffix, a problem is present.
>> >
>> > The problem is that, some suffixes like ideographic comma, the suffix of
>> > cjk-decimal and some other East Asian counter styles, have space inside
>> > themselves. If additional space is appended, the visual gap between
>> > bullet
>> > and content will be too wide. To solve this problem, in Gecko, we
>> > suppress
>> > the padding when the suffix is ideographic comma, and plan to also apply
>> > this suppression to suffixes end with some other punctuations including
>> > ideographic full stop, and fullwidth comma, full stop, and colon.
>> >
>> > Since I find no normative text mentions the space between bullet and
>> > content, any comment of this problem should not be normative, either.
>> > However, the spec may want to mention it as an informative note, so that
>> > future implementators can be aware of this problem.
>>
>> The intention is that the spacing is controlled by the ::marker
>> pseudo-element.  This is currently captured by the Lists spec:
>>
>>   li:dir(ltr)::marker {
>>     margin-right: 1em;
>>   }
>>   li:dir(rtl)::marker {
>>     margin-left: 1em;
>>   }
>>
>> (I'm using a 1em space for arbitrary reasons; I'd be fine with
>> switching it to .5em.  And if margin-inline-end existed, I'd obviously
>> use that instead of selectors.)
>
>
> I noticed this in css-lists, but as it is not normative, I thought it was
> only an example about how the things defined in the spec can be used.
>
>> But it sounds like you're saying that the spacing should be dependent
>> on the counter style instead.  This is somewhat problematic, as
>> spacing has no relevance for *other* uses of counter styles that
>> invoke them with counter(); it's only relevant for <li>s themselves.
>
>
> Right, it is only relevant for <li>s.
>
>>
>> Could you control this with a :lang() style on the <li>?
>
>
> I don't think so. Fullwidth suffixes can be used in many langs, usually in
> CJK environment. In addition, whatever lang it uses, it is still necessary
> to add space after halfwidth punctuations.
>
> Our current practice is to suppress only the padding declared in the style
> provided by UA. Any author-specified padding will not be changed. It may be
> a little bit odd when an author tries to change the padding of ::marker (in
> Gecko, currently, ::-moz-list-{bullet,number}), but it seems to be a good
> compromise between the default style and customizability.
>
> We have do some discussion about the mechinasm. If you are interested about
> the discussion, you may want to read
> https://bugzilla.mozilla.org/show_bug.cgi?id=934072 comment 5, 10, 11, 12,
> 14, 19, 31, 32, 34, 36, 38, 47, 48, 49, 50, 51, 52, 53. As it is very long,
> I'd like to make an abstract here:
>
> I first tried to convert the space from using margin to appending space
> character after halfwidth suffix like what is done by Chrome. But this is
> opposed by jfkthame. He thought it make the list be rendered less perfect.
>
> Then he suggested two possible methods, one is using U+FF64, the halfwidth
> version of ideographic comma, instead of U+3001 in the spec, the other is
> relying on some advanced font features to shrink the character. But we found
> them unsuitable. For the first method, because U+FF64 is not identical to
> U+3001 in shape in some fonts, and U+3001 is more widely used, it is not a
> good idea to replace that character. For the second one, most commen Chinese
> fonts do not support those features. And for both methods, it will be
> problematic if language is zh-tw or zh-hk since in those language, the glyph
> is centered instead of being left-aligned.
>
> Finally, we agreed that making the padding aware of  the suffix is the best
> method. And to compromise, we only suppress padding defined in ua.css, and
> do not touch the padding if it is specified by author.

The CSSWG decided that the spacing between marker and content should
just be handled by the suffix of the counter style, as it's simple and
works well for all the predefined styles.  Anything else is confusing
and weird.

~TJ

Received on Tuesday, 20 May 2014 06:22:28 UTC