RE: DSSSL & Interleaf

Glenn Adams wrote:
>This solution is specific to the document in question and wouldn't
>work as a default.  The primary problem here is CSS's inability to
>qualify ancestors as to immediate ancestry and to specify ancestors
>which "block" an ancestry path.

My fault for not exploring Netscape's behaviour more thoroughly.  I believe 
it is somewhat possible to describe blocking ancestors (see below); perhaps, 
if good reason is offered, immediate ancestry can be added to the CSS spec. 
 It doesn't seem like such a difficult addition, to either the spec or my 
implementation... anyone else?  At any rate, my impression stands - this is 
a Netscape anomaly (bug, if you prefer) - I believe, depending on 
interpretation, the second <LI> in your document should either 1)terminate 
the first <LI>, and therefore the table - which would not cooperate with 
existing implementations very well, 2) use the viewer's default behaviour 
for encountering an <LI> in %flow with no surrounding <OL> or <UL>, which is 
generally to assume an encapsulating <UL> - this appears to be almost what 
Netscape does, except there is some indentation inconsistency when it does 
this, or 3) properly allow <LI>s to occur in %flow, as long as they are 
contained in an <OL> or <UL>.  In this case, one would expect them to be 
treated as part of the nearest surrounding list (which is what Internet 
Explorer does in your test case).

Here's a slightly better stylesheet:
	/* As in the HTML 2.0 stylesheet */
OL { list-style: decimal }
LI { margin: 3em }
	/* To account for Netscape anomaly */
OL TABLE { list-style: disc }
OL TABLE LI { margin: 0em; text-indent: 3em }
	/* To return behaviour to normal */
OL TABLE OL { list-style: decimal }
OL TABLE OL LI { margin: 3em; text-indent: 0em }