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

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.

- Xidorn