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 }
-Chris