Please no Counters!

Bert Bos wrote:
> I'd very much like to keep them underpowered like this, since I'm very
> hesitant about generated content. I can see that some generated content
> can be classified as `style' or `decoration,' but it is easy to see how
> generating content from within the style sheet can also lead to one-line
> HTML files, with all the content in the style sheet (as already happens
> with scripts sometimes).

#1. Why is it a problem with stylesheets but not with scripts and
"dynamic content?"

#2. Why would anyone put all of their content in a stylesheet? What's
the point?
 
> The idea is that counters are declared with an @-rule, and can then be
> used in the `content' property. Counters must be declared explicitly,
> since it is impossible to predict what kinds of things you might want to
> count.
> 
> We've looked at ways to avoid introducing arbitrary counters, but no
> predeclared set of counters seemed able to do the job.

Predeclared counters will do 99% of the job and they will be better in
the long run.

Here's what I envision as predeclared counters (based on DSSSL's):

child-number
    // e.g. Paragraph "5"
    // this element's position in the parent element

ancestor-child-number( div  ) 
    // e.g. "3"
    //   this element's position in some ancestor, like a div

hierarchical-number( "Part", DIV.part, "Paragraph", p)
    // e.g. "Part 3, Paragraph 4"
    //   this element's position in some ancestor, and its position in 
    //   another ancestor

hierarchical-number( DIV.section, "." )
    // e.g. Section 3.2.4
    //   this element's position in some ancestor, and its position in 
    //   another ancestor of the same name

This simple "counting language" can be enhanced both in syntax and
power. It is also very scalable.

a) Simple to use. No predefinition or predeclaration! For the simple
cases you just use it like this:

LI:before{ content: child-number ". " }
DIV.section:before{ 
	content: Section hierarchical-number{ DIV.section,"." 
}

b) More powerful. No finite number of predeclared counters can give you
the equivalent of the line above that will display "Section
5.3.2.4.56.4.3.2.3.4.5.4.3.2.2" if necessary. People should be able to
reuse stylesheets without worrying about arbitrary limitations, right?

c) Easier to implement in a fast wordprocessor.

Using this model a DSSSL based word processor can display the last page
of a 10MB SGML file *without applying the stylesheet to the first
9.8MB*. The file must be parsed of course, but no style attributes need
be applied to it at all. In Web terms that means that you can request a
fragment at the end of a very long document and some context information 
and you can display it without even getting the rest of the document! 
This is too important to give up.

d) DSSSL compatible.

W3C people have given lip service to the fact that they hope that both
CSS and DSSSL get implemented and that they hope that vendors can use
the same implementation model. This will not happen if CSS grows in ways
that are radically different than DSSSL. DSSSL's implementors thought
about the linear dependence problem and steered far away from the
counter model. This is your big chance to show how important aligning 
the implementation models of these languages is.

e) Compatible with the Cascade

I can't believe that I'm the one pointing this out, but: what happens if
you set up a counter and someone overrides some of the elements that
increment it, but not all. All of the other things get numbered wrong
and references to a particular item number goes out of whack. For
instance, maybe I set up counter to count paragraphs. I set up a cascade
to collapse all of the paragraphs in a particular section or a
particular kind of section. I don't want empty paragaphs with "ghost"
counters in front so I override the before and after too and change them
to empty strings. Now the numbering of all of the other paragraphs is
wrong!

 Paul Prescod

Received on Tuesday, 6 May 1997 22:37:34 UTC