Closed
Bug 1049
Opened 26 years ago
Closed 25 years ago
{css1} CSS list-style-position not supported
Categories
(Core :: Layout, defect, P2)
Tracking
()
VERIFIED
FIXED
M11
People
(Reporter: dbaron, Assigned: peterl-retired)
References
()
Details
(Keywords: css1, Whiteboard: suggested fix included)
The CSS1 property list-style-position is not supported. (Possible values are
inside and outside. See the above URL).‰
Reporter | ||
Comment 1•26 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 :-)
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•26 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•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•26 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•26 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•26 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•26 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•26 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•26 years ago
|
||
Yes, It does. (at least it should and will.)
Reporter | ||
Comment 10•26 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•26 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•26 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•26 years ago
|
Target Milestone: M7
Reporter | ||
Comment 13•25 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•25 years ago
|
QA Contact: 4144 → 4110
Updated•25 years ago
|
Severity: enhancement → normal
Summary: CSS list-style-position not supported → {css1} CSS list-style-position not supported
Whiteboard: suggested fix included
Comment 14•25 years ago
|
||
This is not an RFE, it is an implementation bug in ua.css. Moving severity
up to Normal.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M10 → M11
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•25 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•25 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 16•25 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•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Assignee | ||
Comment 17•25 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•25 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•25 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•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 20•25 years ago
|
||
Using 9/15 Apprunner with URL provided, verified fixed.
Comment 21•25 years ago
|
||
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.
Description
•