- From: Chris Wilson (PSD) <cwilso@microsoft.com>
- Date: Mon, 15 Jan 1996 11:11:36 -0800
- To: Glenn Adams <glenn@stonehand.com>
- Cc: "www-style@w3.org" <www-style@w3.org>, Multiple recipients of list <html-wg@fssun09.dev.oclc.org>
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 }
-Chris
Received on Monday, 15 January 1996 14:12:21 UTC