22899 - [LIST][Parser?]<ul> bullets can't be colored

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Robert Kaiser]

try this piece of code:

<font color="#FF9F00">
<ul>
<li><font color="#000000">item 1</font>
<li><font color="#000000">item 2</font>
<li><font color="#000000">item 3</font>
</ul></font>

in MSIE 5 and Nav4.7 the bullets of the unordered list are orange (#FF9F00), in
Mozilla (build 2000010108, win98) they're black. Is this according to the
standards and only a compatibility issue (means MSIE and Nav4.7 fail to support
standards here), or is this false behaviour and a bug?

It's not very serious, I know, but it's a difference to the other browsers...
(and the effect of colored bullets looks good...)

Comment 1

[troy]

Block/inline issue

Comment 2

[buster]

post-beta issue, moved to M16

Comment 3

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 4

[buster]

moving to M19

Comment 5

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 6

[Hixie (not reading bugmail)]

Not an HTML4 issue (the test case is not valid).

Comment 7

[Robert Kaiser]

ok, looks like it is really only a compat bug. look at the attached file (I'll 
attach it in the next minutes) containing the html4 compliant code applying here 
(using <span>), and the code I included in the testcase above (using <font>).
There is another bug if I use <span>, though, so that "item x" is not displayed 
next to the bullet, but one line below it.

Comment 8

[Robert Kaiser]

Attachment: Testcase showing use of font and span tags for coloring

Comment 9

[buster]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 

Comment 10

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

There seem to be some parser issues here with the Transitional DTD, too...

What happens if you modify the 3d case (in the attached testcase) so there's no 
FONT elem outside the UL (and put a color on the FONTs inside the LIs)?

Comment 11

[Robert Kaiser]

David (dbaron), if I do that, the bullets are black and the text is colored,
just as NS4.7 and IE5 render it.
So the difference (bug) appears to be that only the color of a <font> outside
the list is not applied to the bullets (it is applied to the list text though).

In the first example, there is a second bug (line break where it shouldn't be),
dunno if it's reported. If not, it should be split off this one.

Comment 12

[Robert Kaiser]

Attachment: Second, extended tescase (see comment)

Comment 13

[Robert Kaiser]

I attached an extended version of the testcase here, and I'm explaining what is
and should be displayed in the 5 cases there:

case 1: HTML4 strict compliant, span inside li
NS4 & IE5: orange bullet, black text
Mozilla: orange bullet, line break, black text (colors ok, different bug)

case 2: HTML4 strict compliant, no span inside li
NS4 & IE5: orange bullet, orange text
Mozilla: orange bullet, orange text (ok)

case 3: non-HTML4 strict (but transitional) compliant, using font inside li
NS4 & IE5: orange bullet, black text
Mozilla: black bullet, black text (bullet not colored)

case 4: non-HTML4 strict compliant, using font inside li, no font outside ul
NS4 & IE5: black bullet, orange text
Mozilla: black bullet, orange text (ok, bullet shouldn't be colored)

case 5: non-HTML4 strict compliant, using NO font inside li, BUT OUTSIDE ul
(!labeled false in the test case!)
NS4 & IE5: orange bullet, orange text
Mozilla: black bullet, orange text (bullet not colored)

Note that there is no difference if li is closed or not.
Tested again with 2000061708 (win32)

Comment 14

[Robert Kaiser]

I read about bug 96031 in bonsai, and supposed the fix which was checked in
would also fix this one. I looked at both testcases (note that only the second
is well-documented in this bug), and see this fixed with a build from 2001-09-03
on Linux. I suppose I would see the same on other platforms as the fix to 96031
isn't linux-specific.

Marking FIXED, adding dependency to 96031 as the fix connected those bugs.
(always nice to see that old bugs get fixed)

Comment 15

[Sebastian Späth]

This works under Winows (WinNT) as well. Suggest to mark this one verified.

Comment 16

[Sebastian Späth]

actually verifying, if it's still broken on Mac please reopen