Re: [css3-lists] Published as WD!

On Wed, Jun 1, 2011 at 2:21 AM, Håkon Wium Lie <howcome@opera.com> wrote:
> Also sprach Tab Atkins Jr.:
>
>  > The Lists module was just published as WD today, at
>  > <http://www.w3.org/TR/css3-lists/>.  The previous WD was published *8
>  > 1/2* years ago.  Unless I get hit by a bus, we'll finish the process
>  > to Rec in less time than that.  ^_^
>
> We'll see :-)
>
> I have not gone through the draft in detail. But I have been looking at
> section 8 and I marvel at the amazing options it provides. Good work!

Yay, thanks!

Also, thanks for the good feedback!  I'll respond to each in turn.


> To make the representation slightly more compact and readable, perhaps
> we could find a way to write:
>
> @counter-style lower-norwegian {
>  type: alphabetic;
>  glyphs: 'abcdefghijklmnopqrstuvwxyzæøå';
> }
>
> That is, if 'glyphs' only has one string value, it is interpreted as a
> sequence of single characters.

I had thought of this, but decided against it originally.  The problem
is that it's ambiguous with the value of a 'repeating' or
'non-repeating' type.  It's perfectly fine, for example, to have a
style like this:

@counter-style abc {
 type: repeating;
 glyphs: 'abc';
}

I do recognize that it's a bit annoying to have to add at least 3
additional characters for each counter glyph (start and end quotes,
and comma), though.  If it seems worthwhile, I could make it
unambiguous, like requiring a keyword before the string, something
like this:

@counter-style lower-norwegian {
 type: alphabetic;
 glyphs: combined 'abcdefghijklmnopqrstuvwxyzæøå';
}


> The algorithms in the draft are sometimes hard to read. These two can be
> hard to distinguish:
>
>  <i>I</>
>  /
>
> I suggest using another variable than <i>I</i>.

Good point.  I've changed <var>I</var> to <var>value</var>, and
<var>N</var> to <var>length</var> as well.


> I can read the pseudo-algorithm in 8.1.3 fairly easily. Numbered steps
> are good. I suggest using numbered steps in 8.1.4 as well.

OK, done.


> 8.1.4 says:
>
>  The ‘symbolic’ counter type cycles repeatedly through its provided
>  glyphs, doubling, tripling, etc. the glyphs on each successive pass
>  through the list. It can be used for footnote-style markers, and is
>  also sometimes used for alphabetic-style lists for a slightly
>  different presentation than what the ‘alphabetic’ type presents.
>
> I don't intuitively understand what "doubling, tripling, etc." means.
> An example of how this differs from 'alphabetic' would be helpful.

Would this be addressed by simply providing a better example?  The
current example symbolic style, 'unary', is unfortunately the exact
same if I used 'alphabetic'.  I've switched it to using
'upper-alpha-symbolic' as an example, and put in a note specifically
calling out the difference between it and 'upper-alpha'.


> In 8.1.6, step 3 seems to be missing: <i>I</i> is never set to a new value

Whoops, you're right.  Added.


> Section 9.1. lists Predefined Repeating Styles
>
> It's nice to see how to create simple one-glyph lists. I suggest
> keeping the list-style-types defined in CSS 2.1 in the list of
> predefined styles (circle, disc, square), but not add new predefined
> counter styles. For example, I don't think 'check' should be
> predefined. Different languages/traditions use different marks in
> check boxes. And if people want to use 'check' to see '✓', they can
> easily add it themselves.
>
> --
>
> Section 9.2 lists Predefined Numeric Styles
>
> Most ordered lists are numbered, I believe (as opposed to using
> alphabetic markers). I therefore have a higher capacity for predefined
> numeric styles that other styles. But, I don't think we need 'binary',
> 'fullwidth-decimal', 'lower-hexadecimal', 'new-base-60',
> 'super-decimal', 'octal', 'upper-hexadecimal'.
>
> (Again, if people need them, they can easily be added.)
>
> --
>
> Section 9.3 lists Predefined Alphabetic Styles
>
> Hmm. Are all these used? Are they correct? Are they there
> automatically because they have entered Unicode?
>
> When in doubt, I'd rather leave it to the author to define them.

