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

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

From: Xidorn Quan <quanxunzhen@gmail.com>
Date: Tue, 20 May 2014 16:42:27 +1000
Message-ID: <CAMdq699M6_J65jEbyv4uMu2oeL8n5itE+1B=XO_ut_S-keHrDg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>, David Baron <dbaron@dbaron.org>
On Tue, May 20, 2014 at 4:21 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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.


Okay, so you may also want to append a space to suffix of korean-* styles.

- Xidorn
Received on Tuesday, 20 May 2014 06:43:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:27 UTC