Re: Nightmare on generated content street

I wrote:
> I've just considered it, and I think I've come up with quite a good
> suggestion - simply use my self-nesting rules for display: list-item and
> the existing ones for other generated content.
> 
> Until such time as these changes gain adoption, 

I think if a UA wants a sensible display: list-item implementation, it
will probably have to use them now (unless someone can come up with a
better idea...).

Now having decided the basic rules of self-nesting, etc., it remains
only to specify the way in which counter functions are created; i.e.,
how do they fit in with the cascade?

Here's my complete proposal for display: list-item:
<proposal>
DISPLAY: list-item
Display: list-item establishes a counter function, the scope of which is
the element and all its siblings. A counter function is established for
each ruleset that specifies display: list-item. For example, P {display:
list-item} establishes a counter function that applies to P elements.

<example>
Thus P {display: list-item; list-style: decimal inside} and:
<P>
This is a P element that is behaving like a list item.
</P>
<P>
This is a P element that is behaving like a list item.
</P>
 would create the following effect:

1. This is a P element that is behaving 
like a list item.
2. This is a P element that is behaving 
like a list item.

However, 
<P>
This is a P element that is behaving like a list item.
</P>
<DIV>
<P>
This is a P element that is behaving like a list item.
</P>
</DIV>
would create this effect:
1. This is a P element that is behaving 
like a list item.
1. This is a P element that is behaving 
like a list item.
because reusing the counter function in an indirect descendant (i.e.,
one that is deeper in the document tree) establishes a new instance of
the counter function.
</example>

Where multiple conflicting counter functions exist for an element (this
can only occur as a result of counter functions having different
specificities), the one that is used is determined by the cascade. For
example, P.class {display: list-item} P {display: list-item}
<P>
&nbsp;
<P class=class>
&nbsp;
creates:
<P>
1. 
</P>
<P class="class">
1.
</P>
because the P.class counter function has greater specificity, so it is
incremented and used  but the other one is not (this is because an
element cannot have more than one marker box).

Authors should be aware that these rules can fool the unwary - OL LI
{display: list-item} and LI {display: list-item} could conflict with
strange results.

However, thanks to the display: list-item nesting rules, it is only
necessary to specify LI {display: list-item} - there are no separate
rules required for OL LI and UL LI -
<OL>
<LI>
</LI>
<UL>
<LI>
</LI>
</UL>
</OL>
creates two counter functions  - because the LI counter function is
reused in an indirect descendant element, it establishes a new counter
function
</proposal>

I believe this proposal fully specifies the current behaviour of LI
elements; moreover it allows interesting effects with other elements and
does not contain any ambiguities.