Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 1049 - {css1} CSS list-style-position not supported
: {css1} CSS list-style-position not supported
suggested fix included
: css1
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Other
: P2 normal (vote)
: M11
Assigned To: Peter Linss
: Christine Hoffman
: Jet Villegas (:jet)
Depends on:
  Show dependency treegraph
Reported: 1998-10-09 17:46 PDT by David Baron :dbaron: ⌚️UTC-7
Modified: 2000-01-13 15:58 PST (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description David Baron :dbaron: ⌚️UTC-7 1998-10-09 17:46:16 PDT
The CSS1 property list-style-position is not supported.  (Possible values are
inside and outside.  See the above URL).‰
Comment 1 David Baron :dbaron: ⌚️UTC-7 1998-12-02 21:35:59 PST
Just a friendly little nudge:  this is one of *two* CSS1 properties that you
don't support at all (and the other is background-attachment, where you are
waiting for a spec clarification.)  It would be a nice milestone :-)
Comment 2 kipp 1998-12-07 16:58:59 PST
Actually, we have supported it forever, but the way our ua.css is written it
won't work until we have css2's selector syntax.
So I'm reassigning this to peter until we do...
Comment 3 David Baron :dbaron: ⌚️UTC-7 1998-12-08 13:33:59 PST
I don't quite understand what you meant by either of the comments.  It doesn't
work in the above URL.  What does that have to do with ua.css?  And I don't see
any CSS2 selector syntax in ua.css, but CSS2 selector syntax would sure be
Comment 4 Peter Linss 1998-12-08 13:48:59 PST
What Kipp means is that there's a rule in ua.css setting the list-style-position
on LIs, so the inherited value is getting overridden.
The rule is there for backward compatibility with LIs that are outside a list
If you put a rule on the LI itself, it should work.
The ua.css needs to be updated to make this work, however, the correct mechanism
relies on CSS2 '+' selectors, which aren't implemented yet.
Comment 5 David Baron :dbaron: ⌚️UTC-7 1998-12-08 14:30:59 PST
Wouldn't it be better than it is now if you set HTML { list-style-position:
inside;} and UL, OL, DIR, MENU {list-style-position: outside; } (which I think
is what you would want to do eventually anyway...)?

Then there would only be two problems, nested lists and specifying the list-
style-position on the ancestor of a list.  The second would be solved with
descendant selectors (UL+LI+UL {list-style-position: inherit;}, etc. (15 other
ways)).  The first could reasonably be left unsolved.
Comment 6 David Baron :dbaron: ⌚️UTC-7 1998-12-08 14:50:59 PST
Ack... I was getting descendant and adjacent sibling selector syntax mixed up.
I meant UL>LI>UL, etc.  I don't quite see how to do it with adjacent sibling
Comment 7 Peter Linss 1998-12-08 15:27:59 PST
I had them backwards too. Setting the 'inside' property on HTML subverts the
initial value of list-style-position.
The fix I'm waiting to put in removes the LI {list-style-position:inside} rule
and adds BODY > LI, DIV > LI, ... { ...:inside} (plus whatever else can contain
a LI, besides lists of course). Then nothing gets in the way of anything.
Comment 8 David Baron :dbaron: ⌚️UTC-7 1998-12-08 15:50:59 PST
OK... I guess there aren't that many elements that can contain block level
elements.  This is assuming (which I'm not sure of) that the parser parses
<SPAN>a<LI>b</LI>c</SPAN> into
<SPAN>a</SPAN><LI><SPAN>b</SPAN></LI><SPAN>c</SPAN>, which is of course
illegal, but common (... which is the whole problem here to begin with).
Comment 9 Peter Linss 1998-12-08 16:03:59 PST
Yes, It does. (at least it should and will.)
Comment 10 David Baron :dbaron: ⌚️UTC-7 1999-03-04 19:43:59 PST
This seems ready to be fixed (now that you have child selectors) ... but
perhaps your current fix is better??  Maybe even:

li { ... inside } /* will handle body > li, td>li, etc., etc. */
ul > li, ol > li, dir > li, menu > li { ... outside } /* are these the only
valid places according to the DTD.  I think so... */
Comment 11 David Baron :dbaron: ⌚️UTC-7 1999-03-05 11:26:59 PST
My last comment was the result of temporary insanity :-).  The last line should
have been:

ul > li, ol > li, dir > li, menu > li { ... inherit; }

(inherit, not outside!  otherwise it doesn't fix the problem.)

This doesn't handle the case where someone has nested lists that are contained
in an LI as the outermost level.
Comment 12 Paul MacQuiddy 1999-03-05 22:38:59 PST
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at
Comment 13 David Baron :dbaron: ⌚️UTC-7 1999-04-25 08:27:59 PDT
OK... I think this is my best idea so far:

/* rule 1 - change badly nested list items */
li { list-style-position: inside; }

/* rule 2 - override rule 1 for lists within badly nested li's */
li > ul, li > ol, li > dir, li > menu { list-style-position: outside; }

/* rule 3 - override rule 1 for properly nested list items */
ul > li, dir > li, menu > li, ol > li { list-style-position: inherit; }

/* rule 4 - override rule 2 for properly nested lists */
ul ul, ul dir, ul menu, ul ol, dir ul, dir dir, dir menu, dir ol, menu ul, menu
dir, menu menu, menu ol, ol ul, ol dir, ol menu, ol ol {
list-style-position: inherit;

Putting this in ua.css should do exactly what you want.
Comment 14 Hixie (not reading bugmail) 1999-05-18 06:47:59 PDT
This is not an RFE, it is an implementation bug in ua.css. Moving severity
up to Normal.
Comment 15 Peter Linss 1999-09-10 14:56:59 PDT
David, I believe we only need the rules:
li { list-style-position: inside; }
ul li, dir li, menu li, ol li { list-style-position: inherit; }
to make this work right in all situations. Can you or Ian perhaps concoct an
evil test to prove this?
Comment 16 David Baron :dbaron: ⌚️UTC-7 1999-09-10 15:51:59 PDT
This will work badly in the following cases (I'm more worried about the first):

<li> Item
    <li> Item, l-s-position inside!
    <li> Item, l-s-position inside!
(an author may not even realize the ul is inside the li there, without my


       Blah blah blah...
       <li>Item, l-s-position outside!

Now that I think about the second one, my Rule four should have all
"A B" replaced with "A > LI > B".

I suspect there's all kinds of weird stuff out there because people don't know
the rules for what ends an li element.

Comment 17 Peter Linss 1999-09-10 16:33:59 PDT
Ok, added:
li ul, li ol, li dir, li menu { list-style-position: outside; }
to fix the list inside a LI problem. We actually can't use '>' selectors because
there may be other markup between the LI and the list (like <B>).
In your second example, the LI in DIV in LI in UL, the bullet acutally *should*
be outside (Nav behavior).
Comment 18 David Baron :dbaron: ⌚️UTC-7 1999-09-10 17:31:59 PDT
Is that rule *before* the ones you gave earlier???

That is, will the following work as it should:

<ul style="list-style-position: inside">
  <li>item, inside
       <li>item, outside or inside?????
Comment 19 Peter Linss 1999-09-11 11:22:59 PDT
Ok, ok, I get it now. This should do it. Could you please create a testcase that
includes all those permutations and attach it to the bug? It'll help test for
Comment 20 Christine Hoffman 1999-09-16 11:42:59 PDT
Using 9/15 Apprunner with URL provided, verified fixed.
Comment 21 Hixie (not reading bugmail) 2000-01-13 15:58:59 PST
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Note You need to log in before you can comment on or make changes to this bug.