{css1} CSS list-style-position not supported

VERIFIED FIXED in M11

Status

()

Core
Layout
P2
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: dbaron, Assigned: Peter Linss)

Tracking

({css1})

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: suggested fix included, URL)

(Reporter)

Description

19 years ago
The CSS1 property list-style-position is not supported.  (Possible values are
inside and outside.  See the above URL).‰

Updated

19 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 1

19 years ago
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 :-)

Updated

19 years ago
Assignee: kipp → peterl
Status: ASSIGNED → NEW

Comment 2

19 years ago
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...
(Reporter)

Comment 3

19 years ago
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...
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 4

19 years ago
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.
(Reporter)

Comment 5

19 years ago
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.
(Reporter)

Comment 6

19 years ago
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.
(Assignee)

Comment 7

19 years ago
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.
(Reporter)

Comment 8

19 years ago
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).
(Assignee)

Comment 9

19 years ago
Yes, It does. (at least it should and will.)
(Reporter)

Comment 10

19 years ago
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... */
(Reporter)

Comment 11

19 years ago
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

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

Updated

18 years ago
Target Milestone: M7
(Reporter)

Comment 13

18 years ago
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.

Updated

18 years ago
QA Contact: 4144 → 4110
Severity: enhancement → normal
Summary: CSS list-style-position not supported → {css1} CSS list-style-position not supported
Whiteboard: suggested fix included
This is not an RFE, it is an implementation bug in ua.css. Moving severity
up to Normal.
(Assignee)

Updated

18 years ago
Target Milestone: M10 → M11
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

18 years ago
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?
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 16

18 years ago
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.
(Assignee)

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
(Assignee)

Comment 17

18 years ago
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).
(Reporter)

Comment 18

18 years ago
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>
(Assignee)

Comment 19

18 years ago
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...

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 20

18 years ago
Using 9/15 Apprunner with URL provided, verified fixed.
Keywords: css1
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...
You need to log in before you can comment on or make changes to this bug.