38174 - [LIST] List numbers and bullets ignore FONT changes

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect, P3)

Description

[Chris LaRosa]

When a list (<OL> or <UL>) is enclosed within a <FONT> element, the numbers or 
bullets in the list do not use the <FONT> attributes.  The contents of the list 
does use the <FONT> attributes, however.

The numbers in this HTML example are displayed with black normal size font 
instead of white large size font:

<FONT COLOR=WHITE SIZE=+3>
<OL>
<LI>One
<LI>Two
<LI>Three
</OL>
</FONT>

Comment 1

[Kevin McCluskey (gone)]

Reassigning to buster - Triaging Troy's bug list

Comment 2

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

Confirming bug.  This could be a residual style issue.  (Is there really a need
for residual style to be used in this case?  It ought to work if layout were
given the content model as written, even though it's invalid...)

Comment 3

[buster]

I'd have to look, but I'll bet the style context is correct, and we're just 
ignoring it.  Marking it {list} and pushing it down on my priority list.

Comment 4

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 5

[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 6

[Chris LaRosa]

In my opinion, this bug should be corrected before the final release of 
Netscape 5.0.  The following browsers all change the font of the numbers in an 
ordered list:  Netscape Navigator 3.x, Netscape Communicator 4.x, Internet 
Explorer 4.x, and Internet Explorer 5.x, Opera 3.60.  These are the only 
browsers I have tested -- there are probably more with this behavior.  Breaking 
the well-established behaviors of existing browsers may slow public acceptance 
of Netscape 5.0.  Since many web pages use custom background and font color 
schemes, I think this feature is important since it's the only way to change 
the color of the numbers in a list (note:  I haven't tested CSS behavior).

Comment 7

[Asa Dotzler [:asa]]

*** Bug 42127 has been marked as a duplicate of this bug. ***

Comment 8

[Mats Palmgren (inactive)]

*** Bug 60929 has been marked as a duplicate of this bug. ***

Comment 9

[Jubal Kessler]

Anybody looking at this one? Been over a year now.

It's an annoying ugly little glitch of a bug.

Thanks,

Jubal

Comment 10

[basic]

Build 2001062420 win32 on win98
Based on the testcase this looks fixed to me

Comment 11

[Jubal Kessler]

Linux build 2001062508

This isn't fixed for the Linux build at least. I still see black normal size
numbers and bullets instead of larger-size white numbers and bullets.

Comment 12

[basic]

Ooops... sorry I'm still seeing the bug.

Comment 13

[basic]

Setting OS and Platform to ALL

Comment 14

[basic]

Attachment: testcase: apply innerHTML on document.documentElement

Comment 15

[basic]

The attached testcase attachment 40039 [details] uses innerHTML to show the actual
document structure used by Mozilla.

Comment 16

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 17

[Axel Hecht]

OK, I see the problem here:
FONT is a text level element, and must not contain block level elements, like
P or UL. So the mozilla code fixes this up by applying the font tags to the
LI one by one, and misses the bullets. Bad html gives bad foo type of bug.

Comment 18

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 117572 has been marked as a duplicate of this bug. ***

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 156202 has been marked as a duplicate of this bug. ***

Comment 20

[Christopher Stone]

I have noticed that in some cases the bullets will observe the font color.  I
have seen a case where the font color is observed after the first <li> on a new
line.  Quite odd behavior.  The first bullet was black, and all subsequent
bullets where white.  When I put the <ul> and <li> on seperate lines, then all
bullets were white.

Perhaps some deeper stranger bug is at play here?

Comment 21

[Christopher Stone]

Attachment: Demonstrates Work-Around for this Bug

This bug only shows up where there is no space between the <UL> and <LI>
markups.  See the attached html as an example.

Comment 22

[Blake Kaplan (:mrbkap) (inactive)]

Moving this to HTML parser and taking (since, as pointed out in comment 2) this
is in fact a residual style problem.

Comment 23

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

The problem here is that even though <li> is a container (and not an RS tag),
we need to open transient styles around it so that the bullet also has the
styles applied to it.

Note that I feel safe special-casing <li> here because <li> is the only
container that implicitly has leaf content in it. If it's felt to be needed, I
could make this a special property in the element table (kHasLeaf or something)
and check that instead.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 183741 [details] [diff] [review]
patch v1

r=bzbarsky

Comment 25

[Brendan Eich [:brendan]]

Comment on attachment 183741 [details] [diff] [review]
patch v1

Sorry to nit-pick, but wouldn't li_tag be more consistent with rs_tag as a
name?  Nominating for 1.8b2 but I'll let some other driver approve.

/be

Comment 26

[Asa Dotzler [:asa]]

Comment on attachment 183741 [details] [diff] [review]
patch v1

a=asa

Comment 27

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked in.

Comment 28

[Blake Kaplan (:mrbkap) (inactive)]

*** Bug 191949 has been marked as a duplicate of this bug. ***