For the most part, these are present because the previous WD defined
them.  I can drop many of them, like the new repeating styles, if
necessary.

I've added several additional numeric and alphabetic styles based on
feedback built up since then from native speakers of several
languages.  I presume that they're used, since they were explicitly
asked for.


> Section 9.4 lists Predefined Symbolic Styles
>
> I think we should use 'asterisk' (instead of 'asterisks') and
> 'footnote' (intead of 'footnotes'), like we do in 'italic' and
> '@footnote'.

Seems reasonable.  Done.


> But I don't think these should be predefined. Footnote marker vary
> widely and sanctioning one specific list seems wrong. The
> 'lower-alpha-symbolic' and 'upper-alpha-symbolic' gives a slightly
> different result than 'lower-alpha' and 'upper-alpha', but I'm not
> convinced this warrants predefined status.

How about I move the 'footnote' style into just being a symbolic example?

Charles Belov gave the reasoning for the upper/lower-alpha-symbolic
styles, in a reply to your email.


> Section 9.5 lists predefined Non-Repeating Styles
>
> It seems that all series that have Unicode points have been added
> here? As a result we have 'double-circled-decimal' and
> 'parenthesized-decimal' (done through Unicode). I can only imagine the
> discussions leading up to these being added to Unicode, but I don't
> think they should automatically end up being predefined in CSS.
>
> The use case is limited, and authors who want to use them can easily
> do so by using @counter-style. I suggest removing the requirement to
> predefine these, but list them in an appendix.

Several of these are actively used in CJK lists, according to feedback
I've received from native speakers.


> (When adding sample CSS code to the spec, it would be good to use
> shorter lines or allow breaks in the code.)

I've switched the code blocks to whitespace:pre-wrap.



> Section 9.6 lists predefined additive styles. But are all of them
> really necessary? For example, do we need to predefine
> "simple-upper-roman" (which appears to be a variant of roman which is
> slighly easier to read (unless you expect real roman, that is)).

I've definitely seen the simple-*-roman variants used in real life.
It's the "only additive" version, without forms like "IX" which
require subtraction to determine the value.


> Given that these counter styles with can be added to any style
> sheet, I think we should have very strict criteria for making these
> counter styles predefined. We risk making mistakes, or adding styles
> that are never used (like we did for lower-greek, it seems).

What criteria would you propose?  Right now I'm more-or-less using the
criteria of "used at least somewhat commonly in real-life lists".
When possible, I'm letting native speakers actually define the style
for me, so we don't add things that are nonsensical and little/never
used in real life, like the upper/lower-greek styles.


> Section 10 defines complex counter styles that cannot be described
> declaratively: 'ethiopic-numeric' and 'simp-chinese-informal',
> 'simp-chinese-formal', 'trad-chinese-informal', 'trad-chinese-formal'.
> I sympathize with wanting to do numeric lists in your own language
> automatically. I symphtize less with having several variants being
> predefined.

I don't understand what you mean here.  Are you implying that you're
okay with a single Chinese style, but not with the fact that there are
four variants that are only different in the used characters?  Or
something else?

The variants are all commonly used, for what it's worth.


> Also, rather than defining algorithms for how to concatenate glyphs
> into numbers, it may be easiser to write out the list of
> numbers/strings. The ED states:
>
>  In practice, lists are rarely numbered above ten thousand, so these
>  styles have been limited to their first "group".
>
> I'd say that lists are rarely numbered above 100. Thus, by listing
> these number systems to 100 we can remove several algorithms from the
> spec.

I'd be fine with that, except that the WG has already resolved that we
should define the general algorithm.  There's now an optional appendix
that defines the CJK styles out to 10^16.  Unfortunately, you weren't
present at the telcon that this was decided at.  >_<

One issue, though, is the fact that the equivalent Japanese and Korean
styles can be defined perfectly fine out to 10k (or even 100k,
actually) as simple 'additive' styles.  I don't want to define the
Chinese styles to a different length than the others.

~TJ

Received on Thursday, 2 June 2011 02:54:12 UTC