Re: OL starting with zero

[Tue, 26 Mar 2002 19:05:33 +0000] Ian Hickson:
>Coises wrote:
>> I am a bit doubtful that CSS1 compatibility and intuitive
>> behavior with an exposed counter can be achieved simultaneously; as far as
>> I can tell, no one has yet attempted to explain how it will work.
>I fail to see the problem with the way the Lists module specifies it. Maybe the 
>following can help. This is what we intend to add as an appendix at the end of 
>the lists module, showing an example of how CSS can be used to describe the 
>typical presentation of the HTML4 list elements:
>  /* Set up ol and ul so that they reset the list-item counter */
>  ol, ul { counter-reset: list-item; }

That is the problem: it cannot be represented in CSS1 (or in CSS2 using the
"display: list-item" method of creating lists).

*** An example using existing list properties ***

The first thing I want to do is to introduce an example that attempts
to separate the presentation of HTML/CSS1-style lists from anything
that might be "implicit" in HTML by rendering them in XML instead.

Consider the following page:
which contains this XML code:

     <?xml version="1.0" encoding="iso-8859-1"?>
     <?xml-stylesheet type="text/css" href="oplists4.css"?>
     <P>The following lists demonstrate nesting.</P>
         <Ordered style="list-style-type: lower-roman;">
     <P>Another nested list.</P>
         <Ordered style="list-style-type: lower-roman;">

The style sheet is identical to the "sample style sheet for HTML 4.0" given
except that OL and LI have been replaced by "Ordered" and "Item" --- to
prevent any possible, though inappropriate, "carryover" of HTML behavior.

This displays just as it appears to be intended in Internet Explorer 6.
(Opera, however, fails to increment the hidden "counter" at all.)

*** Implicit counter-resets ***

Here is a list of all the properties applied to "Ordered" and "Item"
(omitting bidi and non-screen media entries) in the above example:

     Ordered    { display: block }
     Item       { display: list-item }
     Ordered    { margin: 1.33em 0 }
     Ordered    { margin-left: 40px }
     Ordered    { list-style-type: decimal }
     Ordered UL, UL Ordered,
     UL UL, Ordered Ordered    { margin-top: 0; margin-bottom: 0 }
Is Internet Explorer in error in making it possible to generate lists in
XML using only the CSS1-style list properties?

If not, then the "hidden counter" in CSS1 (which is also hidden in CSS2)
must be implicitly reset *somehow* --- what rules does it follow?  Neither
the CSS1 nor the CSS2 standards say anything about this.

*** Are CSS1 and CSS2 "complete" with regard to list presentation? ***

we read:
     The more general of the two mechanisms is new in CSS2 and is called
     markers. The more limited mechanism involves the list properties of
     CSS1. The list properties give authors quick results for many common
     ordered and unordered list scenarios. However, markers give authors
     precise control over marker content and position. Markers may be used
     with counters to create new list styles, to number margin notes, and
     much more. 

Counters and markers did not exist in CSS1; the list properties did
(and are unchanged in CSS2 except for the addition of more values
for the "list-style-type" property).

These points lead me to believe that the list properties alone are
*supposed* to be able to specify presentation of lists (when numbering
isn't overridden by the deprecated START or VALUE attributes) ---
apparently the designers of Internet Explorer 6 thought so, too.

These properties are useless unless the "counter" used for numbering list
items is somehow incremented and reset.  Since that "counter" cannot be
accessed directly in CSS1 (because CSS1 doesn't have counters) or in CSS2
(because it is not given a name), these functions must either be:
     1. somehow implied by use of the CSS1/CSS2 list properties; or
     2. defined "out-of-band" (e.g., as part of the semantics of the
        document language).

*** Exposing the counter ***

If we conclude that option 1 is more sensible, then the "hidden counter" in
CSS1 (which is also hidden in CSS2) must be implicitly reset *somehow*; and
if CSS3's exposed counter is to be compatible with the hidden counter used
in CSS1 (and in CSS2, when using list properties rather than counters and
markers to format lists), then this implicit behavior must be defined, and
it will impact the coding of explicit counter manipulations.

Do we say that when a list-item is a :first-child, it also gets an implicit
counter-reset?  Or that list-style-type, while inherited, also produces a
non-inherited effect of counter-reset?  Or that where an element with
"display: list-style" occurs and no ancestor of that element (which is also
a descendant of the nearest ancestor that has "display: list-style" if
there is such an ancestor) includes "list-item" in its counter-reset
property, then "list-item" is added to the counter-reset property of the
parent?  (That last is a nightmare, but it attempts to say, "if there's not
an appropriate counter-reset already --- taking nesting into account ---
then add one to the immediate parent."  That would probably produce
"expected" behavior in most cases, but it seems rather "un-CSS-like.")

I can't see any way to define behavior consistent with that of the
unexposed counter that won't be clumsy and unintuitive when combined
with the new, exposed counter.  If there is one, great! --- but it needs to
be specified clearly.

On the other hand, if we say CSS3 list styles aren't to be compatible with
even the CSS1 implementation, then we invalidate existing style sheets that
*do* work in common browsers at present.  At that point, the motivation for
using "display: list-style" at all evaporates.

*** "Passing the buck" to HTML ***

If we accept option 2, then Internet Explorer 6 is wrong: it shouldn't be
possible to generate HTML-style lists in XML with the "display: list-style"
property in CSS1 or CSS2.

This would get CSS3 "off the hook" with regard to the "counter-reset"
problem: resetting the counter is just defined as an HTML side-effect that
was previously not representable in CSS, but for CSS3 must be included in
the user agent default style sheet.

However, this makes style sheets for XML that now work (at least in IE 6)
fail under CSS3 by insisting that they were never supposed to work in the
first place --- that part of CSS1/2 was only supposed to work with HTML.

I wonder what this would do to XHTML?  I'm not familiar with the logic of
that standard, so I really can't guess whether this would be problematic.

>I would love to hear any comments you have on this draft and how it should be 

I will try to come up with some... unfortunately, saying what appears to be
wrong is a lot easier than proposing a better alternative.  ;-)
Randall Joseph Fellmy aka

Received on Tuesday, 26 March 2002 17:14:12 UTC