1049 - {css1} CSS list-style-position not supported

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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-4, no longer working on Mozilla)]

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]

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-4, no longer working on Mozilla)]

Kipp-
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
nice...

Comment 4

[Peter Linss]

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
container.
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-4, no longer working on Mozilla)]

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-4, no longer working on Mozilla)]

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
selectors.

Comment 7

[Peter Linss]

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-4, no longer working on Mozilla)]

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]

Yes, It does. (at least it should and will.)

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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-4, no longer working on Mozilla)]

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]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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)]

This is not an RFE, it is an implementation bug in ua.css. Moving severity
up to Normal.

Comment 15

[Peter Linss]

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-4, no longer working on Mozilla)]

This will work badly in the following cases (I'm more worried about the first):

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

and:

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

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.

Reopening.

Comment 17

[Peter Linss]

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-4, no longer working on Mozilla)]

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
    <ul>
       <li>item, outside or inside?????
    </ul>
</ul>

Comment 19

[Peter Linss]

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
regressions...

Comment 20

[Christine Hoffman]

Using 9/15 Apprunner with URL provided, verified fixed.

Comment 21

[Hixie (not reading bugmail)]

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...