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